Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200421211552.GA36171@t2b3>
In-Reply-To: <20200421211552.GA36171@t2b3>
From:   Brian Norris <briannorris@chromium.org>
Date:   Tue, 21 Apr 2020 15:56:17 -0700
Message-ID: <CA+ASDXN==qo2T6g5YCWpUFPXAdFgcKgww5EbmsmUTvsrSSRHug@mail.gmail.com>
Subject: Re: rtw88: BUG: scheduling while atomic: kworker/u16:0/33416/0x00000002
To:     "Tobias S. Predel" <tobias.predel@gmail.com>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>,
        Kai-Heng Feng <kai.heng.feng@canonical.com>,
        Tony Chuang <yhchuang@realtek.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

I'm not sure about the first half your problem, but for the
scheduling-while-atomic:

On Tue, Apr 21, 2020 at 2:16 PM Tobias S. Predel
<tobias.predel@gmail.com> wrote:
> [28125.482259] BUG: scheduling while atomic: kworker/u16:0/33416/0x00000002
...
> [28125.482436] Preemption disabled at:
> [28125.482443] [<0000000000000000>] 0x0

^^ This line is a bit weird -- shouldn't this have a real PC?

> [28125.482452] CPU: 5 PID: 33416 Comm: kworker/u16:0 Tainted: G        W         5.7.0-rc2-next-20200421-1-next-git #1
> [28125.482456] Hardware name: HP HP ProBook 430 G5/8377, BIOS Q85 Ver. 01.09.01 10/15/2019
> [28125.482477] Workqueue: phy0 rtw_watch_dog_work [rtw88]
> [28125.482481] Call Trace:
> [28125.482495]  dump_stack+0x66/0x90
> [28125.482505]  __schedule_bug.cold+0x8e/0x9b
> [28125.482512]  __schedule+0x686/0x7b0
> [28125.482520]  ? _raw_spin_unlock_irqrestore+0x20/0x40
> [28125.482525]  schedule+0x46/0xf0
> [28125.482531]  schedule_hrtimeout_range_clock+0xa5/0x120
> [28125.482540]  ? hrtimer_init_sleeper+0xa0/0xa0
> [28125.482546]  usleep_range+0x67/0x90
> [28125.482568]  rtw_fw_send_h2c_command+0xe0/0x1a0 [rtw88]
> [28125.482590]  rtw_fw_set_pwr_mode+0x95/0xb0 [rtw88]
> [28125.482610]  rtw_enter_lps+0xa1/0x100 [rtw88]
> [28125.482625]  rtw_watch_dog_work+0x21c/0x230 [rtw88]
> [28125.482635]  process_one_work+0x1da/0x3d0
> [28125.482643]  worker_thread+0x4a/0x3d0
> [28125.482651]  kthread+0x122/0x160
> [28125.482658]  ? process_one_work+0x3d0/0x3d0
> [28125.482663]  ? kthread_park+0x90/0x90
> [28125.482670]  ret_from_fork+0x1f/0x40

This looks like it might be a regression here:

commit 6343a6d4b2130be9323f347d60af8a7ba8f7242c
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Apr 7 15:33:31 2020 +0800

    rtw88: Add delay on polling h2c command status bit

That poll macros is using usleep, which obviously can sleep. We need
to be using a udelay-variant instead.


Brian