[PATCH] rt2x00: Endless loop on hub port power down

[PATCH] rt2x00: Endless loop on hub port power down

[Richard Genoud]

I've met an endless (or at least very long) loop if I power down the usb
port on witch a usb wifi key is plugged.
(Ok, it's not very smart to power down a usb port when a usb key is in
used... but still, I think that should not lead to an endless loop).

I have a lot of:
ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71

(-71==-EPROTO)

How to reproduce:
- plug an usb wifi key
- ip link set wlan0 up
- hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0

hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c

The following patch prevents the endless loop, but I'm really not sure
that The Right Way To Do It (R)

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
 drivers/net/wireless/rt2x00/rt2x00usb.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 14142b099019..6bf4067ebf63 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -68,6 +68,12 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
 		}
 	}
 
+	/* If the port is powered down, we get a -EPROTO error, and this
+	 * leads to a endless loop. So just say that the device is gone.
+	 */
+	if (status == -EPROTO)
+		clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
+
 	rt2x00_err(rt2x00dev,
 		   "Vendor Request 0x%02x failed for offset 0x%04x with error %d\n",
 		   request, offset, status);
-- 
1.8.5.5

Re: [PATCH] rt2x00: Endless loop on hub port power down

[Stanislaw Gruszka]

On Thu, Apr 03, 2014 at 04:48:56PM +0200, Richard Genoud wrote:
> I've met an endless (or at least very long) loop if I power down the usb
> port on witch a usb wifi key is plugged.
> (Ok, it's not very smart to power down a usb port when a usb key is in
> used... but still, I think that should not lead to an endless loop).
>
> I have a lot of:
> ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71
> 
> (-71==-EPROTO)
> 
> How to reproduce:
> - plug an usb wifi key
> - ip link set wlan0 up
> - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0
> 
> hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c
> 
> The following patch prevents the endless loop, but I'm really not sure
> that The Right Way To Do It (R)

If device disappear, we should get -ENODEV status, why we get -EPROTO ?

Stanislaw

Re: [PATCH] rt2x00: Endless loop on hub port power down

[Richard Genoud]

On 04/04/2014 10:04, Stanislaw Gruszka wrote:
> On Thu, Apr 03, 2014 at 04:48:56PM +0200, Richard Genoud wrote:
>> I've met an endless (or at least very long) loop if I power down the usb
>> port on witch a usb wifi key is plugged.
>> (Ok, it's not very smart to power down a usb port when a usb key is in
>> used... but still, I think that should not lead to an endless loop).
>>
>> I have a lot of:
>> ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71
>>
>> (-71==-EPROTO)
>>
>> How to reproduce:
>> - plug an usb wifi key
>> - ip link set wlan0 up
>> - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0
>>
>> hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c
>>
>> The following patch prevents the endless loop, but I'm really not sure
>> that The Right Way To Do It (R)
> 
> If device disappear, we should get -ENODEV status, why we get -EPROTO ?

