headers
Ingo Weinhold | 4 Aug 2007 23:24
Picon

Re: arch_int_restore_interrupts


On 2007-08-04 at 22:13:18 [+0200], Salvatore Benedetto
<emitrax@...> 
wrote:
> I didn't open a ticket because I can't really call it a bug since there is
> this ToDo in the dprintf function
> 
>     // ToDo: maybe add a non-interrupt buffer and path that only
>     //  needs to acquire a semaphore instead of needing to disable
>     //  interrupts?
> 
> Basically I'm doing an heavy use of TRACE calls (a.k.a. dprintf) to debug
> my thread, and sometimes (actually often) my systems hangs. At first I
> thought
> I introduced a deadlock but then, by looking at the stack frame
> in kdl I saw that the system was blocked at
> 
> arch_int_restore_interrupts
> restore_interrupts
> dprintf
> mythread
> etc...

Not sure what you mean with the "system was blocked at ...". 
arch_int_restore_interrupts() does nothing that would block the system in 
anyway. It performs a few harmless instructions and returns.

If you're printing a lot of debug info, your thread will spend quite a lot 
of time in dprintf() with interrupts disabled. It is likely that a timer 
interrupt occurs or you've pressed the F12 key (=> keyboard interrupt)
(Continue reading)

Permalink | Reply |
headers
Salvatore Benedetto | 5 Aug 2007 02:21
Picon

Re: arch_int_restore_interrupts

On 8/4/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/Q@public.gmane.org> wrote:

Not sure what you mean with the "system was blocked at ...".
arch_int_restore_interrupts() does nothing that would block the system in
anyway. It performs a few harmless instructions and returns.

When I say that the system "blocked at", I mean that even the mouse stopped
moving, the only thing I could do was pressing F12 to enter KDL and see what
the system was doing, and more than once, the running thread was my thread and
the stack frame looks like I wrote in the previous email.

If you're printing a lot of debug info, your thread will spend quite a lot
of time in dprintf() with interrupts disabled. It is likely that a timer
interrupt occurs or you've pressed the F12 key (=> keyboard interrupt)
during that time. Thus as soon as your thread enables interrupts again, it
will be interrupted, which is why you'll see it very often at exactly that
point

Ok, thanks for the explanation. :)

.

> so I'm wondering if this ToDo is going to become history any time soon. :)

If you make it so, this can happen very soon. :-) I'm afraid it might not
help much with your problem, since it's basically a system performance
optimization (i.e. dprintf() won't reserve the CPU while doing the output).

Note, that heavy debug output may indeed make your system appear to make no
more progress. The more common case is that it just becomes *really* slow.
A rarer case, particularly when adding enough output in the interrupt
handling code (i386_handle_trap()), is that you really manage to stall the
system.

So do you think that this behavior is due to heavy use of dprintf?

CU, Ingo

Salvo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Open-beos-kernel-devel mailing list
Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel



--
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer and Telecommunications Engineering
University of Messina (Italy)
www.messinalug.org 
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Open-beos-kernel-devel mailing list
Open-beos-kernel-devel@...
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
Permalink | Reply |
headers
Ingo Weinhold | 5 Aug 2007 03:30
Picon

Re: arch_int_restore_interrupts


On 2007-08-05 at 02:21:37 [+0200], Salvatore Benedetto
<emitrax@...> 
wrote:
> > Note, that heavy debug output may indeed make your system appear to make
> > no
> > more progress. The more common case is that it just becomes *really* slow.
> > A rarer case, particularly when adding enough output in the interrupt
> > handling code (i386_handle_trap()), is that you really manage to stall the
> > system.
> 
> So do you think that this behavior is due to heavy use of dprintf?

That's hard to say. If the problem doesn't occur any longer, after you 
disable debug output, then it's pretty likely. In that case, if you mostly 
have interrupts enabled while calling dprintf() from your thread, you might 
indeed think about implementing the second dprintf() path, as it might 
improve the situation.

Note, that our current scheduler seems to have a problem with higher priority 
threads starving lower priority ones. Doing a lot (that includes debug 
output) in a high priority thread can quite likely cause system blocking as 
you describe it.

CU, Ingo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Permalink | Reply |
headers
Salvatore Benedetto | 5 Aug 2007 14:49
Picon

Re: arch_int_restore_interrupts

On 8/5/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/Q@public.gmane.org> wrote:

That's hard to say. If the problem doesn't occur any longer, after you
disable debug output, then it's pretty likely. In that case, if you mostly
have interrupts enabled while calling dprintf() from your thread, you might
indeed think about implementing the second dprintf() path, as it might
improve the situation.

I haven't disabled debug output yet, and the problem has just occurred again.
I realized the scheduler doesn't stop, as getting in and out of KDL gives me a different
running thread (even if always the very same few). System though, does not respond to
the mouse.

Note, that our current scheduler seems to have a problem with higher priority
threads starving lower priority ones. Doing a lot (that includes debug
output) in a high priority thread can quite likely cause system blocking as
you describe it.


Thanks again for you help.

CU, Ingo

Salvo

--
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer and Telecommunications Engineering
University of Messina (Italy)
www.messinalug.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Open-beos-kernel-devel mailing list
Open-beos-kernel-devel@...
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
Permalink | Reply |

Gmane