Re: [PATCH 4/4] Revert rt2x00: Endless loop on hub port power down
On 26/11/2014 15:29, Stanislaw Gruszka wrote: This reverts commit 2ad69ac5976191e9bb7dc4044204a504653ad1bb. It causes wireless device disappear when we get -EPROTO error form USB request. I encounter such situation occasionally when resume form suspend with RT3070 adapter: [ 289.619985] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 [ 289.639368] ieee80211 phy0: rt2800_wait_bbp_ready: Error - BBP register access failed, aborting [ 289.639374] ieee80211 phy0: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5) Without the patch, except printing error, device works just fine after resume. Currently after timeouts and REGISTER_BUSY_COUNT tuning, we should not have any endless loop, though we can wait quite long when driver is trying to communicate with the device through non functioning USB connection. Generally the problem that commit 2ad69ac597619 solves is kinda artificial. Cc: Richard Genoud richard.gen...@gmail.com Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com --- drivers/net/wireless/rt2x00/rt2x00usb.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c index c2346f8..892270d 100644 --- a/drivers/net/wireless/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/rt2x00/rt2x00usb.c @@ -64,12 +64,6 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev, } } while (time_before(jiffies, expire)); - /* 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); It tested this serie but unfortunately, reverting this still caused an infinite loop. (cf https://lkml.org/lkml/2014/4/3/492 to reproduce) [ 642.007812] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.023437] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.031250] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.046875] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.054687] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.062500] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.078125] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.085937] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.101562] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.117187] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.125000] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 0 [ 642.132812] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.25] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1700 with error -71 [ 642.359375] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71 [ 642.468750] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71 [ 642.476562] ieee80211 phy0: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick [ 642.585937] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.695312] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.718750] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.734375] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.742187] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.757812] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.765625] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.773437] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.789062] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.796875] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [ 642.812500]
Re: [PATCH 4/4] Revert rt2x00: Endless loop on hub port power down
On Tue, Dec 02, 2014 at 12:17:57PM +0100, Richard Genoud wrote: It tested this serie but unfortunately, reverting this still caused an infinite loop. (cf https://lkml.org/lkml/2014/4/3/492 to reproduce) It is possible to disable internal hub? It fails here, but perhaps I do not have compiled proper options in the kernel: [stasiu@localhost Downloads]$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 4, If 1, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 4, If 2, Class=Vendor Specific Class, Driver=, 12M |__ Port 4: Dev 4, If 3, Class=Application Specific Interface, Driver=, 12M |__ Port 6: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=rt2800usb, 480M |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M [stasiu@localhost Downloads]$ sudo ./hub-ctrl -b 1 -d 1 -P 1 -p 0 Device not found. [stasiu@localhost Downloads]$ sudo ./hub-ctrl -b 1 -d 2 -P 2 -p 0 Device not found. [ 642.476562] ieee80211 phy0: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick [ 642.585937] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.695312] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.796875] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [...] So it seems the forced kick is not done Forced kick does not mean to remove device, it means restarting hardware queue. It is not done, because it requires write to PBF_CFG register (0x0408), which is not possible. I do not see an infinite loop. What I can see is continues failures when sending requests to to the hardware. I consider this as proper behaviour, taking that USB layer continuously return -EPROTO error. If for example there will be not possible to down interface or remove rt2800usb module in such condition, I would consider this as a minor bug, but I'm not sure if that happen or not. Stanislaw -- 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: [PATCH 4/4] Revert rt2x00: Endless loop on hub port power down
2014-12-02 13:15 GMT+01:00 Stanislaw Gruszka sgrus...@redhat.com: On Tue, Dec 02, 2014 at 12:17:57PM +0100, Richard Genoud wrote: It tested this serie but unfortunately, reverting this still caused an infinite loop. (cf https://lkml.org/lkml/2014/4/3/492 to reproduce) It is possible to disable internal hub? It fails here, but perhaps I do not have compiled proper options in the kernel: [stasiu@localhost Downloads]$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 4, If 1, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 4, If 2, Class=Vendor Specific Class, Driver=, 12M |__ Port 4: Dev 4, If 3, Class=Application Specific Interface, Driver=, 12M |__ Port 6: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=rt2800usb, 480M |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M [stasiu@localhost Downloads]$ sudo ./hub-ctrl -b 1 -d 1 -P 1 -p 0 Device not found. [stasiu@localhost Downloads]$ sudo ./hub-ctrl -b 1 -d 2 -P 2 -p 0 Device not found. I've just tried on my machine, and it doesn't work on root_hub. root@lnx-rg:~$ lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 3: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 4: Dev 4, If 0, Class=vend., Driver=ftdi_sio, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 4: Dev 2, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 5: Dev 10, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 11, If 0, Class=vend., Driver=rt2800usb, 480M |__ Port 6: Dev 12, If 0, Class=vend., Driver=rt2800usb, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M root@lnx-rg:~$ /home/rgenoud/bin/hub-ctrl -b 7 -d 1 -P 6 -p 0 Device not found. but with an external hub: (not every usb hubs have individual port power management) root@lnx-rg:~$ lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 3: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 4: Dev 4, If 0, Class=vend., Driver=ftdi_sio, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 4: Dev 2, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 5: Dev 10, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 11, If 0, Class=vend., Driver=rt2800usb, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M root@lnx-rg:~$ /home/rgenoud/bin/hub-ctrl -b 7 -d 10 -P 1 -p 0 [ 642.476562] ieee80211 phy0: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick [ 642.585937] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.695312] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0408 with error -71 [ 642.796875] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 [...] So it seems the forced kick is not done Forced kick does not mean to remove device, it means restarting hardware queue. It is not done, because it requires write to PBF_CFG register (0x0408), which is not possible. I do not see an infinite loop. What I can see is continues failures when sending requests to to the hardware. I consider this as proper behaviour, taking that USB layer continuously return -EPROTO error. If for example there will be not possible to down interface or remove rt2800usb module in such condition, I would consider this as
