definition of kprintf

[sancho1980]

hi

after finally having figured out how to get kprintf output redirected
to the serial interface, i can see what the scheduler says, yeah :-D
after my first couple of general protection faults, i finally managed
to write the scheduler in such a way, that it "only" hangs on startup
the debug output i get from my serial interface tells me that the
system task is constantly sending and receiving to/from tty, so i
suspect somehow, all the debugging output is at the same time being
redirected to the tty

i modified kputc in such a way that it ONLY puts the character on the
serial interface, but kprintf seems to do something else beside
calling kputc that makes the system task create messages for the tty
my question: where is kprintf actually defined???
in kernel/kprintf.c there is an include of a file "../lib/sysutil/
kprintf.c"
and there is also a #define printf kprintf
but in "../lib/sysutil/kprintf.c", there is no function called kprintf
() defined, there is only a printf() (no K)
so hey im confused here
first you define a macro that makes all invocations of printf expand
to kprintf and then instead of writing a function called kprintf(),
you provide one called printf()..what's the voodoo here??

thanks

martin

[Tomas Hruby]

> i modified kputc in such a way that it ONLY puts the character on the
> serial interface, but kprintf seems to do something else beside
> calling kputc that makes the system task create messages for the tty
> my question: where is kprintf actually defined???

Do you return from kputc just after ser_putc()? That should suppress
output to tty.

> first you define a macro that makes all invocations of printf expand
> to kprintf and then instead of writing a function called kprintf(),
> you provide one called printf()..what's the voodoo here??

Actually the define renames _definition_ of printf to kpritnf. The
printf() in libc is called kprintf in kernel. Afaik, it is the same
code.

T.

[sancho1980]

> Do you return from kputc just after ser_putc()? That should suppress
> output to tty.

I don't think so.
To see what I mean, just try the following:

change the code of kputc as follows:

{
serput(c);
return;
}

then, just at the very start of mini_send insert the following:

{
kprintf("mini_send() from %s to %s\n", caller_ptr->p_name, dst_ptr-
>p_name);
...
}

then try to boot up your system...
but make sure you backup your old image ;-)

martin

[Tomas Hruby]

On Sun, Jul 19, 2009 at 12:11:28PM -0700, sancho1980 wrote:
>
> > Do you return from kputc just after ser_putc()? That should suppress
> > output to tty.
>
> I don't think so.
> To see what I mean, just try the following:
>
> change the code of kputc as follows:
>
> {
> serput(c);
> return;
> }

Yes, that works, the kernel output goes _only_ to the serial console.

> then, just at the very start of mini_send insert the following:
>
> {
> kprintf("mini_send() from %s to %s\n", caller_ptr->p_name, dst_ptr-
> >p_name);
> ...
> }
>
> then try to boot up your system...
> but make sure you backup your old image ;-)

Beware, prints in functions like this will lock up your system as
these prints are so frequent that the system does not do anything else
then printing.

The messages to/from tty are not kprint related, no tty at the
begining of the output :

MINIX 3.1.4. Copyright 2009, Vrije Universiteit, Amsterdam, The
Netherlands
MINIX is open source software, see http://www.minix3.org
mini_send() from vm to system
mini_send() from system to vm
mini_send() from vm to system
mini_send() from system to vm
mini_send() from vm to system
mini_send() from system to vm


They are triggered by other processes trying to print. Might be that
something is starving due to the prints.

Cheers, T.

[sancho1980]

i'm really clueless here
so if you say too many printfs in the kernel may lead to starvation, i
did the following now
i inserted a kprintf() statement in mini_send(), only where a send()
is actually being carried out (where a receiver is waiting)
and i inserted another kprintf() in mini_receive, only where a receive
() is being carried out (where a sender is waiting)
i *only* messed around with the scheduler and the clock_handler, i
didnt modify in any way the clock task, system task or any user space
processes
but the output i get suggests system and tty have a lot to chat, im
clueless here:

mini_receive: system now receiving from pm
^@mini_send(): system now sending to pm
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_receive: system now receiving from log
^@mini_send(): system now sending to log
^@mini_receive: system now receiving from pm
^@mini_send(): system now sending to pm
^@mini_send(): pm now sending to system
^@mini_send(): system now sending to pm
^@mini_send(): pm now sending to system
^@mini_send(): system now sending to pm
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
^@mini_send(): tty now sending to system
^@mini_send(): system now sending to tty
...goes on like this forever

any ideas?

thanks

martin

[Tomas Hruby]

On Sun, Jul 19, 2009 at 03:12:43PM -0700, sancho1980 wrote:
>
> i'm really clueless here
> so if you say too many printfs in the kernel may lead to starvation, i
> did the following now
> i inserted a kprintf() statement in mini_send(), only where a send()
> is actually being carried out (where a receiver is waiting)
> and i inserted another kprintf() in mini_receive, only where a receive
> () is being carried out (where a sender is waiting)
> i *only* messed around with the scheduler and the clock_handler, i
> didnt modify in any way the clock task, system task or any user space
> processes
> but the output i get suggests system and tty have a lot to chat, im
> clueless here:

What if you suppress all prints with tty on either side? Whoud that
give you more useful output? What if you print only per every 100
messages? That makes my system responsive. Would it give you enough
info to debug your stuff?

> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ...goes on like this forever
>
> any ideas?

These are mostly SYS_DEVIO sys_calls

Cheers, T.

[Martin Knappe]

> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ^@mini_send(): tty now sending to system
> ^@mini_send(): system now sending to tty
> ...goes on like this forever
>
> any ideas?

These are mostly SYS_DEVIO sys_calls

Do they never stop? afaik, tty only generates messages to system after being asked to perform some action on behalf of a user process, but when no one is sending to tty, how come tty generates messages on its own?

thanks

martin

[sancho1980]

to be hones with you, i don't see how a process might possibly starve
because of all the prints from the kernel
as you can see from my output, something is constantly going on
between tty and system so they obviously have something to say to each
other
but eventually, this should stop, and then tty should block, giving
way to the other processes, no matter how badly the scheduler works...
what am i getting wrong here, can someone please explain??

thanks

martin

[MIMI]

hi
I add a kprintf in enqueue() function in /usr/src/kernel/proc.c to write some message each time that a process is runnable.
why no message printed?!!

[Erik van der Kouwe]

Hi,

Are you adding a newline (\n) at the end?

BTW please always add new questions in a new thread. This is a bit confusing as it doesn't seem to have much to do with the other posts in this thread.

With kind regards,
Erik

Op maandag 17 december 2012 01:39:47 UTC+1 schreef MIMI het volgende: