Re: kern/58069: Panic when trying to connect tty

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR kern/58069; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: triaxx%NetBSD.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58069: Panic when trying to connect tty
Date: Sun, 24 Mar 2024 03:15:37 +0000

 > Date: Sat, 23 Mar 2024 20:25:06 +0100
 > From: triaxx%NetBSD.org@localhost
 > 
 > crash> bt/a ffffa755807c9c00
 > trace: pid 556 lid 556 at 0xffffffff8069dab2
 > comintr() at comintr+0x313
 
 This one is:
 
 556  > 556 7   0   8020000   ffffa755807c9c00           ttyflags
 
 Now that's weird -- this crash dump is from the REMOTE machine using
 ucom0, isn't it?  Not the TARGET machine using com0?  So it's curious
 that comintr should appear in the stack trace of the ttyflags program.
 
 > crash> bt/a ffffa7558000e400
 > trace: pid 0 lid 311 at 0xffffac88411ddc60
 > bdev_strategy() at bdev_strategy+0xe6
 > [...]
 
 This one is:
 
 0    > 311 7   3       240   ffffa7558000e400            ioflush
 
 Probably not interesting here.
 
 > crash> bt/a ffffa7557fb68400
 > trace: pid 0 lid 178 at 0xffffac8840e3cf80
 > sleepq_block() at sleepq_block+0x298
 > cv_timedwait() at cv_timedwait+0xde
 > usb_event_thread() at usb_event_thread+0x96
 > crash> bt/a ffffa7557fb3c800
 > trace: pid 0 lid 175 at 0xffffac8840e27f80
 > sleepq_block() at sleepq_block+0x298
 > cv_timedwait() at cv_timedwait+0xde
 > usb_event_thread() at usb_event_thread+0x96
 
 These ones are weird, because they are supposed to be currently
 running on the CPU, but instead the stack trace shows them sleeping:
 
 0    > 178 7   4       240   ffffa7557fb68400               usb3
 ...
 0    > 175 7   2       240   ffffa7557fb3c800               usb0
 
 > crash> bt/a ffffa7557ede5c00
 > trace: pid 0 lid 122 at 0xffffac8830726000
 > _KERNEL_OPT_MEMORY_RBFLAGS() at ffffa7557ed43880
 
 This one is:
 
 0    > 122 7   6       200   ffffa7557ede5c00          softser/6
 
 But what is it doing?  My guess is that it's stuck waiting for a lock,
 held by something in kpause or similar, which is only woken by a
 callout, which can't run as long as a higher-priority softint like
 this one is stuck.
 
 > crash> bt/a ffffa7557ede5800
 > trace: pid 0 lid 121 at 0xffffac88307510e0
 > softint_dispatch() at softint_dispatch+0x112
 > DDB lost frame for Xsoftintr+0x4c, trying 0xffffac88307510f0
 > Xsoftintr() at Xsoftintr+0x4c
 > --- interrupt ---
 > 0:
 
 This one is:
 
 0    > 121 7   6       200   ffffa7557ede5800          softclk/6
 
 It has presumably been interrupted by softser/6 above.
 
 > crash> bt/a ffffa7557ed56000
 > trace: pid 0 lid 115 at 0xffffac88306e9000
 > _KERNEL_OPT_MEMORY_RBFLAGS() at ffffa7557ebdef40
 
 This one is:
 
 0    > 115 7   5       200   ffffa7557ed56000          softclk/5
 
 It might be waiting for the same lock as softser/6, but what lock is
 that?
 
 Any chance you could make the kernel and core dump available?