ath5k failure with 2.6.24-git14 - Kernel

This is a discussion on ath5k failure with 2.6.24-git14 - Kernel ; Hi, I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and got the following error message from ath5k: ath5k_pci 0000:02:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of 0000:02:00.0 failed with error -5 Here is the lspci ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: ath5k failure with 2.6.24-git14

  1. ath5k failure with 2.6.24-git14

    Hi,

    I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and
    got the following error message from ath5k:

    ath5k_pci 0000:02:00.0: registered as 'phy0'
    ath5k phy0: failed to resume the MAC Chip
    ath5k_pci: probe of 0000:02:00.0 failed with error -5

    Here is the lspci -vnn output:

    02:00.0 Ethernet controller [0200]: Atheros Communications, Inc.
    AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01)
    Subsystem: Apple Computer Inc. Unknown device [106b:0086]
    Flags: fast devsel, IRQ 17
    Memory at 90100000 (64-bit, non-prefetchable) [disabled]
    [size=64K]
    Capabilities: [40] Power Management version 2
    Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
    Queue=0/0 Enable-
    Capabilities: [60] Express Legacy Endpoint, MSI 00
    Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Virtual Channel
    Kernel modules: ath5k

    The same device works with madwifi:

    ath_rate_sample: 1.2 (svn r3339)
    MadWifi: ath_attach: Switching per-packet transmit power control off
    wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
    wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
    24Mbps 36Mbps 48Mbps 54Mbps
    wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    wifi0: H/W encryption support: WEP AES AES_CCM TKIP
    wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic
    wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic
    wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic
    wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic
    wifi0: ath_announce: Use hw queue 8 for CAB traffic
    wifi0: ath_announce: Use hw queue 9 for beacons
    ath_pci: wifi0: Atheros 5424/2424: mem=0x90100000, irq=17

    I can also set the interface up and use iwlist ath0 scan.

    Regards,
    Tino
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: ath5k failure with 2.6.24-git14


    (cc linux-wireless)

    On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel wrote:

    > Hi,
    >
    > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and
    > got the following error message from ath5k:
    >
    > ath5k_pci 0000:02:00.0: registered as 'phy0'
    > ath5k phy0: failed to resume the MAC Chip
    > ath5k_pci: probe of 0000:02:00.0 failed with error -5
    >
    > Here is the lspci -vnn output:
    >
    > 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc.
    > AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01)
    > Subsystem: Apple Computer Inc. Unknown device [106b:0086]
    > Flags: fast devsel, IRQ 17
    > Memory at 90100000 (64-bit, non-prefetchable) [disabled]
    > [size=64K]
    > Capabilities: [40] Power Management version 2
    > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
    > Queue=0/0 Enable-
    > Capabilities: [60] Express Legacy Endpoint, MSI 00
    > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
    > Capabilities: [100] Advanced Error Reporting
    > Capabilities: [140] Virtual Channel
    > Kernel modules: ath5k
    >
    > The same device works with madwifi:
    >
    > ath_rate_sample: 1.2 (svn r3339)
    > MadWifi: ath_attach: Switching per-packet transmit power control off
    > wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
    > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
    > 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: H/W encryption support: WEP AES AES_CCM TKIP
    > wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic
    > wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic
    > wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic
    > wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic
    > wifi0: ath_announce: Use hw queue 8 for CAB traffic
    > wifi0: ath_announce: Use hw queue 9 for beacons
    > ath_pci: wifi0: Atheros 5424/2424: mem=0x90100000, irq=17
    >
    > I can also set the interface up and use iwlist ath0 scan.
    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [RFT 1/1] single_chip test

    On 02/05/2008 11:57 PM, Tino Keitel wrote:
    > Hi,
    >
    > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and
    > got the following error message from ath5k:
    >
    > ath5k_pci 0000:02:00.0: registered as 'phy0'
    > ath5k phy0: failed to resume the MAC Chip
    > ath5k_pci: probe of 0000:02:00.0 failed with error -5


    We failed to resume after a hardware reset here for a whole second. Is there any
    version of ath5k which worked for you (is this a regression)?

    > Here is the lspci -vnn output:
    >
    > 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc.
    > AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01)
    > Subsystem: Apple Computer Inc. Unknown device [106b:0086]
    > Flags: fast devsel, IRQ 17
    > Memory at 90100000 (64-bit, non-prefetchable) [disabled]
    > [size=64K]
    > Capabilities: [40] Power Management version 2
    > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
    > Queue=0/0 Enable-
    > Capabilities: [60] Express Legacy Endpoint, MSI 00
    > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
    > Capabilities: [100] Advanced Error Reporting
    > Capabilities: [140] Virtual Channel
    > Kernel modules: ath5k
    >
    > The same device works with madwifi:
    >
    > ath_rate_sample: 1.2 (svn r3339)
    > MadWifi: ath_attach: Switching per-packet transmit power control off
    > wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
    > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
    > 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > wifi0: H/W encryption support: WEP AES AES_CCM TKIP
    > wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic
    > wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic
    > wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic
    > wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic
    > wifi0: ath_announce: Use hw queue 8 for CAB traffic
    > wifi0: ath_announce: Use hw queue 9 for beacons
    > ath_pci: wifi0: Atheros 5424/2424: mem=0x90100000, irq=17
    >
    > I can also set the interface up and use iwlist ath0 scan.


    Hmm, I guess madwif-old-openhal doesn't work either.

    I suspect ath5k_hw_nic_wakeup being called before setting ah_single_chip in
    ath5k_hw_attach. Could you test the attached patch?

    --

    Signed-off-by: Jiri Slaby
    ---
    drivers/net/wireless/ath5k/hw.c | 21 ++++++++++-----------
    1 files changed, 10 insertions(+), 11 deletions(-)

    diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
    index 3a4bf40..b56d239 100644
    --- a/drivers/net/wireless/ath5k/hw.c
    +++ b/drivers/net/wireless/ath5k/hw.c
    @@ -181,11 +181,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
    else if (ah->ah_version <= AR5K_AR5211)
    ah->ah_proc_rx_desc = ath5k_hw_proc_old_rx_status;

    - /* Bring device out of sleep and reset it's units */
    - ret = ath5k_hw_nic_wakeup(ah, AR5K_INIT_MODE, true);
    - if (ret)
    - goto err_free;
    -
    /* Get MAC, PHY and RADIO revisions */
    srev = ath5k_hw_reg_read(ah, AR5K_SREV);
    ah->ah_mac_srev = srev;
    @@ -210,12 +205,16 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
    }

    /* Identify single chip solutions */
    - if((srev <= AR5K_SREV_VER_AR5414) &&
    - (srev >= AR5K_SREV_VER_AR2424)) {
    - ah->ah_single_chip = true;
    - } else {
    - ah->ah_single_chip = false;
    - }
    + ah->ah_single_chip = !!(srev >= AR5K_SREV_VER_AR2424 &&
    + srev <= AR5K_SREV_VER_AR5414);
    +
    + printk(KERN_INFO "SINGLE: %d, srev: %x, phy:\n",
    + ah->ah_single_chip, srev, ah->ah_phy_revision);
    +
    + /* Bring device out of sleep and reset it's units */
    + ret = ath5k_hw_nic_wakeup(ah, AR5K_INIT_MODE, true);
    + if (ret)
    + goto err_free;

    /* Single chip radio */
    if (ah->ah_radio_2ghz_revision == ah->ah_radio_5ghz_revision)
    --
    1.5.3.8

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [RFT 1/1] single_chip test

    Jiri Slaby writes:

    > @@ -210,12 +205,16 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
    > }
    >
    > /* Identify single chip solutions */
    > - if((srev <= AR5K_SREV_VER_AR5414) &&
    > - (srev >= AR5K_SREV_VER_AR2424)) {
    > - ah->ah_single_chip = true;
    > - } else {
    > - ah->ah_single_chip = false;
    > - }
    > + ah->ah_single_chip = !!(srev >= AR5K_SREV_VER_AR2424 &&

    ^^

    This is useless.

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [RFT 1/1] single_chip test

    On 02/06/2008 11:48 AM, Andreas Schwab wrote:
    >> + ah->ah_single_chip = !!(srev >= AR5K_SREV_VER_AR2424 &&

    > ^^
    >
    > This is useless.


    Amended locally, thanks.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [RFT 1/1] single_chip test

    On Wed, Feb 06, 2008 at 11:42:40AM +0100, Jiri Slaby wrote:
    > On 02/05/2008 11:57 PM, Tino Keitel wrote:
    > > Hi,
    > >
    > > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and
    > > got the following error message from ath5k:
    > >
    > > ath5k_pci 0000:02:00.0: registered as 'phy0'
    > > ath5k phy0: failed to resume the MAC Chip
    > > ath5k_pci: probe of 0000:02:00.0 failed with error -5

    >
    > We failed to resume after a hardware reset here for a whole second. Is there any
    > version of ath5k which worked for you (is this a regression)?


    I cannot speak for Tino, but my ath5k never worked in MacBook -- it
    failed the same way, and I believe the hardware was the same. My
    understanding was that it was a known bug with PCIE devices, but I got
    that out of reading list archives.

    >
    > > Here is the lspci -vnn output:
    > >
    > > 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc.
    > > AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01)
    > > Subsystem: Apple Computer Inc. Unknown device [106b:0086]
    > > Flags: fast devsel, IRQ 17
    > > Memory at 90100000 (64-bit, non-prefetchable) [disabled]
    > > [size=64K]
    > > Capabilities: [40] Power Management version 2
    > > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
    > > Queue=0/0 Enable-
    > > Capabilities: [60] Express Legacy Endpoint, MSI 00
    > > Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
    > > Capabilities: [100] Advanced Error Reporting
    > > Capabilities: [140] Virtual Channel
    > > Kernel modules: ath5k
    > >
    > > The same device works with madwifi:
    > >
    > > ath_rate_sample: 1.2 (svn r3339)
    > > MadWifi: ath_attach: Switching per-packet transmit power control off
    > > wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
    > > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
    > > 24Mbps 36Mbps 48Mbps 54Mbps
    > > wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
    > > wifi0: H/W encryption support: WEP AES AES_CCM TKIP
    > > wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic
    > > wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic
    > > wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic
    > > wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic
    > > wifi0: ath_announce: Use hw queue 8 for CAB traffic
    > > wifi0: ath_announce: Use hw queue 9 for beacons
    > > ath_pci: wifi0: Atheros 5424/2424: mem=0x90100000, irq=17
    > >
    > > I can also set the interface up and use iwlist ath0 scan.

    >
    > Hmm, I guess madwif-old-openhal doesn't work either.
    >
    > I suspect ath5k_hw_nic_wakeup being called before setting ah_single_chip in
    > ath5k_hw_attach. Could you test the attached patch?


    I cannot, as my MacBook is now broken.

    --
    Joseph Fannin
    jfannin@gmail.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: ath5k failure with 2.6.24-git14

    > On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel wrote:
    >
    > > Hi,
    > >
    > > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and
    > > got the following error message from ath5k:
    > >
    > > ath5k_pci 0000:02:00.0: registered as 'phy0'
    > > ath5k phy0: failed to resume the MAC Chip
    > > ath5k_pci: probe of 0000:02:00.0 failed with error -5


    Hi Tino,

    I have the same chip and it is currently unsupported by ath5k. See:

    http://marc.info/?l=linux-wireless&m=120179743111458
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [RFT 1/1] single_chip test

    > > We failed to resume after a hardware reset here for a whole second. Is there any
    > > version of ath5k which worked for you (is this a regression)?

    >
    > I cannot speak for Tino, but my ath5k never worked in MacBook -- it
    > failed the same way, and I believe the hardware was the same. My
    > understanding was that it was a known bug with PCIE devices, but I got
    > that out of reading list archives.


    Nick Kossifidis and I are in the process of debugging this -- we
    determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup.
    It doesn't look like there is any general support for 5424 cards yet.
    Thread is at:

    http://marc.info/?l=linux-wireless&m=120179743111458

    -Bob
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [RFT 1/1] single_chip test

    On Wed, Feb 06, 2008 at 10:46:39 -0500, Bob Copeland wrote:
    > > > We failed to resume after a hardware reset here for a whole second. Is there any
    > > > version of ath5k which worked for you (is this a regression)?

    > >
    > > I cannot speak for Tino, but my ath5k never worked in MacBook -- it
    > > failed the same way, and I believe the hardware was the same. My
    > > understanding was that it was a known bug with PCIE devices, but I got
    > > that out of reading list archives.

    >
    > Nick Kossifidis and I are in the process of debugging this -- we
    > determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup.
    > It doesn't look like there is any general support for 5424 cards yet.


    I tried the patch, and the card was detected. I was able to associate
    with an WPA2 AP and send/receive some traffic. But after a while the
    interface broke:

    ath0: No ProbeResp from current AP 00:14:bf:16:25:87 - assume out of
    range
    ath5k_hw_get_isr: 0x00000020
    ....
    ath0: failed to set channel 165 (5825 MHz) for scan
    ath0: failed to restore operational channel after scan
    printk: 19 messages suppressed.
    ath5k phy0: calibration timeout (2447MHz)
    printk: 1 messages suppressed.
    ath5k phy0: calibration timeout (2447MHz)
    ath5k phy0: unable to reset hardware: -11

    Regards,
    Tino
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [RFT 1/1] single_chip test

    On 02/07/2008 10:25 PM, Tino Keitel wrote:
    > On Wed, Feb 06, 2008 at 10:46:39 -0500, Bob Copeland wrote:
    >>>> We failed to resume after a hardware reset here for a whole second. Is there any
    >>>> version of ath5k which worked for you (is this a regression)?
    >>> I cannot speak for Tino, but my ath5k never worked in MacBook -- it
    >>> failed the same way, and I believe the hardware was the same. My
    >>> understanding was that it was a known bug with PCIE devices, but I got
    >>> that out of reading list archives.

    >> Nick Kossifidis and I are in the process of debugging this -- we
    >> determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup.
    >> It doesn't look like there is any general support for 5424 cards yet.


    Seems hold for this case too, as Bob noted.

    > I tried the patch, and the card was detected. I was able to associate
    > with an WPA2 AP and send/receive some traffic. But after a while the
    > interface broke:
    >
    > ath0: No ProbeResp from current AP 00:14:bf:16:25:87 - assume out of
    > range
    > ath5k_hw_get_isr: 0x00000020
    > ...
    > ath0: failed to set channel 165 (5825 MHz) for scan
    > ath0: failed to restore operational channel after scan
    > printk: 19 messages suppressed.
    > ath5k phy0: calibration timeout (2447MHz)
    > printk: 1 messages suppressed.
    > ath5k phy0: calibration timeout (2447MHz)
    > ath5k phy0: unable to reset hardware: -11


    What's the srev a phy ver printed few lines above this, please?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [RFT 1/1] single_chip test

    On Thu, Feb 07, 2008 at 22:51:04 +0100, Jiri Slaby wrote:

    [...]

    > What's the srev a phy ver printed few lines above this, please?


    ath5k_pci 0000:02:00.0: registered as 'phy0'
    SINGLE: 1, srev: a3, phy:
    phy0: Selected rate control algorithm 'pid'
    ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61)

    Regards,
    Tino
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread