Hello!
AR5414 fails to scan most of the time starting with the revision
94f2e0d6234991d0c10d458f6f378934efbdf6d6 "ath5k: Update reset code"
I have about 18 APs in the range. With the latest kernel, the scan
results are usually empty. I tried reverting parts of the patch, as it
cannot be cleanly reverted on top of wireless-testing, and I've seen
scan results with all APs occasionally, but most of the time the scan
results would be empty.
With the last working revision, bbcce7389a7288c48d96d13bbf521e901236d287
"ath5k: Update initvals", scanning gives all APs in range every time.
The chip is reported by the driver as:
ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)
$ lspci -vnn -s 0000:0b:00.0
0b:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
Subsystem: Apple Computer Inc. Device [106b:0086]
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fe8f0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: ath5k
Kernel modules: ath_pci, ath5k
It's a PCI Express minicard. The kernel architecture is x86_64.
--
Regards,
Pavel Roskin
2009/3/27 Pavel Roskin <[email protected]>:
> On Thu, 2009-03-26 at 03:47 +0200, Nick Kossifidis wrote:
>
>> That's weird, I've tested this with my 5413 and it works just fine. =
It
>> seems that 5424 (pci-e version of 5413) still has some issues. Have
>> you tried monitor mode ?
>
> I have reduced the patch to the clock setting in ath5k_hw_nic_wakeup(=
).
>
> Testing with madwifi-free shows that the clock register for 802.11a
> channels for RF5413 should be 0x04. =C2=A0ath5k uses 0x44
> (AR5K_PHY_PLL_40MHZ_5413 | AR5K_PHY_PLL_RF5112). =C2=A0The value befo=
re the
> patch that broke scanning was 0xea (AR5K_PHY_PLL_40MHZ |
> AR5K_PHY_PLL_RF5112).
>
> With the following patch, scanning works for both 2.4 GHz and 5 GHz
> bands. =C2=A0Please test with your hardware. =C2=A0If it works, I'll =
submit it.
>
>
> ath5k: fix scanning in AR2424
>
> AR5K_PHY_PLL_40MHZ_5413 shouldn't be ORed with AR5K_PHY_MODE_RAD_RF51=
12.
>
> Signed-off-by: Pavel Roskin <[email protected]>
> ---
>
> =C2=A0drivers/net/wireless/ath5k/reset.c | =C2=A0 =C2=A02 +-
> =C2=A01 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/drivers/net/wireless/ath5k/reset.c b/drivers/net/wireles=
s/ath5k/reset.c
> index 7a17d31..faede82 100644
> --- a/drivers/net/wireless/ath5k/reset.c
> +++ b/drivers/net/wireless/ath5k/reset.c
> @@ -359,7 +359,7 @@ int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int =
flags, bool initial)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0mode |=3D AR5K_PHY_MODE_FREQ_5GHZ;
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0if (ah->ah_radio =3D=3D AR5K_RF5413)
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clock |=3D AR5K_PHY_PLL_40MHZ_5413;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clock =3D AR5K_PHY_PLL_40MHZ_5413;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0else
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clock |=3D AR5K_PHY_PLL_40MHZ=
;
>
>
>
> --
> Regards,
> Pavel Roskin
>
Nice catch ;-)
Acked-by: Nick Kossifidis <[email protected]>
--=20
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Fri, 2009-03-27 at 16:04 +0200, Nick Kossifidis wrote:
> Nice catch ;-)
I just realized that ath5k worked when I was in Russia a week ago
because I was setting the country code correctly, and there is no 5 GHz
band in Russia. But in the US, ath5k fails to scan! That's why ath5k
"broke" when I came back! :-)
Also, the unpatched ath5k scans in the "GR" locale for some reason, even
though it has some 5 GHz channels. Anyway, it's not very interesting
why the 0x44 value for PLL is working in some cases. It should be 0x04.
I've submitted the patch.
--
Regards,
Pavel Roskin
Quoting Nick Kossifidis <[email protected]>:
> That's weird, I've tested this with my 5413 and it works just fine. It
> seems that 5424 (pci-e version of 5413) still has some issues. Have
> you tried monitor mode ?
The monitor mode is fine.
I also looked at the probe requests and probe responses and could not
find any differences before and after the patch. The requests are
sent, the AP answers with responses. The signal strength of the probe
requests is the same. But the scan command returns nothing.
So I'm not even sure if the problem is with transmitting or receiving.
My guess is that the problem is with receiving after transmitting.
That's the simplest remaining explanation. Or maybe it's a problem
with receiving after changing the channel.
I'll try to reduce the patch to the minimum.
--
Regards,
Pavel Roskin
On Thu, 2009-03-26 at 03:47 +0200, Nick Kossifidis wrote:
> That's weird, I've tested this with my 5413 and it works just fine. It
> seems that 5424 (pci-e version of 5413) still has some issues. Have
> you tried monitor mode ?
I have reduced the patch to the clock setting in ath5k_hw_nic_wakeup().
Testing with madwifi-free shows that the clock register for 802.11a
channels for RF5413 should be 0x04. ath5k uses 0x44
(AR5K_PHY_PLL_40MHZ_5413 | AR5K_PHY_PLL_RF5112). The value before the
patch that broke scanning was 0xea (AR5K_PHY_PLL_40MHZ |
AR5K_PHY_PLL_RF5112).
With the following patch, scanning works for both 2.4 GHz and 5 GHz
bands. Please test with your hardware. If it works, I'll submit it.
ath5k: fix scanning in AR2424
AR5K_PHY_PLL_40MHZ_5413 shouldn't be ORed with AR5K_PHY_MODE_RAD_RF5112.
Signed-off-by: Pavel Roskin <[email protected]>
---
drivers/net/wireless/ath5k/reset.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath5k/reset.c b/drivers/net/wireless/ath5k/reset.c
index 7a17d31..faede82 100644
--- a/drivers/net/wireless/ath5k/reset.c
+++ b/drivers/net/wireless/ath5k/reset.c
@@ -359,7 +359,7 @@ int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
mode |= AR5K_PHY_MODE_FREQ_5GHZ;
if (ah->ah_radio == AR5K_RF5413)
- clock |= AR5K_PHY_PLL_40MHZ_5413;
+ clock = AR5K_PHY_PLL_40MHZ_5413;
else
clock |= AR5K_PHY_PLL_40MHZ;
--
Regards,
Pavel Roskin
2009/3/26 Pavel Roskin <[email protected]>:
> Hello!
>
> AR5414 fails to scan most of the time starting with the revision
> 94f2e0d6234991d0c10d458f6f378934efbdf6d6 "ath5k: Update reset code"
>
> I have about 18 APs in the range. =C2=A0With the latest kernel, the s=
can
> results are usually empty. =C2=A0I tried reverting parts of the patch=
, as it
> cannot be cleanly reverted on top of wireless-testing, and I've seen
> scan results with all APs occasionally, but most of the time the scan
> results would be empty.
>
> With the last working revision, bbcce7389a7288c48d96d13bbf521e901236d=
287
> "ath5k: Update initvals", scanning gives all APs in range every time.
>
> The chip is reported by the driver as:
> ath5k phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)
>
> $ lspci -vnn -s 0000:0b:00.0
> 0b:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242=
x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Subsystem: Apple Computer Inc. Device [106=
b:0086]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Flags: bus master, fast devsel, latency 0,=
IRQ 16
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Memory at fe8f0000 (64-bit, non-prefetchab=
le) [size=3D64K]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [40] Power Management versio=
n 2
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [50] Message Signalled Inter=
rupts: Mask- 64bit- Count=3D1/1 Enable-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [60] Express Legacy Endpoint=
, MSI 00
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [90] MSI-X: Enable- Mask- Ta=
bSize=3D1
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [100] Advanced Error Reporti=
ng
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UESta: =C2=A0D=
LP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- =
UnsupReq- ACSVoil-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UEMsk: =C2=A0D=
LP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- =
UnsupReq- ACSVoil-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UESvrt: DLP+ S=
DES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- Unsup=
Req- ACSVoil-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CESta: =C2=A0R=
xErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CESta: =C2=A0R=
xErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AERCap: First =
Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Capabilities: [140] Virtual Channel <?>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Kernel driver in use: ath5k
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Kernel modules: ath_pci, ath5k
>
> It's a PCI Express minicard. =C2=A0The kernel architecture is x86_64.
>
> --
> Regards,
> Pavel Roskin
That's weird, I've tested this with my 5413 and it works just fine. It
seems that 5424 (pci-e version of 5413) still has some issues. Have
you tried monitor mode ?
--=20
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick