Linus Torvalds wrote:
Indeed it does!On Fri, 1 Nov 2002, David Brownell wrote:Oct 31 22:58:47 tove kernel: drivers/usb/core/message.c: usb_control/bulk_msg: timeout
Oct 31 22:58:47 tove kernel: drivers/usb/host/ohci-dbg.c: UNLINK dc8e2b1c dev:4,ep=0-I,CTRL,flags:0,len:0/1,stat:-2
Oct 31 22:58:47 tove kernel: drivers/usb/core/hcd.c: 00:02.2: wait for giveback urb dc8e2b1c
and clearly the "wait for giveback" never happens. (There are some other messages too, but they seem to be for the storage devices that do work)
One thing that might help is to provide the /sys/bus/pci/devices/00:02.2/async file contents when this happens. That'll be present since you enabled debug support, and it will show what your queues look like. Sometimes seeing that information has been enough to zoom right in on the problem, saving a bunch of time on mental "what if ..." experiments.Here: torvalds@tove:~> cat /sys/bus/pci/devices/00:02.2/async ed/c17e7180 fs dev4 ep2-in max 64 00401104 DATA0 td c17e8180 in 4096 cc=f urb c17d64bc (f0d00000) td c17e8080 in 4096 cc=f urb c17d64bc (f0140000) ed/c17e71c0 fs dev4 ep1-out max 64 00400884 DATA0 td c17e8240 out 4096 cc=f urb c17d6544 (f00c0000) Maybe that tells you something..
Firstly, that the control request is gone from the OHCI schedule,
so the problem's at a higher level than I'd suspected. There's
nothing there for ep0 there ... no wonder your printer thread
waits forever for the unlink to complete, it already completed!
Also, "usblp" has issued an up-to-8KB read, which looks to have
all the right bits in the TD for a transfer that's had no progress.
And also a write, of which 4KB seems to remain, can't tell if that
urb involved other tds. That much seems fine.
Your stack trace showed usblp_check_status() was what started this
sequence of troubles, so I looked at it. There were some issues,
it's got a lot of pretty early usb code:
- it assumes it's OK to DMA onto the stack. kmalloc would likely
be the best fix.
- it uses a one second timeout, while the longer USB_CTRL_GET_TIMEOUT
(or even "5" seconds as the usb spec allows ) should likely be used.
- it's called after usblp_write() did an illegal (racey) thing, looking
at urb->status outside the completion function. (does anyone know
why usblp_write() isn't just issuing a single write for that buffer?)
Except for maybe that last one they're unlikely to be very triggering
your symptoms (but of course hangs shouldn't happen).
I'd more suspect a bug in usb_start_wait_urb (in part since every time
I see it I suspect it's wrong; it doesn't _look_ as right as I'd like
and its "control/bulk msg timeout" diagnostic comes up a lot), or that
there's a completion path that doesn't handshake right with unlinking
(long a popular spot for races, ohci did change there in 2.5).
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
