Re: [linux-next:master] [serial] b63e6f60ea: BUG:soft_lockup-CPU##stuck_for#s![modprobe:#]

[John Ogness <john.ogness@linutronix.de>]

On 2025-04-30, Ryo Takakura <ryotkkr98@gmail.com> wrote:
>>> The touch_nmi_watchdog() resets the softlockup watchdog. It might
>>> hide that the CPU did not schedule for a long time.
>
> To test the above, I run the rslib test using legacy console(without
> the John's series) with the touch_nmi_watchdog()s removed as
> following.
>
> The result is that it triggered the softlockup as expected. So I guess
> we can say that the legacy console was indeed hiding the softlockup
> scenario as suggested by Petr.

Excellent.

>> With the John's series appied, I guess the kthread were running on a
>> cpu other than the one running the rslib test as John said[0], and
>> neither of touch_nmi_watchdog() nor cond_resched() were called that
>> could prevent the softlockup.
>
> To test the above, I removed the touch_nmi_watchdog() mentioned by John[0]
> on top of the John's series with the printing forced to be done on the same
> cpu running the rslib test by marking emergency section(below change applied).
>
> The result is that it triggered the softlockup as expected. Similar to
> the first test, the touch_nmi_watchdog() was preventing the softlockup
> when its marked with emergency section.

Excellent.

> And I believe this implies that the kthread was running on some other cpu
> as stated above as it should also be calling the touch_nmi_watchdog()
> when it does printing.

Agreed.

> If sounds good, I will prepare a fix adding cond_resched() to the
> rslib test later on.

Yes, please add a cond_resched() to the rslib test.

> I tested with Linus' master on x86 qemu. I was able to see the rslib
> tests prone to softlockup and the John's series exaggerating it, same
> as raspberry pi.
>
> But I couldn't see the softlockup go away by marking the emergency
> section around the printk call within the rslib test. Looks like it
> never calls the touch_nmi_watchdog() in wait_for_lsr(). Maybe because
> trasmission gets immediatly completed on qemu board?

qemu does not emulate a baudrate, so indeed transmission completes
immediately. It would need to be tested on real hardware. But I am
certain we found the cause and explanation. Thank you for digging into
this!

John