lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 4 Apr 2014 16:13:21 +0200 From: Stanislaw Gruszka <sgruszka@...hat.com> To: Richard Genoud <richard.genoud@...il.com> Cc: Ivo van Doorn <IvDoorn@...il.com>, Gertjan van Wingerde <gwingerde@...il.com>, Helmut Schaa <helmut.schaa@...glemail.com>, "John W. Linville" <linville@...driver.com>, linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] rt2x00: Endless loop on hub port power down 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists