Panic during attempted power-off ("halt -p")

This was with RELENG_5, built today:

freebeast(5.3)[1] uname -a
FreeBSD freebeast.catwhisker.org 5.3-BETA3 FreeBSD 5.3-BETA3 #14: Sat Sep  4 07:26:33 PDT 2004     root_at_freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.3)[2] 

After building & booting it, then doing some reality checks, things
seemed OK.  So -- as is my custom -- I issued:

	sudo boot0cfg -s 1 ad0 && sudo halt -p || sudo reboot

to shut the machine down (until late tonight).

I got the following (cut/pasted from serial console; some earlier lines
left in for context):

Starting local daemons:.
Updating motd.
Starting ntpd.
Configuring syscons: blanktime.
Starting sshd.
Initial i386 initialization:.
Additional ABI support:.
Starting cron.
Local package initialization:Starting apache.
 cvsupd 
.
Additional TCP options:.
Starting inetd.
Starting background file system checks in 60 seconds.

Sat Sep  4 07:52:34 PDT 2004

FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)

login: [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):260/254/63 s:63 l:4192902
[1] f:00 typ:165 s(CHS):261/0/1 e(CHS):521/254/63 s:4192965 l:4192965
[2] f:80 typ:165 s(CHS):522/0/1 e(CHS):782/254/63 s:8385930 l:4192965
[3] f:00 typ:165 s(CHS):783/0/1 e(CHS):1023/254/63 s:12578895 l:67697910
GEOM: Reconfigure ad0s1, start 32256 length 2146765824 end 2146798079
GEOM: Reconfigure ad0s2, start 2146798080 length 2146798080 end 4293596159
GEOM: Reconfigure ad0s3, start 4293596160 length 2146798080 end 6440394239
GEOM: Reconfigure ad0s4, start 6440394240 length 34661329920 end 41101724159
boot() called on cpu#0
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...1 1 1 0 0 0 done
No buffers busy after final sync
Uptime: 1m36s
Shutting down ACPI
panic: Unknown pri class.
cpuid = 0
KDB: stack backtrace:
kdb_backtrace(100,c19686e0,c06def88,0,c06de880) at kdb_backtrace+0x29
panic(c0685937,38,0,c06de890,1) at panic+0x114
sched_add_internal(c06def38,0) at sched_add_internal+0xf2
kseq_assign(c06de890) at kseq_assign+0x3d
sched_runnable(d41e3d20,c04c52c5,c1967a80,c04c52ac,d41e3d34) at sched_runnable+0x82
cpu_idle(c1967a80,c04c52ac,d41e3d34,c04c5035,0) at cpu_idle+0x1b
idle_proc(0,d41e3d48) at idle_proc+0x19
fork_exit(c04c52ac,0,d41e3d48) at fork_exit+0x75
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd41e3d7c, ebp = 0 ---
KDB: enter: panic

[end of cut/paste....]

Note that the buffers had already been cleared, so no file systems
needed fsck's tender mercies.  And note too, that I do not recall seeing
this panic previously (and I've been tracking RELENG_5 daily since it
was tagged, and HEAD daily before then).

My laptop is finishing up it's "make kernel" as I type, so I don't yet
know if it will be similarly affected.  Note that the system that got
the panic is an SMP machine (while the laptop is not).

Subject to other demands on my time, I'm willing and able to bring the
SMP box back up and poke at it, if anyone would care to provide guidance
as to what to poke.

Thanks,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
Evidence of curmudgeonliness:  becoming irritated with the usage of the
word "speed" in contexts referring to quantification of network
performance, as opposed to "bandwidth" or "latency."