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 <senthilb@xxxxxxxxxxxxxxxx>
> 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 <senthilb@xxxxxxxxxxxxxxxx>
> Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
>
> 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))
- REG_WRITE(ah, AR_WA,
- 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
