RE: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Craig McQueen 
Yegor Yefremov wrote:
> On Tue, May 10, 2016 at 9:43 AM, Yegor Yefremov
>  wrote:
> > On Tue, May 10, 2016 at 9:17 AM, Craig McQueen
> >  wrote:
> >> Yegor Yefremov wrote:
> >>> Hi Craig,
> >>>
> >>> On Tue, May 10, 2016 at 8:08 AM, Craig McQueen
> >>>  wrote:
> >>> > I previously wrote:
> >>> >> I previously wrote:
> >>> >> > I previously wrote:
> >>> >> > >
> >>> >> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based
> >>> >> > > (5392 chipset). I've been testing it on a BeagleBone Black
> >>> >> > > running an Ubuntu
> >>> >> > > 16.04 image (4.4.6 kernel), with a USB hub.
> >>> >> > >
> >>> >> > > When I unplug the Wi-Fi device from the USB hub, and it's
> >>> >> > > connected to an access point, and then I unplug it, the OS appears
> to
> >>> lock up.
> >>> >> > > I get messages about a soft lockup on the serial console:
> >>> >> > >
> >>> >> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for
> 22s!
> >>> >> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft
> lockup
> >>> >> > > -
> >>> >> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI
> >>> watchdog:
> >>> >> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
> >>> >> > > 9820.136699] NMI
> >>> >> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> >>> >> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft
> lockup
> >>> >> > > -
> >>> >> CPU#0 stuck for 22s!
> >>> >> > > [kworker/u2:0:1129]
> >>> >> > >
> >>> >> > > This will repeat indefinitely, until I unplug the hub, which
> >>> >> > > resolves the soft lockup and then the system seems to function
> >>> normally.
> >>> >> > >
> >>> >> > > I've attached a dmesg log of the soft lockup stack traces. They
> >>> >> > > seem to indicate a lockup in workqueue
> rt2x00usb_work_rxdone()
> >>> >> > > (specifically in
> >>> >> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry()
> called
> >>> >> > > from rt2x00usb_clear_entry()).
> >>> >> > >
> >>> >> > > I originally found this bug on a 3.14.x kernel built with Yocto
> >>> >> > > for a BeagleBone Black-based product. So it seems this is a bug
> >>> >> > > that has been around for some time.
> >>> >> >
> >>> >> > I should also note that on the 3.14.x Yocto-built kernel on
> >>> >> > BeagleBone Black, this bug does not occur if the rt2800 device is
> >>> >> > unplugged directly from the BBB's USB port. It only occurs if
> unplugged
> >>> from a hub.
> >>> >> >
> >>> >> > I have tested this on an i586 based eBox-3310A mini-PC running
> >>> >> > Debian 8.4, which has a 3.16.0 kernel, with the same hub and same
> >>> >> > rt2800 device. But I was not able to reproduce this issue.
> >>> >>
> >>> >> There is a patch for the AM335x musb driver that seems to fix this:
> >>> >>
> >>> >> http://marc.info/?l=linux-usb=146173995117456=2
> >>> >>
> >>> >> So it seems that this issue's root cause is in the AM335x USB
> >>> >> interrupt handling, and not the Wi-Fi rt2800 driver.
> >>> >
> >>> > Having applied two AM335x USB patches in the 3.14.49 kernel, that
> does
> >>> seem to resolve the soft lock-up on the RX side. The two patches are:
> >>> >
> >>> > http://marc.info/?l=linux-usb=146173995117456=2
> >>> > http://marc.info/?l=linux-usb=146222355213935=2
> >>> >
> >>> > But I am finding there is still a lock-up issue when unplugging from a
> hub,
> >>> this time on the TX side. It is more likely if there is Wi-Fi traffic in 
> >>> progress
> >>> when the unplug occurs. I'm attaching a log. Essentially there are a heap
> of
> >>> lines (100 or so per second):
> >>> >
> >>> > [ 1866.693511] ieee80211 phy7:
> rt2800usb_tx_sta_fifo_read_completed:
> >>> > Warning - TX status read failed -71
> >>> >
> >>> > Which finally stop shortly after USB disconnect is detected:
> >>> >
> >>> > [ 1866.985854] usb 1-1.3: USB disconnect, device number 10
> >>> >
> >>> > However that disconnect message is typically 30-90 seconds after the
> >>> unplug happened. It seems that the USB disconnect detection is delayed
> due
> >>> to the CPU load of the TX.
> >>> >
> >>> > I also sometimes see a kernel panic. That can occur whether connected
> to a
> >>> USB hub or directly to the on-board USB port. See the attached log.
> >>> >
> >>> > I'm not so familiar with either the Wi-Fi or USB stacks in the Linux
> >>> > kernel, so I would appreciate any advice with debugging and fixing
> >>> > this. (My previous investigations indicate these issues are present in
> >>> > both 3.14.x kernel and 4.4.6 kernel. I'm more familiar with working
> >>> > with the 3.14.x kernel under Yocto, but I could try moving to 4.4.6
> >>> > kernel for Ubuntu. I'm open to advice on which to investigate on.)
> >>>
> >>> Take a look at this patch: http://marc.info/?l=linux-
> >>> usb=146222355213935=2
> >>>
> >>> If it fixes your issue please provide your "tested-by" tag here.
> >>
> >> Hi Yegor,
> >>
> >> I am using that patch, and I

Re: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Yegor Yefremov 
On Tue, May 10, 2016 at 9:43 AM, Yegor Yefremov
 wrote:
> On Tue, May 10, 2016 at 9:17 AM, Craig McQueen
>  wrote:
>> Yegor Yefremov wrote:
>>> Hi Craig,
>>>
>>> On Tue, May 10, 2016 at 8:08 AM, Craig McQueen
>>>  wrote:
>>> > I previously wrote:
>>> >> I previously wrote:
>>> >> > I previously wrote:
>>> >> > >
>>> >> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based
>>> >> > > (5392 chipset). I've been testing it on a BeagleBone Black
>>> >> > > running an Ubuntu
>>> >> > > 16.04 image (4.4.6 kernel), with a USB hub.
>>> >> > >
>>> >> > > When I unplug the Wi-Fi device from the USB hub, and it's
>>> >> > > connected to an access point, and then I unplug it, the OS appears to
>>> lock up.
>>> >> > > I get messages about a soft lockup on the serial console:
>>> >> > >
>>> >> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>>> >> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup
>>> >> > > -
>>> >> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI
>>> watchdog:
>>> >> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
>>> >> > > 9820.136699] NMI
>>> >> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>>> >> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup
>>> >> > > -
>>> >> CPU#0 stuck for 22s!
>>> >> > > [kworker/u2:0:1129]
>>> >> > >
>>> >> > > This will repeat indefinitely, until I unplug the hub, which
>>> >> > > resolves the soft lockup and then the system seems to function
>>> normally.
>>> >> > >
>>> >> > > I've attached a dmesg log of the soft lockup stack traces. They
>>> >> > > seem to indicate a lockup in workqueue rt2x00usb_work_rxdone()
>>> >> > > (specifically in
>>> >> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called
>>> >> > > from rt2x00usb_clear_entry()).
>>> >> > >
>>> >> > > I originally found this bug on a 3.14.x kernel built with Yocto
>>> >> > > for a BeagleBone Black-based product. So it seems this is a bug
>>> >> > > that has been around for some time.
>>> >> >
>>> >> > I should also note that on the 3.14.x Yocto-built kernel on
>>> >> > BeagleBone Black, this bug does not occur if the rt2800 device is
>>> >> > unplugged directly from the BBB's USB port. It only occurs if unplugged
>>> from a hub.
>>> >> >
>>> >> > I have tested this on an i586 based eBox-3310A mini-PC running
>>> >> > Debian 8.4, which has a 3.16.0 kernel, with the same hub and same
>>> >> > rt2800 device. But I was not able to reproduce this issue.
>>> >>
>>> >> There is a patch for the AM335x musb driver that seems to fix this:
>>> >>
>>> >> http://marc.info/?l=linux-usb=146173995117456=2
>>> >>
>>> >> So it seems that this issue's root cause is in the AM335x USB
>>> >> interrupt handling, and not the Wi-Fi rt2800 driver.
>>> >
>>> > Having applied two AM335x USB patches in the 3.14.49 kernel, that does
>>> seem to resolve the soft lock-up on the RX side. The two patches are:
>>> >
>>> > http://marc.info/?l=linux-usb=146173995117456=2
>>> > http://marc.info/?l=linux-usb=146222355213935=2
>>> >
>>> > But I am finding there is still a lock-up issue when unplugging from a 
>>> > hub,
>>> this time on the TX side. It is more likely if there is Wi-Fi traffic in 
>>> progress
>>> when the unplug occurs. I'm attaching a log. Essentially there are a heap of
>>> lines (100 or so per second):
>>> >
>>> > [ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed:
>>> > Warning - TX status read failed -71
>>> >
>>> > Which finally stop shortly after USB disconnect is detected:
>>> >
>>> > [ 1866.985854] usb 1-1.3: USB disconnect, device number 10
>>> >
>>> > However that disconnect message is typically 30-90 seconds after the
>>> unplug happened. It seems that the USB disconnect detection is delayed due
>>> to the CPU load of the TX.
>>> >
>>> > I also sometimes see a kernel panic. That can occur whether connected to a
>>> USB hub or directly to the on-board USB port. See the attached log.
>>> >
>>> > I'm not so familiar with either the Wi-Fi or USB stacks in the Linux
>>> > kernel, so I would appreciate any advice with debugging and fixing
>>> > this. (My previous investigations indicate these issues are present in
>>> > both 3.14.x kernel and 4.4.6 kernel. I'm more familiar with working
>>> > with the 3.14.x kernel under Yocto, but I could try moving to 4.4.6
>>> > kernel for Ubuntu. I'm open to advice on which to investigate on.)
>>>
>>> Take a look at this patch: http://marc.info/?l=linux-
>>> usb=146222355213935=2
>>>
>>> If it fixes your issue please provide your "tested-by" tag here.
>>
>> Hi Yegor,
>>
>> I am using that patch, and I referred to it in my last message. But it 
>> doesn't fix this issue.
>
> Have missed that.
>
> I've made following test with am335x based device and a Ralink
> Technology, Corp. RT5370 Wireless Adapter attached vie USB hub:
>
> root@baltos:~# lsusb -t
>

Re: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Yegor Yefremov 
On Tue, May 10, 2016 at 9:17 AM, Craig McQueen
 wrote:
> Yegor Yefremov wrote:
>> Hi Craig,
>>
>> On Tue, May 10, 2016 at 8:08 AM, Craig McQueen
>>  wrote:
>> > I previously wrote:
>> >> I previously wrote:
>> >> > I previously wrote:
>> >> > >
>> >> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based
>> >> > > (5392 chipset). I've been testing it on a BeagleBone Black
>> >> > > running an Ubuntu
>> >> > > 16.04 image (4.4.6 kernel), with a USB hub.
>> >> > >
>> >> > > When I unplug the Wi-Fi device from the USB hub, and it's
>> >> > > connected to an access point, and then I unplug it, the OS appears to
>> lock up.
>> >> > > I get messages about a soft lockup on the serial console:
>> >> > >
>> >> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> >> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup
>> >> > > -
>> >> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI
>> watchdog:
>> >> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
>> >> > > 9820.136699] NMI
>> >> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> >> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup
>> >> > > -
>> >> CPU#0 stuck for 22s!
>> >> > > [kworker/u2:0:1129]
>> >> > >
>> >> > > This will repeat indefinitely, until I unplug the hub, which
>> >> > > resolves the soft lockup and then the system seems to function
>> normally.
>> >> > >
>> >> > > I've attached a dmesg log of the soft lockup stack traces. They
>> >> > > seem to indicate a lockup in workqueue rt2x00usb_work_rxdone()
>> >> > > (specifically in
>> >> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called
>> >> > > from rt2x00usb_clear_entry()).
>> >> > >
>> >> > > I originally found this bug on a 3.14.x kernel built with Yocto
>> >> > > for a BeagleBone Black-based product. So it seems this is a bug
>> >> > > that has been around for some time.
>> >> >
>> >> > I should also note that on the 3.14.x Yocto-built kernel on
>> >> > BeagleBone Black, this bug does not occur if the rt2800 device is
>> >> > unplugged directly from the BBB's USB port. It only occurs if unplugged
>> from a hub.
>> >> >
>> >> > I have tested this on an i586 based eBox-3310A mini-PC running
>> >> > Debian 8.4, which has a 3.16.0 kernel, with the same hub and same
>> >> > rt2800 device. But I was not able to reproduce this issue.
>> >>
>> >> There is a patch for the AM335x musb driver that seems to fix this:
>> >>
>> >> http://marc.info/?l=linux-usb=146173995117456=2
>> >>
>> >> So it seems that this issue's root cause is in the AM335x USB
>> >> interrupt handling, and not the Wi-Fi rt2800 driver.
>> >
>> > Having applied two AM335x USB patches in the 3.14.49 kernel, that does
>> seem to resolve the soft lock-up on the RX side. The two patches are:
>> >
>> > http://marc.info/?l=linux-usb=146173995117456=2
>> > http://marc.info/?l=linux-usb=146222355213935=2
>> >
>> > But I am finding there is still a lock-up issue when unplugging from a hub,
>> this time on the TX side. It is more likely if there is Wi-Fi traffic in 
>> progress
>> when the unplug occurs. I'm attaching a log. Essentially there are a heap of
>> lines (100 or so per second):
>> >
>> > [ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed:
>> > Warning - TX status read failed -71
>> >
>> > Which finally stop shortly after USB disconnect is detected:
>> >
>> > [ 1866.985854] usb 1-1.3: USB disconnect, device number 10
>> >
>> > However that disconnect message is typically 30-90 seconds after the
>> unplug happened. It seems that the USB disconnect detection is delayed due
>> to the CPU load of the TX.
>> >
>> > I also sometimes see a kernel panic. That can occur whether connected to a
>> USB hub or directly to the on-board USB port. See the attached log.
>> >
>> > I'm not so familiar with either the Wi-Fi or USB stacks in the Linux
>> > kernel, so I would appreciate any advice with debugging and fixing
>> > this. (My previous investigations indicate these issues are present in
>> > both 3.14.x kernel and 4.4.6 kernel. I'm more familiar with working
>> > with the 3.14.x kernel under Yocto, but I could try moving to 4.4.6
>> > kernel for Ubuntu. I'm open to advice on which to investigate on.)
>>
>> Take a look at this patch: http://marc.info/?l=linux-
>> usb=146222355213935=2
>>
>> If it fixes your issue please provide your "tested-by" tag here.
>
> Hi Yegor,
>
> I am using that patch, and I referred to it in my last message. But it 
> doesn't fix this issue.

Have missed that.

I've made following test with am335x based device and a Ralink
Technology, Corp. RT5370 Wireless Adapter attached vie USB hub:

root@baltos:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port

RE: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Craig McQueen 
Yegor Yefremov wrote:
> Hi Craig,
> 
> On Tue, May 10, 2016 at 8:08 AM, Craig McQueen
>  wrote:
> > I previously wrote:
> >> I previously wrote:
> >> > I previously wrote:
> >> > >
> >> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based
> >> > > (5392 chipset). I've been testing it on a BeagleBone Black
> >> > > running an Ubuntu
> >> > > 16.04 image (4.4.6 kernel), with a USB hub.
> >> > >
> >> > > When I unplug the Wi-Fi device from the USB hub, and it's
> >> > > connected to an access point, and then I unplug it, the OS appears to
> lock up.
> >> > > I get messages about a soft lockup on the serial console:
> >> > >
> >> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> >> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup
> >> > > -
> >> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI
> watchdog:
> >> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
> >> > > 9820.136699] NMI
> >> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> >> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup
> >> > > -
> >> CPU#0 stuck for 22s!
> >> > > [kworker/u2:0:1129]
> >> > >
> >> > > This will repeat indefinitely, until I unplug the hub, which
> >> > > resolves the soft lockup and then the system seems to function
> normally.
> >> > >
> >> > > I've attached a dmesg log of the soft lockup stack traces. They
> >> > > seem to indicate a lockup in workqueue rt2x00usb_work_rxdone()
> >> > > (specifically in
> >> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called
> >> > > from rt2x00usb_clear_entry()).
> >> > >
> >> > > I originally found this bug on a 3.14.x kernel built with Yocto
> >> > > for a BeagleBone Black-based product. So it seems this is a bug
> >> > > that has been around for some time.
> >> >
> >> > I should also note that on the 3.14.x Yocto-built kernel on
> >> > BeagleBone Black, this bug does not occur if the rt2800 device is
> >> > unplugged directly from the BBB's USB port. It only occurs if unplugged
> from a hub.
> >> >
> >> > I have tested this on an i586 based eBox-3310A mini-PC running
> >> > Debian 8.4, which has a 3.16.0 kernel, with the same hub and same
> >> > rt2800 device. But I was not able to reproduce this issue.
> >>
> >> There is a patch for the AM335x musb driver that seems to fix this:
> >>
> >> http://marc.info/?l=linux-usb=146173995117456=2
> >>
> >> So it seems that this issue's root cause is in the AM335x USB
> >> interrupt handling, and not the Wi-Fi rt2800 driver.
> >
> > Having applied two AM335x USB patches in the 3.14.49 kernel, that does
> seem to resolve the soft lock-up on the RX side. The two patches are:
> >
> > http://marc.info/?l=linux-usb=146173995117456=2
> > http://marc.info/?l=linux-usb=146222355213935=2
> >
> > But I am finding there is still a lock-up issue when unplugging from a hub,
> this time on the TX side. It is more likely if there is Wi-Fi traffic in 
> progress
> when the unplug occurs. I'm attaching a log. Essentially there are a heap of
> lines (100 or so per second):
> >
> > [ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed:
> > Warning - TX status read failed -71
> >
> > Which finally stop shortly after USB disconnect is detected:
> >
> > [ 1866.985854] usb 1-1.3: USB disconnect, device number 10
> >
> > However that disconnect message is typically 30-90 seconds after the
> unplug happened. It seems that the USB disconnect detection is delayed due
> to the CPU load of the TX.
> >
> > I also sometimes see a kernel panic. That can occur whether connected to a
> USB hub or directly to the on-board USB port. See the attached log.
> >
> > I'm not so familiar with either the Wi-Fi or USB stacks in the Linux
> > kernel, so I would appreciate any advice with debugging and fixing
> > this. (My previous investigations indicate these issues are present in
> > both 3.14.x kernel and 4.4.6 kernel. I'm more familiar with working
> > with the 3.14.x kernel under Yocto, but I could try moving to 4.4.6
> > kernel for Ubuntu. I'm open to advice on which to investigate on.)
> 
> Take a look at this patch: http://marc.info/?l=linux-
> usb=146222355213935=2
> 
> If it fixes your issue please provide your "tested-by" tag here.

Hi Yegor,

I am using that patch, and I referred to it in my last message. But it doesn't 
fix this issue.

Thanks,
Craig McQueen

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Yegor Yefremov 
Hi Craig,

On Tue, May 10, 2016 at 8:08 AM, Craig McQueen
 wrote:
> I previously wrote:
>> I previously wrote:
>> > I previously wrote:
>> > >
>> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
>> > > chipset). I've been testing it on a BeagleBone Black running an
>> > > Ubuntu
>> > > 16.04 image (4.4.6 kernel), with a USB hub.
>> > >
>> > > When I unplug the Wi-Fi device from the USB hub, and it's connected
>> > > to an access point, and then I unplug it, the OS appears to lock up.
>> > > I get messages about a soft lockup on the serial console:
>> > >
>> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup -
>> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI watchdog:
>> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
>> > > 9820.136699] NMI
>> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup -
>> CPU#0 stuck for 22s!
>> > > [kworker/u2:0:1129]
>> > >
>> > > This will repeat indefinitely, until I unplug the hub, which
>> > > resolves the soft lockup and then the system seems to function normally.
>> > >
>> > > I've attached a dmesg log of the soft lockup stack traces. They seem
>> > > to indicate a lockup in workqueue rt2x00usb_work_rxdone()
>> > > (specifically in
>> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called
>> > > from rt2x00usb_clear_entry()).
>> > >
>> > > I originally found this bug on a 3.14.x kernel built with Yocto for
>> > > a BeagleBone Black-based product. So it seems this is a bug that has
>> > > been around for some time.
>> >
>> > I should also note that on the 3.14.x Yocto-built kernel on BeagleBone
>> > Black, this bug does not occur if the rt2800 device is unplugged
>> > directly from the BBB's USB port. It only occurs if unplugged from a hub.
>> >
>> > I have tested this on an i586 based eBox-3310A mini-PC running Debian
>> > 8.4, which has a 3.16.0 kernel, with the same hub and same rt2800
>> > device. But I was not able to reproduce this issue.
>>
>> There is a patch for the AM335x musb driver that seems to fix this:
>>
>> http://marc.info/?l=linux-usb=146173995117456=2
>>
>> So it seems that this issue's root cause is in the AM335x USB interrupt
>> handling, and not the Wi-Fi rt2800 driver.
>
> Having applied two AM335x USB patches in the 3.14.49 kernel, that does seem 
> to resolve the soft lock-up on the RX side. The two patches are:
>
> http://marc.info/?l=linux-usb=146173995117456=2
> http://marc.info/?l=linux-usb=146222355213935=2
>
> But I am finding there is still a lock-up issue when unplugging from a hub, 
> this time on the TX side. It is more likely if there is Wi-Fi traffic in 
> progress when the unplug occurs. I'm attaching a log. Essentially there are a 
> heap of lines (100 or so per second):
>
> [ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed: Warning 
> - TX status read failed -71
>
> Which finally stop shortly after USB disconnect is detected:
>
> [ 1866.985854] usb 1-1.3: USB disconnect, device number 10
>
> However that disconnect message is typically 30-90 seconds after the unplug 
> happened. It seems that the USB disconnect detection is delayed due to the 
> CPU load of the TX.
>
> I also sometimes see a kernel panic. That can occur whether connected to a 
> USB hub or directly to the on-board USB port. See the attached log.
>
> I'm not so familiar with either the Wi-Fi or USB stacks in the Linux kernel, 
> so I would appreciate any advice with debugging and fixing this. (My previous 
> investigations indicate these issues are present in both 3.14.x kernel and 
> 4.4.6 kernel. I'm more familiar with working with the 3.14.x kernel under 
> Yocto, but I could try moving to 4.4.6 kernel for Ubuntu. I'm open to advice 
> on which to investigate on.)

Take a look at this patch: http://marc.info/?l=linux-usb=146222355213935=2

If it fixes your issue please provide your "tested-by" tag here.

Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-10 Thread Craig McQueen 
I previously wrote:
> I previously wrote:
> > I previously wrote:
> > >
> > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> > > chipset). I've been testing it on a BeagleBone Black running an
> > > Ubuntu
> > > 16.04 image (4.4.6 kernel), with a USB hub.
> > >
> > > When I unplug the Wi-Fi device from the USB hub, and it's connected
> > > to an access point, and then I unplug it, the OS appears to lock up.
> > > I get messages about a soft lockup on the serial console:
> > >
> > > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> > > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup -
> > > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI watchdog:
> > > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
> > > 9820.136699] NMI
> > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> > > [kworker/u2:0:1129] [ 9848.136696] NMI watchdog: BUG: soft lockup -
> CPU#0 stuck for 22s!
> > > [kworker/u2:0:1129]
> > >
> > > This will repeat indefinitely, until I unplug the hub, which
> > > resolves the soft lockup and then the system seems to function normally.
> > >
> > > I've attached a dmesg log of the soft lockup stack traces. They seem
> > > to indicate a lockup in workqueue rt2x00usb_work_rxdone()
> > > (specifically in
> > > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called
> > > from rt2x00usb_clear_entry()).
> > >
> > > I originally found this bug on a 3.14.x kernel built with Yocto for
> > > a BeagleBone Black-based product. So it seems this is a bug that has
> > > been around for some time.
> >
> > I should also note that on the 3.14.x Yocto-built kernel on BeagleBone
> > Black, this bug does not occur if the rt2800 device is unplugged
> > directly from the BBB's USB port. It only occurs if unplugged from a hub.
> >
> > I have tested this on an i586 based eBox-3310A mini-PC running Debian
> > 8.4, which has a 3.16.0 kernel, with the same hub and same rt2800
> > device. But I was not able to reproduce this issue.
> 
> There is a patch for the AM335x musb driver that seems to fix this:
> 
> http://marc.info/?l=linux-usb=146173995117456=2
> 
> So it seems that this issue's root cause is in the AM335x USB interrupt
> handling, and not the Wi-Fi rt2800 driver.

Having applied two AM335x USB patches in the 3.14.49 kernel, that does seem to 
resolve the soft lock-up on the RX side. The two patches are:

http://marc.info/?l=linux-usb=146173995117456=2
http://marc.info/?l=linux-usb=146222355213935=2

But I am finding there is still a lock-up issue when unplugging from a hub, 
this time on the TX side. It is more likely if there is Wi-Fi traffic in 
progress when the unplug occurs. I'm attaching a log. Essentially there are a 
heap of lines (100 or so per second):

[ 1866.693511] ieee80211 phy7: rt2800usb_tx_sta_fifo_read_completed: Warning - 
TX status read failed -71

Which finally stop shortly after USB disconnect is detected:

[ 1866.985854] usb 1-1.3: USB disconnect, device number 10

However that disconnect message is typically 30-90 seconds after the unplug 
happened. It seems that the USB disconnect detection is delayed due to the CPU 
load of the TX.

I also sometimes see a kernel panic. That can occur whether connected to a USB 
hub or directly to the on-board USB port. See the attached log.

I'm not so familiar with either the Wi-Fi or USB stacks in the Linux kernel, so 
I would appreciate any advice with debugging and fixing this. (My previous 
investigations indicate these issues are present in both 3.14.x kernel and 
4.4.6 kernel. I'm more familiar with working with the 3.14.x kernel under 
Yocto, but I could try moving to 4.4.6 kernel for Ubuntu. I'm open to advice on 
which to investigate on.)

-- 
Craig McQueen



2016-05-10_rt2800_lockup_hub.tar.gz
Description: 2016-05-10_rt2800_lockup_hub.tar.gz

RE: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-05-01 Thread Craig McQueen 
I previously wrote:
> I previously wrote:
> >
> > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> > chipset). I've been testing it on a BeagleBone Black running an Ubuntu
> > 16.04 image (4.4.6 kernel), with a USB hub.
> >
> > When I unplug the Wi-Fi device from the USB hub, and it's connected to
> > an access point, and then I unplug it, the OS appears to lock up. I
> > get messages about a soft lockup on the serial console:
> >
> > [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> > [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup -
> > CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI watchdog:
> > BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
> > 9820.136699] NMI
> > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129]
> > [ 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> > [kworker/u2:0:1129]
> >
> > This will repeat indefinitely, until I unplug the hub, which resolves
> > the soft lockup and then the system seems to function normally.
> >
> > I've attached a dmesg log of the soft lockup stack traces. They seem
> > to indicate a lockup in workqueue rt2x00usb_work_rxdone()
> > (specifically in
> > usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called from
> > rt2x00usb_clear_entry()).
> >
> > I originally found this bug on a 3.14.x kernel built with Yocto for a
> > BeagleBone Black-based product. So it seems this is a bug that has
> > been around for some time.
> 
> I should also note that on the 3.14.x Yocto-built kernel on BeagleBone Black,
> this bug does not occur if the rt2800 device is unplugged directly from the
> BBB's USB port. It only occurs if unplugged from a hub.
> 
> I have tested this on an i586 based eBox-3310A mini-PC running Debian 8.4,
> which has a 3.16.0 kernel, with the same hub and same rt2800 device. But I
> was not able to reproduce this issue.

There is a patch for the AM335x musb driver that seems to fix this:

http://marc.info/?l=linux-usb=146173995117456=2

So it seems that this issue's root cause is in the AM335x USB interrupt 
handling, and not the Wi-Fi rt2800 driver.

-- 
Craig McQueen

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-04-27 Thread Craig McQueen 
I previously wrote:
> 
> I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04
> image (4.4.6 kernel), with a USB hub.
> 
> When I unplug the Wi-Fi device from the USB hub, and it's connected to an
> access point, and then I unplug it, the OS appears to lock up. I get messages
> about a soft lockup on the serial console:
> 
> [ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> [kworker/u2:0:1129] [ 9764.136701] NMI watchdog: BUG: soft lockup - CPU#0
> stuck for 22s! [kworker/u2:0:1129] [ 9792.136701] NMI watchdog: BUG: soft
> lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [ 9820.136699] NMI
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:1129] [
> 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> [kworker/u2:0:1129]
> 
> This will repeat indefinitely, until I unplug the hub, which resolves the soft
> lockup and then the system seems to function normally.
> 
> I've attached a dmesg log of the soft lockup stack traces. They seem to
> indicate a lockup in workqueue rt2x00usb_work_rxdone() (specifically in
> usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called from
> rt2x00usb_clear_entry()).
> 
> I originally found this bug on a 3.14.x kernel built with Yocto for a 
> BeagleBone
> Black-based product. So it seems this is a bug that has been around for some
> time.

I should also note that on the 3.14.x Yocto-built kernel on BeagleBone Black, 
this bug does not occur if the rt2800 device is unplugged directly from the 
BBB's USB port. It only occurs if unplugged from a hub.

I have tested this on an i586 based eBox-3310A mini-PC running Debian 8.4, 
which has a 3.16.0 kernel, with the same hub and same rt2800 device. But I was 
not able to reproduce this issue.

-- 
Craig McQueen

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

2016-04-26 Thread Craig McQueen 
I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 chipset). 
I've been testing it on a BeagleBone Black running an Ubuntu 16.04 image (4.4.6 
kernel), with a USB hub.

