Bug 24582 - Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 normal
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks: 21782
  Show dependency treegraph
 
Reported: 2010-12-09 19:16 UTC by Maciej Rutecki
Modified: 2011-06-18 08:24 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.37-rc4
Tree: Mainline
Regression: Yes


Attachments
image of panic message (399.91 KB, image/jpeg)
2011-02-15 09:59 UTC, Amit Shah
Details
proposed fix (2.60 KB, patch)
2011-02-15 14:56 UTC, Jiri Slaby
Details | Diff

Description Maciej Rutecki 2010-12-09 19:16:58 UTC
Subject    : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter  : "baoyb" <baoyb@avit.org.cn>
Date       : 2010-12-08 13:55
Message-ID : EF6DDE218DB34702B1FA84D6CD7EA771@baoyb
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2

This entry is being used for tracking a regression from 2.6.36. Please don't
close it until the problem is fixed in the mainline.
Comment 1 Greg Kroah-Hartman 2010-12-09 19:30:16 UTC
Should be resolved in 2.6.37-rc5.  Can you test?
Comment 2 baoyb 2010-12-10 04:32:23 UTC
Thanks,I tested 2.6.37-rc5,the kernel also crashed when pppd disconnet the link.
following is log info when oops heppened.

--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Thu Jan  1 00:02:30 1970
--> Pid of pppd: 1151
Unable to handle kernel paging request for data at address 0x000000d8
Faulting instruction address: 0xc0175b3c
Oops: Kernel access of bad area, sig: 11 [#1]
PowerPC 40x Platform
last sysfs file: /sys/devices/pci0000:00/0000:00:00.0/0000:01:00.0/0000:02:09.2/usb1/idVendor
Modules linked in:
NIP: c0175b3c LR: c0175e7c CTR: c0215c90
REGS: c77f7d50 TRAP: 0300   Not tainted  (2.6.37-rc5)
MSR: 00021030 <ME,CE,IR,DR>  CR: 88482028  XER: 2000005f
DEAR: 000000d8, ESR: 00000000
TASK = c7141b90[1149] 'wvdial' THREAD: c2750000
GPR00: 00021030 c77f7e00 c7141b90 00000000 0000000e 00000000 0000000e c0410680 
GPR08: c683db00 00000000 00000001 c03c81f8 88482028 10073ef4 ffffffb9 ffffff94 
GPR16: 00000000 fde036c0 00200200 00100100 00000001 ffffff8d c34fabcc 00000000 
GPR24: c71120d4 00000000 00000000 0000000e 00021030 00000000 00000000 0000000e 
NIP [c0175b3c] tty_buffer_request_room+0x2c/0x194
LR [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0
Call Trace:
[c77f7e00] [00000003] 0x3 (unreliable)
[c77f7e30] [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0
[c77f7e60] [c0215df4] usb_wwan_indat_callback+0x164/0x170
[c77f7e80] [c01e7330] usb_hcd_giveback_urb+0x5c/0xdc
[c77f7e90] [c01f8510] ehci_urb_done+0xe4/0xf8
[c77f7eb0] [c01f85d8] qh_completions+0xb4/0x4d0
[c77f7f10] [c01f96a8] ehci_work+0xdc/0x990
[c77f7f60] [c01fcf34] ehci_irq+0x1c0/0x224
[c77f7f90] [c01e7898] usb_hcd_irq+0x68/0xa8
[c77f7fa0] [c0052858] handle_IRQ_event+0x54/0x12c
[c77f7fc0] [c00553bc] handle_level_irq+0xa0/0x13c
[c77f7fd0] [c0017ca4] uic_irq_cascade+0x100/0x128
[c77f7ff0] [c000cdb4] call_handle_irq+0x18/0x28
[c2751f10] [c0005230] do_IRQ+0xa4/0x140
[c2751f40] [c000da98] ret_from_except+0x0/0x18
Instruction dump:
4e800020 9421ffd0 7c0802a6 7d800026 bf410018 90010034 91810014 7c7e1b78 
7c9f2378 7f8000a6 5780045e 7c000124 <83a300d8> 2e1d0000 4192014c 813d0010 
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[c77f7c80] [c000700c] show_stack+0x44/0x16c (unreliable)
[c77f7cc0] [c00211f4] panic+0xa4/0x1dc
[c77f7d10] [c000abd8] die+0x190/0x19c
[c77f7d30] [c001091c] bad_page_fault+0xc0/0x108
[c77f7d40] [c000d904] handle_page_fault+0x7c/0x80
[c77f7e00] [00000003] 0x3
[c77f7e30] [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0
[c77f7e60] [c0215df4] usb_wwan_indat_callback+0x164/0x170
[c77f7e80] [c01e7330] usb_hcd_giveback_urb+0x5c/0xdc
[c77f7e90] [c01f8510] ehci_urb_done+0xe4/0xf8
[c77f7eb0] [c01f85d8] qh_completions+0xb4/0x4d0
[c77f7f10] [c01f96a8] ehci_work+0xdc/0x990
[c77f7f60] [c01fcf34] ehci_irq+0x1c0/0x224
[c77f7f90] [c01e7898] usb_hcd_irq+0x68/0xa8
[c77f7fa0] [c0052858] handle_IRQ_event+0x54/0x12c
[c77f7fc0] [c00553bc] handle_level_irq+0xa0/0x13c
[c77f7fd0] [c0017ca4] uic_irq_cascade+0x100/0x128
[c77f7ff0] [c000cdb4] call_handle_irq+0x18/0x28
[c2751f10] [c0005230] do_IRQ+0xa4/0x140
[c2751f40] [c000da98] ret_from_except+0x0/0x18
Rebooting in 1 seconds..
Comment 3 baoyb 2010-12-10 04:33:30 UTC
And I also tested v2.6.29.6 and v2.6.32.24.when pppd disconnet the link,the kernel is unlikely crash.
Comment 4 Jiri Slaby 2011-01-06 14:02:23 UTC
Is still still an issue with .37 final?
Comment 5 Jiri Slaby 2011-02-13 13:57:31 UTC
Ping?
Comment 6 Amit Shah 2011-02-15 09:57:31 UTC
Happens for me with 2.6.38-rc6+.

Haven't looked at code yet or even transcribed to text, but the attached image is where I get a kernel panic.

This happened when I think the 3g signal went quite low so packets must have taken longer to transmit or receive.
Comment 7 Amit Shah 2011-02-15 09:59:17 UTC
Created attachment 47862 [details]
image of panic message
Comment 8 Amit Shah 2011-02-15 10:04:13 UTC
(Also confirmed there aren't usb- or tty- specific patches in the fedora kernel I used above to make a difference in the panic.)

I'll disassemble the objs and get pointers to the source where this happens in the next few days.
Comment 9 Jiri Slaby 2011-02-15 14:56:12 UTC
Created attachment 47872 [details]
proposed fix

Well, usb_wwan_indat_callback doesn't check tty_port_tty_get return value. It can be NULL. So let's check it...
Comment 10 Florian Mickler 2011-02-20 12:44:28 UTC
Amit, does this patch fixes the issue for you? 

Patch: https://bugzilla.kernel.org/attachment.cgi?id=47872
Comment 11 Rafael J. Wysocki 2011-02-21 22:25:16 UTC
Handled-By : Jiri Slaby <jslaby@suse.cz>
Comment 12 Chuck Ebbert 2011-02-25 14:45:50 UTC
Fixed by commit 38237fd2be9421c104f84cc35665097bdce89013
Comment 13 Amit Shah 2011-02-28 06:58:30 UTC
(reply to comment 10): This was rare enough for me; hasn't reproduced often w/o the patch and hasn't reproduced so far with the patch either.  Looking at the stack trace, though, looks like Jiri's patch is the right fix.  If it recurs, I'll note it in another bug.
Comment 14 Florian Mickler 2011-03-04 23:51:12 UTC
merged for .38-rc7: 
commit 38237fd2be9421c104f84cc35665097bdce89013
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Tue Feb 15 15:55:07 2011 +0100

    USB: serial/usb_wwan, fix tty NULL dereference
Comment 15 Rodrigo de Farias Gomes 2011-05-05 22:47:40 UTC
This bug occur too in the kernel 2.6.35, but the fix was not applied in the version 2.6.35.13. I use Fedora 14, kernel 2.6.35.12-90.fc14.x86_64, and after apply that fix my computer don't freeze at modem hangup...

Sorry by the english, I could not proofreading the text by lack of time (english is not my native language...)
Comment 16 Rodrigo de Farias Gomes 2011-06-17 23:08:25 UTC
When the kernel 2.6.35.14 containing this fix will be released?
Comment 17 Florian Mickler 2011-06-18 08:24:55 UTC
You'd have to check with Andi Kleen or stable@kernel.org about that...

Note You need to log in before you can comment on or make changes to this bug.