Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Mar 2013 09:00:56 -0700
From:      David Wolfskill <david@catwhisker.org>
To:        current@freebsd.org
Subject:   Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
Message-ID:  <20130320160056.GG32811@albert.catwhisker.org>

next in thread | raw e-mail | index | archive | help

--1giRMj6yz/+FOIRq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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  r2484=
93M/248493: Tue Mar 19 05:57:09 PDT 2013     root@g1-235.catwhisker.org:/us=
r/obj/usr/src/sys/CANARY  i386

Today, after updating to:

FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844  r2485=
50M/248551: Wed Mar 20 06:59:32 PDT 2013     root@g1-235.catwhisker.org:/us=
r/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
--=20
David H. Wolfskill				david@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.

--1giRMj6yz/+FOIRq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlFJ3TcACgkQmprOCmdXAD1VvACfbRV3ylzEhAb/R7r6EcLmlMxV
FokAn1mzsJt2CH4kVtll0FShnRHZl8Fp
=zLgJ
-----END PGP SIGNATURE-----

--1giRMj6yz/+FOIRq--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130320160056.GG32811>