When I unplug the Wi-Fi device from the USB hub, and it's connected to an 
access point, and then I unplug it, the OS appears to lock up. I get messages 
about a soft lockup on the serial console:

[ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9764.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9792.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9820.136699] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]

This will repeat indefinitely, until I unplug the hub, which resolves the soft 
lockup and then the system seems to function normally.

I've attached a dmesg log of the soft lockup stack traces. They seem to 
indicate a lockup in workqueue rt2x00usb_work_rxdone() (specifically in 
usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called from 
rt2x00usb_clear_entry()).

I originally found this bug on a 3.14.x kernel built with Yocto for a 
BeagleBone Black-based product. So it seems this is a bug that has been around 
for some time.

-- 
Craig McQueen

[ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9764.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9792.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9820.136699] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9852.998151] cpts: unable to obtain a time stamp

craigm@beaglebone-craig:~$ dmesg
...
[ 9366.664797] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[ 9366.796197] usb 1-1: New USB device found, idVendor=2109, idProduct=2812
[ 9366.796248] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9366.796279] usb 1-1: Product: USB2.0 Hub 
[ 9366.796308] usb 1-1: Manufacturer: VIA Labs, Inc. 
[ 9366.809649] hub 1-1:1.0: USB hub found
[ 9366.813937] hub 1-1:1.0: 4 ports detected
[ 9371.836876] usb 1-1.1: new high-speed USB device number 5 using musb-hdrc
[ 9371.953209] usb 1-1.1: New USB device found, idVendor=2001, idProduct=3c20
[ 9371.953259] usb 1-1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 9371.953291] usb 1-1.1: Product: 802.11 n WLAN
[ 9371.953319] usb 1-1.1: Manufacturer: Ralink
[ 9371.953348] usb 1-1.1: SerialNumber: 1.0
[ 9373.264832] usb 1-1.1: reset high-speed USB device number 5 using musb-hdrc
[ 9373.374188] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 
detected
[ 9373.391020] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 5372 detected
[ 9373.402442] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 9373.427413] usbcore: registered new interface driver rt2800usb
[ 9373.572855] rt2800usb 1-1.1:1.0 wlx9cd64384611d: renamed from wlan0
[ 9373.920791] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt2870.bin'
[ 9373.922515] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware 
detected - version: 0.29
[ 9374.076725] IPv6: ADDRCONF(NETDEV_UP): wlx9cd64384611d: link is not ready
[ 9382.591520] wlx9cd64384611d: authenticate with e8:94:f6:5a:95:9a
[ 9382.629936] wlx9cd64384611d: send auth to e8:94:f6:5a:95:9a (try 1/3)
[ 9382.631970] wlx9cd64384611d: authenticated
[ 9382.644913] wlx9cd64384611d: associate with e8:94:f6:5a:95:9a (try 1/3)
[ 9382.647039] wlx9cd64384611d: RX AssocResp from e8:94:f6:5a:95:9a 
(capab=0x411 status=0 aid=1)
[ 9382.656390] wlx9cd64384611d: associated
[ 9382.656516] IPv6: ADDRCONF(NETDEV_CHANGE): wlx9cd64384611d: link becomes 
ready
[ 9708.136709] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9708.144990] Modules linked in: rt2800usb rt2800lib rt2x00usb rt2x00lib 
crc_ccitt ccm arc4 rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211 
rfkill snd_soc_simple_card omap_sham omap_aes usb_f_ecm g_ether usb_f_rndis 
u_ether libcomposite omap_rng rng_core snd_soc_davinci_mcasp snd_soc_edma 
snd_soc_omap spi_omap2_mcspi snd_soc_hdmi_codec snd_soc_core snd_pcm_dmaengine 
snd_pcm snd_timer snd soundcore evdev uio_pdrv_genirq uio tilcdc tda998x
[ 9708.145353] CPU: 0 PID: 1129 Comm: kworker/u2:0 Not tainted 4.4.6-ti-r15 #1
[ 9708.145379] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 9708.145477] Workqueue: phy1 rt2x00usb_work_rxdone [rt2x00usb]
[ 9708.145508] task: ddbb5b00 ti: ddf48000 task.ti: ddf48000
[ 9708.145556] PC is at v7_dma_inv_range+0x36/0x40
[ 9708.145585] LR is at __dma_page_cpu_to_dev+0x21/0x74
[ 9708.145614] pc : []lr : []psr: 800e0033
   sp : ddf49d10