HI,
I was trying kernel 2.5 with TCQ enabled.
I tried it on three Desktar disk (manufactured in Thailand
in february 2001) model dtla 305020.
All three disk died after some week, without
any signal of being dying.
I was starting to suspect about an HW problem.
With 2.4 kernels, no tcq, they could work
without any problem for almost 8 months, but now,
I moved those disk to test systems to test tcq support
and all died badly. This is not an heat problem, since
thay staty in a CED conditioned at 18C.
Has anyone had a similar experience with this kind of disks?
Luigi
On Fri, Jul 05 2002, [email protected] wrote:
>
> HI,
> I was trying kernel 2.5 with TCQ enabled.
> I tried it on three Desktar disk (manufactured in Thailand
> in february 2001) model dtla 305020.
>
> All three disk died after some week, without
> any signal of being dying.
> I was starting to suspect about an HW problem.
>
> With 2.4 kernels, no tcq, they could work
> without any problem for almost 8 months, but now,
> I moved those disk to test systems to test tcq support
> and all died badly. This is not an heat problem, since
> thay staty in a CED conditioned at 18C.
This is a puzzling report. I wouldn't recommend that anyone use tcq in
2.5 actually, since even I do not know what state it is currently in. I
would seriously recommend 2.4 + tcq patches instead.
That said, are your disks completely dead now? As in they do not work
with a regular 2.4 kernel anymore?!
--
Jens Axboe
At 11:40 05/07/02, Jens Axboe wrote:
>On Fri, Jul 05 2002, [email protected] wrote:
> >
> > HI,
> > I was trying kernel 2.5 with TCQ enabled.
> > I tried it on three Desktar disk (manufactured in Thailand
> > in february 2001) model dtla 305020.
> >
> > All three disk died after some week, without
> > any signal of being dying.
> > I was starting to suspect about an HW problem.
> >
> > With 2.4 kernels, no tcq, they could work
> > without any problem for almost 8 months, but now,
> > I moved those disk to test systems to test tcq support
> > and all died badly. This is not an heat problem, since
> > thay staty in a CED conditioned at 18C.
>
>This is a puzzling report. I wouldn't recommend that anyone use tcq in
>2.5 actually, since even I do not know what state it is currently in. I
>would seriously recommend 2.4 + tcq patches instead.
>
>That said, are your disks completely dead now? As in they do not work
>with a regular 2.4 kernel anymore?!
It is puzzling indeed, especially since I am running with TCQ enabled ever
since you introduced it and my disk is still alive an kicking. It being a
Deathstar, too.
On of my Deathstars actually broke (before TCQ came about though!) but
after upgrading the firmware on it and powercycling it fixed itself and has
been working just fine ever since.
Perhaps something worth trying on those broken disks, too?
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, Jul 05 2002, Anton Altaparmakov wrote:
> At 11:40 05/07/02, Jens Axboe wrote:
> >On Fri, Jul 05 2002, [email protected] wrote:
> >>
> >> HI,
> >> I was trying kernel 2.5 with TCQ enabled.
> >> I tried it on three Desktar disk (manufactured in Thailand
> >> in february 2001) model dtla 305020.
> >>
> >> All three disk died after some week, without
> >> any signal of being dying.
> >> I was starting to suspect about an HW problem.
> >>
> >> With 2.4 kernels, no tcq, they could work
> >> without any problem for almost 8 months, but now,
> >> I moved those disk to test systems to test tcq support
> >> and all died badly. This is not an heat problem, since
> >> thay staty in a CED conditioned at 18C.
> >
> >This is a puzzling report. I wouldn't recommend that anyone use tcq in
> >2.5 actually, since even I do not know what state it is currently in. I
> >would seriously recommend 2.4 + tcq patches instead.
> >
> >That said, are your disks completely dead now? As in they do not work
> >with a regular 2.4 kernel anymore?!
>
> It is puzzling indeed, especially since I am running with TCQ enabled ever
> since you introduced it and my disk is still alive an kicking. It being a
> Deathstar, too.
Good to know, I'm glad it works for you :-)
> On of my Deathstars actually broke (before TCQ came about though!) but
> after upgrading the firmware on it and powercycling it fixed itself and has
> been working just fine ever since.
>
> Perhaps something worth trying on those broken disks, too?
Might be a good idea, I did the same thing on my DTLA as well.
--
Jens Axboe
Am Fre, 2002-07-05 um 12.27 schrieb [email protected]:
> Has anyone had a similar experience with this kind of disks?
I suspect it's the usual IBM crap phenomenon; three discs died in the
last two weeks (1 DTLA and 2 IC35) here, that's a whooping 33% of the
IBM drives I use. No TCQ involved and on one not even Linux and the
other two had two different stable 2.4 kernels.
<problemdescription>
The drives started developping bad sectors, one of the drives to a
degree over 10% of the total amount sectors; according to IBM it's
a "software failure" of the device driver and can be fixed by what
they call "Erase Disc" i.e. a lowlevel format. Needless to say I
tried this on one drive and the problems started again one week
later. The drives are between 3 and 12 months old and are now on
their way to IBM.
</problemdescription>
<advise>
Buy decent drives, then get DriveFitnessTest (DFT) from their website
and check the harddrives, note the TRC number, request an RMA on their
website and ship the drives as soon as possible to IBM. Wait for the
replacement drives and sell them ASAP on Ebay to some freaks who don't
give a dime about data security.
</advise>
--
Servus,
Daniel
On Fri, 5 Jul 2002, Jens Axboe wrote:
> Date: Fri, 5 Jul 2002 12:40:37 +0200
> From: Jens Axboe <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: IBM Desktar disk problem?
>
> On Fri, Jul 05 2002, [email protected] wrote:
> >
> > HI,
> > I was trying kernel 2.5 with TCQ enabled.
> > I tried it on three Desktar disk (manufactured in Thailand
> > in february 2001) model dtla 305020.
> >
> > All three disk died after some week, without
> > any signal of being dying.
> > I was starting to suspect about an HW problem.
> >
> > With 2.4 kernels, no tcq, they could work
> > without any problem for almost 8 months, but now,
> > I moved those disk to test systems to test tcq support
> > and all died badly. This is not an heat problem, since
> > thay staty in a CED conditioned at 18C.
>
> This is a puzzling report. I wouldn't recommend that anyone use tcq in
> 2.5 actually, since even I do not know what state it is currently in. I
> would seriously recommend 2.4 + tcq patches instead.
>
> That said, are your disks completely dead now? As in they do not work
> with a regular 2.4 kernel anymore?!
Right now they are good just for the trash box.
There is no way they could work, and I listen a noisy
tic-tac frrr tic-tac from the head of the disks...
I would think to an HW problem, but why all three together?
and why exacly when I tested tcq?
Hi,
On 5 Jul 2002, Daniel Egger wrote:
> <advise>
> Buy decent drives, then get DriveFitnessTest (DFT) from their website
> and check the harddrives, note the TRC number, request an RMA on their
> website and ship the drives as soon as possible to IBM. Wait for the
> replacement drives and sell them ASAP on Ebay to some freaks who don't
> give a dime about data security.
> </advise>
...and tell all the people who got a DTLA (because it's not as expensive
as others in some countries, mind France, USA, Germany) to drop their
disks if they want to use Linux, because we're too lazy to find a
solution. That might be cool to you, but we want HARDWARE SUPPORT for
Linux! That's why we're here.
There _is_ a solution, we just have to find it.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Fri, 5 Jul 2002 [email protected] wrote:
> On Fri, 5 Jul 2002, Jens Axboe wrote:
>
> > Date: Fri, 5 Jul 2002 12:40:37 +0200
> > From: Jens Axboe <[email protected]>
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: IBM Desktar disk problem?
> >
> > On Fri, Jul 05 2002, [email protected] wrote:
> > >
> > > HI,
> > > I was trying kernel 2.5 with TCQ enabled.
> > > I tried it on three Desktar disk (manufactured in Thailand
> > > in february 2001) model dtla 305020.
> > >
> > > All three disk died after some week, without
> > > any signal of being dying.
> > > I was starting to suspect about an HW problem.
> > >
> > > With 2.4 kernels, no tcq, they could work
> > > without any problem for almost 8 months, but now,
> > > I moved those disk to test systems to test tcq support
> > > and all died badly. This is not an heat problem, since
> > > thay staty in a CED conditioned at 18C.
> >
> > This is a puzzling report. I wouldn't recommend that anyone use tcq in
> > 2.5 actually, since even I do not know what state it is currently in. I
> > would seriously recommend 2.4 + tcq patches instead.
> >
> > That said, are your disks completely dead now? As in they do not work
> > with a regular 2.4 kernel anymore?!
>
> Right now they are good just for the trash box.
> There is no way they could work, and I listen a noisy
> tic-tac frrr tic-tac from the head of the disks...
>
>
> I would think to an HW problem, but why all three together?
> and why exacly when I tested tcq?
>
hi i have similar problem.
No dead disks, but after two days testing tcq patches (on 2.4). I
got the two ATA errors (smartctl said).
I think that it's no good to test tcq on IBM disks. My disk was without
any problems one year. Two problems now is not normal.
For final i think, that tcq patch is not fully stable, becouse on high
disk load i get oops and have to reboot. I have no problem when i remove
tcq patches.
(high load i mean copy cca 20GiB between two IBM disks).
MOJE
--
Tomas Konir
Brno
ICQ 25849167
On Fri, 5 Jul 2002, Thunder from the hill wrote:
> ...and tell all the people who got a DTLA (because it's not as expensive
> as others in some countries, mind France, USA, Germany) to drop their
> disks if they want to use Linux, because we're too lazy to find a
> solution. That might be cool to you, but we want HARDWARE SUPPORT for
> Linux! That's why we're here.
>
> There _is_ a solution, we just have to find it.
Huh?
--
http://function.linuxpower.ca
At 15:03 05/07/02, Thunder from the hill wrote:
>On 5 Jul 2002, Daniel Egger wrote:
> > <advise>
> > Buy decent drives, then get DriveFitnessTest (DFT) from their website
> > and check the harddrives, note the TRC number, request an RMA on their
> > website and ship the drives as soon as possible to IBM. Wait for the
> > replacement drives and sell them ASAP on Ebay to some freaks who don't
> > give a dime about data security.
> > </advise>
>
>...and tell all the people who got a DTLA (because it's not as expensive
>as others in some countries, mind France, USA, Germany) to drop their
>disks if they want to use Linux, because we're too lazy to find a
>solution. That might be cool to you, but we want HARDWARE SUPPORT for
>Linux! That's why we're here.
>
>There _is_ a solution, we just have to find it.
Um, the solution is already known. Upgrade the firmware on the drive, low
level format if the drive thinks there are bad sectors, and be happy. At
least it worked for me...
The very first question when making a support call for my broken deathstar
was "Have you installed the firmware update?" "No." "Download it here and
install, come back if it still doesn't work."
I never thought it would work but it did! It seems there is something wrong
in the firmware the drives are shipped with and some suppliers obviously
know this considering my experience... When I was running the DFT test
utility it was telling me my drive is broken and needs to be returned.
After the firmware update the same test utility passed all tests repeatedly!
With 5 deathstars (one DTLA and four IC ones), all with firmware updates
now, I have no problems and the oldest of the drives is now over 3 years
old IIRC and some are pretty much in constant spun-up state since purchase...
The only problem I can see is that IBM is not pushing people to apply the
firmware updates. I have never been even able to find where to download
them on the IBM website. - I downloaded them from the website of my supplier...
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, Jul 05 2002, Tomas Konir wrote:
> On Fri, 5 Jul 2002 [email protected] wrote:
>
> > On Fri, 5 Jul 2002, Jens Axboe wrote:
> >
> > > Date: Fri, 5 Jul 2002 12:40:37 +0200
> > > From: Jens Axboe <[email protected]>
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: Re: IBM Desktar disk problem?
> > >
> > > On Fri, Jul 05 2002, [email protected] wrote:
> > > >
> > > > HI,
> > > > I was trying kernel 2.5 with TCQ enabled.
> > > > I tried it on three Desktar disk (manufactured in Thailand
> > > > in february 2001) model dtla 305020.
> > > >
> > > > All three disk died after some week, without
> > > > any signal of being dying.
> > > > I was starting to suspect about an HW problem.
> > > >
> > > > With 2.4 kernels, no tcq, they could work
> > > > without any problem for almost 8 months, but now,
> > > > I moved those disk to test systems to test tcq support
> > > > and all died badly. This is not an heat problem, since
> > > > thay staty in a CED conditioned at 18C.
> > >
> > > This is a puzzling report. I wouldn't recommend that anyone use tcq in
> > > 2.5 actually, since even I do not know what state it is currently in. I
> > > would seriously recommend 2.4 + tcq patches instead.
> > >
> > > That said, are your disks completely dead now? As in they do not work
> > > with a regular 2.4 kernel anymore?!
> >
> > Right now they are good just for the trash box.
> > There is no way they could work, and I listen a noisy
> > tic-tac frrr tic-tac from the head of the disks...
> >
> >
> > I would think to an HW problem, but why all three together?
> > and why exacly when I tested tcq?
> >
>
> hi i have similar problem.
> No dead disks, but after two days testing tcq patches (on 2.4). I
> got the two ATA errors (smartctl said).
> I think that it's no good to test tcq on IBM disks. My disk was without
> any problems one year. Two problems now is not normal.
I find this hard to believe (why would using a different set of
read/write commands show problems?!), and so far the evidence is far
from conclusive. I'll be watching it, though.
> For final i think, that tcq patch is not fully stable, becouse on high
> disk load i get oops and have to reboot. I have no problem when i remove
> tcq patches.
> (high load i mean copy cca 20GiB between two IBM disks).
Any reason you haven't reported this?! Please do so.
--
Jens Axboe
On Fri, 5 Jul 2002, Jens Axboe wrote:
> > hi i have similar problem.
> > No dead disks, but after two days testing tcq patches (on 2.4). I
> > got the two ATA errors (smartctl said).
> > I think that it's no good to test tcq on IBM disks. My disk was without
> > any problems one year. Two problems now is not normal.
>
> I find this hard to believe (why would using a different set of
> read/write commands show problems?!), and so far the evidence is far
> from conclusive. I'll be watching it, though.
If it helps I'll send you complete Log error structure from smartct.
Error Log Structure 1:
DCR FR SC SN CL SH D/H CR Timestamp
00 08 80 ee 88 a2 e0 cc 1210341
00 08 08 ee 88 a2 e0 a2 1210341
00 08 87 04 1d 20 e0 cc 1210341
00 00 00 04 1d 20 e0 00 1210341
00 00 80 06 42 67 e1 c8 1210341
00 84 00 85 42 67 e1 51 0
Error condition: 0 Error State: 3
Error Log Structure 2:
DCR FR SC SN CL SH D/H CR Timestamp
00 80 00 3e 66 23 e1 c7 1386233
00 80 08 3e 66 23 e0 a2 1386233
00 80 30 be 66 23 e1 c7 1386233
00 80 80 be 66 23 e1 c4 1386233
00 08 08 26 32 a4 e0 cc 1386237
00 84 00 2d 32 a4 e0 51 0
Error condition: 0 Error State: 3
>
> > For final i think, that tcq patch is not fully stable, becouse on high
> > disk load i get oops and have to reboot. I have no problem when i remove
> > tcq patches.
> > (high load i mean copy cca 20GiB between two IBM disks).
>
> Any reason you haven't reported this?! Please do so.
sorry but this oops was only on screen and i were no time for log this
to the paper. After second error i removed tcq from my kernel.
(I have no money for new disk now).
MOJE
--
Tomas Konir
Brno
ICQ 25849167
Here's a good place to start:
http://www.geocities.com/dtla_update/
Cheers,
Phil
---------------------------------------------
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK
> -----Original Message-----
> From: Anton Altaparmakov [mailto:[email protected]]
> Sent: 05 July 2002 15:30
> To: Thunder from the hill
> Cc: Daniel Egger; [email protected]; [email protected]
> Subject: Re: IBM Desktar disk problem?
>
>
> At 15:03 05/07/02, Thunder from the hill wrote:
> >On 5 Jul 2002, Daniel Egger wrote:
> > > <advise>
> > > Buy decent drives, then get DriveFitnessTest (DFT) from
> their website
> > > and check the harddrives, note the TRC number, request an
> RMA on their
> > > website and ship the drives as soon as possible to IBM.
> Wait for the
> > > replacement drives and sell them ASAP on Ebay to some
> freaks who don't
> > > give a dime about data security.
> > > </advise>
> >
> >...and tell all the people who got a DTLA (because it's not
> as expensive
> >as others in some countries, mind France, USA, Germany) to drop their
> >disks if they want to use Linux, because we're too lazy to find a
> >solution. That might be cool to you, but we want HARDWARE SUPPORT for
> >Linux! That's why we're here.
> >
> >There _is_ a solution, we just have to find it.
>
> Um, the solution is already known. Upgrade the firmware on
> the drive, low
> level format if the drive thinks there are bad sectors, and
> be happy. At
> least it worked for me...
>
> The very first question when making a support call for my
> broken deathstar
> was "Have you installed the firmware update?" "No." "Download
> it here and
> install, come back if it still doesn't work."
>
> I never thought it would work but it did! It seems there is
> something wrong
> in the firmware the drives are shipped with and some
> suppliers obviously
> know this considering my experience... When I was running the
> DFT test
> utility it was telling me my drive is broken and needs to be
> returned.
> After the firmware update the same test utility passed all
> tests repeatedly!
>
> With 5 deathstars (one DTLA and four IC ones), all with
> firmware updates
> now, I have no problems and the oldest of the drives is now
> over 3 years
> old IIRC and some are pretty much in constant spun-up state
> since purchase...
>
> The only problem I can see is that IBM is not pushing people
> to apply the
> firmware updates. I have never been even able to find where
> to download
> them on the IBM website. - I downloaded them from the website
> of my supplier...
>
> Best regards,
>
> Anton
>
>
> --
> "I've not lost my mind. It's backed up on tape somewhere."
> - Unknown
> --
> Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
> WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, 5 Jul 2002, Thunder from the hill wrote:
> Hi,
>
> On 5 Jul 2002, Daniel Egger wrote:
> > <advise>
> > Buy decent drives, then get DriveFitnessTest (DFT) from their website
> > and check the harddrives, note the TRC number, request an RMA on their
> > website and ship the drives as soon as possible to IBM. Wait for the
> > replacement drives and sell them ASAP on Ebay to some freaks who don't
> > give a dime about data security.
> > </advise>
>
> ...and tell all the people who got a DTLA (because it's not as expensive
> as others in some countries, mind France, USA, Germany) to drop their
> disks if they want to use Linux, because we're too lazy to find a
> solution. That might be cool to you, but we want HARDWARE SUPPORT for
> Linux! That's why we're here.
>
> There _is_ a solution, we just have to find it.
Hmm... Would you be so kind to find it? ;-)
--
Bartlomiej
>
> Regards,
> Thunder
> --
> (Use http://www.ebb.org/ungeek if you can't decode)
> ------BEGIN GEEK CODE BLOCK------
> Version: 3.12
> GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
> N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
> e++++ h* r--- y-
> ------END GEEK CODE BLOCK------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Am Fre, 2002-07-05 um 16.48 schrieb Tomas Konir:
> Error Log Structure 1:
> DCR FR SC SN CL SH D/H CR Timestamp
> 00 08 80 ee 88 a2 e0 cc 1210341
> 00 08 08 ee 88 a2 e0 a2 1210341
> 00 08 87 04 1d 20 e0 cc 1210341
> 00 00 00 04 1d 20 e0 00 1210341
> 00 00 80 06 42 67 e1 c8 1210341
> 00 84 00 85 42 67 e1 51 0
> Error condition: 0 Error State: 3
> Error Log Structure 2:
> DCR FR SC SN CL SH D/H CR Timestamp
> 00 80 00 3e 66 23 e1 c7 1386233
> 00 80 08 3e 66 23 e0 a2 1386233
> 00 80 30 be 66 23 e1 c7 1386233
> 00 80 80 be 66 23 e1 c4 1386233
> 00 08 08 26 32 a4 e0 cc 1386237
> 00 84 00 2d 32 a4 e0 51 0
> Error condition: 0 Error State: 3
Not good. Check for the "Reallocated Sector Ct".
--
Servus,
Daniel
Am Fre, 2002-07-05 um 16.03 schrieb Thunder from the hill:
> ...and tell all the people who got a DTLA (because it's not as expensive
> as others in some countries, mind France, USA, Germany) to drop their
> disks if they want to use Linux, because we're too lazy to find a
> solution. That might be cool to you, but we want HARDWARE SUPPORT for
> Linux! That's why we're here.
> There _is_ a solution, we just have to find it.
Except you believe in the at least questionable explanation from IBM
there's nothing one can solve with software. And since quite a lot
of drives died under several Linux, Windows, *BSD and Mac versions
I don't buy the driver argument and in fact think that IBM is using
this poor excuse to avoid a big (and expensive) replacement plan
on the cost of the users.
I've yet to see a <insert your favourite non-IBM harddrive manufacturer
here>-drive dying after a few months of use, the negative record in this
regard (except for the IBMs) was a Quantum Atlas UW-SCSI drive (which
was in fact also manufactured FOR IBM) which died after 2,5 years of
heavy use which is at least somewhere in the range what one might expect
as lifetime; all other drives here (up to 10 years old) are still alive
and kickin'.
Even if you have backups and RAID systems, a broken harddrive can be
quite expensive; think of data restoration, drive replacement,
downtimes, shipment, data loss which all costs at least one thing: time
and lots of it.
We estimate around 10h per broken drive while it takes a lot less time
(<1h) to simple replace the discs before the accident which is what
we're doing now with all IBM drives prophylactically.
--
Servus,
Daniel
Am Fre, 2002-07-05 um 16.29 schrieb Anton Altaparmakov:
> Um, the solution is already known. Upgrade the firmware on the drive, low
> level format if the drive thinks there are bad sectors, and be happy. At
> least it worked for me...
> The very first question when making a support call for my broken deathstar
> was "Have you installed the firmware update?" "No." "Download it here and
> install, come back if it still doesn't work."
> I never thought it would work but it did! It seems there is something wrong
> in the firmware the drives are shipped with and some suppliers obviously
> know this considering my experience... When I was running the DFT test
> utility it was telling me my drive is broken and needs to be returned.
> After the firmware update the same test utility passed all tests repeatedly!
This is unacceptable; if my problem is really fixable by a firmware
upgrade IBM should have pushed this very upgrade publically after they
started to learn about the problem. Saying "Hey, BTW: if you had this
firmware version you would never have experienced your data loss" is
a very strong argument to never buy any IBM hardware again.
Still, the techsupport insisted on a software problem and didn't mention
a firmware upgrade; up to now I didn't even knew such a thing exists.
And letting customers lowlevel-format a drive, restore their data,
and experience the same problem again a week later is anything but
professional.
Though the timespan makes me curious: Why is there a magnitude
difference in runtime between the first problem on a fresh drive
and after a lowlevel format?
--
Servus,
Daniel
On 5 Jul 2002, Daniel Egger wrote:
> Am Fre, 2002-07-05 um 16.48 schrieb Tomas Konir:
>
> > Error Log Structure 1:
> > DCR FR SC SN CL SH D/H CR Timestamp
> > 00 08 80 ee 88 a2 e0 cc 1210341
> > 00 08 08 ee 88 a2 e0 a2 1210341
> > 00 08 87 04 1d 20 e0 cc 1210341
> > 00 00 00 04 1d 20 e0 00 1210341
> > 00 00 80 06 42 67 e1 c8 1210341
> > 00 84 00 85 42 67 e1 51 0
> > Error condition: 0 Error State: 3
>
> > Error Log Structure 2:
> > DCR FR SC SN CL SH D/H CR Timestamp
> > 00 80 00 3e 66 23 e1 c7 1386233
> > 00 80 08 3e 66 23 e0 a2 1386233
> > 00 80 30 be 66 23 e1 c7 1386233
> > 00 80 80 be 66 23 e1 c4 1386233
> > 00 08 08 26 32 a4 e0 cc 1386237
> > 00 84 00 2d 32 a4 e0 51 0
> > Error condition: 0 Error State: 3
>
> Not good. Check for the "Reallocated Sector Ct".
>
There are no reallocated sectors.
Do you know what these error messages means ?
MOJE
--
Tomas Konir
Brno
ICQ 25849167
Hi,
On 5 Jul 2002, Daniel Egger wrote:
> Though the timespan makes me curious: Why is there a magnitude
> difference in runtime between the first problem on a fresh drive
> and after a lowlevel format?
Can be anything. The disk's administration parts getting messed up with
crap, and already having got messed up by some test run right after
production. Or maybe the drives were padded with maintainer data before
they were shipped (means, after production).
Imagine it thermodynamically. A half-ordered system keeps getting messed
up. Somewhen it's messed up. If you order your system it will take longer
for the drive to get messed up.
Maybe the part which failed in the old firmware was some garbage
collection code? Something that removes the crap?
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Hi,
On Fri, 5 Jul 2002, Bartlomiej Zolnierkiewicz wrote:
> > There _is_ a solution, we just have to find it.
>
> Hmm... Would you be so kind to find it? ;-)
IBM did, it seems. I don't think it was something that would have been
fixable from os level. It might really have been an error on the hard
disk. A forgotten call, whatever.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
At 2002-07-05 15:23:39 Daniel Egger <[email protected]> wrote:
> I've yet to see a <insert your favourite non-IBM harddrive manufacturer
> here>-drive dying after a few months of use
How about a 20 gig Seagate Barracuda ATA II Model ST320420A dying after 1.5 months, and the replacement disk - same model - after 5 months. The supplier blamed my IDE controller (old standard
Intel Corp. 82371FB PIIX IDE [Triton I]: chipset revision 2) and refused to replace the second dud.
The 15 gig IBM-DTLA-307015 has worked flawlessly in the same system for a year. Have yet to try TCQ though. Waiting for a "stable" and modern 2.4
Regards,
Mats Johannesson
On Fri, 5 Jul 2002, Voluspa wrote:
> At 2002-07-05 15:23:39 Daniel Egger <[email protected]> wrote:
>
> > I've yet to see a <insert your favourite non-IBM harddrive manufacturer
> > here>-drive dying after a few months of use
>
> How about a 20 gig Seagate Barracuda ATA II Model ST320420A dying after 1.5 months, and the replacement disk - same model - after 5 months. The supplier blamed my IDE controller (old standard
> Intel Corp. 82371FB PIIX IDE [Triton I]: chipset revision 2) and refused to replace the second dud.
>
> The 15 gig IBM-DTLA-307015 has worked flawlessly in the same system for a year. Have yet to try TCQ though. Waiting for a "stable" and modern 2.4
>
> Regards,
> Mats Johannesson
Overheating?
Regards
--
Bartlomiej
On Fri, 5 Jul 2002 20:05:23 +0200 (MET DST)
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> Overheating?
Yes. First one was like a frying pan on the surface. But the second had a moderate temp. Inside temp of the box, no problem.
Regards,
Mats Johannesson
On Fri, 05 Jul 2002, Tomas Konir wrote:
> hi i have similar problem.
> No dead disks, but after two days testing tcq patches (on 2.4). I
> got the two ATA errors (smartctl said).
*shrug* FreeBSD should have eaten some of those drives as well, it has
been offering hw.ata.tags="1" to enable DMA QUEUED for a while now.
And yes, my deathstar DTLA307045 still works without a single broken
block, but never used TCQ beyond booting 2.5.17 once (no LVM -> not
useful for me).
Another DTLA307045 died some days ago, it has never seen TCQ.
On Fri, 5 Jul 2002, Matthias Andree wrote:
> On Fri, 05 Jul 2002, Tomas Konir wrote:
>
> > hi i have similar problem.
> > No dead disks, but after two days testing tcq patches (on 2.4). I
> > got the two ATA errors (smartctl said).
>
> *shrug* FreeBSD should have eaten some of those drives as well, it has
> been offering hw.ata.tags="1" to enable DMA QUEUED for a while now.
>
> And yes, my deathstar DTLA307045 still works without a single broken
> block, but never used TCQ beyond booting 2.5.17 once (no LVM -> not
> useful for me).
>
> Another DTLA307045 died some days ago, it has never seen TCQ.
>
I have no broken blocks. Only two errors logged in S.M.A.R.T.
I have no S.M.A.R.T. errors for one year ago. And after use TCQ there are
two errors after two days. Is is normal ?
Curently i not believe new IBM disks and TCQ. I'll wait for better disks
and stable TCQ.
MOJE
--
Tomas Konir
Brno
ICQ 25849167
On Fri, 05 Jul 2002, Thunder from the hill wrote:
> ...and tell all the people who got a DTLA (because it's not as expensive
> as others in some countries, mind France, USA, Germany) to drop their
> disks if they want to use Linux, because we're too lazy to find a
> solution. That might be cool to you, but we want HARDWARE SUPPORT for
> Linux! That's why we're here.
>
> There _is_ a solution, we just have to find it.
Might just be that "coincidence" happens more often as "incident"
happens more often. Means: the more drives of that type fails, the more
likely it is someone shows up with a report that the failure is related
to this-and-that. Until someone can reproduce this, assume the TCQ is
Not Guilty in respect to your DTLA failure. Assume it has died a natural
death.
And the "incident often" seems to hold for 75GXP series drives (IBM
DTLA-3070xx). Out of seven DTLA-307045 (all bought approx. Feb. 2001,
in two different stores) I look after I am getting a MTBF(*) of around
28,000 hours -- which is way lower than what IBM claims. Two died after
9 months, another one after 16 months. Other IBM drives, DJNA, DPTA, are
way more reliable -- but these are no longer sold.
(S?ren Schmidt, FreeBSD ata(4) driver maintainer, says that IBM
acknowledged that DJNA have broken TCQ, sometimes forget to flush a
block -- this will then probably also affect the WDC-420400 and 418....
20G 5400/min and 18G 7200/min drives).
(*) Using Fujitsu's formula:
total hours of service of all drives
MTBF = --------------------------------------
number of failed drives to date
Please do NOT Cc: list mail to me if there is a
Mail-Followup-Header/unless I ask for Cc:! Thanks.
On Fri, 05 Jul 2002, Tomas Konir wrote:
> On Fri, 5 Jul 2002, Matthias Andree wrote:
>
> > On Fri, 05 Jul 2002, Tomas Konir wrote:
> >
> > > hi i have similar problem.
> > > No dead disks, but after two days testing tcq patches (on 2.4). I
> > > got the two ATA errors (smartctl said).
> >
> > *shrug* FreeBSD should have eaten some of those drives as well, it has
> > been offering hw.ata.tags="1" to enable DMA QUEUED for a while now.
> >
> > And yes, my deathstar DTLA307045 still works without a single broken
> > block, but never used TCQ beyond booting 2.5.17 once (no LVM -> not
> > useful for me).
> >
> > Another DTLA307045 died some days ago, it has never seen TCQ.
> >
>
> I have no broken blocks. Only two errors logged in S.M.A.R.T.
So what's the issue?
> I have no S.M.A.R.T. errors for one year ago. And after use TCQ there are
> two errors after two days. Is is normal ?
Are there any strong hints that TCQ caused these?
> Curently i not believe new IBM disks and TCQ. I'll wait for better disks
> and stable TCQ.
That's your liberty to choose. :-) (And I can understand the IBM part of
it.)
On Fri, 5 Jul 2002, Matthias Andree wrote:
> > I have no broken blocks. Only two errors logged in S.M.A.R.T.
>
> So what's the issue?
only information.
>
> > I have no S.M.A.R.T. errors for one year ago. And after use TCQ there are
> > two errors after two days. Is is normal ?
>
> Are there any strong hints that TCQ caused these?
only hypothesis, but vith high probability, because there were no problems
before using TCQ. My hypothesis is that my IBM disk is oveloaded when
using TCQ. (This is only HW problem. No TCQ ).
>
> > Curently i not believe new IBM disks and TCQ. I'll wait for better disks
> > and stable TCQ.
>
> That's your liberty to choose. :-) (And I can understand the IBM part of
> it.)
Yes but is there any other disk which supports TCQ ?
MOJE
--
Tomas Konir
Brno
ICQ 25849167
At 21:21 05/07/02, Tomas Konir wrote:
>On Fri, 5 Jul 2002, Matthias Andree wrote:
>
> > On Fri, 05 Jul 2002, Tomas Konir wrote:
> >
> > > hi i have similar problem.
> > > No dead disks, but after two days testing tcq patches (on 2.4). I
> > > got the two ATA errors (smartctl said).
> >
> > *shrug* FreeBSD should have eaten some of those drives as well, it has
> > been offering hw.ata.tags="1" to enable DMA QUEUED for a while now.
> >
> > And yes, my deathstar DTLA307045 still works without a single broken
> > block, but never used TCQ beyond booting 2.5.17 once (no LVM -> not
> > useful for me).
> >
> > Another DTLA307045 died some days ago, it has never seen TCQ.
> >
>
>I have no broken blocks. Only two errors logged in S.M.A.R.T.
>I have no S.M.A.R.T. errors for one year ago. And after use TCQ there are
>two errors after two days. Is is normal ?
>Curently i not believe new IBM disks and TCQ. I'll wait for better disks
>and stable TCQ.
You should update your firmware regardless of using TCQ because the errors
you experienced have nothing to do with TCQ but a lot to do with buggy
firmware. See what I found written about the firmware update on this
webpage (Phil Randal posted this URL earlier on in this thread):
http://www.geocities.com/dtla_update/
---snip---
While S.M.A.R.T. offline scan running in background, a read error could
cause a potential failure. This is corrected with current microcode.
(A5AA/A6AA) will detect and prevent application specific usage patterns
that cause excessive dwell times in particular areas.
---snip---
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Fri, 5 Jul 2002, Anton Altaparmakov wrote:
> >I have no broken blocks. Only two errors logged in S.M.A.R.T.
> >I have no S.M.A.R.T. errors for one year ago. And after use TCQ there are
> >two errors after two days. Is is normal ?
> >Curently i not believe new IBM disks and TCQ. I'll wait for better disks
> >and stable TCQ.
>
> You should update your firmware regardless of using TCQ because the errors
> you experienced have nothing to do with TCQ but a lot to do with buggy
> firmware. See what I found written about the firmware update on this
> webpage (Phil Randal posted this URL earlier on in this thread):
> http://www.geocities.com/dtla_update/
>
I know this page, but firmware upgrade need windows and i have no windows
and there are no windows near me. I'll try to find windows and upgrade it.
Thanks for your advice.
> ---snip---
> While S.M.A.R.T. offline scan running in background, a read error could
> cause a potential failure. This is corrected with current microcode.
>
> (A5AA/A6AA) will detect and prevent application specific usage patterns
> that cause excessive dwell times in particular areas.
> ---snip---
>
> Best regards,
>
> Anton
MOJE
--
Tomas Konir
Brno
ICQ 25849167
AGAIN: Please DO NOT CC: ME on mailing lists unless I ask for a Cc:
On Fri, 05 Jul 2002, Tomas Konir wrote:
> On Fri, 5 Jul 2002, Matthias Andree wrote:
>
> > Are there any strong hints that TCQ caused these?
>
> only hypothesis, but vith high probability, because there were no problems
> before using TCQ. My hypothesis is that my IBM disk is oveloaded when
> using TCQ. (This is only HW problem. No TCQ ).
Well, DTLA break down without giving advance warnings. So TCQ need not
be related to this problem.
> > That's your liberty to choose. :-) (And I can understand the IBM part of
> > it.)
>
> Yes but is there any other disk which supports TCQ ?
I think all relevant SCSI drives do. Not what you intended, but I'm not
aware of any ATA disks other than IBM DPTA, DTLA, IC35L*AV*.
On 7/5/02 17:05, "Anton Altaparmakov" <[email protected]> wrote:
> You should update your firmware regardless of using TCQ because the errors
> you experienced have nothing to do with TCQ but a lot to do with buggy
> firmware. See what I found written about the firmware update on this
> webpage (Phil Randal posted this URL earlier on in this thread):
> http://www.geocities.com/dtla_update/
>
> ---snip---
> While S.M.A.R.T. offline scan running in background, a read error could
> cause a potential failure. This is corrected with current microcode.
>
> (A5AA/A6AA) will detect and prevent application specific usage patterns
> that cause excessive dwell times in particular areas.
> ---snip---
Do you or anyone happen to know if this firmware update fixes UDMA problems
with the drive (i.e. I can't use the drive on my HTP366 cause it'll lock up
the machine). I'm wondering if the firmware also addresses the issues that
caused the drive to be listed in the DMA blacklist.
Also I tried going to page earlier and wasn't able to get to it because of a
bandwidth threshold. I've since gotten through and mirrored the site to
<http://haque.net/dtla_update/>
Thanks
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix.
Don't drink and derive." --Unknown
=====================================================================
On Fri, 5 Jul 2002, Tomas Konir wrote:
>> You should update your firmware regardless of using TCQ because the errors
>> you experienced have nothing to do with TCQ but a lot to do with buggy
>> firmware. See what I found written about the firmware update on this
>> webpage (Phil Randal posted this URL earlier on in this thread):
>> http://www.geocities.com/dtla_update/
> I know this page, but firmware upgrade need windows and i have no windows
There is a disk image for Linux, too, on the same page:
http://www.geocities.com/dtla_update/dtlaupdt.tar.gz
> MOJE
// /
....................................Timo Jantunen ......................
ZZZ (Used to represent :Kuuns?de 8 A 28: Email: [email protected] :
the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti :
Webster's Encyclopedic Unabridged :Finland : GSM+358-40-5763131 :
Dictionary of the English Language :...............:....................:
On 5 Jul 2002, Daniel Egger wrote:
> This is unacceptable; if my problem is really fixable by a firmware
> upgrade IBM should have pushed this very upgrade publically after they
> started to learn about the problem. Saying "Hey, BTW: if you had this
> firmware version you would never have experienced your data loss" is
> a very strong argument to never buy any IBM hardware again.
Not so. More people would mess up the firmware upgrade and destroy drives
which were working (for them) without error than would be helped. Two old
adages apply here, "first, do no harm," and "if it ain't broken don't fix
it." I never upgrade firmware unless I have a problem or need a new
capability, new firmware can have new bugs.
> Still, the techsupport insisted on a software problem and didn't mention
> a firmware upgrade; up to now I didn't even knew such a thing exists.
> And letting customers lowlevel-format a drive, restore their data,
> and experience the same problem again a week later is anything but
> professional.
With that I *totally* agree, tech support should be on top of this.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Am Die, 2002-07-09 um 15.23 schrieb Bill Davidsen:
> Not so. More people would mess up the firmware upgrade and destroy drives
> which were working (for them) without error than would be helped. Two old
> adages apply here, "first, do no harm," and "if it ain't broken don't fix
> it." I never upgrade firmware unless I have a problem or need a new
> capability, new firmware can have new bugs.
Granted, but since the older firmware *is* known to have some radical
bugs, the chance that the new one with just this bug fixed is more buggy
than the old one is close to zero. And since this upgrade is said to be
a possible candidate to prevent most of the failures (which I doubt,
really), this would be the sensible way to go. However I do not see
how an error corrupting the drive on a S.M.A.R.T. offline test could
possibly affect a drive in a system that doesn't even have S.M.A.R.T.
software installed.
So I stand by my claim that the latest IBM drives are piss-poor in
quality and the way IBM acts is irresponsible and unacceptable.
Depending on how they replace my broken (non-OEM) drives in the next
days (or weeks) I'll be deciding whether to go to court or not. In the
meantime I'll replace all remaining IBM drives by other brands and sell
the chunk on Ebay....
--
Servus,
Daniel
Perhaps you should try:
http://www.storage.ibm.com/hdd/support/download.htm
it has a linux version.
Bill Shirley
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Tomas Konir
Sent: Friday, July 05, 2002 5:09 PM
To: Anton Altaparmakov
Cc: Matthias Andree; [email protected]
Subject: Re: IBM Desktar disk problem?
On Fri, 5 Jul 2002, Anton Altaparmakov wrote:
> >I have no broken blocks. Only two errors logged in S.M.A.R.T.
> >I have no S.M.A.R.T. errors for one year ago. And after use TCQ there
are
> >two errors after two days. Is is normal ?
> >Curently i not believe new IBM disks and TCQ. I'll wait for better
disks
> >and stable TCQ.
>
> You should update your firmware regardless of using TCQ because the
errors
> you experienced have nothing to do with TCQ but a lot to do with buggy
> firmware. See what I found written about the firmware update on this
> webpage (Phil Randal posted this URL earlier on in this thread):
> http://www.geocities.com/dtla_update/
>
I know this page, but firmware upgrade need windows and i have no
windows
and there are no windows near me. I'll try to find windows and upgrade
it.
Thanks for your advice.
> ---snip---
> While S.M.A.R.T. offline scan running in background, a read error
could
> cause a potential failure. This is corrected with current microcode.
>
> (A5AA/A6AA) will detect and prevent application specific usage
patterns
> that cause excessive dwell times in particular areas.
> ---snip---
>
> Best regards,
>
> Anton
MOJE
--
Tomas Konir
Brno
ICQ 25849167
On Wed, 10 Jul 2002, Bill Shirley wrote:
> Perhaps you should try:
> http://www.storage.ibm.com/hdd/support/download.htm
> it has a linux version.
I may be blind, but please: where do we find a firmware update at that
site?
Hi,
On Sun, 7 Jul 2002, Timo Jantunen wrote:
> > I know this page, but firmware upgrade need windows and i have no windows
>
> There is a disk image for Linux, too, on the same page:
> http://www.geocities.com/dtla_update/dtlaupdt.tar.gz
I've talked to IBM about this. They say they don't have it on their
website because some people might think they need it and trash their hard
disks because they can't upgrade and are too lazy to read the README.
They say they send you via email if you need it.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Thunder wrote:
>On Sun, 7 Jul 2002, Timo Jantunen wrote:
>> There is a disk image for Linux, too, on the same page:
>> http://www.geocities.com/dtla_update/dtlaupdt.tar.gz
>I've talked to IBM about this. They say they don't have it on their
>website because some people might think they need it and trash their hard
>disks because they can't upgrade and are too lazy to read the README.
Hmm...
http://www-1.ibm.com/support/manager.wss?rs=0&rt=0&org=psg&doc=MIGR-39082
"Aptiva / IntelliStation / NetVista / PC300 / PC300GL / PC300PL - Why
should you use the firmware update for IBM DeskStar hard disk drives?"
and
http://www-1.ibm.com/support/manager.wss?rs=0&rt=0&org=psg&doc=MIGR-38933
"IBM IntelliStation / NetVista / PC300 / PC300GL / PC300PL - PZ2Z16US -
IBM DeskStar hard disk drive firmware update"
and
http://www-1.ibm.com/support/manager.wss?rs=0&rt=0&org=psg&doc=MIGR-42215
"NetVista 2179, 2284, 6643, 6832, 6833 - PZ2Z18US - IBM DeskStar hard disk
drive firmware update"
Left hand, heard of Right hand? Although I don't know how useful these are
if you don't have an IBM computer...
--
Regards, [email protected]
My website: http://www.iain.thomas.dial.pipex.com/