[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANG1+n7Vp-FNCD=uCyHDDFiuCv+u3Ss1L-YUjUc83x7gUD6AkQ@mail.gmail.com>
Date: Tue, 3 Jun 2014 16:54:41 -0700
From: Prathmesh Prabhu <pprabhu@...gle.com>
To: netdev@...r.kernel.org
Subject: Fwd: Kernel panic following bind failure in NCM driver
System info:
- A chromebook with kernel 3.10/3.14 from the ChromiumOS tree.
Steps to reproduce:
- stop modemmanager
- Connect an MBIM modem on an external USB port.
- echo 0 > /sys/bus/usb/devices/xxx/authorized && sleep 1 && echo 1 >
/sys/bus/usb/devices/xxx/authorized
Symptom:
- kernel panic
There is likely a firmware bug in the modem that I'm chasing in
parallel that causes a USB Disconnect after the usb re-authorization.
My concern here is the kernel panic, irrespective of the modem bug.
Attached log has some kernel debugging enabled along with some extra
messages I added. Smell:
<4>[ 384.260677] PPP23: usb_authorize_device
...
<7>[ 384.261969] bus: 'usb': driver_probe_device: matched device
1-1:2.0 with driver cdc_ncm
<7>[ 384.261988] bus: 'usb': really_probe: probing driver cdc_ncm
with device 1-1:2.0
...
<4>[ 384.337078] PPP23: something disconnect.
<6>[ 384.337087] usb 1-1: USB disconnect, device number 18
<6>[ 384.337213] usb 1-1: bind() failure
<7>[ 384.337239] cdc_ncm: probe of 1-1:2.0 rejects match -19
...
<6>[ 384.337794] usb 1-1: authorized to connect
...
<7>[ 384.338142] bus: 'usb': remove device 1-1:2.3
<5>[ 384.338162] Oops: 0000 [#1]
My reading so far is that the disconnect races with the ncm driver's
cdc_ncm_bind_common function. This eventually leads to a kernel worker
thread crash.
<5>[ 384.341607] Call Trace:
<5>[ 384.341616] [<ffffffff8ea4bc10>] worker_thread+0x13c/0x26f
<5>[ 384.341626] [<ffffffff8ea4bad4>] ? manage_workers.isra.27+0x1d7/0x1d7
<4>[ 384.341630] PPP23: trace: usb_remove_ep_devs
<7>[ 384.341631] device: 'ep_00': device_unregister
<5>[ 384.341646] [<ffffffff8ea50a92>] kthread+0xae/0xb6
<7>[ 384.341655] PM: Removing info for No Bus:ep_00
<5>[ 384.341657] [<ffffffff8ea509e4>] ? __kthread_parkme+0x65/0x65
<5>[ 384.341664] [<ffffffff8ef1471c>] ret_from_fork+0x7c/0xb0
<5>[ 384.341668] [<ffffffff8ea509e4>] ? __kthread_parkme+0x65/0x65
Notes:
- The crash itself is in (possibly related?) kernel worker thread.
- I have not yet figured out the actual crash site.
- This is highly reproducible following the steps above (> 60%
attempts). That's why I think this is indeed related to the ncm driver
/ net usb subsystem.
I'd appreciate any insights into what might be going wrong / precedent.
Thanks,
Prathmesh
Download attachment "kernel.kcrash" of type "application/octet-stream" (19005 bytes)
Powered by blists - more mailing lists