cvs commit: src/sys/amd64/amd64 genassym.c src/sys/arm/arm genassym.c src/sys/i386/i386 genassym.c src/sys/ia64/ia64 genassym.c src/sys/kern subr_prf.c tty_cons.c src/sys/powerpc/powerpc genassym.c src/sys/sparc64/sparc64 ...

[Robert Watson]

On Wed, 1 Nov 2006, John Birrell wrote:

>  Add a cnputs() function to write a string to the console with
>  a lock to prevent interspersed strings written from different CPUs
>  at the same time.
>
>  To avoid putting a buffer on the stack or having to malloc one,
>  space is incorporated in the per-cpu structure. The buffer
>  size if 128 bytes; chosen because it's the next power of 2 size
>  up from 80 characters.
>
>  String writes to the console are buffered up the end of the line
>  or until the buffer fills. Then the buffer is flushed to all
>  console devices.
>
>  Existing low level console output via cnputc() is unaffected by
>  this change. ithread calls to log() are also unaffected to avoid
>  blocking those threads.
>
>  A minor change to the behaviour in a panic situation is that
>  console output will still be buffered, but won't be written to
>  a tty as before. This should prevent interspersed panic output
>  as a number of CPUs panic before we end up single threaded
>  running ddb.

This souds really good.  Two points:

(1) It would be really good if printf() were no longer used by panic(),
     rather, panic() used db_printf() (once in the debugger) to print the panic
     string.  Right now there's a rather nasty tendency for an interrupt to
     fire while the panic string is printing, especially on slow serial
     consoles, which can result in a second panic when the interrupt thread
     trips over whatever bad state lead to the panic.  This is tricky to debug
     using other people's hands because you have to say things like "Now find
     the thread where the original panic took place", which involves searching
     thread stacks, etc.

(2) Since you're taking an interesting in console code and its
     synchonization, are you interested in looking at locking/etc for syscons?
     There are a lot of spl*() calls in the syscons source...

Robert N M Watson
Computer Laboratory
University of Cambridge