Jenkins build is back to normal : Build-UFS-image #474
See https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/474/ ___ 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 became unstable: FreeBSD_HEAD-tests2 #293
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/293/ ___ 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
Starting intel driver fails on boot
Hello. A few months ago I sent an e-mail to this mailing list and reported about problems related to starting X on FreeBSD when using EFI mode. I fixed that problem by using the scfb driver from ports. Today I, using Xorg -configure, was playing around with the intel driver, since my Mac has a built-in Intel HD 3000 graphics card as well as a Radeon HD 6770M. For some reason, when I attempt to start X with the intel driver, the screen freezes. However, if I start X using scfb and then manually load the i915kms kernel module, the system works perfectly fine until I leave X (at that time the screen freezes again). When using the xorg.conf.new file generated by Xorg -configure, the system prefers to use the intel driver rather than the radeon driver (neither of which seem to work). Taking a look at the output of dmesg -a from a verbose boot, I noted the following messages: info: [drm] Initialized drm 1.1.0 20060810 drmn1: Intel SandyBridge (M) on vgapci1 vgapci1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 268 to local APIC 2 vector 50 vgapci1: using IRQ 268 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xa000 256MB iicbus0: Philips I2C bus on iicbb0 addr 0xff iic0: I2C generic I/O on iicbus0 iic1: I2C generic I/O on iicbus1 iicbus2: Philips I2C bus on iicbb1 addr 0x0 iic2: I2C generic I/O on iicbus2 iic3: I2C generic I/O on iicbus3 iicbus4: Philips I2C bus on iicbb2 addr 0x0 iic4: I2C generic I/O on iicbus4 iic5: I2C generic I/O on iicbus5 iicbus6: Philips I2C bus on iicbb3 addr 0x0 iic6: I2C generic I/O on iicbus6 iic7: I2C generic I/O on iicbus7 iicbus8: Philips I2C bus on iicbb4 addr 0x0 iic8: I2C generic I/O on iicbus8 iic9: I2C generic I/O on iicbus9 iicbus10: Philips I2C bus on iicbb5 addr 0x0 iic10: I2C generic I/O on iicbus10 iic11: I2C generic I/O on iicbus11 iicbus12: Philips I2C bus on iicbb6 addr 0x0 iic12: I2C generic I/O on iicbus12 iic13: I2C generic I/O on iicbus13 iicbus14: Philips I2C bus on iicbb7 addr 0x0 iic14: I2C generic I/O on iicbus14 iic15: I2C generic I/O on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off drmn1: taking over the fictitious range 0xa000-0xb000 info: [drm] Connector LVDS-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.LVDS-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector VGA-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.VGA-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector HDMI-A-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.HDMI-A-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DP-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DP-1 info: [drm] - kern.vt.fb.default_mode fbd1 on drmn1 VT: Replacing driver efifb with new fb. info: [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) info: [drm] Initialized i915 1.6.0 20080730 error: [drm:pid0:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Can someone please tell me what those messages (especially the last 4 messages) mean? Are they somehow related to the reason why the screen freezes when the intel driver is loaded during the launch of X? Output of uname -a: FreeBSD andersbo-mac.local 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r274793M: Fri Nov 21 16:26:45 CET 2014 root@andersbo-mac.local:/usr/obj/usr/src/sys/KERNEL amd64 ___ 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
Problem with r274819? asr_timeout() not found
Running:
FreeBSD g1-253.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1434
r274790M/274790:1100047: Fri Nov 21 06:07:24 PST 2014
r...@g1-253.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386
Updated sources to r274845; make buildworld is OK, but make buildkernel:
...
stage 3.2: building everything
...
=== asr (all)
--- asr.o ---
--- all_subdir_asmc ---
ctfconvert -L VERSION -g asmc.o
--- all_subdir_asr ---
clang -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/common/S4/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -fno-common -g -I/common/S4/obj/usr/src/sys/GENERIC
-mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -gdwarf-2
-mno-aes -mno-avx -Qunused-arguments -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function -Wno-array-bounds
-mno-aes -mno-avx -Qunused-arguments -c
/usr/src/sys/modules/asr/../../dev/asr/asr.c
--- all_subdir_asmc ---
--- asmc.kld ---
ld -d -warn-common -r -d -o asmc.kld asmc.o
ctfmerge -L VERSION -g -o asmc.kld asmc.o
: export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk asmc.kld export_syms | xargs -J%
objcopy % asmc.kld
--- asmc.ko.debug ---
ld -Bshareable -d -warn-common -o asmc.ko.debug asmc.kld
--- asmc.ko.symbols ---
objcopy --only-keep-debug asmc.ko.debug asmc.ko.symbols
--- all_subdir_asr ---
/usr/src/sys/modules/asr/../../dev/asr/asr.c:393:15: error: use of undeclared
identifier 'asr_timeout'
ch = timeout(asr_timeout, (caddr_t)ccb,
^
1 error generated.
--- all_subdir_asmc ---
--- asmc.ko ---
--- all_subdir_asr ---
*** [asr.o] Error code 1
bmake: stopped in /usr/src/sys/modules/asr
1 error
bmake: stopped in /usr/src/sys/modules/asr
--- all_subdir_asmc ---
objcopy --strip-debug --add-gnu-debuglink=asmc.ko.symbols asmc.ko.debug asmc.ko
--- all_subdir_asr ---
*** [all_subdir_asr] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_asmc ---
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/asmc
*** [all_subdir_asmc] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_arcmsr ---
ctfconvert -L VERSION -g arcmsr.o
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/arcmsr
*** [all_subdir_arcmsr] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_aic7xxx ---
--- aic79xx.o ---
ctfconvert -L VERSION -g aic79xx.o
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/aic7xxx/ahd
*** [_sub.all] Error code 2
bmake: stopped in /usr/src/sys/modules/aic7xxx
1 error
bmake: stopped in /usr/src/sys/modules/aic7xxx
*** [all_subdir_aic7xxx] Error code 2
bmake: stopped in /usr/src/sys/modules
4 errors
bmake: stopped in /usr/src/sys/modules
*** [modules-all] Error code 2
bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC
1 error
bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC
*** [buildkernel] Error code 2
bmake: stopped in /usr/src
1 error
bmake: stopped in /usr/src
*** [buildkernel] Error code 2
make: stopped in /usr/src
1 error
make: stopped in /usr/src
freebeast(11.0-C)[3]
And r274819 did:
Index: asr.c
===
--- asr.c (revision 274818)
+++ asr.c (revision 274819)
@@ -386,8 +386,12 @@
STAILQ_HEAD_INITIALIZER(Asr_softc_list);
static __inline void
-set_ccb_timeout_ch(union asr_ccb *ccb, struct callout_handle ch)
+set_ccb_timeout_ch(union asr_ccb *ccb)
{
+ struct callout_handle ch;
+
+ ch = timeout(asr_timeout, (caddr_t)ccb,
+ (int)((u_int64_t)(ccb-ccb_h.timeout) * (u_int32_t)hz / 1000));
ccb-ccb_h.sim_priv.entries[0].ptr = ch.callout;
}
@@ -812,8 +816,7 @@
*/
ccb-ccb_h.timeout = 6 * 60 * 1000;
}
- set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb,
- (ccb-ccb_h.timeout * hz) / 1000));
+ set_ccb_timeout_ch(ccb);
}
splx(s);
} /* ASR_ccbAdd */
@@ -1337,9 +1340,7 @@
cam_sim_unit(xpt_path_sim(ccb-ccb_h.path)), s);
if (ASR_reset (sc) == ENXIO) {
/* Try again later */
- set_ccb_timeout_ch(ccb, timeout(asr_timeout,
- (caddr_t)ccb,
- (ccb-ccb_h.timeout * hz) / 1000));
+ set_ccb_timeout_ch(ccb);
}
return;
}
@@ -1353,9 +1354,7 @@
if
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #294
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/294/ ___ 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
How much memory do I need for buildworld?
Hi, I've a fresh FreeBSD 10.1 installed on an old 32-bit machine. I've checked out revision 274850 of the base sources and ran 'make buildworld'. After some time it has failed: === lib/clang/libllvmx86disassembler (depend) tblgen -gen-disassembler -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86 -d X86GenDisassemblerTables.inc.d -o X86GenDisassemblerTables.inc.h /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86/X86.td *** Signal 9 Stop. make[4]: stopped in /usr/src/lib/clang/libllvmx86disassembler *** Error code 1 According to /var/log/messages it was killed because of out of memory: Nov 22 16:55:13 mercury kernel: swap_pager: out of swap space Nov 22 16:55:13 mercury kernel: swap_pager_getswapspace(16): failed Nov 22 16:55:13 mercury kernel: pid 22841 (tblgen), uid 0, was killed: out of swap space This machine has 256MB of RAM and one 64MB swap partition. Previously I used FreeBSD 7.4-CURRENT on this machine with two swap partitions of 64MB each and never had such a problem. I use it as a router, i.e. there is no X and no other memory greedy processes. Could it be related to an llvm bug fixed by following commit? http://svnweb.freebsd.org/base?view=revisionrevision=274696 ___ 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: How much memory do I need for buildworld?
On 22 Nov 2014, at 16:51, Rostislav Krasny rosti@gmail.com wrote: I've a fresh FreeBSD 10.1 installed on an old 32-bit machine. I've checked out revision 274850 of the base sources and ran 'make buildworld'. After some time it has failed: === lib/clang/libllvmx86disassembler (depend) tblgen -gen-disassembler -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86 -d X86GenDisassemblerTables.inc.d -o X86GenDisassemblerTables.inc.h /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86/X86.td *** Signal 9 Stop. make[4]: stopped in /usr/src/lib/clang/libllvmx86disassembler *** Error code 1 According to /var/log/messages it was killed because of out of memory: Nov 22 16:55:13 mercury kernel: swap_pager: out of swap space Nov 22 16:55:13 mercury kernel: swap_pager_getswapspace(16): failed Nov 22 16:55:13 mercury kernel: pid 22841 (tblgen), uid 0, was killed: out of swap space This machine has 256MB of RAM and one 64MB swap partition. This is most likely the problem: you need more RAM for this particular instance of tblgen. On my -CURRENT i386 box, it takes ~369MiB of RSS to build the X86 disassembler tables. I'm surprised you didn't run into OOM problems earlier, with so little memory. For such router like machines, it is obviously easier to do the build on a fast desktop machine, then install over NFS, or rsync /usr/src and /usr/obj to the target machine. Previously I used FreeBSD 7.4-CURRENT on this machine with two swap partitions of 64MB each and never had such a problem. I use it as a router, i.e. there is no X and no other memory greedy processes. Yes, 7.4 is much smaller, and does not have any big C++ programs in it, so a buildworld is more likely to succeed on small memory machines. Could it be related to an llvm bug fixed by following commit? http://svnweb.freebsd.org/base?view=revisionrevision=274696 No, this is unlikely. This problem only occurred 1) in the compiler itself, 2) very specific ports, and 3) when compiling with debug info enabled. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problem with r274819? asr_timeout() not found
Fixed, sorry forgot asr wasn't in GENERIC, so missed it in testing.
On 22/11/2014 14:34, David Wolfskill wrote:
Running:
FreeBSD g1-253.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1434
r274790M/274790:1100047: Fri Nov 21 06:07:24 PST 2014
r...@g1-253.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386
Updated sources to r274845; make buildworld is OK, but make buildkernel:
...
stage 3.2: building everything
...
=== asr (all)
--- asr.o ---
--- all_subdir_asmc ---
ctfconvert -L VERSION -g asmc.o
--- all_subdir_asr ---
clang -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/common/S4/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -fno-common -g -I/common/S4/obj/usr/src/sys/GENERIC
-mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -gdwarf-2
-mno-aes -mno-avx -Qunused-arguments -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function -Wno-array-bounds
-mno-aes -mno-avx -Qunused-arguments -c
/usr/src/sys/modules/asr/../../dev/asr/asr.c
--- all_subdir_asmc ---
--- asmc.kld ---
ld -d -warn-common -r -d -o asmc.kld asmc.o
ctfmerge -L VERSION -g -o asmc.kld asmc.o
: export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk asmc.kld export_syms | xargs -J%
objcopy % asmc.kld
--- asmc.ko.debug ---
ld -Bshareable -d -warn-common -o asmc.ko.debug asmc.kld
--- asmc.ko.symbols ---
objcopy --only-keep-debug asmc.ko.debug asmc.ko.symbols
--- all_subdir_asr ---
/usr/src/sys/modules/asr/../../dev/asr/asr.c:393:15: error: use of undeclared
identifier 'asr_timeout'
ch = timeout(asr_timeout, (caddr_t)ccb,
^
1 error generated.
--- all_subdir_asmc ---
--- asmc.ko ---
--- all_subdir_asr ---
*** [asr.o] Error code 1
bmake: stopped in /usr/src/sys/modules/asr
1 error
bmake: stopped in /usr/src/sys/modules/asr
--- all_subdir_asmc ---
objcopy --strip-debug --add-gnu-debuglink=asmc.ko.symbols asmc.ko.debug asmc.ko
--- all_subdir_asr ---
*** [all_subdir_asr] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_asmc ---
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/asmc
*** [all_subdir_asmc] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_arcmsr ---
ctfconvert -L VERSION -g arcmsr.o
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/arcmsr
*** [all_subdir_arcmsr] Error code 2
bmake: stopped in /usr/src/sys/modules
--- all_subdir_aic7xxx ---
--- aic79xx.o ---
ctfconvert -L VERSION -g aic79xx.o
A failure has been detected in another branch of the parallel make
bmake: stopped in /usr/src/sys/modules/aic7xxx/ahd
*** [_sub.all] Error code 2
bmake: stopped in /usr/src/sys/modules/aic7xxx
1 error
bmake: stopped in /usr/src/sys/modules/aic7xxx
*** [all_subdir_aic7xxx] Error code 2
bmake: stopped in /usr/src/sys/modules
4 errors
bmake: stopped in /usr/src/sys/modules
*** [modules-all] Error code 2
bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC
1 error
bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC
*** [buildkernel] Error code 2
bmake: stopped in /usr/src
1 error
bmake: stopped in /usr/src
*** [buildkernel] Error code 2
make: stopped in /usr/src
1 error
make: stopped in /usr/src
freebeast(11.0-C)[3]
And r274819 did:
Index: asr.c
===
--- asr.c (revision 274818)
+++ asr.c (revision 274819)
@@ -386,8 +386,12 @@
STAILQ_HEAD_INITIALIZER(Asr_softc_list);
static __inline void
-set_ccb_timeout_ch(union asr_ccb *ccb, struct callout_handle ch)
+set_ccb_timeout_ch(union asr_ccb *ccb)
{
+ struct callout_handle ch;
+
+ ch = timeout(asr_timeout, (caddr_t)ccb,
+ (int)((u_int64_t)(ccb-ccb_h.timeout) * (u_int32_t)hz / 1000));
ccb-ccb_h.sim_priv.entries[0].ptr = ch.callout;
}
@@ -812,8 +816,7 @@
*/
ccb-ccb_h.timeout = 6 * 60 * 1000;
}
- set_ccb_timeout_ch(ccb, timeout(asr_timeout, (caddr_t)ccb,
- (ccb-ccb_h.timeout * hz) / 1000));
+ set_ccb_timeout_ch(ccb);
}
splx(s);
} /* ASR_ccbAdd */
@@ -1337,9 +1340,7 @@
cam_sim_unit(xpt_path_sim(ccb-ccb_h.path)), s);
if (ASR_reset (sc) == ENXIO) {
/* Try again later */
- set_ccb_timeout_ch(ccb, timeout(asr_timeout,
- (caddr_t)ccb,
- (ccb-ccb_h.timeout * hz) / 1000));
+
zfs/vfs lockups, via poudriere
bdrewery reported a vfs/zfs condition where operations will stall out and block (rm, mv, file) during a poudriere build. I've hit this now and it seems to be alleviated by setting vfs.lookup_shared=0 I seem to be able to trivially reproduce this on my builders and want to know if anyone is looking to diagnose this further. original message: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html On my builders I see: procstat -kka | grep zfs 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+0xe 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe 31071 100995 rm -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 kern_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb 31075 100693 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x4 signature.asc Description: This is a digitally signed message part
Re: WITNESS observes 2 LORs on Boot of Release 10.1
On Fri, 21 Nov 2014, Ellis H. Wilson III wrote: Before I start, and this is mainly geared to my responder Benjamin Kaduk, based on your response, are you suggesting that the cnputc WITNESS panic you expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this a spinlock that WITNESS falls over each time but that is provably deadlock free that the developers have decided cannot be BLESSED for some reason? https://lists.freebsd.org/pipermail/freebsd-current/2012-January/031316.html looks to be a better explanation than the previous link I sent ... in short, console output is hard. I guess I just can't wrap my head around why we would ever move to a regime where SKIPSPIN is the default for testing... That just seems like an open invitation for introducing spinlock regressions. I don't think anyone made the conscious decision to do that, it just happened by default as no one spent the time to fix the aforementioned issue. Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS debugging is how exactly to interpret the output if I see a stacktrace and then a LOR output like the following: lock order reversal: 1st 0x81633d88 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0x813b6208 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2682 Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then #2 scp-scr_lock, and somewhere somebody tried to lock scp-scr_lock without first getting harvest_mtx? Or the reverse (WITNESS previously recorded scrlock and then harvest and the lines it spit out were the offenders?) I believe it is the latter (the ordering being printed is the bad one which caused WITNESS to complain). -Ben ___ 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: zfs/vfs lockups, via poudriere
On 22/11/2014 21:20, Sean Bruno wrote: bdrewery reported a vfs/zfs condition where operations will stall out and block (rm, mv, file) during a poudriere build. I've hit this now and it seems to be alleviated by setting vfs.lookup_shared=0 I seem to be able to trivially reproduce this on my builders and want to know if anyone is looking to diagnose this further. original message: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html On my builders I see: procstat -kka | grep zfs 0 100666 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x2ad taskqueue_thread_loop+0xf5 fork_exit+0x9a fork_trampoline+0xe 3 100151 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100152 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe 3 100657 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 3 100675 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x190 txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100676 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x1ad txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe 31071 100995 rm -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0x9ab vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x534 kern_rmdirat+0x8d amd64_syscall+0x3fb Xfast_syscall+0xfb 31075 100693 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x18d __lockmgr_args+0xd5d vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x4 The last line looks incomplete. -- Andriy Gapon ___ 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
Call for Help: Flame Graphs and Continuous Integration
FYI: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000667.html Please send follow-ups to freebsd-test...@freebsd.org -- 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
[HEADSUP] man(1) now uses mandoc
Hi, The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Best regards, Bapt pgpJ4K_Z_SDkN.pgp Description: PGP signature
Call for Help: openjdk8 tests under Continuous Integration
FYI, https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000668.html Please send followups to freebsd-test...@freebsd.org. -- 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: Starting intel driver fails on boot
On Sat, Nov 22, 2014 at 3:57 AM, Anders Bolt-Evensen andersb...@icloud.com wrote: Hello. Try freebsd-x11@ or #freebsd-xorg on efnet. cheers, Hiren ___ 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
