Re: amd64/SMP(/ata-raid ?) not happy...

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) _at_ ../../../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"
>