Re: scsi freezing problem with NetBSD current

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

On Tue, 28 Oct 2008, David Ross wrote:

> My understanding was that a lot of DMA on the TT030 is to ST-ram, but the 
> SCSI DMA specifically does use TT-ram.  Doing some quick digging, I found:
> http://www.vanc.igs.net/~roughley/overview.htm#SCSI
>
> Which says:
>
> "The TT's SCSI direct-memory-access subsystem can send and receive 
> information equally well, both from ST RAM and faster TT RAM, meaning that 
> present and future software will be able to exploit SCSI peripherals 
> efficiently."
>
> There's a great archive of TT030 hardware info that may be useful as well:
> http://dev-docs.atariforge.org/html/search.php?find=_4

        There is a comment in sys/arch/atari/dev/atari5380.c:

        /*
         * LWP: DMA transfers to TT-ram causes data to be garbled
         * without notice on some TT-mainboard revisions.
         * If programs generate mysterious Segmentations faults,
         * try enabling NO_TTRAM_DMA.
         */

        So, NetBSD is not currently using SCSI DMA to TT-ram.

        I wonder if there is a way to query the mainboard revision so
        NetBSD could selectively disable the DMA to TT-ram. David,
        did you see any notes on DMA to TT-ram issues on earlier TT030s
        in your searches? Does anyone else know?

> As far as the DEBUG kernel below goes...  On first boot I got a panic after 
> the boot message telling me the filesystem is clean.  "Mutex error: 
> mutex_vector_enter: locking against myself"  Then it had a few lines of debug 
> spew and "panic: lock error"
        Thats not a good sign :/

> So I rebooted (still with the same kernel) and now it's busy chugging away 
> validating the filesystem.  Not sure if it will make it past that or not. 
> I've got to head off to sleep now so I'll report back with more info 
> tomorrow.

        Thanks

> I've been fixated on 1.6.1 for the last few months but now that the kernel 
> bug is fixed I want to check out 4.0 again.  David, if you can clarify what 
> some of the "manual fixups" are that you mention are, that would be very 
> helpful.  The next roadblock I'm aware of is the inability to get the more 
> recent installers to drop a working bootstrap on the drive (or even upgrade 
> an install that already has one).
>
> And I second your call for some heroic developer to work on fixing up the 
> installer.  =)

        Well, I think a good first step would be to get a PR opened with
        full details :)

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