Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jul 2001 08:46:29 +0930
From:      Greg Lehey <grog@FreeBSD.org>
To:        Mark Drayton <mark.drayton@izr.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: newfs/vinum kernel panic
Message-ID:  <20010725084629.K75783@wantadilla.lemis.com>
In-Reply-To: <20010724120439.A2885@drex.staff.izr.com>; from mark.drayton@izr.com on Tue, Jul 24, 2001 at 12:04:39PM %2B0100
References:  <20010724120439.A2885@drex.staff.izr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 24 July 2001 at 12:04:39 +0100, Mark Drayton wrote:
> Hi
>
> I've been testing various vinum combinations to see which is best for a
> mail server. The machine I'm using has 7 4gb SCSI disks with da0s1 as
> the root partition and the other 6 as a striped vinum volume. I'm
> getting a reproducable kernel panic when using "newfs -v
> /dev/vinum/raid10". I wouldn't be surprised if it's a hardware problem -
> the equipment is quite old. However, I'm not sure how to find out.
>
> I've built a debug kernel as described in the FAQ and attached the
> backtrace.

You didn't load the module symbols.  The most interesting frame here
is #6, but there's no information:

> #0  dumpsys () at ../../kern/kern_shutdown.c:469
> 469		if (dumping++) {
> (kgdb) where
> #0  dumpsys () at ../../kern/kern_shutdown.c:469
> #1  0xc015093f in boot (howto=256) at ../../kern/kern_shutdown.c:309
> #2  0xc0150cf0 in poweroff_wait (junk=0xc0276ecf, howto=-880207296)
>     at ../../kern/kern_shutdown.c:556
> #3  0xc024134b in trap_fatal (frame=0xccc6dcd0, eva=28)
>     at ../../i386/i386/trap.c:951
> #4  0xc0240fe1 in trap_pfault (frame=0xccc6dcd0, usermode=0, eva=28)
>     at ../../i386/i386/trap.c:844
> #5  0xc0240b7b in trap (frame={tf_fs = 24, tf_es = -859439088, 
>       tf_ds = -1057488880, tf_edi = 396, tf_esi = -1059782272, 
>       tf_ebp = -859382500, tf_isp = -859382532, tf_ebx = 0, tf_edx = 12699, 
>       tf_ecx = -1069469696, tf_eax = 0, tf_trapno = 12, tf_err = 2, 
>       tf_eip = -1057467227, tf_cs = 8, tf_eflags = 66118, tf_esp = 5520, 
>       tf_ss = -1058951168}) at ../../i386/i386/trap.c:443
> #6  0xc0f854a5 in ?? ()
> #7  0xc0f84a52 in ?? ()
> #8  0xc0f84e53 in ?? ()
> #9  0xc0f84432 in ?? ()
> #10 0xc0f84306 in ?? ()
> #11 0xc014d30b in physio (dev=0xc0ecee00, uio=0xccc6ded4, ioflag=524289)
>     at ../../kern/kern_physio.c:111

From the man page:

     2.   Make sure that you build the vinum module with debugging informa-
          tion.  The standard Makefile builds a module with debugging symbols
          by default.  If the version of vinum in /modules does not contain
          symbols, you will not get an error message, but the stack trace will
          not show the symbols.  Check the module before starting gdb:

          $ file /modules/vinum.ko
          /modules/vinum.ko: ELF 32-bit LSB shared object, Intel 80386,
            version 1 (FreeBSD), not stripped

          If the output shows that /modules/vinum.ko is stripped, you will
          have to find a version which is not.  Usually this will be either in
          /usr/obj/sys/modules/vinum/vinum.ko (if you have built vinum with a
          make world) or /usr/src/sys/modules/vinum/vinum.ko (if you have
          built vinum in this directory).  Modify the file
          .gdbinit.vinum.paths accordingly.

     3.   Either take a dump or use remote serial gdb to analyse the problem.
          To analyse a dump, say /var/crash/vmcore.5, link
          /var/crash/.gdbinit.crash to /var/crash/.gdbinit and enter:

          # cd /var/crash
          # gdb -k kernel.debug vmcore.5

          This example assumes that you have installed the correct debug ker-
          nel at /var/crash/kernel.debug.  If not, substitute the correct name
          of the debug kernel.

> vinum list:
>
> 6 drives:
> D d1                    State: up       Device /dev/da1s1e      Avail: 0/4133 MB (0%)
> D d2                    State: up       Device /dev/da2s1e      Avail: 0/4133 MB (0%)
> D d3                    State: up       Device /dev/da3s1e      Avail: 0/4133 MB (0%)
> D d4                    State: up       Device /dev/da4s1e      Avail: 0/4353 MB (0%)
> D d5                    State: up       Device /dev/da5s1e      Avail: 0/4353 MB (0%)
> D d6                    State: up       Device /dev/da6s1e      Avail: 0/4353 MB (0%)
>
> 1 volumes:
> V raid10                State: up       Plexes:       1 Size:         24 GB
>
> 1 plexes:
> P raid10.p0           S State: up       Subdisks:     6 Size:         24 GB
>
> 6 subdisks:
> S raid10.p0.s0          State: up       PO:        0  B Size:       4133 MB
> S raid10.p0.s1          State: up       PO:      460 kB Size:       4133 MB
> S raid10.p0.s2          State: up       PO:      920 kB Size:       4133 MB
> S raid10.p0.s3          State: up       PO:     1380 kB Size:       4353 MB
> S raid10.p0.s4          State: up       PO:     1840 kB Size:       4353 MB
> S raid10.p0.s5          State: up       PO:     2300 kB Size:       4353 MB
>
> (ignore the volume name; I forgot to change it!)

Look at the sizes of the subdisks.  They're different.  That shouldn't
be possible, but it might be related to your problem.

> Nothing related to the crash in /var/log/messages or
> /var/log/vinum_history.

I would have expected to find a comment about the subdisk sizes in
both places.

Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply.
For more information, see http://www.lemis.com/questions.html
See complete headers for address and phone numbers

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725084629.K75783>