Skip to contentSkip to conversation

New: Huawei E169 GPRS connection causes Ooops

Bugme-new Andrew Morton 5 participants 5 messages Aug 4, 2009 3 messages not in the archive TTY layer and serial drivers

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Tue, 4 Aug 2009 09:02:16 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        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.

Quoted 53 lines

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 ]---
#2 lore raw

Hi Andrew,

Quoted 4 lines

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 <[email protected]>:

Quoted 107 lines

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Tue, 4 Aug 2009 09:02:16 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        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.

Quoted 74 lines

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 ]---

A message that is not in the archive (sent off-list or not yet received): 20090804021637.ce7e62ad.akpm-de/[email protected]

#4 lore raw
Quoted 3 lines · Andrew Morton
Quoted 3 lines

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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 8 lines · Alan Stern
Quoted 3 lines · Andrew Morton
Quoted 3 lines

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:

Quoted 7 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw

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 <[email protected]>:

Quoted 15 lines · Alan Stern
Quoted 14 lines · Andrew Morton
Quoted 4 lines
Quoted 4 lines

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

Quoted 8 lines
Quoted 1 line

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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html