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

[Igor Khavkine]

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.