Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Aug 2007 22:24:22 GMT
From:      James Pfeffer <jbug@ednixon.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/115202: memory error diagnostic
Message-ID:  <200708042224.l74MOMn9010760@www.freebsd.org>
Resent-Message-ID: <200708042230.l74MU5n3065235@freefall.freebsd.org>

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

>Number:         115202
>Category:       kern
>Synopsis:       memory error diagnostic
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 04 22:30:05 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     James Pfeffer
>Release:        6.1 beta
>Organization:
>Environment:
(irrelavent)
>Description:
A memory verify mode would be helpful to diagnose flaky memory.  Maintain an
option so that the kernel can generate a table of memory checksums-per-page,
(I suggest md4, computationally light, non-cryptographic) of readonly pages.
Particularly on swap-in and swap-out, and all of memory during idle cycles
at intervals.  Log differences to /var/log/messages.

Situation:  errors on a second hard disk stop when swap space on it is
inactivated, made readonly (change fstab, reboot), then errors arise on the
primary drive.  Errors are swap errors with weird huge block numbers being
requested.  All happened out of the blue sky, machine was fine for many
months.  Changing fans to lower CPU temp was done first, did not help.

Perhaps a kernel option, such that one reboots into a second kernel with this
option enabled when problems start?
>How-To-Repeat:
Put in known bad RAM.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



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