Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ath9k_htc: Target is unresponsive #1

Open
EtiennePerot opened this issue Mar 17, 2013 · 43 comments
Open

ath9k_htc: Target is unresponsive #1

EtiennePerot opened this issue Mar 17, 2013 · 43 comments

Comments

@EtiennePerot
Copy link

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")):

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
Copy link
Collaborator

erikarn commented Mar 17, 2013

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")):

It would be nice if this issue got fixed.


Reply to this email directly or view it on GitHub:

#1

@EtiennePerot
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

olerem commented Apr 30, 2013

  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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

olerem commented May 24, 2013

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
Copy link

aafaba commented Jul 2, 2013

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

@aaronfhamilton
Copy link

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

@olerem
Copy link
Contributor

olerem commented Jul 2, 2013

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

@olerem
Copy link
Contributor

olerem commented Jul 2, 2013

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
Copy link

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
Copy link

aafaba commented Jul 3, 2013

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

@EtiennePerot
Copy link
Author

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
Copy link

aafaba commented Jul 3, 2013

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
Copy link
Contributor

olerem commented Jul 3, 2013

@aafaba
Copy link

aafaba commented Jul 5, 2013

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

@olerem
Copy link
Contributor

olerem commented Jul 5, 2013

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
Copy link
Contributor

olerem commented Jul 5, 2013

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
Copy link
Contributor

olerem commented Jul 10, 2013

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

any one else?

@JukkaHonkola
Copy link

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
Copy link
Contributor

olerem commented Jul 11, 2013

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
Copy link

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
Copy link
Contributor

olerem commented Jul 15, 2013

Any updates?

@JukkaHonkola
Copy link

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
Copy link
Contributor

olerem commented Aug 13, 2013

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
Copy link
Collaborator

erikarn commented Aug 13, 2013

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
.

HazouPH pushed a commit to HazouPH/android_kernel_motorola_smi that referenced this issue Jan 30, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcsibi pushed a commit to tcsibi/android_kernel_samsung_smdk4412 that referenced this issue Apr 27, 2018
commit dc2a87f upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EspreDigChaos pushed a commit to EspreDigChaos/80211s that referenced this issue Apr 29, 2018
Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
EspreDigChaos pushed a commit to EspreDigChaos/80211s that referenced this issue Apr 29, 2018
Currently ath9k_htc will reboot firmware only if interface was
ever started. Which lead to the problem in case where interface
was never started but module need to be reloaded.

This patch will partially fix bug "ath9k_htc: Target is unresponsive"
qca/open-ath9k-htc-firmware#1

Reproduction case:
- plug adapter
- make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
maxime-poulain pushed a commit to maxime-poulain/android_kernel_samsung_jf that referenced this issue Jun 5, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
shinobizero pushed a commit to shinobizero/android_kernel_lge_hammerhead that referenced this issue Jun 21, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
shinobizero pushed a commit to shinobizero/android_kernel_lge_hammerhead that referenced this issue Jun 22, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tahamsaglam pushed a commit to tahamsaglam/willow that referenced this issue Jul 15, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
varphone pushed a commit to varphone/linux-stable that referenced this issue Aug 13, 2018
commit dc2a87f upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 20d717b)
nichcream pushed a commit to nichcream/kernel_xiaomi_lte26007 that referenced this issue Sep 30, 2018
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nichcream pushed a commit to nichcream/kernel_xiaomi_lte26007 that referenced this issue Sep 30, 2018
commit 4928bd2ef8ece262f4f314630219999a91eaa440 upstream.

Currently ath9k_htc will reboot firmware only if interface was
ever started. Which lead to the problem in case where interface
was never started but module need to be reloaded.

This patch will partially fix bug "ath9k_htc: Target is unresponsive"
qca/open-ath9k-htc-firmware#1

Reproduction case:
- plug adapter
- make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@saintofinternet
Copy link

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

Klozz pushed a commit to XPerience-AOSP-Lollipop/android_kernel_motorola_ghost that referenced this issue Jan 22, 2019
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rlawoehd187 pushed a commit to rlawoehd187/android_kernel_pantech_msm8960 that referenced this issue Jan 17, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chrmhoffmann pushed a commit to chrmhoffmann/android_kernel_fairphone_msm8974 that referenced this issue Mar 1, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
z3DD3r pushed a commit to z3DD3r/android_kernel_lge_hammerhead that referenced this issue Mar 19, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
z3DD3r pushed a commit to z3DD3r/android_kernel_lge_hammerhead that referenced this issue Mar 23, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cakehonolulu pushed a commit to cakehonolulu/android_kernel_bq_Aquaris5HD that referenced this issue Apr 30, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
K9100ii pushed a commit to K9100ii/kernel_sony_msm8x60 that referenced this issue Jun 29, 2020
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@Dimelay Dimelay mentioned this issue Jul 14, 2020
snuk182 pushed a commit to snuk182/android_kernel_asus_A66 that referenced this issue Jun 21, 2021
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
seskir pushed a commit to seskir/android_kernel_samsung_exynos5260 that referenced this issue Aug 8, 2021
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rlawoehd187 pushed a commit to sky-vega-dev-team/kernel_pantech_msm8x74 that referenced this issue Aug 3, 2022
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rainbowdashh pushed a commit to rainbowdashh/android_kernel_samsung_smdk5260 that referenced this issue Aug 11, 2022
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RobertCNelson pushed a commit to beagleboard/mirror-ti-linux-kernel that referenced this issue Aug 27, 2024
[ Upstream commit dc2a87f ]

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: qca/open-ath9k-htc-firmware#1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests