[lkml]   [2011]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Regression, 3.2-rc1] ath9k broken on AR928X
On 2011-11-27 4:32 AM, Rafael J. Wysocki wrote:
> On Friday, November 25, 2011, Rafael J. Wysocki wrote:
>> On Thursday, November 24, 2011, Linus Torvalds wrote:
>> > Hey, since most of the US will be in a food-induced coma tomorrow, I
>> > just *know* that doing a new release candidate is a good idea.
>> >
>> > One quarter arch updates, two quarters drivers, and one quarter random
>> > changes. Shake vigorously and serve cold..
>> >
>> > And maybe the rest of the world can try to make up for the lack of any
>> > expected US participation? Hmm?
>> Well, unfortunately, this kernel is unusable on my Acer Ferrari One.
>> First off, it hangs solid every time several seconds or at last a few
>> minutes after boot. I haven't been able to collect any debug data from
>> it yet, but one of the symptoms is black screen with (unmovable) mouse
>> cursor (this only happens when X has been started, but the box hangs without
>> X too).
>> Second, the wireless is apparently unable to associate with the AP
>> (that 3.1-rc10 works with correctly on the same box).
>> Tomorrow I'll try to identify the offending commits.
> Well, it took more time than I had hoped. :-(
> Bisection turns up:
> commit 2577c6e8f2320f1d2f09be122efef5b9118efee4
> Author: Senthil Balasubramanian <>
> Date: Tue Sep 13 22:38:18 2011 +0530
> ath9k_hw: Add support for AR946/8x chipsets.
> This patch adds support for AR946/8x chipets.
> Signed-off-by: Senthil Balasubramanian <>
> Signed-off-by: John W. Linville <>
> which I think is wrong for at lest two reasons. Not that I understand
> what it actually does to the driver, but first, it does much more than the
> changelog says and, second, it is practically impossible to revert
> because of the number of commits on top depending on it. Quite frankly,
> it is about to make it to my list of examples of how things should _not_ be
> done in the kernel.
> The commit immediately preceding it doesn't show any symptoms of failure, so
> I'm quite convinced this one really introduced the problem for me.
> The chip in the affected box is (according to "lspci -v"):
> 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
> Subsystem: Foxconn International, Inc. Device e01f
> Flags: bus master, fast devsel, latency 0, IRQ 19
> Memory at f0000000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] Power Management version 2
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
> Capabilities: [60] Express Legacy Endpoint, MSI 00
> Capabilities: [90] MSI-X: Enable- Count=1 Masked-
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
> Thanks,
> Rafael

Looking at the diff, the only thing I can find that would break AR928x
is this (in the function ath9k_set_power_sleep in hw.c):

/* Clear Bit 14 of AR_WA after putting chip into Full Sleep mode. */
- if (AR_SREV_9300_20_OR_LATER(ah))
- ah->WARegVal & ~AR_WA_D3_L1_DISABLE);
+ if (!AR_SREV_9480(ah))
+ REG_WRITE(ah, AR_WA, ah->WARegVal & ~AR_WA_D3_L1_DISABLE);

Please try changing the if line to:
if (AR_SREV_9300_20_OR_LATER(ah) && !AR_SREV_9480(ah))

Apparently later changes even removed this check. I'll take a look at the
history to figure out what's going on, this could probably explain other
regressions on pre-AR9380 chips as well.

- Felix

 \ /
  Last update: 2011-11-27 07:23    [W:0.077 / U:2.820 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site