Silent reboots in head @r248550 starting xdm with x11/nvidia-driver

Wed Mar 20 17:13:56 UTC 2013

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@ 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).

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20130320/a67f9b63/attachment.sig>