Date: Wed, 27 Jul 2011 12:44:16 -1000 From: Tim Newsham <tim.newsham@gmail.com> To: freebsd-amd64@freebsd.org Subject: Re: page fault in kernel Message-ID: <CAGSRWbiichP9=orN4_asrbuRJ-0S8j2ic=yd-unH_npmzVt61w@mail.gmail.com> In-Reply-To: <CAGSRWbh_O1iNavv3e=PKo3s4tP9gPz4k3V80-OncUE2WoFCtEw@mail.gmail.com> References: <CAGSRWbibOcLKUOrLFx-K5ftnfO1pkTyNew5kGMdgrJ8suyU8DQ@mail.gmail.com> <CAGSRWbh_O1iNavv3e=PKo3s4tP9gPz4k3V80-OncUE2WoFCtEw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> So anyway, going to try a big overnight build to see if that has > completely resolved the issue or not. things are looking good so far. Looks like rearranging and reseating the ram addressed the problem. *phew* This is getting a little off topic, but any idea what might be wrong given how burnMMX is failing? Sounds like its at least not the primary cache. The fact that reseating or rearranging the RAM made it work makes me think that its not the secondary either. If it turns out that it happens only in specific RAM slots, then what would it most likely be? I ask because I'm wondering if replacing the CPU module would address the issue completely or if it might be something else on the motherboard. -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGSRWbiichP9=orN4_asrbuRJ-0S8j2ic=yd-unH_npmzVt61w>