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

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

On Fri, Nov 14, 2008 at 2:19 AM, David Brownlee <abs%netbsd.org@localhost> 
wrote:
> On Thu, 13 Nov 2008, T. Makinen wrote:
>> 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 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 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.

-Tuomo