On 03/13/12 05:37, Brandon Gooch wrote:
On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selasky<hsela...@c2i.net>  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?

It is SCSI protocol that "down rev'ed", not USB. AFAIK this came from old SPI era when SCSI protocol version was same for device and controller, limited by transport type. At this moment, with many possible transports, I believe this message lost its informativeness.

--
Alexander Motin
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to