On Wed, Apr 14, 2010 at 3:01 AM, Victor Latushkin
<victor.latush...@sun.com> wrote:
>
> On Apr 13, 2010, at 9:52 PM, Cyril Plisko wrote:
>
>> Hello !
>>
>> I've had a laptop that crashed a number of times during last 24 hours
>> with this stack:
>>
>> panic[cpu0]/thread=ffffff0007ab0c60:
>> assertion failed: ddt_object_update(ddt, ntype, nclass, dde, tx) == 0,
>> file: ../../common/fs/zfs/ddt.c, line: 968
>>
>>
>> ffffff0007ab09a0 genunix:assfail+7e ()
>> ffffff0007ab0a20 zfs:ddt_sync_entry+2f1 ()
>> ffffff0007ab0a80 zfs:ddt_sync_table+dd ()
>> ffffff0007ab0ae0 zfs:ddt_sync+136 ()
>> ffffff0007ab0ba0 zfs:spa_sync+41f ()
>> ffffff0007ab0c40 zfs:txg_sync_thread+24a ()
>> ffffff0007ab0c50 unix:thread_start+8 ()
>>
>>
>> Is that a known issue ?
>
> There is CR 6912741 with similar stack reported. It is now closed, as problem 
> was seen on some custom kernel, and was not reproducible.
>
>> I have vmdump files available in case people want to have a look.
>
>
> If you can pack and upload your dumps to e.g. supportfiles.sun.com (or 
> provide a link to download), it is definitely interesting to have a look and 
> reopen the bug (or even file a new one).


Hi Victor,

Here we go:

===================================================================
Thanks for your upload

Your file has been stored as "/cores/vmdump.0.7z" on the Supportfiles service.

Size of the file (in bytes) : 169866288.

The file has a cksum of : 2780601688 .

You can verify the checksum of the file by comparing this value with
the output of /usr/bin/cksum filename on your local machine. If there
is any difference in the checksum values, please re-upload the file.


-- 
Regards,
        Cyril
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to