My kernel version is 2.4.1 and the processor is an MIPS R4000
style embedded processor.
I ues the serial port as my console.
I found that the reason why the printf message will not be
completely outputed is the process of my testing program will not be selected
again by the schedular after outputing some message.
Its "state" is TASK_INTERRUPTIBLE but the return value of
signal_pending(prev) is zero.
Therefore, it is deleted from running queue in
schedul() and never wake up.
asmlinkage void schedule(void)
del_from_runqueue(prev); (<---- Be
I am not familiar with the machanism of
Can any body tell me where should be chceked
My serial driver is modified based on
----- Original Message -----
Sent: Friday, July 20, 2001 10:49 AM
Subject: weird printf problem
I ported linux to my embeded board and encountered
a weird "printf" problem.
The library i used is uClibc.
I made the kernel to run a testing program directly after
In my case, less "printf" work well but more will
Here is my testing program:
The output message will die at "Hello World=10" or
"Hello World=168" or "Hello World=76" ........
Every times the message dies at different place but it will never successfully be outputed "200"
However, if the condition is changed to "while(i<100)",
then everything is fine.
It is so weird!!
Why too much "printf" will cause the program to
Is it the problem of uClibc or kernel?
Does the compiler for my testing program concern this weird
Can anybody give me some hints?