Re: [ale] Just an FYI for those using UDMA hard drives and RH 7.2

[Michael Smith]

I don't know for sure if it needs to be sent to that list or not.  I should 
probably monitor the list to see if it's a common problem.  I did leave out 
one major thing......  I am also using raid0 on the 2 drives.  This 
probably complicates things even more....

I haven't tried using other drives since all I buy are Maxtors and IBM(this 
drive is on my wifes pc and I don't want to mess with it).  I had several 
Western Digitals crash on me in the past so I don't buy them.  I could 
definitely repeat the steps to make it happen, though....

> Is this something for the kernel development list?  Having to take a 
> permanent performance hit doesn't strike me as a good solution.  Does
> it  seem as though Maxtors are the only affected drives?
> 
> - Jeff
> 
> James P. Kinney III wrote:
> 
>> What an arcane problem! Congratulations on getting it resolved. That
>> took some legwork. 
>> 
>> I can see the reasons for having the option to turn off WV. I take it
>> it was not documented with the drive. It seems a bit underhanded if
>> the WV is turned off for benchmarking but will fail under normal
>> conditions with out it.
>> 
>> So, clearly, RedHat 7.2, and presumably Linux in general, will have a
>> hard time with this drive unless WV is always on. Is a write verify
>> CRC check manadatory at all times? Is there an option in /proc/ide
>> that will allow the WV to be turned off from the Linux OS for speed
>> trials? Does this drive come with an installation disk for M$?
>> 
>> I don't use any Maxtor drives so my proc shows no WV parameters. I
>> went digging in "man hdparm" and found a -W flag that is used to
>> toggle the write caching. No reference to write verify. 
>> 
>> On Tue, 2002-01-15 at 12:08, Michael Smith wrote:
>> 
>>>I have been fighting for the last 2 weeks trying to get my 7.2 machine
>>>up  for more than 12 hours at a time without a kernel panic and I
>>>think I  finally got it working...
>>>
>>>I determined that it was a UDMA issue after receiving
>>>{DriveStatusError  BadCRC} errors in the messages log file.  So I
>>>bought 2 new 80 pin, less  than 18 inch, ide cables after reading this
>>>blurb at 
>>>http://www.kernel.org/pub/linux/docs/lkml/#s13-3 .  I still received
>>>the  errors.  So I then moved the hard drives to the bottom and top
>>>bays to  hopefully reduce any crosstalk.  Still didn't work.  I then
>>>moved the power  cables as far away from the ide cables as possible. 
>>>Still didn't work.
>>>
>>>So now I am thinking that either my controller or my hard drives are
>>>bad.   I go to the Maxtor site and download Powermax to test the
>>>drives.  I  perform exhaustive checks with both drives coming out
>>>without any errors. I  am now at a loss.  
>>>
>>>So I dig a little more on the Maxtor site about the write verify 
>>>functionality on the hard drive and find out, that for speed, the
>>>write  verify is turned off after 10 power cycles on the hard drive. 
>>>So I  downloaded this utility called WVSet from their site and turned
>>>the write  verify back on permanently and now my machine has been up
>>>for 24 hours w/o  a kernel panic....
>>>
>>>Here's Maxtor's blurb on Write Verify:
>>>
>>>"Write Verify" performs a Read of the data just written to the hard
>>>drive  and validates the data via the Cyclic Redundancy Check (CRC),
>>>providing  additional assurance that the data written to the hard
>>>drive was written  correctly. When Write Verify is enabled, the WRITE
>>>performance of the drive  is affected as a read occurs for each write.
>>>When disabled WRITE  performance is improved as, a read is not
>>>performed for each write When performing benchmark operations the
>>>"write verify" feature should be  disabled to insure valid comparisons
>>>to other products that do not offer  this capability in their product.
>>>
>>>
>>>Just an FYI......
>>>
>>>-- 
>>>Michael Smith
>>>
>>>
>>>
>>>---
>>>This message has been sent through the ALE general discussion list.
>>>See http://www.ale.org/mailing-lists.shtml for more info. Problems
>>>should be  sent to listmaster at ale dot org.


-- 
Michael Smith
msmith at mikeandmel.com


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.