[BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[Pavel Roskin]

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

Re: [ath5k-devel] [BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[Nick Kossifidis]

2009/3/26 Pavel Roskin <proski@gnu.org>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] [BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[Pavel Roskin]

Quoting Nick Kossifidis <mickflemm@gmail.com>:

> 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

Re: [ath5k-devel] [BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[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 <proski@gnu.org>
---

 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

Re: [ath5k-devel] [BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[Nick Kossifidis]

2009/3/27 Pavel Roskin <proski@gnu.org>:
> 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 <proski@gnu.org>
> ---
>
> =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 <mickflemm@gmail.com>

--=20
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] [BISECTED] AR5414 fails to scan after "ath5k: Update reset code"

[Pavel Roskin]

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