Most recent kernel where this bug did not occur: None I know
Distribution: Debian unstable, but my own kernel compile off kernel.org
Hardware Environment: Toshiba R100, with docking station
Software Environment: Debian unstable
I connect the nokia E70 (a symbian S60 3rd edition device) to the USB, and
select "PC Suite". The kernel spews the following:
Sep 25 16:16:52 r100 kernel: usb 1-3.4: new full speed USB device using ehci_hcd
and address 9
Sep 25 16:16:52 r100 kernel: usb 1-3.4: configuration #1 chosen from 1 choice
Sep 25 16:16:53 r100 kernel: cdc_acm 1-3.4:1.12: ttyACM0: USB ACM device
Sep 25 16:16:53 r100 kernel: usbcore: registered new driver cdc_acm
Sep 25 16:16:53 r100 kernel: drivers/usb/class/cdc-acm.c: v0.25:USB Abstract
Control Model driver for USB modems and ISDN adapters
Sep 25 16:16:53 r100 kernel: usbcore: registered new driver cdc_ether
Sep 25 16:16:53 r100 kernel: usb%%d: unregister 'rndis_host'
usb-0000:00:1d.7-3.4, RNDIS device
Sep 25 16:16:53 r100 kernel: unregister_netdevice: device usb%%d/c343b000 never
Sep 25 16:16:53 r100 kernel: Modules linked in: rndis_host cdc_ether usbnet
cdc_acm rfcomm l2cap thermal fan button processor ac battery usblp mct_u232
usbserial ipv6 usbhid hci_usb bluetooth arc4 ieee80211_crypt_wep msdos fat
nls_iso8859_1 ntfs dm_snapshot dm_mirror dm_mod ide_cd cdrom 8250_pci joydev
snd_intel8x0 snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss
mousedev snd_pcm snd_timer tsdev snd ipw2100 ehci_hcd uhci_hcd intel_agp
soundcore yenta_socket rsrc_nonstatic pcmcia ieee80211 ieee80211_crypt shpchp
pci_hotplug usbcore agpgart psmouse pcmcia_core rtc snd_page_alloc
firmware_class pcspkr e100 mii serio_raw evdev ext3 jbd mbcache ide_disk
ide_generic via82cxxx trm290 triflex slc90e66 sis5513 siimage serverworks sc1200
rz1000 piix pdc202xx_old pdc202xx_new opti621 ns87415 it821x hpt366 hpt34x
generic cy82c693 cs5535 cs5530 cs5520 cmd64x atiixp amd74xx alim15x3 aec62xx
Sep 25 16:16:53 r100 kernel: EIP: 0060:[<b0154b0f>] Not tainted VLI
Sep 25 16:16:53 r100 kernel: EFLAGS: 00010046 (2.6.18 #2)
Sep 25 16:16:53 r100 kernel: [<d0bd3014>] usbnet_probe+0x4ee/0x503 [usbnet]
Sep 25 16:16:53 r100 kernel: [<b020ce28>] __driver_attach+0x0/0x5d
Sep 25 16:16:53 r100 kernel: [<d0941ba1>] usb_probe_interface+0x58/0x87 [usbcore]
Sep 25 16:16:53 r100 kernel: [<b020cd89>] driver_probe_device+0x42/0x8b
Sep 25 16:16:53 r100 kernel: [<b020ce60>] __driver_attach+0x38/0x5d
Sep 25 16:16:53 r100 kernel: [<b020c8aa>] bus_for_each_dev+0x33/0x55
Sep 25 16:16:53 r100 kernel: [<b020ccf3>] driver_attach+0x11/0x13
Sep 25 16:16:53 r100 kernel: [<b020ce28>] __driver_attach+0x0/0x5d
Sep 25 16:16:53 r100 kernel: [<b020c5c3>] bus_add_driver+0x64/0xfd
Sep 25 16:16:53 r100 kernel: [<d09419d6>] usb_register_driver+0x60/0xbb [usbcore]
Sep 25 16:16:53 r100 kernel: [<b01354ce>] sys_init_module+0x1692/0x1815
Sep 25 16:16:53 r100 kernel: [<b0102c73>] syscall_call+0x7/0xb
Sep 25 16:16:53 r100 udevd-event: run_program: '/sbin/modprobe' abnormal exit
USB system bocomes unstable. on 2.6.17 (debian version -2) the kernel would
crash pretty fast after this. In this version it seems I can still use firefox
to send this bug.
Steps to reproduce:
I seem to have a similar problem when unplugging a Nokia 6234 from my Thinkpad
T42 (kernel 2.6.18 Debian stock), see also:
rndis_host 2-1:1.9: RNDIS init failed, -110
usb%d: unregister 'rndis_host' usb-0000:00:1d.1-1, RNDIS device
unregister_netdevice: device usb%d/f6fa8800 never was registered
------------[ cut here ]------------
kernel BUG at mm/slab.c:595!
invalid opcode: 0000 [#1]
Modules linked in: rndis_host cdc_ether usbnet nls_cp437 vfat fat isofs nls_utf8
udf sd_mod usb_storage scsi_mod radeon drm binfmt_misc ipv6 video sbs ibm_acpi
i2c_ec dock button battery container ac asus_acpi pcmcia firmware_class wlan_wep
fuse nvram hdaps speedstep_centrino freq_table cpufreq_ondemand ide_generic wla
n_scan_sta ath_pci ath_rate_sample wlan ath_hal yenta_socket rsrc_nonstatic pcmc
ia_core intel_rng irtty_sir sir_dev joydev nsc_ircc irda psmouse serio_raw crc_c
citt snd_intel8x0m snd_pcm_oss snd_mixer_oss shpchp pci_hotplug snd_intel8x0 snd
_ac97_codec snd_ac97_bus parport_pc parport intel_agp agpgart i2c_i801 tsdev i2c
_core pcspkr evdev floppy rtc snd_pcm snd_timer snd soundcore snd_page_alloc ext
3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_cd cdrom ide_disk usbhid piix e10
00 generic ide_core ehci_hcd uhci_hcd usbcore thermal processor fan
EIP: 0060:[<c015521b>] Tainted: P VLI
EFLAGS: 00010046 (2.6.18-1-686 #1)
EIP is at kfree+0x2e/0x65
eax: 80000000 ebx: f6fa8ac0 ecx: dffff7c0 edx: c16df440
esi: 00000282 edi: f6fa2392 ebp: f6fa8800 esp: f6fd1e18
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 4089, ti=f6fd0000 task=f6f58030 task.ti=f6fd0000)
Stack: f6fa8ac0 f8e1960e f6fa8806 f8e1901a f6f3b400 f8e5d6a0 f6efd2c8 f6f56c00
ffffff92 c18d6000 00000000 00000000 00000001 00000001 00000001 00000001
f8e5d660 f6f3b400 f8e5e520 f8e5e550 c020eae8 f886bba9 f6f3b414 f6f3b414
[<f8e1901a>] usbnet_probe+0x4ee/0x503 [usbnet]
[<f886bba9>] usb_probe_interface+0x58/0x87 [usbcore]
[<f886b9de>] usb_register_driver+0x60/0xbb [usbcore]
Code: 56 89 c7 53 74 58 9c 5e fa 8d 90 00 00 00 40 c1 ea 0c c1 e2 05 03 15 70 b3
36 c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 84 c0 78 08 <0f> 0b 53 02 e5 8d 29 c0
89 e0 8b 4a 18 25 00 e0 ff ff 8b 40 10
EIP: [<c015521b>] kfree+0x2e/0x65 SS:ESP 0068:f6fd1e18
<6>agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
I can provide any info needed.
BTW, disabling cdc_ether, cdc-acm seems to solve the issue, see:
Answering #2 above,
It works in USB-storage mode, OK. The problem, as stated, is when I select "PC
We are not trying to get rid of the bug, we are trying to get at some
functionality that is supposed to wrok.
I can confirm this bug exists also with Nokia E61.
I have a similar problem with Nokia 6280 and the supplied data cable, using
cdc-acm with ppp.
The interesting thing though is that it works fine on another PC. This other PC
is an older laptop witrh USB 1 (not 2), and also running an older kernel:
$ uname -a
Linux piglet 2.6.16-gentoo-r7 #17 PREEMPT Fri Aug 25 16:13:13 WAT 2006 i686
Mobile Intel(R) Celeron(TM) CPU 1333MHz GNU/Linux
On my new PC it works fine most of the time, but when its downloading a large
file and getting good bandwidth, it locks up the kernel, and I have to push the
The "new PC" is:
Linux trotter 2.6.17-gentoo-r8 #13 SMP Thu Oct 26 13:38:19 SAST 2006 i686
Intel(R) Pentium(R) D CPU 3.40GHz GNU/Linux
I suspect it has something to do with USB 2.0 and also with faster processors.
This PC is a dual core Pentium. Motherboard is MSI, chipset is Intel.
Feel free to email me, and please tell me about workarounds
Confirming with Nokia N91, in both 2.6.18 and 126.96.36.199. The errors always
appear on all xterms and consoles, but despite this, sometimes the ttyACM0
device gets created and then it's functional. Only once, I got a hard crash.
The problem doesn't seem to exist with 188.8.131.52 on the same machine (using it
(distro is Debian/unstable, but all kernels I checked are built by me from
official kernel.org sources).
I can confirm the bug on 2.6.18-1 (FC), 184.108.40.206 (vanilla), and unfortunately
also 220.127.116.11 (vanilla). On 18.104.22.168 and 22.214.171.124 it doesn't occur
immediately upon connecting the Nokia phone in its "modem" mode, but only after
the phone is disconnected from USB.
Last perfectly working version of cdc_acm on exactly the same hw, I've seen, was
on an aging 2.4.27 vanilla kernel. It's really a pain debugging and/or testing
this bug, since it almost always provides a hard freeze of the machine. I will
try older 2.6 builds further on, once time permits.
Hi, I can confirm that bug with Nokia E60 and Kernel 126.96.36.199
I'd like to confirm this bug with Debian Etch ("testing") and Debian kernel
2.6.17 and Nokia 6280.
I connect the Nokia as a storage device and manage to manipulate the files in
memory and the internal MiniSD card. Then I can also "stop" the device and even
tell the Nokia to get out of "storage mode". The problems occur when I
disconnect the phone from the USB cable - then I get OOPS's and many times a
complete freeze. I'll try to get a sample output of the OOPS here.
I can now confirm exactly same behavior (cdc-acm module freezes the whole
Only partial luck w 2.6.11. Device using cdc-acm module can be connected and
disconnected w/out kernel freezing the whole machine, however "Oopses" still DO
OCCUR upon disconnect.
Last fully working kernel, I've seen w cdc-acm module, was:
Please let me know, if I could help with w more testing. Pity that the bug is
still unassigned. Perhaps the original maintainer of cdc-acm could help us here?
I can confirm this is happening on ubuntu edgy, 2.6.17-10 and 2.6.17-13. The
hardware is a Nokia 9300 phone.
My laptop basically freezes up at this point.. note i have some extra logging I
put into the module..
Dec 12 02:31:09 localhost kernel: [17179649.972000] usb 1-1: new full speed USB
device using uhci_hcd and address 2
Dec 12 02:31:09 localhost kernel: [17179650.132000] usb 1-1: Product: Nokia 9300
Dec 12 02:31:09 localhost kernel: [17179650.132000] usb 1-1: Manufacturer: Nokia
Dec 12 02:31:09 localhost kernel: [17179650.132000] usb 1-1: choose_config: 0,
class: 2, iface: 2, proto: 255, maxPower: 50, bus_ma: 500
Dec 12 02:31:09 localhost kernel: [17179650.132000] usb 1-1: ndis device found!
: 0, class: 2
Dec 12 02:31:09 localhost kernel: [17179650.132000] usb 1-1: configuration #1
chosen from 1 choice
Dec 12 02:31:10 localhost kernel: [17179650.304000] usbcore: registered new
Dec 12 02:31:12 localhost kernel: [17179653.260000] usb 1-1: USB disconnect,
Dec 12 02:31:13 localhost kernel: [17179653.308000] usb%%d: unregister
'rndis_host' usb-0000:00:1d.0-1, RNDIS device
Dec 12 02:31:13 localhost kernel: [17179653.308000] rndis_host: probe of 1-1:1.0
failed with error -110
1234 #ifndef CONFIG_USB_NET_RNDIS
1237 best = c;
I dont see any defines of that sort in ubuntu, I had to make that a #if 1 to
force usb to setup my nokia phone's rndis configuration (and subsequently hang).
Did anyone else have to do this?
FWIW, it seems my comment #12 has been fixed in 188.8.131.52. Anyone have luck
reproducing this bug with this kernel?
I have the same issue with my Nokia 6280 cellphone. My machine is an Intel
Centrino Laptop running Ubuntu 6.10
Created attachment 10017 [details]
184.108.40.206 kernel bugtrace
Does not hang the machine as with older kernels, just renders the USB detection
system non-working for any newly connected device.
Kernel 220.127.116.11 did indeed fix something. Nokia 6280 now works with the cdc-acm
module and the crashes are _almost_ gone. The toll is a non-working USB
Upon connecting the phone once, it causes serveral things:
*kernel bug is encountered, see trace in
*USB auto-detection stops working for any newly connected device
*only devices with modules already in the kernel do work ok
*Nokia phone must not be disconnected, otherwise the functionality is lost and a
machine reboot needed for the kernel to have functional /dev/ttyACM0 device again
*occasional system hangs still occur, however now after days of ppp connection
running through the phone, rather than hours or minutes as before
*the phone must not be connected upon machine boot, otherwise the system hangs
immediately after startup of udev subsystem
As for #13 from Ram. I can neither confirm, nor deny your observation, since I'm
not familiar with the RNDIS interaction and the cdc-acm module. However no
change in the source code of vanilla 18.104.22.168 was needed, only a plain recompile
using the old config brought me this slight improvement.
Sorry to spoil the optimistic mood, but my computer seizes up with 2.6.20-rc4,
just as described in the original bug.
I guess this is related:
Created attachment 10093 [details]
bug fix for rdnis_host module
I prepared a bug fix for driver rndis_host which fixes rndis_host probing certain
Nokia S60 (Series 60) mobiles. While the rndis_host get probed by usbnet
and tries to bind the Nokia mobile the bind is going to fail. The
rndis_host module tries to release the device, in a wrong way, which
cause the oops.
Feel free to give it a try.
This patch fixes the problem for me.
Looks like the patch is in mainline already, right Daniel?
I guess this bug can be closed then.
Yes - the patch is already in mainline.
Since 2.6.20 iirc...