All of lore.kernel.org
 help / color / mirror / Atom feed
From: wi nk <wink@technolu.st>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: Thomas Krause <thomaskrause@posteo.de>, ath11k@lists.infradead.org
Subject: Re: ath11k: QCA6390 on Dell XPS 13 and kernel crashes
Date: Mon, 30 Nov 2020 18:02:16 +0100	[thread overview]
Message-ID: <CAHUdJJWA=XqYUwYk9deK3UTr9S03rM3L8YZ9_DHJyKh-CVgW-w@mail.gmail.com> (raw)
In-Reply-To: <87tut6iy39.fsf@codeaurora.org>

On Mon, Nov 30, 2020 at 5:55 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Hi Wi and Thomas,
>
> I'll start a new thread about problems on XPS 13. The information is
> scattered to different threads and hard to find everything, it's much
> easier to have everything in one place. So let's continue the discussion
> about the kernel crashes on this thread.
>
> Here's what I have understood so far:
>
> * On Dell XPS 15 there are no issues with QCA6390 and it seems to work
>   with 32 MSI vectors.
>
> * On Dell XPS 13 there's a BIOS bug and kernel prints:
>
> [    0.050130] DMAR: [Firmware Bug]: Your BIOS is broken; DMAR reported at address 0!
>                BIOS vendor: Dell Inc.; Ver: 1.1.1; Product Version:
>
> * Because of this BIOS bug QCA6390 only gets one MSI vector on Dell XPS
>   13. We added a hack to ath11k make it work with only vector and after
>   that it's possible to boot the firmware, connect to the AP and use the
>   device for a while.
>
> * But the problem now is that the kernel is crashing almost immediately
>   and almost every time(?). And these crashes only happen on Dell XPS
>   13, all other systems (including Dell XPS 15) seem to work without
>   issues.
>
> Is my understanding correct? Did I miss anything?
>
> About the symptoms Wi reports:
>
> ----------------------------------------------------------------------
> So up until this point, everything is working without issues.
> Everything seems to spiral out of control a couple of seconds later
> when my system attempts to actually bring up the adapter.  In most of
> the crash states I will see this:
>
> [   31.286725] wlp85s0: send auth to ec:08:6b:27:01:ea (try 1/3)
> [   31.390187] wlp85s0: send auth to ec:08:6b:27:01:ea (try 2/3)
> [   31.391928] wlp85s0: authenticated
> [   31.394196] wlp85s0: associate with ec:08:6b:27:01:ea (try 1/3)
> [   31.396513] wlp85s0: RX AssocResp from ec:08:6b:27:01:ea
> (capab=0x411 status=0 aid=6)
> [   31.407730] wlp85s0: associated
> [   31.434354] IPv6: ADDRCONF(NETDEV_CHANGE): wlp85s0: link becomes ready
>
> And then either somewhere in that pile of messages, or a second or two
> after this my machine will start to stutter as I mentioned before, and
> then it either hangs, or I see this message (I'm truncating the
> timestamp):
>
> [   35.xxxx ] sched: RT throttling activated
>
> After that moment, the machine is unresponsive.  Sorry I can't seem to
> extract this data other than screenshots from my phone at the moment,
> you can see the dmesg output from 6 different hangs here:
>
> https://github.com/w1nk/ath11k-debug
> ----------------------------------------------------------------------
>
> And Thomas Krause reports:
>
> --------------------------------------------------------------------------------
> I can confirm this behavior on my configuration. I managed to login
> once and select the Wifi and connect to it. It seemed curiously enough
> be stable long enough to enter the Wifi passphrase. After the
> connection was established, the system hang and on each attempt to
> reboot into the graphical system it would freeze at some point
> (sometimes even before showing the login screen).
> ----------------------------------------------------------------------
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Hi Kalle,

  Again, thanks much for your work.  I think you've summarized
everything up until this point.  On my XPS 13 9310 The behavior of the
RT throttling still exists for me occasionally on loading the
driver/associating with an AP.  The throttling consistently occurs
after a few sets of the MHI debug printing showing the EE entering an
invalid state ( AMSS -> INVALID_EE ).  I'm now building the latest tag
to see if there are any differences.

Thanks!

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

  reply	other threads:[~2020-11-30 17:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 16:55 ath11k: QCA6390 on Dell XPS 13 and kernel crashes Kalle Valo
2020-11-30 17:02 ` wi nk [this message]
2020-12-01 10:17   ` wi nk
2020-12-05 19:17     ` wi nk
2020-12-06  8:05       ` wi nk
2020-12-02 23:49 Stephen Liang
2020-12-09 15:09 ` Kalle Valo
2020-12-10  3:07   ` Stephen Liang
2020-12-10  7:37     ` Stephen Liang
2020-12-06 17:38 Mitchell Nordine
2020-12-06 17:53 ` wi nk
2020-12-06 21:45   ` wi nk
2020-12-07  1:17     ` wi nk
2020-12-07 14:45       ` Mitchell Nordine
2020-12-07 17:01         ` wi nk
2020-12-09  1:52           ` wi nk
2020-12-09  9:43             ` wi nk
2020-12-09 15:28               ` wi nk
2020-12-09 15:35     ` Kalle Valo
2020-12-09 15:39       ` wi nk
2020-12-09 15:50         ` wi nk
2020-12-09 15:50         ` Kalle Valo
2020-12-09 15:55           ` wi nk
2020-12-09 21:46             ` wi nk
2020-12-11 12:28               ` wi nk
2020-12-12  5:37                 ` Kalle Valo
2020-12-12 11:46                   ` wi nk
2020-12-12 23:29                     ` wi nk
2020-12-13  0:03                       ` wi nk
2020-12-13  0:59                         ` Mitchell Nordine
2020-12-13 22:09                           ` Stephen Liang
2020-12-16  8:50                           ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHUdJJWA=XqYUwYk9deK3UTr9S03rM3L8YZ9_DHJyKh-CVgW-w@mail.gmail.com' \
    --to=wink@technolu.st \
    --cc=ath11k@lists.infradead.org \
    --cc=kvalo@codeaurora.org \
    --cc=thomaskrause@posteo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.