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

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

On Thu, 13 Nov 2008, T. Makinen wrote:

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

        Great - I'll update the default in GENERIC.in

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

        I also seem to remember reading something about marginal DMA
        on some machines which just about worked normally but failed
        once the machine was upgraded (and various minor surgery
        which was needed to help the signals on the board). It would
        be good to determine the performance with and without REAL_DMA.
        If the advantage is small then we may be best leaving it off.
        Its its worthwhile then we could default it to off, and maybe
        have a kernel define and even a sysctl value to switch it on.

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

        I suspect that those uvm_map() calls are pretty much bogus at this
        point. If we can work out the various start and end regions of
        memory used in atari/atari_init.c then we can set new uvm_map()
        calls to mark those regions as allocated. Right now its passing
        much more than is needed to uvm_map() which ends up wasting some
        VM space - though as we have 4GB its probably not that serious.
        Fixing it will allow the DEBUG kernel to boot which may then
        allow us to start checking for real issues.

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