Hello David
I posted earlier questions regarding the scanning of qhs and is reproduced below
I used the standard idiom like below to dump all the qh and qtds.
qh = ehci->async->qh_next.qh;
if(qh)
{
do {
dbg_qh ("ehci-hcd",ehci, qh);
qh = qh->qh_next.qh;
} while (qh);
}
I do the above after the expiry of 30 seconds scsi timer and i always see that
there is only one queue head in the list where as i was expecting at least two
queue head. After reading the code, i think only active qh and its associated
qtds are shown. If a qh has no qtd,then above code fragment won't produce all
the qhs. Is this observation correct ?
Alternately, I tried to dump all the qhs by doing something like below
addr = readl(&ehci->regs->async_next);
addr = le32_to_cpu(addr); /* My system is big endian */
qh = (struct ehci_qh *)bus_to_virt(addr);
dbg_qh ("ehci-hcd",ehci, (struct ehci_qh *)qh);
addr = le32_to_cpu(qh->hw_next);
qh = (struct ehci_qh *)bus_to_virt(addr);
dbg_qh ("ehci-hcd",ehci, (struct ehci_qh *)qh);
The dword1 which contains RL,H,Device Address etc fields obtained using above
code fragment contained wrong values. Obviously i did something wrong above.
What am i missing here ? What is the correct way to dump all qhs either ?
Thanks.
Regards
Vivek
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Brownell
Sent: Monday, July 03, 2006 6:34 PM
To: Vivek Dharmadhikari
Cc: linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] decoding qh and qtds
On Monday 03 July 2006 4:57 pm, Vivek Dharmadhikari wrote:
[ again, please fix your mailer so lines wrap before 80 characters... ]
> Ok Got it. I really need to dump the entire all qh even if there are no qtds
> linked in them and need to modify the current code to do that.
Simple enough.
> I need to pass
> snapshot of qh and qts to hardware guy who can debug it further more. I am
> doing all this to debug a issue if you recall "host controller not issuing
> ping after 30 seconds".
Ah yes, that one. Glad you're looking at it ... it's not one
that reproduces for me! :)
> I dumped the qh given below at the end of 30 seconds
> timer and i see that there is 512 byte qtd waiting to be executed by the host
> controller but is not executed for some reason.
>
> qh/a1610100 dev2 hs ep1 42002102 40000000 (80008c01 data1 nak4)
> a1595120 out len=512 02008c80 urb 81612500
Presumably you verified that dev2 ep1out is a valid address.
I recall there were a few important pieces of information that
only came out with the dbg_*() macros, not through debug files.
> I would appreciate if you have any idea in this regards.
There are a bunch of funky (and sometimes racey) states in that area:
- Any empty scheduled QH should have a "dummy" td that's never
written into the overlay area ... except (RACE) some silicon
(AFAIK mostly ehci 0.95 implementations) will wrongly fetch it,
leaving the QH in a should-not-exist state. That silicon bug
should have a workaround in place (for a few years now)...
- Once such a QH is empty, it becomes eligible to be removed
from the async schedule after a EHCI_ASYNC_JIFFIES (~5msec)
or from the periodic schedule immediately. (Where "empty" is
checked after return from any urb completion call.) One RACE
is between that timeout and submission of a new URB.
- Removal uses IAA (which some silicon, notably VIA, seems not
to issue correctly) ... and there's a RACE between when the
QH is taken out of the hardware queue and when the hardware
actually sees that.
- Up until the IAA IRQ for that QH removal is received, any new
urbs tacked on its queue of QTDs could be acted upon by the
controller ... a RACE easily resolved by scanning the QH after
it's removed, which is also the spot that must decide whether
to reschedule that QH.
- When scanning a qTD list, there's also a race between the host
controller updating the overlay (which ISTR happens first) and
updating the QH. (Ought to be already resolved safely...)
- When removing the very last QH from the async ring, there's
a short delay before the async schedule is turned off.
- Turning the async schedule off isn't immediatel it can take
up to about 2msec, during which there are races with the
submission of new URBs.
So for example I've often seen a QH hit the "deschedule me"
timeout and start to be descheduled, right as an URB for that
endpoint gets submitted ... then had URBs (a) complete, which
is easy to cope with, or (b) complete partially, which takes
some care since on this path the overlay is more current than
the QTD it mirrors, or also (c) not start at all. Assuming that
URB wasn't being unlinked, both (b) and (c) involve immediate
rescheduling.
All this is complicated by the fact that the host CPU and EHCI are
both accessing the QH, its overlay, and qTDs concurrently. It's
simple if the qTD rolled off the front of the list when the controller
finished it. If it's actively rolling off, or the dummy is being
overwritten, then the exact sequence of memory reads and writes by
the host and the controller matter...
You might be hitting on a race I've not encountered before. If
your "hardware guy" has a PCI sniffer, I'd expect that logs of
accesses by the host and the USB controller to the pages of memory
allocated for QTD and QH pci_pool data would be informative.
If adding debug printks in those critical paths doesn't affect the
behavior you're seeing, I'd guess the issue is more related to one
of the QH overlay update races.
- Dave
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
