Forgot to mention that this works flawless with 2.6.30

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

On Mon, 22 Jun 2009 13:58:09 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=13601
> 
>            Summary: Hard crash connecting via Huawei E169 + umtsmon
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.31-0.17.rc0.git15.fc12.i586
>           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

A post-2.6.30 regression.

> 
> When connect my Huawei E169 using umtsmon, I always get the following hard
> crash:
> 
> Jun 22 15:48:22 localhost kernel: Pid: 4807, comm: umtsmon Not tainted
> (2.6.31-0.17.rc0.git15.fc12.i586 #1) Tecra A8
> Jun 22 15:48:22 localhost kernel: EIP: 0060:[<c045b298>] EFLAGS: 00010046
> CPU:
> 1
> Jun 22 15:48:22 localhost kernel: EIP is at finish_wait+0x45/0x6e
> Jun 22 15:48:22 localhost kernel: EAX: 00000000 EBX: f53dd0f8 ECX: 00000000
> EDX: 00000246
> Jun 22 15:48:22 localhost kernel: ESI: f47b5dcc EDI: f47b5dd8 EBP: f47b5da0
> ESP: f47b5d90
> Jun 22 15:48:22 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS:
> 0068
> Jun 22 15:48:22 localhost kernel: Process umtsmon (pid: 4807, ti=f47b4000
> task=f1d62b80 task.ti=f47b4000)
> Jun 22 15:48:22 localhost kernel: Stack:
> Jun 22 15:48:22 localhost kernel: e9dbb5ab f53dd0c4 fffffe00 00000001
> f47b5df0
> c0678810 00000246 f53dd0f8
> Jun 22 15:48:22 localhost kernel: <0> f53dd0cc f1d8fe00 f53dd1d8 f53dd200
> f47b5dcc c046d86c e9dbb5ab 00000000
> Jun 22 15:48:22 localhost kernel: <0> f1d62b80 c043e5ac 00000000 00000000
> e9dbb5ab fffffe00 f63252d0 f53dd0c0
> Jun 22 15:48:22 localhost kernel: Call Trace:
> Jun 22 15:48:22 localhost kernel: [<c0678810>] ?
> tty_port_block_til_ready+0x1d0/0x21f
> Jun 22 15:48:22 localhost kernel: [<c046d86c>] ? trace_hardirqs_on+0x19/0x2c
> Jun 22 15:48:22 localhost kernel: [<c043e5ac>] ?
> default_wake_function+0x0/0x35
> Jun 22 15:48:22 localhost kernel: [<f8e4a47e>] ? serial_open+0x176/0x1ec
> [usbserial]
> Jun 22 15:48:22 localhost kernel: [<c0673025>] ? tty_open+0x292/0x39d
> Jun 22 15:48:22 localhost kernel: [<c04f64f4>] ? chrdev_open+0x117/0x145
> Jun 22 15:48:22 localhost kernel: [<c04f132c>] ? __dentry_open+0x17f/0x2ad
> Jun 22 15:48:22 localhost kernel: [<c04f63dd>] ? chrdev_open+0x0/0x145
> Jun 22 15:48:22 localhost kernel: [<c04f1530>] ? nameidata_to_filp+0x41/0x67
> Jun 22 15:48:22 localhost kernel: [<c04fe13d>] ? do_filp_open+0x3f2/0x704
> Jun 22 15:48:22 localhost kernel: [<c05081e2>] ? alloc_fd+0x38/0xef
> Jun 22 15:48:22 localhost kernel: [<c05081e2>] ? alloc_fd+0x38/0xef
> Jun 22 15:48:22 localhost kernel: [<c05081e2>] ? alloc_fd+0x38/0xef
> Jun 22 15:48:22 localhost kernel: [<c08122e1>] ? _spin_unlock+0x30/0x45
> Jun 22 15:48:22 localhost kernel: [<c050827b>] ? alloc_fd+0xd1/0xef
> Jun 22 15:48:22 localhost kernel: [<c04f1031>] ? do_sys_open+0x5c/0x109
> Jun 22 15:48:22 localhost kernel: [<c04f115b>] ? sys_open+0x31/0x4a
> Jun 22 15:48:22 localhost kernel: [<c0403a5c>] ? syscall_call+0x7/0xb
> Jun 22 15:48:22 localhost kernel: Code: f0 31 c0 8d 7a 0c 64 a1 00 10 ad c0
> c7
> 00 00 00 00 00 39 7a 0c 75 05 3b 7a 10 74 21 89 d8 e8 3a 73 3b 00 8b 4e 10 89
> c2 8b 46 0c <89> 48 04 89 01 89 d8 89 7e 0c 89 7e 10 e8 9a 6f 3b 00 8b 45 f0 
> Jun 22 15:48:22 localhost kernel: EIP: [<c045b298>] finish_wait+0x45/0x6e
> SS:ESP 0068:f47b5d90
> Jun 22 15:48:22 localhost kernel: CR2: 0000000000000004
> Jun 22 15:48:22 localhost kernel: ---[ end trace 7b7ea1124776698e ]---
> 

And a somewhat familiar-looking one.  Have you been able to retest
2.6.31-rc1 or later?  We might have already fixed this.

Thanks.

Seems to work fine with 2.6.31.rc1 :)