|
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)
{
...
...
move_rr_back:
switch
(prev->state)
{
case
TASK_INTERRUPTIBLE:
if (signal_pending(prev))
{
prev->state =
TASK_RUNNING;
break;
}
default:
del_from_runqueue(prev); (<---- Be
deleted
here!)
case TASK_RUNNING:
}
...
...
}
I am not familiar with the machanism of
tty_write().
Can any body tell me where should be chceked
over?
My serial driver is modified based on
drivers/char/serial.c
Thanks.
----- Original Message -----
Sent: Friday, July 20, 2001 10:49 AM
Subject: weird printf problem
Hi all,
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
boot up.
In my case, less "printf" work well but more will
fail.
Here is my testing program:
main()
{
int i=0;
while(i<200)
{
printf("Hello
World=%d\n",i);
i++;
}
}
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"
times.
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
die?
Is it the problem of uClibc or kernel?
Does the compiler for my testing program concern this weird
problem?
Can anybody give me some hints?
Thanks,
KJ
|