Date: Tue, 13 Mar 2012 08:57:40 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: Nathan Whitehorn <nwhitehorn@freebsd.org>, "freebsd-usb@freebsd.org" <freebsd-usb@freebsd.org> Subject: Re: Ongoing battle with umass(4) and xhci(4) Message-ID: <4F5EEFE4.2020402@FreeBSD.org> In-Reply-To: <CALBk6yLg7gt2ZkQPHQwTfA-NxCV9i6BHdjeiurk_6M4=3V9V8A@mail.gmail.com> References: <CALBk6y%2BoYS4CuXpt0Uwm_KsSPKyhtn2mCHaSk7O0meWoPB1ZzA@mail.gmail.com> <201203120915.18908.hselasky@c2i.net> <CALBk6yLg7gt2ZkQPHQwTfA-NxCV9i6BHdjeiurk_6M4=3V9V8A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/13/12 05:37, Brandon Gooch wrote:
> On Mon, Mar 12, 2012 at 3:15 AM, Hans Petter Selasky<hselasky@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F5EEFE4.2020402>