Console output for debugging

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.

Thank you.

--

Serguei Miridonov                CICESE, Research Center,
CICESE, Optics Dept.             Ensenada B.C., Mexico
PO Box 434944                    E-mail: [email protected]
San Diego, CA 92143-4944         FAX: +52 (646) 1750553

U.S.A.

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

Followup to:  <[email protected]>
By author:    Serguei Miridonov <[email protected]>
In newsgroup: linux.dev.kernel

Use printk.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

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:

@@ -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);

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: [email protected]
San Diego, CA 92143-4944         FAX: +52 (646) 1750553

U.S.A.

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).