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