Date: Tue, 16 Dec 2008 10:27:28 -0800 From: Sam Leffler <sam@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 154573 for review Message-ID: <4947F310.5050403@freebsd.org> In-Reply-To: <200812161722.06337.hselasky@c2i.net> References: <200812122326.mBCNQX6w024511@repoman.freebsd.org> <200812141623.51473.hselasky@c2i.net> <494598B0.9090501@freebsd.org> <200812161722.06337.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote:
> On Monday 15 December 2008, Sam Leffler wrote:
>
>> Hans Petter Selasky wrote:
>>
>>> On Saturday 13 December 2008, Sam Leffler wrote:
>>>
>>>> Hans Petter Selasky wrote:
>>>>
>>>>> On Saturday 13 December 2008, Sam Leffler wrote:
>>>>>
>>>> No. But if you are interested in helping debug the problem I'm happy to
>>>> send you debug output. The controller rejects all cmds setting the
>>>> ERRINT status bit. The qTD contents and xfer contents look fine but I
>>>> haven't been able to identify the cause given the overlay qTD contents.
>>>> I'm in the process of collecting comparative traces from linux where usb
>>>> works.
>>>>
>>> Send me the EHCI traces and I will have a look at it. Have you tried
>>> USB2? The patches which you need to apply should be similar.
>>>
>> This is what I get w/ sysctl hw.usb.ehci.debug=6 for the first cmd
>> submitted after card insert:
>>
>>
>
>
>> Subsequent cmds fail similarly. I don't see the issue and don't
>> understand how to use the overlay qTD information to pinpoint the reason
>> the controller is rejecting the request.
>>
>> This happens w/ either of the 2 USB ports (1 port / controller):
>>
>>
>
> Hi Sam,
>
> The overlay qTD is a copy of the last processed QTD. You might need to do a
> cache invalidate on the memory region before reading it.
>
Yes, this is what the docs says about the overlay qTD but what do the
2nd and later words mean? They went from:
buffer[0]=0x014b8a3c
buffer[1]=0x00000000
buffer[2]=0x00000000
buffer[3]=0x00000000
buffer[4]=0x00000000
to:
buffer[0]=0x014b8a3c
buffer[1]=0x00000008
buffer[2]=0x00000000
buffer[3]=0x00000000
buffer[4]=0x00000000
All memory allocated to hold usb data structures are allocated coherent
so should not require an invalidate. I have also inserted explicit
dcache invalidates while debugging this issue "just in case".
USB works fine on another xscale platform where the usb controller is on
the pci bus so I'd expect any cache coherency issues to already be dealt
with (I found the PIO cache invalidate issue I fixed a while back on
this other board).
> What I see:
>
> - The first TD completed successfully, and that TD had a lower physical memory
> adddress than the one that failed.
>
> buffer[0]=0x01091fc8
>
> vs:
>
> buffer[0]=0x014b8a3c
>
> - Halted usually means that that you had a STALL token sent from the device to
> the host, which indicates that the contents of the SETUP packet (PID=2), in
> the first TD did not contain valid data, possible due to a missing cache
> flush.
>
> return ((status & EHCI_QTD_HALTED) ?
> USB_ERR_STALLED : USB_ERR_NORMAL_COMPLETION);
>
>
So maybe this answers one question I have; is this error from the device
or the controller? Am I actually talking to the device? It appears the
controller is functional as I get interrupts, get status for things like
ports, etc. Remember this is a big-endian host. On another xscale
platform the usb controller is on the pci bus and we setup xfers
(dma+pio) to be swizzled by the byte lane hardware so everything just
works wrt little-endian-ness. I've been searching for something
byte-order related that is missing. The linux usb code swizzles
descriptor contents on the host but I don't see it doing anything to the
data sent to the device; it's still little-endian.
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4947F310.5050403>