bind: eating a lot CPU time
On a CURRENT server acting as the gateway/router (FreeBSD 10.0-CURRENT #1 r243869M: Wed Dec 5 00:09:59 CET 2012), a running named/bind service for local DNS resolution is eating up a lot of time. Is this usual? I can not see caching, checking for requests or similar what could cause a permanent load on the server daemon. regards oliver PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1635 bind 7 200 98640K 31640K kqread 0 41:02 113.13% named 1371 root 1 200 47932K 4168K select 2 0:14 0.00% ppp 2413 klicko 1 200 99092K 8008K select 2 0:01 0.00% sshd [...] signature.asc Description: OpenPGP digital signature
Re: bind: eating a lot CPU time
On Wed, Dec 5, 2012 at 10:30 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On a CURRENT server acting as the gateway/router (FreeBSD 10.0-CURRENT #1 r243869M: Wed Dec 5 00:09:59 CET 2012), a running named/bind service for local DNS resolution is eating up a lot of time. Is this usual? I can not see caching, checking for requests or similar what could cause a permanent load on the server daemon. You could try enabling logging, and see if there is something there. -- chs, ___ 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: SU+J on 9.1-RC2 ISO
Date: Sun, 04 Nov 2012 21:13:36 +0900 (JST)
To: freebsd-sta...@freebsd.org
Subject: Re: SU+J on 9.1-RC2 ISO
From: HATANO Tomomi hata...@infolab.ne.jp
Cc: j...@koitsu.org, b.smee...@ose.nl, fnwhiteh...@freebsd.org,
freebsd-current@freebsd.org
Hi all.
The point is:
There is completely no way to take a snapshot of SU+J partition
unless modify one's kernel.
Whether some issue still exist or not,
how about enabling snapshoting SU+J partition
through sysctl variable?
Would you mind to see patch attached?
1. Taking a snapshot of SU+J partition is controlled through sysctl variable.
2. Default to disable.
One who want to enable it should set the variable manually.
3. The default value in bsdinstall(8) may be left as is.
--
HATANO Tomomi.
--- src/sys/ufs/ffs/ffs_snapshot.c.orig 2012-11-04 11:01:58.0
+0900
+++ src/sys/ufs/ffs/ffs_snapshot.c2012-11-04 11:13:32.0 +0900
@@ -182,8 +182,10 @@
*/
int dopersistence = 0;
-#ifdef DEBUG
#include sys/sysctl.h
+int snapsuj = 0;
+SYSCTL_INT(_debug, OID_AUTO, snapsuj, CTLFLAG_RW, snapsuj, 0, );
+#ifdef DEBUG
SYSCTL_INT(_debug, OID_AUTO, dopersistence, CTLFLAG_RW, dopersistence, 0,
);
static int snapdebug = 0;
SYSCTL_INT(_debug, OID_AUTO, snapdebug, CTLFLAG_RW, snapdebug, 0, );
@@ -230,7 +232,7 @@
* At the moment, journaled soft updates cannot support
* taking snapshots.
*/
- if (MOUNTEDSUJ(mp)) {
+ if (MOUNTEDSUJ(mp) (snapsuj == 0)) {
vfs_mount_error(mp, %s: Snapshots are not yet supported when
running with journaled soft updates, fs-fs_fsmnt);
return (EOPNOTSUPP);
Snapshots are disabled when using SU+J for a reason. That reason is
that the journal rollback when a snapshot is active on a filesystem
DOES NOT WORK. It leaves your filesystem with duplicate blocks that can
only be removed by manually running fsck and correcting the duplicate
block entries by hand. If you need to use snapshots, then run with SU
and not SU+J. When journal rollback properly handles snapshots, snapshots
on SU+J will be enabled.
Kirk McKusick
___
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: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
On Thu, Nov 29, 2012 at 12:05 PM, Andriy Gapon a...@freebsd.org wrote: on 16/11/2012 16:42 Andriy Gapon said the following: on 15/11/2012 23:44 Attilio Rao said the following: Do you think you can test this patch?: http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I will use this patch in my tree, but I think that it is effectively already quite well tested by using INVARIANTS+WITNESS. I've been using this patch in both debug and non-debug environments and I have not run into any issues. Please commit when you get a chance. Thank you. Committed as r243900, please proceed with manpage cleanup. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: Call for testers, users with scsi cards
On Tue, 2012-12-04 at 14:58 -1000, Jeff Roberson wrote: On Tue, 4 Dec 2012, Ian Lepore wrote: On Tue, 2012-12-04 at 14:49 -0700, Warner Losh wrote: On Dec 4, 2012, at 2:36 PM, Jeff Roberson wrote: http://people.freebsd.org/~jeff/loadccb.diff This patch consolidates all of the functions that map cam control blocks for DMA into one central function. This change is a precursor to adding new features to the I/O stack. It is mostly mechanical. If you are running current on a raid or scsi card, especially if it is a lesser used one, I would really like you to apply this patch and report back any problems. If it works you should notice nothing. If it doesn't work you will probably panic immediately on I/O or otherwise no I/O will happen. I haven't tested it yet. My only comment from reading it though would be to make subr_busdma.c be dependent on cam, since it can only used from cam. We've grown sloppy about noting these dependencies in the tree... Warner Hmmm, if it's only used by cam, why isn't it in cam/ rather than kern/ ? kib pointed out drivers that use ccbs but do not depend on cam. Ahh, I didn't realize. I also intend to consolidate many of the busdma_load_* functions into this subr_busdma.c eventually. I will add a load_bio and things like load_uio and load_mbuf don't need to be re-implemented for every machine. I will define a MD function that allows you to add virtual or physical segments piecemeal (as they all currently have) so that function may be called for each member in the uio, mbuf, ccb, or bio. I'm afraid the current near-identicalness of things like the load_mbuf implementations have more to do with the cut-and-paste nature of how the non-x86 implementations came to be, rather than actual correctness. A proper implementation of the load_mbuf routines on architectures with VIVT cache should involve setting some flags in the map so that the sync operations can be handled differently for mbufs than for anonymous memory. (Mbufs are allowed to bend the rules about DMA buffers being aligned to cacheline boundaries.) The uio-related busdma operations for VIVT cache platforms are probably just plain wrong -- like would cause a panic type wrong if they were actually invoked. I posted a set of patches that fix all the problems I know of in the armv4 busdma implementation, except for the uio stuff. It didn't get much comment at the time and lacks a champion who can actually commit the code. They won't even apply cleanly anymore because of other changes that have happened, I guess I should go re-spin the patchset and post it again. -- Ian ___ 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 module parallel build?
On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote: Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). This is definitely not the behaviour that I see trying to build any version of FreeBSD. I see the same behaviour as Andre: the depend and all targets both iterate through the module directories sequentially. It never builds two module subdirectories concurrently. Hmm, I think I was confused by seeing kernel builds intermingle with the associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see similar things in world builds where I will see parallel builds of bin vs sbin vs usr.bin vs usr.sbin, but within each of those directories the builds go sequentially. I think you would need to change bsd.subdir.mk if you want to fix this. -- John Baldwin ___ 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 module parallel build?
On Wed, Dec 5, 2012 at 8:42 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote:
On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote:
Hmm, I certainly see the module directories being built in parallel. Some
of
the make jobs may not be as obvious since links are silent (no output
unless
there is an error).
This is definitely not the behaviour that I see trying to build any version
of FreeBSD. I see the same behaviour as Andre: the depend and all targets
both iterate through the module directories sequentially. It never builds
two module subdirectories concurrently.
Hmm, I think I was confused by seeing kernel builds intermingle with the
associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see
similar things in world builds where I will see parallel builds of bin vs sbin
vs usr.bin vs usr.sbin, but within each of those directories the builds go
sequentially. I think you would need to change bsd.subdir.mk if you want to
fix this.
Correct:
45 @${_+_}for entry in ${SUBDIR}; do \
^^^ This is where things get serialized
46 if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \
Same thing applies for buildkernel building modules because it
just wraps around bsd.subdir.mk in sys/modules/Makefile . Enhancing it
to be parallel would introduce potential races. Some of the work sjg's
doing with meta make will make this unnecessary from a buildworld
perspective, but I'm not sure about buildkernel.
Thanks,
-Garrett
___
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: Call for testers, users with scsi cards
On Tue, Dec 4, 2012 at 2:36 PM, Jeff Roberson jrober...@jroberson.netwrote:
http://people.freebsd.org/~**jeff/loadccb.diffhttp://people.freebsd.org/~jeff/loadccb.diff
This patch consolidates all of the functions that map cam control blocks
for DMA into one central function. This change is a precursor to adding
new features to the I/O stack. It is mostly mechanical. If you are
running current on a raid or scsi card, especially if it is a lesser used
one, I would really like you to apply this patch and report back any
problems. If it works you should notice nothing. If it doesn't work you
will probably panic immediately on I/O or otherwise no I/O will happen.
Hi Jeff,
This patch breaks both ahci and isci on my system. I still need to root
cause the isci panic, but I have some details on ahci.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x6c
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80314f98
stack pointer = 0x28:0xff884433a130
frame pointer = 0x28:0xff884433a1d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4 (xpt_thrd)
[ thread pid 4 tid 100174 ]
Stopped at ahci_dmasetprd+0xb8:movl0x6c(%rcx),%eax
db bt
Tracing pid 4 tid 100174 td 0xfe002c080480
ahci_dmasetprd() at ahci_dmasetprd+0xb8/frame 0xff884433a1d0
bus_dmamap_load() at bus_dmamap_load+0x91/frame 0xff884433a230
bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0xf0/frame 0xff884433a280
ahci_dmasetprd() at ahci_dmasetprd+0x82e/frame 0xff884433a320
bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0x3b/frame 0xff884433a370
ahciaction() at ahciaction+0x7d4/frame 0xff884433a3b0
xpt_run_dev_sendq() at xpt_run_dev_sendq+0x2a1/frame 0xff884433a3f0
xpt_action_default() at xpt_action_default+0x10bd/frame 0xff884433a480
probestart() at probestart+0x1e5/frame 0xff884433a5d0
xpt_run_dev_allocq() at xpt_run_dev_allocq+0x192/frame 0xff884433a610
proberegister() at proberegister+0xf9/frame 0xff884433a630
cam_periph_alloc() at cam_periph_alloc+0x571/frame 0xff884433a710
ata_scan_lun() at ata_scan_lun+0x147/frame 0xff884433a920
ata_scan_bus() at ata_scan_bus+0x2c0/frame 0xff884433aa40
xpt_scanner_thread() at xpt_scanner_thread+0x161/frame 0xff884433aa70
fork_exit() at fork_exit+0x9a/frame 0xff884433aab0
fork_trampoline() at fork_trampoline+0xe/frame 0xff884433aab0
The following patch to ahci.c works, but hopefully someone more familiar
with ahci can chime in.
Index: sys/dev/ahci/ahci.c
===
--- sys/dev/ahci/ahci.c (revision 243900)
+++ sys/dev/ahci/ahci.c (working copy)
@@ -1669,19 +1669,9 @@
slot-dma.nsegs = 0;
/* If request moves data, setup and load SG list */
if ((ccb-ccb_h.flags CAM_DIR_MASK) != CAM_DIR_NONE) {
- void *buf;
- bus_size_t size;
-
slot-state = AHCI_SLOT_LOADING;
- if (ccb-ccb_h.func_code == XPT_ATA_IO) {
- buf = ccb-ataio.data_ptr;
- size = ccb-ataio.dxfer_len;
- } else {
- buf = ccb-csio.data_ptr;
- size = ccb-csio.dxfer_len;
- }
- bus_dmamap_load(ch-dma.data_tag, slot-dma.data_map,
- buf, size, ahci_dmasetprd, slot, 0);
+ bus_dmamap_load_ccb(ch-dma.data_tag, slot-dma.data_map,
ccb,
+ ahci_dmasetprd, slot, 0);
} else
ahci_execute_transaction(slot);
}
-Jim
___
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 module parallel build?
On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote: Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). This is definitely not the behaviour that I see trying to build any version of FreeBSD. I see the same behaviour as Andre: the depend and all targets both iterate through the module directories sequentially. It never builds two module subdirectories concurrently. Hmm, I think I was confused by seeing kernel builds intermingle with the associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see similar things in world builds where I will see parallel builds of bin vs sbin vs usr.bin vs usr.sbin, but within each of those directories the builds go sequentially. I think you would need to change bsd.subdir.mk if you want to fix this. The builds are in parallel, just that the parallelism is low because it is only parallel within the module being built. Would love to see a fix. Warner ___ 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: Call for testers, users with scsi cards
On Tue, Dec 4, 2012 at 2:36 PM, Jeff Roberson jrober...@jroberson.netwrote:
http://people.freebsd.org/~**jeff/loadccb.diffhttp://people.freebsd.org/~jeff/loadccb.diff
This patch consolidates all of the functions that map cam control blocks
for DMA into one central function. This change is a precursor to adding
new features to the I/O stack. It is mostly mechanical. If you are
running current on a raid or scsi card, especially if it is a lesser used
one, I would really like you to apply this patch and report back any
problems. If it works you should notice nothing. If it doesn't work you
will probably panic immediately on I/O or otherwise no I/O will happen.
+int
+bus_dmamap_load_ccb(bus_dma_tag_t dmat, bus_dmamap_t map, union ccb *ccb,
+bus_dmamap_callback_t *callback, void *callback_arg,
+int flags)
+{
+struct ccb_ataio *ataio;
+struct ccb_scsiio *csio;
+struct ccb_hdr *ccb_h;
+void *data_ptr;
+uint32_t dxfer_len;
+uint16_t sglist_cnt;
+
+ccb_h = ccb-ccb_h;
+if ((ccb_h-flags CAM_DIR_MASK) == CAM_DIR_NONE) {
+callback(callback_arg, NULL, 0, 0);
+}
+
I think you need to return here after invoking the callback. Otherwise you
drop through and then either invoke the callback again or call
bus_dmamap_load (which will in turn invoke the callback again).
This fix allows the ahci.c change to go back to:
Index: sys/dev/ahci/ahci.c
===
--- sys/dev/ahci/ahci.c (revision 243900)
+++ sys/dev/ahci/ahci.c (working copy)
@@ -1667,23 +1667,9 @@
(ccb-ataio.cmd.flags (CAM_ATAIO_CONTROL |
CAM_ATAIO_NEEDRESULT)))
ch-aslots |= (1 slot-slot);
slot-dma.nsegs = 0;
- /* If request moves data, setup and load SG list */
- if ((ccb-ccb_h.flags CAM_DIR_MASK) != CAM_DIR_NONE) {
- void *buf;
- bus_size_t size;
-
- slot-state = AHCI_SLOT_LOADING;
- if (ccb-ccb_h.func_code == XPT_ATA_IO) {
- buf = ccb-ataio.data_ptr;
- size = ccb-ataio.dxfer_len;
- } else {
- buf = ccb-csio.data_ptr;
- size = ccb-csio.dxfer_len;
- }
- bus_dmamap_load(ch-dma.data_tag, slot-dma.data_map,
- buf, size, ahci_dmasetprd, slot, 0);
- } else
- ahci_execute_transaction(slot);
+ slot-state = AHCI_SLOT_LOADING;
+ bus_dmamap_load_ccb(ch-dma.data_tag, slot-dma.data_map, ccb,
+ ahci_dmasetprd, slot, 0);
}
/* Locked by busdma engine. */
This is almost what you head earlier, but adding back setting of the slot's
state to AHCI_SLOT_LOADING, to cover the case where the load is deferred.
It seems OK to do this even in case where no load is actually happening
(i.e. CAM_DIR_NONE).
-Jim
___
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: Call for testers, users with scsi cards
On Wed, 5 Dec 2012, Jim Harris wrote:
On Tue, Dec 4, 2012 at 2:36 PM, Jeff Roberson jrober...@jroberson.net
wrote:
http://people.freebsd.org/~jeff/loadccb.diff
This patch consolidates all of the functions that map cam
control blocks for DMA into one central function. This change
is a precursor to adding new features to the I/O stack. It is
mostly mechanical. If you are running current on a raid or scsi
card, especially if it is a lesser used one, I would really like
you to apply this patch and report back any problems. If it
works you should notice nothing. If it doesn't work you will
probably panic immediately on I/O or otherwise no I/O will
happen.
+int
+bus_dmamap_load_ccb(bus_dma_tag_t dmat, bus_dmamap_t map, union ccb *ccb,
+ bus_dmamap_callback_t *callback, void *callback_arg,
+ int flags)
+{
+ struct ccb_ataio *ataio;
+ struct ccb_scsiio *csio;
+ struct ccb_hdr *ccb_h;
+ void *data_ptr;
+ uint32_t dxfer_len;
+ uint16_t sglist_cnt;
+
+ ccb_h = ccb-ccb_h;
+ if ((ccb_h-flags CAM_DIR_MASK) == CAM_DIR_NONE) {
+ callback(callback_arg, NULL, 0, 0);
+ }
+
I think you need to return here after invoking the callback. Otherwise you
drop through and then either invoke the callback again or call
bus_dmamap_load (which will in turn invoke the callback again).
This fix allows the ahci.c change to go back to:
Thanks Jim. That was silly of me. I have decided to move this work to a
branch and keep expanding on it. I'll solicit more testing once the
branch is closer to the ultimate goal.
Thanks,
Jeff
Index: sys/dev/ahci/ahci.c
===
--- sys/dev/ahci/ahci.c (revision 243900)
+++ sys/dev/ahci/ahci.c (working copy)
@@ -1667,23 +1667,9 @@
(ccb-ataio.cmd.flags (CAM_ATAIO_CONTROL |
CAM_ATAIO_NEEDRESULT)))
ch-aslots |= (1 slot-slot);
slot-dma.nsegs = 0;
- /* If request moves data, setup and load SG list */
- if ((ccb-ccb_h.flags CAM_DIR_MASK) != CAM_DIR_NONE) {
- void *buf;
- bus_size_t size;
-
- slot-state = AHCI_SLOT_LOADING;
- if (ccb-ccb_h.func_code == XPT_ATA_IO) {
- buf = ccb-ataio.data_ptr;
- size = ccb-ataio.dxfer_len;
- } else {
- buf = ccb-csio.data_ptr;
- size = ccb-csio.dxfer_len;
- }
- bus_dmamap_load(ch-dma.data_tag, slot-dma.data_map,
- buf, size, ahci_dmasetprd, slot, 0);
- } else
- ahci_execute_transaction(slot);
+ slot-state = AHCI_SLOT_LOADING;
+ bus_dmamap_load_ccb(ch-dma.data_tag, slot-dma.data_map, ccb,
+ ahci_dmasetprd, slot, 0);
}
/* Locked by busdma engine. */
This is almost what you head earlier, but adding back setting of the slot's
state to AHCI_SLOT_LOADING, to cover the case where the load is deferred.
It seems OK to do this even in case where no load is actually happening
(i.e. CAM_DIR_NONE).
-Jim
___
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: Call for testers, users with scsi cards
On Wed, Dec 5, 2012 at 1:56 PM, Jeff Roberson jrober...@jroberson.netwrote: Thanks Jim. That was silly of me. I have decided to move this work to a branch and keep expanding on it. I'll solicit more testing once the branch is closer to the ultimate goal. Thanks, Jeff Sounds good. FYI - that same change (returning after invoking the callback) fixes the isci panic as well. Your patch also uncovered a different issue in the isci driver that I just fixed in r243904. It will likely cause a merge conflict next time you rebase your physbio branch. Thanks, -Jim ___ 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 module parallel build?
On Wed, Dec 5, 2012 at 3:51 PM, Damien Fleuriot m...@my.gd wrote: ... All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. I would be happy to check if this is advertised in the handbook in the rebuilding kernel section and enhance its visibility if required. I can provide en_US and fr_FR. +1. Please write it up if you can; it's much quicker/better than the kitchen sink approach if you know what you're doing and don't have to build for a large set of platforms. Thanks! -Garrett ___ 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 module parallel build?
On 5 Dec 2012, at 18:39, Warner Losh i...@bsdimp.com wrote: On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote: Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). This is definitely not the behaviour that I see trying to build any version of FreeBSD. I see the same behaviour as Andre: the depend and all targets both iterate through the module directories sequentially. It never builds two module subdirectories concurrently. Hmm, I think I was confused by seeing kernel builds intermingle with the associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see similar things in world builds where I will see parallel builds of bin vs sbin vs usr.bin vs usr.sbin, but within each of those directories the builds go sequentially. I think you would need to change bsd.subdir.mk if you want to fix this. The builds are in parallel, just that the parallelism is low because it is only parallel within the module being built. Would love to see a fix. Warner All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. I would be happy to check if this is advertised in the handbook in the rebuilding kernel section and enhance its visibility if required. I can provide en_US and fr_FR. ___ 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
