[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I've got it! (Re: oskit-mach)
From: |
Igor Khavkine |
Subject: |
Re: I've got it! (Re: oskit-mach) |
Date: |
Sat, 30 Sep 2000 23:11:11 -0400 |
User-agent: |
Mutt/1.2.5i |
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.