Re: hard disk I/O error fixed only by hdparm -W0 - any clues?

[Stuart Levy]

VJ <vijay.s.gill(a)gmail.com&gt; wrote:
>  > Hi,
>  >     I have a seagate hard disk with 8Mb cache. I get hard disk sector
>  > I/O errors but those are easily fixed by using hdparm -W0 on the disk.
>  > Running smart tools does not give any error. Is it because linux
>  > kernel cannot cope with this cache or what? This disk works perfectly
>  > under windoes XP though (I removed Fedora and installed XP). 
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.

hard disk I/O error fixed only by hdparm -W0 - any clues?

[Vijay Gill]

>  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

hard disk I/O error fixed only by hdparm -W0 - any clues?

[John Wendel]

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