On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selasky <[email protected]> wrote: >> >> Is there something fishy happening between the USB stack and CAM? hmmm... >> > > No, > > It is not the CAM layer this time, though there are some bugs there too. > > > In the beginning of the log I see that in the successful case we receive a > stall event: > > -xhci_check_transfer: slot=1 epno=3 remainder=13 status=6 > -xhci_check_transfer: TD is last > -xhci_cmd_stop_ep: > -xhci_check_command: Received command event > -xhci_configure_reset_endpoint: Could not stop endpoint 3 > -xhci_cmd_reset_ep: > -xhci_check_command: Received command event > -xhci_cmd_set_tr_dequeue_ptr: > -xhci_check_command: Received command event > -xhci_cmd_evaluate_ctx: > -xhci_check_command: Received command event > -xhci_cmd_configure_ep: > -xhci_check_command: Received command event > -xhci_configure_reset_endpoint: Could not configure endpoint 3 > -xhci_ep_clear_stall: > -xhci_device_generic_enter: > -xhci_setup_generic_chain_sub: NTRB=1 > -xhci_setup_generic_chain_sub: LINK=0x82883180 > -xhci_setup_generic_chain_sub: NTRB=1 > -xhci_setup_generic_chain_sub: LINK=0x82883000 > -xhci_setup_generic_chain: first=0xffffff8460883300 last=0xffffff8460883180 > -xhci_device_generic_start: > -xhci_transfer_insert: qh_pos = 1 > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > -xhci_check_transfer: Following next TD > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > -xhci_check_transfer: slot=1 epno=1 remainder=0 status=1 > -xhci_check_transfer: TD is last > > > This is not received in the failing case. > > Maybe this indicates a lost interrupt or something like that? > > In /sys/dev/usb/controller/xhci.c > > static void > xhci_interrupt_poll(struct xhci_softc *sc) > > Add a printf: > > if (i == XHCI_MAX_EVENTS) { > i = 0; > j ^= 1; > > /* check for timeout */ > if (!--t) { > + printf("XHCI: > Timeout\n"); > break; > } > } > > > See if what happens. > > Also change the xhci.c code to call > > xhci_interrupt_poll() two times instead of one. > > > --HPS
Unfortunately, the condition was never reached. I've started trying to dtrace xhci(4) function boundaries, and, well there's a lot of recursion with xhci_interrupt_poll(). However, I never see that function called from xhci_do_poll(), which is called from xhci_interrupt() (to "catch any lost interrupts" according to the comment). You may have already told me this, but what does "Down reving Protocol Version from 2 to 0?" in the success case on my system? Is this the USB protocol which is "down rev'ed"? If so, what USB level is this flash drive running at? -Brandon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
