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