Re: [ath9k-devel] Failed to init on TP-Link TL-WN861N

Re: [ath9k-devel] Failed to init on TP-Link TL-WN861N

[Luis R. Rodriguez]

On Sat, Oct 11, 2008 at 11:01 PM, Cameron Hutchison <lists@xdna.net> wrote:
> I've just loaded linux kernel 2.6.27 onto a box that I have that
> contains a TP-Link TLWN861N atheros minipci card. It identifes as a
> AR5416:
>
> 00:09.0 Network controller: Atheros Communications Inc. AR5416 802.11abgn Wireless PCI Adapter (rev 01)
>        Subsystem: Atheros Communications Inc. Device 2079
>        Flags: 66MHz, medium devsel, IRQ 17
>        Memory at fcfe0000 (32-bit, non-prefetchable) [size=64K]
>        Capabilities: [40] #80 [0000]
>        Kernel modules: ath9k
>
> When I try to load the ath9k module (with all debugging messages
> enabled) I get the following kernel messages:
>
> ath9k: 0.1
> ath9k 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> ath_init: devid 0x23
> ath9k_hw_setpower: AWAKE -> AWAKE (set chip )
> ath9k_hw_do_attach: serialize_regmode is 0
> ath9k_hw_do_attach: This Mac Chip Rev 0x0d.2 is
> ath9k_hw_chip_test: address test failed addr: 0x00008000 - wr:0x00ff00ff != rd:0x00ff00ef

This is during ath9k_hw_chip_test(), which is a simple loop to test
write/read on 2 registers to see if the written values can be read as
the same values. The two registers are:

AR_STA_ID0 which is 0x8000
AR_PHY_BASE + (8 << 2) which is 0x9800 + (8<<2) --> 0x9820

AR_STA_ID0 is used to store part of the MAC address and 0x9820 is just
one of the PHY registers. So we test writing and reading a 256 times
to each register some arbitrary value. We also try writing and reading
some 4 specific patterns just to be sure.

> ath9k_hw_post_attach: hardware self-test failed

This means when it tried to write to a register it then tried reading
the value on the register but didn't get what it was expecting. In
your case we tried writing to register offset 0x8000 the value
0x00ff00ff but read 0x00ff00ef, this test will only continue if the
value read was 0x00ff00ef so for some reason a bit was lost and the
hardware was unable to write the 5th bit on that register.

If we continue this could lead to issues. It seems you may have a
faulty wireless card, specifically bit #5 on register 0x8000. Maybe
the card is loose? Have you seen it working before?

  Luis

Re: [ath9k-devel] Failed to init on TP-Link TL-WN861N

[Luis R. Rodriguez]

On Mon, Oct 13, 2008 at 3:00 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:

> In
> your case we tried writing to register offset 0x8000 the value
> 0x00ff00ff but read 0x00ff00ef, this test will only continue if the
> value read was 0x00ff00ef

I meant 0x00ff00ff of course.

  Luis

Re: Failed to init on TP-Link TL-WN861N

[Cameron Hutchison]

Luis R. Rodriguez wrote:

>On Sat, Oct 11, 2008 at 11:01 PM, Cameron Hutchison <lists@xdna.net> wrote:
>> [...]
>> ath9k_hw_chip_test: address test failed addr: 0x00008000 - wr:0x00ff00ff != rd:0x00ff00ef

>This is during ath9k_hw_chip_test(), which is a simple loop to test
>write/read on 2 registers to see if the written values can be read as
>the same values. The two registers are:

>AR_STA_ID0 which is 0x8000
>AR_PHY_BASE + (8 << 2) which is 0x9800 + (8<<2) --> 0x9820

>AR_STA_ID0 is used to store part of the MAC address and 0x9820 is just
>one of the PHY registers. So we test writing and reading a 256 times
>to each register some arbitrary value. We also try writing and reading
>some 4 specific patterns just to be sure.

