Re: Falcon panics, DEBUG & ST_POOL_SIZE (Was: Testing sysinst.fs)

[David Brownlee <abs%NetBSD.org@localhost>]

On Wed, 12 Nov 2008, T. Makinen wrote:

> On Tue, Nov 11, 2008 at 1:42 AM, David Brownlee <abs%netbsd.org@localhost> 
> wrote:
> >        Excellent. So 22 fails but 40 works. Could you maybe test 32 and
> >        a couple of other values to find the smallest value that reliably
> >        works?
>
> Yes, I'll run some tests with different ST_POOL_SIZE values tomorrow with
> unclean file systems.
        Adding 'fsck_flags=-fp' to /etc/rc.conf will force a full fsck on
        boot. (Add -P if you like a progress bar :)

> >        Does a kernel without REAL_DMA choke on both, or does it work on
> >        030 and fail on 060?
>
> Kernel without REAL_DMA worked with 030 and 060. So far the only crash has been
> with kernel which has REAL_DMA defined and ST_POOL_SIZE set to 22.

        Interesting... so with a high enough ST_POOL_SIZE we may not
        need to undefine REAL_DMA at all, which would be nice.

        If you run out of other tests it might be interesting to see
        the relative performance with and without REAL_DMA (something
        like pkgsrc/benchmarks/iozone would probably be a reasonable
        test case). Only if you run out of other things to play with :)

> >        OK, so we're choking in one of the three uvm_map() calls in
> >        pmap_init() in sys/arch/atari/atari/pmap.c
> >        uvm_km_check_empty() is checking that an area of memory
> >        is free to map (that is doesn't overlap with any existing
> >        mappings).
> >
> >        Could you add printf() calls before each of those uvm_map()s
> >        showing the address and length in each case? That should let
> >        us know which is failing, and hopefully some insight into
> >        what is overlapping.
>
> It fails at first uvm_map() call. I added debug printf() calls with address and
> value of addr, hopefully this helps.
>
> Here's picture of panic (sorry about crappy quality this time), debug printf()
> output is at second line:
> http://koti.welho.com/tmakinen/atari/debug.jpg

        I'm curious that the 0x4fb0000 in uvm_map is given as a size, but
        uvm_km_check_empty() panics when it gets to virtual *address*
        0x4fb0000.

> Here's also dmesg with debug printf() calls from FALCON kernel without DEBUG
> option:
> http://koti.welho.com/tmakinen/atari/Falcon-netbsd-debug-dmesg

        OK, those the numbers in the uvm_map calls make ~no sense to me.
        The same vaddr_t start in all cases but with different sizes?
        I think something very bogus is going on.
        Hmmm, in atari/pmap.c we have

                pmap_bootstrap(kernel_size, hw_addr, hw_pages)

        While atari/atari_init.c calls

                pmap_bootstrap(vstart, stio_addr, ptextra);
                where (as far as I can tell)
                    vstart: first free virtual address
                    stio_addr: is set to 0xff8000, then
                      reset to something else in map_io_areas()
                    ptextra: number of pages needed by the initial
                      kernel pagetable (probably)

        There is a maze of twisty code going on here :/

        I think we need to go through atari/atari_init.c and work out
        what areas of memory its using and then pass those across to
        pmap_bootstrap() so the uvm_map() calls can get it right...


> >            ./build.sh -m atari kernel=FALCON
>
> Thanks for the tip, I have been using just nbconfig and nbmake-atari to
> configure and build kernel.

        Ah, excellent - that will be slightly faster than build.sh as
        it will not need to rebuild make each time :)

--
                David/absolute       -- www.NetBSD.org: No hype required --