arch_int_restore_interrupts

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

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/

Re: arch_int_restore_interrupts

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

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/

Re: arch_int_restore_interrupts

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

DDM Documentation

Hi,

I looked at the documentation patches for the DDM interface and the
reusable parts are the documentation for the kernel interface for
partition modules (ddm_modules.h) and the documentation on the
userspace classes (which will belong to the storage kit).

Questions:

1. Currently both the kernel interface and the userspace classes are
private. Will these move to the public headers?
2. The ddm_modules.h file contains a list of typedefs, which are then
linked into the partition_module_info struct. Is this really
necessary? Because it produces messy output.
3. If the documentation will be part of the Haiku Book, what names
should be credited?

In case the answer to question 1 is "No", I will stop working on it
and I will put it in another part of the docs directory tree.

Kind Regards,

Niels

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

Re: DDM Documentation

On 2007-08-09 at 15:52:24 [+0200], Niels Reedijk
<niels.reedijk@...> 
wrote:
> 
> I looked at the documentation patches for the DDM interface and the
> reusable parts are the documentation for the kernel interface for
> partition modules (ddm_modules.h) and the documentation on the
> userspace classes (which will belong to the storage kit).
> 
> Questions:
> 
> 1. Currently both the kernel interface and the userspace classes are
> private. Will these move to the public headers?

Eventually yes. But just as the layout API they are private/experimental 
ATM. Probably till some R1.x or R2.

> 2. The ddm_modules.h file contains a list of typedefs, which are then
> linked into the partition_module_info struct. Is this really
> necessary? Because it produces messy output.

No, it's not necessary. I plan to change that. Moreover the supports_*() 
hooks will be compacted into a single hook (same for the FS interface).

> 3. If the documentation will be part of the Haiku Book, what names
> should be credited?

In doubt the three names Jan listed, I suppose.

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/