[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    Re: [linux-usb-devel] OHCI problems in latest 2.5 kernels
From:       Lars Doelle <lars.doelle () on-line ! de>
Date:       2002-10-15 12:40:00
[Download RAW message or body]

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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[prev in list] [next in list] [prev in thread] [next in thread]