Re: 5.2RC1 Read+Write data corruption (with SeagateBarracuda ATA V120G (ST3120023A) + VIA 8237)

On Thu, 18 Dec 2003 15:16:04 -0800
Peter Wemm <peter_at_wemm.org> wrote:

> On Thursday 18 December 2003 05:49 am, Ion-Mihai Tetcu wrote:
> > On Thu, 18 Dec 2003 13:19:39 +0100 (CET)
> >
> > Soren Schmidt <sos_at_spider.deepcore.dk> wrote:
> > > It seems Ion-Mihai Tetcu wrote:
> > > > > Hmm, there has been some trouble with a certain model of
> > > > > Seagate 40G drives (bad firmware) so that might be something
> > > > > you could look into, otherwise I have no idea...
> > > >
> > > > Any info on that ? After all, as log as it works on win I will
> > > > have to be very convincing to change it, if that is the case.
> > >
> > > Not really, check Seagate support if an update exist for your
> > > drive?
> >
> > Hmm... I assume that the 3.33 from ad0: <ST3120023A/3.33> is the
> > firmware revision, am I right ?
> 
> We have hideous problems with this firmware version at work.  The
> older firmware revisions are ok.  The problem is much worse under 4.x
> than 5.x for us though, which makes it a bit harder to track down.
> 
> I'm pretty sure rev 3.21 is another revision that we have problems
> with. 3.19 seems to work.  So does 3.12.

;)
How I wish you have posted something about it; after all writting and
accessing 120G in PIO4 takes *a lot* of time.

BTW, did you contact Seagate about it ? Is there any way to change the
firmware on IDE Seagates ? 

> The really bizzare thing is that the corruption doesn't seem to be 
> random.  I did a fresh system install, did a cvsup, and got an 
> explosion.  The state of the fs was so bad it wasn't funny.  I nuked 
> it, reinstalled using the same CD/options/etc and did the same cvsup 
> again.  Again, boom!  The really bizzare thing is that the fsck
> carnage was almost exactly the same, if not completely identical.  The
> same block numbers were dup alloc'ed, the same directories trashed,
> etc.

I think I can confirm the "same blocks part"; but I don't know if this
happends every time. What really bothers me is that you have no chance
to know something is wrong untill a crash, when fsck wipes out you hdd.

> We've seen it on:
>   Intel ICH4 and ICH5
>   AMD 8111
>   nVidia nForce3-Pro150
>   CMD 649
>   Serverworks CSB5.

Gigabyte GA-7VT600-L (KT600/VIA 8237) / AthlonXP 2400+ / 512 DDRAM400
Mercury (KOB KT133a/VIA 82C686B) / Athlon 1000 / 256 DDRAM266
and probably 
GA-7VA-XP (KT400/VIA 8235) /  AthlonXP 2400+ / 512 DDRAM333

> Also, it was significantly worse *before* ataNG went in, and its much 
> worse on RELENG_4 than 5.x for us.
> 
> Something else just occurred to me..  I think all the problems we've 
> been seeing are on *fast* machines.  (p4/xeon/amd64).  I wonder if
> that is something significant?  I'll see if I can confirm this.

Hmm, I think you are right. I have originally used this disk on a VIA
8235 southbridge wiht a first 40G slice for winXP and the remaining
space a bsd slice. The system was very unstable (e.g. totaly freezing)
and after a crash and fsck I've had to play with the live disk to put
the standard .so back on it (I didn't looked at the right place that
time). But I've used it for about 70 days without so big problems. That
MB crashed and I've replaced it with the one with VIA 8237 and I've got
the BAD SUPERBLOCK problem for the last (g) partition. After about 2
weeks of trying to recover I've wiped out everithing and run into
problems described in my first email. Now I have BIOS setted something
it calls "Top Performance" (it seems more stable at that time) - if that
makes any diference.

Søren, I'm curious about one thing: if this is timing releated how does
it happend that the data at the begining of the hdd seems to be
acceessed OK ? The data is accessed faster that at the end so the timing
just happends to work or ?


-- 
IOnut
Unregistered ;) FreeBSD user