using printk without buffering
Laurent Chavey
out. What I am looking for is a way to guarranty that a given string is
output
before printk returns.
any ideas.
I have a oops message come up but the machine is frozen, is there a way to
get
that message sent to the serial port before the machine freezes.
Heinz Häberle
Peter Samuelson
[Laurent Chavey <cha...@rosemail.rose.hp.com>]
> is there a way to have printk behave "atomicly" when printing
> characters out. What I am looking for is a way to guarranty that a
> given string is output before printk returns.
Then you mean "sychronously", not "atomically".
> I have a oops message come up but the machine is frozen, is there a
> way to get that message sent to the serial port before the machine
> freezes.
I imagine that making printk synchronous would have two big problems:
(a) it would make the kernel thread in question wait on a possibly slow
interface, and (b) it would invite deadlocks, since the function
calling printk (or the function that page-faulted to the oops handler
that then called printk) might be holding a lock that is needed during
some part of the print process.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
Klaus Elend
> I imagine that making printk synchronous would have two big problems:
> (a) it would make the kernel thread in question wait on a possibly slow
> interface, and (b) it would invite deadlocks, since the function
> calling printk (or the function that page-faulted to the oops handler
> that then called printk) might be holding a lock that is needed during
> some part of the print process.
Having exactly the problem Laurent has, I changed
kernel/printk.c to additionally write all messages to one of the
UARTs. This works synchronously, the routine waits after each
character until it is sent. It is even possible to do printk()s
from within interrupt routines, when it *only* writes the message
to the serial port then.
I do not think problem (a) is really a problem, since we are
not talking about a production system, only about a test tool,
where performance should not really be an issue. (b) does not
exist, since only the output to the serial port is synchronous,
and there are of course no locks needed for that.
I am not going to post my changes here because the
implementation is *really* rude, but I will mail them if you
like.
Klaus
--
-----------------------------------------------------------------
Ingenieurbuero Ingo Mohnen Tel +49 (241) 94924-11
Rottstrasse 33 Fax +49 (241) 94924-29
52068 Aachen mailto:kl...@imp.ac.uunet.de
Germany http://members.aol.com/impaachen
Mark Langsdorf
Klaus Elend wrote in message <38328299...@imp.ac.uunet.de>...
>Peter Samuelson wrote:
>> I imagine that making printk synchronous would have two big problems:
>> (a) it would make the kernel thread in question wait on a possibly slow
>> interface, and (b) it would invite deadlocks, since the function
>> calling printk (or the function that page-faulted to the oops handler
>> that then called printk) might be holding a lock that is needed during
>> some part of the print process.
>
> Having exactly the problem Laurent has, I changed
>kernel/printk.c to additionally write all messages to one of the
>UARTs. This works synchronously, the routine waits after each
>character until it is sent. It is even possible to do printk()s
>from within interrupt routines, when it *only* writes the message
>to the serial port then.
> I am not going to post my changes here because the
>implementation is *really* rude, but I will mail them if you
>like.
If you would please. I'm trying to support a proprietary debug
interfance with serial-like characteristics, and I'd like to see how
someone else handled the issues I'm dealing with.
-Mark Langsdorf
Peter Pointner
> Peter Samuelson wrote:
>> I imagine that making printk synchronous would have two big problems:
>> (a) it would make the kernel thread in question wait on a possibly slow
>> interface, and (b) it would invite deadlocks, since the function
>> calling printk (or the function that page-faulted to the oops handler
>> that then called printk) might be holding a lock that is needed during
>> some part of the print process.
> Having exactly the problem Laurent has, I changed
> kernel/printk.c to additionally write all messages to one of the
> UARTs. This works synchronously, the routine waits after each
> character until it is sent. It is even possible to do printk()s
> from within interrupt routines, when it *only* writes the message
> to the serial port then.
> I do not think problem (a) is really a problem, since we are
> not talking about a production system, only about a test tool,
> where performance should not really be an issue. (b) does not
> exist, since only the output to the serial port is synchronous,
> and there are of course no locks needed for that.
> I am not going to post my changes here because the
> implementation is *really* rude, but I will mail them if you
> like.
> Klaus
Do you really need to change the kernel? You can have the output at
more than one device by simply giving more than one "console=..."
parameter to the kernel. The last one will be /dev/console, but all
will get the printk's. All valid at least for 2.2.13, and documented
in /usr/src/linux/Documentation/serial-console.txt.
Peter
Peter Samuelson
[Peter Samuelson <cadcamlab.org!peter>]
> > (a) it would make the kernel thread in question wait on a possibly
> > slow interface
[Klaus Elend <kl...@imp.ac.uunet.de>]
> I do not think problem (a) is really a problem, since we are not
> talking about a production system, only about a test tool, where
> performance should not really be an issue.
Right, for testing you can do whatever you want. I was talking about
making kernel changes to distribute or use in general-purpose systems.
Not that the kernel in normal operation does a *lot* of printk's, but
still....
> (b) does not exist, since only the output to the serial port is
> synchronous, and there are of course no locks needed for that.
OK.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
Klaus Elend
> Do you really need to change the kernel? You can have the output at
> more than one device by simply giving more than one "console=..."
> parameter to the kernel. The last one will be /dev/console, but all
> will get the printk's. All valid at least for 2.2.13, and documented
> in /usr/src/linux/Documentation/serial-console.txt.
Having the output written to multiple devices is not my point,
this is indeed possible wihtout kernel modification.
What I needed was synchronous output because I had a bug in my
driver that made the machine crash. So with the last few
printk()-messages left in some buffer at the time of the crash,
I never knew exactly where in my code the bug was.
And this cannot be achieved (to my knowledge) with an unchanged
kernel.
Laurent Chavey
describe it
(I like Klaus description, it goes right to the point), may be a good add on
feature
to the current printk function
- many time the current printk buffering makes it impossible to guess what
goes wrong.
- the loging of printk (in debug mode) on an other machine is kind of nice
when the file system
is what you are debuging
thank klaus for your help, maybe you can post the code so it gets archive
in the news group
for future requests ?
-**** Posted from RemarQ, http://www.remarq.com/?a ****-
Search and Read Usenet Discussions in your Browser - FREE -