Re: arch_int_restore_interrupts

"Salvatore Benedetto" <[email protected]> Sun, 5 Aug 2007 02:21:37 +0200
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <[email protected]>
On 8/4/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel