usb-uhci *BUG*

Hi

I'm not familiar with the USB code, but I've been hitting a BUG() with my
new OHCI card (sorry, it was cheap :( )

the BUG() is at line 464 in usb-ohci.h, which seems to be a linked-list traversal failing to find an entry.

the backtrace /does/ seem to be the same every time. I dont have ksymoops (on ARM I decode oopses with grep and system.map :). This appears not to work so well for X86, but here goes...

c583708b  - n/a
c01098fc  - follows handle_IRQ_event
c0109a62  - preceeds request_irq
c0106c10  - default_idle
c0106c10  - default_idle
c0106c33  - follows default_idle
c0106c97  - follows cpu_idle
c0105000  - _stext
c0105027  - follows rest_init

Ian Molton Awoke this dragon, who will now respond:

Oops. sorry, forgot - kernel 2.4.19-pre6 (same problem on 2.4.12-ac_something though)

Any particular reason for not using ksymoops? If it does not work on arm, I can get rid of all the arm code ;).

It does work on ARM. I use it, and we've had a few posts using it. However, since it took several _months_ for the ksymoops version with the fixed regexps for ARM to come out, I don't really think you're justified in the above comments.

However, it's just that most people don't bother to think about reading any documentation (like REPORTING-BUGS) and think that just posting random bits is sufficient. It's difficult enough to get these people to post basic things like kernel versions and so forth.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

You missed the smiley.

I must admit that ksymoops tends to be the poor relation, it is my lowest priority out of ia64, kdb, kbuild, modutils and ksymoops. Now if I could just get kbuild 2.5 and kdb into the kernel, I would have more time for the other projects :-)>

So your "Subject:" is wrong? Which driver are you having problems with? usb-ohci.c or usb-uhci.c?

What platform are you running this on, x86?
What devices do you have plugged in?
What were you doing when the BUG() call happened?
Are there any kernel log entries before the BUG()?
What is your .config?
What is the output of /proc/bus/usb/devices with your USB device plugged in?

thanks,

greg k-h

Greg KH Awoke this dragon, who will now respond:

yes. sh*t. sorry :-/

its usb-ohci.

yes

one alcatel usb speedtouch ADSL modem, using the 'user mode' driver.

surfin' the net ;) it appears to occur randomly - its been fine the whole day today, although less stressed than yesterday.

nope.

I can mail it if necessary.

bash-2.05$ cat /proc/bus/usb/devices

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=c583b000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=06b9 ProdID=4061 Rev= 0.00
S:  Manufacturer=ALCATEL
S:  Product=Speed Touch USB 
S:  SerialNumber=0090D047C395
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=50ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
I:  If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E:  Ad=06(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E:  Ad=06(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=05(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=c5839000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

Ah, please try using the patch below from David Brownell to fix this problem. I've already applied this to my trees, and will get pushed to the main kernels soon.

Let me know if this helps or not.

thanks,

greg k-h

@@ -286,7 +286,9 @@
 }
 
 /*
- * interface claiming
+ * interface claims are made only at the request of user level code,
+ * which can also release them (explicitly or by closing files).
+ * they're also undone when devices disconnect.
  */
 
 static void *driver_probe(struct usb_device *dev, unsigned int intf,

@@ -299,7 +301,20 @@
 {
 	struct dev_state *ps = (struct dev_state *)context;
 
+	if (!ps)
+		return;
+
+	/* this waits till synchronous requests complete */
+	down_write (&ps->devsem);
+
+	/* prevent new I/O requests */
+	ps->dev = 0;
 	ps->ifclaimed = 0;
+
+	/* force async requests to complete */
+	destroy_all_async (ps);
+
+	up_write (&ps->devsem);
 }
 
 struct usb_driver usbdevfs_driver = {

Greg KH Awoke this dragon, who will now respond:

apparently not. first time it booted, it oopsed (not recorded, sorry). second time, it hit the BUG() again. same backtrace.

I built USB all as modules, in case thats relevant.

Is this before you even run the usermode driver?

A real ksymoops output would be appreciated.

thanks,

greg k-h

The oops doesn't come when the driver is exiting in this case (as the patch was for), it "occurs randomly". The problem might be with the usb hardware.

What is the motherboard, is it an usb add-on card ?

Pierre
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------

Pierre Rousselet Awoke this dragon, who will now respond:

Its a VIA based board, and it /is/ an add-on card. its a 4 port OPTi based card.

Mobo stuff:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 4).
Master Capable. Latency=16.
Prefetchable 32 bit memory at 0xe0000000 [0xe07fffff].
Bus 0, device 1, function 0:

    PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x

AGP] (rev 0). Master Capable. No bursts. Min Gnt=4.

USB controller:
Bus 0, device 10, function 0:

    USB Controller: OPTi Inc. 82C861 (rev 32).
      IRQ 10.
      Master Capable.  Latency=16.  Max Lat=80.
      Non-prefetchable 32 bit memory at 0xe0800000 [0xe0800fff].
  Bus  0, device  10, function  1:
    USB Controller: OPTi Inc. 82C861 (#2) (rev 32).
      IRQ 12.
      Master Capable.  Latency=16.  Max Lat=80.
      Non-prefetchable 32 bit memory at 0xe0801000 [0xe0801fff].

From FAQ on Alcatel site:

Q11: My modem often powers down without any reason and I have to reboot to connect again.

A11: This is a known problem with motherboards using the VIA chipset. Always install the latest Via4in1 drivers and USB filter from the Via website. If you have a Motherboard of the KT7 type, one workaround is to change the BIOS settings: set the 'enhanced chipset performance' setting on 'enable'. This should help in most cases. For more information about the KT7 / VIA chipset issues with USB, you may read the the ViaHardware
FAQ pages or the USBman page.

Pierre
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------

Pierre Rousselet Awoke this dragon, who will now respond:

the modem doesnt power down. all I get is an oops.

the machine is a k6-ii and is otherwise reliable (even with 100mbit ethernet).

I've been poking about and have replaced the BUG() with a printk("about to die!\n"), and return NULL.

I then hardened dl_reverse_done_list so it wouldnt die on receiving a NULL.

this seems to have improved things a LITTLE. I see a few 'about to die's whizz by, and it stiffs shortly after.

does that help anyone?