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) 
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.

> 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.

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/