Date: Wed, 9 Mar 2005 13:50:03 -0500 From: Aaron Daubman <daubman@gmail.com> To: Doug White <dwhite@gumbysoft.com> Cc: freebsd-amd64@freebsd.org Subject: Re: Consistant buildworld Segmentation fault at '===> gnu/usr.bin/cc/cpp' after latest RELENG_5 cvsup Message-ID: <ae6373410503091050456dfbd8@mail.gmail.com> In-Reply-To: <3e4aa11492a6bd41859f0490f2e94202@gumbysoft.com> References: <ae637341050309063657975c7@mail.gmail.com> <3e4aa11492a6bd41859f0490f2e94202@gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Doug,
> > ===> gnu/usr.bin/cc/cpp
> > Segmentation fault (core dumped)
> > *** Error code 139
> [...]
>
> The typical reason for segfaults is bad hardware. A v20z is a pretty
> decent server class machine, though, so unless its suffering from an
> undetected condition it should scream bloody murder if something goes
> bad. This is assuming it has ECC memory and you aren't ignoring that
> big yellow "maintenance" light that comes on when something bad
> happens, like a fan going down.
>
> Can you get into the LOM and check the environmentals?
Everything is showing up as "Nominal" status.
One note that might make a difference:
The system is a Dual Opteron - not single. I was going by dmesg
output (and since GENERIC is non-SMP...), not on what I had actually
ordered (or LOM status showed ;-).
Also, isn't segfault usually only indicative of hardware failure when
it does not reliably occur at the exact same spot?
I should mention that this box was running some fairly intensive
network management software under Windows 2003 server for a month or
so solid as well - which would make me lean away from hardware
faults...
Any suggestions as to what to change HT settings to - or if that's a
worthwhile avenue to go down?
Thanks again,
~Aaron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ae6373410503091050456dfbd8>