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 :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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 0x0020 ... 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 0x0020 ... 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 0x0020 ... 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 0x0020 ... 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 :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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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=120179743111458 -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 :02:00.0: registered as 'phy0' > > ath5k phy0: failed to resume the MAC Chip > > ath5k_pci: probe of :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 9010 (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=0x9010, 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 [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
Jiri Slaby <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
Jiri Slaby [EMAIL PROTECTED] 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, [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 :02:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of :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 9010 (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=0x9010, 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 [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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-wirelessm=120179743111458 -Bob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
