Greetings, all.
I'm running Debian stable, and I've been running the 2.2 kernel series
for some time now, because I've never had very good luck getting DMA to
work for my hard drive under the 2.4 series. However, with sarge's
release appearing increasingly imminent, I need to try to get this
resolved. Google has, unfortunately, completely let me down on this.
The hard drive is a Seagate ST340014A, and it's plugged into the main
IDE controller on my motherboard, a Tyan Tiger MPX S2466. According to
the manufacturer, this uses the AMD-760 MPX chipset. As far as I can
tell, I've configured my kernel correctly, but I'm still having serious
problems that occasionally result in filesystem corruption.
I've tried three different invocations of hdparm:
1) /sbin/hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda
2) /sbin/hdparm -X66 -d1 -u0 -m16 -c3 /dev/hda
3) /sbin/hdparm -X33 -d1 -u0 -m16 -c3 /dev/hda
I have used the first invocation with the 2.2 kernels for a couple of
years now with no filesystem problems. Under 2.4.26, however, it
doesn't work as well. The failure modes are somewhat complicated, but
they generally involve a message printed to the console immediately
after I run hdparm (which is one of the last things in my boot process).
In one scenario, I'll just get a warning message printed to the console:
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
Things generally seem to work well subsequently, although I can end up
with transient failures later on, some of which require rebooting, and
some of which involve filesystem corruption. Unfortunately, I haven't
had one of these in a while, so I can't describe it more fully.
In another scenario, I'll get a longer message printed to the console
during hdparm's execution:
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete
DriveRequest }
ide0: Drive 0 didn't accept speed setting. Oh, well.
At this point, the system hangs and is completely unresponsive to
keyboard input, and I have to hit the reset button. In the subsequent
fsck, I'll often find some filesystem errors that are relatively minor
but still require manual intervention to fix. (One of these left a
couple of things in /var/lost+found and clobbered /etc/motd.)
In the third scenario, I'll get this error during hdparm's execution:
EXT2-fs error (device ide0(3,2)): ext2_check_page: bad entry in
directory #452483: unaligned directory entry -- offset=0,
inode=16501003888, rec_len=59267, name_len=6
at which point the system automatically remounts / as read-only. Since
this happens before the boot procedure removes /etc/nologin, I have to
reboot, although in this case a ctrl-alt-del is sufficient. Again, this
requires an fsck on reboot, although I don't think this generally leads
to filesystem errors (other than non-zero sizes on FIFOs).
Out of the hdparm invocations given above, numbers 1 and 2 both lead to
these problems. Number 3, which I'm using currently, seems to be more
stable, although I do get console messages on startup as well:
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
hda: CHECK for good STATUS
I've only been running this for a couple of days, though, so I'm not yet
sure that it'll be stable over the long term.
Since this worked under the 2.2 series, I'm pretty sure that it's a
software configuration issue rather than a hardware problem. As I say,
I believe that I've configured things correctly, but things still aren't
working. I've attached my kernel configuration file below; note that
I've tried this both with and without CONFIG_IDEDISK_MULTI_MODE enabled,
with no observable difference.
I would greatly appreciate any suggestions that anyone might have.
Thanks much,
Richard
Attachment:
config-2.4.26rc1
Description: Binary data