CVSup was at the usual time, 0347 hrs. US/Pacific.  SMP build machine
built, installed, and rebooted just fine.

Trying to do likewise on my (UP) laptop got as far as the reboot, which
got a panic.  I don't have a serial console on the laptop, so I'm hand-
transcribing this:

...
pcm0: pch[2].offset = 0x16000
/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:3" locked from 
/usr/src/sys/dev/sound/pcm/channel.c:677
/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:3" locked from 
/usr/src/sys/dev/sound/pcm/channel.c:677
/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:3" locked from 
/usr/src/sys/dev/sound/pcm/channel.c:677
setmap (7ed000, 4000), nseg=1, error=0
/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:3" locked from 
/usr/src/sys/dev/sound/pcm/channel.c:677
pcm0: pch[3].offset = 0x1a000
Memory modified after free 0xc18fe000(8188)
panic: Most recently used by bus

Debugger("panic")
Stopped at      Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> tr
Debugger(c0473f9c,c05293a0,c04929a3,c0684b78,ffffffff) at Debugger+0x54
panic(c04929a3,c0475700,1ffc,c18e9800,c0b85868) at panic+0x90
mtrash_ctor(c18fe000,2000,0,54c,0) at mtrash_ctor+0x5d
uma_zalloc_arg(c0b85780,0,5,0,c0b85780) at uma_zalloc_arg+0x147
malloc(13a4,c04eb2c0,5,6,c0b8b680) at malloc+0x75
device_set_driver(c0bbd880,c04e1c88,c0b8b6a0,0,0) at device_set_driver+0xb0
device_probe_child(c18e8300,c0bbd880,c04a5c10,c0bbc880,0) at device_probe_child+0x91
device_probe_and_attach(c0bbd880,c18e8300,c0684ca0,c02bda4f,c18e8300) at 
device_probe_and_attach+0x52
bus_generic_attach(c18e8300,c183b098,c04a5c10,c049d978,0) at bus_generic_attach+0x28
device_probe_and_attach(c18e8300,c0bbc880,c0684cc8,c0420990,c0bbc880) at 
device_probe_and_attach+0xaf
bus_generic_attach(c0bbc880,c049d978,0,c0bbc880,c0684cf8) at bus_generic_attach+0x28
nexus_pcib_attach(c0bbc880,c18ac098,c04a5c10,c0b8b850,c18e8400) at 
nexus_pcib_attach+0x30
device_probe_and_attach(c0bbc880,c0bbcc00,c0684d2c,c0412ba4,c0bbcc00) at 
device_probe_and_attach+0xaf
bus_generic_attach(c0bbcc00,0,c0b8b850,c0bb5880,c0bbcc00) at bus_generic_attach+0x28
nexus_attach(c0bbcc00,c1894098,c04a5c10,c0495c60,0) at nexus_attach+0x14
device_probe_and_attach(c0bbcc00,c0bb08d4,c0684d80,c04059f5,c0bbce80) at 
device_probe_and_attach+0xaf
root_bus_configure(c0bbce80,c0495c60,0,c0684d98,c02880b5) at root_bus_configure+0x28
configure(0,681000,681c00,681000,0) at configure+0x35
mi_startup() at mi_startup+0xb5
begin() at begin+0x2c
db> show locks
exclusive sleep mutex Giant r = 0 (0xc04e9140) locked @ /usr/src/sys/vm/vm_object.c:445
db> show pcpu
cpuid        = 0
curthread    = 0xc04e4c20: ppid 0 "swapper"
curpcb       = 0
fpcurthread  = none
idlethread   = 0xc0bc1e40: pid 11 "idle"
currentldt   = 0x28
spin locks held:
db> 


I'll leave the machine in its current state for a while, pending suggestions
for further debugging and/or evasive action.

Thanks,
david
-- 
David H. Wolfskill                              [EMAIL PROTECTED]
To paraphrase David Hilbert, there can be no conflicts between Microsoft
and the discipline of systems administration, since they have nothing in
common.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to