Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Oct 2004 19:12:25 +0200
From:      Emanuel Strobl <Emanuel.Strobl@gmx.net>
To:        freebsd-current@freebsd.org
Cc:        Peter Jeremy <PeterJeremy@optushome.com.au>
Subject:   Re: 5.3-BETA7 install cd: kernel trap 12 with interrupts disabled
Message-ID:  <200410161912.26923.Emanuel.Strobl@gmx.net>
In-Reply-To: <4171059C.9070908@withagen.nl>
References:  <20041013214911.GD986@green.homeunix.org> <20041015220203.GT83620@cirb503493.alcatel.com.au> <4171059C.9070908@withagen.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart6421401.QHoA1VPTny
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Samstag, 16. Oktober 2004 13:27 schrieb Willem Jan Withagen:
> Peter Jeremy wrote:
> >On Fri, 2004-Oct-15 14:35:47 +0200, Guido van Rooij wrote:
> >>A make buildworld cannot be used in sich a scenario. A nice memtester
> >>that could be called from the bootloader would have been handy.
> >
> >http://www.memtest86.com/memtest86-3.1a.iso.gz
> >
> >I'm not sure how much effort would be involved in making memtest[86]
> >in a form that could be loaded by the bootloader.
>
> I'd be willing to do the work, but somebody needs to hold my hand in
> finding a place and way to get it early enough in the kernel. The
> memtest algorithms in themselves are not all that complex to program.
[...]
> Another valid remark was made about the environment. temperature and
> power are also very influential factors for holding electrons in memory
> cells. And these are hard/impossible to influence whilest running the
> tests.

Guys, I'd really love to see this great feature!!!
I'm no hacker but due to my past I know something of memory and I always li=
ked=20
the ASUS jumper which sets memory voltage between 3v3 and 3v6, with 3v4 as=
=20
default. Perhaps you could add a comment that reducing the voltage to 3v3 o=
n=20
ASUS boards will expose failures more likely.

Thanks,

=2DHarry

> An also important item for memory failure is refresh timing. It could be
> that the memory as such is correct, but that too much leakage causes
> bits to fall too fast. To detect this it requires that whole rows of the
> memory are not touched by either read or write for the duration of the
> refresh period. All in all again not very simple without knowing the
> memory architecture.
>
> These arguments have for me always been the reason, not to try implement
> a memory tester. Especially since most people using this will not be
> aware of  limitted relevance of the tests they are running.
>
> But like I said, give me some pointers on how to plug it into the
> kernel, and I'll get going on this.
>
> --WjW
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

--nextPart6421401.QHoA1VPTny
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQBBcVZ6Bylq0S4AzzwRAhfyAJwMAgwUzPngYRH3Nsl200V7uNNtOwCfdd0T
ON5dTLD5JS61eyTZBg8LrD4=
=do8r
-----END PGP SIGNATURE-----

--nextPart6421401.QHoA1VPTny--



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