I was finally able to replace my old build machine (2x850 MHz PIII) with a considerably faster one over the weekend, and it's been working well. This morning, however, it ddn't power off when its daily duties were ended; this surprised me, as it had done so previously. Some background: The machine in question maintains a private mirror of the FreeBSD.org CVS & SVN repositories. It is also configured (as is my laptop) to boot from any of the 4 slices on drive 0: * slice 1: FreeBSD 6.4-STABLE (stable/6) * slice 2: FreeBSD 7.2-STABLE (stable/7) * slice 3: FreeBSD 8.0-STABLE (stable/8) * slice 4: FreeBSD 9.0-CURRENT (head) (Slices 1 - 3 each contain only 2 partitions; the a partition is for the root file system; the d partition is for the "usr" file system. Slice 4 has those, as well as swap on b and /var on f. I have a couple of other file systems on the other drive.) Anyway, today there were (small, in some cases) changes for each of the 4, so I ended up building each, in the above sequence. Finally, after rebuilding head, then booting it (both as a reality check and to delete old libraries), I'm in the habit of running the command: sudo boot0cfg -s 1 aacd0 && sudo shutdown -p now || sudo shutdown -r now which I did, then went on about other things ... until I noticed the "login: " prompt from the machine's serial console. Hmmm...? So I logged in, noted that it was running 6.4-STABLE, switched to 9.0-CURRENT (via "sudo boot0cfg -s 4 aacd0 && sudo shutdown -r now") and tried the above sequence that includes "shutdown -p now"; the serial console mentioned something about powering off ... but then it didn't do that -- it came bak up again. While that might be an admirable quality in some situations, I rather like the notion that in this relationship, the master is the one with opposable thumbs... and whenm I tell a machine to do something, I don't want it to do something different. :-} I'll try it again & show what I see on the serial console: First, before I do anything, I see |... |Starting background file system checks in 60 seconds. | |Tue Dec 8 07:40:58 PST 2009 | |FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0) | |login: So now I'll login & try the command: |login: david |Password: |Last login: Tue Dec 8 07:42:56 from 172.16.8.13 |... |freebeast(9.0-C)[1] uname -a |FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r200252: Tue Dec 8 06:50:43 PST 2009 root_at_freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 |freebeast(9.0-C)[2] sudo boot0cfg -s 1 aacd0 && sudo shutdown -p now || sudo shutdown -r now |Password:Shutdown NOW! |shutdown: [pid 1403] |freebeast(9.0-C)[3] |*** FINAL System shutdown message from david_at_freebeast.catwhisker.org *** |System going down IMMEDIATELY | | |Dec 8 08:05:02 freebeast shutdown: power-down by david: | |System shutdown Stopping cron. |Stopping sshd. |Stopping cvsupd. |Stopping rsyncd. |Waiting for PIDS: 1135. |Stopping powerd. |Stopping ntpd. |Stopping lpd. |Stopping amd. |Waiting for PIDS: 889. |Stopping ypbind. |Stopping rpcbind. |Stopping devd. |Writing entropy file:. |Terminated |. |Dec 8 08:05:09 freebeast syslogd: exiting on signal 15 |Waiting (max 60 seconds) for system process `vnlru' to stop...done |Waiting (max 60 seconds) for system process `bufdaemon' to stop...done | |Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...7 7 7 7 4 4 3 2 0 0 0 0 done |All buffers synced. |lock order reversal: | 1st 0xc66a67ac ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1204 | 2nd 0xc66a6594 devfs (devfs) _at_ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 |KDB: stack backtrace: |db_trace_self_wrapper(c0c90502,e416499c,c08cc275,c08bd03b,c0c933b8,...) at db_trace_self_wrapper+0x26 |kdb_backtrace(c08bd03b,c0c933b8,c5930500,c5930430,e41649f8,...) at kdb_backtrace+0x29 |_witness_debugger(c0c933b8,c66a6594,c0c81ecc,c5930430,c0cb40ba,...) at _witness_debugger+0x25 |witness_checkorder(c66a6594,9,c0cb40ba,4aa,c66a65b0,...) at witness_checkorder+0x839 |__lockmgr_args(c66a6594,80400,c66a65b0,0,0,...) at __lockmgr_args+0x7a7 |vop_stdlock(e4164b00,556,e4164af8,80400,c66a653c,...) at vop_stdlock+0x62 |VOP_LOCK1_APV(c0d72620,e4164b00,c67b753c,c0db2080,c66a653c,...) at VOP_LOCK1_APV+0xb5 |_vn_lock(c66a653c,80400,c0cb40ba,4aa,c600ac00,...) at _vn_lock+0x5e |ffs_flushfiles(c6721508,2,c5971d80,556,3,...) at ffs_flushfiles+0xa7 |softdep_flushfiles(c6721508,2,c5971d80,c0c9a60e,8aa,...) at softdep_flushfiles+0x2e |ffs_unmount(c6721508,80000,e4164bf4,4f9,e4160008,...) at ffs_unmount+0x149 |dounmount(c6721508,80000,c5971d80,c55a5830,0,...) at dounmount+0x46d |vfs_unmountall(c0c9a2c1,0,c0c8d069,129,0,...) at vfs_unmountall+0x4e |boot(c0de69d0,0,c0c8d069,ac,bfbfe9c0,...) at boot+0x44f |reboot(c5971d80,e4164cf8,4,c0c945ec,c0d76444,...) at reboot+0x69 |syscall(e4164d38) at syscall+0x2a3 |Xint0x80_syscall() at Xint0x80_syscall+0x20 |--- syscall (55, FreeBSD ELF32, reboot), eip = 0x80510b3, esp = 0xbfbfe88c, ebp = 0xbfbfe968 --- |Uptime: 4m36s |aac0: shutting down controller...done |acpi0: Powering system off | And then it starts taking this "Phoenix BIOS" thing a bit too literally (well, I suppose I'm thankful that no flames were involved) and starts booting up again.... I'm pretty sure the poweroff worked as expected yesterday (r200211). As an experiment, I tried booting into single-user mode, then issuing "halt -p" ... yup; same effect. Booting to single-user mode in 8.0-STABLE (slice 3), then issuing "halt -p" appears to work OK. Here's a list (courtesy "svn update") of updates from yesterday to today: U sys/sparc64/sparc64/trap.c U sys/cam/ata/ata_xpt.c U sys/cam/ata/ata_pmp.c U sys/cam/ata/ata_all.c U sys/boot/i386/libi386/libi386.h U sys/boot/i386/libi386/biosmem.c U sys/boot/i386/loader/main.c U sys/ia64/ia64/exception.S U sys/fs/ntfs/ntfs.h U sys/fs/ntfs/ntfs_subr.c U sys/fs/ntfs/ntfs_vfsops.c U sys/dev/e1000/e1000_82575.c U sys/dev/e1000/e1000_ich8lan.h U sys/dev/e1000/e1000_82575.h U sys/dev/e1000/e1000_regs.h U sys/dev/e1000/e1000_api.c U sys/dev/e1000/if_igb.c U sys/dev/e1000/e1000_80003es2lan.c U sys/dev/e1000/if_igb.h U sys/dev/e1000/e1000_defines.h U sys/dev/e1000/e1000_hw.h U sys/dev/e1000/e1000_82541.c U sys/dev/e1000/e1000_80003es2lan.h U sys/dev/e1000/e1000_manage.c U sys/dev/e1000/LICENSE U sys/dev/e1000/e1000_mac.c U sys/dev/e1000/e1000_phy.c U sys/dev/e1000/e1000_phy.h U sys/dev/e1000/if_em.c U sys/dev/e1000/e1000_osdep.h U sys/dev/e1000/if_em.h U sys/dev/e1000/e1000_ich8lan.c U sys/dev/e1000/e1000_82571.c U sys/dev/uart/uart_bus_pci.c U sys/dev/siis/siis.c U sys/dev/siis/siis.h U sys/dev/mfi/mfi.c U sys/dev/aac/aacvar.h U sys/dev/aac/aac.c U sys/dev/aac/aac_cam.c U sys/dev/bge/if_bge.c U sys/dev/ixgbe/ixgbe.c U sys/dev/ixgbe/ixgbe_82599.c U sys/dev/ixgbe/ixgbe_phy.c U sys/dev/ixgbe/ixgbe.h U sys/dev/ixgbe/ixgbe_phy.h U sys/dev/ixgbe/ixgbe_type.h U sys/dev/ixgbe/ixgbe_common.c U sys/dev/ixgbe/ixgbe_api.c U sys/dev/ixgbe/ixgbe_common.h U sys/dev/ixgbe/ixgbe_api.h U sys/dev/ixgbe/ixgbe_82598.c U sys/dev/ixgbe/ixgbe_osdep.h U sys/dev/puc/pucdata.c U sys/dev/usb/input/atp.c U sys/net80211/ieee80211_hostap.c I've attached a dmesg.boot from 9/0-CURRENT, as well. I'm fairly open to testing stuff on the machine, but I'll need a bit of direction. I'm about to build today's CURRENT on my laptop (as it is now doing an installworld for 8.0-STABLE); I'll see if the poweroff acts similarly on it. Peace, david -- David H. Wolfskill david_at_catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC