* Re: FUSB200 xhci issue [not found] <51ED4E12.8030006@rempel-privat.de> @ 2013-07-22 19:54 ` Christian Lamparter 2013-07-22 20:47 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-22 19:54 UTC (permalink / raw) To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee Hello! On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: > i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of > this adapters. Looks like ar9271 and ar7010 have FUSB200, and i > accidentally discovered that 9170 have it too. Are there any issue with > usb-suspend + xhci controllers by you? Did you some how specially > handled it? No, I haven't heard any complains about xhci + suspend. In fact, it's working fine with the NEC xhci I have. I also have a AR9271 and AR7010, so if you want I could try if they survive a suspend +resume cycle when attached. But, I do have a bug-report from someone else who has/had? problems with carl9170 and xhci. If you want, you can get the details from: "carl9170 A-MPDU transmit problem": <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> The likely cause is related to Intel's xhci silicon (Ivy Bridge is affected, but I don't know about Haswell): <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> However, I haven't heard back from Sarah or Seth about this matter (Added them to the CC. so "PLEASE" join if either of you think to have something to add about carl9170 transmit problem or ath9k_htc's suspend issue... of course, if it was fixed, then it would be really great to know which commit "fixed it"...) Regards Christian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-22 19:54 ` FUSB200 xhci issue Christian Lamparter @ 2013-07-22 20:47 ` Oleksij Rempel 2013-07-22 21:23 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-22 20:47 UTC (permalink / raw) To: Christian Lamparter; +Cc: linux-wireless, Sarah Sharp, Seth Forshee Am 22.07.2013 21:54, schrieb Christian Lamparter: > Hello! > > On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: >> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of >> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i >> accidentally discovered that 9170 have it too. Are there any issue with >> usb-suspend + xhci controllers by you? Did you some how specially >> handled it? > > No, I haven't heard any complains about xhci + suspend. In fact, > it's working fine with the NEC xhci I have. I also have a AR9271 > and AR7010, so if you want I could try if they survive a suspend > +resume cycle when attached. > > But, I do have a bug-report from someone else who has/had? problems > with carl9170 and xhci. If you want, you can get the details from: > "carl9170 A-MPDU transmit problem": > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> > > The likely cause is related to Intel's xhci silicon (Ivy Bridge is > affected, but I don't know about Haswell): > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> Same situation is here - i have problem on Ivy Bridge. Steps to reproduce: - plug adapter. Module and firmware will be loaded - make sure usb autosupend is enabled. By default it is not! Use powertop or directly sysfs to enable autosuspend for this device - rmmod .... and wait some seconds until adapter is suspended and then modprobe ath9k_htc first packet which is bigger as 64Byte will kill EP4 FIFO. Size register will report wrong size.. bigger as FIFO can handle. And only first ~40 readet bytes will be actually OK.. all the rest of packet will be trashed. But... i'm not 100% sure, if the FIFO as actually over filled, or host controller sending brocken data, or wrong timing... There are flawing workarounds: - reload xhci_hcd module. - do USB_PHY reset, from firmware. - use other host controller It will be good if you can test it on you NEX xhci. > > However, I haven't heard back from Sarah or Seth about this matter > (Added them to the CC. so "PLEASE" join if either of you think to > have something to add about carl9170 transmit problem or ath9k_htc's > suspend issue... of course, if it was fixed, then it would be really > great to know which commit "fixed it"...) > > Regards > > Christian -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-22 20:47 ` Oleksij Rempel @ 2013-07-22 21:23 ` Christian Lamparter 2013-07-23 4:59 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-22 21:23 UTC (permalink / raw) To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: > Am 22.07.2013 21:54, schrieb Christian Lamparter: > > Hello! > > > > On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: > >> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of > >> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i > >> accidentally discovered that 9170 have it too. Are there any issue with > >> usb-suspend + xhci controllers by you? Did you some how specially > >> handled it? > > > > No, I haven't heard any complains about xhci + suspend. In fact, > > it's working fine with the NEC xhci I have. I also have a AR9271 > > and AR7010, so if you want I could try if they survive a suspend > > +resume cycle when attached. > > > > But, I do have a bug-report from someone else who has/had? problems > > with carl9170 and xhci. If you want, you can get the details from: > > "carl9170 A-MPDU transmit problem": > > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> > > > > The likely cause is related to Intel's xhci silicon (Ivy Bridge is > > affected, but I don't know about Haswell): > > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> > > Same situation is here - i have problem on Ivy Bridge. (Note: I don't have any Ivy Bridge system. Just Sandy Bridge and AMD's new A6-1450 Temash and both xhci work. So I can't do any proper comparisons like you.) > Steps to reproduce: > - plug adapter. Module and firmware will be loaded > - make sure usb autosupend is enabled. By default it is not! Use > powertop or directly sysfs to enable autosuspend for this device > - rmmod .... and wait some seconds until adapter is suspended and then > modprobe ath9k_htc > > first packet which is bigger as 64Byte will kill EP4 FIFO. Size register > will report wrong size.. bigger as FIFO can handle. And only first ~40 > readet bytes will be actually OK.. all the rest of packet will be trashed. This is what happens with a WN721 (ar9271): [17619.597905] usbcore: deregistering interface driver ath9k_htc [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized [17619.679602] ath9k_htc: Driver unloaded <suspend> <resume> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested [17667.573873] usbcore: registered new interface driver ath9k_htc [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits The driver loads, but there's no "wlanX" interface, no phyX interface and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". Regards Christian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-22 21:23 ` Christian Lamparter @ 2013-07-23 4:59 ` Oleksij Rempel 2013-07-23 18:26 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-23 4:59 UTC (permalink / raw) To: Christian Lamparter; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list Am 22.07.2013 23:23, schrieb Christian Lamparter: > On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: >> Am 22.07.2013 21:54, schrieb Christian Lamparter: >>> Hello! >>> >>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: >>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of >>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i >>>> accidentally discovered that 9170 have it too. Are there any issue with >>>> usb-suspend + xhci controllers by you? Did you some how specially >>>> handled it? >>> >>> No, I haven't heard any complains about xhci + suspend. In fact, >>> it's working fine with the NEC xhci I have. I also have a AR9271 >>> and AR7010, so if you want I could try if they survive a suspend >>> +resume cycle when attached. >>> >>> But, I do have a bug-report from someone else who has/had? problems >>> with carl9170 and xhci. If you want, you can get the details from: >>> "carl9170 A-MPDU transmit problem": >>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> >>> >>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is >>> affected, but I don't know about Haswell): >>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> >> >> Same situation is here - i have problem on Ivy Bridge. > (Note: I don't have any Ivy Bridge system. Just Sandy Bridge > and AMD's new A6-1450 Temash and both xhci work. So I can't > do any proper comparisons like you.) > >> Steps to reproduce: >> - plug adapter. Module and firmware will be loaded >> - make sure usb autosupend is enabled. By default it is not! Use >> powertop or directly sysfs to enable autosuspend for this device >> - rmmod .... and wait some seconds until adapter is suspended and then >> modprobe ath9k_htc >> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register >> will report wrong size.. bigger as FIFO can handle. And only first ~40 >> readet bytes will be actually OK.. all the rest of packet will be trashed. > > This is what happens with a WN721 (ar9271): > > [17619.597905] usbcore: deregistering interface driver ath9k_htc > [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized > [17619.679602] ath9k_htc: Driver unloaded > <suspend> > > <resume> > [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- > [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 > [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 > [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 > [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 > [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 > [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 > [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested > [17667.573873] usbcore: registered new interface driver ath9k_htc > [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 > [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits > > The driver loads, but there's no "wlanX" interface, no phyX interface > and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". So, it is exactly this bug. After firmware was loaded ath9k trying to set some registers. Since command buffer is trashed it will write some nonsense to registers and some times in wrong to wrong addresses. I have some patches to do crc check of commands, to easy detect corrupted ones. You reproduced it on NEC xhci? Is it possible to reproduce it in carl9170? How about "carl9170 A-MPDU transmit problem"? I noticed one more workaround. By reducing skb size to 64byte for EP4, this bug can be avoided. But, since it works on EHCI, and on XHCI before usb-suspend, i would prefer to fix host controller driver. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-23 4:59 ` Oleksij Rempel @ 2013-07-23 18:26 ` Christian Lamparter 2013-07-24 10:37 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-23 18:26 UTC (permalink / raw) To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote: > Am 22.07.2013 23:23, schrieb Christian Lamparter: > > On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: > >> Am 22.07.2013 21:54, schrieb Christian Lamparter: > >>> Hello! > >>> > >>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: > >>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of > >>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i > >>>> accidentally discovered that 9170 have it too. Are there any issue with > >>>> usb-suspend + xhci controllers by you? Did you some how specially > >>>> handled it? > >>> > >>> No, I haven't heard any complains about xhci + suspend. In fact, > >>> it's working fine with the NEC xhci I have. I also have a AR9271 > >>> and AR7010, so if you want I could try if they survive a suspend > >>> +resume cycle when attached. > >>> > >>> But, I do have a bug-report from someone else who has/had? problems > >>> with carl9170 and xhci. If you want, you can get the details from: > >>> "carl9170 A-MPDU transmit problem": > >>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> > >>> > >>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is > >>> affected, but I don't know about Haswell): > >>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> > >> > >> Same situation is here - i have problem on Ivy Bridge. > > (Note: I don't have any Ivy Bridge system. Just Sandy Bridge > > and AMD's new A6-1450 Temash and both xhci work. So I can't > > do any proper comparisons like you.) > > > >> Steps to reproduce: > >> - plug adapter. Module and firmware will be loaded > >> - make sure usb autosupend is enabled. By default it is not! Use > >> powertop or directly sysfs to enable autosuspend for this device > >> - rmmod .... and wait some seconds until adapter is suspended and then > >> modprobe ath9k_htc > > >> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register > >> will report wrong size.. bigger as FIFO can handle. And only first ~40 > >> readet bytes will be actually OK.. all the rest of packet will be trashed. > > > > This is what happens with a WN721 (ar9271): > > > > [17619.597905] usbcore: deregistering interface driver ath9k_htc > > [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized > > [17619.679602] ath9k_htc: Driver unloaded > > <suspend> > > > > <resume> > > [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- > > [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 > > [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 > > [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 > > [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 > > [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 > > [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 > > [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested > > [17667.573873] usbcore: registered new interface driver ath9k_htc > > [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 > > [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits > > > > The driver loads, but there's no "wlanX" interface, no phyX interface > > and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". > > So, it is exactly this bug. > After firmware was loaded ath9k trying to set some registers. Since > command buffer is trashed it will write some nonsense to registers and > some times in wrong to wrong addresses. I have some patches to do crc > check of commands, to easy detect corrupted ones. > > You reproduced it on NEC xhci? Is it possible to reproduce it in > carl9170? Ok: That's dmesg of your scenario: [ 809.995966] usbcore: deregistering interface driver carl9170 <suspend> <resume> [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900 [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940 [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980 [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0 [ 826.432257] usbcore: registered new interface driver carl9170 [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1] ... [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3' carl9170 is able to recover and the stick is working after autosuspend cycle. > How about "carl9170 A-MPDU transmit problem"? This was already isolated. The "AMPDU transmit problem" only happens with Ivy Bridge's xhci. Regards Christian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-23 18:26 ` Christian Lamparter @ 2013-07-24 10:37 ` Oleksij Rempel 2013-07-27 21:59 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-24 10:37 UTC (permalink / raw) To: Christian Lamparter; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list Am 23.07.2013 20:26, schrieb Christian Lamparter: > On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote: >> Am 22.07.2013 23:23, schrieb Christian Lamparter: >>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: >>>> Am 22.07.2013 21:54, schrieb Christian Lamparter: >>>>> Hello! >>>>> >>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: >>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of >>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i >>>>>> accidentally discovered that 9170 have it too. Are there any issue with >>>>>> usb-suspend + xhci controllers by you? Did you some how specially >>>>>> handled it? >>>>> >>>>> No, I haven't heard any complains about xhci + suspend. In fact, >>>>> it's working fine with the NEC xhci I have. I also have a AR9271 >>>>> and AR7010, so if you want I could try if they survive a suspend >>>>> +resume cycle when attached. >>>>> >>>>> But, I do have a bug-report from someone else who has/had? problems >>>>> with carl9170 and xhci. If you want, you can get the details from: >>>>> "carl9170 A-MPDU transmit problem": >>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> >>>>> >>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is >>>>> affected, but I don't know about Haswell): >>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> >>>> >>>> Same situation is here - i have problem on Ivy Bridge. >>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge >>> and AMD's new A6-1450 Temash and both xhci work. So I can't >>> do any proper comparisons like you.) >>> >>>> Steps to reproduce: >>>> - plug adapter. Module and firmware will be loaded >>>> - make sure usb autosupend is enabled. By default it is not! Use >>>> powertop or directly sysfs to enable autosuspend for this device >>>> - rmmod .... and wait some seconds until adapter is suspended and then >>>> modprobe ath9k_htc >> >>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register >>>> will report wrong size.. bigger as FIFO can handle. And only first ~40 >>>> readet bytes will be actually OK.. all the rest of packet will be trashed. >>> >>> This is what happens with a WN721 (ar9271): >>> >>> [17619.597905] usbcore: deregistering interface driver ath9k_htc >>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized >>> [17619.679602] ath9k_htc: Driver unloaded >>> <suspend> >>> >>> <resume> >>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- >>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 >>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 >>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 >>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 >>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 >>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 >>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested >>> [17667.573873] usbcore: registered new interface driver ath9k_htc >>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 >>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits >>> >>> The driver loads, but there's no "wlanX" interface, no phyX interface >>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". >> >> So, it is exactly this bug. >> After firmware was loaded ath9k trying to set some registers. Since >> command buffer is trashed it will write some nonsense to registers and >> some times in wrong to wrong addresses. I have some patches to do crc >> check of commands, to easy detect corrupted ones. >> >> You reproduced it on NEC xhci? Is it possible to reproduce it in >> carl9170? > > Ok: That's dmesg of your scenario: > > [ 809.995966] usbcore: deregistering interface driver carl9170 > <suspend> > > <resume> > [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd > [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900 > [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940 > [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980 > [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0 > [ 826.432257] usbcore: registered new interface driver carl9170 > [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1] > ... > [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3' > > carl9170 is able to recover and the stick is working after autosuspend cycle. Thank you for your tests. USB configuration and handlers look similar on this two firmwares. May be problem is not in FUSB200 and it is clock related issue so carl9170 do not need reset. - I don't know :( Can you please test this branch: https://github.com/olerem/open-ath9k-htc-firmware/commits/next There is a workaround to reset adapter, right after this bug is detected. It is really dirty hack, but currently i do not know how to fix this bug on xhci or on ath9k-htc side. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-24 10:37 ` Oleksij Rempel @ 2013-07-27 21:59 ` Christian Lamparter 2013-07-28 5:50 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-27 21:59 UTC (permalink / raw) To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote: > Am 23.07.2013 20:26, schrieb Christian Lamparter: > > On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote: > >> Am 22.07.2013 23:23, schrieb Christian Lamparter: > >>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: > >>>> Am 22.07.2013 21:54, schrieb Christian Lamparter: > >>>>> Hello! > >>>>> > >>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: > >>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of > >>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i > >>>>>> accidentally discovered that 9170 have it too. Are there any issue with > >>>>>> usb-suspend + xhci controllers by you? Did you some how specially > >>>>>> handled it? > >>>>> > >>>>> No, I haven't heard any complains about xhci + suspend. In fact, > >>>>> it's working fine with the NEC xhci I have. I also have a AR9271 > >>>>> and AR7010, so if you want I could try if they survive a suspend > >>>>> +resume cycle when attached. > >>>>> > >>>>> But, I do have a bug-report from someone else who has/had? problems > >>>>> with carl9170 and xhci. If you want, you can get the details from: > >>>>> "carl9170 A-MPDU transmit problem": > >>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> > >>>>> > >>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is > >>>>> affected, but I don't know about Haswell): > >>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> > >>>> > >>>> Same situation is here - i have problem on Ivy Bridge. > >>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge > >>> and AMD's new A6-1450 Temash and both xhci work. So I can't > >>> do any proper comparisons like you.) > >>> > >>>> Steps to reproduce: > >>>> - plug adapter. Module and firmware will be loaded > >>>> - make sure usb autosupend is enabled. By default it is not! Use > >>>> powertop or directly sysfs to enable autosuspend for this device > >>>> - rmmod .... and wait some seconds until adapter is suspended and then > >>>> modprobe ath9k_htc > >> > >>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register > >>>> will report wrong size.. bigger as FIFO can handle. And only first ~40 > >>>> readet bytes will be actually OK.. all the rest of packet will be trashed. > >>> > >>> This is what happens with a WN721 (ar9271): > >>> > >>> [17619.597905] usbcore: deregistering interface driver ath9k_htc > >>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized > >>> [17619.679602] ath9k_htc: Driver unloaded > >>> <suspend> > >>> > >>> <resume> > >>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- > >>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 > >>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 > >>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 > >>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 > >>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 > >>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 > >>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested > >>> [17667.573873] usbcore: registered new interface driver ath9k_htc > >>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 > >>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits > >>> > >>> The driver loads, but there's no "wlanX" interface, no phyX interface > >>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". > >> > >> So, it is exactly this bug. > >> After firmware was loaded ath9k trying to set some registers. Since > >> command buffer is trashed it will write some nonsense to registers and > >> some times in wrong to wrong addresses. I have some patches to do crc > >> check of commands, to easy detect corrupted ones. > >> > >> You reproduced it on NEC xhci? Is it possible to reproduce it in > >> carl9170? > > > > Ok: That's dmesg of your scenario: > > > > [ 809.995966] usbcore: deregistering interface driver carl9170 > > <suspend> > > > > <resume> > > [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd > > [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900 > > [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940 > > [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980 > > [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0 > > [ 826.432257] usbcore: registered new interface driver carl9170 > > [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1] > > ... > > [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3' > > > > carl9170 is able to recover and the stick is working after autosuspend cycle. > > Thank you for your tests. USB configuration and handlers look similar on > this two firmwares. May be problem is not in FUSB200 and it is clock > related issue so carl9170 do not need reset. - I don't know :( > > Can you please test this branch: > https://github.com/olerem/open-ath9k-htc-firmware/commits/next > There is a workaround to reset adapter, right after this bug is > detected. It is really dirty hack, but currently i do not know how to > fix this bug on xhci or on ath9k-htc side. > Is it still Saturday? Anyway, I tried the -next branch. commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 Author: Oleksij Rempel <linux@rempel-privat.de> Date: Wed Jul 24 10:26:18 2013 +0200 k2_fw_usb_api: workaround for EP4 bug. but still, the device won't show up after autosuspend. regards, Chr ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-27 21:59 ` Christian Lamparter @ 2013-07-28 5:50 ` Oleksij Rempel 2013-07-28 11:38 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-28 5:50 UTC (permalink / raw) To: Christian Lamparter; +Cc: linux-wireless Am 27.07.2013 23:59, schrieb Christian Lamparter: > On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote: >> Am 23.07.2013 20:26, schrieb Christian Lamparter: >>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote: >>>> Am 22.07.2013 23:23, schrieb Christian Lamparter: >>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: >>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter: >>>>>>> Hello! >>>>>>> >>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: >>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of >>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i >>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with >>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially >>>>>>>> handled it? >>>>>>> >>>>>>> No, I haven't heard any complains about xhci + suspend. In fact, >>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271 >>>>>>> and AR7010, so if you want I could try if they survive a suspend >>>>>>> +resume cycle when attached. >>>>>>> >>>>>>> But, I do have a bug-report from someone else who has/had? problems >>>>>>> with carl9170 and xhci. If you want, you can get the details from: >>>>>>> "carl9170 A-MPDU transmit problem": >>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> >>>>>>> >>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is >>>>>>> affected, but I don't know about Haswell): >>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> >>>>>> >>>>>> Same situation is here - i have problem on Ivy Bridge. >>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge >>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't >>>>> do any proper comparisons like you.) >>>>> >>>>>> Steps to reproduce: >>>>>> - plug adapter. Module and firmware will be loaded >>>>>> - make sure usb autosupend is enabled. By default it is not! Use >>>>>> powertop or directly sysfs to enable autosuspend for this device >>>>>> - rmmod .... and wait some seconds until adapter is suspended and then >>>>>> modprobe ath9k_htc >>>> >>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register >>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40 >>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed. >>>>> >>>>> This is what happens with a WN721 (ar9271): >>>>> >>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc >>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized >>>>> [17619.679602] ath9k_htc: Driver unloaded >>>>> <suspend> >>>>> >>>>> <resume> >>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- >>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 >>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 >>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 >>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 >>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 >>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 >>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested >>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc >>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 >>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits >>>>> >>>>> The driver loads, but there's no "wlanX" interface, no phyX interface >>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". >>>> >>>> So, it is exactly this bug. >>>> After firmware was loaded ath9k trying to set some registers. Since >>>> command buffer is trashed it will write some nonsense to registers and >>>> some times in wrong to wrong addresses. I have some patches to do crc >>>> check of commands, to easy detect corrupted ones. >>>> >>>> You reproduced it on NEC xhci? Is it possible to reproduce it in >>>> carl9170? >>> >>> Ok: That's dmesg of your scenario: >>> >>> [ 809.995966] usbcore: deregistering interface driver carl9170 >>> <suspend> >>> >>> <resume> >>> [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd >>> [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900 >>> [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940 >>> [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980 >>> [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0 >>> [ 826.432257] usbcore: registered new interface driver carl9170 >>> [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1] >>> ... >>> [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3' >>> >>> carl9170 is able to recover and the stick is working after autosuspend cycle. >> >> Thank you for your tests. USB configuration and handlers look similar on >> this two firmwares. May be problem is not in FUSB200 and it is clock >> related issue so carl9170 do not need reset. - I don't know :( >> >> Can you please test this branch: >> https://github.com/olerem/open-ath9k-htc-firmware/commits/next >> There is a workaround to reset adapter, right after this bug is >> detected. It is really dirty hack, but currently i do not know how to >> fix this bug on xhci or on ath9k-htc side. >> > Is it still Saturday? > > Anyway, I tried the -next branch. > > commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 > Author: Oleksij Rempel <linux@rempel-privat.de> > Date: Wed Jul 24 10:26:18 2013 +0200 > > k2_fw_usb_api: workaround for EP4 bug. > > but still, the device won't show up after autosuspend. Hm... firmware probably didn't rebooted before suspend. Did interface was up, before autosuspend? If no, you need latest wireles-testing - there are patches to handle this issue. Or just make "ifconfig wlan1 up" before rmmod. If it was up... then i would need last log messages from firmware.. If there is some way to attach to uart pins on it. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-28 5:50 ` Oleksij Rempel @ 2013-07-28 11:38 ` Christian Lamparter 2013-07-28 12:12 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-28 11:38 UTC (permalink / raw) To: Oleksij Rempel; +Cc: linux-wireless On Sunday 28 July 2013 07:50:32 Oleksij Rempel wrote: > Am 27.07.2013 23:59, schrieb Christian Lamparter: > > On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote: > >> Am 23.07.2013 20:26, schrieb Christian Lamparter: > >>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote: > >>>> Am 22.07.2013 23:23, schrieb Christian Lamparter: > >>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote: > >>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter: > >>>>>>> Hello! > >>>>>>> > >>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote: > >>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of > >>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i > >>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with > >>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially > >>>>>>>> handled it? > >>>>>>> > >>>>>>> No, I haven't heard any complains about xhci + suspend. In fact, > >>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271 > >>>>>>> and AR7010, so if you want I could try if they survive a suspend > >>>>>>> +resume cycle when attached. > >>>>>>> > >>>>>>> But, I do have a bug-report from someone else who has/had? problems > >>>>>>> with carl9170 and xhci. If you want, you can get the details from: > >>>>>>> "carl9170 A-MPDU transmit problem": > >>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597> > >>>>>>> > >>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is > >>>>>>> affected, but I don't know about Haswell): > >>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602> > >>>>>> > >>>>>> Same situation is here - i have problem on Ivy Bridge. > >>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge > >>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't > >>>>> do any proper comparisons like you.) > >>>>> > >>>>>> Steps to reproduce: > >>>>>> - plug adapter. Module and firmware will be loaded > >>>>>> - make sure usb autosupend is enabled. By default it is not! Use > >>>>>> powertop or directly sysfs to enable autosuspend for this device > >>>>>> - rmmod .... and wait some seconds until adapter is suspended and then > >>>>>> modprobe ath9k_htc > >>>> > >>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register > >>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40 > >>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed. > >>>>> > >>>>> This is what happens with a WN721 (ar9271): > >>>>> > >>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc > >>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized > >>>>> [17619.679602] ath9k_htc: Driver unloaded > >>>>> <suspend> > >>>>> > >>>>> <resume> > >>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <---- > >>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600 > >>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640 > >>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680 > >>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0 > >>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700 > >>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740 > >>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested > >>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc > >>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 > >>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits > >>>>> > >>>>> The driver loads, but there's no "wlanX" interface, no phyX interface > >>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use". > >>>> > >>>> So, it is exactly this bug. > >>>> After firmware was loaded ath9k trying to set some registers. Since > >>>> command buffer is trashed it will write some nonsense to registers and > >>>> some times in wrong to wrong addresses. I have some patches to do crc > >>>> check of commands, to easy detect corrupted ones. > >>>> > >>>> You reproduced it on NEC xhci? Is it possible to reproduce it in > >>>> carl9170? > >>> > >>> Ok: That's dmesg of your scenario: > >>> > >>> [ 809.995966] usbcore: deregistering interface driver carl9170 > >>> <suspend> > >>> > >>> <resume> > >>> [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd > >>> [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900 > >>> [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940 > >>> [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980 > >>> [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0 > >>> [ 826.432257] usbcore: registered new interface driver carl9170 > >>> [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1] > >>> ... > >>> [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3' > >>> > >>> carl9170 is able to recover and the stick is working after autosuspend cycle. > >> > >> Thank you for your tests. USB configuration and handlers look similar on > >> this two firmwares. May be problem is not in FUSB200 and it is clock > >> related issue so carl9170 do not need reset. - I don't know :( > >> > >> Can you please test this branch: > >> https://github.com/olerem/open-ath9k-htc-firmware/commits/next > >> There is a workaround to reset adapter, right after this bug is > >> detected. It is really dirty hack, but currently i do not know how to > >> fix this bug on xhci or on ath9k-htc side. > >> > > Is it still Saturday? > > > > Anyway, I tried the -next branch. > > > > commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 > > Author: Oleksij Rempel <linux@rempel-privat.de> > > Date: Wed Jul 24 10:26:18 2013 +0200 > > > > k2_fw_usb_api: workaround for EP4 bug. > > > > but still, the device won't show up after autosuspend. > > Hm... firmware probably didn't rebooted before suspend. Did interface > was up, before autosuspend? If no, you need latest wireles-testing - > there are patches to handle this issue. Or just make "ifconfig wlan1 up" > before rmmod. Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module had the patch "ath9k_htc: reboot firmwware if it was loaded"). Furthermore, I did the same test with one of the ehci-only ports and it worked. Both, devices (one had a AR7015, the other a AR9271) came back after autosuspend there. > then i would need last log messages from firmware.. If there is > some way to attach to uart pins on it. Sorry, I can't really help you there as I don't have the necessary tools. But I would be happy to test patches. Regards, Chr ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-28 11:38 ` Christian Lamparter @ 2013-07-28 12:12 ` Oleksij Rempel 2013-07-28 14:28 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-28 12:12 UTC (permalink / raw) To: Christian Lamparter Cc: linux-wireless, Sarah Sharp, USB list, Seth Forshee, ath9k_htc_fw Am 28.07.2013 13:38, schrieb Christian Lamparter: >>> >>> Anyway, I tried the -next branch. >>> >>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 >>> Author: Oleksij Rempel <linux@rempel-privat.de> >>> Date: Wed Jul 24 10:26:18 2013 +0200 >>> >>> k2_fw_usb_api: workaround for EP4 bug. >>> >>> but still, the device won't show up after autosuspend. >> >> Hm... firmware probably didn't rebooted before suspend. Did interface >> was up, before autosuspend? If no, you need latest wireles-testing - >> there are patches to handle this issue. Or just make "ifconfig wlan1 up" >> before rmmod. > Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module > had the patch "ath9k_htc: reboot firmwware if it was loaded"). > > Furthermore, I did the same test with one of the ehci-only ports > and it worked. Both, devices (one had a AR7015, the other a AR9271) > came back after autosuspend there. Grrr... so it brings us back to xhci issue. Even EP4 workaround wont work here :( Suddenly i have no more ideas. Sarah, it's your turn now. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-28 12:12 ` Oleksij Rempel @ 2013-07-28 14:28 ` Oleksij Rempel 2013-07-28 20:41 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-28 14:28 UTC (permalink / raw) To: Christian Lamparter Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 28.07.2013 14:12, schrieb Oleksij Rempel: > Am 28.07.2013 13:38, schrieb Christian Lamparter: > >>>> >>>> Anyway, I tried the -next branch. >>>> >>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 >>>> Author: Oleksij Rempel <linux@rempel-privat.de> >>>> Date: Wed Jul 24 10:26:18 2013 +0200 >>>> >>>> k2_fw_usb_api: workaround for EP4 bug. >>>> >>>> but still, the device won't show up after autosuspend. >>> >>> Hm... firmware probably didn't rebooted before suspend. Did interface >>> was up, before autosuspend? If no, you need latest wireles-testing - >>> there are patches to handle this issue. Or just make "ifconfig wlan1 up" >>> before rmmod. >> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module >> had the patch "ath9k_htc: reboot firmwware if it was loaded"). >> >> Furthermore, I did the same test with one of the ehci-only ports >> and it worked. Both, devices (one had a AR7015, the other a AR9271) >> came back after autosuspend there. > > Grrr... so it brings us back to xhci issue. Even EP4 workaround wont > work here :( Suddenly i have no more ideas. > > Sarah, it's your turn now. Christian, can you please provide some more info about your xhci controller. I'll try to get me same. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-28 14:28 ` Oleksij Rempel @ 2013-07-28 20:41 ` Christian Lamparter 2013-07-31 6:52 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-07-28 20:41 UTC (permalink / raw) To: Oleksij Rempel Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote: > Am 28.07.2013 14:12, schrieb Oleksij Rempel: > > Am 28.07.2013 13:38, schrieb Christian Lamparter: > > > >>>> > >>>> Anyway, I tried the -next branch. > >>>> > >>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 > >>>> Author: Oleksij Rempel <linux@rempel-privat.de> > >>>> Date: Wed Jul 24 10:26:18 2013 +0200 > >>>> > >>>> k2_fw_usb_api: workaround for EP4 bug. > >>>> > >>>> but still, the device won't show up after autosuspend. > >>> > >>> Hm... firmware probably didn't rebooted before suspend. Did interface > >>> was up, before autosuspend? If no, you need latest wireles-testing - > >>> there are patches to handle this issue. Or just make "ifconfig wlan1 up" > >>> before rmmod. > >> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module > >> had the patch "ath9k_htc: reboot firmwware if it was loaded"). > >> > >> Furthermore, I did the same test with one of the ehci-only ports > >> and it worked. Both, devices (one had a AR7015, the other a AR9271) > >> came back after autosuspend there. > > > > Grrr... so it brings us back to xhci issue. Even EP4 workaround wont > > work here :( Suddenly i have no more ideas. > > > > Sarah, it's your turn now. > > Christian, > can you please provide some more info about your xhci controller. I'll > try to get me same. Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the same setup will be difficult. However, since the uPD720200 was/is very popular, it should be very easy to find one. [It's probably on all of these "10 euro usb-3.0 pcie-adapters". So as long as you got a free 1x-pcie port you should be good.] Here's the lspci summary: 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI]) Subsystem: Hewlett-Packard Company Device [103c:1657] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: xhci_hcd Regards, Chr ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-28 20:41 ` Christian Lamparter @ 2013-07-31 6:52 ` Oleksij Rempel 2013-08-08 15:35 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-07-31 6:52 UTC (permalink / raw) To: Christian Lamparter Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 28.07.2013 22:41, schrieb Christian Lamparter: > On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote: >> Am 28.07.2013 14:12, schrieb Oleksij Rempel: >>> Am 28.07.2013 13:38, schrieb Christian Lamparter: >>> >>>>>> >>>>>> Anyway, I tried the -next branch. >>>>>> >>>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799 >>>>>> Author: Oleksij Rempel <linux@rempel-privat.de> >>>>>> Date: Wed Jul 24 10:26:18 2013 +0200 >>>>>> >>>>>> k2_fw_usb_api: workaround for EP4 bug. >>>>>> >>>>>> but still, the device won't show up after autosuspend. >>>>> >>>>> Hm... firmware probably didn't rebooted before suspend. Did interface >>>>> was up, before autosuspend? If no, you need latest wireles-testing - >>>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up" >>>>> before rmmod. >>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module >>>> had the patch "ath9k_htc: reboot firmwware if it was loaded"). >>>> >>>> Furthermore, I did the same test with one of the ehci-only ports >>>> and it worked. Both, devices (one had a AR7015, the other a AR9271) >>>> came back after autosuspend there. >>> >>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont >>> work here :( Suddenly i have no more ideas. >>> >>> Sarah, it's your turn now. >> >> Christian, >> can you please provide some more info about your xhci controller. I'll >> try to get me same. > > Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the > same setup will be difficult. However, since the uPD720200 was/is > very popular, it should be very easy to find one. [It's probably > on all of these "10 euro usb-3.0 pcie-adapters". So as long as you > got a free 1x-pcie port you should be good.] > > Here's the lspci summary: > > 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI]) > Subsystem: Hewlett-Packard Company Device [103c:1657] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 19 > Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K] > Capabilities: <access denied> > Kernel driver in use: xhci_hcd > Thx... i purchased on random on ebay, will see what i get. I know now why carl9170 don't triggering this bug. Carl uses EP4 as Interrupt with packet size 64. ath9k-htc initially have EP4=Intr, Interval=1, but will reconfigure it to Bulk, Interval=0. It mean, before usb suspend EP4=Bulk, Interval=0 and after resume EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may be interval stay 0, and xhci will overfill usb buffer on adapter - at least it looks so. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-07-31 6:52 ` Oleksij Rempel @ 2013-08-08 15:35 ` Oleksij Rempel 2013-08-08 19:09 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-08-08 15:35 UTC (permalink / raw) To: Christian Lamparter Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless [-- Attachment #1: Type: text/plain, Size: 2618 bytes --] Am 31.07.2013 08:52, schrieb Oleksij Rempel: > Am 28.07.2013 22:41, schrieb Christian Lamparter: >> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote: >>> Am 28.07.2013 14:12, schrieb Oleksij Rempel: >>>> Am 28.07.2013 13:38, schrieb Christian Lamparter: >>>> >>>>>> before rmmod. >>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" >>>>> module >>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded"). >>>>> >>>>> Furthermore, I did the same test with one of the ehci-only ports >>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271) >>>>> came back after autosuspend there. >>>> >>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont >>>> work here :( Suddenly i have no more ideas. >>>> >>>> Sarah, it's your turn now. >>> >>> Christian, >>> can you please provide some more info about your xhci controller. I'll >>> try to get me same. >> >> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the >> same setup will be difficult. However, since the uPD720200 was/is >> very popular, it should be very easy to find one. [It's probably >> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you >> got a free 1x-pcie port you should be good.] >> >> Here's the lspci summary: >> >> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host >> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI]) >> Subsystem: Hewlett-Packard Company Device [103c:1657] >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 19 >> Region 0: Memory at d3400000 (64-bit, non-prefetchable) >> [size=8K] >> Capabilities: <access denied> >> Kernel driver in use: xhci_hcd >> > > Thx... i purchased on random on ebay, will see what i get. > > I know now why carl9170 don't triggering this bug. Carl uses EP4 as > Interrupt with packet size 64. ath9k-htc initially have EP4=Intr, > Interval=1, but will reconfigure it to Bulk, Interval=0. > It mean, before usb suspend EP4=Bulk, Interval=0 and after resume > EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may > be interval stay 0, and xhci will overfill usb buffer on adapter - at > least it looks so. Christian, can you please test one more patch. It is working for me, but who knows. More testing is never bad idea ;) -- Regards, Oleksij [-- Attachment #2: interval.diff --] [-- Type: text/x-patch, Size: 510 bytes --] diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 5205a36..6f4f39c 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -1053,7 +1053,7 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb *hif_dev) == USB_ENDPOINT_XFER_INT) { endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK; endp->bmAttributes |= USB_ENDPOINT_XFER_BULK; - endp->bInterval = 0; + // endp->bInterval = 0; } } ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-08 15:35 ` Oleksij Rempel @ 2013-08-08 19:09 ` Christian Lamparter 2013-08-08 20:19 ` Alan Stern 0 siblings, 1 reply; 29+ messages in thread From: Christian Lamparter @ 2013-08-08 19:09 UTC (permalink / raw) To: Oleksij Rempel, Alan Stern Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Thursday 08 August 2013 17:35:34 Oleksij Rempel wrote: > Am 31.07.2013 08:52, schrieb Oleksij Rempel: > > Am 28.07.2013 22:41, schrieb Christian Lamparter: > >> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote: > >>> Am 28.07.2013 14:12, schrieb Oleksij Rempel: > >>>> Am 28.07.2013 13:38, schrieb Christian Lamparter: > >>>> > >>>>>> before rmmod. > >>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" > >>>>> module > >>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded"). > >>>>> > >>>>> Furthermore, I did the same test with one of the ehci-only ports > >>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271) > >>>>> came back after autosuspend there. > >>>> > >>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont > >>>> work here :( Suddenly i have no more ideas. > >>>> > >>>> Sarah, it's your turn now. > >>> > >>> Christian, > >>> can you please provide some more info about your xhci controller. I'll > >>> try to get me same. > >> > >> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the > >> same setup will be difficult. However, since the uPD720200 was/is > >> very popular, it should be very easy to find one. [It's probably > >> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you > >> got a free 1x-pcie port you should be good.] > >> > >> Here's the lspci summary: > >> > >> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host > >> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI]) > >> Subsystem: Hewlett-Packard Company Device [103c:1657] > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > >> ParErr- Stepping- SERR- FastB2B- DisINTx+ > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast > >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > >> Latency: 0, Cache Line Size: 64 bytes > >> Interrupt: pin A routed to IRQ 19 > >> Region 0: Memory at d3400000 (64-bit, non-prefetchable) > >> [size=8K] > >> Capabilities: <access denied> > >> Kernel driver in use: xhci_hcd > >> > > > > Thx... i purchased on random on ebay, will see what i get. > > > > I know now why carl9170 don't triggering this bug. Carl uses EP4 as > > Interrupt with packet size 64. ath9k-htc initially have EP4=Intr, > > Interval=1, but will reconfigure it to Bulk, Interval=0. > > It mean, before usb suspend EP4=Bulk, Interval=0 and after resume > > EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may > > be interval stay 0, and xhci will overfill usb buffer on adapter - at > > least it looks so. > > Christian, > can you please test one more patch. It is working for me, but who knows. > More testing is never bad idea ;) It sort of works, but not without a hiccup: I get the following messages when I try to load the driver again after an autosuspend cycle (ar9271, NEC xhci): ath: phy6: Reading Magic # failed ath9k_htc: Failed to Initialize the device usb 2-1: ath9k_htc: USB layer deinitialized .... However, the device is resetted automatically and it comes back on the second probe attempt. Anyway, I do have a question about something else too. in ath9k_htc's hif_usb: > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0]; > struct usb_endpoint_descriptor *endp; > ... > /* On downloading the firmware to the target, the USB descriptor of EP4 > * is 'patched' to change the type of the endpoint to Bulk. This will > * bring down CPU usage during the scan period. */ > > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) { > endp = &alt->endpoint[idx].desc; > if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { > endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK; > endp->bmAttributes |= USB_ENDPOINT_XFER_BULK; >// endp->bInterval = 0; > } > } Alan, can you please tell us, if it is really safe to override the bmAttributes this way? After all (according to the comment) the device has "morphed" (EP4 has changed). Or, is it necessary for the driver call "usb_reset_device" or (usb_reset_configuration) in this case? Regards, Chr ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-08 19:09 ` Christian Lamparter @ 2013-08-08 20:19 ` Alan Stern 2013-08-08 22:06 ` Christian Lamparter 0 siblings, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-08 20:19 UTC (permalink / raw) To: Christian Lamparter Cc: Oleksij Rempel, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Thu, 8 Aug 2013, Christian Lamparter wrote: > Anyway, I do have a question about something else too. > > in ath9k_htc's hif_usb: > > > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0]; > > struct usb_endpoint_descriptor *endp; > > ... > > /* On downloading the firmware to the target, the USB descriptor of EP4 > > * is 'patched' to change the type of the endpoint to Bulk. This will > > * bring down CPU usage during the scan period. */ > > > > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) { > > endp = &alt->endpoint[idx].desc; > > if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { > > endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK; > > endp->bmAttributes |= USB_ENDPOINT_XFER_BULK; > >// endp->bInterval = 0; > > } > > } > > Alan, can you please tell us, if it is really safe to > override the bmAttributes this way? After all (according to > the comment) the device has "morphed" (EP4 has changed). This does not look like a good idea. Why does the driver do it? > Or, is it necessary for the driver call "usb_reset_device" > or (usb_reset_configuration) in this case? After loading firmware, a reset generally is necessary. Some devices will do it themselves; others require you to call usb_reset_device(). Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-08 20:19 ` Alan Stern @ 2013-08-08 22:06 ` Christian Lamparter 2013-08-09 2:52 ` Sujith Manoharan 2013-08-09 14:13 ` FUSB200 xhci issue Alan Stern 0 siblings, 2 replies; 29+ messages in thread From: Christian Lamparter @ 2013-08-08 22:06 UTC (permalink / raw) To: Alan Stern Cc: Oleksij Rempel, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Thursday 08 August 2013 22:19:32 Alan Stern wrote: > On Thu, 8 Aug 2013, Christian Lamparter wrote: > > > Anyway, I do have a question about something else too. > > > > in ath9k_htc's hif_usb: > > > > > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0]; > > > struct usb_endpoint_descriptor *endp; > > > ... > > > /* On downloading the firmware to the target, the USB descriptor of EP4 > > > * is 'patched' to change the type of the endpoint to Bulk. This will > > > * bring down CPU usage during the scan period. */ > > > > > > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) { > > > endp = &alt->endpoint[idx].desc; > > > if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { > > > endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK; > > > endp->bmAttributes |= USB_ENDPOINT_XFER_BULK; > > >// endp->bInterval = 0; > > > } > > > } > > > > Alan, can you please tell us, if it is really safe to > > override the bmAttributes this way? After all (according to > > the comment) the device has "morphed" (EP4 has changed). > > This does not look like a good idea. Why does the driver do it? Probably because people use ath9k_htc devices with everything that has some sort of usb port (devkits and embedded systems: Dockstar, Rasberry Pi, ...) to get "wifi connectivity". ... Yeah. I think we better ask "Rajkumar Manoharan" (before I write more text out of thin air :-D ) commit 4a0e8ecca4eeed38d4b3b7a317a3aaab4dd3cacd Author: Rajkumar Manoharan <rmanoharan@atheros.com> Date: Tue Sep 14 14:35:55 2010 +0530 ath9k_htc: Fix CPU usage issue during scan period Does anyone know his Qualcomm Atheros address? > > Or, is it necessary for the driver call "usb_reset_device" > > or (usb_reset_configuration) in this case? > > After loading firmware, a reset generally is necessary. Some devices > will do it themselves; others require you to call usb_reset_device(). This makes things complicated. Because, as far as I remember, usb_reset_device() will cause the current driver to be unbound unless its called during .probe, right? You see, ath9k_htc loads its firmware asynchronously in ".probe" (ath9k_htc's .probe routine finishes before the firmware is retrieved via the firmware loader helper... so part of the firmware download is done in a firmware_complete callback on a workqueue). So, if we call usb_reset_device there and the driver is unbound and later rebound. the next ath9k_htc .probe will start again and again and again not knowing that it is already initialized (and we have a loop). This could be solved, if the devices changes the usb-id again when a proper "wifi" ath9k_htc firmware was downloaded. So, the driver would know that it doesn't have to download and reset the device... But we need a "free" USB-ID for that. Alan, Oleksij: What do you think? Regards, Chr ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-08 22:06 ` Christian Lamparter @ 2013-08-09 2:52 ` Sujith Manoharan 2013-08-09 14:32 ` ath9k_htc firmware problem [was: Re: FUSB200 xhci issue] Alan Stern 2013-08-09 14:13 ` FUSB200 xhci issue Alan Stern 1 sibling, 1 reply; 29+ messages in thread From: Sujith Manoharan @ 2013-08-09 2:52 UTC (permalink / raw) To: Christian Lamparter Cc: Alan Stern, Oleksij Rempel, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Christian Lamparter wrote: > So, if we call usb_reset_device there and the driver is unbound > and later rebound. the next ath9k_htc .probe will start again and > again and again not knowing that it is already initialized > (and we have a loop). The HW/FW is buggy and this workaround is required: http://marc.info/?l=linux-usb&m=127960864905646&w=2 Sujith ^ permalink raw reply [flat|nested] 29+ messages in thread
* ath9k_htc firmware problem [was: Re: FUSB200 xhci issue] 2013-08-09 2:52 ` Sujith Manoharan @ 2013-08-09 14:32 ` Alan Stern 0 siblings, 0 replies; 29+ messages in thread From: Alan Stern @ 2013-08-09 14:32 UTC (permalink / raw) To: Sujith Manoharan Cc: Christian Lamparter, Oleksij Rempel, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Fri, 9 Aug 2013, Sujith Manoharan wrote: > Christian Lamparter wrote: > > So, if we call usb_reset_device there and the driver is unbound > > and later rebound. the next ath9k_htc .probe will start again and > > again and again not knowing that it is already initialized > > (and we have a loop). > > The HW/FW is buggy and this workaround is required: > http://marc.info/?l=linux-usb&m=127960864905646&w=2 I see the problem. The device loses its firmware when it gets reset or its port is disabled. This is really a very serious bug. For one thing, it means the device cannot support runtime PM. (Not unless the driver caches a copy of the firmware and reloads it every time the device resumes.) IMO a bug like this should disqualify the device from being allowed to wear the USB logo. One way around the problem might be for the firmware-loading thread to issue a usb_set_configuration call to switch to config 0 (i.e., to unconfigure the device), then patch the host's copy of the descriptor, and then switch back to the original configuration. This _will_ unbind and rebind the driver, so it definitely will need a way to tell whether the firmware has already been loaded. Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-08 22:06 ` Christian Lamparter 2013-08-09 2:52 ` Sujith Manoharan @ 2013-08-09 14:13 ` Alan Stern 2013-08-09 14:34 ` Oleksij Rempel 1 sibling, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-09 14:13 UTC (permalink / raw) To: Christian Lamparter Cc: Oleksij Rempel, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Fri, 9 Aug 2013, Christian Lamparter wrote: > > After loading firmware, a reset generally is necessary. Some devices > > will do it themselves; others require you to call usb_reset_device(). > > This makes things complicated. Because, as far as I remember, > usb_reset_device() will cause the current driver to be unbound > unless its called during .probe, right? If the driver defines pre_reset and post_reset methods, it won't get unbound during a reset. > You see, ath9k_htc loads its firmware asynchronously in ".probe" > (ath9k_htc's .probe routine finishes before the firmware is > retrieved via the firmware loader helper... so part of the > firmware download is done in a firmware_complete callback > on a workqueue). > > So, if we call usb_reset_device there and the driver is unbound > and later rebound. the next ath9k_htc .probe will start again and > again and again not knowing that it is already initialized > (and we have a loop). > > > This could be solved, if the devices changes the usb-id again > when a proper "wifi" ath9k_htc firmware was downloaded. So, the > driver would know that it doesn't have to download and reset > the device... But we need a "free" USB-ID for that. What about a "get firmware version" sort of thing? There really should be a way for the driver to tell whether the firmware has already been updated. Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 14:13 ` FUSB200 xhci issue Alan Stern @ 2013-08-09 14:34 ` Oleksij Rempel 2013-08-09 14:52 ` Alan Stern 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-08-09 14:34 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 09.08.2013 16:13, schrieb Alan Stern: > On Fri, 9 Aug 2013, Christian Lamparter wrote: > >>> After loading firmware, a reset generally is necessary. Some devices >>> will do it themselves; others require you to call usb_reset_device(). >> >> This makes things complicated. Because, as far as I remember, >> usb_reset_device() will cause the current driver to be unbound >> unless its called during .probe, right? > > If the driver defines pre_reset and post_reset methods, it won't get > unbound during a reset. > >> You see, ath9k_htc loads its firmware asynchronously in ".probe" >> (ath9k_htc's .probe routine finishes before the firmware is >> retrieved via the firmware loader helper... so part of the >> firmware download is done in a firmware_complete callback >> on a workqueue). >> >> So, if we call usb_reset_device there and the driver is unbound >> and later rebound. the next ath9k_htc .probe will start again and >> again and again not knowing that it is already initialized >> (and we have a loop). >> >> >> This could be solved, if the devices changes the usb-id again >> when a proper "wifi" ath9k_htc firmware was downloaded. So, the >> driver would know that it doesn't have to download and reset >> the device... But we need a "free" USB-ID for that. > > What about a "get firmware version" sort of thing? There really should > be a way for the driver to tell whether the firmware has already been > updated. I was not able to find good direct way to check firmware version. If i would add some new command then i will get option like: if responding FW is updated; if not, then dead or old. How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, then firmware is updated? Is it more or less acceptable method? I need to ask this because it is really new for me. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 14:34 ` Oleksij Rempel @ 2013-08-09 14:52 ` Alan Stern 2013-08-09 15:51 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-09 14:52 UTC (permalink / raw) To: Oleksij Rempel Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Fri, 9 Aug 2013, Oleksij Rempel wrote: > > What about a "get firmware version" sort of thing? There really should > > be a way for the driver to tell whether the firmware has already been > > updated. > > I was not able to find good direct way to check firmware version. If i > would add some new command then i will get option like: if responding FW > is updated; if not, then dead or old. > How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, > then firmware is updated? Is it more or less acceptable method? I need > to ask this because it is really new for me. Changing the iProduct string descriptor would work, because the descriptors_changed() routine doesn't compare the old value of that string with the new value. (On the other hand, it does compare the iSerialNumber strings.) Is there any way to read the firmware back from the device? Then you could check directly. Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 14:52 ` Alan Stern @ 2013-08-09 15:51 ` Oleksij Rempel 2013-08-09 17:16 ` Alan Stern 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-08-09 15:51 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 09.08.2013 16:52, schrieb Alan Stern: > On Fri, 9 Aug 2013, Oleksij Rempel wrote: > >>> What about a "get firmware version" sort of thing? There really should >>> be a way for the driver to tell whether the firmware has already been >>> updated. >> >> I was not able to find good direct way to check firmware version. If i >> would add some new command then i will get option like: if responding FW >> is updated; if not, then dead or old. >> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, >> then firmware is updated? Is it more or less acceptable method? I need >> to ask this because it is really new for me. > > Changing the iProduct string descriptor would work, because the > descriptors_changed() routine doesn't compare the old value of that > string with the new value. (On the other hand, it does compare the > iSerialNumber strings.) Just to make sure. You mean, i should avoid changing iSerialNumber because host will initiate usb reset and this device will probably not survive it? > Is there any way to read the firmware back from the device? Then you > could check directly. No, this device is a SoC with usb client interface based on FUSB200 core (If i'm correct, same core as on carl9170 devices). We can't read memory unless FW provide this service. At power on, this device will boot from external or internal ROM and load minimal FW. Without it, USB wont work. If i read FW code correctly, it should be responsible for suspend and reset. I do not have documentation, so created doc[1] based on code. From what is see, i assume that we can reset usb from FW. There is at least two methods: - reset complete USB core. It looks for me like brute force, since we will need completely reconfigure usb core. - use TEST registers? ZM_TEST_OFFSET or ZM_PHY_TEST_SELECT_OFFSET - i didn't played with it. So it is just assumption. - other regs? [1] https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-regs -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 15:51 ` Oleksij Rempel @ 2013-08-09 17:16 ` Alan Stern 2013-08-09 18:53 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-09 17:16 UTC (permalink / raw) To: Oleksij Rempel Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Fri, 9 Aug 2013, Oleksij Rempel wrote: > Am 09.08.2013 16:52, schrieb Alan Stern: > > On Fri, 9 Aug 2013, Oleksij Rempel wrote: > > > >>> What about a "get firmware version" sort of thing? There really should > >>> be a way for the driver to tell whether the firmware has already been > >>> updated. > >> > >> I was not able to find good direct way to check firmware version. If i > >> would add some new command then i will get option like: if responding FW > >> is updated; if not, then dead or old. > >> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, > >> then firmware is updated? Is it more or less acceptable method? I need > >> to ask this because it is really new for me. > > > > Changing the iProduct string descriptor would work, because the > > descriptors_changed() routine doesn't compare the old value of that > > string with the new value. (On the other hand, it does compare the > > iSerialNumber strings.) > > Just to make sure. You mean, i should avoid changing iSerialNumber > because host will initiate usb reset and this device will probably not > survive it? Right. If the device would survive a reset then there would be no problem. BTW, it is common for new firmware to change the bcdDevice value in the device descriptor. That might be easier than changing a string descriptor. > > Is there any way to read the firmware back from the device? Then you > > could check directly. > > No, this device is a SoC with usb client interface based on FUSB200 core > (If i'm correct, same core as on carl9170 devices). We can't read memory > unless FW provide this service. > At power on, this device will boot from external or internal ROM and > load minimal FW. Without it, USB wont work. > If i read FW code correctly, it should be responsible for suspend and reset. How do you tell the device to start running the new firmware after it is loaded? Normally this requires some sort of reset. Is there any way to prevent the device from losing its firmware during a USB reset or suspend? Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 17:16 ` Alan Stern @ 2013-08-09 18:53 ` Oleksij Rempel 2013-08-09 19:32 ` Alan Stern 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-08-09 18:53 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 09.08.2013 19:16, schrieb Alan Stern: > On Fri, 9 Aug 2013, Oleksij Rempel wrote: > >> Am 09.08.2013 16:52, schrieb Alan Stern: >>> On Fri, 9 Aug 2013, Oleksij Rempel wrote: >>> >>>>> What about a "get firmware version" sort of thing? There really should >>>>> be a way for the driver to tell whether the firmware has already been >>>>> updated. >>>> >>>> I was not able to find good direct way to check firmware version. If i >>>> would add some new command then i will get option like: if responding FW >>>> is updated; if not, then dead or old. >>>> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, >>>> then firmware is updated? Is it more or less acceptable method? I need >>>> to ask this because it is really new for me. >>> >>> Changing the iProduct string descriptor would work, because the >>> descriptors_changed() routine doesn't compare the old value of that >>> string with the new value. (On the other hand, it does compare the >>> iSerialNumber strings.) >> >> Just to make sure. You mean, i should avoid changing iSerialNumber >> because host will initiate usb reset and this device will probably not >> survive it? > > Right. If the device would survive a reset then there would be no > problem. > > BTW, it is common for new firmware to change the bcdDevice value in the > device descriptor. That might be easier than changing a string > descriptor. > >>> Is there any way to read the firmware back from the device? Then you >>> could check directly. >> >> No, this device is a SoC with usb client interface based on FUSB200 core >> (If i'm correct, same core as on carl9170 devices). We can't read memory >> unless FW provide this service. >> At power on, this device will boot from external or internal ROM and >> load minimal FW. Without it, USB wont work. >> If i read FW code correctly, it should be responsible for suspend and reset. > > How do you tell the device to start running the new firmware after it > is loaded? Normally this requires some sort of reset. There are two vendor commands cUSB_REQ_DOWNLOAD and cUSB_REQ_DOWNLOAD_COMP. With cUSB_REQ_DOWNLOAD firmware will be uploaded and cUSB_REQ_DOWNLOAD_COMP should just jump to first address of the firmware. This system has micro modular structure. Firmware can register own modules. Or relink modules of bootloader, but this is limited only to existing api. > Is there any way to prevent the device from losing its firmware during > a USB reset or suspend? For suspend - yes. It is possible to ignore suspend command or put the SoC in low power mode - but is it probably not so easy to bring it back. I would need to read more code and create some doc as side effect untill i understand how it works. I'm not sure how about reset command. I would need more testing and some ones help. If i see it correctly, usb reset should affect only usb core and usb pll. How can i trigger usb reset? -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 18:53 ` Oleksij Rempel @ 2013-08-09 19:32 ` Alan Stern 2013-08-10 6:19 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-09 19:32 UTC (permalink / raw) To: Oleksij Rempel Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Fri, 9 Aug 2013, Oleksij Rempel wrote: > > Is there any way to prevent the device from losing its firmware during > > a USB reset or suspend? > > For suspend - yes. It is possible to ignore suspend command or put the > SoC in low power mode - but is it probably not so easy to bring it back. > I would need to read more code and create some doc as side effect untill > i understand how it works. > I'm not sure how about reset command. I would need more testing and some > ones help. If i see it correctly, usb reset should affect only usb core > and usb pll. > > How can i trigger usb reset? http://marc.info/?l=linux-usb&m=121459435621262&w=2 Give the program the pathname for the USB device node. For example: usbreset /dev/bus/usb/001/004 Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-09 19:32 ` Alan Stern @ 2013-08-10 6:19 ` Oleksij Rempel 2013-08-10 11:57 ` Alan Stern 0 siblings, 1 reply; 29+ messages in thread From: Oleksij Rempel @ 2013-08-10 6:19 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless Am 09.08.2013 21:32, schrieb Alan Stern: > On Fri, 9 Aug 2013, Oleksij Rempel wrote: > >>> Is there any way to prevent the device from losing its firmware during >>> a USB reset or suspend? >> >> For suspend - yes. It is possible to ignore suspend command or put the >> SoC in low power mode - but is it probably not so easy to bring it back. >> I would need to read more code and create some doc as side effect untill >> i understand how it works. >> I'm not sure how about reset command. I would need more testing and some >> ones help. If i see it correctly, usb reset should affect only usb core >> and usb pll. >> >> How can i trigger usb reset? > > http://marc.info/?l=linux-usb&m=121459435621262&w=2 > > Give the program the pathname for the USB device node. For example: > > usbreset /dev/bus/usb/001/004 Great! thx! usb reset do not affect behaviour of firmware. At least after i remove all attempts to reboot FW from driver. If adapter will got reset signal, FW will be notified about it. Then FW will remove reset flag and will just continue to work. After usb reset, lsusb show correct, update information - EP3 and EP4 was updated from INT to BULK. I assume, no i need to add to the driver some kind of firmware check. What is the proper way to do it? -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-10 6:19 ` Oleksij Rempel @ 2013-08-10 11:57 ` Alan Stern 2013-08-12 7:58 ` Oleksij Rempel 0 siblings, 1 reply; 29+ messages in thread From: Alan Stern @ 2013-08-10 11:57 UTC (permalink / raw) To: Oleksij Rempel Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless On Sat, 10 Aug 2013, Oleksij Rempel wrote: > usb reset do not affect behaviour of firmware. At least after i remove > all attempts to reboot FW from driver. > If adapter will got reset signal, FW will be notified about it. Then FW > will remove reset flag and will just continue to work. After usb reset, > lsusb show correct, update information - EP3 and EP4 was updated from > INT to BULK. > > I assume, no i need to add to the driver some kind of firmware check. > What is the proper way to do it? The simplest way is to put a new value for the device descriptor's bcdDevice value in the firmware. Then all you have to do is check that value. Alan Stern ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: FUSB200 xhci issue 2013-08-10 11:57 ` Alan Stern @ 2013-08-12 7:58 ` Oleksij Rempel 0 siblings, 0 replies; 29+ messages in thread From: Oleksij Rempel @ 2013-08-12 7:58 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless, Sujith Manoharan Am 10.08.2013 13:57, schrieb Alan Stern: > On Sat, 10 Aug 2013, Oleksij Rempel wrote: > >> usb reset do not affect behaviour of firmware. At least after i remove >> all attempts to reboot FW from driver. >> If adapter will got reset signal, FW will be notified about it. Then FW >> will remove reset flag and will just continue to work. After usb reset, >> lsusb show correct, update information - EP3 and EP4 was updated from >> INT to BULK. >> >> I assume, no i need to add to the driver some kind of firmware check. >> What is the proper way to do it? > > The simplest way is to put a new value for the device descriptor's > bcdDevice value in the firmware. Then all you have to do is check that > value. Since adding fw check will need fw version update. I would like to do quick fix for current kernel and firmware version. I will revert EP3 and EP4 from bulk back to interrupt. But, before sending patch to the list i would like to know, how to reproduce the bug which was fixed by converting this endpoints from interrupt to bulk. -- Regards, Oleksij -- Regards, Oleksij ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2013-08-12 7:59 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <51ED4E12.8030006@rempel-privat.de> 2013-07-22 19:54 ` FUSB200 xhci issue Christian Lamparter 2013-07-22 20:47 ` Oleksij Rempel 2013-07-22 21:23 ` Christian Lamparter 2013-07-23 4:59 ` Oleksij Rempel 2013-07-23 18:26 ` Christian Lamparter 2013-07-24 10:37 ` Oleksij Rempel 2013-07-27 21:59 ` Christian Lamparter 2013-07-28 5:50 ` Oleksij Rempel 2013-07-28 11:38 ` Christian Lamparter 2013-07-28 12:12 ` Oleksij Rempel 2013-07-28 14:28 ` Oleksij Rempel 2013-07-28 20:41 ` Christian Lamparter 2013-07-31 6:52 ` Oleksij Rempel 2013-08-08 15:35 ` Oleksij Rempel 2013-08-08 19:09 ` Christian Lamparter 2013-08-08 20:19 ` Alan Stern 2013-08-08 22:06 ` Christian Lamparter 2013-08-09 2:52 ` Sujith Manoharan 2013-08-09 14:32 ` ath9k_htc firmware problem [was: Re: FUSB200 xhci issue] Alan Stern 2013-08-09 14:13 ` FUSB200 xhci issue Alan Stern 2013-08-09 14:34 ` Oleksij Rempel 2013-08-09 14:52 ` Alan Stern 2013-08-09 15:51 ` Oleksij Rempel 2013-08-09 17:16 ` Alan Stern 2013-08-09 18:53 ` Oleksij Rempel 2013-08-09 19:32 ` Alan Stern 2013-08-10 6:19 ` Oleksij Rempel 2013-08-10 11:57 ` Alan Stern 2013-08-12 7:58 ` Oleksij Rempel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.