Re: I've got it! (Re: oskit-mach)

[Roland McGrath]

> The reboot comes from a `panic' call from the `free_for_oskit' routine
> in [gnumach]/oskit/osenv_mem.c. Here's that piece of code:

Interesting.  Can you show me the stack trace?  The oskit panic routine
should print out a stack trace.  You can feed the addresses to addr2line to
get the functions and source locations from your kernels debug symbols.
(Or if you are using gdb over the serial line to debug oskit-mach, just do
"bt" in gdb.)

> Well it did happen, the linux floppy driver from oskit wanted to free some
> memory for dma. So Roland (or whoever wrote that code), why is this a
> special case and what was your plan exactly?

It's an issue of atomicity.  The Mach kernel memory allocator (kalloc and
kfree) are called with interrupts enabled, meaning that a kalloc call from
some kernel code might be interrupted e.g. to run a device driver's
interrupt handler.  Since this is a possibility, it's not safe for any code
called from an interrupt handler to use kalloc/kfree.  The check in this
function is to make sure that it's not a call from inside an interrupt
handler when it decides to use the kernel memory allocator.  

It might well be that I need to handle this case, as described in the
comment you cited.  But I am a bit suspicious and would be inclined to
investigate what the circumstances are in fact.  For the piece of memory in
question (something allocated by the floppy driver, I gather from what you
said), what is it used for, where is it allocated and freed?  The
alloc_for_oskit function decides what flavor of memory to allocate based on
the parameters in the oskit interface, which are less than perfectly
communicative.  It might be the case that this thing really ought to be
allocated in contiguous physical memory.