ath9k_htc: Target is unresponsive

[EtiennePerot]

Hello,

There has been a longstanding bug with the ath9k_htc driver whereby the firmware is not properly unloaded until the USB adapter is power-cycled.

How to reproduce:

1. Connect the computer to a powered USB hub
2. Plug the USB adapter into one of the hub's ports
3. Boot the computer, USB adapter works perfectly
4. Reboot the computer without touching any cables
5. Adapter does not work anymore until power-cycled, by either unplugging and replugging the dongle, or unplugging and replugging the USB hub.

dmesg shows the following output during the second boot:

usb 1-1.2.4: ath9k_htc: Firmware htc_9271.fw requested
usbcore: registered new interface driver ath9k_htc
usb 1-1.2.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
ath9k_htc 1-1.2.4:1.0: ath9k_htc: Target is unresponsive
ath9k_htc: Failed to initialize the device
usb 1-1.2.4: ath9k_htc: USB layer deinitialized

This is a more common use case than it used to be, thanks to the number of guides suggesting such a setup to make cheap DIY router-like devices with Raspberry Pis, as is my case.

There are a lot of reports and mailing list threads on the web about this issue ([Google for "ath9k_htc: Target is unresponsive"](https://encrypted.google.com/search?q="ath9k_htc%3A Target is unresponsive")):

• Long March 2012 thread about the issue
• Raspberry Pi forum thread
• Another thread
• Yet another thread
• Same issue on firmware ar9271, with patch for it

It would be nice if this issue got fixed. I have verified that this is still an issue with the latest version of the firmware (cc765de).

[erikarn]

I honestly don't think it's a firmware issue. At least in most cases.

The driver should see if the firmware is up and loaded before continuing. If it's up, it could try restarting things. It shouldn't just squirt firmware down upon probe/attach.

So I suggest taking a closer look at what the device probe, attacg, sleep, resume code does. Maybe power down the usb port first, too, if possible.

Adrian

Sent from my Palm Pre on AT&T
On Mar 16, 2013 9:00 PM, Etienne Perot <notifications@github.com> wrote:

Hello,

There has been a longstanding bug with the ath9k_htc driver whereby the firmware is not properly unloaded until the USB adapter is power-cycled.

How to reproduce:

1. Connect the computer to the hub
2. Plug the USB adapter into one of the hub's ports
3. Boot the computer, USB adapter works perfectly
4. Reboot the computer without touching any cables
5. Adapter does not work anymore until power-cycled, by either unplugging and replugging the dongle, or unplugging and replugging the USB hub.

dmesg shows the following output during the second boot:

usb 1-1.2.4: ath9k_htc: Firmware htc_9271.fw requested

usbcore: registered new interface driver ath9k_htc

usb 1-1.2.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980

ath9k_htc 1-1.2.4:1.0: ath9k_htc: Target is unresponsive

ath9k_htc: Failed to initialize the device

usb 1-1.2.4: ath9k_htc: USB layer deinitialized

This is a more common use case than it used to be, thanks to the number of guides suggesting such a setup to make cheap DIY router-like devices with Raspberry Pis, as is my case.

There are a lot of reports and mailing list threads on the web about this issue ([Google for "ath9k_htc: Target is unresponsive"](https://encrypted.google.com/search?q="ath9k_htc%3A Target is unresponsive")):

• Long March 2012 thread about the issue
• Raspberry Pi forum thread
• Another thread
• Yet another thread
• Same issue on firmware ar9271, with patch for it

It would be nice if this issue got fixed.

---

Reply to this email directly or view it on GitHub:

#1

[EtiennePerot]

I believe it is partially a firmware issue. In the case where htc_9271.fw is updated, for example, the updated version of the firmware cannot be used without a power cycle. On the setup described above (with a powered USB hub), such a power cycle is impossible to achieve without physical access to the machine (besides waiting for the next global power outage), because having the computer power down its USB port will not power down the USB hub, which in turn will not power down the USB adapter.

Perhaps the driver should indeed check of the firmware is already on the device before trying to download it, but allowing the firmware to be sent to the device again would both work around this issue and allow the use case defined above, at the same time.

As for checking what the driver does, I'm not a kernel developer nor good at reading C, but I gave it a shot anyway. Here's the waiting code (drivers/net/wireless/ath/ath9k/htc_drv_init.c):

static int ath9k_htc_wait_for_target(struct ath9k_htc_priv *priv)
{
    int time_left;

    if (atomic_read(&priv->htc->tgt_ready) > 0) {
        atomic_dec(&priv->htc->tgt_ready);
        return 0;
    }

    /* Firmware can take up to 50ms to get ready, to be safe use 1 second */
    time_left = wait_for_completion_timeout(&priv->htc->target_wait, HZ);
    if (!time_left) {
        dev_err(priv->dev, "ath9k_htc: Target is unresponsive\n");
        return -ETIMEDOUT;
    }

    atomic_dec(&priv->htc->tgt_ready);

    return 0;
}

It is called from ath9k_htc_probe_device and ath9k_htc_resume. It looks like it reads some flag (htc->tgt_ready), which gets set by ath9k_htc_rx_msg when it receives a HTC_MSG_READY_ID message...?

The probe function of the driver (ath9k_hif_usb_probe in drivers/net/wireless/ath/ath9k/hif_usb.c) does look like it tries requesting the firmware all the time; it calls request_firmware_nowait as part of its normal execution, which I think sends the firmware?

Sorry I can't be of much help, I don't really know my way around C or the Linux kernel well enough to undertake such a thing.

[robiezhou]

In driver hw.c, function ath9k_hw_set_power_awake(), It will check the RTC_STATUS value and then reset chip.
Sometimes the value of AR_RTC_STATUS is not AR_RTC_STATUS_SHUTDOWN, and this will cause ath9k_hw_set_reset_reg can not be executed, and we will see "Target is unreponsive" error. Could you help to look at that?

if (setChip) {
    if ((REG_READ(ah, AR_RTC_STATUS) &
         AR_RTC_STATUS_M) == AR_RTC_STATUS_SHUTDOWN) {
        if (ath9k_hw_set_reset_reg(ah,
                   ATH9K_RESET_POWER_ON) != true) {
            return false;
        }
        if (!AR_SREV_9300_20_OR_LATER(ah))
            ath9k_hw_init_pll(ah, NULL);

Thanks,
Robie

[EtiennePerot]

That doesn't seem to be the problem. I added a printk and a dump_stack() like this:

static bool ath9k_hw_set_power_awake(struct ath_hw *ah)
{
    u32 val;
    int i;

    /* Set Bits 14 and 17 of AR_WA before powering on the chip. */
    if (AR_SREV_9300_20_OR_LATER(ah)) {
        REG_WRITE(ah, AR_WA, ah->WARegVal);
        udelay(10);
    }

    printk("REG_READ(ah, AR_RTC_STATUS) = %d\n", REG_READ(ah, AR_RTC_STATUS));
    dump_stack();
    if ((REG_READ(ah, AR_RTC_STATUS) &
    AR_RTC_STATUS_M) == AR_RTC_STATUS_SHUTDOWN) {
        if (!ath9k_hw_set_reset_reg(ah, ATH9K_RESET_POWER_ON)) {
            return false;
        }
        if (!AR_SREV_9300_20_OR_LATER(ah))
            ath9k_hw_init_pll(ah, NULL);
    }

I also added dump_stack() near the "Failed to initialize the device" message in hope to see the path it takes to reach there, although I'm guessing it runs in a different thread so it's not too helpful:

int ath9k_htc_hw_init(struct htc_target *target,
        struct device *dev, u16 devid,
        char *product, u32 drv_info)
{
    if (ath9k_htc_probe_device(target, dev, devid, product, drv_info)) {
        dump_stack();
        pr_err("Failed to initialize the device\n");
        return -ENODEV;
    }

    return 0;
}

I booted it without the adapter attached. Once attached, dmesg showed this:

[   97.997084] usb 1-1.2.4: new high-speed USB device number 7 using dwc_otg
[   98.138521] usb 1-1.2.4: New USB device found, idVendor=0cf3, idProduct=9271
[   98.145798] usb 1-1.2.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[   98.154923] usb 1-1.2.4: Product: USB2.0 WLAN
[   98.159648] usb 1-1.2.4: Manufacturer: ATHEROS
[   98.164265] usb 1-1.2.4: SerialNumber: 12345
[   98.247458] cfg80211: Calling CRDA to update world regulatory domain
[   98.360526] usb 1-1.2.4: ath9k_htc: Firmware htc_9271.fw requested
[   98.378004] usbcore: registered new interface driver ath9k_htc
[   98.707976] usb 1-1.2.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[   98.947061] ath9k_htc 1-1.2.4:1.0: ath9k_htc: HTC initialized with 33 credits
[   98.972923] REG_READ(ah, AR_RTC_STATUS) = 2
[   98.977542] [<c0013b7c>] (unwind_backtrace+0x0/0xf0) from [<bf132bcc>] (ath9k_hw_setpower+0xdc/0x5dc [ath9k_hw])
[   98.988314] [<bf132bcc>] (ath9k_hw_setpower+0xdc/0x5dc [ath9k_hw]) from [<bf133fb4>] (ath9k_hw_init+0x2f8/0xae8 [ath9k_hw])
[   99.000018] [<bf133fb4>] (ath9k_hw_init+0x2f8/0xae8 [ath9k_hw]) from [<bf1a5714>] (ath9k_htc_probe_device+0x264/0x7e4 [ath9k_htc])
[   99.012206] [<bf1a5714>] (ath9k_htc_probe_device+0x264/0x7e4 [ath9k_htc]) from [<bf19d750>] (ath9k_htc_hw_init+0x14/0x3c [ath9k_htc])
[   99.024620] [<bf19d750>] (ath9k_htc_hw_init+0x14/0x3c [ath9k_htc]) from [<bf19f068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc])
[   99.037192] [<bf19f068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc]) from [<c024251c>] (request_firmware_work_func+0x70/0xb0)
[   99.049478] [<c024251c>] (request_firmware_work_func+0x70/0xb0) from [<c0035170>] (process_one_work+0x150/0x40c)
[   99.059971] [<c0035170>] (process_one_work+0x150/0x40c) from [<c0035750>] (worker_thread+0x150/0x498)
[   99.069495] [<c0035750>] (worker_thread+0x150/0x498) from [<c003a914>] (kthread+0x88/0x94)
[   99.078051] [<c003a914>] (kthread+0x88/0x94) from [<c000eafc>] (kernel_thread_exit+0x0/0x8)
[   99.308605] ath9k_htc 1-1.2.4:1.0: ath9k_htc: FW Version: 1.3
[   99.314558] ath: EEPROM regdomain: 0x809c
[   99.314571] ath: EEPROM indicates we should expect a country code
[   99.314583] ath: doing EEPROM country->regdmn map search
[   99.314592] ath: country maps to regdmn code: 0x52
[   99.314603] ath: Country alpha2 being used: CN
[   99.314611] ath: Regpair used: 0x52
[   99.353017] ieee80211 phy0: Atheros AR9271 Rev:1
[   99.377471] Registered led device: ath9k_htc-phy0

The adapter works fine. Then, after a reboot (with the wireless adapter still attached):

[    4.507083] usb 1-1.2.4: new high-speed USB device number 7 using dwc_otg
[    4.668613] usb 1-1.2.4: New USB device found, idVendor=0cf3, idProduct=9271
[    4.696901] usb 1-1.2.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[    4.696914] usb 1-1.2.4: Product: USB2.0 WLAN
[    4.696923] usb 1-1.2.4: Manufacturer: ATHEROS
[    4.696931] usb 1-1.2.4: SerialNumber: 12345
[    5.165613] cfg80211: Calling CRDA to update world regulatory domain
...
[    7.237611] usb 1-1.2.4: ath9k_htc: Firmware htc_9271.fw requested
[    7.263756] usbcore: registered new interface driver ath9k_htc
[    7.699638] usb 1-1.2.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[    8.736909] ath9k_htc 1-1.2.4:1.0: ath9k_htc: Target is unresponsive
[    8.765111] [<c0013b7c>] (unwind_backtrace+0x0/0xf0) from [<bf13d224>] (ath9k_htc_wait_for_target+0x60/0x6c [ath9k_htc])
[    8.805803] [<bf13d224>] (ath9k_htc_wait_for_target+0x60/0x6c [ath9k_htc]) from [<bf13d510>] (ath9k_htc_probe_device+0x60/0x7e4 [ath9k_htc])
[    8.838252] [<bf13d510>] (ath9k_htc_probe_device+0x60/0x7e4 [ath9k_htc]) from [<bf135750>] (ath9k_htc_hw_init+0x14/0x3c [ath9k_htc])
[    8.858598] [<bf135750>] (ath9k_htc_hw_init+0x14/0x3c [ath9k_htc]) from [<bf137068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc])
[    8.879895] [<bf137068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc]) from [<c024251c>] (request_firmware_work_func+0x70/0xb0)
[    8.900265] [<c024251c>] (request_firmware_work_func+0x70/0xb0) from [<c0035170>] (process_one_work+0x150/0x40c)
[    8.918873] [<c0035170>] (process_one_work+0x150/0x40c) from [<c0035750>] (worker_thread+0x150/0x498)
[    8.936586] [<c0035750>] (worker_thread+0x150/0x498) from [<c003a914>] (kthread+0x88/0x94)
[    8.953327] [<c003a914>] (kthread+0x88/0x94) from [<c000eafc>] (kernel_thread_exit+0x0/0x8)
[    8.971559] [<c0013b7c>] (unwind_backtrace+0x0/0xf0) from [<bf135764>] (ath9k_htc_hw_init+0x28/0x3c [ath9k_htc])
[    8.990576] [<bf135764>] (ath9k_htc_hw_init+0x28/0x3c [ath9k_htc]) from [<bf137068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc])
[    9.011564] [<bf137068>] (ath9k_hif_usb_firmware_cb+0xd8/0x1b8 [ath9k_htc]) from [<c024251c>] (request_firmware_work_func+0x70/0xb0)
[    9.032311] [<c024251c>] (request_firmware_work_func+0x70/0xb0) from [<c0035170>] (process_one_work+0x150/0x40c)
[    9.051230] [<c0035170>] (process_one_work+0x150/0x40c) from [<c0035750>] (worker_thread+0x150/0x498)
[    9.069176] [<c0035750>] (worker_thread+0x150/0x498) from [<c003a914>] (kthread+0x88/0x94)
[    9.086164] [<c003a914>] (kthread+0x88/0x94) from [<c000eafc>] (kernel_thread_exit+0x0/0x8)
[    9.103250] ath9k_htc: Failed to initialize the device
[    9.125085] usb 1-1.2.4: ath9k_htc: USB layer deinitialized

Running dmesg | grep REG_READ returns no output, so not only is ath9k_hw_set_reset_reg not being executed, neither is ath9k_hw_set_power_awake.

Note: Your message's code shows a if (setChip) { statement which I don't seem to have in my clone of the Linux kernel. I am using the 3.6 kernel from raspberrypi/linux@bb9948f.

[andyross]

I'm using such a device in a similar router application (though hanging off an IVB PC). There is a plausibly related issue there, too, where the device will hang unrecoverably after 1-2 days of activity. In this state, the firmware seems wedged, and will not respond to a usb port reset (e.g. with a USBDEVFS_RESET ioctl). I've seen identical failures with similar frequency on multiple units of both AT9271 and AR9287, so it doesn't seem to be bad hardware.

It's not at all clear to me that the underlying cause is the same, but a software-accesible reset procedure seems like it would be a useful treatment for both these failures...

[olerem]

1. These chip has UART port. If it is provided on the board, you can probably get more information if you use it.
2. do you use latest firmware? GIT build? Any difference if firmware versions?

[andyross]

I've seen the lockup once with the most recent firmware (with a quick hack to revert the version number to 1.3 so it can be loaded by the upstream 3.8 driver), but it hasn't had much testing. I'd love to have UART output, but these are consumer boards and my soldering skills limit me to through-hole rework only. :)

[andyross]

FWIW, I didn't see anything in the kernel bugzilla to track this issue, so I added it: https://bugzilla.kernel.org/show_bug.cgi?id=57341

[aaronfhamilton]

I'm having this problem as well on AT91RM9200 boards. In addition to the "Target is Unresponsive", the WiFi seems to stop working after several days of use.

I'm happy to provide whatever support I can in getting this resolved.

[olerem]

We do not know what exactly happens and why. We even can't find good reproduction case. On one network, it is working fine on other some time fail.
Provide as match information as you can, may be we will find some pattern, For example:

• sudo iw dev wlan0 scan dump
• output from uoart port on adapter

[aafaba]

I am having this problem as well on arm boards. Any progress on this issue or any suggestion to work around?

[aaronfhamilton]

Seems like this is specific to ARM processors. Wonder it isn't happening on x86 devices as well.

[olerem]

Hi aafaba, what kind of issue do you have? here are mixed some different issues with similar symptoms.

[olerem]

Right now we found one more issue: Some boards do not control usb power. So it is possible that after reboot firmware is actually not reloaded. Can any one confirm it?

[aaronfhamilton]

Is a fix possible for boards that don't control USB power? I know some
laptops have a dedicated USB port for charging that also never powers off.

Forgive my ignorance, but does the firmware have to be loaded on every
boot? Or can it be retained across power cycles?

On Tue, Jul 2, 2013 at 12:18 AM, Oleksij Rempel notifications@github.comwrote:

Right now we found one more issue: Some boards do not control usb power.
So it is possible that after reboot firmware is actually not reloaded. Can
any one confirm it?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-20330324
.

[aafaba]

Yes, my board does not control USB power. Every time after reboot, 'Target is unresponsive'

[EtiennePerot]

This is a similar predicament to the one described in the first post, i.e. when using a powered USB hub. The computer may be powered off, but the USB hub is still powered and so is the wireless device. In these situations, the "target is unresponsive" message consistently appears after a reboot.

[aafaba]

Yes, it is serious issue in embedded system, because it may reboot due to watch dog or other situation without power disconnect/connect action.

[olerem]

can you please test my branch:
https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend

[aafaba]

Hi olerem, can not find adapter after reboot by using your branch.

[olerem]

I was able to find some reproduction cases which are hardware and action depended. For example if interface was at least one time up, some bugs won't be reproducible. It means ath9k_htc_start function do some additional hardware configuration needed to be done on init.

Here different cases and sort of different bugs:

1. case. Adapter will freeze on module reload if interface is up.
Way to reproduce:
- plug adapter
- ifconfig wlan0 up. Or let NetworkManager configure it.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc

In this case only one of my PCs firmware filed to restart. Solution is to add delay on hardware reset. See this patch:
olerem@a796f6d

2. case. Adapter will freeze on PC reboot only if interface was not up before.
Reproduction case:
- start PC and make sure nothing will touch adapter. Stop Networkmanager or blacklist mac address of this adapter.
- plug adapter. Firmware will be loaded
- restart PC. After restart firmware will be loaded but immediately restart again. Checking different registers show possible pll error.

Workaround: ifconfig wlan0 up. This will configure pll.
Or try this patch, it seems to work on my PC:

--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -895,6 +895,7 @@ static int ath9k_init_device(struct ath9k_htc_priv *priv,
        ath9k_init_leds(priv);
        ath9k_start_rfkill_poll(priv);

+       ath9k_hw_disable(priv->ah);
        return 0;

 err_world:

3. case. Adapter will freeze on module reload  if interface was not up before.
It is similar like 2. case, but it seems to be not solved by this patch. It behave differently on different hardware.

Suggestions, testing, patches are welcome.

[olerem]

Here is some more code to test.

You will need three my last kernel patches from this branch:
https://github.com/olerem/linux-2.6/commits/github-wifi-ath9k_htc-fw

and last firmware patches from this branch:
https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend_fix

[olerem]

So, we have at least one confirmation that issue was fixed after this patch:
olerem/linux-2.6@38255e8

any one else?

[JukkaHonkola]

Hello, we have encountered the freezing problem using ath9k_htc based dongle with OpenWRT Attitude Adjustment which has kernel version 3.3.8. After a quick look, it seems that the 2.6 kernel patches could be applied manually to 3.3.8. Are the kernel patches needed 38255e8, 2cc5ab7, 67c89d5 and c7844f7?

[olerem]

38255e8 and 2cc5ab7 are most important. with this patches you need this firmware branch:
https://github.com/olerem/open-ath9k-htc-firmware/commits/next
If it wont fix your issue then you'll need next patches. 67c89d5 and c7844f7 will brake api, so you will need this firmware branch:
https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend_fix
In all cases, if you have problems. Please use uart port on chip to provide us logs.

[JukkaHonkola]

Thanks. I'll try the patches and see if it works. Unfortunately we can't provide UART logs, but I'll confirm whether it works or not.

[olerem]

Any updates?

[JukkaHonkola]

The patches (manually applied) compiled on kernel 3.3.8 in OpenWRT. Tomorrow on Tuesday I'll try to reproduce the issue deterministically in our enviroment (currently we can only reproduce the issue by repeated rebooting).

[olerem]

Today i finished last part of this issue. EP4 related bug is fixed, at least for me. If there is no issues, i hope this last patch will go soon upstream.
Are there any feed backs?

[erikarn]

Cool! Is there another pull needed for the firmware?

-adrian

On 13 August 2013 12:23, Oleksij Rempel notifications@github.com wrote:

Today i finished last part of this issue. EP4 related bug is fixed, at
least for me. If there is no issues, i hope this last patch will go soon
upstream.
Are there any feed backs?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-22590380
.

[saintofinternet]

Seems like this is specific to ARM processors. Wonder it isn't happening on x86 devices as well.

i am facing this on my VirtualBox running on Windows