ZFS raid1 crash kernel panic.

[Jeremy Chadwick]

On Wed, Jun 15, 2011 at 04:15:56PM +0400, ?????????????? wrote:
> I have a ZFS raid1 from 2 drives to 1TB <WDC WD1001FALS-00E8B0 05.00K05>.
>   Recently, my system OS: FreeBSD 8.2-RELEASE has crashed, with kernel
> panic:
> 
> --------------------------------
> panic: solaris assert: ss->ss_end >= end (0x6a80753600 >= 0x6a80753800),
> file:
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c,
> line: 174
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> panic: solaris assert: ss->ss_end >= end (0x6a80753600 >= 0x6a80753800),
> file:
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c,
> line: 174
> cpuid = 0
> KDB: stack backtrace:
> #0 0xffffffff805f4e0e at kdb_backtrace+0x5e
> #1 0xffffffff805c2d07 at panic+0x187
> #2 0xffffffff80ee36f6 at space_map_remove+0x296
> #3 0xffffffff80ee3d9b at space_map_load+0x1bb
> #4 0xffffffff80ed4c19 at metaslab_activate+0x89
> #5 0xffffffff80ed586e at metaslab_alloc+0x6ae
> #6 0xffffffff80f00299 at zio_dva_allocate+0x69
> #7 0xffffffff80efe287 at zio_execute+0x77
> #8 0xffffffff80e9e303 at taskq_run_safe+0x13
> #9 0xffffffff805ffeb5 at taskqueue_run_locked+0x85
> #10 0xffffffff8060004e at taskqueue_thread_loop+0x4e
> #11 0xffffffff805994f8 at fork_exit+0x118
> #12 0xffffffff8089547e at fork_trampoline+0xe
> ---------------
> 
> Reinstall OS and import zfs pool not change anything.
> smartctl-a says that everything is OK
> Can anybody tell me what is it?

The panic happens intentionally due to an assertion check.  Assuming
these "solaris asserts" work the same way as KASSERT(), then what the
output says is: "ss->ss_end should be >= end, but obviously 0x6a80753600
is less than 0x6a80753800, thus panic".

ZFS developers, do you have any ideas/explanations for this crash or
what Aleksey can provide to help diagnose the cause?

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |