>On Oct 25,  2:48pm, Tim Walls wrote:
>  I think earlier versions of the A2091 driver did have some problems with
>DMA transfers, but those should have been fixed in the latest kernels.

Well...

>> DMA into the 4MB RAM block that LoadBSD uses by default, cos thats off the
>> motherboard) - if so, this could well be the cause of my slightly
>> bizarre disk problems....  (Although I must admit I can't see how it would
>> even recognise the disks, let alone mkfs them, if this was the case...).
>  The initial disk configuration is all done with PIO transfers, so no
>DMA I/O is being done at that point.  If the kernel were trying to do DMA
>using non-DMA memory, you shouldn't even be able to mount the disk, since
>the superblock (NetBSD partitions) or root block (ADOS partitions) wouldn't
>be readable.

You'dve thought so...

>>    a) Tell me if there is a label I could binpatch to make sure the kernel
>>       knows it can't DMA into this space,
>  You can binpatch _sbic_no_dma to a non-zero value to force the driver
>to use programmed I/O transfers.

It worked!!!!!  thankyouthankyouthankyou!  That it was ever possible to
mount, and intermittently read the right data, the partitions is one of
the great mysteries of mankind, but setting it to use PIO only, it worked
perfectly - a flawless installation!

>Michael
I suspect NetBSD's probs. were a result of a buggy A2091 ROM, but it might
be worth mentioning that bizarre errors could be a result of DMA problems,
and the fix, in the FAQ...  (Although I assume its not that frequent, it
_is_ bloody puzzling :*)


>Michael L. Hitch			INTERNET:  osymh@montana.edu

Thanks again!

-- 
 __ //||/  Tim Walls/TJay            EMail                 tjw1@doc.ic.ac.uk
 /_//=|/  Skating away...           PGP2.3 Key, finger  tjw1@sg1.cc.ic.ac.uk
----------------------------------------------------------------------------
  `And with the last line almost drawn, wish you goodbye 'till further on'