* [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-15 13:42 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-15 13:42 UTC (permalink / raw) To: ath9k-devel 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* ath9k_htc: Target is unresponsive @ 2013-05-15 13:42 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-15 13:42 UTC (permalink / raw) To: ath9k-devel, linux-wireless 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-15 13:42 ` Ignacy Gawedzki @ 2013-05-15 14:43 ` Eugene Krasnikov -1 siblings, 0 replies; 39+ messages in thread From: Eugene Krasnikov @ 2013-05-15 14:43 UTC (permalink / raw) To: ath9k-devel 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 <i@lri.fr>: > 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 > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Best regards, Eugene ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-15 14:43 ` Eugene Krasnikov 0 siblings, 0 replies; 39+ messages in thread From: Eugene Krasnikov @ 2013-05-15 14:43 UTC (permalink / raw) To: Ignacy Gawedzki, ath9k-devel, linux-wireless 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 <i@lri.fr>: > 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 > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Best regards, Eugene ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-15 13:42 ` Ignacy Gawedzki @ 2013-05-15 14:50 ` Kalle Valo -1 siblings, 0 replies; 39+ messages in thread From: Kalle Valo @ 2013-05-15 14:50 UTC (permalink / raw) To: ath9k-devel Ignacy Gawedzki <i@lri.fr> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-15 14:50 ` Kalle Valo 0 siblings, 0 replies; 39+ messages in thread From: Kalle Valo @ 2013-05-15 14:50 UTC (permalink / raw) To: Ignacy Gawedzki; +Cc: ath9k-devel, linux-wireless Ignacy Gawedzki <i@lri.fr> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-15 14:50 ` Kalle Valo @ 2013-05-15 16:11 ` Eugene Krasnikov -1 siblings, 0 replies; 39+ messages in thread From: Eugene Krasnikov @ 2013-05-15 16:11 UTC (permalink / raw) To: ath9k-devel 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 <kvalo@qca.qualcomm.com>: > Ignacy Gawedzki <i@lri.fr> 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 > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Best regards, Eugene ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-15 16:11 ` Eugene Krasnikov 0 siblings, 0 replies; 39+ messages in thread From: Eugene Krasnikov @ 2013-05-15 16:11 UTC (permalink / raw) To: Kalle Valo; +Cc: Ignacy Gawedzki, ath9k-devel, linux-wireless 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 <kvalo@qca.qualcomm.com>: > Ignacy Gawedzki <i@lri.fr> 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 > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Best regards, Eugene ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-15 16:11 ` Eugene Krasnikov @ 2013-05-15 16:34 ` Ignacy Gawedzki -1 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-15 16:34 UTC (permalink / raw) To: ath9k-devel 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-15 16:34 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-15 16:34 UTC (permalink / raw) To: Eugene Krasnikov; +Cc: Kalle Valo, ath9k-devel, linux-wireless 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-15 13:42 ` Ignacy Gawedzki @ 2013-05-16 13:27 ` Oleksij Rempel -1 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-05-16 13:27 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 13:27 ` Oleksij Rempel 0 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-05-16 13:27 UTC (permalink / raw) To: Ignacy Gawedzki, ath9k-devel, linux-wireless 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 13:27 ` Oleksij Rempel @ 2013-05-16 17:20 ` Ignacy Gawedzki -1 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 17:20 UTC (permalink / raw) To: ath9k-devel 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 17:20 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 17:20 UTC (permalink / raw) To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 17:20 ` Ignacy Gawedzki @ 2013-05-16 17:46 ` Oleksij Rempel -1 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-05-16 17:46 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 17:46 ` Oleksij Rempel 0 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-05-16 17:46 UTC (permalink / raw) To: Ignacy Gawedzki, ath9k-devel, linux-wireless 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 17:46 ` Oleksij Rempel @ 2013-05-16 18:50 ` Ignacy Gawedzki -1 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 18:50 UTC (permalink / raw) To: ath9k-devel 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] =- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 18:50 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 18:50 UTC (permalink / raw) To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless 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] =- ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 18:50 ` Ignacy Gawedzki @ 2013-05-16 23:48 ` Ignacy Gawedzki -1 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 23:48 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 23:48 ` Ignacy Gawedzki 0 siblings, 0 replies; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-16 23:48 UTC (permalink / raw) To: Oleksij Rempel, ath9k-devel, linux-wireless 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 23:48 ` Ignacy Gawedzki @ 2013-05-16 23:45 ` Forest Bond -1 siblings, 0 replies; 39+ messages in thread From: Forest Bond @ 2013-05-16 23:45 UTC (permalink / raw) To: ath9k-devel 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130516/1ee06ad9/attachment.pgp ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-16 23:45 ` Forest Bond 0 siblings, 0 replies; 39+ messages in thread From: Forest Bond @ 2013-05-16 23:45 UTC (permalink / raw) To: Ignacy Gawedzki, Oleksij Rempel, ath9k-devel, linux-wireless [-- Attachment #1: Type: text/plain, Size: 720 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-16 23:45 ` Forest Bond @ 2013-05-17 6:00 ` Johannes Stezenbach -1 siblings, 0 replies; 39+ messages in thread From: Johannes Stezenbach @ 2013-05-17 6:00 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-05-17 6:00 ` Johannes Stezenbach 0 siblings, 0 replies; 39+ messages in thread From: Johannes Stezenbach @ 2013-05-17 6:00 UTC (permalink / raw) To: Forest Bond; +Cc: Ignacy Gawedzki, Oleksij Rempel, ath9k-devel, linux-wireless 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 6:00 ` Johannes Stezenbach (?) @ 2013-05-17 8:07 ` Oleksij Rempel 2013-05-17 8:15 ` Ignacy Gawedzki -1 siblings, 1 reply; 39+ messages in thread From: Oleksij Rempel @ 2013-05-17 8:07 UTC (permalink / raw) To: ath9k-devel Am 17.05.2013 08:00, schrieb Johannes Stezenbach: > 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. OK, now i was able to reproduce it on ar9271. In attachment is the log i grubbed form adapter. Lines starting with ######### are my comments -- Regards, Oleksij -------------- next part -------------- A non-text attachment was scrubbed... Name: ath9k_htc.log Type: text/x-log Size: 6370 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130517/223692c5/attachment-0001.bin ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 8:07 ` Oleksij Rempel @ 2013-05-17 8:15 ` Ignacy Gawedzki 2013-05-17 8:31 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-17 8:15 UTC (permalink / raw) To: ath9k-devel On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: > OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? > In attachment is the log i grubbed form adapter. > Lines starting with ######### are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? -- /* This is not a comment */ ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 8:15 ` Ignacy Gawedzki @ 2013-05-17 8:31 ` Oleksij Rempel 2013-05-17 9:33 ` Eugene Krasnikov 0 siblings, 1 reply; 39+ messages in thread From: Oleksij Rempel @ 2013-05-17 8:31 UTC (permalink / raw) To: ath9k-devel Am 17.05.2013 10:15, schrieb Ignacy Gawedzki: > On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: >> OK, now i was able to reproduce it on ar9271. > > Ah, good, but what did you do wrong previously then? Nothing. I needed to start single user mode first, and reboot the system to et this error. > >> In attachment is the log i grubbed form adapter. >> Lines starting with ######### are my comments > > At least we can already diagnose a problem with A_PRINTF. :/ > > Do these logs speak to anyone? > Here are some explanations: "ASIC-ROM_1.8" - is start of boot loader on device. It should go immediately after adapter got power. "8. download" - at this stage bootloader is ready to receive firmware. "[Tgt running" - firmware was downloaded and running. "!USB suspend" - means usb suspend was initiated And that is probably our problem. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 8:31 ` Oleksij Rempel @ 2013-05-17 9:33 ` Eugene Krasnikov 2013-05-17 10:30 ` Ignacy Gawedzki 0 siblings, 1 reply; 39+ messages in thread From: Eugene Krasnikov @ 2013-05-17 9:33 UTC (permalink / raw) To: ath9k-devel Did anybody tried to force the usb to go to suspend? If something like this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" will help to reproduce this issue? 2013/5/17 Oleksij Rempel <linux@rempel-privat.de>: > Am 17.05.2013 10:15, schrieb Ignacy Gawedzki: > >> On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: >>> >>> OK, now i was able to reproduce it on ar9271. >> >> >> Ah, good, but what did you do wrong previously then? > > > Nothing. I needed to start single user mode first, and reboot the system to > et this error. > > >> >>> In attachment is the log i grubbed form adapter. >>> Lines starting with ######### are my comments >> >> >> At least we can already diagnose a problem with A_PRINTF. :/ >> >> Do these logs speak to anyone? >> > > Here are some explanations: > "ASIC-ROM_1.8" - is start of boot loader on device. It should go immediately > after adapter got power. > "8. download" - at this stage bootloader is ready to receive firmware. > "[Tgt running" - firmware was downloaded and running. > "!USB suspend" - means usb suspend was initiated > And that is probably our problem. > > -- > Regards, > Oleksij -- Best regards, Eugene ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 9:33 ` Eugene Krasnikov @ 2013-05-17 10:30 ` Ignacy Gawedzki 2013-05-17 10:40 ` Ignacy Gawedzki 0 siblings, 1 reply; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-17 10:30 UTC (permalink / raw) To: ath9k-devel On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: > Did anybody tried to force the usb to go to suspend? If something like > this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" > will help to reproduce this issue? This way of forcing suspend is apparently deprecated and doesn't work in my case. I tried to set power/control to auto, but it has no apparent effect on anything. :( -- I drive too fast to worry about cholesterol. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 10:30 ` Ignacy Gawedzki @ 2013-05-17 10:40 ` Ignacy Gawedzki 2013-05-17 10:48 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-17 10:40 UTC (permalink / raw) To: ath9k-devel On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki: > On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: > > Did anybody tried to force the usb to go to suspend? If something like > > this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" > > will help to reproduce this issue? > > This way of forcing suspend is apparently deprecated and doesn't work in my > case. I tried to set power/control to auto, but it has no apparent effect on > anything. :( Okay, I did manage to make it fail. In single-user mode (to prevent any daemon from interfering), I plugged the dongle, set power/control to "auto" and after a few seconds unloaded/reloaded the ath9k_htc module. This made the target unresponsive. If I do the same without setting power/control to "auto" (it is "on" by default), then unloading/reloading the module doesn't make the device unresponsive. BTW, Oleksij, just out of curiosity, how did you manage to solder those UART pins? -- I have not lost my mind, it's backed up on disk somewhere. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 10:40 ` Ignacy Gawedzki @ 2013-05-17 10:48 ` Oleksij Rempel 2013-05-17 11:22 ` Ignacy Gawedzki 0 siblings, 1 reply; 39+ messages in thread From: Oleksij Rempel @ 2013-05-17 10:48 UTC (permalink / raw) To: ath9k-devel Am 17.05.2013 12:40, schrieb Ignacy Gawedzki: > On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki: >> On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: >>> Did anybody tried to force the usb to go to suspend? If something like >>> this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" >>> will help to reproduce this issue? >> >> This way of forcing suspend is apparently deprecated and doesn't work in my >> case. I tried to set power/control to auto, but it has no apparent effect on >> anything. :( > > Okay, I did manage to make it fail. In single-user mode (to prevent any > daemon from interfering), I plugged the dongle, set power/control to "auto" > and after a few seconds unloaded/reloaded the ath9k_htc module. This made the > target unresponsive. If I do the same without setting power/control to "auto" > (it is "on" by default), then unloading/reloading the module doesn't make the > device unresponsive. > > BTW, Oleksij, just out of curiosity, how did you manage to solder those UART > pins? > Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 10:48 ` Oleksij Rempel @ 2013-05-17 11:22 ` Ignacy Gawedzki 2013-05-17 11:41 ` Ignacy Gawedzki 0 siblings, 1 reply; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-17 11:22 UTC (permalink / raw) To: ath9k-devel On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: > Here an example of soldered pins, it is ar7010 device. I attached > here jtag pins. > https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ > here is a workaround for this issue, please test it: > https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend It seems to work just right on the PC. I'll test on the RPi and let you know. Big thanks! -- :wq! ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 11:22 ` Ignacy Gawedzki @ 2013-05-17 11:41 ` Ignacy Gawedzki 2013-05-17 12:00 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Ignacy Gawedzki @ 2013-05-17 11:41 UTC (permalink / raw) To: ath9k-devel On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: > On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: > > Here an example of soldered pins, it is ar7010 device. I attached > > here jtag pins. > > https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk > > Wow, my soldering iron has too broad a tip for that precision work. :/ > > > here is a workaround for this issue, please test it: > > https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend > > It seems to work just right on the PC. I'll test on the RPi and let you know. Works on the RPi as well! Are there any implications for this being a workaround and not a proper fix? -- Sex on TV doesn't hurt....unless you fall off. ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 11:41 ` Ignacy Gawedzki @ 2013-05-17 12:00 ` Oleksij Rempel 2013-05-17 15:37 ` Adrian Chadd 0 siblings, 1 reply; 39+ messages in thread From: Oleksij Rempel @ 2013-05-17 12:00 UTC (permalink / raw) To: ath9k-devel Am 17.05.2013 13:41, schrieb Ignacy Gawedzki: > On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: >> On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: >>> Here an example of soldered pins, it is ar7010 device. I attached >>> here jtag pins. >>> https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk >> >> Wow, my soldering iron has too broad a tip for that precision work. :/ >> >>> here is a workaround for this issue, please test it: >>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend >> >> It seems to work just right on the PC. I'll test on the RPi and let you know. > > Works on the RPi as well! Are there any implications for this being a > workaround and not a proper fix? Yes, i do not know what i did. I will need to find out, what it actually should do. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 12:00 ` Oleksij Rempel @ 2013-05-17 15:37 ` Adrian Chadd 2013-05-17 18:51 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Adrian Chadd @ 2013-05-17 15:37 UTC (permalink / raw) To: ath9k-devel On 17 May 2013 05:00, Oleksij Rempel <linux@rempel-privat.de> wrote: >>>> here is a workaround for this issue, please test it: >>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend >>> >>> It seems to work just right on the PC. I'll test on the RPi and let you know. >> >> Works on the RPi as well! Are there any implications for this being a >> workaround and not a proper fix? > > Yes, i do not know what i did. I will need to find out, what it actually > should do. ... hm, is this reset type not working? Is this the whole "reset through watchdog" versus "reset through reset" thing you talked about a couple weeks ago? Adrian ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 15:37 ` Adrian Chadd @ 2013-05-17 18:51 ` Oleksij Rempel 2013-05-18 10:59 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Oleksij Rempel @ 2013-05-17 18:51 UTC (permalink / raw) To: ath9k-devel Am 17.05.2013 17:37, schrieb Adrian Chadd: > On 17 May 2013 05:00, Oleksij Rempel <linux@rempel-privat.de> wrote: > >>>>> here is a workaround for this issue, please test it: >>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend >>>> >>>> It seems to work just right on the PC. I'll test on the RPi and let you know. >>> >>> Works on the RPi as well! Are there any implications for this being a >>> workaround and not a proper fix? >> >> Yes, i do not know what i did. I will need to find out, what it actually >> should do. > > ... hm, is this reset type not working? Is this the whole "reset > through watchdog" versus "reset through reset" thing you talked about > a couple weeks ago? No, it is different issue, at least at different path. I did some more test and i'll try now to reflect all collected informations: - Only ar9271 devices are affected. ar7010 seems to be fine. - the issue is in: target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c: in _fw_usb_suspend_reboot() this function is called from two points: - _fw_usbfifo_recv_command(), this one is triggered if host go to supend - _fw_usb_fw_task(), this function is called on different events, including reset, some cases if suspend? and resume? last was never called. I'll need to check how exactly this part is working. So, _fw_usb_suspend_reboot() should theoretically prepare adapter for suspend, to reduce power consumption. But there are fallowing problems with this function: - some hosts will completely power down this device. Absolutely no power is consumed and all preparations made by this function are lost (cald reset). - some hosts keep usb port powered to be able to charge some device. It is done only on laptops/pcs connected to power supply (i have one of this, so i was able to check it). In this case we go to some undefined state, and probably prepared to receive firmware. In this state device use about 40mA. - in all cases linux will do reset on resume. So all side effects produced by _fw_usb_suspend_reboot() are reseted. This is why it is so hard to reproduce this case. The problem what we now have is passed from _fw_usb_fw_task(), in this case adapter will restart to boot loader and got ready to receive firmware. But it looks like usb descriptor in this case is incomplete: here is brocken descriptor: Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice 1.08 iManufacturer 16 iProduct 32 iSerial 48 bNumConfigurations 1 ---end--- here is ok descriptor: Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice 1.08 iManufacturer 16 ATHEROS iProduct 32 UB91C iSerial 48 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA --- and some more -------- after i disabled this function... see my workaround patch. I got fallowing process. Host send suspend command.... no changes was made, (currently i do not know what should we send as response), host trying to send it some more times and the send reset. After this, adapter is rebooting and firmware is uploaded... so it comes to normal working state. There is no way to support WoW here. So, there is no need to have some sort of reduced power state. I assume, we can remove most part of suspend sequence from firmware. And replace it with some correct response to the host that every thing is ok, or that we do not support this bit. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-05-17 18:51 ` Oleksij Rempel @ 2013-05-18 10:59 ` Oleksij Rempel 0 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-05-18 10:59 UTC (permalink / raw) To: ath9k-devel To be able to reproduce this bug a bit easier, i added usbautosuspend to ath9k_htc. There is some interesting statistic of power usage for now: ar9271: ? power on + wifi on = 160 uA ? "ifconfig wlan0 down" without autosuspend = 60 uA ? "ifconfig wlan0" down with autosupend = 1,6 uA Current problem is to bring adapter back. Am 17.05.2013 20:51, schrieb Oleksij Rempel: > Am 17.05.2013 17:37, schrieb Adrian Chadd: >> On 17 May 2013 05:00, Oleksij Rempel <linux@rempel-privat.de> wrote: >> >>>>>> here is a workaround for this issue, please test it: >>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend >>>>> >>>>> It seems to work just right on the PC. I'll test on the RPi and let you know. >>>> >>>> Works on the RPi as well! Are there any implications for this being a >>>> workaround and not a proper fix? >>> >>> Yes, i do not know what i did. I will need to find out, what it actually >>> should do. >> >> ... hm, is this reset type not working? Is this the whole "reset >> through watchdog" versus "reset through reset" thing you talked about >> a couple weeks ago? > > No, it is different issue, at least at different path. > I did some more test and i'll try now to reflect all collected informations: > - Only ar9271 devices are affected. ar7010 seems to be fine. > - the issue is in: > target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c: > in _fw_usb_suspend_reboot() > > this function is called from two points: > - _fw_usbfifo_recv_command(), this one is triggered if host go to supend > - _fw_usb_fw_task(), this function is called on different events, > including reset, some cases if suspend? and resume? last was never > called. I'll need to check how exactly this part is working. > > So, _fw_usb_suspend_reboot() should theoretically prepare adapter for > suspend, to reduce power consumption. But there are fallowing problems > with this function: > - some hosts will completely power down this device. Absolutely no power > is consumed and all preparations made by this function are lost (cald > reset). > - some hosts keep usb port powered to be able to charge some device. It > is done only on laptops/pcs connected to power supply (i have one of > this, so i was able to check it). In this case we go to some undefined > state, and probably prepared to receive firmware. In this state device > use about 40mA. > - in all cases linux will do reset on resume. So all side effects > produced by _fw_usb_suspend_reboot() are reseted. This is why it is so > hard to reproduce this case. > > The problem what we now have is passed from _fw_usb_fw_task(), in this > case adapter will restart to boot loader and got ready to receive > firmware. But it looks like usb descriptor in this case is incomplete: > > here is brocken descriptor: > Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 64 > idVendor 0x0cf3 Atheros Communications, Inc. > idProduct 0x9271 AR9271 802.11n > bcdDevice 1.08 > iManufacturer 16 > iProduct 32 > iSerial 48 > bNumConfigurations 1 > ---end--- > > > here is ok descriptor: > > Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 64 > idVendor 0x0cf3 Atheros Communications, Inc. > idProduct 0x9271 AR9271 802.11n > bcdDevice 1.08 > iManufacturer 16 ATHEROS > iProduct 32 UB91C > iSerial 48 12345 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 60 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > --- and some more -------- > > > after i disabled this function... see my workaround patch. I got > fallowing process. Host send suspend command.... no changes was made, > (currently i do not know what should we send as response), host trying > to send it some more times and the send reset. After this, adapter is > rebooting and firmware is uploaded... so it comes to normal working state. > > There is no way to support WoW here. So, there is no need to have some > sort of reduced power state. I assume, we can remove most part of > suspend sequence from firmware. And replace it with some correct > response to the host that every thing is ok, or that we do not support > this bit. > -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive @ 2013-11-13 11:23 Rajeshwar Bandi 2013-11-13 14:39 ` Oleksij Rempel 0 siblings, 1 reply; 39+ messages in thread From: Rajeshwar Bandi @ 2013-11-13 11:23 UTC (permalink / raw) To: ath9k-devel Hi, We are testing the WiFi over USB dongle (AR9271 chip based) on our platform and find the log info as below. Please help in this regard. 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 Thanks, Rajeshwar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131113/e1d341fa/attachment.htm ^ permalink raw reply [flat|nested] 39+ messages in thread
* [ath9k-devel] ath9k_htc: Target is unresponsive 2013-11-13 11:23 Rajeshwar Bandi @ 2013-11-13 14:39 ` Oleksij Rempel 0 siblings, 0 replies; 39+ messages in thread From: Oleksij Rempel @ 2013-11-13 14:39 UTC (permalink / raw) To: ath9k-devel Hi Rajeshwar, we need more information. Kernel and firmware version? It will be really good if you will get firmware log. In this case you should use UART port on this chip. Am 13.11.2013 12:23, schrieb Rajeshwar Bandi: > Hi, > > We are testing the WiFi over USB dongle (AR9271 chip based) on our > platform and find the log info as below. Please help in this regard. > > > > 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 > > > > > > Thanks, > > Rajeshwar > > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- Regards, Oleksij ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2013-11-13 14:39 UTC | newest] Thread overview: 39+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-15 13:42 [ath9k-devel] ath9k_htc: Target is unresponsive Ignacy Gawedzki 2013-05-15 13:42 ` Ignacy Gawedzki 2013-05-15 14:43 ` [ath9k-devel] " Eugene Krasnikov 2013-05-15 14:43 ` Eugene Krasnikov 2013-05-15 14:50 ` Kalle Valo 2013-05-15 14:50 ` Kalle Valo 2013-05-15 16:11 ` Eugene Krasnikov 2013-05-15 16:11 ` Eugene Krasnikov 2013-05-15 16:34 ` Ignacy Gawedzki 2013-05-15 16:34 ` Ignacy Gawedzki 2013-05-16 13:27 ` Oleksij Rempel 2013-05-16 13:27 ` Oleksij Rempel 2013-05-16 17:20 ` Ignacy Gawedzki 2013-05-16 17:20 ` Ignacy Gawedzki 2013-05-16 17:46 ` Oleksij Rempel 2013-05-16 17:46 ` Oleksij Rempel 2013-05-16 18:50 ` Ignacy Gawedzki 2013-05-16 18:50 ` Ignacy Gawedzki 2013-05-16 23:48 ` Ignacy Gawedzki 2013-05-16 23:48 ` Ignacy Gawedzki 2013-05-16 23:45 ` Forest Bond 2013-05-16 23:45 ` Forest Bond 2013-05-17 6:00 ` Johannes Stezenbach 2013-05-17 6:00 ` Johannes Stezenbach 2013-05-17 8:07 ` Oleksij Rempel 2013-05-17 8:15 ` Ignacy Gawedzki 2013-05-17 8:31 ` Oleksij Rempel 2013-05-17 9:33 ` Eugene Krasnikov 2013-05-17 10:30 ` Ignacy Gawedzki 2013-05-17 10:40 ` Ignacy Gawedzki 2013-05-17 10:48 ` Oleksij Rempel 2013-05-17 11:22 ` Ignacy Gawedzki 2013-05-17 11:41 ` Ignacy Gawedzki 2013-05-17 12:00 ` Oleksij Rempel 2013-05-17 15:37 ` Adrian Chadd 2013-05-17 18:51 ` Oleksij Rempel 2013-05-18 10:59 ` Oleksij Rempel -- strict thread matches above, loose matches on Subject: below -- 2013-11-13 11:23 Rajeshwar Bandi 2013-11-13 14:39 ` 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.