From owner-freebsd-current@FreeBSD.ORG Wed Mar 20 16:01:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCCCAD91 for ; Wed, 20 Mar 2013 16:01:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8E38F10E for ; Wed, 20 Mar 2013 16:01:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2KG0uOY041234 for ; Wed, 20 Mar 2013 09:00:56 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2KG0uMX041233 for current@freebsd.org; Wed, 20 Mar 2013 09:00:56 -0700 (PDT) (envelope-from david) Date: Wed, 20 Mar 2013 09:00:56 -0700 From: David Wolfskill To: current@freebsd.org Subject: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver Message-ID: <20130320160056.GG32811@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1giRMj6yz/+FOIRq" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:01:03 -0000 --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--