Am 02/21/13 20:51, schrieb Konstantin Belousov: > On Thu, Feb 21, 2013 at 08:40:44PM +0100, O. Hartmann wrote: >> Am 02/21/13 16:28, schrieb Shawn Webb: >>> I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm >>> running ZFS as root with a mirrored root pool. >>> >>> Here's a pic of the box failing: >>> https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/AAAAAAAAGoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg >>> >>> There isn't much useful information in the pic. No crash dump is generated. >>> Where do I go from here? >>> >>> I can boot into kernel.old and that works as a workaround for now. >>> >>> Thanks, >>> >>> Shawn >> >> >> Well, I guess you faced the same problem I reported in two days ago. I >> have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use >> CLANG as the default compiler as well as setting CXXFLAGS+= >> -stdlib=libc++ >> CXXFLAGS+= -std=c++1 >> >> The working kernel on those boxes is >> >> FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 >> >> On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in >> the picture, but sometimes there is "trap 18" or "trap 16" instead of >> the cryptic signs. >> >> On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock >> characters on the screen - this box uitilizes as a server the Intel iGPU >> of the CPU. >> >> Since I use customized kernels, I tried to start with the official >> GENERIC kernel and disabling every setting in /boot/loader.conf, but the >> result is even with such a setting the same - all boxes crashes with the >> kernel sources > r246949. >> >> I also tried to enable the debugging features in the customized kernel >> (as they are enabled in the GENERIC), but there is no chance to get any >> backtrace, the kernel simply gets stuck or - on the mentioned box with >> the ivy Bridge, simply blinking funnily as a home computer in the late 80s. >> >> Sorry for being unable to report more substantial facts on that. > > The supposed fix was committed as r247117. > Simply compiling a new kernel doesn't resolve the problem. -------------------------------------------------------------- >>> Updating /usr/src using Subversion -------------------------------------------------------------- /usr/local/bin/svn update -r HEAD Updating '.': At revision 247121. This kernel crashes the same way. As it is supposed to be a gcc-change, I guess I have to recompile the whole world? Doing so by now. If not necessary to build world - then the bug is still persent - at least in my case. Regards, Oliver
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC
