| Message ID | 1396536536-26423-1-git-send-email-richard.genoud@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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(+)