On Tuesday 15 October 2002 08:31, David Brownell wrote: > Interesting ... towards the end your kernel messages had lots of messages > among which were periodic: > > Oct 15 03:42:32 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad > entry fcac7c1 Oct 15 03:42:35 hal9 kernel: drivers/usb/host/ohci-q.c: > 00:02.0 bad entry fcac7c1 Oct 15 03:42:41 hal9 kernel: > drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 03:42:44 hal9 > kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 Oct 15 > 03:43:02 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1 > Oct 15 03:43:05 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry > fcac7c1 Oct 15 03:43:08 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad > entry fcac7c1 Oct 15 03:43:11 hal9 kernel: drivers/usb/host/ohci-q.c: > 00:02.0 bad entry fcac7c1 > > Many/all related to failures when it was trying to get the device > descriptor (I guess) for device #7. What was that device, do you know?
I attached the device list in the refered mail (usbdev-3) from which the device is a hub. I can offer to try to reproduce the finding with one hub only. I have two on my system, and the high number would mean that it is the second, since i attached it later. It is a 7 port hub, one of those wonderful pieces of technical design art. In case you didn't already guessed why it is not an 8 port hub, here a hint: In the usb tree it magically shows up as two 4 port hubs, one hooked into one of the ports of the other. ;-) Think #7 should be the one in the construction that is located deeper in the tree, but i could draw it from the usbdev-3 listing... Yes. Dev#7 (hub) has #6 (hub) as parent. Beside that, i guess it is a standard piece of hardware. Though i'd rather blame the code than the coarse-motorical hub designer. During the tests, i didn't make any attempt to activate one of the devices attached to the hub pair, but of course enumberations, firmware download and reenumberation ran through it. > That's interesting because it's much the same as Martin reported, but > with two key differences. One, that your controller didn't give itself > the kiss of death. Two, that it was always the same pointer! Three > (sorry, I can't count on mondays) the pointer is reasonable. Four, > that they're likely all happening after some control request error. > > Something that might be useful here: at the very end of ohci-q.c there > is a line calling ed_deschedule(). Make it call start_urb_unlink() > instead, same signature, and see if anything changes. Okay - findings later. -lars ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
