Hello!
Simple question: Do printk()s get printed while interrupts are disabled
(after cli)?
Thanks
Norbert
++ 02/10/01 13:37 +0200 - Norbert Roos:
> Hello!
>
> Simple question: Do printk()s get printed while interrupts are disabled
> (after cli)?
They get stuffed into a buffer to be printed later. It is possible to
overflow that buffer, and lose some of your printk messages.
from krenel/printk.c:
/*
* This is printk. It can be called from any context. We want it to
* work.
*
* We try to grab the console_sem. If we succeed, it's easy - we log
* the output and
* call the console drivers. If we fail to get the semaphore we place
* the output
* into the log buffer and return. The current holder of the
* console_sem will
* notice the new output in release_console_sem() and will send it to
* the
* consoles before releasing the semaphore.
*
* One effect of this deferred printing is that code which calls
* printk() and
* then changes console_loglevel may break. This is because
* console_loglevel
* is inspected when the actual printing occurs.
*/
...
/* This stops the holder of console_sem just where we want him
* */
spin_lock_irqsave(&logbuf_lock, flags);
--
Crutcher <[email protected]>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$
On Tue, Oct 02, 2001 at 10:22:10AM -0400, Crutcher Dunnavant wrote:
> They get stuffed into a buffer to be printed later. It is possible to
> overflow that buffer, and lose some of your printk messages.
Incidentally, something I noticed today: when using a parallel printer
console, 'Alt-SysRq-T' gave me a complete task list followed by the
entire kernel ring buffer.
I've taken a look at the code in lp.c, sysrq.c, and printk.c, and I
don't see what can be causing it. Anyone have ideas?
This happened when the machine had locked up for some reason.
Tim.
*/
Crutcher Dunnavant wrote:
>
> ++ 02/10/01 13:37 +0200 - Norbert Roos:
> > Hello!
> >
> > Simple question: Do printk()s get printed while interrupts are disabled
> > (after cli)?
>
> They get stuffed into a buffer to be printed later. It is possible to
> overflow that buffer, and lose some of your printk messages.
Not quite - a printk from cli() or hardirq context will normally
come out immediately. The only time the deferred buffering
thing happens is if the console semaphore is found to be already held on
entry to printk(). ie: there is already a printk in progress on another CPU
or on this CPU in non-interrupt context.
The buffered printk output will be printed by the current console-sem
owner before it releases the semaphore.