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