Bug 13906
Summary: | Huawei E169 GPRS connection causes Ooops | ||
---|---|---|---|
Product: | Drivers | Reporter: | Clemens Eisserer (linuxhippy) |
Component: | Serial | Assignee: | Greg Kroah-Hartman (greg) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | akpm, gerald, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.31.rc5 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 13615 |
Description
Clemens Eisserer
2009-08-04 09:02:13 UTC
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 4 Aug 2009 09:02:16 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13906 > > Summary: Huawei E169 GPRS connection causes Ooops > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.31.rc5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Serial > AssignedTo: rmk@arm.linux.org.uk > ReportedBy: linuxhippy@gmail.com > Regression: No > use-after-free in the tty/serial code, I expect. I also expect that it's a regression - Clemens, are you able to say whether any earlier kernel version worked OK? Thanks. > I am using umtsmon to connect my Huawei-E169 to Internet. > > When connecting to an UMTS network everything works fine, however when > connecting to a GPRS network (fallback, if no umts network available), I get > the following Ooops: > > PPP generic driver version 2.4.2 > PPP Deflate Compression module registered > BUG: unable to handle kernel paging request at 6b6b6b87 > IP: [<f7cc3df9>] serial_do_free+0x30/0x7b [usbserial] > *pde = 00000000 > Oops: 0000 [#1] SMP > last sysfs file: > > /sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/ieee80211/phy0/rfkill1/uevent > Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic > slhc fuse option usbserial usb_storage sunrpc ipv6 cpufreq_ondemand > acpi_cpufreq dm_multipath uinput snd_hda_codec_si3054 snd_hda_codec_realtek > snd_hda_intel snd_hda_codec snd_hwdep snd_pcm arc4 ppdev btusb parport_pc ecb > bluetooth firewire_ohci firewire_core iwl3945 sdhci_pci yenta_socket > snd_timer > iTCO_wdt sdhci snd parport rsrc_nonstatic crc_itu_t iTCO_vendor_support > iwlcore > mmc_core soundcore snd_page_alloc e1000e mac80211 toshiba_acpi cfg80211 > joydev > rfkill ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core video output > [last > unloaded: microcode] > > Pid: 1472, comm: umtsmon Not tainted (2.6.31-0.118.rc5.fc12.i686 #1) Tecra A8 > EIP: 0060:[<f7cc3df9>] EFLAGS: 00010286 CPU: 0 > EIP is at serial_do_free+0x30/0x7b [usbserial] > EAX: f259ca6c EBX: f63eca50 ECX: f7cc3e44 EDX: 6b6b6b6b > ESI: f63eca88 EDI: 00000000 EBP: f15d3e84 ESP: f15d3e74 > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > Process umtsmon (pid: 1472, ti=f15d2000 task=f1602b80 task.ti=f15d2000) > Stack: > ed87ae0e f259c860 f25872a0 00000000 f15d3ea0 f7cc3ed3 f15cc900 ed87ae0e > <0> f25872a0 00000000 00000000 f15d3f34 c0679747 f15d3ee4 f25960b0 00000000 > <0> 00000000 ed87ae0e 00000000 ed87ae0e f15d3ee4 c046ec0c 00000000 00000000 > Call Trace: > [<f7cc3ed3>] ? serial_close+0x8f/0xa8 [usbserial] > [<c0679747>] ? tty_release_dev+0x16a/0x3fa > [<c046ec0c>] ? mark_lock+0x29/0x1f6 > [<c045c7ba>] ? autoremove_wake_function+0x0/0x55 > [<c04f524a>] ? sys_close+0x35/0xc2 > [<c06799fc>] ? tty_release+0x25/0x41 > [<c04f8a42>] ? __fput+0x101/0x1a2 > [<c04f8b0a>] ? fput+0x27/0x3a > [<c04f51fa>] ? filp_close+0x64/0x7f > [<c04f5291>] ? sys_close+0x7c/0xc2 > [<c0403a50>] ? syscall_call+0x7/0xb > Code: 53 83 ec 04 0f 1f 44 00 00 65 8b 15 14 00 00 00 89 55 f0 31 d2 80 b8 06 > 02 00 00 00 75 41 8b 18 05 0c 02 00 00 8b 53 04 8d 73 38 <8b> 7a 1c e8 14 03 > 9e > c8 31 d2 89 f0 e8 54 80 b5 c8 f6 43 0c 01 > EIP: [<f7cc3df9>] serial_do_free+0x30/0x7b [usbserial] SS:ESP 0068:f15d3e74 > CR2: 000000006b6b6b87 > ---[ end trace 6c0877bfb04cdcd3 ]--- Assigned to Greg. Sorry :( Hi Andrew, > use-after-free in the tty/serial code, I expect. > > I also expect that it's a regression - Clemens, are you able to say > whether any earlier kernel version worked OK? 2.6.30 worked fine, 2.6.31.rc2 already showed that problem. - Clemens 2009/8/4, Andrew Morton <akpm@linux-foundation.org>: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Tue, 4 Aug 2009 09:02:16 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=13906 >> >> Summary: Huawei E169 GPRS connection causes Ooops >> Product: Drivers >> Version: 2.5 >> Kernel Version: 2.6.31.rc5 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Serial >> AssignedTo: rmk@arm.linux.org.uk >> ReportedBy: linuxhippy@gmail.com >> Regression: No >> > > use-after-free in the tty/serial code, I expect. > > I also expect that it's a regression - Clemens, are you able to say > whether any earlier kernel version worked OK? > > Thanks. > >> I am using umtsmon to connect my Huawei-E169 to Internet. >> >> When connecting to an UMTS network everything works fine, however when >> connecting to a GPRS network (fallback, if no umts network available), I >> get >> the following Ooops: >> >> PPP generic driver version 2.4.2 >> >> PPP Deflate Compression module registered >> >> BUG: unable to handle kernel paging request at 6b6b6b87 >> >> IP: [<f7cc3df9>] serial_do_free+0x30/0x7b [usbserial] >> >> *pde = 00000000 >> >> Oops: 0000 [#1] SMP >> >> last sysfs file: >> >> /sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/ieee80211/phy0/rfkill1/uevent >> >> Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt >> ppp_generic >> slhc fuse option usbserial usb_storage sunrpc ipv6 cpufreq_ondemand >> acpi_cpufreq dm_multipath uinput snd_hda_codec_si3054 >> snd_hda_codec_realtek >> snd_hda_intel snd_hda_codec snd_hwdep snd_pcm arc4 ppdev btusb parport_pc >> ecb >> bluetooth firewire_ohci firewire_core iwl3945 sdhci_pci yenta_socket >> snd_timer >> iTCO_wdt sdhci snd parport rsrc_nonstatic crc_itu_t iTCO_vendor_support >> iwlcore >> mmc_core soundcore snd_page_alloc e1000e mac80211 toshiba_acpi cfg80211 >> joydev >> rfkill ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core video output >> [last >> unloaded: microcode] >> >> Pid: 1472, comm: umtsmon Not tainted (2.6.31-0.118.rc5.fc12.i686 #1) Tecra >> A8 >> EIP: 0060:[<f7cc3df9>] EFLAGS: 00010286 CPU: 0 >> EIP is at serial_do_free+0x30/0x7b [usbserial] >> EAX: f259ca6c EBX: f63eca50 ECX: f7cc3e44 EDX: 6b6b6b6b >> ESI: f63eca88 EDI: 00000000 EBP: f15d3e84 ESP: f15d3e74 >> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 >> Process umtsmon (pid: 1472, ti=f15d2000 task=f1602b80 task.ti=f15d2000) >> Stack: >> ed87ae0e f259c860 f25872a0 00000000 f15d3ea0 f7cc3ed3 f15cc900 ed87ae0e >> <0> f25872a0 00000000 00000000 f15d3f34 c0679747 f15d3ee4 f25960b0 >> 00000000 >> <0> 00000000 ed87ae0e 00000000 ed87ae0e f15d3ee4 c046ec0c 00000000 >> 00000000 >> Call Trace: >> [<f7cc3ed3>] ? serial_close+0x8f/0xa8 [usbserial] >> [<c0679747>] ? tty_release_dev+0x16a/0x3fa >> [<c046ec0c>] ? mark_lock+0x29/0x1f6 >> [<c045c7ba>] ? autoremove_wake_function+0x0/0x55 >> [<c04f524a>] ? sys_close+0x35/0xc2 >> [<c06799fc>] ? tty_release+0x25/0x41 >> [<c04f8a42>] ? __fput+0x101/0x1a2 >> [<c04f8b0a>] ? fput+0x27/0x3a >> [<c04f51fa>] ? filp_close+0x64/0x7f >> [<c04f5291>] ? sys_close+0x7c/0xc2 >> [<c0403a50>] ? syscall_call+0x7/0xb >> Code: 53 83 ec 04 0f 1f 44 00 00 65 8b 15 14 00 00 00 89 55 f0 31 d2 80 b8 >> 06 >> 02 00 00 00 75 41 8b 18 05 0c 02 00 00 8b 53 04 8d 73 38 <8b> 7a 1c e8 14 >> 03 9e >> c8 31 d2 89 f0 e8 54 80 b5 c8 f6 43 0c 01 >> EIP: [<f7cc3df9>] serial_do_free+0x30/0x7b [usbserial] SS:ESP >> 0068:f15d3e74 >> CR2: 000000006b6b6b87 >> ---[ end trace 6c0877bfb04cdcd3 ]--- > > Marked as a regression. Post-2.6.30. On Tue, 4 Aug 2009, Andrew Morton wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=13906 > > > > Summary: Huawei E169 GPRS connection causes Ooops There are a lot of serial fixes in Greg KH's queue. Try applying: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch to your 2.6.31-rc5 kernel. In particular, this one patch: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-tty/tty-usb-shutdown might solve your problem. Alan Stern On Tue, Aug 04, 2009 at 10:25:20AM -0400, Alan Stern wrote: > On Tue, 4 Aug 2009, Andrew Morton wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=13906 > > > > > > Summary: Huawei E169 GPRS connection causes Ooops > > There are a lot of serial fixes in Greg KH's queue. Try applying: > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch > > to your 2.6.31-rc5 kernel. In particular, this one patch: > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-tty/tty-usb-shutdown > > might solve your problem. If it does, I need to know soon, as that isn't queued up for a .31 release. thanks, greg k-h I'll try to get that done soon, however its not easy sitting behind a ~56K GPRS connection which decides to break every 5min ;) - Clemens 2009/8/4, Greg KH <greg@kroah.com>: > On Tue, Aug 04, 2009 at 10:25:20AM -0400, Alan Stern wrote: >> On Tue, 4 Aug 2009, Andrew Morton wrote: >> >> > > http://bugzilla.kernel.org/show_bug.cgi?id=13906 >> > > >> > > Summary: Huawei E169 GPRS connection causes Ooops >> >> There are a lot of serial fixes in Greg KH's queue. Try applying: >> >> >> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch >> >> to your 2.6.31-rc5 kernel. In particular, this one patch: >> >> >> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-tty/tty-usb-shutdown >> >> might solve your problem. > > If it does, I need to know soon, as that isn't queued up for a .31 release. > > thanks, > > greg k-h > 2.6.31.5-96.fc12.i686 seems to work fine :) Great, marking closed. |