On Apr 22,  4:34am, Brian Brennan wrote:
> In order to get my piece of crap GVP 4008-SCSI card to work under AmigaDOS,
> I spent some 2 weeks trying to tinker with it to get it to run on my
> system.  Eventually, on a whim, I set the DMA Mask to 0x17ffffff (hey I was
> desperate) and it actually started working.  Notice that the 'gtsc0' at
> 'scsibus0' did recognize my drive correctly, however it reported dmamask at
> 0xffffff rather than the actual dmamask, which I believe should be
> 0x17ffffff.  I find this odd since I used HDToolBox and set them all to
> dmamask of 0x17ffffff.  (grumble)

  Not true.  The dmamask used in NetBSD is used to specify to the driver
the physical address space the SCSI adapter can do DMA to.  The A4008 is
a Zorro II board, and can only do DMA to the first 16MB of memory.  The
Zorro II bus has no way to address any memory outside that range.  If
the NetBSD dmamask was set to 0x17ffffff, then NetBSD will try to use
DMA access to the accelerator memory.  That won't work since the 4008 is
physically incapable to doing DMA transfer to that memory.

  The DMA mask specified in the RDB partitions are used to indicated to
the AmigaDOS filesystem (and any other programs which care to check)
what valid address space the SCSI driver will accept.  This does not
have to be limited to the actual DMA address space which the SCSI
adapter can access.  The GVP driver deals properly with addresses
outside the physical DMA address space by using an internal buffer in
the driver when the external buffer is not in the address space the
controller has DMA access to it.

  Disks that use the gvpscsi.device driver should have the partition DMA
mask set to 0xfffffffe for best performance.  Otherwise, I think the
filesystem will break up any I/O transfers into 512 byte chunks and use
a Chip memory buffer for the actual driver I/O (if the driver is smart
enough, it could allocate a Zorro II fastmem buffer, which would be
preferable to a Chip memory buffer).  All my disks that I've had on my
GVP HardCArd+8 board (which I think is the same as the 4008) have always
had 0xfffffffe or 0x7ffffffe as the mask, with no problems.  [If those
disks were ever put on a DMA controller that requires the partition DMA
mask to be the actual physical DMA address space, then things wouldn't
work right.]

> If this is the problem (which I have a hunch it might be) can anyone
> tell me how to fix it?  Thanks.  Also, as a related side note, if anyone

  I don't know what your problem might be.  You could disable the DMA
transfer to verify that everything else is working.  You will need to
get the binpatch program from ftp.uni-regensburg.de and patch the
variable _sbic_no_dma to a non-zero value.  This will force PIO transfers
and eliminate any problems related to DMA.  If the problem is with DMA,
this will at least let you get NetBSD installed, although the disk
performance will not be as good.  Once you have NetBSD installed, then
you can start looking at getting the DMA working (if you feel like
digging into the kernel at that level :-)).

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA