Booting YDL 2.1 on B&W G3 Problems

[Timothy A. Seufert]

At 12:33 AM -0400 6/30/02, Bill Fink wrote:

>>  The reason you aren't having problems when you eliminate the CMD64X
>>  driver is presumably that the generic IDE driver can't enable UDMA
>>  mode.  It might not even be able to enable DMA.
>
>Actually, being somewhat paranoid after all the severe problems I had
>run into, I finally removed the original internal drive to avoid any
>further problems.  I do have the CMD64X driver disabled in the current
>kernel:
>
>astro% dmesg | grep CMD
>CMD646: IDE controller on PCI bus 01 dev 08
>CMD646: detected chipset, but driver not compiled in!
>CMD646: chipset revision 5
>CMD646: 100% native mode on irq 26
>
>Is using_dma as reported by hdparm the same thing as the UDMA mode
>you were talking about?  If so, it still seems to be set on the new
>drive:

Not necesssarily.  It might be using the slower 16.6 MB/s DMA mode 
(multiword DMA mode 2) instead of 33.3 MB/s UDMA.  If I recall 
correctly, corruption only happens in UDMA mode.

>According to your theory, it would seem all that would be necessary to
>workaround the problem would be to issue an "hdparm -d 0" on the drive(s).
>If I get some spare time, I may test that theory, but as much time as I've
>already wasted on that system, it's not real high on my priority list,
>especially since it seems to be working pretty well finally.

Yes, that should do it.  No guarantees, but I don't remember ever 
seeing a problem with DMA off.  Not using UltraDMA mode should also 
do the trick.  Use:

hdparm -X34 /dev/hdX

to select multiword DMA mode 2.  -X66 selects UDMA mode 2.

Also, back when I was trying to get my B&W working right, I wrote a 
simple program that tests for disk I/O corruption by writing large 
files to disk and then reading them back and verifying them.  Better 
than writing real data to disk and having to find out later that it 
got corrupted.  :)  If you want it, let me know and I'll send you the 
C source code.
-- 
Tim Seufert