Hi everyone,
This is an old issue, about which it seems the first posts date back to 2009.
With the latest possible version of the firmware for AR9271 and the latest
possible wireless drivers, the issue is still there. Whether this is still
the exact same problem every time remains to be checked, but it is annoying
enough to deserve some consideration.
The problem is that the driver can't talk to the device if the following
conditions are met:
- The system cold boots with the USB dongle inserted or the USB dongle is
inserted on a running system.
- The interface is *not* brought up.
- The system (warm) reboots.
Then the driver complains about the target being unresponsive after uploading
the firmware. Apparently the only way to make it work again is to unplug and
then plug the USB dongle back, physically. It seems that if the USB port is
not powered down during reboot (which happens with at least two different
setups that I've tested it with), the device is left in a broken state.
I would gladly help in tracing down this bug if only I knew where to start.
Thanks for any suggestion.
Ignacy
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
Am 15.05.2013 15:42, schrieb Ignacy Gawedzki:
> Hi everyone,
>
> This is an old issue, about which it seems the first posts date back to 2009.
> With the latest possible version of the firmware for AR9271 and the latest
> possible wireless drivers, the issue is still there. Whether this is still
> the exact same problem every time remains to be checked, but it is annoying
> enough to deserve some consideration.
>
> The problem is that the driver can't talk to the device if the following
> conditions are met:
>
> - The system cold boots with the USB dongle inserted or the USB dongle is
> inserted on a running system.
>
> - The interface is *not* brought up.
>
> - The system (warm) reboots.
>
> Then the driver complains about the target being unresponsive after uploading
> the firmware. Apparently the only way to make it work again is to unplug and
> then plug the USB dongle back, physically. It seems that if the USB port is
> not powered down during reboot (which happens with at least two different
> setups that I've tested it with), the device is left in a broken state.
>
> I would gladly help in tracing down this bug if only I knew where to start.
>
> Thanks for any suggestion.
Hi Ignacy,
i can't reproduce this issue on my system. I tested it with 4 different
ath9_htc adapter. Without luck. Please provide as match information as
possible:
- Usb host controller
- Adapter manufacture and version, or even better add it to the wiki,
and upload some images:
http://wikidevi.com/wiki/Main_Page
- your kernel version
I assume it is not firmware. May be there are some issue with boot
loader on adapter. Are you sure that UART pins are not soldered?
Current ath9k_htc do not have mechanism to reset an adapter. I will
start to work on it after some other issues are done.
PS: please find some way to enable uart, at least TX pin.
--
Regards,
Oleksij
Am 16.05.2013 19:20, schrieb Ignacy Gawedzki:
> On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel:
>> Am 15.05.2013 15:42, schrieb Ignacy Gawedzki:
>>> Hi everyone,
>>>
>>> This is an old issue, about which it seems the first posts date back to 2009.
>>> With the latest possible version of the firmware for AR9271 and the latest
>>> possible wireless drivers, the issue is still there. Whether this is still
>>> the exact same problem every time remains to be checked, but it is annoying
>>> enough to deserve some consideration.
>>>
>>> The problem is that the driver can't talk to the device if the following
>>> conditions are met:
>>>
>>> - The system cold boots with the USB dongle inserted or the USB dongle is
>>> inserted on a running system.
>>>
>>> - The interface is *not* brought up.
>>>
>>> - The system (warm) reboots.
>>>
>>> Then the driver complains about the target being unresponsive after uploading
>>> the firmware. Apparently the only way to make it work again is to unplug and
>>> then plug the USB dongle back, physically. It seems that if the USB port is
>>> not powered down during reboot (which happens with at least two different
>>> setups that I've tested it with), the device is left in a broken state.
>>>
>>> I would gladly help in tracing down this bug if only I knew where to start.
>>>
>>> Thanks for any suggestion.
>>
>> Hi Ignacy,
>>
>> i can't reproduce this issue on my system. I tested it with 4
>> different ath9_htc adapter. Without luck.
>
> Without luck, but it seems you're the lucky one anyway. =)
>
>> Please provide as match
>> information as possible:
>> - Usb host controller
>
> Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI,
> 8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly.
>
>> - Adapter manufacture and version, or even better add it to the
>> wiki, and upload some images:
>> http://wikidevi.com/wiki/Main_Page
>
> TP-Link TL-WN722NC, exactly as the one on the wiki.
That is interesting. I have got today TL-WN722N, but i still can't
reproduce this issue.
>> - your kernel version
>
> Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a
> customized buildroot, but I can provide the .config if needed).
>
>> I assume it is not firmware. May be there are some issue with boot
>> loader on adapter. Are you sure that UART pins are not soldered?
>
> I opened the dongle, managed to solder the metal shield off and the pins
> weren't used (all four 48-51, among others).
>
>> Current ath9k_htc do not have mechanism to reset an adapter. I will
>> start to work on it after some other issues are done.
>
> Is it physically possible?
may be.
>> PS: please find some way to enable uart, at least TX pin.
>
> I tried to solder the TX pin, but it's really too tiny. I don't have an iron
> so small as to be able to do it, sorry. I would really love to have an UART
> connection, but that's just beyond my abilities. BTW, it would really be
> great to have a way to send debug message up the USB link, just as with
> carl9170.
That make no sense. Debug message i need, are from boot loader. There is
no way, that boot loader can send messages over usb. Or if firmwre will
crash, it wont send any thing too.
So what do we have:
- TL-WN722N is working. Or your model is different, or it is broken one.
- Did you checked the cable?
- usb host controller?
- other options?
--
Regards,
Oleksij
On Thu, May 16, 2013 at 07:46:56PM +0200, thus spake Oleksij Rempel:
> Am 16.05.2013 19:20, schrieb Ignacy Gawedzki:
> >TP-Link TL-WN722NC, exactly as the one on the wiki.
>
> That is interesting. I have got today TL-WN722N, but i still can't
> reproduce this issue.
Are you sure that not any subsystem ups the interface before you have any
chance to warm reboot? Or that you don't have a hub that cuts power to
devices on warm reboot?
> >I tried to solder the TX pin, but it's really too tiny. I don't have an iron
> >so small as to be able to do it, sorry. I would really love to have an UART
> >connection, but that's just beyond my abilities. BTW, it would really be
> >great to have a way to send debug message up the USB link, just as with
> >carl9170.
>
> That make no sense. Debug message i need, are from boot loader.
> There is no way, that boot loader can send messages over usb. Or if
> firmwre will crash, it wont send any thing too.
I understand.
> So what do we have:
> - TL-WN722N is working. Or your model is different, or it is broken one.
I happen to have 8 of them, bought at different times and all exhibit the
problem.
> - Did you checked the cable?
I usually plug the device directly to the USB port, but I also happen to use
the cradle (supplied with the WN722NC version) that has a cable, when I need
two wireless interfaces on the RPi (both of them don't fit at once directly on
the ports).
> - usb host controller?
I'll try on yet another one and will tell you the results.
> - other options?
Hmmm... :/
--
-= Best Viewed Using [INLINE] =-
On Wed, May 15, 2013 at 06:11:49PM +0200, thus spake Eugene Krasnikov:
> there is a function in driver "ath9k_htc_reset"
> http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_main.c#L189
> but not sure that is what you are looking for.
>From the issue report about watchdog problems, I gather that the device is
supposed to be prepared for reception of the firmware code from the driver.
This normally happens when the device boots up and passes the first stage of
the bootloader. I suppose (I'm really totally guessing) that the driver
somehow doesn't do something to prepare the device for firmware upload if the
device is already past stage 2.
I would love to have the UART pins connected to some terminal, but I don't
have the soldering tools for such small-scale work...
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
The firmware is open nowadays for AR9271
https://github.com/qca/open-ath9k-htc-firmware/
But this is an interesting issue. I am currently working on one
problem that target becomes unresponsive(as described here
https://github.com/qca/open-ath9k-htc-firmware/issues/25) but i doubt
it's the same issue as yours. Let me see if i can reproduce your
problem. Will come back to you shortly.
2013/5/15 Ignacy Gawedzki <[email protected]>:
> Hi everyone,
>
> This is an old issue, about which it seems the first posts date back to 2009.
> With the latest possible version of the firmware for AR9271 and the latest
> possible wireless drivers, the issue is still there. Whether this is still
> the exact same problem every time remains to be checked, but it is annoying
> enough to deserve some consideration.
>
> The problem is that the driver can't talk to the device if the following
> conditions are met:
>
> - The system cold boots with the USB dongle inserted or the USB dongle is
> inserted on a running system.
>
> - The interface is *not* brought up.
>
> - The system (warm) reboots.
>
> Then the driver complains about the target being unresponsive after uploading
> the firmware. Apparently the only way to make it work again is to unplug and
> then plug the USB dongle back, physically. It seems that if the USB port is
> not powered down during reboot (which happens with at least two different
> setups that I've tested it with), the device is left in a broken state.
>
> I would gladly help in tracing down this bug if only I knew where to start.
>
> Thanks for any suggestion.
>
> Ignacy
>
> --
> A person is shit's way of making more shit.
> -- S. Barnett, anthropologist.
> _______________________________________________
> ath9k-devel mailing list
> [email protected]
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
--
Best regards,
Eugene
On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki:
> I'll try on yet another one and will tell you the results.
Just tried on ICH7, same thing. The easiest way to reproduce the bug is to
boot into single user mode ("recovery mode" on Ubuntu), in order to prevent
any NetworkManager or udev from interfering. Then, without any attempt to up
the interface, reboot the system by typing "reboot" in a root shell.
--
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
- Bertrand Russell
there is a function in driver "ath9k_htc_reset"
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_main.c#L189
but not sure that is what you are looking for.
2013/5/15 Kalle Valo <[email protected]>:
> Ignacy Gawedzki <[email protected]> writes:
>
>> Hi everyone,
>>
>> This is an old issue, about which it seems the first posts date back to 2009.
>> With the latest possible version of the firmware for AR9271 and the latest
>> possible wireless drivers, the issue is still there. Whether this is still
>> the exact same problem every time remains to be checked, but it is annoying
>> enough to deserve some consideration.
>>
>> The problem is that the driver can't talk to the device if the following
>> conditions are met:
>>
>> - The system cold boots with the USB dongle inserted or the USB dongle is
>> inserted on a running system.
>>
>> - The interface is *not* brought up.
>>
>> - The system (warm) reboots.
>>
>> Then the driver complains about the target being unresponsive after uploading
>> the firmware. Apparently the only way to make it work again is to unplug and
>> then plug the USB dongle back, physically. It seems that if the USB port is
>> not powered down during reboot (which happens with at least two different
>> setups that I've tested it with), the device is left in a broken state.
>>
>> I would gladly help in tracing down this bug if only I knew where to start.
>
> With ath6kl a cold reset helped in a similar situation. Try to find if
> ath9k_htc has a cold/warm reset and see if that helps.
>
> --
> Kalle Valo
> _______________________________________________
> ath9k-devel mailing list
> [email protected]
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
--
Best regards,
Eugene
Hi,
On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote:
> On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki:
> > I'll try on yet another one and will tell you the results.
>
> Just tried on ICH7, same thing. The easiest way to reproduce the bug is to
> boot into single user mode ("recovery mode" on Ubuntu), in order to prevent
> any NetworkManager or udev from interfering. Then, without any attempt to up
> the interface, reboot the system by typing "reboot" in a root shell.
FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it
the same way.
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel:
> Am 15.05.2013 15:42, schrieb Ignacy Gawedzki:
> >Hi everyone,
> >
> >This is an old issue, about which it seems the first posts date back to 2009.
> >With the latest possible version of the firmware for AR9271 and the latest
> >possible wireless drivers, the issue is still there. Whether this is still
> >the exact same problem every time remains to be checked, but it is annoying
> >enough to deserve some consideration.
> >
> >The problem is that the driver can't talk to the device if the following
> >conditions are met:
> >
> > - The system cold boots with the USB dongle inserted or the USB dongle is
> > inserted on a running system.
> >
> > - The interface is *not* brought up.
> >
> > - The system (warm) reboots.
> >
> >Then the driver complains about the target being unresponsive after uploading
> >the firmware. Apparently the only way to make it work again is to unplug and
> >then plug the USB dongle back, physically. It seems that if the USB port is
> >not powered down during reboot (which happens with at least two different
> >setups that I've tested it with), the device is left in a broken state.
> >
> >I would gladly help in tracing down this bug if only I knew where to start.
> >
> >Thanks for any suggestion.
>
> Hi Ignacy,
>
> i can't reproduce this issue on my system. I tested it with 4
> different ath9_htc adapter. Without luck.
Without luck, but it seems you're the lucky one anyway. =)
> Please provide as match
> information as possible:
> - Usb host controller
Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI,
8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly.
> - Adapter manufacture and version, or even better add it to the
> wiki, and upload some images:
> http://wikidevi.com/wiki/Main_Page
TP-Link TL-WN722NC, exactly as the one on the wiki.
> - your kernel version
Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a
customized buildroot, but I can provide the .config if needed).
> I assume it is not firmware. May be there are some issue with boot
> loader on adapter. Are you sure that UART pins are not soldered?
I opened the dongle, managed to solder the metal shield off and the pins
weren't used (all four 48-51, among others).
> Current ath9k_htc do not have mechanism to reset an adapter. I will
> start to work on it after some other issues are done.
Is it physically possible?
> PS: please find some way to enable uart, at least TX pin.
I tried to solder the TX pin, but it's really too tiny. I don't have an iron
so small as to be able to do it, sorry. I would really love to have an UART
connection, but that's just beyond my abilities. BTW, it would really be
great to have a way to send debug message up the USB link, just as with
carl9170.
Thanks for your help anyway, I hope we'll find a way to make that work.
--
Sex on TV doesn't hurt....unless you fall off.
On Thu, May 16, 2013 at 07:45:26PM -0400, Forest Bond wrote:
> On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote:
> > On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki:
> > > I'll try on yet another one and will tell you the results.
> >
> > Just tried on ICH7, same thing. The easiest way to reproduce the bug is to
> > boot into single user mode ("recovery mode" on Ubuntu), in order to prevent
> > any NetworkManager or udev from interfering. Then, without any attempt to up
> > the interface, reboot the system by typing "reboot" in a root shell.
>
> FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it
> the same way.
FWIW, I also met this problem after I added ath9k_htc
to my initrd (via /etc/initramfs-tools/modules).
So I removed it and the issue went away. I first
noticed it after resume from suspend-to-disk, but
later found it doesn't work after warm reboot, too.
The mainboard has Intel H77 chipset, the TL-WN722N is
plugged into USB2.0 port.
Johannes
Ignacy Gawedzki <[email protected]> writes:
> Hi everyone,
>
> This is an old issue, about which it seems the first posts date back to 2009.
> With the latest possible version of the firmware for AR9271 and the latest
> possible wireless drivers, the issue is still there. Whether this is still
> the exact same problem every time remains to be checked, but it is annoying
> enough to deserve some consideration.
>
> The problem is that the driver can't talk to the device if the following
> conditions are met:
>
> - The system cold boots with the USB dongle inserted or the USB dongle is
> inserted on a running system.
>
> - The interface is *not* brought up.
>
> - The system (warm) reboots.
>
> Then the driver complains about the target being unresponsive after uploading
> the firmware. Apparently the only way to make it work again is to unplug and
> then plug the USB dongle back, physically. It seems that if the USB port is
> not powered down during reboot (which happens with at least two different
> setups that I've tested it with), the device is left in a broken state.
>
> I would gladly help in tracing down this bug if only I knew where to start.
With ath6kl a cold reset helped in a similar situation. Try to find if
ath9k_htc has a cold/warm reset and see if that helps.
--
Kalle Valo
I do not know which backport include patch for usb interrupt transfer.
If your kernel still use bulk, it may be the cause of this issue.
Am 15.11.2013 14:47, schrieb Luis R. Rodriguez:
> Cc'ing linux-wireless and ath9k_htc_fw list. The firmware is open
> so any issues can now be debugged in collaboration with the community.
>
> You may try the newer backports:
>
> http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.12/backports-3.12-1.tar.bz2
>
> And as for the firmware it seems to be the latest but I'll let
> others who are maintaining that now chime in.
>
> Luis
>
> On Fri, Nov 15, 2013 at 02:17:43AM -0800, Proffit, Jerome wrote:
>> Hello,
>>
>> Could anybody help with the question below?
>>
>> Thanks,
>>
>> -Jerome
>>
>> -------------------------------------------
>>
>> We are trying to bring up the VIA TECH WLAN USB dongle (AR9271 based
>> chip) on our platform. We have downloaded the back port
>> drivers from:
>> https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10/backports-3.10-1.tar.bz2
>> and cross compiled to our target (Tensilica -233). The Firmware
>> (htc_9271.fw) is downloaded from:
>> http://wireless.kernel.org/download/htc_fw/1.3/htc_9271.fw and copied
>> the same into /lib/firmware/ on the target. Loaded all generated
>> modules (.ko) and connect the WiFi over USB dongle into the USB
>> connector. But the device is not getting initialized. Please find the
>> log as below. Please help in this regard.
>>
>>
>> Log:
>> usb 1-1: new high speed USB device using dwc_otg and address 2
>> usb 1-1: configuration #1 chosen from 1 choice
>> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
>> usb 1-1: firmware: requesting htc_9271.fw
>> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51000
>> ath9k_htc 1-1:1.0: ath9k_htc: Target is unresponsive
>> ath9k_htc: Failed to initialize the device
>>
>>
>> Product:VIA USB2.0 WLAN
>> Manufacturer:VIA TECH
>>
>> Vendor id: 0x040d
>> Product id: 0x3801
>> ----------------------------------------
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Oleksij
On Fri, Nov 15, 2013 at 5:04 PM, Oleksij Rempel <[email protected]> wrote:
> Am 15.11.2013 16:33, schrieb Luis R. Rodriguez:
>> On Fri, Nov 15, 2013 at 3:36 PM, Oleksij Rempel <[email protected]> wrote:
>>> Am 15.11.2013 15:29, schrieb Luis R. Rodriguez:
>>>> On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
>>>>> I do not know which backport include patch for usb interrupt transfer.
>>>>
>>>> Which patch are you referring to? The backports project releases match
>>>> the Linux kernel releases, so the backports-3.12 release is based on
>>>> linux v3.12, we can check what kernel the patch you are describing got
>>>> merged into Linux by doing:
>>>>
>>>> git describe --contains gitsum
>>>
>>> i mean:
>>>
>>> commit 2f5e3ecfc155449987d64028ff6b73f29cd1ef8b
>>> Author: Oleksij Rempel <[email protected]>
>>> Date: Tue Aug 13 09:29:34 2013 +0200
>>>
>>> ath9k_htc: do not use bulk on EP3 and EP4
>>
>> OK that is upstream commit ID 2b721118b7
>>
>> mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains
>> 2b721118b7821107757eb1d37af4b60e877b27e7
>> v3.12-rc1~132^2~84^2^2~88
>>
>> This means that patch got merged into v3.12-rc1 which means the
>> backports release based on v3.12 will have it.
>>
>>> If it is already included, then try to revert.
>>
>> What do you mean? Are you saying to try to revert that patch in case
>> v3.12 backports release causes issues with the card?
>
> yes
>
>> It seems the user
>> of this card had issues with the v3.10 release of backports which
>> would not have this patch merged.
>
> Ok. Thank you.
So to be clear -- you would recommend testing the new v3.12 release
that *has* the patch then?
Luis
Cc'ing linux-wireless and ath9k_htc_fw list. The firmware is open
so any issues can now be debugged in collaboration with the community.
You may try the newer backports:
http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.12/backports-3.12-1.tar.bz2
And as for the firmware it seems to be the latest but I'll let
others who are maintaining that now chime in.
Luis
On Fri, Nov 15, 2013 at 02:17:43AM -0800, Proffit, Jerome wrote:
> Hello,
>
> Could anybody help with the question below?
>
> Thanks,
>
> -Jerome
>
> -------------------------------------------
>
> We are trying to bring up the VIA TECH WLAN USB dongle (AR9271 based
> chip) on our platform. We have downloaded the back port
> drivers from:
> https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10/backports-3.10-1.tar.bz2
> and cross compiled to our target (Tensilica -233). The Firmware
> (htc_9271.fw) is downloaded from:
> http://wireless.kernel.org/download/htc_fw/1.3/htc_9271.fw and copied
> the same into /lib/firmware/ on the target. Loaded all generated
> modules (.ko) and connect the WiFi over USB dongle into the USB
> connector. But the device is not getting initialized. Please find the
> log as below. Please help in this regard.
>
>
> Log:
> usb 1-1: new high speed USB device using dwc_otg and address 2
> usb 1-1: configuration #1 chosen from 1 choice
> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
> usb 1-1: firmware: requesting htc_9271.fw
> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51000
> ath9k_htc 1-1:1.0: ath9k_htc: Target is unresponsive
> ath9k_htc: Failed to initialize the device
>
>
> Product:VIA USB2.0 WLAN
> Manufacturer:VIA TECH
>
> Vendor id: 0x040d
> Product id: 0x3801
> ----------------------------------------
>
>
On Fri, Nov 15, 2013 at 3:36 PM, Oleksij Rempel <[email protected]> wrote:
> Am 15.11.2013 15:29, schrieb Luis R. Rodriguez:
>> On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
>>> I do not know which backport include patch for usb interrupt transfer.
>>
>> Which patch are you referring to? The backports project releases match
>> the Linux kernel releases, so the backports-3.12 release is based on
>> linux v3.12, we can check what kernel the patch you are describing got
>> merged into Linux by doing:
>>
>> git describe --contains gitsum
>
> i mean:
>
> commit 2f5e3ecfc155449987d64028ff6b73f29cd1ef8b
> Author: Oleksij Rempel <[email protected]>
> Date: Tue Aug 13 09:29:34 2013 +0200
>
> ath9k_htc: do not use bulk on EP3 and EP4
OK that is upstream commit ID 2b721118b7
mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains
2b721118b7821107757eb1d37af4b60e877b27e7
v3.12-rc1~132^2~84^2^2~88
This means that patch got merged into v3.12-rc1 which means the
backports release based on v3.12 will have it.
> If it is already included, then try to revert.
What do you mean? Are you saying to try to revert that patch in case
v3.12 backports release causes issues with the card? It seems the user
of this card had issues with the v3.10 release of backports which
would not have this patch merged.
Luis
On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
> I do not know which backport include patch for usb interrupt transfer.
Which patch are you referring to? The backports project releases match
the Linux kernel releases, so the backports-3.12 release is based on
linux v3.12, we can check what kernel the patch you are describing got
merged into Linux by doing:
git describe --contains gitsum
where the gitsum is the gitsum of the patch.
Luis
Am 15.11.2013 15:29, schrieb Luis R. Rodriguez:
> On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
>> I do not know which backport include patch for usb interrupt transfer.
>
> Which patch are you referring to? The backports project releases match
> the Linux kernel releases, so the backports-3.12 release is based on
> linux v3.12, we can check what kernel the patch you are describing got
> merged into Linux by doing:
>
> git describe --contains gitsum
i mean:
commit 2f5e3ecfc155449987d64028ff6b73f29cd1ef8b
Author: Oleksij Rempel <[email protected]>
Date: Tue Aug 13 09:29:34 2013 +0200
ath9k_htc: do not use bulk on EP3 and EP4
If it is already included, then try to revert.
--
Regards,
Oleksij
Am 15.11.2013 16:33, schrieb Luis R. Rodriguez:
> On Fri, Nov 15, 2013 at 3:36 PM, Oleksij Rempel <[email protected]> wrote:
>> Am 15.11.2013 15:29, schrieb Luis R. Rodriguez:
>>> On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
>>>> I do not know which backport include patch for usb interrupt transfer.
>>>
>>> Which patch are you referring to? The backports project releases match
>>> the Linux kernel releases, so the backports-3.12 release is based on
>>> linux v3.12, we can check what kernel the patch you are describing got
>>> merged into Linux by doing:
>>>
>>> git describe --contains gitsum
>>
>> i mean:
>>
>> commit 2f5e3ecfc155449987d64028ff6b73f29cd1ef8b
>> Author: Oleksij Rempel <[email protected]>
>> Date: Tue Aug 13 09:29:34 2013 +0200
>>
>> ath9k_htc: do not use bulk on EP3 and EP4
>
> OK that is upstream commit ID 2b721118b7
>
> mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains
> 2b721118b7821107757eb1d37af4b60e877b27e7
> v3.12-rc1~132^2~84^2^2~88
>
> This means that patch got merged into v3.12-rc1 which means the
> backports release based on v3.12 will have it.
>
>> If it is already included, then try to revert.
>
> What do you mean? Are you saying to try to revert that patch in case
> v3.12 backports release causes issues with the card?
yes
> It seems the user
> of this card had issues with the v3.10 release of backports which
> would not have this patch merged.
Ok. Thank you.
--
Regards,
Oleksij
Am 15.11.2013 17:07, schrieb Luis R. Rodriguez:
> On Fri, Nov 15, 2013 at 5:04 PM, Oleksij Rempel <[email protected]> wrote:
>> Am 15.11.2013 16:33, schrieb Luis R. Rodriguez:
>>> On Fri, Nov 15, 2013 at 3:36 PM, Oleksij Rempel <[email protected]> wrote:
>>>> Am 15.11.2013 15:29, schrieb Luis R. Rodriguez:
>>>>> On Fri, Nov 15, 2013 at 3:18 PM, Oleksij Rempel <[email protected]> wrote:
>>>>>> I do not know which backport include patch for usb interrupt transfer.
>>>>>
>>>>> Which patch are you referring to? The backports project releases match
>>>>> the Linux kernel releases, so the backports-3.12 release is based on
>>>>> linux v3.12, we can check what kernel the patch you are describing got
>>>>> merged into Linux by doing:
>>>>>
>>>>> git describe --contains gitsum
>>>>
>>>> i mean:
>>>>
>>>> commit 2f5e3ecfc155449987d64028ff6b73f29cd1ef8b
>>>> Author: Oleksij Rempel <[email protected]>
>>>> Date: Tue Aug 13 09:29:34 2013 +0200
>>>>
>>>> ath9k_htc: do not use bulk on EP3 and EP4
>>>
>>> OK that is upstream commit ID 2b721118b7
>>>
>>> mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains
>>> 2b721118b7821107757eb1d37af4b60e877b27e7
>>> v3.12-rc1~132^2~84^2^2~88
>>>
>>> This means that patch got merged into v3.12-rc1 which means the
>>> backports release based on v3.12 will have it.
>>>
>>>> If it is already included, then try to revert.
>>>
>>> What do you mean? Are you saying to try to revert that patch in case
>>> v3.12 backports release causes issues with the card?
>>
>> yes
>>
>>> It seems the user
>>> of this card had issues with the v3.10 release of backports which
>>> would not have this patch merged.
>>
>> Ok. Thank you.
>
> So to be clear -- you would recommend testing the new v3.12 release
> that *has* the patch then?
Yes. Before this patch ath9k_htc was overwriting usb descriptor from
driver. The problem with it - USB subsystem do not have this option, so
not all usb host controller drivers will use updated information.
In case driver indeed use Bulk instead of Int, it can still cause other
problems. For example not all controller can work with 64 byte bulk frames.
This behaviour was added back in 2010 and should be workaround for speed
problem on EP4, which is intensively used by REG_READ/WRITE.
Right now there are two options:
- use Bulk, but fail on some controllers
- use Int but be damn slow on other controllers.
After i tested ath9k-htc on different usb HC, i will not wonder that
there can be other problems too. Here is some info about known usb issues:
https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues
--
Regards,
Oleksij