From: Kalle Valo <kvalo@codeaurora.org>
To: wi nk <wink@technolu.st>
Cc: "ath11k@lists.infradead.org" <ath11k@lists.infradead.org>,
Mitchell Nordine <mail@mitchellnordine.com>
Subject: Re: ath11k: QCA6390 on Dell XPS 13 and kernel crashes
Date: Wed, 09 Dec 2020 17:50:35 +0200 [thread overview]
Message-ID: <87mtyn9dx0.fsf@codeaurora.org> (raw)
In-Reply-To: <CAHUdJJWpxVCz1S1AcoNGjCcKGCuRXsJqZZtx4=rpev2nOc-dGQ@mail.gmail.com> (wi nk's message of "Wed, 9 Dec 2020 16:39:16 +0100")
wi nk <wink@technolu.st> writes:
> On Wed, Dec 9, 2020 at 4:35 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> wi nk <wink@technolu.st> writes:
>>
>> > So I've managed to stabilise my system now, so either the race is
>> > gone, or I've done something to win it all the time. So one of the
>> > avenues of racing I was chasing at first was in the ath11k driver
>> > itself. There are a couple areas where the single/shared IRQ is being
>> > forcibly toggled in ways that the documentation says are not great
>> > (and the original patch was trying to avoid). Fixing those didn't
>> > seem to have much impact on the stability of things (I've included
>> > those changes in my patch though). After the last email I was
>> > thinking about the MHI side of things a bit more and found a number of
>> > call sites that my naive grepping had missed that do the same thing,
>> > but via acquiring a lock at the same time. I modified all the calls
>> > to *_lock_irq and *_unlock_irq to the lock/unlock - save/restore
>> > variants that accept the flags parameter to capture state. I've now
>> > booted and loaded the driver 10+ times without a single freeze or
>> > crash. I'm not sure all of those modifications are necessary (ie:
>> > which things are re-entrant in this single interrupt operating mode vs
>> > which ones can use the simpler lock/unlock mechanisms), so I could use
>> > some advice/guidance there.
>> >
>> > Mitchell - if you want to grab this patch and try it, let me know how
>> > it goes and I can clean it up for the mailing list:
>> > https://github.com/w1nk/ath11k-debug/blob/master/one-irq-manage.patch
>> > (apply to ath11k-qca6390-bringup-202011301608)
>>
>> Wink, I want to ask more about your the very interesting
>> one-irq-manage.patch you wrote. Have you seen the "sched: RT throttling
>> activated" crash with that patch? If yes, how many times, for example 5
>> out of 10 times or something like that?
>>
>> Or is it so with one-irq-manage.patch the kernel doesn't crash at all? I
>> didn't quite understand the situation.
>>
>> --
>> https://patchwork.kernel.org/project/linux-wireless/list/
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
> Kalle,
>
> Sorry for moving the thread :).
No problem, I'll just make extra questions to make sure that I'm
understanding things correctly :)
> So I've attempted 2 patches that seem to produce varying degrees of
> success. The single IRQ patch took the crashing behaviour from hard
> locking immediately, to that stuttering / RT throttling message
> consistently. So instead of hard locking 9/10 times and stuttering
> 1/10, it was inverted.
Ok, got it now.
> The second patch disabling the m2 transition (even without the single
> IRQ patch) seems to have resolved the issues altogether, but at the
> expense of disabling this m2 state, which I don't have much idea of
> the consequences..
Sorry, I have missed that. What second patch are you talking about?
Also can you share your /proc/interrupts in full?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
--
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
next prev parent reply other threads:[~2020-12-09 15:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-06 17:38 ath11k: QCA6390 on Dell XPS 13 and kernel crashes 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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-11-30 16:55 Kalle Valo
2020-11-30 17:02 ` wi nk
2020-12-01 10:17 ` wi nk
2020-12-05 19:17 ` wi nk
2020-12-06 8:05 ` wi nk
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=87mtyn9dx0.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath11k@lists.infradead.org \
--cc=mail@mitchellnordine.com \
--cc=wink@technolu.st \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).