Re: Silent reboots in head _at_r248550 starting xdm with x11/nvidia-driver

From: Shawn Webb <lattera_at_gmail.com>
Date: Wed, 20 Mar 2013 12:06:56 -0400
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 <david_at_catwhisker.org>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).
>
> 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.
>
Received on Wed Mar 20 2013 - 15:06:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC