panic with vinum
ticso at cicely5.cicely.de
Sun Jun 27 18:18:21 PDT 2004
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
More information about the freebsd-current