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

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

On Fri, 14 Nov 2008, T. Makinen wrote:

> I made SDMA patch and replaced one 0 ohm resistor for my second Falcon to make
> it possible to run stable with CT63. Patches are mentioned under Some problems
> to solve (with some solders) :
> http://www.czuba-tech.com/CT60/english/fitting63.htm
>
> REAL_DMA undefined seems to cure most issues with CT63, but kernel still
> sometimes freeze just after kernel finds ffs file system (I also tried this
> couple of times with my second Falcon, which tend to freeze under MiNT/TOS if
> SCSI is used in 640x480 256c graphics mode, and it failed).

        I think the best option would be to change REAL_DMA from
        a compiletime to a runtime test and default it on for TT
        and off for Falcon. Do you want to take a pass at that? :)

        If there are specific patterns which are more likely to
        cause a failure then one option would be to have some code
        at bootup which would switch to a high bandwidth video mode
        and then run some DMA scsi tests to try to provoke a failure.
        If it fails then it disables DMA and continues booting. Of
        course for that to work it must be easy to induce the
        failure (so we don't get any false "it works not but fails
        later"), and we need to be able to recover from the failure
        (hopefully just reset the SCSI controller). I don't really
        think that would be worth the effort tho...

> >        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.
>
> Amiga port pmap.c is quite similar to atari version and amiga/pmap.c has
> dropped two first uvm_map() calls since revision 1.123 (they had also some
> problems with DEBUG kernels). I removed them from atari/pmap.c to make quick
> test and at least now I'm able to boot with DEBUG kernel :) If we can get rid
> of those uvm_map() calls we do not need anymore to pass ptextra to
> pmap_bootstrap() and use atarihwpg in atari/pmap.c.

        Sounds like a plan. Do you want to cleanup the code and params
        and maybe build a kernel for DavidR to test as well?

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