Bad disk controller? Dying HDD? - Hardware

This is a discussion on Bad disk controller? Dying HDD? - Hardware ; On 8/13/2008 1:22 PM PT, Ant typed: >>>> I've never heard of Fortron but that doesn't mean that they aren't any good. >>>> What I have seen before is IDE devices on the same cable interfering with each >>>> other ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 55 of 55

Thread: Bad disk controller? Dying HDD?

  1. Re: Bad disk controller? Dying HDD?

    On 8/13/2008 1:22 PM PT, Ant typed:

    >>>> I've never heard of Fortron but that doesn't mean that they aren't any good.
    >>>> What I have seen before is IDE devices on the same cable interfering with each
    >>>> other when one of them is going south. You could try removing the 2nd device
    >>>> from the primary cable and attaching it to another one (if there is one) and see
    >>>> if that eliminates the errors on one or both of the drives.
    >>> Is unmounting hdb via umount command valid?

    >
    >> Not really, you need to get the drive off the cable to tell which means opening
    >> things up and performing surgery.

    >
    > OK when I get a chance (at work right now).


    OK, I am going to have to physically disconnect that drive since I was
    using the hda intensively (didn't even touch my unmounted hdb):

    Aug 14 07:03:45 ANTian kernel: hdb: dma_timer_expiry: dma status == 0x61
    Aug 14 07:03:55 ANTian kernel: hdb: DMA timeout error
    Aug 14 07:03:55 ANTian kernel: hdb: dma timeout error: status=0x58 {
    DriveReady SeekComplete DataRequest }
    Aug 14 07:03:55 ANTian kernel: ide: failed opcode was: unknown
    Aug 14 07:03:55 ANTian kernel: hda: DMA disabled
    Aug 14 07:03:55 ANTian kernel: hdb: DMA disabled
    Aug 14 07:03:55 ANTian kernel: ide0: reset: success
    --
    "When the ant grows wings it is about to die." --Arabic
    /\___/\
    / /\ /\ \ Phil/Ant @ http://antfarm.home.dhs.org (Personal Web Site)
    | |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
    \ _ / Remove ANT from e-mail address: philpi@earthlink.netANT
    ( ) or ANTant@zimage.com
    Ant is currently not listening to any songs on his home computer.

  2. Re: Bad disk controller? Dying HDD?

    On 8/14/2008 3:35 AM PT, david typed:

    >>>> Darn it, this Fortron FSP650-80GLC PSU (650 watts) isn't not that old
    >>>> either. Grr.
    >>> I've never heard of Fortron but that doesn't mean that they aren't any
    >>> good. What I have seen before is IDE devices on the same cable
    >>> interfering with each other when one of them is going south. You could
    >>> try removing the 2nd device from the primary cable and attaching it to
    >>> another one (if there is one) and see if that eliminates the errors on
    >>> one or both of the drives.

    >> Is unmounting hdb via umount command valid?

    >
    > umount doesn't normally power down the drive, it only unmounts the file
    > system.


    Ah. So, there is no way to tell PC to not to touch the drive without
    physically disconnecting the drive cables.

    Thanks.
    --
    "Stir up an ant's nest." --unknown
    /\___/\
    / /\ /\ \ Phil/Ant @ http://antfarm.home.dhs.org (Personal Web Site)
    | |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
    \ _ / Remove ANT from e-mail address: philpi@earthlink.netANT
    ( ) or ANTant@zimage.com
    Ant is currently not listening to any songs on his home computer.

  3. Re: Bad disk controller? Dying HDD?

    Arno Wagner wrote in news:6gihk1FfueosU1@mid.individual.net
    > In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > > On 14 Aug 2008 00:36:19 GMT, Arno Wagner put finger
    > > to keyboard and composed:

    >
    > > > > High raw "seek error rate" and "read error rate" figures for Seagate
    > > > > drives appear to be normal. By my reckoning, the "seek error rate"
    > > > > parameter appears to be a seek count, not an error, and not a rate.
    > > >
    > > > Agreed for the raw value. I am actually concerned about the cooked
    > > > values. They are a bit low, which may aor may not indicate a problem.
    > > > If removing hdb (SectorIdNotFound is a killer...) solves the
    > > > issue, I would say that hda is likely fine but should be watched.
    > > >
    > > >
    > > > Arno

    >
    > > Sorry, I should have looked more closely. It would appear then that
    > > the raw value and the normalised values are not directly related. The
    > > former is monotonically increasing according to my testing, but
    > > clearly the normalised values show a worst case figure which is less
    > > than the current value. I wish Seagate would come clean and release
    > > their SMART documentation, if only to dispel people's concerns over
    > > the large raw "error" numbers.

    >
    > And agreed again.


    > At least there is a cooked value that has
    > a somewhat constant and known semantics.


    Totally cuckoo.

    >
    > Arno


  4. Re: Bad disk controller? Dying HDD?

    Arno Wagner wrote in news:6ghd03Fg2th9U2@mid.individual.net
    > In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > > On 13 Aug 2008 09:34:21 GMT, Arno Wagner put finger
    > > to keyboard and composed:

    >
    > > > In comp.sys.ibm.pc.hardware.storage Ant wrote:
    > > > > Hi. My old mini-tower PC's HDDs are acting crazy today. I came home and
    > > > > noticed my second drive wasn't there so I checked dmesg (deleted normal
    > > > > logs before hdb):
    > > >
    > > > From the SMART status, the Seagate (first drive) has read and
    > > > seek errors, that could well be connected. The Quantum looks fine
    > > > in SMART, but it is older (i.e. less reliable SMART implementation)
    > > > and has nasty SectorIDNotFound errors in the log.
    > > >
    > > > So, what is going on indeed. I think either hdb is dying
    > > > and messing with the bus as it does so, or you have a different
    > > > problem. Attributes 1 and 7 on hda do not look good either.
    > > > The errors in the log for hda could indeed be a controller
    > > > issue, but nether could the errors for hdb or the SMART
    > > > attributes 1 and 7 for hda. I would suspect that your PSU is
    > > > going south and that unlean power is causing the problem.
    > > >
    > > > Arno

    >
    > > High raw "seek error rate" and "read error rate" figures for Seagate
    > > drives appear to be normal. By my reckoning, the "seek error rate"
    > > parameter appears to be a seek count, not an error, and not a rate.


    > Agreed for the raw value. I am actually concerned about the cooked values.


    It's your brain that is cooked, Babblebot, they are called 'normalized values'.

    > They are a bit low, which may aor may not indicate a problem.


    > If removing hdb (SectorIdNotFound is a killer...)


    "SectorIdNotFound" is an internal physical (platter) error, no-
    thing whatsoever to do with a (possibly) misbehaving interface.

    > solves the issue, I would say that hda is likely fine but should be watched.
    >
    >
    > Arno


  5. Re: Bad disk controller? Dying HDD?

    In comp.sys.ibm.pc.hardware.storage Ant wrote:
    >
    > # smartctl -l error /dev/hdb
    > smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce
    > Allen
    > Home page is http://smartmontools.sourceforge.net/
    >
    > === START OF READ SMART DATA SECTION ===
    > Warning: device does not support Error Logging


    Your disk doesn't support logging.

    > SMART Error Log Version: 0
    > No Errors Logged
    >
    > # smartctl -l selftest /dev/hdb
    > smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce
    > Allen
    > Home page is http://smartmontools.sourceforge.net/
    >
    > === START OF READ SMART DATA SECTION ===
    > Warning: device does not support Self Test Logging


    Your disk doesn't support logging.

    > SMART Self-test log structure revision number 0
    > Warning: ATA Specification requires self-test log structure revision
    > number = 1
    > No self-tests have been logged. [To run self-tests, use: smartctl -t]
    >
    >
    > # smartctl -l selftest /dev/hda
    > smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce
    > Allen
    > Home page is http://smartmontools.sourceforge.net/
    >
    > === START OF READ SMART DATA SECTION ===
    > SMART Self-test log structure revision number 1
    > Num Test_Description Status Remaining
    > LifeTime(hours) LBA_of_first_error
    > # 1 Extended offline Completed without error 00% 18951
    > -
    > # 2 Extended offline Completed without error 00% 18674
    > -
    > # 3 Extended offline Completed without error 00% 15957
    > -
    > # 4 Extended offline Completed without error 00% 14448
    > -


    IIRC if there were any errors, they would be logged. You'd get an
    error count, and perhaps some additional information. If, of course,
    hdb supported logging.

    Jerry

  6. Re: Bad disk controller? Dying HDD?

    Franc Zabkar wrote in news:1nl7a4l1qg1i6fbt1t23kiiksui0p54opk@4ax.com
    > On 14 Aug 2008 00:36:19 GMT, Arno Wagner put finger
    > to keyboard and composed:
    >
    > > > High raw "seek error rate" and "read error rate" figures for Seagate
    > > > drives appear to be normal. By my reckoning, the "seek error rate"
    > > > parameter appears to be a seek count, not an error, and not a rate.

    > >
    > > Agreed for the raw value. I am actually concerned about the cooked
    > > values. They are a bit low, which may aor may not indicate a problem.
    > > If removing hdb (SectorIdNotFound is a killer...) solves the
    > > issue, I would say that hda is likely fine but should be watched.
    > >
    > >
    > > Arno


    > Sorry, I should have looked more closely.


    What you should do is to not take that Babblebot seriously.
    Yes, you should have looked more closely and know he doesn't have a
    point there either. Those normalized values too are kind of normal.

    > It would appear then that the raw value and
    > the normalised values are not directly related.


    Nope, they are related.

    > The former is monotonically increasing according to my testing, but
    > clearly the normalised values show a worst case figure which is less
    > than the current value.


    No! Really?
    Maybe there is something to be said for a worst value after-all then.
    Else the 'current' and 'worst' would be the same all the time, no?

    > I wish Seagate would come clean and release their SMART documentation,
    > if only to dispel people's concerns over the large raw "error" numbers.


    Why would they want to do that when the SMART attributes system is to be abandoned anyway.

    >
    > - Franc Zabkar


  7. Re: Bad disk controller? Dying HDD?

    Ant wrote:
    > On 8/13/2008 1:22 PM PT, Ant typed:
    >
    >>>>> I've never heard of Fortron but that doesn't mean that they aren't
    >>>>> any good. What I have seen before is IDE devices on the same cable
    >>>>> interfering with each other when one of them is going south. You
    >>>>> could try removing the 2nd device from the primary cable and
    >>>>> attaching it to another one (if there is one) and see
    >>>>> if that eliminates the errors on one or both of the drives.
    >>>> Is unmounting hdb via umount command valid?

    >>
    >>> Not really, you need to get the drive off the cable to tell which
    >>> means opening things up and performing surgery.

    >>
    >> OK when I get a chance (at work right now).

    >
    > OK, I am going to have to physically disconnect that drive since I was
    > using the hda intensively (didn't even touch my unmounted hdb):
    >
    > Aug 14 07:03:45 ANTian kernel: hdb: dma_timer_expiry: dma status == 0x61
    > Aug 14 07:03:55 ANTian kernel: hdb: DMA timeout error
    > Aug 14 07:03:55 ANTian kernel: hdb: dma timeout error: status=0x58 {
    > DriveReady SeekComplete DataRequest }
    > Aug 14 07:03:55 ANTian kernel: ide: failed opcode was: unknown
    > Aug 14 07:03:55 ANTian kernel: hda: DMA disabled
    > Aug 14 07:03:55 ANTian kernel: hdb: DMA disabled
    > Aug 14 07:03:55 ANTian kernel: ide0: reset: success


    Check your power supply. I had one where the 5V had dropped to 4.5V and
    the HDDs were doing funny things like that and the pc was slow to boot.

  8. Re: Bad disk controller? Dying HDD?

    On 14 Aug 2008 11:01:21 GMT, Arno Wagner put finger
    to keyboard and composed:

    >In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    >> On 14 Aug 2008 00:36:19 GMT, Arno Wagner put finger
    >> to keyboard and composed:

    >
    >>>> High raw "seek error rate" and "read error rate" figures for Seagate
    >>>> drives appear to be normal. By my reckoning, the "seek error rate"
    >>>> parameter appears to be a seek count, not an error, and not a rate.
    >>>
    >>>Agreed for the raw value. I am actually concerned about the cooked
    >>>values. They are a bit low, which may aor may not indicate a problem.
    >>>If removing hdb (SectorIdNotFound is a killer...) solves the
    >>>issue, I would say that hda is likely fine but should be watched.
    >>>
    >>>
    >>>Arno

    >
    >> Sorry, I should have looked more closely. It would appear then that
    >> the raw value and the normalised values are not directly related. The
    >> former is monotonically increasing according to my testing, but
    >> clearly the normalised values show a worst case figure which is less
    >> than the current value. I wish Seagate would come clean and release
    >> their SMART documentation, if only to dispel people's concerns over
    >> the large raw "error" numbers.

    >
    >And agreed again. At least there is a cooked value that has
    >a somewhat constant and known semantics.
    >
    >Arno


    Some time ago I posted these results for my failing Seagate 13GB HDD:
    http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS

    They span a period of 521 powered-on hours.

    During that time the normalised values did not change.

    Attribute ID Threshold Value Worst
    ----------------------------------------------------
    * Seek Error Rate 7 30 53 38

    I don't know what to make of that, if anything.

    I would have thought that a genuine seek error rate figure would vary
    from day to day.

    - Franc Zabkar
    --
    Please remove one 'i' from my address when replying by email.

  9. Re: Bad disk controller? Dying HDD?

    Franc Zabkar wrote in news:8m1ca4lkm4gnidc02nd49692k9atilnr0v@4ax.com
    > On 14 Aug 2008 11:01:21 GMT, Arno Wagner put finger
    > to keyboard and composed:
    >
    > > In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > > > On 14 Aug 2008 00:36:19 GMT, Arno Wagner put finger
    > > > to keyboard and composed:

    > >
    > > > > > High raw "seek error rate" and "read error rate" figures for Seagate
    > > > > > drives appear to be normal. By my reckoning, the "seek error rate"
    > > > > > parameter appears to be a seek count, not an error, and not a rate.
    > > > >
    > > > > Agreed for the raw value. I am actually concerned about the cooked
    > > > > values. They are a bit low, which may aor may not indicate a problem.
    > > > > If removing hdb (SectorIdNotFound is a killer...) solves the
    > > > > issue, I would say that hda is likely fine but should be watched.
    > > > >
    > > > >
    > > > > Arno

    > >
    > > > Sorry, I should have looked more closely. It would appear then that
    > > > the raw value and the normalised values are not directly related. The
    > > > former is monotonically increasing according to my testing, but
    > > > clearly the normalised values show a worst case figure which is less
    > > > than the current value. I wish Seagate would come clean and release
    > > > their SMART documentation, if only to dispel people's concerns over
    > > > the large raw "error" numbers.

    > >

    [snip]
    > >
    > > Arno

    >
    > Some time ago I posted these results for my failing Seagate 13GB HDD:
    > http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS
    >
    > They span a period of 521 powered-on hours.
    >
    > During that time the normalised values did not change.
    >
    > Attribute ID Threshold Value Worst
    > ----------------------------------------------------


    > * Seek Error Rate 7 30 53 38


    Oh look, they are quite 'low'. Whatever 'low' is.

    > I don't know what to make of that, if anything.


    That SMART attributes are Vendor specific maybe ?

    > I would have thought that a genuine seek error rate figure would vary
    > from day to day.


    Well, that rather depends on the resolution of that counter, doesn't it.

    >
    > - Franc Zabkar


  10. Re: Bad disk controller? Dying HDD?

    In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > On 14 Aug 2008 11:01:21 GMT, Arno Wagner put finger

    [...]
    >>And agreed again. At least there is a cooked value that has
    >>a somewhat constant and known semantics.
    >>
    >>Arno


    > Some time ago I posted these results for my failing Seagate 13GB HDD:
    > http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS


    > They span a period of 521 powered-on hours.


    > During that time the normalised values did not change.


    > Attribute ID Threshold Value Worst
    > ----------------------------------------------------
    > * Seek Error Rate 7 30 53 38


    > I don't know what to make of that, if anything.


    The worst value was close to the threshold at one time.
    SMART thresholds are notoriously overoptimistic on disks.
    The worst value indicates a serious problem. The current
    value of 53 is a lot lower than the (likely) initial value
    of 100 and very close to the threshold of 30. This disk
    has a serious problem, which, in the case of seek errors,
    can also be cause by external factors such as a bad PSU
    or strong vibration.

    > I would have thought that a genuine seek error rate figure would vary
    > from day to day.


    Not necessarily. Depends on how they are measured. If the
    problem is relatively staric, and if this is a longer-term
    average, the values can remain pretty constant.

    I agree however that a sensible measurement
    scheme would likely have different values from day to
    day, at least if this deep into failure.

    Arno

  11. Re: Bad disk controller? Dying HDD?

    On 16 Aug 2008 00:36:32 GMT, Arno Wagner put finger
    to keyboard and composed:

    >> Some time ago I posted these results for my failing Seagate 13GB HDD:
    >> http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS

    >
    >> They span a period of 521 powered-on hours.

    >
    >> During that time the normalised values did not change.

    >
    >> Attribute ID Threshold Value Worst
    >> ----------------------------------------------------
    >> * Seek Error Rate 7 30 53 38

    >
    >> I don't know what to make of that, if anything.

    >
    >The worst value was close to the threshold at one time.
    >SMART thresholds are notoriously overoptimistic on disks.
    >The worst value indicates a serious problem. The current
    >value of 53 is a lot lower than the (likely) initial value
    >of 100 and very close to the threshold of 30. This disk
    >has a serious problem, which, in the case of seek errors,
    >can also be cause by external factors such as a bad PSU
    >or strong vibration.


    I just checked to see what other people were getting. It appears that
    everyone with a working drive gets 60 and 30 for the worst and
    threshold values of the seek error rate attribute. AFAICS, that makes
    the data somewhat suspect. In fact the OP's drive is no worse than any
    other.

    OP's ST380011A (80GB)
    Current/Worst/Threshold = 82/60/30

    ST3320620AS (320GB)
    http://img360.imageshack.us/img360/7...10smarttx3.jpg
    http://img58.imageshack.us/img58/8498/7200smarttf4.jpg
    83/60/30

    ST340016A (40GB)
    http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT
    76/60/30

    ST3120026A (120GB)
    http://www.users.on.net/~fzabkar/SmartUDM/120GB.RPT
    79/60/30

    Seagate SATA 7200.10 (500GB)
    http://www.tomshardware.com/forum/22...200-sata-500gb
    63/60/30

    Seagate 160GB SATA 2.5" ST9160821AS
    http://forums.seagate.com/stx/board/...thread.id=1428
    63/60/30

    ST3160812A (160GB)
    http://forum.hddguru.com/software-f7...12a-t6703.html
    65/60/??

    ST3160811AS
    http://www.passmark.com/forum/archiv...php/t-779.html
    69/60/30

    - Franc Zabkar
    --
    Please remove one 'i' from my address when replying by email.

  12. Re: Bad disk controller? Dying HDD?

    In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > On 16 Aug 2008 00:36:32 GMT, Arno Wagner put finger
    > to keyboard and composed:


    >>> Some time ago I posted these results for my failing Seagate 13GB HDD:
    >>> http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS

    >>
    >>> They span a period of 521 powered-on hours.

    >>
    >>> During that time the normalised values did not change.

    >>
    >>> Attribute ID Threshold Value Worst
    >>> ----------------------------------------------------
    >>> * Seek Error Rate 7 30 53 38

    >>
    >>> I don't know what to make of that, if anything.

    >>
    >>The worst value was close to the threshold at one time.
    >>SMART thresholds are notoriously overoptimistic on disks.
    >>The worst value indicates a serious problem. The current
    >>value of 53 is a lot lower than the (likely) initial value
    >>of 100 and very close to the threshold of 30. This disk
    >>has a serious problem, which, in the case of seek errors,
    >>can also be cause by external factors such as a bad PSU
    >>or strong vibration.


    > I just checked to see what other people were getting. It appears that
    > everyone with a working drive gets 60 and 30 for the worst and
    > threshold values of the seek error rate attribute. AFAICS, that makes
    > the data somewhat suspect. In fact the OP's drive is no worse than any
    > other.


    > OP's ST380011A (80GB)
    > Current/Worst/Threshold = 82/60/30


    > ST3320620AS (320GB)
    > http://img360.imageshack.us/img360/7...10smarttx3.jpg
    > http://img58.imageshack.us/img58/8498/7200smarttf4.jpg
    > 83/60/30


    > ST340016A (40GB)
    > http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT
    > 76/60/30


    > ST3120026A (120GB)
    > http://www.users.on.net/~fzabkar/SmartUDM/120GB.RPT
    > 79/60/30


    > Seagate SATA 7200.10 (500GB)
    > http://www.tomshardware.com/forum/22...200-sata-500gb
    > 63/60/30


    > Seagate 160GB SATA 2.5" ST9160821AS
    > http://forums.seagate.com/stx/board/...thread.id=1428
    > 63/60/30


    > ST3160812A (160GB)
    > http://forum.hddguru.com/software-f7...12a-t6703.html
    > 65/60/??


    > ST3160811AS
    > http://www.passmark.com/forum/archiv...php/t-779.html
    > 69/60/30


    Hmm. Seems Seagate is doing something definitely non-intuitive
    here. I have one that had shows the same symptoms. Not found
    on Hitachi, WD, Samsung. Pretty stupid design.

    Arno

  13. Re: Bad disk controller? Dying HDD?

    Arno Wagner wrote in news:6gog28Fgu2g0U1@mid.individual.net
    > In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:
    > > On 16 Aug 2008 00:36:32 GMT, Arno Wagner put finger
    > > to keyboard and composed:

    >
    > > > > Some time ago I posted these results for my failing Seagate 13GB HDD:
    > > > > http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS
    > > >
    > > > > They span a period of 521 powered-on hours.
    > > >
    > > > > During that time the normalised values did not change.
    > > >
    > > > > Attribute ID Threshold Value Worst
    > > > > ----------------------------------------------------
    > > > > * Seek Error Rate 7 30 53 38
    > > >
    > > > > I don't know what to make of that, if anything.
    > > >
    > > > The worst value was close to the threshold at one time.
    > > > SMART thresholds are notoriously overoptimistic on disks.
    > > > The worst value indicates a serious problem. The current
    > > > value of 53 is a lot lower than the (likely) initial value
    > > > of 100 and very close to the threshold of 30. This disk
    > > > has a serious problem, which, in the case of seek errors,
    > > > can also be cause by external factors such as a bad PSU
    > > > or strong vibration.

    >
    > > I just checked to see what other people were getting. It appears that
    > > everyone with a working drive gets 60 and 30 for the worst and
    > > threshold values of the seek error rate attribute. AFAICS, that makes
    > > the data somewhat suspect. In fact the OP's drive is no worse than any
    > > other.

    >
    > > OP's ST380011A (80GB)
    > > Current/Worst/Threshold = 82/60/30

    >
    > > ST3320620AS (320GB)
    > > http://img360.imageshack.us/img360/7...10smarttx3.jpg
    > > http://img58.imageshack.us/img58/8498/7200smarttf4.jpg
    > > 83/60/30

    >
    > > ST340016A (40GB)
    > > http://www.users.on.net/~fzabkar/SmartUDM/40GB.RPT
    > > 76/60/30

    >
    > > ST3120026A (120GB)
    > > http://www.users.on.net/~fzabkar/SmartUDM/120GB.RPT
    > > 79/60/30

    >
    > > Seagate SATA 7200.10 (500GB)
    > > http://www.tomshardware.com/forum/22...200-sata-500gb
    > > 63/60/30

    >
    > > Seagate 160GB SATA 2.5" ST9160821AS
    > > http://forums.seagate.com/stx/board/...thread.id=1428
    > > 63/60/30

    >
    > > ST3160812A (160GB)
    > > http://forum.hddguru.com/software-f7...12a-t6703.html
    > > 65/60/??

    >
    > > ST3160811AS
    > > http://www.passmark.com/forum/archiv...php/t-779.html
    > > 69/60/30


    > Hmm.


    Still not have that humming in your head looked after, Babblebot?

    > Seems Seagate is doing something definitely non-intuitive here.


    > I have one that had shows the same symptoms.


    So you well knew that you were bull****ting, Babblebot.

    > Not found on Hitachi, WD, Samsung.


    > Pretty stupid design.


    Well suited for a pretty stupid Babblebot.

    >
    > Arno


  14. Re: Bad disk controller? Dying HDD?

    On 16 Aug 2008 17:11:36 GMT, Arno Wagner put finger
    to keyboard and composed:

    >In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:


    >> I just checked to see what other people were getting. It appears that
    >> everyone with a working drive gets 60 and 30 for the worst and
    >> threshold values of the seek error rate attribute. AFAICS, that makes
    >> the data somewhat suspect. In fact the OP's drive is no worse than any
    >> other.

    >
    >> OP's ST380011A (80GB)
    >> Current/Worst/Threshold = 82/60/30




    >> ST3160811AS
    >> http://www.passmark.com/forum/archiv...php/t-779.html
    >> 69/60/30

    >
    >Hmm. Seems Seagate is doing something definitely non-intuitive
    >here. I have one that had shows the same symptoms. Not found
    >on Hitachi, WD, Samsung. Pretty stupid design.
    >
    >Arno


    Here's one where the seek error rate (Current/Worst/Threshold =
    28/28/30) is causing a bad SMART status:
    http://www.techsupportforum.com/hard...e-too-low.html

    The raw value of 58266 is relatively low, as is the Power-On Time
    Count of 194.

    - Franc Zabkar
    --
    Please remove one 'i' from my address when replying by email.

  15. Re: Bad disk controller? Dying HDD?

    Franc Zabkar wrote in newssbea49oh4omj68l5prgv9prdaknfr53oc@4ax.com
    > On 16 Aug 2008 17:11:36 GMT, Arno Wagner put finger
    > to keyboard and composed:
    >
    > > In comp.sys.ibm.pc.hardware.storage Franc Zabkar wrote:

    >
    > > > I just checked to see what other people were getting. It appears that
    > > > everyone with a working drive gets 60 and 30 for the worst and
    > > > threshold values of the seek error rate attribute. AFAICS, that makes
    > > > the data somewhat suspect. In fact the OP's drive is no worse than any
    > > > other.

    > >
    > > > OP's ST380011A (80GB)
    > > > Current/Worst/Threshold = 82/60/30

    >
    >
    >
    > > > ST3160811AS
    > > > http://www.passmark.com/forum/archiv...php/t-779.html
    > > > 69/60/30

    > >
    > > Hmm. Seems Seagate is doing something definitely non-intuitive
    > > here. I have one that had shows the same symptoms. Not found
    > > on Hitachi, WD, Samsung. Pretty stupid design.
    > >
    > > Arno

    >
    > Here's one where the seek error rate (Current/Worst/Threshold =
    > 28/28/30) is causing a bad SMART status:
    > http://www.techsupportforum.com/hard...e-too-low.html


    > The raw value of 58266 is relatively low, as is the Power-On Time
    > Count of 194.


    Yeah, but then it is a Maxtor, not a Seagate. Your point being?

    >
    > - Franc Zabkar


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3