[#7385] Kernel panic in musb_gadget.c when using carl9170 wireless driver

Document created by Aaronwu Employee on Sep 12, 2013
Version 1Show Document
  • View in full screen mode

[#7385] Kernel panic in musb_gadget.c when using carl9170 wireless driver

Submitted By: Stephan Hoffmann

Open Date

2012-10-14 09:57:26    

Priority:

Medium     Assignee:

Bob Liu

Status:

Open     Fixed In Release:

N/A

Found In Release:

N/A     Release:

Category:

Drivers     Board:

Custom

Processor:

ALL     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Assigned (Not Start)

Uboot version or rev.:

    Toolchain version or rev.:

ADI-2012R1-RC2

App binary format:

N/A     

Summary: Kernel panic in musb_gadget.c when using carl9170 wireless driver

Details:

 

Hello all,

 

when the usb wifi stick MSI US300N is used together with the carl9170 driver the kernel crashes in the function musb_g_tx() in the file drivers/usb/musb/musb_gadget.c, because next_request(musb_ep) returns a invalid pointer (0xffffffcc). I could not find out, where this pointer comes from.

 

After working around this by clearing the false req the driver still does not work, producing the following output:

 

[   52.715598] usb 1-1: Unprotected firmware image.

[   55.593060] req == 0xffffffcc!

[   56.600070] usb 1-1: no command feedback received (-110).

[   56.606672] usb 1-1: restart device (6)

[   56.611887] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   57.618887] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   58.626898] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   59.634901] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   60.642896] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   61.650900] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   62.658903] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   63.666896] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   64.674896] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   65.682903] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   66.690898] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-110)

[   67.699156] ------------[ cut here ]------------

[   67.703647] WARNING: at drivers/net/wireless/ath/carl9170/main.c:247

[   67.709953] Modules linked in: carl9170 mac80211 ath cfg80211 gpio_keys spidev i2c_dev

[   67.721377] ---[ end trace 9fc0cd0622913f89 ]---

[   67.725828] Disabling lock debugging due to kernel taint

[   68.741899] ieee80211 phy0: writing reg 0x1d0104 (val 0x1) failed (-110)

[   70.749972] req == 0xffffffcc!

[   70.754108] usb 1-1: kill pending tx urbs.

[   71.959941] usb 1-1: firmware upload failed (-110).

[   72.965876] usb 1-1: stuck tx urbs!

[   72.971181] usb 1-1: Failed to restart device  (-110).

[   73.977139] ------------[ cut here ]------------

[   73.981630] WARNING: at drivers/net/wireless/ath/carl9170/main.c:247

[   73.987936] Modules linked in: carl9170 mac80211 ath cfg80211 gpio_keys spidev i2c_dev

[   73.999420] ---[ end trace 9fc0cd0622913f8a ]---

[   74.015917] ieee80211 phy0: writing reg 0x1c36f0 (val 0x5000) failed (-5)

[   89.528926] usb 1-1: device descriptor read/64, error -110

 

The messages "req == 0xffffffcc!" come from my workaround.

 

Since the carl9170 driver is almost the same as the known good from a ubuntu kernel I think the problem is more likely within musb than in carl9170. In fact I copied the carl9170 source into the blackfin tree without any change.

 

Another, possibly related, issue is, that the MSI US300EX Lite using the rt2800usb driver seems to work at the first glance (makes connection to the access point), but does not transfer data. After a while (about one minute) the connection to the access point is dropped and the following messages appear:

 

[  137.346579] ------------[ cut here ]------------

[  137.351112] WARNING: at drivers/usb/musb/musb_host.c:125 _musb_h_tx_flush_fifo+0x98/0xc4()

[  137.359282] Could not flush host TX1 fifo: csr: 0003

[  137.364210] Modules linked in: rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 cfg80211 gpio_keys spidev i2c_dev

[  137.381933] ---[ end trace ba00996d14c7bd82 ]---

[  139.346209] ------------[ cut here ]------------

[  139.350744] WARNING: at drivers/usb/musb/musb_host.c:125 _musb_h_tx_flush_fifo+0x98/0xc4()

[  139.358913] Could not flush host TX1 fifo: csr: 0003

[  139.363841] Modules linked in: rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 cfg80211 gpio_keys spidev i2c_dev

[  139.381611] ---[ end trace ba00996d14c7bd83 ]---

repeated...

 

This also does not change at all when I use the driver source code from my ubuntu kernel.

 

Since this is somehow urgent I would be thankful for every suggestion.

 

Kind regards

 

Stephan

 

Follow-ups

 

--- Rob Maris                                                2012-10-16 04:08:49

I'd appreciate it very much when when Analog folks would supply at least an

intermediate comment. The bug tracking system is not that busy that this

couldn't be responded to, yet. A customer is going to ask why blackfin was

chosen as the core of a linux-based product that goes in far more than 1000

units/year.

 

--- Stephan Hoffmann                                         2012-10-16 14:25:26

In the meantime I found out that the same problem also exists in the

trunk version.

 

--- Rob Maris                                                2012-10-19 06:48:35

Update: using a more stiff power supply, the stick is operating correctly (at

least does successful initialisation).

Issue priority may be lowered. However, the issue should not be closed, since

it is better when the system does not crash when Vusb goes below the valid

threshold (4.4V), but instead  generates a printk warning!

 

--- Sonic Zhang                                              2012-10-22 05:44:07

You's better ask this question in ADI EZ help community first before sumitting a

bug. Because we don't have your customer hardware, could you please show us a

way to replicate your problem on bf609-ezkit board. Maybe attach your driver and

send us a carl9170 USB dungle?

 

--- Stephan Hoffmann                                         2012-10-22 11:26:35

Hello,

thank you for responding to my bug report.

In fact there is a bug in the musb implementation, since musb_g_tx() gets

called when the controller changes state to Device mode because of a VBus error,

even when the driver is in host mode. This causes the crash.

I was not aware that the 2012 release is for the new bf609 only, so my bug

report is obsolete, since it relates to bf526.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes