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

["T. Makinen" <tjamaloo%gmail.com@localhost>]

On Wed, Nov 12, 2008 at 3:25 AM, David Brownlee <abs%netbsd.org@localhost> 
wrote:
>        Adding 'fsck_flags=-fp' to /etc/rc.conf will force a full fsck on
>        boot. (Add -P if you like a progress bar :)

Cool :) I found at that absolute minimum for ST_POOL_SIZE should be 24... So it
was quite close already :). With value of 23 it starts to print ST-mem
exhausted
messages to the screen.

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

Yes, it would be nice to use REAL_DMA for all cases. Could it be something else
that breaks REAL_DMA SCSI with CT63 ? AFAIK at least early Falcon models can
have SCSI problems and with advanced upgrades like CT63 I guess that some
Falcon problems might be amplified, so there can be some HW issues also.

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

Yes, those tests would be informative :)

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

In set_machtype() stio_addr is initially set with following comment:
"XXX: For TT & Falcon only", which sounds little bit suspicious, because as you
said it's then reset later...

I played with two situations: first I short circuited stio_addr reset at
map_io_areas(), but then something else breaks; first uvm_map() call still
fails. If I set addr value to 0xff8000 at pmap_init() before first uvm_map()
call, then first call passes, but second one fails...

-Tuomo