who broke dtrace and buildworld?
% cd /usr/src % svn update Updating '.': At revision 277307. % make buildworld === cddl/usr.sbin/dtrace (all) cc -O2 -pipe -march=core2 -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz -lutil -lrtld_db -lpthread /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idstack_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_probe' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_nextid' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_create' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_type' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_thaw' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_args Please fix. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 8:37 AM, Hans Petter Selasky h...@selasky.org wrote: On 01/14/15 15:31, Hans Petter Selasky wrote: On 01/11/15 19:08, Jason Wolfe wrote: Hans, We've had 50 machines running 10.1-STABLE with this patch for the better part of a week without issue. Prior we would have seen a panic every few days at the least, so things are looking very promising on our front. Jason Hi, I've updated D1438 including the manual page changes needed for timeout.9 aswell in addition to a minor fix for those using timeout() and untimeout() and KTR(). https://reviews.freebsd.org/D1438 --HPS FYI: Now in -current: https://svnweb.freebsd.org/changeset/base/277213 Thanks for all good comments and reviews. --HPS HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to td_slpcallout as the culprit, and HPS for your rewrite. I had heard rumors of other being affected by similar issues, so this seems like a fine candidate for an MFC if possible. Jason ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] kern/kern_timeout.c rewrite in progress
On 01/17/15 20:11, Jason Wolfe wrote: HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to td_slpcallout as the culprit, and HPS for your rewrite. I had heard rumors of other being affected by similar issues, so this seems like a fine candidate for an MFC if possible. Jason Hi Jason, I'm glad to hear that my patch has resolved your issue and I'm happy we now have a more stable system. It was actually a co-worker at work which wrote some bad code which I started debugging which then lead me to look at the callout subsystem. One bug kills the other ;-) I'm planning a MFC to 10-stable - yes, and will possibly add the _callout_stop_safe() function to not break binary compatibility with existing drivers as part of the MFC. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD-tests2 #575
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/575/ -- Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#599 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson4671036307176382476.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/scripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img vm_test Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (rodr...@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/Loading /boot/defaults/loader.conf -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|[H[J[7;46H ````[8;46Hs` `.---...--.``` -/[9;46H+o .--` /y:` +.[10;46H yo`:.:o `+-[11;46H y/ -/` -o/[12;46H .- ::/sy+:.[13;46H / `-- /[14;46H`: :`[15;46H`: :`[16;46H / /[17;46H .- -.[18;46H -- -.[19;46H `:` `:`[20;46H .-- `--.[21;46H.---..[25;0H[1;2H __ _ _ [2;2H| | | _ \ / | __ \ [3;2H| |___ _ __ ___ ___ | |_) | (___ | | | |[4;2H| ___| '__/ _ \/ _ \| _ \___ \| | | |[5;2H| | | | | __/ __/| |_) | ) | |__| |[6;2H| | | | |||| | | |[7;2H|_| |_| \___|\___||/|_/|_/ [25;0H[10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H-[22;3H-[9;2H+[22;2H+[9;44H+[22;44H+[25;0H/-\|/-\|/-\|[9;15HWelcome to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 [12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 [17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot [O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to pause[25;0H[23;4HAutoboot in 6 seconds. [Space] to pause[ 25;0H[23;4HAutoboot in 5 seconds. [Space] to pause[25;0H[23;4HAutoboot in 4 seconds. [Space] to pause[25;0H[23;4HAutoboot in 3 seconds. [Space] to pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H [25;0H/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/boot/kernel/kernel text=0x103f658 /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\Traceback (most recent call last): File /vm/freebsd-ci/scripts/test/run-tests.py, line 152, in module main(sys.argv) File /vm/freebsd-ci/scripts/test/run-tests.py, line 80, in main runTest() File /vm/freebsd-ci/scripts/test/run-tests.py, line 96, in runTest child.expect(pexpect.EOF) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1451, in expect timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1466, in expect_list timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. pexpect.spawn object at 0x803eeca50 version: 3.3 command: /usr/sbin/bhyveload args: [u'/usr/sbin/bhyveload', u'-m', u'2G', u'-d', u'/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'vm_test'] searcher: pexpect.searcher_re object at 0x803eeca10 buffer (last 100 chars): 'kernel text=0x103f658 /\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08|\x08/\x08-\x08\\\x08' before (last 100 chars): 'kernel text=0x103f658
Re: who broke dtrace and buildworld?
On Sun, Jan 18, 2015 at 01:40:09AM +, Steven Hartland wrote: % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did complete a full buildworld on what is r277300 before it was committed so no reason to think it wont complete. My laptop is running % uname -a (with some editing) FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 and I understand the a bit slower statement as it takes 5+ hours to buildworld on my laptop. Note sure if it matters, but I'm building i386 not amd64. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On Sun, Jan 18, 2015 at 02:10:19AM +, Steven Hartland wrote: On 18/01/2015 01:44, Steve Kargl wrote: On Sun, Jan 18, 2015 at 01:40:09AM +, Steven Hartland wrote: % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did complete a full buildworld on what is r277300 before it was committed so no reason to think it wont complete. My laptop is running % uname -a (with some editing) FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 and I understand the a bit slower statement as it takes 5+ hours to buildworld on my laptop. Note sure if it matters, but I'm building i386 not amd64. I just replaced my make.conf and src.conf with the ones you posted and am retested and again the build completes. tinderbox being based off universe just with error reporting so tested buildworld and buildkernel for all arch's so I can't see i386 being an issue either, but I'm testing now with TARGET=i386 just be be sure. Could you verify you don't have something stale or a bad checkout? I did all of the checking before I sent the first email (including multiple 'svn update' and 'svn status'). The tree before reverting your patch was an up-to-date head without any other patches. I use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to clean out OBJDIR. Without your patch installed everything completed as I expected (well, I did hit the MCA_system issue), and updated my system. I'm now trying to again rebuild buildworld from scratch. This is going to take awhile. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On 18/01/2015 00:22, Steve Kargl wrote: On Sat, Jan 17, 2015 at 03:54:47PM -0800, Steve Kargl wrote: % cd /usr/src % svn update Updating '.': At revision 277307. % make buildworld === cddl/usr.sbin/dtrace (all) cc -O2 -pipe -march=core2 -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz -lutil -lrtld_db -lpthread /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idstack_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_probe' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_nextid' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_create' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_type' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_thaw' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_args Please fix. To fix the build, % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did complete a full buildworld on what is r277300 before it was committed so no reason to think it wont complete. ... --- ldd32 --- cc -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/include/ -L/usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/lib32 -B/usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/lib32 -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o ldd32 ldd.o sods.o --- buildworld_epilogue --- -- World build completed on Sun Jan 18 01:31:27 UTC 2015 -- svn info |grep Revision Revision: 277307 Is anyone else seeing this issue? Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On 18/01/2015 02:35, Steve Kargl wrote: On Sun, Jan 18, 2015 at 02:10:19AM +, Steven Hartland wrote: On 18/01/2015 01:44, Steve Kargl wrote: On Sun, Jan 18, 2015 at 01:40:09AM +, Steven Hartland wrote: % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did complete a full buildworld on what is r277300 before it was committed so no reason to think it wont complete. My laptop is running % uname -a (with some editing) FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 and I understand the a bit slower statement as it takes 5+ hours to buildworld on my laptop. Note sure if it matters, but I'm building i386 not amd64. I just replaced my make.conf and src.conf with the ones you posted and am retested and again the build completes. tinderbox being based off universe just with error reporting so tested buildworld and buildkernel for all arch's so I can't see i386 being an issue either, but I'm testing now with TARGET=i386 just be be sure. Could you verify you don't have something stale or a bad checkout? I did all of the checking before I sent the first email (including multiple 'svn update' and 'svn status'). The tree before reverting your patch was an up-to-date head without any other patches. I use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to clean out OBJDIR. Without your patch installed everything completed as I expected (well, I did hit the MCA_system issue), and updated my system. I'm now trying to again rebuild buildworld from scratch. This is going to take awhile. buildworld with TARGET=i386 worked fine as did standard amd64 on head ...lsqlite3 -lz -lcrypto -lssl -lpthread --- buildworld_epilogue --- -- World build completed on Sun Jan 18 02:23:24 UTC 2015 -- ...uments -o ldd32 ldd.o sods.o --- buildworld_epilogue --- -- World build completed on Sun Jan 18 02:40:26 UTC 2015 -- Both from Revision: 277307 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On Sat, Jan 17, 2015 at 07:48:37AM -0800, David Wolfskill wrote: On Sat, Jan 17, 2015 at 04:45:04PM +0100, Hans Petter Selasky wrote: Hi, The nvidia-driver package needs to be recompiled with the latest FreeBSD-current sources, because of changes in the callout subsystem. If this is not possible, we can temporarily add the _callout_stop_safe symbol to the kernel for some transition time. ... While I'm running i386 (vs. amd64), I have not encountered the cited issue. Given the above, I suspect that the fact that I have the line: PORTS_MODULES=x11/nvidia-driver in /etc/src.conf has a fair amount of (positive) influence on that. (I track stable/10 head -- on different slices -- daily on my laptop.) Peace, david Thanks ALL! Adding the PORTS_MODULES=x11/nvidia-driver line to my /etc/src.conf file and rebuilding the kernel fixed it! Learn something new every day! :) Bob -- Bob Willcox| The Ancient Doctrine of Mind Over Matter: b...@immure.com | I don't mind... and you don't matter. Austin, TX | -- As revealed to reporter G. Rivera by Swami Havabanana ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to normal : FreeBSD_HEAD-tests2 #577
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/577/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On Sat, Jan 17, 2015 at 04:22:46PM -0800, Steve Kargl wrote: To fix the build, % svn revert -r 377300:377299 . s/revert/merge -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On Sat, Jan 17, 2015 at 03:54:47PM -0800, Steve Kargl wrote: % cd /usr/src % svn update Updating '.': At revision 277307. % make buildworld === cddl/usr.sbin/dtrace (all) cc -O2 -pipe -march=core2 -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o dtrace dtrace.o -ldtrace -ly - ll -lproc -lctf -lelf -lz -lutil -lrtld_db -lpthread /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idstack_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_probe' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_nextid' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_create' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idhash_lookup' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_type' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_thaw' /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idops_args Please fix. To fix the build, % svn revert -r 377300:377299 . -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On Sat, Jan 17, 2015 at 7:43 AM, Andreas Tobler andreast-l...@fgznet.ch wrote: On 17.01.15 16:18, Bob Willcox wrote: Yesterday when I upgraded my current box I encountered this failure when attempting to load the nvidia-driver (nvidia.so): link_elf_obj: symbol _callout_stop_safe undefined linker_load_file: Unsupported file type So, today I updtated my system again today hoping it might be fixed but the problem persists. System info: FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN amd64 I think you have to rebuild the nvidia-driver against your fresh built system. At least I had and my T510 s working again with the nvidia.ko. David W. really has it right. If you rebuild the kernel, any port installing a kernel module needs to be rebuilt, as well. The use of PORT_MODULES in /etc/src.conf is the best way to make sure it happens. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel: MCA: CPU 0 COR (1) internal parity error
On Sat, Jan 17, 2015 at 06:43:26PM +0100, Matthias Apitz wrote: El d??a Friday, January 16, 2015 a las 03:04:52PM -0500, Eric van Gyzen escribi??: On 01/16/2015 14:45, Matthias Apitz wrote: Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x904f0005 Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0c07, Status 0x Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor GenuineIntel, ID 0x40651, APIC ID 0 Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error Try ports/sysutils/mcelog. I have installed that port and launched it as # mcelog mcelog.txt ... mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors ... (the messages are STDERR); in 'mcelog.txt' it has for the last event from /var/log/messages: Jan 17 18:23:54 c720-r276659 kernel: MCA: Bank 0, Status 0x904f0005 Jan 17 18:23:54 c720-r276659 kernel: MCA: Global Cap 0x0c07, Status 0x Jan 17 18:23:54 c720-r276659 kernel: MCA: Vendor GenuineIntel, ID 0x40651, APIC ID 0 Jan 17 18:23:54 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error the following lines (the uptime matches): ... HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor MCE 32 CPU 0 BANK 0 TSC 36eec80fd688 [at 1397 Mhz 0 days 12:0:41 uptime (unreliable)] MCG status: MCi status: Error enabled MCA: Unknown Error 5 STATUS 904f0005 MCGSTATUS 0 MCGCAP c07 APICID 0 SOCKETID 0 CPUID Vendor Intel Family 6 Model 69 Questions: a) Is the output of mcelog valid (regardless of the msg on STDERR of 'unsupported model')? It may or may not be reliable. For MCE decoding to work accurately, the software (read: kernel) needs to have full support for the processor model and revision in question. mcelog simply tries to decode the output that the kernel spits out and provide a more user-friendly explanation. That isn't as simple as just modifying some table of supported CPUs; it involves reading Intel documentation and implementing what can be figured out through that. VMware has a small KB about this, to give you some insight into the complexity: http://kb.vmware.com/kb/1005184 There are some capabilities of MCA that are semi-universal across series of CPUs, so sometimes those can be decoded (mostly) accurately, but other times such isn't the case. Sometimes there are certain MCEs that have be ignored by the kernel (i.e. the kernel MCE support has to be updated to reflect changes in MCEs for that newer model of processor). The version of mcelog available in ports is extremely old, and the amount of work to upgrade it to the latest Linux mcelog (1.08) I imagine would be quite large: http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git The existing FreeBSD port involves a large number of patches written by John Baldwin, and whether or not those can be correctly backported to newer mcelog releases is unknown. I really need to renounce my maintainer flag of that port and let someone else take care of it. b) Is it worth to contact the dealer or wait until it is broken completely? To me, the above message indicates that one of the CPU cores is damaged/misbehaving. I cannot determine if it's referring to L1, L2, or L3 cache, but I don't see any clear indicator of that (possibly due to the aforementioned explanation I gave about accuracy). However, I will point you to this thread, which may indicate that the model of CPU in question (or series or models of Intel CPUs) have MCEs that happen which are considered normal and are thus not being decoded correctly: https://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255873.html I would suggest providing relevant dmesg lines about your exact processor in this system and possibly ask for help from either John Baldwin or someone on freebsd-hackers@. I myself cannot help with this. The dmesg lines I'm referring to, by the way, look like this (all of them matter, particularly the first two): CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (2833.59-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10677 Family = 0x6 Model = 0x17 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics The OP of that freebsd-questions thread should have provided this but didn't (instead just says Intel i3-4310 -- this isn't precise enough), so whether or not you two are using the same CPU is unknown. There simply could be
Re: who broke dtrace and buildworld?
On 18/01/2015 01:44, Steve Kargl wrote: On Sun, Jan 18, 2015 at 01:40:09AM +, Steven Hartland wrote: % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did complete a full buildworld on what is r277300 before it was committed so no reason to think it wont complete. My laptop is running % uname -a (with some editing) FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 and I understand the a bit slower statement as it takes 5+ hours to buildworld on my laptop. Note sure if it matters, but I'm building i386 not amd64. I just replaced my make.conf and src.conf with the ones you posted and am retested and again the build completes. tinderbox being based off universe just with error reporting so tested buildworld and buildkernel for all arch's so I can't see i386 being an issue either, but I'm testing now with TARGET=i386 just be be sure. Could you verify you don't have something stale or a bad checkout? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On Sat, Jan 17, 2015 at 09:22:06PM -0800, Kevin Oberman wrote: ... Can anyone tell me where PORTS_MODULES is documented? I don't find it in the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I thing) wrote it. This is a very beneficial tool. It really needs to be well documented. ... build(7) has it. (I confess that I didn't recall this, nor it it just magically occur to me. Rather, brute force works again: grep -Zwr PORTS_MODULES /usr/share/man/man* Ugly, perhaps, but effective. :-}) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpw45ConolGY.pgp Description: PGP signature
Re: CURRENT breaks loading of nvidia.so
Any hope to get a bit of text on this into the Handbook? Maybe with the example in Doug B.'s e-mail announcing it. (It's in the ports archive and DuckDuckGo can find it easily.) The example in build(7) is for a single module while Doug's message show that they should be space delimited. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com On Sat, Jan 17, 2015 at 9:28 PM, David Wolfskill da...@catwhisker.org wrote: On Sat, Jan 17, 2015 at 09:22:06PM -0800, Kevin Oberman wrote: ... Can anyone tell me where PORTS_MODULES is documented? I don't find it in the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I thing) wrote it. This is a very beneficial tool. It really needs to be well documented. ... build(7) has it. (I confess that I didn't recall this, nor it it just magically occur to me. Rather, brute force works again: grep -Zwr PORTS_MODULES /usr/share/man/man* Ugly, perhaps, but effective. :-}) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
I did all of the checking before I sent the first email (including multiple 'svn update' and 'svn status'). The tree before reverting your patch was an up-to-date head without any other patches. I use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to clean out OBJDIR. Without your patch installed everything completed as I expected (well, I did hit the MCA_system issue), and updated my system. I'm now trying to again rebuild buildworld from scratch. This is going to take awhile. buildworld with TARGET=i386 worked fine as did standard amd64 on head ...lsqlite3 -lz -lcrypto -lssl -lpthread --- buildworld_epilogue --- -- World build completed on Sun Jan 18 02:23:24 UTC 2015 -- ...uments -o ldd32 ldd.o sods.o --- buildworld_epilogue --- -- World build completed on Sun Jan 18 02:40:26 UTC 2015 -- Both from Revision: 277307 Must be a problem with updating from a circa early December 2014 world to 277300. My newest attempt completed as expected. Have no idea what caused th build failure, but it appears fixed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: who broke dtrace and buildworld?
On Sun, Jan 18, 2015 at 01:07:31AM +, Steven Hartland wrote: On 18/01/2015 00:23, Steve Kargl wrote: On Sat, Jan 17, 2015 at 04:22:46PM -0800, Steve Kargl wrote: To fix the build, % svn revert -r 377300:377299 . s/revert/merge Full buildworld completes here even did a tinderbox on that one, do you have anything strange in your env? Not that I know about. I have very little in /etc/make.conf and /etc/src.conf. % cat /etc/make.conf KERNCONF=MOBILE CPUTYPE?=core2 WITH_PKGNG=yes FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MAKE_JOBS_UNSAFE=yes MASTER_SITE_FREEBSD=yes % cat /etc/src.conf WITHOUT_TESTS = YES WITHOUT_CTM = YES WITHOUT_NDIS = YES WITHOUT_PROFILE = YES WITH_LLDB=yes MALLOC_PRODUCTION = YES I also start my build process with cd /usr/obj rm -rf usr cd /usr/src make buildworld Due do space limitations on my laptop prior to this attempt at buildworld, I did symlink /usr/obj to /mnt/obj where /mnt/obj is on an external USB 2.0 hard drive. Reverting your patch allows me to complete a buildworld. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On Sat, Jan 17, 2015 at 8:34 PM, Bob Willcox b...@immure.com wrote: On Sat, Jan 17, 2015 at 07:48:37AM -0800, David Wolfskill wrote: On Sat, Jan 17, 2015 at 04:45:04PM +0100, Hans Petter Selasky wrote: Hi, The nvidia-driver package needs to be recompiled with the latest FreeBSD-current sources, because of changes in the callout subsystem. If this is not possible, we can temporarily add the _callout_stop_safe symbol to the kernel for some transition time. ... While I'm running i386 (vs. amd64), I have not encountered the cited issue. Given the above, I suspect that the fact that I have the line: PORTS_MODULES=x11/nvidia-driver in /etc/src.conf has a fair amount of (positive) influence on that. (I track stable/10 head -- on different slices -- daily on my laptop.) Peace, david Thanks ALL! Adding the PORTS_MODULES=x11/nvidia-driver line to my /etc/src.conf file and rebuilding the kernel fixed it! Learn something new every day! :) Can anyone tell me where PORTS_MODULES is documented? I don't find it in the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I thing) wrote it. This is a very beneficial tool. It really needs to be well documented. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make distribution, but more than one filesystem at destination?
UPDATING from what I have read does not go into detail in the case that the destination has separate /var etc partitions. A variable to set, or procedure, or one should rsync the contents onto the filesystems after install? Experiences welcomed. Also maybe into the UPDATING file(s) [ usual one; v11 one...] ... unless it is not recommended. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[SOLVED] Re: make distribution, but more than one filesystem at destination?
On Sat, 17 Jan 2015 04:06:34 -0800 (PST), Jeffrey Bouquet jbt...@iherebuywisely.com wrote: UPDATING from what I have read does not go into detail in the case that the destination has separate /var etc partitions. A variable to set, or procedure, or one should rsync the contents onto the filesystems after install? Experiences welcomed. Also maybe into the UPDATING file(s) [ usual one; v11 one...] ... unless it is not recommended. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mount -t ufs -o union [partition not root in dev] /mnt/var#etc in DESTDIR installworld, installkernel, distribution. unmount and mount regularly the new filesystems. Seems to have produced CURRENT r277276 running fine here, but a very many haven't-done-in-years mergemaster-related not-a-direct upgrade tasks cropped up...not to mention the one or two errors (coded vt, meant to code sc in loader.conf...) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r272568 - head/sys/net
On Sun, Oct 05, 2014 at 07:43:37PM +, Hiroki Sato wrote: Author: hrs Date: Sun Oct 5 19:43:37 2014 New Revision: 272568 URL: https://svnweb.freebsd.org/changeset/base/272568 Log: Virtualize if_bridge(4) cloner. Hi, after this commit I always get a kernel panic when I stop my vnet jails. With a recent kernel this only happens when if_bridge is loaded as a module. savecore: writing core to /var/crash/vmcore.4 savecore: reboot after panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1814 dump (textdump=0) at pcpu.h:219 #1 0x802ded1e in db_dump (dummy=value optimized out, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0x802de7bd in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:449 #3 0x802de534 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0x802e0fc0 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0x8051e5f1 in kdb_trap (type=3, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x8071c2e2 in trap (frame=0xfe00980ae680) at /usr/src/sys/amd64/amd64/trap.c:542 #7 0x80700652 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0x8051dcee in kdb_enter (why=0x807e37e8 panic, msg=value optimized out) at cpufunc.h:63 #9 0x804e54e9 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:739 #10 0x804e5339 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0x804d038a in __mtx_lock_flags (c=0xfe00016ca278, opts=0, file=0x8141cb48 /usr/src/sys/modules/if_bridge/../../net/if_bridge.c, line=1814) at /usr/src/sys/kern +/kern_mutex.c:215 #12 0x8141a510 in bridge_ifdetach () from /boot/kernel/if_bridge.ko #13 0x805b1c0a in if_detach_internal (ifp=0xf80005c5, vmove=0) at /usr/src/sys/net/if.c:963 #14 0x805b188f in if_detach (ifp=0x80b98530) at /usr/src/sys/net/if.c:894 #15 0x805bdfc6 in lo_clone_destroy (ifp=0xf800059a4800) at /usr/src/sys/net/if_loop.c:117 #16 0x805b955f in if_clone_destroyif (ifc=0xf8000538a580, ifp=0x0) at /usr/src/sys/net/if_clone.c:684 #17 0x805b9e48 in if_clone_detach (ifc=value optimized out) at /usr/src/sys/net/if_clone.c:458 #18 0x805bde56 in vnet_loif_uninit (unused=value optimized out) at /usr/src/sys/net/if_loop.c:168 #19 0x805cf217 in vnet_destroy
CURRENT breaks loading of nvidia.so
Yesterday when I upgraded my current box I encountered this failure when attempting to load the nvidia-driver (nvidia.so): link_elf_obj: symbol _callout_stop_safe undefined linker_load_file: Unsupported file type So, today I updtated my system again today hoping it might be fixed but the problem persists. System info: FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN amd64 Thanks, Bob -- Bob Willcox| The Ancient Doctrine of Mind Over Matter: b...@immure.com | I don't mind... and you don't matter. Austin, TX | -- As revealed to reporter G. Rivera by Swami Havabanana ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On 01/17/15 16:18, Bob Willcox wrote: Yesterday when I upgraded my current box I encountered this failure when attempting to load the nvidia-driver (nvidia.so): link_elf_obj: symbol _callout_stop_safe undefined linker_load_file: Unsupported file type So, today I updtated my system again today hoping it might be fixed but the problem persists. System info: FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN amd64 Thanks, Bob Hi, The nvidia-driver package needs to be recompiled with the latest FreeBSD-current sources, because of changes in the callout subsystem. If this is not possible, we can temporarily add the _callout_stop_safe symbol to the kernel for some transition time. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT breaks loading of nvidia.so
On Sat, Jan 17, 2015 at 04:45:04PM +0100, Hans Petter Selasky wrote: On 01/17/15 16:18, Bob Willcox wrote: Yesterday when I upgraded my current box I encountered this failure when attempting to load the nvidia-driver (nvidia.so): link_elf_obj: symbol _callout_stop_safe undefined linker_load_file: Unsupported file type So, today I updtated my system again today hoping it might be fixed but the problem persists. System info: FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN amd64 Thanks, Bob Hi, The nvidia-driver package needs to be recompiled with the latest FreeBSD-current sources, because of changes in the callout subsystem. If this is not possible, we can temporarily add the _callout_stop_safe symbol to the kernel for some transition time. ... While I'm running i386 (vs. amd64), I have not encountered the cited issue. Given the above, I suspect that the fact that I have the line: PORTS_MODULES=x11/nvidia-driver in /etc/src.conf has a fair amount of (positive) influence on that. (I track stable/10 head -- on different slices -- daily on my laptop.) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpu5UZEWvWbm.pgp Description: PGP signature
Re: CURRENT breaks loading of nvidia.so
On 17.01.15 16:18, Bob Willcox wrote: Yesterday when I upgraded my current box I encountered this failure when attempting to load the nvidia-driver (nvidia.so): link_elf_obj: symbol _callout_stop_safe undefined linker_load_file: Unsupported file type So, today I updtated my system again today hoping it might be fixed but the problem persists. System info: FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN amd64 I think you have to rebuild the nvidia-driver against your fresh built system. At least I had and my T510 s working again with the nvidia.ko. Gruss, Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel: MCA: CPU 0 COR (1) internal parity error
El día Friday, January 16, 2015 a las 03:04:52PM -0500, Eric van Gyzen escribió: On 01/16/2015 14:45, Matthias Apitz wrote: Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x904f0005 Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0c07, Status 0x Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor GenuineIntel, ID 0x40651, APIC ID 0 Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error Try ports/sysutils/mcelog. I have installed that port and launched it as # mcelog mcelog.txt ... mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors ... (the messages are STDERR); in 'mcelog.txt' it has for the last event from /var/log/messages: Jan 17 18:23:54 c720-r276659 kernel: MCA: Bank 0, Status 0x904f0005 Jan 17 18:23:54 c720-r276659 kernel: MCA: Global Cap 0x0c07, Status 0x Jan 17 18:23:54 c720-r276659 kernel: MCA: Vendor GenuineIntel, ID 0x40651, APIC ID 0 Jan 17 18:23:54 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error the following lines (the uptime matches): ... HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor MCE 32 CPU 0 BANK 0 TSC 36eec80fd688 [at 1397 Mhz 0 days 12:0:41 uptime (unreliable)] MCG status: MCi status: Error enabled MCA: Unknown Error 5 STATUS 904f0005 MCGSTATUS 0 MCGCAP c07 APICID 0 SOCKETID 0 CPUID Vendor Intel Family 6 Model 69 Questions: a) Is the output of mcelog valid (regardless of the msg on STDERR of 'unsupported model')? b) Is it worth to contact the dealer or wait until it is broken completely? Thanks matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
