When disconnecting my Huawei E169 connected via "umtsmon", which hangs from time to time, I get the stack-trace attached at the end. Sometimes my laptop survives this, sometimes it crashes with a blinking caps-lock key led. Kernel-Version: Linux localhost.localdomain 2.6.30-0.97.rc8.fc12.i586 #1 SMP Wed Jun 3 09:55:34 EDT 2009 i686 i686 i386 GNU/Linux BUG: unable to handle kernel paging request at 6b6b6b93 IP: [<c06c8d3f>] usb_kill_urb+0x32/0xc5 *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/rfkill/rfkill1/state Modules linked in: fuse ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc rfcomm bridge stp llc bnep sco l2cap sunrpc ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput snd_hda_codec_si3054 snd_hda_codec_realtek option usbserial btusb bluetooth arc4 ecb firewire_ohci iwl3945 firewire_core iwlcore ppdev mac80211 lib80211 crc_itu_t cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc parport_pc toshiba_acpi rfkill usb_storage yenta_socket rsrc_nonstatic parport iTCO_wdt sdhci_pci sdhci mmc_core e1000e iTCO_vendor_support pcspkr joydev input_polldev ata_generic pata_acpi i915 drm i2c_algo_bit video output i2c_core [last unloaded: microcode] Pid: 2179, comm: pppd Not tainted (2.6.30-0.97.rc8.fc12.i586 #1) Tecra A8 EIP: 0060:[<c06c8d3f>] EFLAGS: 00010202 CPU: 0 EIP is at usb_kill_urb+0x32/0xc5 EAX: 00000000 EBX: 6b6b6b6b ECX: c093208b EDX: 00000000 ESI: 00000001 EDI: f5e47aa0 EBP: f14f7ddc ESP: f14f7dbc DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process pppd (pid: 2179, ti=f14f6000 task=f305c020 task.ti=f14f6000) Stack: 00000202 8597fcbd f56b66e0 00000000 f5e47aa0 8597fcbd f56b66e0 f5e47aa0 f14f7dfc f898d97e f1e86240 f56817b8 8597fcbd f5e47aa0 f8990e20 f5681780 f14f7e28 f895ecfc 8597fcbd f14a3800 f8991fd4 f1e86240 f5e47bb4 8597fcbd Call Trace: [<f898d97e>] ? option_close+0x89/0xc3 [option] [<f895ecfc>] ? serial_close+0x98/0x14d [usbserial] [<c0649c01>] ? tty_release_dev+0x16a/0x3fa [<c04d6988>] ? __slab_free+0x223/0x258 [<c0463f1b>] ? trace_hardirqs_on_caller+0x26/0x155 [<c04ef079>] ? __d_free+0x4b/0x60 [<c04ef079>] ? __d_free+0x4b/0x60 [<c0649eb6>] ? tty_release+0x25/0x41 [<c04e0b23>] ? __fput+0xe5/0x183 [<c04e0be8>] ? fput+0x27/0x3a [<c04dd424>] ? filp_close+0x64/0x7f [<c043e819>] ? put_files_struct+0x68/0xbd [<c043e8b1>] ? exit_files+0x43/0x59 [<c0440202>] ? do_exit+0x1d6/0x641 [<c0487b62>] ? audit_syscall_entry+0x135/0x168 [<c04406df>] ? do_group_exit+0x72/0x99 [<c044072d>] ? sys_exit_group+0x27/0x3c [<c040417c>] ? syscall_call+0x7/0xb Code: 18 0f 1f 44 00 00 ba 32 02 00 00 89 c3 65 a1 14 00 00 00 89 45 f4 31 c0 b8 8b 20 93 c0 e8 a8 c3 d6 ff e8 c2 a2 11 00 85 db 74 7b <83> 7b 28 00 74 75 83 7b 2c 00 74 6f f0 ff 43 0c ba fe ff ff ff EIP: [<c06c8d3f>] usb_kill_urb+0x32/0xc5 SS:ESP 0068:f14f7dbc CR2: 000000006b6b6b93 ---[ end trace 9a57afe6f9d10176 ]--- Fixing recursive fault but reboot is needed!
Just a me-too, with Huawei E160. $ uname -a Linux river 2.6.29-ARCH #1 SMP PREEMPT Wed May 20 06:42:43 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz GenuineIntel GNU/Linux BUG: unable to handle kernel paging request at 000000000357d181 IP: [<ffffffffa015baa4>] usb_kill_urb+0x14/0xc0 [usbcore] PGD 7dc80067 PUD 7ddc7067 PMD 0 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2/uevent CPU 0 Modules linked in: vboxnetflt vboxdrv ati_remote2 ext2 cbc loop i915 drm i2c_algo_bit ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async ipv6 ppp_generic slhc usbhid hid aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod snd_hda_codec_realtek option snd_hda_intel irtty_sir snd_seq_oss usbserial snd_hda_codec snd_seq_midi_event snd_seq snd_seq_device usb_storage sir_dev snd_pcm_oss snd_mixer_oss snd_hwdep snd_pcm irda i2c_i801 iTCO_wdt iTCO_vendor_support ppdev snd_timer uhci_hcd ehci_hcd crc_ccitt i2c_core pcspkr sg parport_pc snd usbcore r8169 mii intel_agp lp parport soundcore snd_page_alloc thermal processor evdev fan button battery ac rtc_cmos rtc_core rtc_lib ext3 jbd mbcache sd_mod ata_generic ata_piix pata_acpi libata scsi_mod [last unloaded: kvm] Pid: 2848, comm: pppd Not tainted 2.6.29-ARCH #1 To Be Filled By O.E.M. RIP: 0010:[<ffffffffa015baa4>] [<ffffffffa015baa4>] usb_kill_urb+0x14/0xc0 [usbcore] RSP: 0018:ffff88007a249d58 EFLAGS: 00010206 RAX: 0000000100000000 RBX: 000000000357d139 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000357d139 RBP: 0000000000000008 R08: ffff88007de11120 R09: 0000000000000000 R10: 2222222222222222 R11: 2222222222222222 R12: ffff88007a001800 R13: ffff88007aec2c00 R14: ffff88007dd38a28 R15: ffffffffa02a7ca0 FS: 00007fcfe87466f0(0000) GS:ffffffff8067a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000357d181 CR3: 000000007a025000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process pppd (pid: 2848, threadinfo ffff88007a248000, task ffff88007a1f4800) Stack: 2222222222222222 ffff88007aebb8b0 ffff88007dd38a28 0000000000000246 ffff88007dd389c0 ffff88007aebb800 ffff88007aebb800 0000000000000008 ffff88007a001800 ffffffffa02a2841 ffff88007aebb800 ffff88007a001800 Call Trace: [<ffffffffa02a2841>] ? option_close+0x81/0x100 [option] [<ffffffffa02744bf>] ? serial_close+0x1df/0x210 [usbserial] [<ffffffff803c4962>] ? tty_release_dev+0x162/0x5a0 [<ffffffff802d9b7d>] ? vfs_ioctl+0x1d/0xb0 [<ffffffff803c4db1>] ? tty_release+0x11/0x20 [<ffffffff802cbdd2>] ? __fput+0xc2/0x210 [<ffffffff802c869b>] ? filp_close+0x5b/0x90 [<ffffffff802c8784>] ? sys_close+0xb4/0x120 [<ffffffff8020c6aa>] ? system_call_fastpath+0x16/0x1b Code: a0 e8 51 d8 0f e0 48 83 c4 38 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 89 fb 48 83 ec 30 48 85 ff 0f 84 97 00 00 00 <48> 83 7f 48 00 0f 84 8c 00 00 00 48 83 7f 50 00 0f 84 81 00 00 RIP [<ffffffffa015baa4>] usb_kill_urb+0x14/0xc0 [usbcore] RSP <ffff88007a249d58> CR2: 000000000357d181 ---[ end trace 12a69bdddb01d275 ]---
Seems like this patch (merged after .30 release) fixes it: USB: usb-serial: replace shutdown with disconnect, release Alan Stern [Tue, 2 Jun 2009 15:53:55 +0000 (11:53 -0400)] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9c99bb8b3a1ec81af68d484a551307326c2e933 So far no oopses here. Clemens, can you confirm this, please?
I can't try, because as soon as I try to connect I get a hard lockup: http://bugzilla.kernel.org/show_bug.cgi?id=13601
On Fri, 12 Jun 2009 21:51:31 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13524 Alan has a patch, which worked for Domen: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9c99bb8b3a1ec81af68d484a551307326c2e933 But that patch a) doesn't have cc:stable in its changelog, b) seems appropriate for -stable and c) is pretty damn big. What should we do?
On Mon, Jun 22, 2009 at 02:49:19PM -0700, Andrew Morton wrote: > On Fri, 12 Jun 2009 21:51:31 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=13524 > > Alan has a patch, which worked for Domen: > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9c99bb8b3a1ec81af68d484a551307326c2e933 > > But that patch a) doesn't have cc:stable in its changelog, b) seems > appropriate for -stable and c) is pretty damn big. > > What should we do? It was going to be submitted to -stable after it was determined to fix the problem, right Alan? thanks, greg k-h
Yep. See also bug #13472. Do you think it has gotten enough testing yet? There hasn't been much feedback. Maybe that's a good sign.
FWIW, since I'm using the mentioned patch ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9c99bb8b3a1ec81af68d484a551307326c2e933 ), there have been no more oopses; tried plugging it out/in, suspend to ram etc. Is there a way to get these folks to test it? http://www.kerneloops.org/guilty.php?guilty=option_close&version=2.6.30-release&start=1998848&end=2031615&class=oops
I have similar issues, this time with 2.6.31-rc4 (as provided by openSuSE) and model E220. I booted three times to start umtsmon (version 0.9.50-20081117) as root, and it never worked; it always hangs after displaying installing GUI SIGABRT handler The first time pressing ^C to abort umtsmon works, the second time starting umtsmon and quitting with ^C made the kernel always crash with blinking LEDs, and I never got any message in /var/log/messages. I had to revert to an older kernel (2.6.27 in my case since this is what I have on my openSuSE 11.1 DVD). Has the abovementioned patch been integrated into 2.6.31?
Does everything now work okay with the latest 2.6.30.stable release?
Yes, für me 2.6.30 releases seem to be ok, however I've experienced other problems in 2.6.31.rc2/rc5 http://bugzilla.kernel.org/show_bug.cgi?id=13906
Then this bug report can be closed.