amd64/SMP(/ata-raid ?) not happy...
Jeff Roberson
jroberson at chesapeake.net
Sun Nov 30 01:44:38 PST 2003
On Sun, 30 Nov 2003, Poul-Henning Kamp wrote:
>
> Timecounters tick every 10.000 msec
> GEOM: create disk ad0 dp=0xffffff00eebfaca0
> ad0: 35772MB <IBM-DPTA-353750> [72680/16/63] at ata0-master UDMA66
> GEOM: create disk ad4 dp=0xffffff00eebfa4a0
> ad4: 35304MB <WDC WD360GD-00FNA0> [71730/16/63] at ata2-master UDMA133
> GEOM: create disk ad6 dp=0xffffff00eebfa0a0
> ad6: 35304MB <WDC WD360GD-00FNA0> [71730/16/63] at ata3-master UDMA133
> GEOM: create disk ad8 dp=0xffffff00014c4ea0
> ad8: 35304MB <WDC WD360GD-00FNA0> [71730/16/63] at ata4-master UDMA133
> GEOM: create disk ar0 dp=0xffffff00f04a3270
> ar0: 105913MB <ATA RAID0 array> [13502/255/63] status: READY subdisks:
> disk0 READY on ad4 at ata2-master
> disk1 READY on ad6 at ata3-master
> disk2 READY on ad8 at ata4-master
> SMP: AP CPU #1 Launched!
> panic: mtx_lock() of spin mutex (null) @ ../../../vm/uma_core.c:1716
I mailed re about this. There has been some disagreement over how
mp_maxid is implemented on all architectures. Until this gets resolved
and stamped as approved by re, please as mp_maxid++; at line 187 of
amd64/amd64/mp_machdep.c
Thanks,
Jeff
> cpuid = 1;
> Stack backtrace:
> backtrace() at backtrace+0x17
> panic() at panic+0x1d2
> _mtx_lock_flags() at _mtx_lock_flags+0x4f
> uma_zfree_arg() at uma_zfree_arg+0x7e
> g_destroy_bio() at g_destroy_bio+0x1b
> g_disk_done() at g_disk_done+0x85
> biodone() at biodone+0x66
> ad_done() at ad_done+0x31
> ata_completed() at ata_completed+0x237
> taskqueue_run() at taskqueue_run+0x88
> taskqueue_swi_run() at taskqueue_swi_run+0x10
> ithread_loop() at ithread_loop+0x189
> fork_exit() at fork_exit+0xbd
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffad5b0d30, rbp = 0 ---
> Debugger("panic")
> Stopped at Debugger+0x4c: xchgl %ebx,0x2caefe
> db>
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list