* Re: Console output for debugging
2002-01-22 23:15 Console output for debugging Serguei Miridonov
@ 2002-01-22 23:31 ` Dave Jones
2002-01-22 23:34 ` H. Peter Anvin
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Dave Jones @ 2002-01-22 23:31 UTC (permalink / raw)
To: Serguei Miridonov; +Cc: linux-kernel
On Tue, Jan 22, 2002 at 03:15:57PM -0800, Serguei Miridonov wrote:
> Q: Is there any function in the kernel which I can call
> safely from a module to print debug message on the console
> screen?
>
> I don't want to use printk for some reasons.
Keith Owens made a patch that allowed direct rendering of text
to console.. I just put an old copy of it at
http://www.kernelnewbies.org/documents/videochar.txt
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Console output for debugging
2002-01-22 23:15 Console output for debugging Serguei Miridonov
2002-01-22 23:31 ` Dave Jones
@ 2002-01-22 23:34 ` H. Peter Anvin
2002-01-23 18:09 ` root
2002-01-22 23:42 ` Andrew Morton
2002-01-23 18:02 ` Serguei Miridonov
3 siblings, 1 reply; 6+ messages in thread
From: H. Peter Anvin @ 2002-01-22 23:34 UTC (permalink / raw)
To: linux-kernel
Followup to: <3C4DF2AD.66BC3F6C@cicese.mx>
By author: Serguei Miridonov <mirsev@cicese.mx>
In newsgroup: linux.dev.kernel
>
> Q: Is there any function in the kernel which I can call
> safely from a module to print debug message on the console
> screen?
>
> I don't want to use printk for some reasons. One of them is
> that I want messages to appear on the screen immediately,
> even from interrupt processing routines. Another is to be
> able to see messages until the system freezes completely in
> case of software or hardware bug.
>
Use printk.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Console output for debugging
2002-01-22 23:34 ` H. Peter Anvin
@ 2002-01-23 18:09 ` root
0 siblings, 0 replies; 6+ messages in thread
From: root @ 2002-01-23 18:09 UTC (permalink / raw)
To: linux-kernel
"H. Peter Anvin" wrote:
> Followup to: <3C4DF2AD.66BC3F6C@cicese.mx>
> By author: Serguei Miridonov <mirsev@cicese.mx>
> In newsgroup: linux.dev.kernel
> >
> > Q: Is there any function in the kernel which I can call
> > safely from a module to print debug message on the console
> > screen?
> >
> > I don't want to use printk for some reasons. One of them is
> > that I want messages to appear on the screen immediately,
> > even from interrupt processing routines. Another is to be
> > able to see messages until the system freezes completely in
> > case of software or hardware bug.
> >
>
> Use printk.
But beware of some ioctls to which at least Suse defaults,
these can intercept the direct output to the console (and
let syslogd emulate the console output).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Console output for debugging
2002-01-22 23:15 Console output for debugging Serguei Miridonov
2002-01-22 23:31 ` Dave Jones
2002-01-22 23:34 ` H. Peter Anvin
@ 2002-01-22 23:42 ` Andrew Morton
2002-01-23 18:02 ` Serguei Miridonov
3 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2002-01-22 23:42 UTC (permalink / raw)
To: Serguei Miridonov; +Cc: linux-kernel
Serguei Miridonov wrote:
>
> Q: Is there any function in the kernel which I can call
> safely from a module to print debug message on the console
> screen?
>
> I don't want to use printk for some reasons. One of them is
> that I want messages to appear on the screen immediately,
> even from interrupt processing routines. Another is to be
> able to see messages until the system freezes completely in
> case of software or hardware bug.
>
printk does all this, usually. It is synchronous, so when
it returns to your code, the text is on the screen.
The only exception to this is when you perform a printk
from within an interrupt handler *while* printk itself
is executing in non-interrupt context. When this rare
situation occurs, the text is buffered, to be emitted
by the non-interrupt code before it returns to its caller.
If the printk-within-printk buffering is a problem for you,
(which I doubt) then you could disable interrupts while
running printk. Something like this:
--- linux-2.4.18-pre6/kernel/printk.c Tue Jan 22 12:38:31 2002
+++ linux-akpm/kernel/printk.c Tue Jan 22 15:40:57 2002
@@ -412,6 +412,10 @@ asmlinkage int printk(const char *fmt, .
char *p;
static char printk_buf[1024];
static int log_level_unknown = 1;
+ static spinlock_t printk_lock = SPIN_LOCK_UNLOCKED;
+ unsigned long xflags;
+
+ spin_lock_irqsave(&printk_lock, xflags);
if (oops_in_progress) {
/* If a crash is occurring, make sure we can't deadlock */
@@ -471,6 +475,7 @@ asmlinkage int printk(const char *fmt, .
spin_unlock_irqrestore(&logbuf_lock, flags);
}
out:
+ spin_unlock_irqrestore(&printk_lock, xflags);
return printed_len;
}
EXPORT_SYMBOL(printk);
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Console output for debugging
2002-01-22 23:15 Console output for debugging Serguei Miridonov
` (2 preceding siblings ...)
2002-01-22 23:42 ` Andrew Morton
@ 2002-01-23 18:02 ` Serguei Miridonov
3 siblings, 0 replies; 6+ messages in thread
From: Serguei Miridonov @ 2002-01-23 18:02 UTC (permalink / raw)
To: linux-kernel
First of all, thanks to everybody who replied to my post.
Now I would like to clarify why I don't want to use printk...
1. This output is not intended to be logged at all. I just want to catch the
event which locks the system.
2. This console print must be very fast and atomic, so I will be sure that
some particular checkpoint in the driver passed.
3. This is not intended to be in production code, so I think that it is OK
even if it is very i386 specific.
4. I don't want to spend much time in printk, I prefer to have something like
direct VGA display memory writing. I know it can be done with something like
a solution proposed by Keith Owens
(http://www.kernelnewbies.org/documents/videochar.txt) but with additional
phys_to_virt macro. The only problem is that I need to find a way to switch
console VGA to a mode compatible with this.
Why do I need this? Well, I'm one of maintainers of driver for Zoran MJPEG
chipset based video capture cards
(http://www.cicese.mx/~mirsev/Linux/DC10plus/). The driver seems to work with
almost any platform but has a lot of problems with my new Soyo Dragon Plus
motherboard (KT266A chipset). At the beginning I had everything like
filesystem corruptions, lockups, etc. Many problems were solved by so called
PCI latency patch
http://www.cicese.mx/~mirsev/Linux/VIA/VIA-latency-linux.html and now the
system is very stable unless I run a program which uses MJPEG hardware codec
of DC10plus card (Zoran 36067/36060 chipset). After a few seconds (sometimes
immediately) the system locks up completely. Other user who has similar
hardware also has this problem.
I wrote to VIA support, to Pinnacle Systems (DC10plus card maker) but they
remain silent. I was asking people who run these cards successfully on
systems based on KT266A chipset to send their lspci outputs to try the same
registers settings myself. However I have received only one from someone who
indeed successfully runs Iomega Buz on this VIA chipset. But the Iomega Buz
card is a little bit different, it has its own PCI bridge which controls
motherboard PCI bus, not like in DC10plus where PCI bus is controlled by
ZR36067 chip.
So, what I intend to do is to add these checkpoints in the driver to see some
data supplied to the card (fragmentation table, MJPEG buffer addresses, size,
etc.) and return back to look for any clue which leads to the system failure.
May be there is some boundary crossing in PCI bus master mode which
VIA chipset may not like or anything else...
This debug output must be very fast. It would be nice if I can catch starting
PCI master transaction which locks the system...
So, that's the story...
--
Serguei Miridonov CICESE, Research Center,
CICESE, Optics Dept. Ensenada B.C., Mexico
PO Box 434944 E-mail: mirsev@cicese.mx
San Diego, CA 92143-4944 FAX: +52 (646) 1750553
U.S.A.
^ permalink raw reply [flat|nested] 6+ messages in thread