Build failed in Jenkins: FreeBSD_HEAD-tests2 #158
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/158/ -- Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#153 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson4396968245292862072.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. [S pace] 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=0x10031e8 \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
Re: VT: NOT giving extended console
On 31.10.2014 04:16, Larry Rosenman wrote: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. link_elf_obj: symbol ttm_agp_tt_create undefined KLD file radeonkms.ko - could not finalize loading Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On Fri, 31 Oct 2014 11:35:00 +0100 Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr wrote: On 31.10.2014 04:16, Larry Rosenman wrote: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #4 r273876: Thu Oct 30 21:44:26 CDT 2014 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. link_elf_obj: symbol ttm_agp_tt_create undefined KLD file radeonkms.ko - could not finalize loading Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) Done in r273902. ___ 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: VT: NOT giving extended console
On 31.10.2014 11:46, Tijl Coosemans wrote: Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) Done in r273902. Thanks :) And thank you very much for adding AGP support! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Build failed in Jenkins: FreeBSD_HEAD-tests2 #159
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/159/ -- Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#154 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson6275656759345592008.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. [S pace] 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=0x10031e8 -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
Re: VT: NOT giving extended console
On Fri, Oct 31, 2014 at 11:48:03AM +0100, Jean-S?bastien P?dron wrote: On 31.10.2014 11:46, Tijl Coosemans wrote: Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) Done in r273902. Thanks :) And thank you very much for adding AGP support! -- Jean-S?bastien P?dron [repost to list, sorry Jean-Sebastien]: Thanks, now I get a constant stream of: Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:25 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:25 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:26 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:26 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:36 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:36 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:47 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:47 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:53:57 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:53:57 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:07 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:07 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:18 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:18 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:28 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:28 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:38 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:38 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:49 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:49 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:54:59 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:54:59 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:09 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:09 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:19 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:19 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:30 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:30 borg kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Oct 31 06:55:40 borg kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. Oct 31 06:55:40 borg kernel: error:
Unclean shutdown for r273852 - r273899 transition
I thought it a bit odd when I rebooted after the make installworld completed and found that fsck(8) was checking teh file systems on my laptop. When it also happened for my build machine, I suspected it might not merely be a one-off oddity... and I was able to make use of the serial console on the build machine. THe laptop started out running: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1412 r273852M/273852:1100040: Thu Oct 30 05:25:51 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 this morning; I performed an in-place source upgrade to: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1413 r273899M/273900:1100041: Fri Oct 31 06:01:13 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Here's what things looked like on the cosnole for the build machine (which had been built from sources at the same revisions): Oct 31 06:40:09 freebeast shutdown: reboot by david: Stopping cron. Waiting for PIDS: 723. Stopping sshd. Waiting for PIDS: 713. Stopping rsyncd. Waiting for PIDS: 686. Stopping powerd. Waiting for PIDS: 671. Stopping ntpd. Waiting for PIDS: 668. Stopping lpd. Waiting for PIDS: 647. Stopping lockd. Waiting for PIDS: 630. Stopping statd. Waiting for PIDS: 627. Stopping nfsd. Waiting for PIDS: 623 624. Stopping mountd. Waiting for PIDS: 617. Stopping casperd. Waiting for PIDS: 595. Stopping amd. Waiting for PIDS: 587. Stopping ypbind. Waiting for PIDS: 582. Stopping rpcbind. Waiting for PIDS: 491. Stopping devd. Waiting for PIDS: 407. Writing entropy file:. . TermiOct 31 06:40:14 freebeast syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...5 6 6 6 6 4 4 4 4 4 3 1 1 1 1 1 1 1 1 0 0 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. lock order reversal: 1st 0xc7925388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 2nd 0xc7a7a7f8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper(c11ac524,c6da28c8,c156af90,c156afa4,e1fb9890,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9828 kdb_backtrace(c11b00a9,c7a7a7f8,c11a2e94,c6daa3e0,c11e2149,...) at kdb_backtrace+0x30/frame 0xe1fb9890 witness_checkorder(c7a7a7f8,9,c11e2149,55f,0,...) at witness_checkorder+0xd0c/frame 0xe1fb98e0 __lockmgr_args(c7a7a7f8,80400,c7a7a818,0,0,0,c11e2149,55f) at __lockmgr_args+0x8f3/frame 0xe1fb99bc vop_stdlock(e1fb9a30,c11e2149,63d,1244,c7a7a838,...) at vop_stdlock+0x4d/frame 0xe1fb99ec VOP_LOCK1_APV(c140ddac,e1fb9a30,0,0,c145ac60,...) at VOP_LOCK1_APV+0x10a/frame 0 __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ \___ \| | | | | | | | | __/ __/| |_) |) | |__| | | | | | |||| | | | |_| |_| \___|\___||/|_/|_/```` s` `.---...--.``` -/ ... (The stack bactrace is obviously truncated.) ... Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1651 r273899M/273900:1100041: Fri Oct 31 06:31:31 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) Origin=GenuineIntel Id=0xf41 Family=0xf Model=0x4 Stepping=1 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=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR AMD Features=0x2010NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2077032448 (1980 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 random device not loaded/active; using insecure pseudo-random number generator ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow ... SMP: AP CPU #1 Launched! Timecounter TSC-low frequency
Build failed in Jenkins: FreeBSD_HEAD-tests2 #160
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/160/ -- Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#155 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson2662489205289567898.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. [S pace] 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=0x10031e8 |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
Re: VT: NOT giving extended console
On 31.10.2014 12:59, Larry Rosenman wrote: Thanks, now I get a constant stream of: kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Yeah, the driver reprobe any output connectors every 10 by default. I think there's a setting to tune how/when connectors are probed but we don't expose it currently. Feel free to comment those messages, they are in: o sys/dev/drm2/drm_edid.c o sys/dev/drm2/radeon/radeon_connectors.c -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ ___ 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Oct 31, 2014, at 10:04, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ Hi Craig, I have a potential fix for this on my github branch (I ATFified the testcase and fixed some broken assumptions; I'll find the PR later). Now that boot is fixed on head I can upgrade, and will see about testing out the fix. If I don't get to it today, I'll look at fixing it when I'm down at MeetBSD. Thank you, ___ 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
NVidia Tesla K40
Hello! I want to use NVidia Tesla K40 GPU for parallel computing.Does FreeBSD support such a hardware? Thanks a lot! ___ 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: NVidia Tesla K40
Am Fri, 31 Oct 2014 16:46:15 + (UTC) John Dison jdiso...@yahoo.com schrieb: Hello! I want to use NVidia Tesla K40 GPU for parallel computing.Does FreeBSD support such a hardware? Thanks a lot! ___ 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 You're out of luck. No, FreeBSD doesn't support GPGPU computing on modern graphics hardware. Since 2009 we try to utilize FreeBSD for such a purpose, especially with the use of OpenCL for high performance computing. Around 2010 there was the glimpse of a dawn with Pathscale, offering a OpenACC-precursor with their compiler infrastructure, supposed to be capable of utilizing FreeBSD and nVidia GPUs (that time Tesla) with Pathscale-libraries (I forgot the name, it's CAPS or something like that) but at the end it revealed its self as a heap of unfinished, unmature code and by now the company or ist successor doen't even provide a commercial product for FreeBSD - the project died! It is even worse: FreeBSD ports dropped Nouveau! There are effords bringing libclc, the new Mesa library, Glover and OpenCL in combination with LLVM 3.4/3.5 together to provide OpenCL and via LLVM the nVidia PTX backend, but as far as I know this work is still under development and immature and FreeBSD is no longer part of the scene due to the drop of the Nouveau driver (I was told FreeBSD lacks important kernel features known for years for KMS). CUDA is completely out of view: nVidia doesn't provide support for FreeBSD. nVidia fellows claim there is no need/request from FreeBSD people. I believe it is simply ignorance and a stupid political issue, made years ago, that we suffer from by now. The situation with open source AMD driver (radeonSI) is unknown to me. We made very bad experiences with AMD hardware in the era of the AMD HD46XX/47XX and HD48XX chipsets and the development is/was behind the recent chips available on market. On Linux there were reports of successfully running OpenCL kernels on the radeonSI drivers with Glover/Mesa and other mandatory software not available for FreeBSD - the FreeBSD X11 base system is also methusalem and behind the recent development. If you would go with AMD, you would have to stay with open source since AMD doens't provide BLOBs for their GPUs for FreeBSD. For Linux, the AMD OpenCL SDK is very nice, their hardware is pretty fast ( nVidia!) while their driver tend to crash. But as said, Linux only. With nVidia you get a pretty fast and nice BLOB for all FreeBSDs and modern GPUs from nVidia, but there is no OpenCL backend lib (or CUDA). Either way, it is a dead end with FreeBSD. There was also once a setup with the FreeBSD Linuxulator - but this is 32bit only and a no go for serious scientific compuations. We also tried this with more modern FreeBSDs (8.X, 9.X, 10-CURRENT that time), but with CUDA 4 you're out of luck. And FreeBSD doesn't have a 64bit support in the Linuxulator. And why running a Linuxulator? If you really plan to use a beast like K40, consider dropping FreeBSD and using Linux! We started with Ubuntu and OpenSuse that time. At the first moment the shock is heavy, but you'll come along with Linux very soon. The only bad thing is the missing ZFS support as someone might be used to in FreeBSD but this is also only a question of time (more short than long!). Linux development is pretty fast these days, support is excellent and Linux suffers from bad karma from the days of the Linux 2.4 kernel. That has changed dramatically. A department developing security facilities is now dropping OpenBSD in favour of Debian Linux, even OpenBSD is still considered more bullet proof. But the decision was made due to a dramatic driver issue - I mention this here because also FreeBSD seems to suffer increasingly (compared to to Linux) from driver issues for high performance equipment (special interlink adaptors, WiFi NICs and even the GPU issue!). I'm very sad having no better experience to tell. oh pgpiAVMAsCSDT.pgp Description: OpenPGP digital signature
r273910 build failure if sys/_umtx.h is out-of-date
Hi! I have the following error when building HEAD: ---8--- cc -O2 -pipe -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/include -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64 -DNLS -fexceptions -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/gdtoa -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../libmd -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/tzcode/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/locale -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cancelpoints_sem_new.c -o cancelpoints_sem_new.o In file included from cancelpoints_sem_new.c:47: /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include/semaphore.h:41: error: field '_kern' has incomplete type cancelpoints_sem_new.c:66: error: 'USEM_MAX_COUNT' undeclared here (not in a function) cc1: warnings being treated as errors cancelpoints_sem_new.c: In function '_sem_getvalue': cancelpoints_sem_new.c:335: warning: implicit declaration of function 'USEM_COUNT' cancelpoints_sem_new.c: In function 'usem_wake': cancelpoints_sem_new.c:342: error: 'UMTX_OP_SEM2_WAKE' undeclared (first use in this function) cancelpoints_sem_new.c:342: error: (Each undeclared identifier is reported only once cancelpoints_sem_new.c:342: error: for each function it appears in.) cancelpoints_sem_new.c: In function 'usem_wait': cancelpoints_sem_new.c:361: error: 'UMTX_OP_SEM2_WAIT' undeclared (first use in this function) cancelpoints_sem_new.c: In function '_sem_post': cancelpoints_sem_new.c:445: error: 'USEM_HAS_WAITERS' undeclared (first use in this function) *** Error code 1 Stop. make[4]: stopped in /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc *** Error code 1 ---8--- The problem is that the installed version of sys/_umtx.h is out-of-date compared to the version in the source tree. I guess it's supposed to pick the version in the source tree, but I'm not sure what's the correct way of doing this. FYI, this is with base gcc on sparc64. World was updated on August 6. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver pgpq78x9cSl2E.pgp Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On 2014-10-31 11:58, Jean-Sébastien Pédron wrote: On 31.10.2014 12:59, Larry Rosenman wrote: Thanks, now I get a constant stream of: kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 invalid. kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID Yeah, the driver reprobe any output connectors every 10 by default. I think there's a setting to tune how/when connectors are probed but we don't expose it currently. Feel free to comment those messages, they are in: o sys/dev/drm2/drm_edid.c o sys/dev/drm2/radeon/radeon_connectors.c I think we had this before, and someone(I forget who) shut it up.. I really think it's the PROJECTS responsibility to shut this up, as I'm sure I won't be the only one whining... Can we at least lower it to DEBUG so it doesn't spam /var/log/messages and the console? or put it behind BOOTVERBOSE? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: Unclean shutdown for r273852 - r273899 transition
Am Fri, 31 Oct 2014 06:59:12 -0700 David Wolfskill da...@catwhisker.org schrieb: I thought it a bit odd when I rebooted after the make installworld completed and found that fsck(8) was checking teh file systems on my laptop. When it also happened for my build machine, I suspected it might not merely be a one-off oddity... and I was able to make use of the serial console on the build machine. THe laptop started out running: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1412 r273852M/273852:1100040: Thu Oct 30 05:25:51 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 this morning; I performed an in-place source upgrade to: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1413 r273899M/273900:1100041: Fri Oct 31 06:01:13 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Here's what things looked like on the cosnole for the build machine (which had been built from sources at the same revisions): Oct 31 06:40:09 freebeast shutdown: reboot by david: Stopping cron. Waiting for PIDS: 723. Stopping sshd. Waiting for PIDS: 713. Stopping rsyncd. Waiting for PIDS: 686. Stopping powerd. Waiting for PIDS: 671. Stopping ntpd. Waiting for PIDS: 668. Stopping lpd. Waiting for PIDS: 647. Stopping lockd. Waiting for PIDS: 630. Stopping statd. Waiting for PIDS: 627. Stopping nfsd. Waiting for PIDS: 623 624. Stopping mountd. Waiting for PIDS: 617. Stopping casperd. Waiting for PIDS: 595. Stopping amd. Waiting for PIDS: 587. Stopping ypbind. Waiting for PIDS: 582. Stopping rpcbind. Waiting for PIDS: 491. Stopping devd. Waiting for PIDS: 407. Writing entropy file:. . TermiOct 31 06:40:14 freebeast syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...5 6 6 6 6 4 4 4 4 4 3 1 1 1 1 1 1 1 1 0 0 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. lock order reversal: 1st 0xc7925388 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1223 2nd 0xc7a7a7f8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace: db_trace_self_wrapper(c11ac524,c6da28c8,c156af90,c156afa4,e1fb9890,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9828 kdb_backtrace(c11b00a9,c7a7a7f8,c11a2e94,c6daa3e0,c11e2149,...) at kdb_backtrace+0x30/frame 0xe1fb9890 witness_checkorder(c7a7a7f8,9,c11e2149,55f,0,...) at witness_checkorder+0xd0c/frame 0xe1fb98e0 __lockmgr_args(c7a7a7f8,80400,c7a7a818,0,0,0,c11e2149,55f) at __lockmgr_args+0x8f3/frame 0xe1fb99bc vop_stdlock(e1fb9a30,c11e2149,63d,1244,c7a7a838,...) at vop_stdlock+0x4d/frame 0xe1fb99ec VOP_LOCK1_APV(c140ddac,e1fb9a30,0,0,c145ac60,...) at VOP_LOCK1_APV+0x10a/frame 0 __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ \___ \| | | | | | | | | __/ __/| |_) |) | |__| | | | | | |||| | | | |_| |_| \___|\___||/|_/|_/ ```` s` `.---...--.``` -/ ... (The stack bactrace is obviously truncated.) ... Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1651 r273899M/273900:1100041: Fri Oct 31 06:31:31 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) Origin=GenuineIntel Id=0xf41 Family=0xf Model=0x4 Stepping=1 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=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR AMD Features=0x2010NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2077032448 (1980 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 random device not loaded/active; using insecure pseudo-random number generator ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random:
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
At 12:20 PM 10/31/2014, O. Hartmann wrote: On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver With r273911 on amd64, after fresh build installworld. Upon reboot all of a sudden /var is mounted mfs. needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc I had to change the following in rc.conf to get system to work again. varmfs=AUTO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=AUTO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=YES# Clean the /var directory CHANGED TO : varmfs=NO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=NO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=NO# Clean the /var directory Not why all of a sudden /var/ was mounted mfs. Maybe something to do with the new random stuff, I did a mergemaster before rebooting Not sure if this is related to your problem Manfred || n...@pozo.com || || || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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
r273918 buildworld broke at semaphore
First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/r273918-buildworld-broke-at-semaphore-tp5961241.html Sent from the freebsd-current mailing list archive at Nabble.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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #162
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/162/ ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31.10.2014 21:35, Martin MATO a écrit : Le 31.10.2014 21:00, Manfred Antar a écrit : At 12:20 PM 10/31/2014, O. Hartmann wrote: On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption after reboot. The systems do have FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 and suffer without exception from the same breakage, quitting services and/or reporting corrupted filesystems after a fresh reboot - even if I've performed a manual triggered fsck -fz in single user mode on the console. All systems have GPT partion schemes. The problem is serious! I can not get rid via fsck of the problem of corrupted filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start properly and need to be started manually after a reboot. What is wrong? The fact that several CURRENT boxes are affected the very same way ( 5 ) make me confident this is a serious bug recently introduced. Oliver With r273911 on amd64, after fresh build installworld. Upon reboot all of a sudden /var is mounted mfs. needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc I had to change the following in rc.conf to get system to work again. varmfs=AUTO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=AUTO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=YES# Clean the /var directory CHANGED TO : varmfs=NO # Set to YES to always create an mfs /var, NO to never varsize=32m # Size of mfs /var if created varmfs_flags=-S # Extra mount options for the mfs /var populate_var=NO # Set to YES to always (re)populate /var, NO to never cleanvar_enable=NO# Clean the /var directory Not why all of a sudden /var/ was mounted mfs. Maybe something to do with the new random stuff, I did a mergemaster before rebooting Not sure if this is related to your problem Manfred || n...@pozo.com || || || Same things here. It appears that the ld-elf.so.hints files are not generated ( ldconfig not executed at boot); well at least in my case. executing manually a 'service ldconfig start' generate them. ___ 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: r273910 build failure if sys/_umtx.h is out-of-date
Hi dumbbell@! On Oct 31, 2014, at 11:55, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: Hi! I have the following error when building HEAD: … The problem is that the installed version of sys/_umtx.h is out-of-date compared to the version in the source tree. I guess it's supposed to pick the version in the source tree, but I'm not sure what's the correct way of doing this. FYI, this is with base gcc on sparc64. World was updated on August 6. Beeblebrox sent out the same thing in the thread titled r273918 buildworld broke at semaphore”. My guess is that it’s this bug that I filed a while ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192394 , but Beeblebrox should confirm whether or not he’s using gcc in the build or clang. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r273910 build failure if sys/_umtx.h is out-of-date
Hello Beeblebrox should confirm whether or not he’s using gcc in the build or clang. Thanks! Using clang I have some tighter settings in src.conf, but nothing clang/gcc related. -- FreeBSD_amd64_11-Current_RadeonKMS ___ 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: r273910 build failure if sys/_umtx.h is out-of-date
On Oct 31, 2014, at 14:00, Beeblebrox zap...@berentweb.com wrote: Hello Beeblebrox should confirm whether or not he’s using gcc in the build or clang. Thanks! Using clang I have some tighter settings in src.conf, but nothing clang/gcc related. Hi! Do you have WITHOUT_CLANG_BOOTSTRAP set? Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r273910 build failure if sys/_umtx.h is out-of-date
Hi! Do you have WITHOUT_CLANG_BOOTSTRAP set? Thanks! No. No clang/gcc settings. All src.conf WITHOUT entries are of the sort INET6, PORTSNAP, BLUETOOTH, etc I DO use ccache -- FreeBSD_amd64_11-Current_RadeonKMS ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On 31.10.14 22:23, Dag-Erling Smørgrav wrote: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. +1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. [zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT @(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 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: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
At 02:44 PM 10/31/2014, Andreas Tobler wrote: On 31.10.14 22:23, Dag-Erling Smørgrav wrote: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. +1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs. [zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT @(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014 Andreas FreeBSD 11.0-CURRENT #0 r273905: Fri Oct 31 06:15:56 PDT 2014 11.0-CURRENT No corruption here, during the last few days i was getting sysctl-random error during boot. So today I did a buildworld installworld buildkernel installkernel, and mergemaster . some of the /etc/rc.d/random files were updated. Reboot Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. I noticed one thing during boot: Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. || n...@pozo.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: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ 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 the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. find /usr/tests/ /usr/tests/ /usr/tests/bin /usr/tests/bin/chown /usr/tests/bin/chown/chown-f_test /usr/tests/bin/chown/Kyuafile /usr/tests/bin/date /usr/tests/bin/date/Kyuafile /usr/tests/bin/date/format_string_test /usr/tests/bin/mv /usr/tests/bin/mv/legacy_test /usr/tests/bin/mv/Kyuafile /usr/tests/bin/pax /usr/tests/bin/pax/legacy_test /usr/tests/bin/pax/Kyuafile /usr/tests/bin/pkill /usr/tests/bin/pkill/pgrep-F_test /usr/tests/bin/pkill/pgrep-LF_test /usr/tests/bin/pkill/pgrep-P_test /usr/tests/bin/pkill/pgrep-U_test /usr/tests/bin/pkill/pgrep-_g_test /usr/tests/bin/pkill/pgrep-_s_test /usr/tests/bin/pkill/pgrep-g_test /usr/tests/bin/pkill/pgrep-i_test /usr/tests/bin/pkill/pgrep-j_test /usr/tests/bin/pkill/pgrep-l_test /usr/tests/bin/pkill/pgrep-n_test /usr/tests/bin/pkill/pgrep-o_test /usr/tests/bin/pkill/pgrep-q_test /usr/tests/bin/pkill/pgrep-s_test /usr/tests/bin/pkill/pgrep-t_test /usr/tests/bin/pkill/pgrep-v_test /usr/tests/bin/pkill/pgrep-x_test /usr/tests/bin/pkill/pkill-F_test /usr/tests/bin/pkill/pkill-LF_test /usr/tests/bin/pkill/pkill-P_test /usr/tests/bin/pkill/pkill-U_test /usr/tests/bin/pkill/pkill-_g_test /usr/tests/bin/pkill/pkill-g_test /usr/tests/bin/pkill/pkill-i_test /usr/tests/bin/pkill/pkill-j_test /usr/tests/bin/pkill/pkill-s_test /usr/tests/bin/pkill/pkill-t_test /usr/tests/bin/pkill/pkill-x_test /usr/tests/bin/pkill/Kyuafile /usr/tests/bin/sh /usr/tests/bin/sh/builtins /usr/tests/bin/sh/builtins/alias.0 /usr/tests/bin/sh/builtins/alias.0.stdout /usr/tests/bin/sh/builtins/alias.1 /usr/tests/bin/sh/builtins/alias.1.stderr /usr/tests/bin/sh/builtins/alias3.0 /usr/tests/bin/sh/builtins/alias3.0.stdout /usr/tests/bin/sh/builtins/alias4.0 /usr/tests/bin/sh/builtins/break1.0 /usr/tests/bin/sh/builtins/break2.0 /usr/tests/bin/sh/builtins/break2.0.stdout /usr/tests/bin/sh/builtins/break3.0 /usr/tests/bin/sh/builtins/break4.4 /usr/tests/bin/sh/builtins/break5.4 /usr/tests/bin/sh/builtins/break6.0 /usr/tests/bin/sh/builtins/builtin1.0 /usr/tests/bin/sh/builtins/case1.0 /usr/tests/bin/sh/builtins/case2.0 /usr/tests/bin/sh/builtins/case3.0 /usr/tests/bin/sh/builtins/case4.0 /usr/tests/bin/sh/builtins/case5.0 /usr/tests/bin/sh/builtins/case6.0 /usr/tests/bin/sh/builtins/case7.0 /usr/tests/bin/sh/builtins/case8.0 /usr/tests/bin/sh/builtins/case9.0 /usr/tests/bin/sh/builtins/case10.0 /usr/tests/bin/sh/builtins/cd1.0 /usr/tests/bin/sh/builtins/case11.0 /usr/tests/bin/sh/builtins/case12.0 /usr/tests/bin/sh/builtins/case13.0 /usr/tests/bin/sh/builtins/case14.0 /usr/tests/bin/sh/builtins/case15.0 /usr/tests/bin/sh/builtins/case16.0 /usr/tests/bin/sh/builtins/case17.0 /usr/tests/bin/sh/builtins/case18.0 /usr/tests/bin/sh/builtins/case19.0 /usr/tests/bin/sh/builtins/cd2.0 /usr/tests/bin/sh/builtins/cd3.0 /usr/tests/bin/sh/builtins/cd4.0 /usr/tests/bin/sh/builtins/cd5.0 /usr/tests/bin/sh/builtins/cd6.0 /usr/tests/bin/sh/builtins/cd7.0 /usr/tests/bin/sh/builtins/cd8.0 /usr/tests/bin/sh/builtins/command1.0 /usr/tests/bin/sh/builtins/command2.0 /usr/tests/bin/sh/builtins/command3.0 /usr/tests/bin/sh/builtins/command3.0.stdout /usr/tests/bin/sh/builtins/command4.0 /usr/tests/bin/sh/builtins/command5.0 /usr/tests/bin/sh/builtins/command5.0.stdout /usr/tests/bin/sh/builtins/command6.0 /usr/tests/bin/sh/builtins/command6.0.stdout /usr/tests/bin/sh/builtins/dot1.0 /usr/tests/bin/sh/builtins/command7.0 /usr/tests/bin/sh/builtins/command8.0 /usr/tests/bin/sh/builtins/command9.0 /usr/tests/bin/sh/builtins/command10.0 /usr/tests/bin/sh/builtins/command11.0 /usr/tests/bin/sh/builtins/command12.0 /usr/tests/bin/sh/builtins/dot2.0 /usr/tests/bin/sh/builtins/dot3.0 /usr/tests/bin/sh/builtins/dot4.0 /usr/tests/bin/sh/builtins/eval1.0 /usr/tests/bin/sh/builtins/eval2.0 /usr/tests/bin/sh/builtins/eval3.0 /usr/tests/bin/sh/builtins/eval4.0 /usr/tests/bin/sh/builtins/eval5.0 /usr/tests/bin/sh/builtins/eval6.0 /usr/tests/bin/sh/builtins/exec1.0 /usr/tests/bin/sh/builtins/exec2.0 /usr/tests/bin/sh/builtins/exit1.0
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The problem should have been corrected by r273919. Please update your system and update /etc/ with mergemaster. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUVBaIAAoJEJW2GBstM+nsDHIP/jEgsdtn8ZWbwSHCh8RBXhM7 rr7wdRXcti0h8G0htXTaWWrEaJ1Y7LKGVBjqrUqTJU/g7mRha/p2BrEsYMGBwFbT uqPDYIiHvfVIDH6wAO5qi1CvPG8UhsGG3IV+RXEazeBFlNUA50ZRhyhYtvuywoWw 9izOCtc1y3pEuR3i7Ybpors6oulyYWIpd/tuafkVWmhrLblvCLNv6wrmwxAcXtNN UC92bvH320nqA49AC1jAD0zrZ5uc6fPBgcSXi1SZvmnuxnODRrV/O0yD67fUHKtm 59x7woa4tMaVNtP+eQ2QSZv75oko5HmZqfAV4urTQjfb44wDj42uFOKN8WHmMNbe RxZ/b7dhbU9BMKhnf117IIg2P96o2Hj9jwBN6+PaPoPw2UGSgiJf7/bf3RnEZCoM TISlyv3fAvbNg7yuGAZsm8onjUPIfjlriOUhUeiKzNDhQDRW8eKWDPEio8IapyJW wYLtNPjARYUfIswAVMRn5NuNzjqloPKLjXf2YOtREb/c3K1UZMRLTc98zPhJ7za+ 6EzIe/CuY7X55ajwK8Fqmqh/G3TiaSomwiVzZrtl2ggdeXsMsWfeaV0E9gtspVwb Qaprmo1Qx/vZUhHPy8L/OHqvCF39z4RC4N/4ryc7gt5gpW9jkeWzyYvGD/wCdV7b bHxbVZR+Ukuz2B4aUFH5 =J3ap -END PGP SIGNATURE- ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Am Fri, 31 Oct 2014 22:23:28 +0100 Dag-Erling Smørgrav d...@des.no schrieb: Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES r273800 was the last (obviously) working on one box, r273872 seems to have the problem: /var/log/messages:Oct 30 05:53:45 0.2 gate kernel: FreeBSD 11.0-CURRENT #0 r273800: Tue Oct 28 21:24:08 CET 2014 /var/log/messages:Oct 31 05:32:25 0.2 gate kernel: FreeBSD 11.0-CURRENT #1 r273872: Thu Oct 30 22:32:59 CET 2014 /var/log/messages:Oct 31 19:59:55 0.2 gate kernel: FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 r273746: Mon Oct 27 21:43:42 CET 2014 is the one I'm sure it worked flawless. I did the past two days daily builds. pgpp1KfU39tUM.pgp Description: OpenPGP digital signature
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #163
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/163/ ___ 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Oct 31, 2014, at 10:12, Garrett Cooper yaneurab...@gmail.com wrote: On Oct 31, 2014, at 10:04, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ Hi Craig, I have a potential fix for this on my github branch (I ATFified the testcase and fixed some broken assumptions; I'll find the PR later). Now that boot is fixed on head I can upgrade, and will see about testing out the fix. If I don't get to it today, I'll look at fixing it when I'm down at MeetBSD. Thank you, Given the discussion on one of the FreeBSD IRC channels about /dev/md0 being mounted at boot due to potential fallout from the random(4) rewrite (until r273919, potentially…), this is probably a symptom of this PR I filed a while back: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191191 . I'll take ownership in getting the fix in this weekend/early next week. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Oct 31, 2014, at 15:35, Martin MATO martin.m...@orange.fr wrote: Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ... the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? MK_TESTS has been yes by default for some time. This isn’t unexpected… I did however fix a faux pas I accidentally introduced in r273803 in r273810, which may have resulted in more files being installed under /usr/tests . the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. Cheers! -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Le 31/10/2014 23:35, Martin MATO a écrit : Le 31/10/2014 22:50, Martin MATO a écrit : Le 31/10/2014 22:23, Dag-Erling Smørgrav a écrit : Can you all please tell me which revision(s) you were running before you upgraded? Something like bzgrep 11.0-CURRENT /var/log/messages* should do the trick. DES Absolutely here it is /var/log/messages:Oct 31 12:11:05 kernel: FreeBSD 11.0-CURRENT #0 r273863: Thu Oct 30 16:55:16 CET 2014 ps: there is no filesystem corruption (first thing i checked twice.) ___ 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 the is one thing i noticed: there is a new directory under /usr called tests containing several directories and files maybe something goes wrong in the 'make installworld' part ? the timestamps are more or less when i tried to upgrade world. i'm reverting back to 273863 to see if i get a system functionnal. find /usr/tests/ /usr/tests/ /usr/tests/bin /usr/tests/bin/chown ... snip... ___ 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 Reverted back userland AND kernel to r273863 and all things working as before for me. otherwise keeping the last revision kernel and reverting back the operating system to r273863 results in crashes, coredumps and filesystem corruption. ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
O. Hartmann ohart...@zedat.fu-berlin.de writes: r273800 was the last (obviously) working on one box, r273872 seems to have the problem: Are you sure? If I understand Manfred correctly, r273905 was running fine for him. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
Manfred Antar n...@pozo.com writes: Then for some reason /var started to being mounted mfs. so for me i think it has something to do with the new rc.d startup files. If I have varmfs=NO and cleanvar_enable=NO everything works fine. Not really. The default for varmfs is AUTO, which mounts a memory file system on /var if, after mounting all early file systems, /var is not writeable. Writing entropy file:random: unblocking device. takes a little longer I changed to entropy_save_sz=4096 in /etc/rc.conf, maybe thats why. That shouldn't make any difference. Our /dev/random never blocks once it's seeded, and reading 4096 bytes won't take noticeably longer than reading 2048 bytes. But it should already be unblocked by then - this is on shutdown, right? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Fri, Oct 31, 2014 at 10:04 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ Mateusz, Can you take a look at: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ The last successful pass was GRN r273871. I'm not sure, but you made a bunch of commits under /usr/src/sys/kern at about the time when things started failing. Thanks. -- Craig ___ 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Fri, Oct 31, 2014 at 06:52:43PM -0700, Craig Rodrigues wrote: On Fri, Oct 31, 2014 at 10:04 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ Mateusz, Can you take a look at: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ The last successful pass was GRN r273871. I'm not sure, but you made a bunch of commits under /usr/src/sys/kern at about the time when things started failing. There was a regression after commits related to new random code which resulted in /dev/md0 being created and mounted to /var. Looks like the test in question assumes it always gets /dev/md0. The test works for me not what the regression is fixed. I guess jenkins didn't catch up to it yet. -- Mateusz Guzik mjguzik 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Oct 31, 2014, at 19:00, Mateusz Guzik mjgu...@gmail.com wrote: On Fri, Oct 31, 2014 at 06:52:43PM -0700, Craig Rodrigues wrote: On Fri, Oct 31, 2014 at 10:04 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/161/ Mateusz, Can you take a look at: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ The last successful pass was GRN r273871. I'm not sure, but you made a bunch of commits under /usr/src/sys/kern at about the time when things started failing. There was a regression after commits related to new random code which resulted in /dev/md0 being created and mounted to /var. Looks like the test in question assumes it always gets /dev/md0. The test works for me not what the regression is fixed. I guess jenkins didn't catch up to it yet. Correct. sbin/mdconfig/tests/legacy_test.sh always assumes /dev/md0 is available, which is wrong in a lot of cases and fixed by my enhancement. signature.asc Description: Message signed with OpenPGP using GPGMail
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #164
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/164/ ___ 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: Jenkins build is unstable: FreeBSD_HEAD-tests2 #161
On Oct 31, 2014 7:01 PM, Mateusz Guzik mjgu...@gmail.com wrote: There was a regression after commits related to new random code which resulted in /dev/md0 being created and mounted to /var. Looks like the test in question assumes it always gets /dev/md0. The test works for me not what the regression is fixed. I guess jenkins didn't catch up to it yet. Thanks for the analysis. Looks like things are OK as of https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/164/ . -- Craig ___ 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
