ath5k failure with 2.6.24-git14

ath5k failure with 2.6.24-git14

[Tino Keitel]

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

Re: ath5k failure with 2.6.24-git14

[Andrew Morton]

(cc linux-wireless)

On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel <tino.keitel@gmx.de> 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.
> 

[RFT 1/1] single_chip test

[Jiri Slaby]

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 <jirislaby@gmail.com>
---
 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

Re: [RFT 1/1] single_chip test

[Andreas Schwab]

Jiri Slaby <jirislaby@gmail.com> 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."

Re: [RFT 1/1] single_chip test

[Jiri Slaby]

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.

Re: [RFT 1/1] single_chip test

[Joseph Fannin]

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

Re: [RFT 1/1] single_chip test

[Bob Copeland]

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

Re: [RFT 1/1] single_chip test

[Tino Keitel]

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

Re: [RFT 1/1] single_chip test

[Jiri Slaby]

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?

Re: [RFT 1/1] single_chip test

[Tino Keitel]

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

Re: ath5k failure with 2.6.24-git14

[Bob Copeland]

> On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel <tino.keitel@gmx.de> 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