Re: LX164 Eide motherboard DMA?

["Adam C. Powell, IV" <adam powell nist gov>]

Greg Johnson wrote:
> 
> >
> > I did hdparm on my Alpha 164LX EIDE hrad drives and was getting about
> > 1.5M/sec.
> >  I did on a ASUS K6 EIDE and was getting about 5.5 and using a 2940UW SCSI
> > I was getting 5.5 and 9.1 depending on the the drive.  I wuols like to
> > increase the Alpha 164LX EIDE speed, which kernel optimization/switches
> > should I compile with to get better hard disk speed(DMA on,...)?  I am
> > using kernel 2.1.127 ( I had to comment out SMP=1 in the make file)

My directions from August 18 on how to configure a CMD646-capable
kernel:

1. (from Dave Gilbert) Go in and edit drivers/block/Config.in and just
under the line about NS87415 support add (one line, unnecessary for
2.1.126 and above):

  bool '     CMD646 chipset support (EXPERIMENTAL)'
CONFIG_BLK_DEV_CMD646

2. Re-configure the kernel, making sure to:
 - Answer 'y' to "Prompt for development and/or incomplete
code/drivers", which should be the first question.
 - Answer 'y' to "Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support".
 - Answer 'y' to "Generic PCI IDE chipset support", "Generic PCI
bus-master DMA support", and "Use DMA by default when available".
 - Finally, answer 'y' to "CMD646 chipset support".

> I have seen this as well.  It WAS working around 2.1.120 or so.  There was a
> patch to a Config.in file to enable the DMA option for the CMD646.  I got more
> than 9MB/sec. with kernel 2.1.120.  Unfortunately, DMA is now broken.  Without
> the config option for CMD646 I get 1.5MB/s.  Even with the CMD646 option on I
> only get about 5.5MB/sec AND I get a fair amount of messages like:
> 
> hda: dma_intr: bad DMA status
> hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> 
> You are the first other person I've seen report this, and I haven't had time to
> look into it further.  I hope it gets fixed.  If anyone has any suggestions,
> please let me know.

I reported this on August 18 (an hour before posting the above
solution). The problem: I wasn't setting _all_ of the proper
configuration flags as above.

So you were getting faster transfers under 2.1.120 than .127?  I have
noticed no performance differences from .115 (when CMD646 first
appeared) to .125 (.126 and .127 didn't boot; haven't applied
yesterday's .127 patch by Nikita Schmidt).  I don't know how hdparm
works, but my little dd tests only work once per reboot because of
Linux's extensive caching.  I never got more than 3-4x speedup (but with
1/4 the CPU load), so I'm amazed by your 9 MB/s number for .120.

Please elaborate...

-Adam `Cold Fusion' Powell, IV http://www.ctcms.nist.gov/~powell/ ____
USDoC, National Institute of Standards & Technology (NIST)  |\ ||<  |
Center for Theoretical and Computational Materials Science  | \||_> |