On 23/12/11 00:47, Jonathan Nieder wrote: > Steven Chamberlain wrote: >> After several hours or days of running aircrack-ng (in this instance >> only 90 minutes) on a USB rtl8187 wlan interface, a strange kind of >> kernel lockup happens... > > Is this still reproducible?
Hi Jonathan, I was trying to reproduce this for the past couple of days, using the same USB rtl8187 wlan device on a similar machine I had spare (but with 2.6.32-5-686 version 2.6.32-38), and it hasn't recurred yet. Also I'm now thinking it was a more generic USB/OHCI issue on the original machine, because: 1. with rtl8187 device only -- these crashes were the most serious as they sometimes crashed the whole system: > [ 9001.662862] [<ffffffff812e7ccc>] ? schedule_timeout+0xad/0xdd > [ 9001.669046] [<ffffffffa0176eb9>] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] > [ 9001.676253] [<ffffffffa00a10d8>] ? usb_kill_urb+0x9d/0xbb [usbcore] > [ 9001.683018] [<ffffffff81065422>] ? autoremove_wake_function+0x0/0x2e > [ 9001.689847] [<ffffffffa00a2406>] ? usb_start_wait_urb+0x7e/0xb7 > [usbcore] > [ 9001.697128] [<ffffffffa00a267c>] ? usb_control_msg+0x112/0x135 [usbcore] > [ 9001.704315] [<ffffffff810468b3>] ? finish_task_switch+0x3a/0xaf > [ 9001.710714] [<ffffffffa03f3d2e>] ? rtl818x_ioread8+0x61/0x7e [rtl8187] > [ 9001.717737] [<ffffffffa03f3d6f>] ? > rtl8187_is_radio_enabled+0x24/0xc0 [rtl8187] > [ 9001.725642] [<ffffffffa03f3e30>] ? rtl8187_rfkill_poll+0x25/0x78 > [rtl8187] > [ 9001.733036] [<ffffffffa0217e5d>] ? rfkill_poll+0x1b/0x31 [rfkill] > [ 9001.739616] [<ffffffff81061952>] ? worker_thread+0x188/0x21d > [ 9001.745732] [<ffffffffa0217e42>] ? rfkill_poll+0x0/0x31 [rfkill] > [ 9001.752209] [<ffffffff81065422>] ? autoremove_wake_function+0x0/0x2e > [ 9001.759049] [<ffffffff810617ca>] ? worker_thread+0x0/0x21d > [ 9001.764955] [<ffffffff81065156>] ? kthread+0xc0/0xca > [ 9001.770341] [<ffffffff81011c6a>] ? child_rip+0xa/0x20 > [ 9001.775816] [<ffffffff81065096>] ? kthread+0x0/0xca > [ 9001.781131] [<ffffffff81011c60>] ? child_rip+0x0/0x20 2. two different series of APC UPS attached via USB cable (hiddev driver), without rtl8187 attached, would sometimes lose communications with: > [20761.764191] Call Trace: > [20761.766909] [<ffffffffa0159eb9>] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] > [20761.774308] [<ffffffffa004b10c>] ? usb_kill_urb+0x9d/0xbb [usbcore] > [20761.781219] [<ffffffff810667da>] ? autoremove_wake_function+0x0/0x2e > [20761.788210] [<ffffffffa021efeb>] ? usbhid_init_reports+0x8c/0xee > [usbhid] > [20761.795684] [<ffffffffa0220396>] ? hiddev_ioctl+0x2bf/0x632 [usbhid] > [20761.802705] [<ffffffff810cfd01>] ? handle_mm_fault+0x48f/0x9bb > [20761.809178] [<ffffffff81073a6b>] ? do_uncharge_dcache+0x3d/0x51 > [20761.815689] [<ffffffff810fcc36>] ? vfs_ioctl+0x21/0x6c > [20761.821375] [<ffffffff810fd184>] ? do_vfs_ioctl+0x48d/0x4cb > [20761.827486] [<ffffffff812ecc05>] ? do_page_fault+0x2e0/0x2fc > [20761.833743] [<ffffffff810fd1ff>] ? sys_ioctl+0x3d/0x5c > [20761.839424] [<ffffffff81010c12>] ? system_call_fastpath+0x16/0x1b 3. just today (now using 2.6.32-5-openvz-amd64 version 2.6.32-40), I connected one of those UPSes via serial cable instead, using a pl2303 usbserial device, and again it lost communications with a similar-looking issue that has caused only apcupsd to hang: > [91922.798791] Call Trace: > [91922.801429] [<ffffffff812ea4d4>] ? schedule_timeout+0xad/0xdd > [91922.807651] [<ffffffffa0189ee9>] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] > [91922.814882] [<ffffffffa004a25c>] ? usb_kill_urb+0x9d/0xbb [usbcore] > [91922.821581] [<ffffffff810668b6>] ? autoremove_wake_function+0x0/0x2e > [91922.828397] [<ffffffffa004b594>] ? usb_start_wait_urb+0x7e/0xb7 [usbcore] > [91922.835696] [<ffffffffa004b80b>] ? usb_control_msg+0x112/0x135 [usbcore] > [91922.842885] [<ffffffffa03f41b7>] ? pl2303_set_termios+0xaa/0x620 [pl2303] > [91922.850155] [<ffffffffa03f423d>] ? pl2303_set_termios+0x130/0x620 [pl2303] > [91922.857474] [<ffffffff811ea5e1>] ? set_termios+0x365/0x3fb > [91922.863422] [<ffffffff811ea8df>] ? tty_mode_ioctl+0x19c/0x46d > [91922.869630] [<ffffffff811ead87>] ? tty_ldisc_try+0x40/0x47 > [91922.875579] [<ffffffff811ead87>] ? tty_ldisc_try+0x40/0x47 > [91922.881481] [<ffffffff811eb61a>] ? tty_ldisc_ref_wait+0x10/0x90 > [91922.887861] [<ffffffff811e685a>] ? tty_ioctl+0x975/0x9ad > [91922.893604] [<ffffffff8122e41a>] ? sys_sendto+0x109/0x138 > [91922.899369] [<ffffffff810668b6>] ? autoremove_wake_function+0x0/0x2e > [91922.906159] [<ffffffff810fd182>] ? vfs_ioctl+0x21/0x6c > [91922.911698] [<ffffffff810fd6d0>] ? do_vfs_ioctl+0x48d/0x4cb > [91922.917720] [<ffffffff810f1b90>] ? vfs_write+0xcd/0x102 > [91922.923316] [<ffffffff810fd74b>] ? sys_ioctl+0x3d/0x5c > [91922.928873] [<ffffffff81010c12>] ? system_call_fastpath+0x16/0x1b The machine having all the problems is essentially a 'production' box and also requires openvz, so it's not practical for me to try linux 3.x on there yet. I must really find a way to reproduce this issue on the 'spare' box. They are both Sun Fire v20z, albeit different hardware revisions but the USB host controller is the same. I'll test the rtl8187 for a few more hours with the existing 686 kernel, before trying on 2.6.32-5-openvz-amd64 version 2.6.32-40 to be consistent with the other box. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