I trace it down, and the EPROTO status comes from ctx.status (returned from usb_start_wait_urb() in drivers/usb/core/message.c)
And, in my case, the ctx.status is set to EPROTO in qtd_copy_status() ( drivers/usb/host/ehci-q.c )
in the code:
} else if (token & QTD_STS_XACT) {
	/* timeout, bad CRC, wrong PID, etc */
	ehci_dbg(ehci, "devpath %s ep%d%s 3strikes\n",
		urb->dev->devpath,
		usb_pipeendpoint(urb->pipe),
		usb_pipein(urb->pipe) ? "in" : "out");
	status = -EPROTO;

enabling this log, I get:
atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71

Re: [PATCH] rt2x00: Endless loop on hub port power down

[Stanislaw Gruszka]

On Fri, Apr 04, 2014 at 11:58:26AM +0200, Richard Genoud wrote:
> On 04/04/2014 10:04, Stanislaw Gruszka wrote:
> > On Thu, Apr 03, 2014 at 04:48:56PM +0200, Richard Genoud wrote:
> >> I've met an endless (or at least very long) loop if I power down the usb
> >> port on witch a usb wifi key is plugged.
> >> (Ok, it's not very smart to power down a usb port when a usb key is in
> >> used... but still, I think that should not lead to an endless loop).
> >>
> >> I have a lot of:
> >> ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71
> >>
> >> (-71==-EPROTO)
> >>
> >> How to reproduce:
> >> - plug an usb wifi key
> >> - ip link set wlan0 up
> >> - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0
> >>
> >> hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c
> >>
> >> The following patch prevents the endless loop, but I'm really not sure
> >> that The Right Way To Do It (R)
> > 
> > If device disappear, we should get -ENODEV status, why we get -EPROTO ?
> 
> I trace it down, and the EPROTO status comes from ctx.status (returned from usb_start_wait_urb() in drivers/usb/core/message.c)
> And, in my case, the ctx.status is set to EPROTO in qtd_copy_status() ( drivers/usb/host/ehci-q.c )
> in the code:
> } else if (token & QTD_STS_XACT) {
> 	/* timeout, bad CRC, wrong PID, etc */
> 	ehci_dbg(ehci, "devpath %s ep%d%s 3strikes\n",
> 		urb->dev->devpath,
> 		usb_pipeendpoint(urb->pipe),
> 		usb_pipein(urb->pipe) ? "in" : "out");
> 	status = -EPROTO;
> 
> enabling this log, I get:
> atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
> atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
> atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
> atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
> ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71

Thanks, ehci driver behaviour seems to be fine. Could you check if updating
rt2800 firmware (I assume you have some RT2800 usb dongle) change the situation,
i.e. we stop getting -EPROTO errors. To install new firmware, you can download
rt2870.bin blob from:
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-January/005610.html
and need to replace /lib/firmware/rt2870.bin file.

Stanislaw

Re: [PATCH] rt2x00: Endless loop on hub port power down

[Richard Genoud]

2014-04-04 16:13 GMT+02:00 Stanislaw Gruszka <sgruszka@redhat.com>:
> On Fri, Apr 04, 2014 at 11:58:26AM +0200, Richard Genoud wrote:
>> On 04/04/2014 10:04, Stanislaw Gruszka wrote:
>> > On Thu, Apr 03, 2014 at 04:48:56PM +0200, Richard Genoud wrote:
>> >> I've met an endless (or at least very long) loop if I power down the usb
>> >> port on witch a usb wifi key is plugged.
>> >> (Ok, it's not very smart to power down a usb port when a usb key is in
>> >> used... but still, I think that should not lead to an endless loop).
>> >>
>> >> I have a lot of:
>> >> ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71
>> >>
>> >> (-71==-EPROTO)
>> >>
>> >> How to reproduce:
>> >> - plug an usb wifi key
>> >> - ip link set wlan0 up
>> >> - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0
>> >>
>> >> hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c
>> >>
>> >> The following patch prevents the endless loop, but I'm really not sure
>> >> that The Right Way To Do It (R)
>> >
>> > If device disappear, we should get -ENODEV status, why we get -EPROTO ?
>>
>> I trace it down, and the EPROTO status comes from ctx.status (returned from usb_start_wait_urb() in drivers/usb/core/message.c)
>> And, in my case, the ctx.status is set to EPROTO in qtd_copy_status() ( drivers/usb/host/ehci-q.c )
>> in the code:
>> } else if (token & QTD_STS_XACT) {
>>       /* timeout, bad CRC, wrong PID, etc */
>>       ehci_dbg(ehci, "devpath %s ep%d%s 3strikes\n",
>>               urb->dev->devpath,
>>               usb_pipeendpoint(urb->pipe),
>>               usb_pipein(urb->pipe) ? "in" : "out");
>>       status = -EPROTO;
>>
>> enabling this log, I get:
>> atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
>> atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
>> atmel-ehci 700000.ehci: devpath 2.1 ep1in 3strikes
>> atmel-ehci 700000.ehci: devpath 2.1 ep0in 3strikes
>> ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71
>
> Thanks, ehci driver behaviour seems to be fine. Could you check if updating
> rt2800 firmware (I assume you have some RT2800 usb dongle) change the situation,
> i.e. we stop getting -EPROTO errors. To install new firmware, you can download
> rt2870.bin blob from:
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-January/005610.html
> and need to replace /lib/firmware/rt2870.bin file.
>
> Stanislaw
It's the same behaviour:

dmesg | grep firm
[   13.648437] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Loading firmware file 'rt2870.bin'
[   13.656250] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Firmware detected - version: 0.33
# disable_usb_port 1
# [   31.398437] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x07 failed for offset 0x1700 with error -71
[   31.804687] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x07 failed for offset 0x0438 with error -71
[   32.226562] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x07 failed for offset 0x0438 with error -71
[   32.640625] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x06 failed for offset 0x0408 with error -71
[   33.062500] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x06 failed for offset 0x0408 with error -71
[   33.617187] ieee80211 phy0: rt2x00usb_vendor_request: Error -
Vendor Request 0x07 failed for offset 0x1700 with error -71