Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Jul 2003 19:32:34 -0400 (EDT)
From:      Andre Guibert de Bruet <andy@siliconlandmark.com>
To:        "Georg-W. Koltermann" <g.w.k@web.de>
Cc:        freebsd-current@freebsd.org
Subject:   Re: still data corruption with 5.1-R on Intel Pentium 4
Message-ID:  <20030723192339.B19406@alpha.siliconlandmark.com>
In-Reply-To: <1058998043.628.77.camel@bat.localnet>
References:  <1058998043.628.77.camel@bat.localnet>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 24 Jul 2003, Georg-W. Koltermann wrote:

> There have been threads about data corruption in RAM on P4 and other
> i386 machines on this list.  I also observed the problem, on my laptop
> with 5.0-R.  It seemed to go away with 5.1-R, on the laptop.
>
> Recently I upgraded my home PC which is a P4 2.0A from 4.8-R to 5.1-R.
> No problems at first.
>
> Until I ran "portsdb -Uu".  I got a couple mysterious SIG4 and SIG11.
> Just to be sure I rebooted and tried again, same result.  I rebooted
> another time, this time with ACPI disabled, and tried again, still the
> same.
>
> Then I rebuilt my kernel with options DISABLE_PSE and DISABLE_PG_G, as
> suggested by Terry in the old threads: Bingo, everything is fine now, no
> more SIG4 or SIG11 during portsdb -Uu.
>
> It seems the workarounds that we have in 5.1-R are not effective enough.
> What do you think?

DISABLE_PSE and DISABLE_PG_G fixes all of the machines that I've seen with
random segvs (And for the record, they've all been Pentium 4s).

I find it ridiculous that chip vendors require NDAs to find out about
_faults_ in the chips they've sold you. It's bad enough that these faults
made it through QA and they're not offering replacement chips, but not
allowing information about the problem to circulate so that appropriate
workarounds can be made is immoral.

My thoughts,
Andy

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/    >



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030723192339.B19406>