Panics with 5-stable - vinum? raid5?

[Doug White]

On Tue, 22 Feb 2005 daniel at flipse.org wrote:

> Hi there,
>
> I have random, non-reproducable panics every so often (roughly averaging
> once a week) with my Intel server running FreeBSD- 5-stable and I am
> running out of options trying to track down the issue.
>
> Error details:
> Definitely not consistent, generally something like:
> "panic: vm_fault fault on naofault entry, addr:d6f68000"
>
> Turned to debugging kernel, unattended reboot and crash dumping via swap,
> however this doesn't work at all. Kernel options added to GENERIC:
> "makeoptions     DEBUG=-g"
> "options         KDB, GDB, DDB, KDB_UNATTENDED"

This is not the correct syntax. The options need to be on their own lines.

> dumpdev specified correctly in rc.conf (swap parition > mem) and rights
> set correctly and existing /var/crash. Recently cvsed /usr/src, no
> optimizations in /etc/make.conf and world/kernel made in accordance with
> the handbook.

[...]

> kldstat:
> Id Refs Address    Size     Name
>  1    3 0xc0400000 3b05c8   kernel
>  2    1 0xc189c000 dd000    vinum.ko
>  3    1 0xc1a0a000 7000     nullfs.ko

I'd strongly, strongly suggest migrating to gvinum if you can. My
experience has found it vastly more stable on 5.X and seems free of the
odd config problems that have plagued vinum in the 4.X days.

> vinum dumpconfig:
> Drive vinumdrive0:      Device /dev/ad0s1e
> Drive vinumdrive1:      Device /dev/ad2s1e
> Drive vinumdrive2:      Device /dev/ad4s1e
> Drive vinumdrive3:      Device /dev/ad6s1e

This is ok, but:

disklabel /dev/ad0s1:
# /dev/ad0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 77075519        0    4.2BSD     2048 16384 28552
  b:  1048576 77075519      swap
  c: 398283417        0    unused        0     0
  e: 320159322 78124095     vinum

Unfortnately since you've elected to share vinumdrive0 with your root
partition you can't do the gvinum migration. I'd strongly suggest finding
a separate root disk, migrate to it, then convert the remaining 4 disks to
gvinum. If you switched to gvinum now your root partition (ad0s1a) would
be masked (and quite possibly destroyed) by the gvinum conversion.

gvinum generally expects to have the whole disk (or slice?) to itself. le
may be able to expound on the exact reasons for this and if your setup is
actually supported.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite at gumbysoft.com          |  www.FreeBSD.org