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 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). Did you rebuild the nvidia driver after the update ? Do you have a core dump partition configured ? Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see does it change anything.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC