On Sun, Aug 2, 2009 at 19:19, Oliver Neukum<oliver@xxxxxxxxxx> wrote: > Am Sonntag, 2. August 2009 18:40:56 schrieb Alex Riesen: >> [ 75.453444] Call Trace: >> [ 75.453444] [<ffffffff812a77b2>] usb_autopm_get_interface+0xe/0x10 >> [ 75.453444] [<ffffffffa0072e19>] acm_port_down+0x3f/0x1bb [cdc_acm] >> [ 75.453444] [<ffffffff811f0af1>] ? tty_port_close_start+0xc1/0x153 >> [ 75.453444] [<ffffffffa0073258>] acm_tty_close+0x3d/0x83 [cdc_acm] >> [ 75.453444] [<ffffffff811eaca7>] tty_release_dev+0x1bf/0x4e8 >> [ 75.453444] [<ffffffffa00732c3>] ? acm_tty_open+0x25/0x2ae [cdc_acm] > > This can happen only if acm_port_down() fails to detect that the device has > been disconnected, as it calls usb_autopm_get_interface() > only if acm->dev != NULL. > This however should not happen if acm_disconnect runs. > > Can you put a printk into acm_disconnect and recompile with CONFIG_USB_DEBUG? I put the printks at some random lines in acm_disconnect (as of v2.6.31-rc2) and turned CONFIG_USB_DEBUG on. It is definitely not the same kernel I tried before (and sadly, it does not go oops), but it still has tty_port_close_start: count = -1 Dmesg attached I'm retrying with recent kernels (hopefully I'll get enough data left on the screen), I shall try to find the -rc2 which oopses (I suspect it is the one just before -rc3).
Attachment:
usbdeb
Description: Binary data
