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 ?
I have vmdump files available in case people want to have a look.
--
Regards,
Cyril
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). -- regards victor
On Wed, Apr 14, 2010 at 3:01 AM, Victor Latushkin <Victor.Latushkin at 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