mountroot event
I would like to propose the following change. My understanding is that it was never a true intention to post 'mountroot' event on every set_rootvnode() call, but rather an accident in the original commit. But I could be wrong here. In either case I think that it is more appropriate to post the event only once. I do not expect that there could be any consumers interested in all the details of root fs manipulations. It looks like there is just a single subscriber to this event in subr_firmware.c. I am not familiar with that code, so I would like to ask for confirmation that the proposed change won't break anything there. Thank you. commit 9dc8eaa50afa6ac88c44fbaad82509721e106f1a Author: Andriy Gapon Date: Wed Mar 6 08:57:35 2013 +0200 post mountroot event after a real/final root is mounted not every time an intermediate root (including the first devfs) is mounted. diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 147926e..162738d 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -199,8 +199,6 @@ set_rootvnode(void) VREF(rootvnode); FILEDESC_XUNLOCK(p->p_fd); - - EVENTHANDLER_INVOKE(mountroot); } static int @@ -991,6 +989,8 @@ vfs_mountroot(void) atomic_store_rel_int(&root_mount_complete, 1); wakeup(&root_mount_complete); mtx_unlock(&mountlist_mtx); + + EVENTHANDLER_INVOKE(mountroot); } static struct mntarg * -- 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"
Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1
> Due to the security incident, there are still no official FreeBSD > packages. > Do you know what the status is on that issue? ___ 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"
Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
Yesterday, I built head & ran it without incident (as has been the daily norm for some time now): FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Today, after updating to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I find that booting to single-user mode is OK, and I can even start xdm -- as long as I did not kldload nvidia.ko first. (Indeed, I find that once loaded, the attempt to unload nvidia.ko appears to hang.) If (as has been my practice for the last several years) I loaded nvidia.ko (via /boot/loader.conf) before attempting to start xdm, when I do try starting xdm, the machine (my laptop -- no serial console) quietly initiates a reboot. Mounted file systems don't get unmounted first, so that tends to be mildly annoying -- and provides some evidence that the reboot isn't exactly being performed under ideal conditions (which, I admit, is not all that much of a surprise). Here's what happened during the "svn update," so folks can see what files changed: Script started on Wed Mar 20 06:01:32 2013 svn update /usr/src Updating '/usr/src': U/usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp U/usr/src/share/man/man4/unix.4 U/usr/src/share/man/man4/iwn.4 U/usr/src/lib/libc/sys/recv.2 U/usr/src/lib/libc/sys/socket.2 U/usr/src/lib/libc/sys/socketpair.2 U/usr/src/sys/ia64/ia64/pmap.c U/usr/src/sys/mips/mips/pmap.c U/usr/src/sys/fs/nfsclient/nfs_clbio.c U/usr/src/sys/amd64/amd64/pmap.c U/usr/src/sys/sys/mount.h U/usr/src/sys/sys/systm.h U/usr/src/sys/sys/bio.h U/usr/src/sys/sys/socket.h U/usr/src/sys/sys/domain.h U/usr/src/sys/sys/buf.h U/usr/src/sys/powerpc/powerpc/pmap_dispatch.c U/usr/src/sys/powerpc/aim/mmu_oea64.c U/usr/src/sys/arm/arm/pmap-v6.c U/usr/src/sys/arm/arm/pmap.c U/usr/src/sys/vm/vm_kern.c U/usr/src/sys/vm/vm.h U/usr/src/sys/vm/vm_init.c U/usr/src/sys/vm/swap_pager.c U/usr/src/sys/vm/vnode_pager.c U/usr/src/sys/vm/swap_pager.h U/usr/src/sys/sparc64/sparc64/pmap.c U/usr/src/sys/net80211/ieee80211_freebsd.c U/usr/src/sys/nfsclient/nfs_bio.c U/usr/src/sys/geom/geom_io.c U/usr/src/sys/geom/geom_disk.c U/usr/src/sys/geom/geom_disk.h U/usr/src/sys/geom/part/g_part.c U/usr/src/sys/geom/geom.h U/usr/src/sys/geom/geom_vfs.c U/usr/src/sys/i386/i386/pmap.c U/usr/src/sys/i386/xen/pmap.c U/usr/src/sys/ufs/ufs/ufs_extern.h U/usr/src/sys/ufs/ffs/ffs_alloc.c U/usr/src/sys/ufs/ffs/ffs_balloc.c U/usr/src/sys/ufs/ffs/ffs_vfsops.c U/usr/src/sys/ufs/ffs/ffs_rawread.c U/usr/src/sys/ufs/ffs/ffs_vnops.c U/usr/src/sys/cam/cam_periph.c U/usr/src/sys/cam/cam_ccb.h U/usr/src/sys/cam/scsi/scsi_da.c U/usr/src/sys/cam/scsi/scsi_all.c U/usr/src/sys/cam/scsi/scsi_all.h U/usr/src/sys/cam/scsi/scsi_cd.c U/usr/src/sys/cam/ata/ata_da.c U/usr/src/sys/dev/mii/rgephyreg.h U/usr/src/sys/dev/mii/rgephy.c U/usr/src/sys/dev/usb/usbdevs U/usr/src/sys/dev/usb/serial/u3g.c U/usr/src/sys/dev/ath/if_ath_beacon.c U/usr/src/sys/dev/ath/if_ath_rx.c U/usr/src/sys/dev/ath/if_ath_tx.c U/usr/src/sys/dev/ath/if_ath.c U/usr/src/sys/dev/ath/if_athvar.h U/usr/src/sys/dev/ath/if_ath_rx_edma.c U/usr/src/sys/dev/ath/if_ath_tx_edma.c U/usr/src/sys/dev/siis/siis.c U/usr/src/sys/dev/fdt/fdt_common.c U/usr/src/sys/dev/ahci/ahci.c U/usr/src/sys/dev/md/md.c U/usr/src/sys/kern/kern_physio.c U/usr/src/sys/kern/subr_bus_dma.c U/usr/src/sys/kern/vfs_bio.c U/usr/src/sys/kern/subr_param.c U/usr/src/sys/kern/uipc_usrreq.c U/usr/src/sys/kern/uipc_socket.c U/usr/src/sys/kern/vfs_cluster.c U/usr/src/sys/kern/uipc_syscalls.c U/usr/src/sys/kern/vfs_aio.c U/usr/src/sbin/shutdown/shutdown.8 U/usr/src/sbin/ldconfig/ldconfig.c U/usr/src/sbin/ldconfig/ldconfig.8 Updated to revision 248551. I note that r248084 made some changes in src/sys/vm/ that broke x11/nvidia-driver a few days ago, and I hacked up a patch for that (which sbruno@ committed recently). Still, I had been running (without incident) using that patch And I freely admit that I'm far more of a hacker than a developer; I don't claim familiarity with the VM subsystem at all. But given that nvidia-driver is (evidently) somewhat sensitive with respect to the VM subsystem, I would be unsurprised to find that there might be some undesirable interactions between that and the changes kib@ recently committed to head (e.g., r248508). Unfortunately, I'm just about clueless as to how to get any debugging information out of the system. I'm open to suggestions, and willing to hack and test (and report, of course). Peace, david -- David
Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1
On 20/03/2013 15:20, Matthias Gamsjager wrote: >> Due to the security incident, there are still no official FreeBSD >> packages. >> > > > Do you know what the status is on that issue? Unchanged so far. No official pkgng packages yet. However, an end to the wait is apparently in sight. There has been mention of work on pkgng building systems. Cheers, Matthew ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
I've been having random panics since the VM changes. I'm stuck running r247527. If I try to install a newer kernel/world, I get random panics (I really should enable crashdumps). Not a big deal, but I'm mostly interested in epair fixes and bhyve enhancements. On Wed, Mar 20, 2013 at 12:00 PM, David Wolfskill wrote: > Yesterday, I built head & ran it without incident (as has been the > daily norm for some time now): > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 > r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 > r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > Today, after updating to: > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 > r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 > r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > I find that booting to single-user mode is OK, and I can even start xdm -- > as long as I did not kldload nvidia.ko first. (Indeed, I find that > once loaded, the attempt to unload nvidia.ko appears to hang.) > > If (as has been my practice for the last several years) I loaded > nvidia.ko (via /boot/loader.conf) before attempting to start xdm, > when I do try starting xdm, the machine (my laptop -- no serial > console) quietly initiates a reboot. Mounted file systems don't get > unmounted first, so that tends to be mildly annoying -- and provides > some evidence that the reboot isn't exactly being performed under ideal > conditions (which, I admit, is not all that much of a surprise). > > Here's what happened during the "svn update," so folks can see what > files changed: > > Script started on Wed Mar 20 06:01:32 2013 > svn update /usr/src > Updating '/usr/src': > U/usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp > U/usr/src/share/man/man4/unix.4 > U/usr/src/share/man/man4/iwn.4 > U/usr/src/lib/libc/sys/recv.2 > U/usr/src/lib/libc/sys/socket.2 > U/usr/src/lib/libc/sys/socketpair.2 > U/usr/src/sys/ia64/ia64/pmap.c > U/usr/src/sys/mips/mips/pmap.c > U/usr/src/sys/fs/nfsclient/nfs_clbio.c > U/usr/src/sys/amd64/amd64/pmap.c > U/usr/src/sys/sys/mount.h > U/usr/src/sys/sys/systm.h > U/usr/src/sys/sys/bio.h > U/usr/src/sys/sys/socket.h > U/usr/src/sys/sys/domain.h > U/usr/src/sys/sys/buf.h > U/usr/src/sys/powerpc/powerpc/pmap_dispatch.c > U/usr/src/sys/powerpc/aim/mmu_oea64.c > U/usr/src/sys/arm/arm/pmap-v6.c > U/usr/src/sys/arm/arm/pmap.c > U/usr/src/sys/vm/vm_kern.c > U/usr/src/sys/vm/vm.h > U/usr/src/sys/vm/vm_init.c > U/usr/src/sys/vm/swap_pager.c > U/usr/src/sys/vm/vnode_pager.c > U/usr/src/sys/vm/swap_pager.h > U/usr/src/sys/sparc64/sparc64/pmap.c > U/usr/src/sys/net80211/ieee80211_freebsd.c > U/usr/src/sys/nfsclient/nfs_bio.c > U/usr/src/sys/geom/geom_io.c > U/usr/src/sys/geom/geom_disk.c > U/usr/src/sys/geom/geom_disk.h > U/usr/src/sys/geom/part/g_part.c > U/usr/src/sys/geom/geom.h > U/usr/src/sys/geom/geom_vfs.c > U/usr/src/sys/i386/i386/pmap.c > U/usr/src/sys/i386/xen/pmap.c > U/usr/src/sys/ufs/ufs/ufs_extern.h > U/usr/src/sys/ufs/ffs/ffs_alloc.c > U/usr/src/sys/ufs/ffs/ffs_balloc.c > U/usr/src/sys/ufs/ffs/ffs_vfsops.c > U/usr/src/sys/ufs/ffs/ffs_rawread.c > U/usr/src/sys/ufs/ffs/ffs_vnops.c > U/usr/src/sys/cam/cam_periph.c > U/usr/src/sys/cam/cam_ccb.h > U/usr/src/sys/cam/scsi/scsi_da.c > U/usr/src/sys/cam/scsi/scsi_all.c > U/usr/src/sys/cam/scsi/scsi_all.h > U/usr/src/sys/cam/scsi/scsi_cd.c > U/usr/src/sys/cam/ata/ata_da.c > U/usr/src/sys/dev/mii/rgephyreg.h > U/usr/src/sys/dev/mii/rgephy.c > U/usr/src/sys/dev/usb/usbdevs > U/usr/src/sys/dev/usb/serial/u3g.c > U/usr/src/sys/dev/ath/if_ath_beacon.c > U/usr/src/sys/dev/ath/if_ath_rx.c > U/usr/src/sys/dev/ath/if_ath_tx.c > U/usr/src/sys/dev/ath/if_ath.c > U/usr/src/sys/dev/ath/if_athvar.h > U/usr/src/sys/dev/ath/if_ath_rx_edma.c > U/usr/src/sys/dev/ath/if_ath_tx_edma.c > U/usr/src/sys/dev/siis/siis.c > U/usr/src/sys/dev/fdt/fdt_common.c > U/usr/src/sys/dev/ahci/ahci.c > U/usr/src/sys/dev/md/md.c > U/usr/src/sys/kern/kern_physio.c > U/usr/src/sys/kern/subr_bus_dma.c > U/usr/src/sys/kern/vfs_bio.c > U/usr/src/sys/kern/subr_param.c > U/usr/src/sys/kern/uipc_usrreq.c > U/usr/src/sys/kern/uipc_socket.c > U/usr/src/sys/kern/vfs_cluster.c > U/usr/src/sys/kern/uipc_syscalls.c > U/usr/src/sys/kern/vfs_aio.c > U/usr/src/sbin/shutdown/shutdown.8 > U/usr/src/sbin/ldconfig/ldconfig.c > U/usr/src/sbin/ldconfig/ldconfig.8 > Updated to revision 248551. > > I note that r248084 made some changes in src/sys/vm/ that broke > x11/nvidia-driver a few days ago, and I hacked up a patch for that > (which sbruno@ committed recently). Still, I had been running > (without incident) using that patch And I freely admit that > I'm far more of a hacker than a
Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1
On Wed, Mar 20, 2013 at 04:20:02PM +0100, Matthias Gamsjager wrote: > > Due to the security incident, there are still no official FreeBSD > > packages. > > Do you know what the status is on that issue? I'd also like to find out what the status of this is. The packages at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/ Are still circa October 2012 -- that's 4-5 months ago. While I truly and deeply understand that proper engineering design and infrastructure changes take time, there has been absolutely no communication presented to the community as to what has (or hasn't) transpired, if there is (or isn't) a plan, or if people are simply waiting until future in-person BSD* events to work things out. freebsd-ops-announce has been silent on this matter as well: http://lists.freebsd.org/mailman/listinfo/freebsd-ops-announce At this point users and administrators do not know if newer packages will be made available or if they should stick to building purely from source. Deep down I'm worried that this will solicit a response of "switch to ports-mgmt/pkg and ports-mgmt/poudriere". While I'm not opposed to the tools themselves, I'm strongly opposed to that kind of response as I'm tired of seeing the security incident being used as a opportunistic crutch (as it was for the sudden cvsup/csup deprecation). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 09:00:56AM -0700, David Wolfskill wrote: > Yesterday, I built head & ran it without incident (as has been the > daily norm for some time now): > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 > r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 > r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > Today, after updating to: > > FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 > r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 > r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > I find that booting to single-user mode is OK, and I can even start xdm -- > as long as I did not kldload nvidia.ko first. (Indeed, I find that > once loaded, the attempt to unload nvidia.ko appears to hang.) > > If (as has been my practice for the last several years) I loaded > nvidia.ko (via /boot/loader.conf) before attempting to start xdm, > when I do try starting xdm, the machine (my laptop -- no serial > console) quietly initiates a reboot. Mounted file systems don't get > unmounted first, so that tends to be mildly annoying -- and provides > some evidence that the reboot isn't exactly being performed under ideal > conditions (which, I admit, is not all that much of a surprise). > > Here's what happened during the "svn update," so folks can see what > files changed: > > Script started on Wed Mar 20 06:01:32 2013 > svn update /usr/src > Updating '/usr/src': > U/usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp > U/usr/src/share/man/man4/unix.4 > U/usr/src/share/man/man4/iwn.4 > U/usr/src/lib/libc/sys/recv.2 > U/usr/src/lib/libc/sys/socket.2 > U/usr/src/lib/libc/sys/socketpair.2 > U/usr/src/sys/ia64/ia64/pmap.c > U/usr/src/sys/mips/mips/pmap.c > U/usr/src/sys/fs/nfsclient/nfs_clbio.c > U/usr/src/sys/amd64/amd64/pmap.c > U/usr/src/sys/sys/mount.h > U/usr/src/sys/sys/systm.h > U/usr/src/sys/sys/bio.h > U/usr/src/sys/sys/socket.h > U/usr/src/sys/sys/domain.h > U/usr/src/sys/sys/buf.h > U/usr/src/sys/powerpc/powerpc/pmap_dispatch.c > U/usr/src/sys/powerpc/aim/mmu_oea64.c > U/usr/src/sys/arm/arm/pmap-v6.c > U/usr/src/sys/arm/arm/pmap.c > U/usr/src/sys/vm/vm_kern.c > U/usr/src/sys/vm/vm.h > U/usr/src/sys/vm/vm_init.c > U/usr/src/sys/vm/swap_pager.c > U/usr/src/sys/vm/vnode_pager.c > U/usr/src/sys/vm/swap_pager.h > U/usr/src/sys/sparc64/sparc64/pmap.c > U/usr/src/sys/net80211/ieee80211_freebsd.c > U/usr/src/sys/nfsclient/nfs_bio.c > U/usr/src/sys/geom/geom_io.c > U/usr/src/sys/geom/geom_disk.c > U/usr/src/sys/geom/geom_disk.h > U/usr/src/sys/geom/part/g_part.c > U/usr/src/sys/geom/geom.h > U/usr/src/sys/geom/geom_vfs.c > U/usr/src/sys/i386/i386/pmap.c > U/usr/src/sys/i386/xen/pmap.c > U/usr/src/sys/ufs/ufs/ufs_extern.h > U/usr/src/sys/ufs/ffs/ffs_alloc.c > U/usr/src/sys/ufs/ffs/ffs_balloc.c > U/usr/src/sys/ufs/ffs/ffs_vfsops.c > U/usr/src/sys/ufs/ffs/ffs_rawread.c > U/usr/src/sys/ufs/ffs/ffs_vnops.c > U/usr/src/sys/cam/cam_periph.c > U/usr/src/sys/cam/cam_ccb.h > U/usr/src/sys/cam/scsi/scsi_da.c > U/usr/src/sys/cam/scsi/scsi_all.c > U/usr/src/sys/cam/scsi/scsi_all.h > U/usr/src/sys/cam/scsi/scsi_cd.c > U/usr/src/sys/cam/ata/ata_da.c > U/usr/src/sys/dev/mii/rgephyreg.h > U/usr/src/sys/dev/mii/rgephy.c > U/usr/src/sys/dev/usb/usbdevs > U/usr/src/sys/dev/usb/serial/u3g.c > U/usr/src/sys/dev/ath/if_ath_beacon.c > U/usr/src/sys/dev/ath/if_ath_rx.c > U/usr/src/sys/dev/ath/if_ath_tx.c > U/usr/src/sys/dev/ath/if_ath.c > U/usr/src/sys/dev/ath/if_athvar.h > U/usr/src/sys/dev/ath/if_ath_rx_edma.c > U/usr/src/sys/dev/ath/if_ath_tx_edma.c > U/usr/src/sys/dev/siis/siis.c > U/usr/src/sys/dev/fdt/fdt_common.c > U/usr/src/sys/dev/ahci/ahci.c > U/usr/src/sys/dev/md/md.c > U/usr/src/sys/kern/kern_physio.c > U/usr/src/sys/kern/subr_bus_dma.c > U/usr/src/sys/kern/vfs_bio.c > U/usr/src/sys/kern/subr_param.c > U/usr/src/sys/kern/uipc_usrreq.c > U/usr/src/sys/kern/uipc_socket.c > U/usr/src/sys/kern/vfs_cluster.c > U/usr/src/sys/kern/uipc_syscalls.c > U/usr/src/sys/kern/vfs_aio.c > U/usr/src/sbin/shutdown/shutdown.8 > U/usr/src/sbin/ldconfig/ldconfig.c > U/usr/src/sbin/ldconfig/ldconfig.8 > Updated to revision 248551. > > I note that r248084 made some changes in src/sys/vm/ that broke > x11/nvidia-driver a few days ago, and I hacked up a patch for that > (which sbruno@ committed recently). Still, I had been running > (without incident) using that patch And I freely admit that > I'm far more of a hacker than a developer; I don't claim familiarity > with the VM subsystem at all. But given that nvidia-driver is > (evidently) somewhat sensitive with respect to the VM subsystem, I > would be unsurprised to find that there might be some undesira
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > ... > > I'm open to suggestions, and willing to hack and test (and report, > > of course). > > Did you rebuild the nvidia driver after the update ? Yes; src.conf includes the line: PORTS_MODULES=x11/nvidia-driver > Do you have a core dump partition configured ? d129(10.0-C)[2] grep dump /etc/rc.conf dumpdev="AUTO" > Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see > does it change anything. OK; will report shortly. Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpjwhRzQtsJE.pgp Description: PGP signature
[RFC] small VM patch to review
hello,
would anyone object to the following small patch?
==
Index: vm_pageout.c
===
--- vm_pageout.c(revision 248560)
+++ vm_pageout.c(working copy)
@@ -882,14 +882,17 @@
vm_pageout_init_marker(&marker, PQ_INACTIVE);
- /*
-* Decrease registered cache sizes.
-*/
- EVENTHANDLER_INVOKE(vm_lowmem, 0);
- /*
-* We do this explicitly after the caches have been drained above.
-*/
- uma_reclaim();
+ if (pass) {
+ /*
+* Decrease registered cache sizes.
+*/
+ EVENTHANDLER_INVOKE(vm_lowmem, 0);
+ /*
+* We do this explicitly after the caches have
+* been drained above.
+*/
+ uma_reclaim();
+ }
/*
* The addl_page_shortage is the number of temporarily
==
the idea is to not invoke lowmem handler etc. on first pass in
vm_pageout_scan(). it saves a few CPU cycles on a relatively busy
webserver with moderate amount of RAM serving large-ish files.
thanks,
max
___
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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
on 20/03/2013 19:18 David Wolfskill said the following: > Yes; src.conf includes the line: > > PORTS_MODULES=x11/nvidia-driver Have you double-checked that this actually works according to your intention? -- 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"
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > ... > Did you rebuild the nvidia driver after the update ? > Do you have a core dump partition configured ? (I note that I have, in the past, captured crash dumps from head running on this machine with this configuration.) > Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see > does it change anything. OK; I tried this, then booted without attempting to start X in any way. I then logged in as root and verified that sysctl vfs.unmapped_buf_allowed reported "0". I then issued "kldload nvidia.ko" (and verified that it was loaded via kldstat). I then started xdm, and (as before), got an unclean reboot. (So: no difference in behavior as far as I can tell.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpWIRE86I7Qm.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:37:59AM -0700, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: > > ... > > Did you rebuild the nvidia driver after the update ? > > Do you have a core dump partition configured ? > > (I note that I have, in the past, captured crash dumps from head running > on this machine with this configuration.) > > > Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see > > does it change anything. > > OK; I tried this, then booted without attempting to start X in any way. > I then logged in as root and verified that > > sysctl vfs.unmapped_buf_allowed > > reported "0". > > I then issued "kldload nvidia.ko" (and verified that it was loaded via > kldstat). > > I then started xdm, and (as before), got an unclean reboot. (So: no > difference in behavior as far as I can tell.) Ok. The best idea I have right now is to rebuild the nvidia.ko. Do you have a firewire port on the laptop ? pgp5s25xME8fB.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:24:30PM +0200, Andriy Gapon wrote: > on 20/03/2013 19:18 David Wolfskill said the following: > > Yes; src.conf includes the line: > > > > PORTS_MODULES=x11/nvidia-driver > > Have you double-checked that this actually works according to your intention? > ... Until I started specifying that, the attempt to load nvidia.ko would fail (under head), as the module resides in /boot/modules. Note that I have the (single) drive on this machine split into 4 bootable slices, each of which has its own root and /usr file system. (Slice 4 has the partitions that are "common" to all images -- one for swap; another for the /var FS; one for local SVN mirrors mounted on /repo; one for miscellaneous stuff, such as home directories, ports tree, and /usr/local, which I mount under /common. There's another FS called /bkp, but it's not actually used for much usually.) Since /usr/local is the same FS regardless of which slice is booted (thanks to symlinks), I build the ports under stable/9 (which is on slice 1). On the other hand, head is on slice 4. So building x11/nvidia-driver would populate /usr/local/lib and slice 1's /boot/modules, but would not populate any other slice's /boot/*. This is something I have been doing (in the general sense of multiple bootable slices) for over a decade, and have been doing it for x11/nvidia-driver (in particular) for a few years. I have been tracking stable/9 & head daily for quite a while (years -- note the iteration number in the uname output), and after the smoke-test for stable/9, I update all installed ports that have been updated in the last 24 hrs. -- daily. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNfitzF_Zdn.pgp Description: PGP signature
Re: access to hard drives is "blocked" by writes to a flash drive
On 03/19/2013 18:26, Marcus Reid wrote: On Mon, Mar 04, 2013 at 04:53:10AM +0100, deeptech71 wrote: I use atimes all the time to get to the bottom of lots of common problems. Details ! It sounds like in your case, atime is a debugging feature (which are generally to be turned off on production systems). Turning off atime system-wide is a really bad move. Your bikeshed. Turning off atime works for me. SUPPORT_ATIME=0 would be an *optional* kernel option. Additionally a DEFAULT_NOATIME=1 may be provided. ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > ... > > I then started xdm, and (as before), got an unclean reboot. (So: no > > difference in behavior as far as I can tell.) > > Ok. The best idea I have right now is to rebuild the nvidia.ko. Again? OK > Do you have a firewire port on the laptop ? I do: ... none2@pci0:3:1:1: class=0x0c0010 card=0x02501028 chip=0x08321180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C832 IEEE 1394 Controller' class = serial bus subclass = FireWire ... On the other hand, I'm less sure about any other machines around, or cables that would work. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpHHYnFoMhBh.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > ... > Ok. The best idea I have right now is to rebuild the nvidia.ko. OK; I did this: After rebooting (without attempting to either load nvidia.ko or start X in any way), I issued: sudo portmaster x11/nvidia-driver which rebuilt & reinstalled the driver. I then loaded nvidia.ko, and started xdm -- and as before, the machine performed a fairly hard reset. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp1JbuO3eP3Y.pgp Description: PGP signature
Re: mountroot event
On Wednesday, March 20, 2013 4:30:27 am Andriy Gapon wrote: > > I would like to propose the following change. > > My understanding is that it was never a true intention to post 'mountroot' > event > on every set_rootvnode() call, but rather an accident in the original commit. > But I could be wrong here. In either case I think that it is more appropriate > to post the event only once. I do not expect that there could be any > consumers > interested in all the details of root fs manipulations. The firmware code only needs the final call for the "real" root. I think your change is fine. -- 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"
net/xmlrpc-c-devel port with GCC 4.8
/usr/local/bin/g++48 -o test test.o base64.o registry.o server_abyss.o server_pstream.o tools.o value.o xml.o testclient.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server_abyss++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server_pstream++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_server++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_client++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_client.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc++.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_cpp.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_server_abyss.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_server.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/abyss/src/libxmlrpc_ab yss.a /u s r/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/cpp/libxmlrpc_packetsocket.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/libutil/libxmlrpc_util.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmlparse/libxmlrpc_xmlparse.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmltok/libxmlrpc_xmltok.a -pthread /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc_client.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/src/libxmlrpc.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmlparse/libxmlrpc_xmlparse.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/expat/xmltok/libxmlrpc_xmltok.a /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.32.99/lib/libutil/libxmlrpc_util.a -L/usr/local/lib -lcurl -Wl,-rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -lssh2 -lssl -lcrypto -lz -lssh2 -L/usr/local/lib -lwwwxml -lxmltok -lxmlparse -lwwwzip -lwwwssl -lwwwinit -lwwwapp -lwwwhtml -lwwwtelnet -lwwwnews -lwwwh ttp -lww w mime -lwwwgopher -lwwwftp -lwwwfile -lwwwdir -lwwwcache -lwwwstream -lwwwmux -lwwwtrans -lwwwcore -lwwwutils -lmd5 -lz -L/usr/lib -lssl -lcrypto [...] /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined reference to `std::ctype::_M_widen_init() const' [...] /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' [...] I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to the make-rule. Weird. Why does this work? Should it? ___ 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: net/xmlrpc-c-devel port with GCC 4.8
On Mar 20, 2013, at 19:54, deeptech71 wrote: > /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined > reference to `std::ctype::_M_widen_init() const' > [...] > /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined reference to > `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' > [...] > > I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to the > make-rule. Weird. Why does this work? Should it? The link step is erroneously pulling in /usr/lib/libstdc++.so by default. Since that is an older version of libstdc++, it does not contain the symbols you listed. As you saw, forcing the link stage to use gcc 4.8's version of libstdc++ at least produces an executable. However, there is very likely still a problem at runtime, because the resulting executable probably does not have the correct rpath entry. This is a general problem with the gcc ports: they should all pull in their own version(s) of libstdc++.so instead of using the default linker path. And possibly add rpath entries, to make sure the correct version of libstdc++.so is used at runtime. ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 11:02:39AM -0700, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: > > ... > > Ok. The best idea I have right now is to rebuild the nvidia.ko. > > OK; I did this: After rebooting (without attempting to either load > nvidia.ko or start X in any way), I issued: > > sudo portmaster x11/nvidia-driver > > which rebuilt & reinstalled the driver. > > I then loaded nvidia.ko, and started xdm -- and as before, the machine > performed a fairly hard reset. I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. pgpLIqF5CWk7K.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > ... > I looked at the nvidia sources to check that the driver does not use > the interfaces which KBI was changed, and this is indeed the case, as > expected. OK; thank you for checking & reporting. > I must admit that I have no idea why buffer cache changes could affect > nvidia driver, and with no input on the panic (I hope that it is panic, > and not a reset) have no idea even to speculate. So firewire cable is > probably the must. OK. > Note that I split that import of the work into the series of commits. > The split was done to ease the reading of the chunks, and individual > commits were not functionally tested. Still, you might try to do the > bisect. OK; I'll see what I can do. (It's a little awkward, as I use the laptop to access ... well, just about everything.) Thanks again! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp8Q45XfjkjA.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
I would advise that you try the following: (1) On a machine which is not your laptop, build a CURRENT chroot (2) Follow the instructions at: http://www.freebsd.org/doc/handbook/network-pxe-nfs.html to NFS export the chroot and set up a TFTP server. (3) Set up your laptop to PXE boot using (2). This is one quick way you can test your laptop with CURRENT, without installing all the bits on the disk of your laptop. -- Craig On Wed, Mar 20, 2013 at 1:13 PM, David Wolfskill wrote: > On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > > ... > > I looked at the nvidia sources to check that the driver does not use > > the interfaces which KBI was changed, and this is indeed the case, as > > expected. > > OK; thank you for checking & reporting. > > > I must admit that I have no idea why buffer cache changes could affect > > nvidia driver, and with no input on the panic (I hope that it is panic, > > and not a reset) have no idea even to speculate. So firewire cable is > > probably the must. > > OK. > > > Note that I split that import of the work into the series of commits. > > The split was done to ease the reading of the chunks, and individual > > commits were not functionally tested. Still, you might try to do the > > bisect. > > OK; I'll see what I can do. (It's a little awkward, as I use the laptop > to access ... well, just about everything.) > > Thanks again! > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Craig Rodrigues rodr...@crodrigues.org ___ 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: gptzfsboot problem on HP P410i Smart Array
Dear All,
At present I do not have access to a HP box with a SmartArray
but zfsboot works perfectly with FreeBSD 9.1-RELEASE #0 r245668
(including EDD fix) on:
hpiLO-> show system1
[...]
Properties
name=ProLiant DL160 Gen8
[...]
with the following firmware
hpiLO-> show system1/firmware1
[...]
/system1/firmware1
Targets
Properties
version=J03
date=08/20/2012
[...]
I know it is not much help, but hope it might give you
some input.
Thank you very much indeed for your work on this issue.
Best Regards,
Christoph
--
Christoph Hoffmann
e-mail: christoph_hoffm...@me.com
On Mar 19, 2013, at 5:20 PM, John Baldwin wrote:
> On Tuesday, March 19, 2013 5:55:45 am Andriy Gapon wrote:
>> on 19/03/2013 07:41 Sergey Dyatko said the following:
>>> I was faced with same problem on my laptop. Adding printf() into main()
>>> before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed
>>> patch:
>>> Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c
>>> ===
>>> --- /usr/src/sys/boot/i386/zfsboot/zfsboot.c(revision 248421)
>>> +++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c(working copy)
>>> @@ -302,6 +302,7 @@
>>> * region in the SMAP, use the last 3MB of 'extended' memory as a
>>> * high heap candidate.
>>> */
>>> + high_heap_size = 0;
>>> if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) {
>>>high_heap_size = HEAP_MIN;
>>>high_heap_base = bios_extmem + 0x10 - HEAP_MIN;
>>>
>>> it works for me, without printf() :) Can you test it ?
>>
>> A comment about a nature of this patch.
>>
>> Based on the previous investigation by Christoph Hoffmann and jhb:
>> http://thread.gmane.org/gmane.os.freebsd.current/134199/focus=134309
>> I made a guess that either BIOS/firmware provides incorrect memory map or
>> some
>> agent in the BIOS/firmware (e.g. SMM handler) or controller firmware writes
>> outside of a memory range reserved for it.
>> I think that jhb made a similar guess at the time while Christoph conjectured
>> that memory corruption was related to CPU caches or some such.
>> My conjecture is that it is simply a combination of timing and a particular
>> memory range.
>>
>> Just in case, here is how the memory map looks on the Sergey's system:
>> SMAP type=01 base= end=0009fc00 len=0009fc00
>> SMAP type=02 base=0009fc00 end=000a len=0400
>> SMAP type=02 base=000e end=0010 len=0002
>> SMAP type=01 base=0010 end=bc1a1000 len=bc0a1000
>> SMAP type=04 base=bc1a1000 end=bc1a4000 len=3000
>> SMAP type=01 base=bc1a4000 end=bdf04000 len=01d6
>> SMAP type=04 base=bdf04000 end=bdf3f000 len=0003b000
>> SMAP type=01 base=bdf3f000 end=bdf6a000 len=0002b000
>> SMAP type=02 base=bdf6a000 end=bdfbf000 len=00055000
>> SMAP type=01 base=bdfbf000 end=bdfeb000 len=0002c000
>> SMAP type=03 base=bdfeb000 end=bdfff000 len=00014000
>> SMAP type=01 base=bdfff000 end=be00 len=1000
>> SMAP type=02 base=be00 end=c000 len=0200
>> SMAP type=02 base=f800 end=fc00 len=0400
>> SMAP type=02 base=fec0 end=fec01000 len=1000
>> SMAP type=02 base=fed1 end=fed14000 len=4000
>> SMAP type=02 base=fed18000 end=fed1a000 len=2000
>> SMAP type=02 base=fed1c000 end=fed2 len=4000
>> SMAP type=02 base=fee0 end=fee01000 len=1000
>> SMAP type=02 base=ffe0 end=0001 len=0020
>> SMAP type=01 base=0001 end=00014000 len=4000
>>
>> The algorithm for placing the heap picks up a range at bc1a4000, which is
>> between two ranges of type '4' (ACPI NVS memory).
>> So my idea was just to try a different memory range. Seems that it worked.
>>
>> P.S. I am not sure why our algorithm for selecting heap location is what it
>> is.
>> On all systems that I have I see that the "bios_extmem" range (the one
>> starting
>> at 0x10) is usually the largest one and has more than enough space for
>> both
>> the heap and other things that are placed there.
>
> Yes, we likely could start using that, we would just need to ensure it has
> some
> sort of minimum size. However, maybe it would always have that minimum size
> as you
> are only going to have additional ranges if you have more than 4GB of RAM
> anyway.
> I think though that there were some odd BIOSes that would place a hole at
> 15-16MB,
> and for those the memory region at 1MB is too small. A minimum size of 16MB
> might
> handl
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: > ... > I looked at the nvidia sources to check that the driver does not use > the interfaces which KBI was changed, and this is indeed the case, as > expected. > > I must admit that I have no idea why buffer cache changes could affect > nvidia driver, and with no input on the panic (I hope that it is panic, > and not a reset) have no idea even to speculate. So firewire cable is > probably the must. > > Note that I split that import of the work into the series of commits. > The split was done to ease the reading of the chunks, and individual > commits were not functionally tested. Still, you might try to do the > bisect. I elected to go ahead and try the bisection; here are my results: r248493M/248493: OK r248550M/248551: resets on X startup with nvidia.ko r248521M/248521: resets on X startup with nvidia.ko r248507M/248507: OK r248508M/248508: resets on X startup with nvidia.ko r248493M/248493 was my last working point (built yesterday morning). r248550M/248551 was what failed for me this morning. r248521M/248521 was a convenient mid-point between the above two. r248507M/248507 was the next natural test-point. r248508M/248508 was a guess on my part -- I would normally have gone to r248514, but since I had previously noted that r248508 touched some things that nvidia-driver uses, I thought that test might be worthwhile. I am, however, mildly concerned that no one else appears to be reporting similar symptoms (though I have it on good authority that someone is about to test). Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpsMwuYLMMMc.pgp Description: PGP signature
