Anders.Hjalmarsson@economics.gu.se wrote:

> Will somebody remind me what the multidisk panics look like ?

what you have below looks pretty much like what i'm seeing.  i can also
get this:

sysinst from memory disk causes:
panic: closef: count < 0
_Debugger(77b024,6,128,77b024,77ef10) + 6
_panic(20c62,77b024,104932c,76a4e0,0) + 52
_closef(77b024,76a4e0,ffffc374,76a4e0,4) + a0
_fdrelease(76a4e0,3,77efa8,13af8,76a4e0) + 70
_sys_close(76a4e0,77ef88,77ef80) + 1c
_syscall(6) + 14c
_trap0() + e

and also:
panic: intr_dispatch: bad vec 0x366
_Debugger()
_panic()
_intr_dispatch()
_intrhand()
_vn_lock()
_spec_open()
_vn_open()
_sys_open()
_syscall()
_trap0


> I wonder if my problem is similar.
> I get a panic with only one disk if I boot singleuser and do
> disklabel -r sd0 (If I do it later it seems to work, no immediate panic)

me too.  if i manage to get into multi-user and then mount partitions on
the second disk, things seem to go ok.  it's very strange.  scott believes
we might have an interrupt handling problem.

> This is on a IIsi with a current kernel for March 23.
> 
> 
> # disklabel -r sd0
> a: HFS_PART 'MacOS' at 96 size 80000
> b: Other (APPLE_FREE) 'Extra' at 80096 size 1984
> panic: pool_get: rusgepl: page empty
> Stopped in disklabel at _Debugger+0x6:  unlk    a6
> db> trace
> _Debugger(ffffc98c,2,0,60cfd8,610f00) + 6
> _panic(1f24f,16273,ffffc98c,1,0) + 52
> __pool_get(f3cf4,2,12f75,a7,ffffc98c) + 118
> _exit1(5fc4e0,100,610fa8,bbb74,5fc4e0) + 52
> _sys_exit(5fc4e0,610f88,610f80) + 12
> _syscall(1) + 148
> _trap0() + e
> db> show reg
> d0              0x2704  _InitEgretJTVec+0x6f4
> d1                 0x4
> d2            0x610edc  _end+0x51ccbc
> d3               0x100
> d4             0x1f24f  _pool_destroy+0x185
> d5                0x13
> d6             0x11170  _statclock+0x92
> d7                 0x2
> a0               0x21e  _KbdType
> a1             0x1ff93  _tablefull+0x1f
> a2             0x203e4  _printf
> a3             0xf3cf4  _rusage_pool
> a4                   0
> a5             0xcb2ac  _sysent+0x8
> a6            0x610eb8  _end+0x51cc98
> sp            0x610eb8  _end+0x51cc98
> pc             0x9155e  _Debugger+0x6
> sr              0x2000  _ADBState+0x1220
> _Debugger+0x6:  unlk    a6
> db> call _pool_chk(_rusage_pool, 0)
> pool(0xf3cf4:rusgepl): page inconsistency: page 0x0; at page head addr 0x60cfd8 (p 0x60c000)
> 0x1
> db> call _pool_print(_rusage_pool, 0)
> pool rusgepl: nalloc 2 nfree 2 npagealloc 1 npagefree 0
>          npages 1 minitems 0 itemsperpage 56 itemoffset 0
>          nidle 1
> 0x2704

hopefully, we'll manage to figure this out before 1.4 gets out of the
door....

later.

colin