printk problems

printk problems

[Avinash S.]

Hello,
I am trying to port linux to a custom built IDT MIPS board. I have 
managed to get the UART working. My bootup code loads and prints some 
debugging messages initially and then actual kernel bootup occurs. 
However it hangs when it reaches the first printk function. i have tried 
to debug this with some difficulty but with no effect. Could some one 
tell me or atleast point me to where i can get some info on how printk 
works or atleast how to debug my printk to see where the actual problem 
lies?

Thanks in advance.


Avinash

Re: printk problems

[Justin Carlson]

On Tue, 2003-04-08 at 07:57, Avinash S. wrote:
> Hello,
> I am trying to port linux to a custom built IDT MIPS board. I have 
> managed to get the UART working. My bootup code loads and prints some 
> debugging messages initially and then actual kernel bootup occurs. 
> However it hangs when it reaches the first printk function. i have tried 
> to debug this with some difficulty but with no effect. Could some one 
> tell me or atleast point me to where i can get some info on how printk 
> works or atleast how to debug my printk to see where the actual problem 
> lies?
> 

Couple quick questions:

1)  I assume you want to do console over serial port.  You have
SERIAL_CONSOLE enabled in your .config, right?

2) Is the UART standard, for which a driver is extant?  If not, you'll
need to write one.  

3) Are you sure it's hanging, or is it just not reporting anything
else?  Do you have other status indicators (i.e. LED's of some sort?)


Here's the 30 second summary of what happens at bootup on a serial
console.  This is mostly from memory a year old or so, so don't take
this as gospel:

Pretty early in the boot sequence (in init/main.c) console_init() is
called (in drivers/char/tty_io.c).  If your serial driver is compiled in
with console support, the serial port is initialized here, and added to
a list of available consoles.  The first(?) extant console is chosen for
console output, where your printk()s will end up.

Until this point, printk() calls are buffered in memory.  If you have
printk()s not showing up, odds are pretty good you're failing to
initialize the serial console in some way.

Hope that helps...

-Justin

Re: printk problems

[Jun Sun]

On Tue, Apr 08, 2003 at 05:27:23PM +0530, Avinash S. wrote:
> Hello,
> I am trying to port linux to a custom built IDT MIPS board. I have 
> managed to get the UART working. My bootup code loads and prints some 
> debugging messages initially and then actual kernel bootup occurs. 
> However it hangs when it reaches the first printk function. i have tried 
> to debug this with some difficulty but with no effect. Could some one 
> tell me or atleast point me to where i can get some info on how printk 
> works or atleast how to debug my printk to see where the actual problem 
> lies?
>

You might want to try the early printk approach.  See

http://linux.junsun.net/porting-howto/

Jun

Re: printk problems

[Michael Pruznick]

> Until this point, printk() calls are buffered in memory. 

This is what I like to use to bypass the buffering for
non-standard serial hardware.  

The raw_output() function needs to be specific to
your serial driver.  The one below is just an example
from a board I'm currently working on (that is not in
the linux-mips tree yet).  Basically, raw_output() needs
to put the char in the serial hardware output register
and then wait for the serial hardware to indicate that
it put the char on the wire to prevent over-run.


Changes to kernel/printk.c
#define RAW_OUTPUT
static void emit_log_char(char c)
{
#ifdef RAW_OUTPUT
        void raw_output(char c);
        raw_output(c);
#else
        LOG_BUF(log_end) = c;
        log_end++;
        if (log_end - log_start > LOG_BUF_LEN)
                log_start = log_end - LOG_BUF_LEN;
        if (log_end - con_start > LOG_BUF_LEN)
                con_start = log_end - LOG_BUF_LEN;
        if (logged_chars < LOG_BUF_LEN)
                logged_chars++;
#endif
}


What I added to my serial driver.  You will need to
do the similar for your specific serial hardware.
#ifdef RAW_OUTPUT
void raw_output(char c)
{
        struct rs_port *port = &rs_ports[0];
        if ( c == '\n' )
        {
          sio_out(port, TXX9_SITFIFO, '\r');
          wait_for_xmitr(port);
        }
        sio_out(port, TXX9_SITFIFO, c);
        wait_for_xmitr(port);
        return;
}
#endif


-- 
Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com
MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085

printk problems

[Arrigo Benedetti]

For some reason I can't get printk() to work on a YDL 4.0 system. I have 
followed all the instructions, like
setting the correct log level in /proc/sys/kernel/printk, killing klogd 
and then

cat /proc/kmsg

but I do not see any message from printk. The printk is in a new kernel 
system call that I wrote.
Any ideas?

thanks much
-Arrigo

Re: printk problems

[Benjamin Herrenschmidt]

On Wed, 2004-11-03 at 12:13 -0800, Arrigo Benedetti wrote:
> For some reason I can't get printk() to work on a YDL 4.0 system. I have 
> followed all the instructions, like
> setting the correct log level in /proc/sys/kernel/printk, killing klogd 
> and then
> 
> cat /proc/kmsg
> 
> but I do not see any message from printk. The printk is in a new kernel 
> system call that I wrote.
> Any ideas?

Are you sure you are reaching your syscall at all ? Besides, why are you
adding a syscall in the first place ? (just curious ... it's usually the
wrong solution :)

Ben.

Re: printk problems

[Arrigo Benedetti]

Benjamin Herrenschmidt wrote:

>On Wed, 2004-11-03 at 12:13 -0800, Arrigo Benedetti wrote:
>  
>
>>For some reason I can't get printk() to work on a YDL 4.0 system. I have 
>>followed all the instructions, like
>>setting the correct log level in /proc/sys/kernel/printk, killing klogd 
>>and then
>>
>>cat /proc/kmsg
>>
>>but I do not see any message from printk. The printk is in a new kernel 
>>system call that I wrote.
>>Any ideas?
>>    
>>
>
>Are you sure you are reaching your syscall at all ? Besides, why are you
>adding a syscall in the first place ? (just curious ... it's usually the
>wrong solution :)
>
>  
>

I'm pretty sure that the syscall is called, in fact at some point there 
was a bug in the code which
froze the system... I made a syscall just to do some quick timing tests. 
I agree that a module is a
better solution, and in fact I have just posted a message about that...

-Arrigo