Re: panic with vinum

On Sun, Jun 27, 2004 at 03:26:13AM +0200, Bernd Walter wrote:
> On Sat, Jun 26, 2004 at 08:06:42PM +0200, Lukas Ertl wrote:
> > On Sat, 26 Jun 2004, Matthias Schuendehuette wrote:
> > 
> > >On Saturday 26 June 2004 13:56, Lukas Ertl wrote:
> > >>I'm quite sure that recent changes to vfs_mount.c cause this.  I'm
> > >>not sure how to fix it, though.
> > >
> > >At least going back to version 1.128 of vfs_mount.c alone doesn't help.
> > 
> > You probably need to go back to 1.127.
> 
> I saw the same thing with 22th -current on alpha.
> As workaround the vinum volumes are started later for now, but with
> around 1 day uptime:
> 
> fatal kernel trap:
> 
>     trap entry     = 0x2 (memory management fault)
>     cpuid          = 0
>     faulting va    = 0x0
>     type           = access violation
>     cause          = store instruction
>     pc             = 0xfffffc00005e5cb8
>     ra             = 0xfffffe0000377238
>     sp             = 0xfffffe003079da90
>     curthread      = 0xfffffc007aa1e000
>         pid = 32, comm = syncer
> 
> Stopped at      bcopy_samealign_lp:     stq_u   t2,0(a1) <0x0>  <t2=0x18124,a1=0x0>
> db> trace
> bcopy_samealign_lp() at bcopy_samealign_lp
> vinumstart() at vinumstart+0x138
> vinumstrategy() at vinumstrategy+0x118
> prologue botch: displacement 16

I got the same panic again, but it seems that vinum wrote something
bevor the panic happened, which just wasn't put to the console.
On booting I got the following:
Jun 28 03:05:18 cicely12 kernel: vinum: can't allocate 8192 bytes from /var/d2/c12-x/src/sys/dev/vinum/vinumrequest.c:279
This must have been old content, because vinum.ko wasn't loaded yet.

Is the td_intr_nesting_level check in MMalloc still valid in -current?

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd_at_bwct.de                                  info_at_bwct.de