Date: Fri, 19 Dec 2003 12:37:25 +0200 From: Ion-Mihai Tetcu <itetcu@apropo.ro> To: Peter Wemm <peter@wemm.org> Cc: Soren Schmidt <sos@spider.deepcore.dk> Subject: Re: 5.2RC1 Read+Write data corruption (with SeagateBarracuda ATA V120G (ST3120023A) + VIA 8237) Message-ID: <20031219123725.13e5ff2d.itetcu@apropo.ro> In-Reply-To: <200312181516.05505.peter@wemm.org> References: <20031218141159.5ec25935.itetcu@apropo.ro> <200312181219.hBICJdII069525@spider.deepcore.dk> <20031218154939.042465ce.itetcu@apropo.ro> <200312181516.05505.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Dec 2003 15:16:04 -0800 Peter Wemm <peter@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@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 ? >=20 > 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. >=20 > 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 ?=20 > The really bizzare thing is that the corruption doesn't seem to be=20 > random. I did a fresh system install, did a cvsup, and got an=20 > explosion. The state of the fs was so bad it wasn't funny. I nuked=20 > it, reinstalled using the same CD/options/etc and did the same cvsup=20 > 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=20 GA-7VA-XP (KT400/VIA 8235) / AthlonXP 2400+ / 512 DDRAM333 > Also, it was significantly worse *before* ataNG went in, and its much=20 > worse on RELENG_4 than 5.x for us. >=20 > Something else just occurred to me.. I think all the problems we've=20 > 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=F8ren, 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 ? --=20 IOnut Unregistered ;) FreeBSD user
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031219123725.13e5ff2d.itetcu>