hda error waiting for DMA
Alden Pierre
I'm currently running slackware 10.2 I noticed the following from dmesg.
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, UDMA(100)
Partition check:
hda:<4>hda: dma_timer_expiry: dma status == 0x21
hda: error waiting for DMA
hda: dma timeout retry: status=0x58 { DriveReady SeekComplete DataRequest }
hda1 hda2 <<4>hda: dma_timer_expiry: dma status == 0x21
hda: error waiting for DMA
hda: dma timeout retry: status=0x58 { DriveReady SeekComplete DataRequest }
hda5<4>hda: dma_timer_expiry: dma status == 0x21
hda: error waiting for DMA
hda: dma timeout retry: status=0x58 { DriveReady SeekComplete DataRequest }
hda6<4>hda: dma_timer_expiry: dma status == 0x21
hda: error waiting for DMA
hda: dma timeout retry: status=0x58 { DriveReady SeekComplete DataRequest }
hda7 hda8 hda9 >
Is there anything I can do to get the error to go away?
Regards,
Alden
Sylvain Robitaille
> hda6<4>hda: dma_timer_expiry: dma status == 0x21
> hda: error waiting for DMA
> hda: dma timeout retry: status=0x58 { DriveReady SeekComplete DataRequest }
> ...
> Is there anything I can do to get the error to go away?
I would try setting different DMA modes with hdparm. If that doesn't
work, you may need to look at disabling DMA for the disk.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Grant
>Alden Pierre wrote:
>
>> hda6<4>hda: dma_timer_expiry: dma status == 0x21
...
>I would try setting different DMA modes with hdparm. If that doesn't
>work, you may need to look at disabling DMA for the disk.
Disagree, IDE DMA errors generally pointy to wrong chip driver,
particularly with distro kernel. This is why I compile custom
kernels for linux boxen since a long time. Playing with DMA on
drive with mounted FS may lead to dataloss.
OP should report dmesg filtered for drive, then lspci -v for
chipset, and hdparm -i /dev/hda to see what is there, often hdd
dma is on, but wrong driver is place.
Grant.
--
Memento mori ( remember that you must die... )
Sylvain Robitaille
>> I would try setting different DMA modes with hdparm. ...
>
> Disagree, IDE DMA errors generally pointy to wrong chip driver,
> particularly with distro kernel. ...
Ok. I've never experienced this problem first-hand, and that (trying
different DMA settings) is certainly where I would have started looking.
Your response might save me some time and aggravation should I ever
encounter this problem.
> Playing with DMA on drive with mounted FS may lead to dataloss.
Perhaps, though I've done it (cycled through all available settings to
see if there was one that worked best; there was: the one that the
system had picked by itself in the first place, so I've not done this
with every combination of hardware that I own) without any data loss
whatsoever.
Grant
>Grant wrote:
...
>> Playing with DMA on drive with mounted FS may lead to dataloss.
>
>Perhaps, though I've done it (cycled through all available settings to
>see if there was one that worked best; there was: the one that the
>system had picked by itself in the first place, so I've not done this
>with every combination of hardware that I own) without any data loss
>whatsoever.
Well I lost data playing with hdparm (once) a very long time ago, the
man page warns me that happens, for some settings.
Besides, I cannot remember solving this type of problem with hdparm,
the solution for me has been to compile the correct drivers into the
kernel.
Other point is using a new drive in older box, one needs to use the
manufacturer's utility to limit the drive's max DMA setting, otherwise
the linux driver may drop DMA altogether rather than go to slower
DMA. That's the other part of story I forgot to add to last reply.
Applies to new HDD on 40-ribbon. (Seagate: uata100.exe from ms-dos
boot floppy)
Alden Pierre
Is there a way to have the following statement executed while booting?
hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda
Regards,
Alden
Roger Manyard
> Is there a way to have the following statement executed while booting?
> hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda
Put the statement in /etc/rc.d/rc.local. This will be one of the
last things executed during boot.
cordially, as always,
rm
Alden Pierre
By that time it would be a little too late, I was thinking about placing
it right underneath the path statement in /etc/rc.d/rc.S.
Regards,
Alden
Loki Harfagr
I'm not certain that you'd like to have your fscks ran with
HD optimizations on...
May be safer to pass to lilo (.conf or at boot prompt)
append="ide=nodma"
for the boot and when all is calm and stable, experiment if
your hdparm settings introduce an error.
If all goes well, put your hdparm setup in rc.local as Ronald proposed.
Anyway, maybe it's not what you'd hope but that's the way I set up
most machines I have to keep safe, including my own.
+Alan Hicks+
Hash: SHA1
In alt.os.linux.slackware, Alden Pierre dared to utter,
> Is there a way to have the following statement executed while booting?
>
> hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda
http://slackbook.org/html/system-configuration.html#SYSTEM-CONFIGURATION-RCD
This page describes most of the rc scripts that are run when Slackware
boots. The one that is most likely what you want is rc.local. It
exists as a handy place to put just this sort of stuff.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
iD8DBQFENVF5z8zcalmVmBkRAv6FAJ9yJZKi5nXa5smVeANYrm2/T0Nf2QCfXyOE
bCcslyxtM24xswlapL8Ft7g=
=Siqe
-----END PGP SIGNATURE-----
Alden Pierre
lilo.conf. The hda error waiting for dma, made me a little nervous. I
thought I could just fool the system by placing the dma option in
/etc/rc.d/rc.S :-) . Considering by the time the hda error waiting for
dma is occuring, the file systems has already been mounted. Which is
why I avoided placing it in /etc/rc.d/rc.local. I'll place it under
/etc/rc.d/local as Ronald proposed and turn the option off via
/etc/lilo.conf. Thanks again.
Regards,
Alden
Sumo Wrestler (or just ate too much)
> [...] safer to pass to lilo (.conf or at boot prompt)
> append="ide=nodma"
> [...]
Thanks Loki. This advice helped me too.