![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Thanks Glen. I also learn new stuff at the Installfests. Most of the volunteers each have their own cache of knowledge which they very generously share. Glenn Burkhardt wrote: > As I was leaving I just happened to overhear you telling > someone that you always recommend as part of a Linux > installation that the installer enable DMA for the IDE drives > by regenerating the kernel. I was curious to see if there > might not be an easier way, since most users probably don't > want to muck around with the kernel. > > I was also curious to see if my systems were using DMA with > the IDE disks, since I've almost always found computers to be > IO bound for my applications. > > It looks like kernels can be configured to enable DMA for > hardware that supports it by setting the CONFIG_IDEDMA_AUTO > macro during configuration. Apparently, most distributions > don't turn this feature on for their stock kernels. At least, > the three I checked (Mandrake 7.2, RedHat 7.0, SuSE 7.1) > didn't have it turned on. > > I've found two different techniques that can be used to enable > DMA for the disks, with the 2.2 and 2.4 kernels, when the > kernel hasn't been configured for auto enable. > > One is to include the boot prompt argument "idex=dma", where > > * "idex=" is recognized for all "x" from "0" to "3", such as "ide1". > > This is functionally equivalent to defining CONFIG_IDEDMA_AUTO > during kernel configuration. The 'hwif->autodma' flag in the > IDE driver gets set, and queries of the drive and controller > chip set determine whether DMA is used with the drive. > > A better way is to use hdparm. It can enable DMA while the > system is running, and so can be added to a start up script, > e.g., rc.local. Then command would be something like > > hdparm -d1 /dev/hda > > Whenever DMA is enabled, it is turned off by the system if > excessive errors occur while accessing the drive. > > You can determine if DMA is currently enabled for a particular > drive by executing a command like: > > cat /proc/ide/hda/settings > > and look for the 'using_dma' line. > > The computer I have at home doesn't work in DMA mode at all. > The IDE driver kept turning DMA off. This computer is not a > newly manufactured system, but has relatively standard > components (Intel Celeron, 440LX chipset, and an Intel IDE > controller). A query of /proc/pci revealed that the IDE > controller billed itself as "Master Capable", and 'hdparm -i' > indicates that the disk drive prefers UDMA mode 4. I noticed > that I had a standard 40 conductor IDE cable installed, and > ran out to buy an 80 conductor UDMA cable. It didn't help. > when I enabled DMA, the disk chattered for a few seconds, and > went silent. The file /var/log/messages had lines in it like: > > > kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > kernel: hda: DMA disabled > kernel: ide0: reset: success > > > It looked like there were changes to the IDE driver since the > Linux version I was running was released. There were new > sections in the latest drivers that dealt with CPUs lacking > cache snooping, so I upgraded my computer to use the 2.2.15 > kernel. It still didn't work. Perhaps there are enough > machines out there that don't work with Linux's IDE driver in > DMA mode that distribution companies leave DMA disabled by > default to avoid dealing with calls from users about funny > messages in system logs. > > But newer systems at the office responded quite well. The > 'hdparm' program includes a performance test for the disk: > > hdparm -t -T > > Here are the results: > > > ============================================================== > > [root at nimue aoi]# /sbin/hdparm -t -T /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 0.69 seconds =185.51 MB/sec > Timing buffered disk reads: 64 MB in 18.94 seconds = 3.38 MB/sec > > [root at nimue aoi]# /sbin/hdparm -d1 /dev/hda > > /dev/hda: > setting using_dma to 1 (on) > using_dma = 1 (on) > > [root at nimue aoi]# /sbin/hdparm -t -T /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 0.95 seconds =134.74 MB/sec > Timing buffered disk reads: 64 MB in 3.15 seconds = 20.32 MB/sec > > ============================================================== > > [root at raijin glenn]# hdparm -t -T /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 4.86 seconds = 26.34 MB/sec > Timing buffered disk reads: 64 MB in 23.27 seconds = 2.75 MB/sec > > [root at raijin glenn]# hdparm -d1 /dev/hda > > /dev/hda: > setting using_dma to 1 (on) > using_dma = 1 (on) > > [root at raijin glenn]# hdparm -t -T /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 3.71 seconds = 34.50 MB/sec > Timing buffered disk reads: 64 MB in 6.45 seconds = 9.92 MB/sec > > ============================================================== > > But now this enlightenment is going to cost me. I'll need to > put $300 into my home system, to bring it up to snuff. > > > > -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |