VJ wrote:
Is it a SATA drive? And is your motherboard's controller a Silicon Image
one (uses "sata_sil" driver under Linux)? If so, I've seen that
problem too on some of our systems, and read about it elsewhere --
not sure where to point the finger, but it seems that
the Seagate SATA drives don't implement the protocol the way that the
Silicon Image controllers want, so you get spurious I/O errors.
(That is, they're real as seen from the Linux point of view, but don't
indicate bad spots on the disk, or failure of the drive electronics, etc.)
Haven't heard where the incompatibility lies, but "hdparm -W0" disables
write caching on the drive -- I bet that reduces performance a good deal,
so not the most desirable way to work around the problem.
Better workaround: other manufacturers' drives work fine, so you
might be able (... might have been able?) to return your Seagate
drive and get a similar one, e.g. from Western Digital. That's
what we did. I couldn't even *install* FC2 on our si-image-equipped
systems with a Seagate drive, nor with its replacement -- the installer
would detect an I/O error after copying a few tens of MB, and the
driver would lock up. But WD drives have worked flawlessly.
And dozens of Seagate drives are working well for us on other
SATA controllers.
Hi, thanks for the reply. Mine is a PATA one. I still remember digging
up some information on kernel not being able to handle large cache
(that is where I read to use -W0 to disable caching). I could not find
it now (may be I did try enough).
I cannot return my drive now as it has been in my system for a long
time. I remember kernel showing this error long time ago (a year ago)
and I started using -W0. Yesterday it just occured to me to see if
things have changed or not.
Any way, it was nice to see responses to my query.
Regards from
VJ
VJ
I looked at the hdparm output you sent off-line.
I've got the exact same drive (Seagate 200GB ST3200822A) working
correctly on a Via 8237 IDE controller. The only difference I see in our
hdparm output is the readahead value, you have 8192 and I have 256,
which shouldn't affect writes, and of course our drive serial numbers.
I suspect the culprit is your Via 686B IDE controller, or more
specifically the Linux driver for this chip. This beast is known to be
quirky and I suspect that setting -W0 changes the timing enough so that
it works. The Windows IDE drivers probably contain more fixes for the
quirks (bugs) in this chipset, so they work properly.
You might try changing the DMA mode (slow down). I suspect disabling DMA
would also fix the drive, but make it unusably slow. Maybe an IDE wizard
will see this post and add some helpful comments.
You might also ask on the Linux forum at http://forums.viaarena.com/.
There are some smart people there. Sorry I couldn't help more.
Regards,
John