Which part of the MAC address would be at AR_STA_ID0? I'm stretching
here, since the nibbles would be out of order, but could this card be
forcing the multicast bit of the MAC address off?

>If we continue this could lead to issues. It seems you may have a
>faulty wireless card, specifically bit #5 on register 0x8000. Maybe
>the card is loose? Have you seen it working before?

I haven't used the card before - recently purchased for this linux box.
I've tried reseating the card but no luck.

I modified ath9k_hw_chip_test to continue testing on failure and I get
the same problem on the second test:
ath9k_hw_chip_test: address test failed addr: 0x00008000 - wr:0x00ff00ff != rd:0x00ff00ef
ath9k_hw_chip_test: address test failed addr: 0x00009820 - wr:0x00ff00ff != rd:0x00ff00ef

It does not always fail on these two addresses though - sometimes only
on one (either one) and occasionally none. But then it goes on to fail
the EEPROM checksum:

ath9k_hw_fill_eeprom: Reading from EEPROM, not flash
ath9k_hw_check_eeprom: Read Magic = 0xA55A
need_swap = False.
Bad EEPROM checksum 0xff0f or revision 0x000e
Detaching Ani

I guess the MAC multicast is not happening. I'll see if I can rustle up
a windows laptop to try this out in and see if it works there.

Re: [ath9k-devel] Failed to init on TP-Link TL-WN861N

[Luis R. Rodriguez]

On Tue, Oct 14, 2008 at 01:12:32AM -0700, Cameron Hutchison wrote:
> Luis R. Rodriguez wrote:
> 
> >On Sat, Oct 11, 2008 at 11:01 PM, Cameron Hutchison <lists@xdna.net> wrote:
> >> [...]
> >> ath9k_hw_chip_test: address test failed addr: 0x00008000 - wr:0x00ff00ff != rd:0x00ff00ef
> 
> >This is during ath9k_hw_chip_test(), which is a simple loop to test
> >write/read on 2 registers to see if the written values can be read as
> >the same values. The two registers are:
> 
> >AR_STA_ID0 which is 0x8000
> >AR_PHY_BASE + (8 << 2) which is 0x9800 + (8<<2) --> 0x9820
> 
> >AR_STA_ID0 is used to store part of the MAC address and 0x9820 is just
> >one of the PHY registers. So we test writing and reading a 256 times
> >to each register some arbitrary value. We also try writing and reading
> >some 4 specific patterns just to be sure.
> 
> Which part of the MAC address would be at AR_STA_ID0? I'm stretching
> here, since the nibbles would be out of order, but could this card be
> forcing the multicast bit of the MAC address off?

Please check the usage of the AR_STA_ID0 register as that is what I'd
look to answer to you.

> >If we continue this could lead to issues. It seems you may have a
> >faulty wireless card, specifically bit #5 on register 0x8000. Maybe
> >the card is loose? Have you seen it working before?
> 
> I haven't used the card before - recently purchased for this linux box.
> I've tried reseating the card but no luck.
> 
> I modified ath9k_hw_chip_test to continue testing on failure and I get
> the same problem on the second test:
> ath9k_hw_chip_test: address test failed addr: 0x00008000 - wr:0x00ff00ff != rd:0x00ff00ef
> ath9k_hw_chip_test: address test failed addr: 0x00009820 - wr:0x00ff00ff != rd:0x00ff00ef
> 
> It does not always fail on these two addresses though - sometimes only
> on one (either one) and occasionally none. But then it goes on to fail
> the EEPROM checksum:
> 
> ath9k_hw_fill_eeprom: Reading from EEPROM, not flash
> ath9k_hw_check_eeprom: Read Magic = 0xA55A
> need_swap = False.
> Bad EEPROM checksum 0xff0f or revision 0x000e
> Detaching Ani

Ouch, this is pretty negative.

> I guess the MAC multicast is not happening. I'll see if I can rustle up
> a windows laptop to try this out in and see if it works there.

Let us know how it goes.

  Luis