search

qca / open-ath9k-htc-firmware

The firmware for QCA AR7010/AR9271 802.11n USB NICs
Other
428 stars 182 forks source link

ath9k_htc: Target is unresponsive #1

Open EtiennePerot opened 11 years ago

EtiennePerot commented 11 years ago

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 (cc765de49061ce8947ea90d1c02af130f7089a93).

erikarn commented 11 years ago

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:

https://github.com/qca/open-ath9k-htc-firmware/issues/1

EtiennePerot commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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@bb9948f6c26e201e85b5ab0e2bed1189024a4aab.

andyross commented 11 years ago

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 commented 11 years ago
  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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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:

aafaba commented 11 years ago

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

aaronfhamilton commented 11 years ago

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

olerem commented 11 years ago

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

olerem commented 11 years ago

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 commented 11 years ago

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/qca/open-ath9k-htc-firmware/issues/1#issuecomment-20330324 .

aafaba commented 11 years ago

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

EtiennePerot commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

aafaba commented 11 years ago

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

olerem commented 11 years ago

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: https://github.com/olerem/open-ath9k-htc-firmware/commit/a796f6d5744bc91bf40a7a8762efa1190d5204bc

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 commented 11 years ago

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 commented 11 years ago

So, we have at least one confirmation that issue was fixed after this patch: https://github.com/olerem/linux-2.6/commit/38255e8e271dea5f62368263bd005d45571f048e

any one else?

JukkaHonkola commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Any updates?

JukkaHonkola commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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/qca/open-ath9k-htc-firmware/issues/1#issuecomment-22590380 .

olerem commented 11 years ago

all needed (and not needed) patches are in this pull request: https://github.com/qca/open-ath9k-htc-firmware/pull/38/commits

kernel need one more patch: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/111931

dlangeland commented 11 years ago

Hi,

I am trying to make this work with compat drivers 3.7.9-1 and a TP-Link TL-WN722N dongle using the ath9k driver.

I have done the following:

  1. Cloned https://github.com/olerem/open-ath9k-htc-firmware/tree/next to get Olerem's patches
  2. Modified the version number for the firmware from 1.4 to 1.3 to make compat drivers accept it
  3. Compiled the firmware and copied it to /lib/firmware/
  4. Patched the ath9k driver in compat drivers with the 4 latest patches from https://github.com/olerem/linux-2.6/commits/github-wifi-ath9k_htc-fw as well as the patch described in http://permalink.gmane.org/gmane.linux.kernel.wireless.general/111931
  5. Installed compat drivers
  6. Rebooted the machine

When I do a "sudo ifconfig wlan2 down" followed by "sudo ifconfig wlan2 up" the PC is completely stuck until I disconnect the dongle. I see the following in the kernel log:

[  538.615823] usb 2-1.7: USB disconnect, device number 9
[  539.075581] ath: phy5: Unable to reset hardware; reset status -5 (freq 2412 MHz)
[  539.154720] usb 2-1.7: ath9k_htc: USB layer deinitialized

Have I made some obvious mistake? Unfortunately I can not provide UART logs or similar since I am using a standard USB dongle.

Thanks a lot!

olerem commented 11 years ago

hi helten, last two patches from my kernel branch should not be used. remove this two patches: ath9k_htc: add extra fields to WMI_CMD_HDR ath9k_htc: do extra sanity check on wmi commands

dlangeland commented 11 years ago

Hi,

Thank you for your speedy reply. Unfortunately it is even worse after removing those two patches (restoring wmi.c/h to original versions). The device is never fully initialized:

[   26.355455] usb 2-1.7: new high-speed USB device number 5 using ehci_hcd
[   26.464855] usb 2-1.7: New USB device found, idVendor=0cf3, idProduct=9271
[   26.464860] usb 2-1.7: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[   26.464863] usb 2-1.7: Product: USB2.0 WLAN
[   26.464865] usb 2-1.7: Manufacturer: ATHEROS
[   26.464867] usb 2-1.7: SerialNumber: 12345
[   26.472013] usb 2-1.7: ath9k_htc: Firmware htc_9271.fw requested
[   26.472072] usbcore: registered new interface driver ath9k_htc
[   26.836741] usb 2-1.7: ath9k_htc: Transferred FW: htc_9271.fw, size: 51000
[   26.836988] ath9k_htc 2-1.7:1.0: ath9k_htc: Magical patched drivers  <-- added by helten..ignore
[   27.078433] ath9k_htc 2-1.7:1.0: ath9k_htc: HTC initialized with 33 credits
[   43.547491] usb 2-1.7: USB disconnect, device number 5
[   44.023098] ath: phy1: Couldn't reset chip
[   44.023104] ath: phy1: Unable to initialize hardware; initialization status: -5
[   44.023106] ath: phy1: Unable to initialize hardware; initialization status: -5
[   44.023115] ath9k_htc: Failed to initialize the device
[   44.029919] usb 2-1.7: ath9k_htc: USB layer deinitialized

It is basically stuck after the "HTC initialized..." line.

Any ideas?

olerem commented 11 years ago

So, what about reverting "ath9k_htc: do not use bulk on EP3 and EP4"? Only this patch should affect initialisation. What host side hardware are you using? USB host controller?

dlangeland commented 11 years ago

Hi,

I will try to revert the patch you refer to and get back with the result.

I am testing this on an Intel NUC (http://www.intel.com/content/www/us/en/desktops/dc3217iye-product-brief.html) with the following USB controller:

00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
        Subsystem: Intel Corporation Device 2044
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at f7d27000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port: BAR=1 offset=00a0
        Capabilities: [98] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP+
        Kernel driver in use: ehci_hcd

This is the info about the Atheros USB device (with the patches that are not working):

Bus 002 Device 007: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Couldn't open device, some information will be missing
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
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           60
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           6
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

I will get back to you.

dlangeland commented 11 years ago

https://github.com/olerem/linux-2.6/commits/github-wifi-ath9k_htc-fw is removed? I can not find the patches again.

olerem commented 11 years ago

This was my personal experimental branch for wmi related changes. I removed it to avoid confusions. All needed patches are upstream, see: https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git

please, if it possible, use wireless-next source. Since patches was made and testes for it.

Timpson85 commented 10 years ago

Hi All!

Is there any way to reset firmware if "Target is unresponsive" occures? I use DaVinci custom board. My situation is from main case. I tried to use master branch on firmware site with backports-3.12.8-1 on kernel site (Linux kernel 3.6.11). The use case sequence is:

  1. USB modem is powered up. All is ok.
  2. USB modem power down. All is ok.
  3. After second power up - "Target is unresponsive" occures.

I think the problem is that firmware halts on power down. Or may be kernel driver not reset all needed variables.

Thanks for help!

olerem commented 10 years ago

Hi,

please make sure that previously mentioned patches included in backports-3.12.8-1.

hackers365 commented 10 years ago

To solve the problem of temporary, I reset usb when reboot that no need to replug.

http://www.roman10.net/how-to-reset-usb-device-in-linux/

Timpson85 commented 10 years ago

Thank you both for reply. Previously mentioned patches are included in backports-3.12.8-1. The problem was in usb hub. I solved my problem by reseting usb hub. May be reseting usb port helps too.

Thanks.

saintofinternet commented 5 years ago

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