[ath9k-devel] D-Link DWA-547 completely freezes system

[Pavel Roskin <proski@gnu.org>]

On Fri, 2010-01-22 at 10:58 +0100, Khashayar Naderehvandi wrote:

> > I can confirm that 0xdeadbeef comes from the chip, not from some random
> > place in memory.  Even the supported Ubiquiti SR71-15 returns 0xdeadbeef
> > when reading from the register 0x00ac (AR_IMR_S2).
> >
> > The fact that SR71-12 only works if installed in a slot below SR71-15 is
> > very intriguing.  I checked the modules with nm for possible static
> > variables, but I cannot spot anything wrong.  I'm going to try
> > mmiotrace.
> >
> Pavel, this is way too technical for me to understand :)

Sorry, it was meant for Luis.

Ubiquiti SR71-15 is the only AR9220 card I know that works with ath9k.
It's a 5GHz-only card, so maybe that's the reason.

Ubiquiti SR71-12 is a 2GHz card and it doesn't work.  However, if
SR71-15 is present in the same system and has a lower PCI address so
that it's initialized first, SR71-12 would work.  This makes me think
that the initialization of SR71-15 changes something in the state of the
driver.  The state should be separate for every device, so it may be a
bug.

I discovered that reading from some registers gives 0xdeadbeef.  Even
for SR71-15 reading from one register gives 0xdeadbeef.  0xdeadbeef is a
number commonly used to indicate uninitialized data.  But it comes from
the device.  So we are doing something wrong.  Maybe the register in
question (AR_IMR_S2) should be initialized, or maybe the whole chip
initialization is wrong.

> Are you saying that you can confirm the issue I posted about?

Yes.

>  Does
> this bug surface depending on which PCI-slot the card is inserted in?

Only if you have Ubiquiti SR71-15 on that system.

> How can I help out?

I don't know.  It's hard to give instructions how to fix a bug.  It's
easier to fix a bug.  I just don't have enough time for that.

-- 
Regards,
Pavel Roskin