Re: recent signal changes related panic

On Wed, 9 Apr 2003, Maxim Konovalov wrote:

> Hello,
>
> How to repeat:
>
> $ stty status ^T
> $ while :; do cat /etc/services >q; done
>
> [ Press and hold ^T, get a panic. ]

This seems to be just the old bug that TIOCCONS (redirection of
/dev/console, normally to a pty) never worked.  Its not working is now
sometimes detected by a KASSERT().  Usually, holding sched_lock (which
is acquired for ^T handling) causes problems.  calcru() is called with
sched_lock held and sometimes wants to call printf() to report another
bug (that the timecounter went backwards).  This is fatal for most
console drivers, but especially for the pty driver.

Here you have the additional complication that the pty driver is reentered.
This need not be a problem and I think it is not the main problem here.
After all, ttyinfo() prints to a terminal in normal operation and the
terminal may be a pty, so printing to ttys must basically work (^T must
be blocked in critical regions for it to work).  Printing to pty's just
cannot be expected to work if sched_lock is held.

> ...
> panic messages:
> ---
> panic: blockable sleep lock (sleep mutex) sellck _at_ /usr/src/sys/kern/sys_generic.c:1191
> Uptime: 4m5s
> Dumping 511 MB
> ata0: resetting devices ..
> done
> [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496

This demonstrates the unrelated bug that the "any" key no longer works
for aborting dumps.  The "any" key still works right for the panic
reboot wait and other places in panic().

Bruce