Distribution: Gentoo Linux Hardware Environment: Pentium 4 M, 786mb ram, and Dual P4 Xeon 2.4ghz, 1.5gb ram Software Environment: pppd version 2.4.2 devfs Problem Description: The Audiovox 9900 cellphone from Verizon can be used to make a data call as a usb acm modem. If while pppd is in a call and the cellphone is disconnected the kernel oops' with the following dmsg output (in this case the phone has reset itself): usb 1-1.3: USB disconnect, address 13 Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c0243b5b *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: msdos fat ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async cr c_ccitt ppp_generic slhc ipt_MASQUERADE ipt_LOG ipt_state iptable_nat ip_conntrack iptab le_filter ip_tables nvidia vmnet vmmon snd_seq_midi snd_emu10k1_synth snd_emux_synth snd _seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page _alloc snd_util_mem snd_hwdep snd soundcore cdc_acm CPU: 0 EIP: 0060:[<c0243b5b>] Tainted: P VLI EFLAGS: 00010246 (2.6.11-mm1) EIP is at get_kobj_path_length+0x1a/0x31 eax: 00000000 ebx: 00000000 ecx: ffffffff edx: f64745b8 esi: 00000001 edi: 00000000 ebp: ffffffff esp: e7819d7c ds: 007b es: 007b ss: 0068 Process pppd (pid: 26671, threadinfo=e7818000 task=c295e530) Stack: f57ccc53 f6474594 f55c2218 f64745b8 c0243be0 f64745b8 00000286 00000000 00000000 f57ccc53 f6474594 f55c2218 000003ad c02c8167 f64745b8 000000d0 c047f928 00000246 f565fb20 ffffffff ffffffff fffffffd c047fc00 00000000 Call Trace: [<c0243be0>] kobject_get_path+0x1f/0x77 [<c02c8167>] class_hotplug+0xb3/0x235 [<c02447c3>] kobject_hotplug+0x1d8/0x2e4 [<c024403e>] kobject_release+0x0/0xa [<c0243f52>] kobject_del+0x18/0x2d [<c02c8680>] class_device_del+0xae/0xba [<f886e419>] acm_tty_close+0x0/0x102 [cdc_acm] [<c02c869c>] class_device_unregister+0x10/0x1d [<f886e4df>] acm_tty_close+0xc6/0x102 [cdc_acm] [<c02903ce>] release_dev+0x6ec/0x825 [<c0116e4a>] finish_task_switch+0x3a/0xb7 [<c03cd041>] schedule+0x389/0xba8 [<c012609f>] del_timer_sync+0x94/0xda [<c02965ea>] inotify_dentry_parent_queue_event+0x35/0xb5 [<c0126106>] del_singleshot_timer_sync+0x21/0x32 [<c03ce27e>] schedule_timeout+0x75/0xbb [<c0290a01>] tty_release+0x14/0x1f [<c0161d31>] __fput+0x16d/0x1a6 [<c0160259>] filp_close+0x52/0x96 [<c0160307>] sys_close+0x6a/0x91 [<c01030f5>] syscall_call+0x7/0xb Code: ff 85 c0 89 c3 74 e4 89 34 24 e8 be 57 f5 ff eb da 55 bd ff ff ff ff 57 56 be 01 0 0 00 00 53 31 db 8b 54 24 14 8b 3a 89 e9 89 d8 <f2> ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 ea 5b 89 f0 5e 5f <6>usb 1-1.3: new full speed USB device using uhci_hcd and address 14 cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device If pppd is stopped properly and then the phone is disconnected, there are no problems. I have recreated this problem on several different 2.6 kernels including kernels not tainted by binary only modules (nvidia and vmware). The vmware vm is not active at the time of this oops. Following is lsmod output after above oops: Module Size Used by msdos 8064 0 fat 35996 1 msdos ppp_deflate 5376 0 zlib_deflate 22296 1 ppp_deflate zlib_inflate 17664 1 ppp_deflate bsd_comp 5888 0 ppp_async 10112 1 crc_ccitt 2304 1 ppp_async ppp_generic 27412 3 ppp_deflate,bsd_comp,ppp_async slhc 6656 1 ppp_generic ipt_MASQUERADE 3200 1 ipt_LOG 6784 1 ipt_state 2048 1 iptable_nat 20028 2 ipt_MASQUERADE ip_conntrack 37832 3 ipt_MASQUERADE,ipt_state,iptable_nat iptable_filter 2688 1 ip_tables 21120 5 ipt_MASQUERADE,ipt_LOG,ipt_state,iptable_nat,iptable_filter nvidia 3916700 12 vmnet 28580 2 vmmon 169292 0 snd_seq_midi 7072 0 snd_emu10k1_synth 7296 0 snd_emux_synth 35200 1 snd_emu10k1_synth snd_seq_virmidi 6528 1 snd_emux_synth snd_seq_midi_emul 7296 1 snd_emux_synth snd_pcm_oss 48672 0 snd_mixer_oss 17536 1 snd_pcm_oss snd_seq_oss 32256 0 snd_seq_midi_event 6912 3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss snd_seq 50960 8 snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event snd_emu10k1 102788 3 snd_emu10k1_synth snd_rawmidi 20640 3 snd_seq_midi,snd_seq_virmidi,snd_emu10k1 snd_seq_device 7436 7 snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi snd_ac97_codec 73720 1 snd_emu10k1 snd_pcm 82436 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec snd_timer 21892 3 snd_seq,snd_emu10k1,snd_pcm snd_page_alloc 8068 2 snd_emu10k1,snd_pcm snd_util_mem 3968 2 snd_emux_synth,snd_emu10k1 snd_hwdep 7584 2 snd_emux_synth,snd_emu10k1 snd 46564 17 snd_emux_synth,snd_seq_virmidi,snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_hwdep soundcore 8160 1 snd cdc_acm 10400 2 Steps to reproduce: 1. connect audiovox 9900 cellphone 2. make a data call using pppd 3. cause a usb disconnect, either by the phone resetting, powering off or unplugging the usb cable
This problem is fixed by better reference counting. The tty device has its parent removed by the disconnect. When the terminal is then closed the kernel crashes. This is fixed by the attached patch set.
Created attachment 4809 [details] exports usb_get_intf and usb_put_intf
Created attachment 4810 [details] fix tty reference counting problem
I can confirm that these patches resolve the problem.
Corresponding bug for Red Hat kernels: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147176 Possible dup: bug 4418.
*** Bug 4418 has been marked as a duplicate of this bug. ***
I have tested these patches and can verify they resolve the problem, so marking this as verified.
Can we please confirm that this fix was merged and that 2.6.12-rc5 is behaving properly? Thanks.
These fixes are aparently not merged with 2.6.12-rc5 as the problem still persists. The two patches still fix the problem after being applied to 2.6.12-rc5
Ok, I've added these to my tree, will show up in the next -mm release and make it in after 2.6.12 is released.
*** Bug 4715 has been marked as a duplicate of this bug. ***
Hi Greg. When is this patch going to be applied? It's still not in 2.6.13-rc2, it's been 4 months! Huh? Huh? When? :)
2.6.13-rc2 should not need these patches, right? Please test to verify it.
I have tested just a half an hour ago. Why do you think they're not needed?
sorry, I said wrong. I have tested 2.6.12.2 (where it fails) and noted no significant difference (in acm) to 2.6.13-rc2. Is there a change somewhere else which would make the patch unnecessary?
Yes, the usb core and driver core have changed. This patch should no longer be necessary. Can you please test 2.6.13-rc2 and let me know if it works or not?
2.6.13-rc2 says: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c0237d76 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: cdc_acm ohci_hcd usbcore CPU: 0 EIP: 0060:[<c0237d76>] Tainted: G S VLI EFLAGS: 00010246 (2.6.13-rc2) EIP is at get_kobj_path_length+0x26/0x40 eax: 00000000 ebx: 00000000 ecx: ffffffff edx: d739d694 esi: 00000001 edi: 00000000 ebp: ffffffff esp: ceb3bd94 ds: 007b es: 007b ss: 0068 Process minicom (pid: 4285, threadinfo=ceb3a000 task=d37100c0) Stack: d736dc53 d739d614 d7d6c0f8 d739d694 c0237e0f d739d694 00000286 c04a58a8 c04a58c0 d736dc53 d739d614 d7d6c0f8 000003ad c02a1c37 d739d694 000000d0 00000286 00000286 d67fd6a0 00000013 ffffffff fffffffd d736dc29 00000000 Call Trace: [<c0237e0f>] kobject_get_path+0x1f/0x80 [<c02a1c37>] class_hotplug+0x137/0x210 [<c0238afe>] kobject_hotplug+0x1ee/0x300 [<c02a21eb>] class_device_del+0x8b/0x100 [<c02a2273>] class_device_unregister+0x13/0x30 [<d899d73c>] acm_tty_close+0xcc/0x110 [cdc_acm] [<c026f304>] release_dev+0x774/0x780 [<c0164b7b>] invalidate_inode_buffers+0x1b/0x90 [<c017d046>] clear_inode+0xb6/0xe0 [<c01a7158>] reiserfs_delete_inode+0x38/0xe0 [<c026f814>] tty_release+0x14/0x20 [<c016388b>] __fput+0x11b/0x130 [<c0161e5d>] filp_close+0x4d/0x80 [<c0161efd>] sys_close+0x6d/0x90 [<c0103175>] syscall_call+0x7/0xb Code: 90 8d 74 26 00 55 bd ff ff ff ff 57 56 be 01 00 00 00 53 8b 54 24 14 31 db 8d b6 00 00 00 00 8d bf 00 00 00 00 8b 3a 89 e9 89 d8 <f2> ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 ea 5b 89 f0 5e 5f
I have verified that this is now fixed in 2.6.13-rc4
Great, thanks for verifying.