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 _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
