i know this is a stupid question but that is how i m feeling after looking at kernel 2.6.
i was just surfing around when i saw this thing about not being able to turn DMA on the drive. i checked on my drives and the DMA was not on. the thing struck me that what did i miss. a bit of searching around and i found the stuff that i had to manually put in to .config.
i wrote all those thing in kernel config, started xconfig window and what do i see...
all the DMA options are under PCI IDE Chipset and before doing those manual editing all the options were hidden. setting auto DMA has an explanation that setting it 'used' to cause disk faults. is there still any such risk? i didn't know where to put it so putting it in here. what do you guys think about this DMA?
switching DMA on after a kernel re-compile has definitely given me a performance boost
Hayl
03-11-2004, 03:06 PM
leave it on. if your hardware supports it nothing bad will likely happen. i use it on all my boxes.
asklepios
03-11-2004, 03:19 PM
well it supports fine as i have been using it on Windows. just was a bit scepticle after reading all the explanation in xconfig.
thanx for the reply :)
Icarus
03-11-2004, 04:00 PM
I have a Seagate drive that I had to disable DMA on because it would give errors like this non-stop
Last time I let these errors go, the drive to a dump on the fsck and I lost all the data.
Most of the time though DMA is a very good thing with newer hardware that supports it, I don't know what the deal is with this drive of mine...but it works fine without DMA so I'm not too concerened
lagitus
03-12-2004, 06:30 PM
I got similar errors and symptoms once because the jumpers on the slave drive were set incorrectly.
post on LKML, those errors are nothing more than a failed checksum -- the checksum that the drive calculated is different from the one that the host IDE controller calculated. The usual culprits are IDE cables running too close to each other (and causing crosstalk), or flaky power.
Now, if the "dma_intr" was different in your case, then that would not necessarily be the cause. dma_intr is the interrupt handler for DMA, I think.
Of course, I'm not going to argue with you losing all your data, it's just that according to the linux-ide maintainer, these errors should not be anything to worry about. ;)
asklepios
03-13-2004, 12:29 AM
well i don't see an eror like that and it has given me a tremendous boost in performace so i don't see reasons to stop DMA.
btw mahdi have you tried enabling "use multi-mode by default" option in kernel 2.6? it specifically deals with that error you are getting.
Use multi-mode by default (IDEDISK_MULTI_MODE)
Last time I let these errors go, the drive to a dump on the fsck and I lost all the data.
Most of the time though DMA is a very good thing with newer hardware that supports it, I don't know what the deal is with this drive of mine...but it works fine without DMA so I'm not too concerened
I get these with my CDRW drive during boot with the 2.6.x kernels, but the 2.4.22 doesn't do it. Never really concerned myself with it.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD800JB-00CRA1, ATA DISK drive
hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: ASUS CD-S520/A, ATAPI CD/DVD-ROM drive
hdd: PHILIPS CDRW2010, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
SiI680: IDE controller at PCI slot 0000:02:0b.0
SiI680: chipset revision 1
SiI680: BASE CLOCK == 133
SiI680: 100% native mode on irq 11
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
hde: WDC WD800JB-00ETA0, ATA DISK drive
ide2 at 0xf9833080-0xf9833087,0xf983308a on irq 11
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
hda: hda1 hda2 hda3 hda4
hde: max request size: 64KiB
hde: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
hde: hde1 hde2 hde3 hde4
hdc: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: DMA disabled
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: status error: error=0x00
hdd: drive not ready for command
hdd: ATAPI reset complete
hdd: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache
:confused:
BeDe
03-13-2004, 05:52 AM
Originally posted by mahdi
I have a Seagate drive that I had to disable DMA on because it would give errors like this non-stop
Last time I let these errors go, the drive to a dump on the fsck and I lost all the data.
Most of the time though DMA is a very good thing with newer hardware that supports it, I don't know what the deal is with this drive of mine...but it works fine without DMA so I'm not too concerened
Also, this kind of stuff can appear because of some write
cache problem. It happened to me.
Disabling the write cache helped, without changing the DMA settings.
bwkaz
03-13-2004, 10:38 AM
Originally posted by asklepios
btw mahdi have you tried enabling "use multi-mode by default" option in kernel 2.6? it specifically deals with that error you are getting. Use multi-mode by default (IDEDISK_MULTI_MODE)
If in doubt, say N. No, those are not the same errors!
The errors that IDEDISK_MULTIMODE is supposed to help with are when the drive status byte says "I'm finished (DriveReady), and my seek is complete (SeekComplete), but there was an error (Error)" and the error byte says "there was a drive status error" (whatever that means).
NOT "I'm finished, the seek is complete, and there was an error", with the error byte saying "there was a drive status error and a bad CRC". The "bad CRC" part can't be affected by software, as the CRC is calculated on the drive and on the IDE host controller, then the two are compared. This error result is reported if they differ. The ATAPI spec apparently says that the correct course of action is for the OS to retry the read, and the IDE driver does (sometimes it backs the DMA mode off a bit before retrying too, which is why you sometimes see some message about a bus reset).
Originally posted by j79zlr
hdd: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
hdd: status error: error=0x20LastFailedSense 0x02
hdd: drive not ready for command Again, this is NOT the same error.
This one has the extra DataRequest bit set in the status byte (not sure what that means, actually). The error byte also has a different bit set (LastFailedSense, not sure what that is either).
hdd: ATAPI reset complete
hdd: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache However, it appears that the solution is the same -- reset the IDE bus (presumably at a lower DMA rate, though I can't tell for sure).
Of course, if we all used SCSI, we wouldn't have these problems... *ducks*
Icarus
03-13-2004, 01:27 PM
Originally posted by bwkaz
Of course, if we all used SCSI, we wouldn't have these problems... *ducks* We all would...IF SCSI was anywhere near the price of IDE :)
Well, I'm going to try an experiment with this drive (all the data is currently backed up so loosing it won't hurt, and it's still under warrenty for the next month...even though this might mean VOID ;))
setting fs readahead to 24
setting 32-bit IO_support flag to 3
setting multcount to 16
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
setting keep_settings to 1 (on)
HDIO_DRIVE_CMD(setxfermode) failed: Input/output error
setting drive read-lookahead to 1 (on)
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 1 (on)
readahead = 24 (on)
So, besides the drive not supporting UDMA, it looks good...let's give this a couple days of use to see what happens ;)
bwkaz
03-13-2004, 03:02 PM
Originally posted by mahdi
We all would...IF SCSI was anywhere near the price of IDE :) I only wish it was, then I'd be using it too (yeah, I'm guilty of using crappy storage too, so sue me :p).
I don't even know what half of those hdparm switches do. Good thing I've got a manpage handy. Let's see... here are the ones I didn't know for sure:
-u1, turn on unmasked IRQs. According to some posts later in that LKML thread, certain Via IDE chipsets have major issues with that, so I won't be using it (I've got a KT400 at the moment).
-A1, turn on read-lookahead. Manpage says it's on by default on most drives, but hey, whatever. ;)
-a24, set the FS driver to perform 24-block readahead. According to the manpage, it's only useful when you're reading large files, and most of the time the on-disk readahead means you don't need it. But it's not like it can hurt, either, unless you're reading large numbers of small files which are randomly placed on the drive. Default setting is 8, so you've tripled it.
-k1, keep settings over reset. The manpage says that this is only useful for -d, -m, and -u, not the others, and it only applies over a soft reset, not a power-off or a system reset. Of course, if the -d setting caused the reset to begin with, this setting can put your IDE driver in an infinite loop where it turns on DMA, DMA resets the bus, and the bus reset turns DMA back on. But whatever. The manpage also says to only use it after you're sure of the stability of your other options. But hey, if you want to use it, then go right ahead.
The ones I did know, just in case anybody cares what else you've turned on: -q means quiet, -X69 means turn on UDMA5, -d1 means turn on DMA, -m16 means read 16 sectors at a time, and -c3 means turn on 32-bit PCI-bus transfers with an extra sync sequence.
This error did not occur when I was using Mandrake or SuSE but does appear with Gentoo. Not blaming the distro but that kinda makes it sound as if it could be a kernel issue. Possibly due to hdparm settings as well (Thanks Sharth!) No idea what settings would be different between the distros though.
I have replaced the ide cable and that did not change the error.
Icarus
03-14-2004, 12:01 AM
What are your hdparm settings on hda?
hdparm /dev/hda
I haven't seen any errors since I've made that change (made it permament and reboot also)
Just to add to this, other than the error being there I see no flaw in performance.
bwkaz
03-14-2004, 11:16 PM
What IDE mode is hda running in? You can tell with hdparm -i /dev/hda
ions
03-16-2004, 12:45 AM
Well I upgraded my kernel and this has gone away - well been replaced with another error of sorts.
TSC cannot be used as a timesource. <4>Possible reasons for this are:
You're running with Speedstep,
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.
Do you have a SpeedStep processor? I.e., a laptop?
Do you have more than one processor?
Otherwise, you might have to turn on "Unsynced TSC support" in the kernel, I think.
ions
11-16-2004, 01:41 AM
Recently reinstalled Gentoo due to me being an idiot. <- Different story.
Anyway my new install is much slower than my old install was. In fact a Gnoppix disc is FAR faster than my Gentoo install.
The good news is I'm not getting the DMA errors, the bad news is my system performance BLOWS. Trying to enable DMA keeps failing. FWIW using the PC with the DMA errors above caused absolutely no problems. And for the performance sacrifice I am more than willing to put up with that error spamming my dmesg.
Here's what I gots:
Relevent bits in the kernel (afaik):
Generic PCI bus-master DMA support
Use PCI DMA by default when available
<*> VIA82CXXX chipset support
<*> Intel PIIXn chipsets support
# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10)
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10)
0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10)
0000:00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
0000:00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
0000:00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
0000:00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 08)
0000:00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
Last time I let these errors go, the drive to a dump on the fsck and I lost all the data.
Most of the time though DMA is a very good thing with newer hardware that supports it, I don't know what the deal is with this drive of mine...but it works fine without DMA so I'm not too concerened I guess I'm kinda late to this post, but this happened to me too. It was on a Sony Vaio laptop. At first they were just an annoyance, but the errors started becoming more and more frequent. Eventually my harddrive was toasted. There was no reading or writing to it. All my data was lost.
bwkaz
11-16-2004, 09:11 PM
ions -- you can turn off "Intel PIIXn chipsets support". You don't have an Intel chipset, so you don't need that.
That shouldn't be causing the operation not permitted errors, though... What does cat /proc/cmdline say?
stumbles
11-16-2004, 11:00 PM
Why do you have <*> Intel PIIXn chipsets support turned on when your lspci command does not list any Intel chipsets?
ions
11-20-2004, 07:02 PM
I had the Intel Chipset support included as it was suggested on the gentoo forums that may help. It did nothing and has been removed.
# cat /proc/cmdline
root=/dev/hda3 devfs=nomount
bwkaz
11-20-2004, 10:19 PM
OK, so you're not turning off DMA at boot time (there's an "hdX=nodma" switch that will disable DMA for hdX if it's passed to the kernel at boot). One Red Hat release used to do that (RH8 perhaps?), and it caused some issues here a couple times. But that's not it here...
Hmm... What makes it even more strange is that hdparm said that your hard drive was operating in UDMA4 mode. Which seems to me to indicate that DMA is definitely on. But it still says it's off.
I don't really know what it could be...
ions
11-22-2004, 11:30 PM
Originally posted by bwkaz
I don't really know what it could be...
Well you're not alone. Nobody else has any idea either. Someone one the Gentoo forums had the same problem and it went away when they changed their kernel. I guess that's the next thing to try really. :(
I also have a brand new hard drive I just picked up. If I don't build a whole new system I'll mv my system onto the new drive and see if that works.
Sepero
11-22-2004, 11:45 PM
If you're getting ANY kernel errors about dma. I definitely recommend disabling it. Screw performance. Your data is more valuable.
Read my above post, I had to learn the hard way.
ions
11-23-2004, 04:47 PM
My system is pretty much unusable. I can type faster than text appears now. And I'm a slow buttocks typer. Running a few apps at once is just a disaster.
Sepero
11-24-2004, 08:07 AM
You can't blame your harddrive for your system typing slow. I used one old harddrive without DMA just fine for a long time. If your system is swapping a lot, then you probably need more RAM(or a lighter window manager).
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.