Hi,
I think there may be a usb locking problem recently introduced by this
patch:
http://lkml.org/lkml/2006/1/4/458
I got a report from a user with an wireless USB keyboard with 3
interfaces:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04f2 ProdID=0200 Rev= 0.03
S: Manufacturer=Chicony
S: Product=USB Wireless HID Receiver
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
On boot, with this keyboard plugged the system hangs. A trace shows
modprobes and a grep hanging in "D state" in usbcore:
modprobe D C02E8A05 0 540 537 (NOTLB)
c1581d74 53051340 000f41fe c02e8a05 c1581d84 53051340 000f41fe 00000000
c1580000 c1580000 c156268c c1562560 53051340 000f41fe c1580000 02cd29c0
00000000 c1580000 df7cad1c 00000286 df7cad24 c02ea205 c1562560 00000001
Call Trace:
[<c02e8a05>] schedule+0x285/0x530
[<c02ea205>] __down+0xd5/0x114
[<c0119e60>] default_wake_function+0x0/0x20
[<c0249100>] __driver_attach+0x0/0x70
[<c02e8737>] __down_failed+0x7/0xc
[<c02492ad>] .text.lock.dd+0x27/0xca
[<c0249100>] __driver_attach+0x0/0x70
[<c02482ab>] next_device+0xb/0x20
[<c024831d>] bus_for_each_dev+0x5d/0x80
[<c0248e65>] driver_attach+0x25/0x30
[<c0249100>] __driver_attach+0x0/0x70
[<c02486ec>] bus_add_driver+0x8c/0x180
[<c02495bb>] driver_register+0x4b/0x90
[<e0c60560>] usb_register_driver+0x60/0xf0 [usbcore]
[<c01aa61a>] sysfs_create_group+0x7a/0x130
[<e084b019>] usb_kbd_init+0x19/0x3b [usbkbd]
[<c0139019>] sys_init_module+0x189/0x1a30
[<e0c57680>] usb_buffer_alloc+0x0/0x50 [usbcore]
[<c0132700>] autoremove_wake_function+0x0/0x60
[<c011760a>] do_page_fault+0x13a/0x650
[<c0102fb7>] sysenter_past_esp+0x54/0x75
another modprobe just like this from usbmouse instead of usbkbd, and:
grep D C15DBF50 0 740 739 (NOTLB)
c15dbef8 0bbc1000 000f41ff c15dbf50 c15dbf70 00000002 00000000 ded80000
c15da000 c15da000 c15f168c c15f1560 0bbc1000 000f41ff c15da000 001e8480
00000000 c15da000 df7e0d1c 00000286 df7e0d24 c02ea205 c15f1560 00000001
Call Trace:
[<c02ea205>] __down+0xd5/0x114
[<c0119e60>] default_wake_function+0x0/0x20
[<c02e8737>] __down_failed+0x7/0xc
[<e0c68c6e>] .text.lock.devices+0x4d/0x6f [usbcore]
[<c01635fe>] vfs_read+0xde/0x1b0
[<c01642ab>] sys_read+0x4b/0x80
[<c0102fb7>] sysenter_past_esp+0x54/0x75
It does not seem to occur with HZ=100, but with HZ=1000 it occurs
9 out of 10 times.
The grep is because the initscripts are doing:
needusbstorage=`LC_ALL=C grep -e "^I.*Cls=08" /proc/bus/usb/devices
2>/dev/null`
Not grepping makes booting proceed normally.
Deleting the lines coming from above patch that aquire a lock on the parent of
the device
in linux/drivers/base/dd.c completely solves the problem.
Unfortunately, I do not really know how this can lead to cyclic locking. It may
have something todo with the fact that this keyboard has 3 interfaces. And we
somehow managed to aquire one lock causing devices.c to wait on us, but at the
same time we are trying to aquire a lock on something that devices.c already
has
locked.
I hope that someone can provide some insight here. Otherwise, how safe is it to
remove the patch mentioned above from 2.6.17 to get a bit more stable
distro-kernel?
danny
-------------------------------------------------------------------------
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
