[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))
    - 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

     \ /
      Last update: 2011-11-27 07:23    [W:0.027 / U:18.276 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site