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 root_at_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 root_at_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_at_ 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_at_ 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 H. Wolfskill david_at_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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC