On Sat, Sep 30, 2000 at 09:41:55PM -0400, Roland McGrath wrote: > > 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.)
Hmm, if only I had a spare serial terminal lying around. :-) It's a neat thing this addr2line, except that I didn't know about. I used the old `nm kernel | sort | less' trick. But here's the my stack dump: 0016e5fa <panic> (from oskit) 001002fb <free_for_oskit> -+_ [gnumach]/oskit/osenv_mem.h 001007af <mem_free> -+ 00151604 <free_irq> -+ 0014cd6d <floppy_release_irq_and_dma> | 0014a14a <immediate_bh> |- in Oskit 001536cd <do_bottom_half> | 00153742 <linux_intr> | 001513fd <irq_handler> -+ 00100d2a <interrupt> [gnumach]/i386/i386at/interrupt.S 00103789 ??? I can't give more info because, I don't have the image that gave this stack dump anymore. I simply commented out the part of the code that panicked and just used kfree anyway. From what you said below this is not totally safe, but it did work and I was finally able to boot with oskit-mach. I haven't tried using the floppy drive though. Now I can proceed with testing my FPE code additions. Igor > > > 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.