Recently, when trying to use UDMA/66 on my SiS 530 and
WD84AA, I got some data corruption. At first, I tried
with "UDMA Enabled" set to off in the BIOS, because I
had known this to previously cause problems. However,
like this, I couldn't set the harddrive to use UDMA
mode4 (-X68). I would set it, it would appear
successful, check with hdparm -i, and it would still
say mode2. Additionally, there was no speed increase
after the -X68.
Before, on a 40-conductor cable, I was getting 11MB/s
with hdparm -t . I bought an 80-conductor cable
today, and saw no speed improvement in mode2, which is
the only mode I can set it to. Something that striked
me as odd about the cable, though, is that the red
wire was broken between the Drive 1 socket and the
Drive 0 socket. Is this to differentiate the two?
Anyway, what's interesting is what happens after I
turned "UDMA Enabled" on in the BIOS. Upon booting,
everything appeared normal until just before X
started. At this point, I got a
dma_intr: hda: status=0x58 { DriveReady SeekComplete
Error}
error=0x0 { }
I'm not sure about the numbers, but I am sure about
the texts. The drive said there was an error, but no
error was set. After fooling around with hdparm
(setting the drive to -X68, timing it, etc) I got a
few more identical errors. Then, I started getting
errors from EXT3-fs regarding invalid/corrupt data.
This concerned me, so I tried a "shutdown -r now", but
to no avail. I instead did a SysRq
Sync-Unmount-reBoot. Upon rebooting, I could no
longer mount my root fs due to "Invalid track type or
session number," or something to that effect. I tried
using e2fsck, but I can't find a valid superblock on
the root partition. Other partitions on the drive
remain intact, however.
If anyone can shed any light on this problem, it would
be much appreciated. I wonder whether this is a linux
bug, or a hardware problem, and if a hardware problem, where?
=====
-Steven
====================================================
"The most foolish mistake we could possibly make would be to allow the subject races to possess arms. History shows that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so."
Adolph Hitler
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/
On Mon, 30 Oct 2000, Steven Walter wrote:
>
> Recently, when trying to use UDMA/66 on my SiS 530 and
> WD84AA, I got some data corruption. At first, I tried
> with "UDMA Enabled" set to off in the BIOS, because I
> had known this to previously cause problems. However,
> like this, I couldn't set the harddrive to use UDMA
> mode4 (-X68). I would set it, it would appear
> successful, check with hdparm -i, and it would still
> say mode2. Additionally, there was no speed increase
> after the -X68.
Check your logs and see if their is a speed setting block issued, only if
you are using patched 2.2x or 2.4.0x kernels will this report be
generated.
> Before, on a 40-conductor cable, I was getting 11MB/s
> with hdparm -t . I bought an 80-conductor cable
> today, and saw no speed improvement in mode2, which is
This clear indicates a problem in the device pairing or you have not
enable the entire driver.
> the only mode I can set it to. Something that striked
> me as odd about the cable, though, is that the red
> wire was broken between the Drive 1 socket and the
> Drive 0 socket. Is this to differentiate the two?
Explain...
> Anyway, what's interesting is what happens after I
> turned "UDMA Enabled" on in the BIOS. Upon booting,
> everything appeared normal until just before X
> started. At this point, I got a
>
> dma_intr: hda: status=0x58 { DriveReady SeekComplete
> Error}
> error=0x0 { }
>
> I'm not sure about the numbers, but I am sure about
> the texts. The drive said there was an error, but no
> error was set. After fooling around with hdparm
> (setting the drive to -X68, timing it, etc) I got a
> few more identical errors. Then, I started getting
> errors from EXT3-fs regarding invalid/corrupt data.
If you are using "EXT3-fs" journalling and your write cache is not
disable, you are TOAST! I just now got the drive venders to auto-update
the contents of the identify page that reports the features set and
masked.
Regards,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
> Check your logs and see if their is a speed setting
> block issued, only if
> you are using patched 2.2x or 2.4.0x kernels will
> this report be
> generated.
I haven't been able to recover anything from the root
fs as of yet. If I do; I will check the logs.
> > Before, on a 40-conductor cable, I was getting
> 11MB/s
> > with hdparm -t . I bought an 80-conductor cable
> > today, and saw no speed improvement in mode2,
> which is
>
> This clear indicates a problem in the device pairing
> or you have not
> enable the entire driver.
IOW, that the drive will not work above a certain
speed with the SiS530 IDE chipset? If it makes any
difference, there is also a UDMA/33 CD-ROM drive on
the same bus, set as slave.
> > the only mode I can set it to. Something that
> striked
> > me as odd about the cable, though, is that the red
> > wire was broken between the Drive 1 socket and the
> > Drive 0 socket. Is this to differentiate the two?
>
> Explain...
Well, I noted that one socket is only for drive 0, and
one socket it only for drive 1. My thoughts were that
the broken wire between the two sockets were akin to
the twist in a floppy cable, i.e., to designate one as
drive 0 and one as drive 1.
It apparently doesn't impair normal operation, as I
can run windows 95 on the machine without problem.
> If you are using "EXT3-fs" journalling and your
> write cache is not
> disable, you are TOAST! I just now got the drive
> venders to auto-update
> the contents of the identify page that reports the
> features set and
> masked.
That doesn't sound encouraging... yes, I was using
EXT3 journalling on the root partition. As for
whether write cache is disabled, I do not know. I
haven't done anything to explicitly disable it. But,
as I noted, I sync/unmounted the disks before
rebooting.
> Regards,
>
> Andre Hedrick
> CTO Timpanogas Research Group
> EVP Linux Development, TRG
> Linux ATA Development
>
One other thing I remember is that the HD is now
recognized as being UDMA/33, whereas before it was
recognized as UDMA/66. AFAIK, this happened
immediately after swapping cables. My kernel is
2.2.17+ide. Thanks for your help so far
=====
-Steven
====================================================
"The most foolish mistake we could possibly make would be to allow the subject races to possess arms. History shows that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so."
Adolph Hitler
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/