Port-atari archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

On Tue, Nov 11, 2008 at 1:42 AM, David Brownlee <abs%netbsd.org@localhost> 
       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

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

       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:

        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*

Here's also dmesg with debug printf() calls from FALCON kernel without DEBUG

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

Home | Main Index | Thread Index | Old Index