Hello, We''re repeatedly seeing a kernel panic on our disk server. We''ve been unable to determine exactly how to reproduce it, but it seems to occur fairly frequently (a few times a day). This is happening on both snv91 and snv96. We''ve run ''zpool scrub'' and this has reported no errors. I can try to provide more information if needed. Is there a way to turn on more logging/debugging? Sep 9 09:32:23 ginseng unix: [ID 836849 kern.notice] Sep 9 09:32:23 ginseng ^Mpanic[cpu1]/thread=ffffff01598d6820: Sep 9 09:32:23 ginseng genunix: [ID 403854 kern.notice] assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 116 Sep 9 09:32:23 ginseng unix: [ID 100000 kern.notice] Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03010 genunix:assfail+7e () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d030b0 zfs:zfs_fuid_table_load+1ed () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03100 zfs:zfs_fuid_init+f8 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03140 zfs:zfs_fuid_find_by_idx+3f () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d031a0 zfs:zfs_fuid_map_id+3f () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03250 zfs:zfs_zaccess_common+253 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d032b0 zfs:zfs_zaccess_delete+9f () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03310 zfs:zfs_zaccess_rename+64 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03400 zfs:zfs_rename+2e1 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03490 genunix:fop_rename+c2 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03770 nfssrv:rfs3_rename+3ad () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03a70 nfssrv:common_dispatch+439 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03a90 nfssrv:rfs_dispatch+2d () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03b80 rpcmod:svc_getreq+1c6 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03bf0 rpcmod:svc_run+185 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03c30 rpcmod:svc_do_run+85 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03ec0 nfs:nfssys+770 () Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03f10 unix:brand_sys_sysenter+1e6 () Sep 9 09:32:23 ginseng unix: [ID 100000 kern.notice] Sep 9 09:32:23 ginseng genunix: [ID 672855 kern.notice] syncing file systems... Sep 9 09:32:23 ginseng genunix: [ID 904073 kern.notice] done Sep 9 09:32:24 ginseng genunix: [ID 111219 kern.notice] dumping to /dev/dsk/c5d1s1, offset 429391872, content: kernel Sep 9 09:32:41 ginseng genunix: [ID 409368 kern.notice] ^M100% done: 265125 pages dumped, compression ratio 3.52, Sep 9 09:32:41 ginseng genunix: [ID 851671 kern.notice] dump succeeded -- David -- This message posted from opensolaris.org
David Bartley wrote:> Hello, > > We''re repeatedly seeing a kernel panic on our disk server. We''ve been unable to determine exactly how to reproduce it, but it seems to occur fairly frequently (a few times a day). This is happening on both snv91 and snv96. We''ve run ''zpool scrub'' and this has reported no errors. I can try to provide more information if needed. Is there a way to turn on more logging/debugging? > > Sep 9 09:32:23 ginseng unix: [ID 836849 kern.notice] > Sep 9 09:32:23 ginseng ^Mpanic[cpu1]/thread=ffffff01598d6820: > Sep 9 09:32:23 ginseng genunix: [ID 403854 kern.notice] assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 116 > Sep 9 09:32:23 ginseng unix: [ID 100000 kern.notice] > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03010 genunix:assfail+7e () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d030b0 zfs:zfs_fuid_table_load+1ed () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03100 zfs:zfs_fuid_init+f8 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03140 zfs:zfs_fuid_find_by_idx+3f () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d031a0 zfs:zfs_fuid_map_id+3f () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03250 zfs:zfs_zaccess_common+253 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d032b0 zfs:zfs_zaccess_delete+9f () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03310 zfs:zfs_zaccess_rename+64 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03400 zfs:zfs_rename+2e1 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03490 genunix:fop_rename+c2 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03770 nfssrv:rfs3_rename+3ad () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03a70 nfssrv:common_dispatch+439 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03a90 nfssrv:rfs_dispatch+2d () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03b80 rpcmod:svc_getreq+1c6 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03bf0 rpcmod:svc_run+185 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03c30 rpcmod:svc_do_run+85 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03ec0 nfs:nfssys+770 () > Sep 9 09:32:23 ginseng genunix: [ID 655072 kern.notice] ffffff0005d03f10 unix:brand_sys_sysenter+1e6 () > Sep 9 09:32:23 ginseng unix: [ID 100000 kern.notice] > Sep 9 09:32:23 ginseng genunix: [ID 672855 kern.notice] syncing file systems... > Sep 9 09:32:23 ginseng genunix: [ID 904073 kern.notice] done > Sep 9 09:32:24 ginseng genunix: [ID 111219 kern.notice] dumping to /dev/dsk/c5d1s1, offset 429391872, content: kernel > Sep 9 09:32:41 ginseng genunix: [ID 409368 kern.notice] ^M100% done: 265125 pages dumped, compression ratio 3.52, > Sep 9 09:32:41 ginseng genunix: [ID 851671 kern.notice] dump succeeded > > -- David > --Have you been using the CIFS server? You should only be going down that path for Windows created files and its trying to load Windows domain SID table. -Mark
David Bartley wrote:> On Tue, Sep 9, 2008 at 11:43 AM, Mark Shellenbaum > <Mark.Shellenbaum at sun.com> wrote: >> David Bartley wrote: >>> Hello, >>> >>> We''re repeatedly seeing a kernel panic on our disk server. We''ve been >>> unable to determine exactly how to reproduce it, but it seems to occur >>> fairly frequently (a few times a day). This is happening on both snv91 and >>> snv96. We''ve run ''zpool scrub'' and this has reported no errors. I can try to >>> provide more information if needed. Is there a way to turn on more >>> logging/debugging? >>> >>> -- David >>> -- >> Have you been using the CIFS server? You should only be going down that >> path for Windows created files and its trying to load Windows domain SID >> table. > > No. We have a bunch of linux NFS clients. The machines mount from the > server using a mixture of NFSv3, NFSv4, sys auth, and krb5 auth. >What is the history of this file system? Was is created prior to snv_77 and then upgraded? You most likely have a bad uid/gid on one or more files. Can you post the dump so I can download it? -Mark
I can reliably reproduce this panic with a similar stack trace on a newly installed Solaris 10 10/08 system (I know, not OpenSolaris but it appears to be the same problem). I just opened a support case w/ Sun but then discovered what appear to be the specific steps for me to reproduce it. My setup is a Sol10u6 server, with /export/olddata a ZFS filesystem with sharenfs=root=zeus.mattwilson.local zeus.mattwilson.local is an Ubuntu Linux system. I mount the NFS share with no options, just mount athena:/export/olddata /mnt What I think is causing the problem is that if I copy a file, as root, with owner UID 4294967294 to the Solaris NFS share, using the -a option to GNU cp on the Linux box (which, among other things, preserves the owner), the panic occurs. Other files, with more "reasonable" owners, don''t panic the server. In my case I can avoid the problem by fixing the bad owner ID on the file I''m copying, but not sure if this helps with your situation. My stack was: SolarisCAT(vmcore.2/10X)> stack unix:vpanic_common+0x165() unix:0xfffffffffb84d7c2() genunix:0xfffffffffb9f0c63() zfs:zfs_fuid_table_load+0xac() zfs:zfs_fuid_init+0x53() zfs:zfs_fuid_find_by_idx+0x87() zfs:zfs_fuid_map_id+0x47() zfs:zfs_fuid_map_ids+0x42() zfs:zfs_getattr+0xbc() zfs:zfs_shim_getattr+0x15() genunix:fop_getattr+0x25() nfssrv:rfs4_delegated_getattr+0x9() nfssrv:rfs3_setattr+0x19d() nfssrv:common_dispatch+0x5b8() nfssrv:rfs_dispatch+0x21() rpcmod:svc_getreq+0x209() rpcmod:svc_run+0x124() rpcmod:svc_do_run+0x88() nfs:nfssys+0x16a() unix:_sys_sysenter_post_swapgs+0x14b() -- switch to user thread''s user stack -- panic string: assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 95 On Tue, Sep 9, 2008 at 7:56 AM, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> David Bartley wrote: >> On Tue, Sep 9, 2008 at 11:43 AM, Mark Shellenbaum >> <Mark.Shellenbaum at sun.com> wrote: >>> David Bartley wrote: >>>> Hello, >>>> >>>> We''re repeatedly seeing a kernel panic on our disk server. We''ve been >>>> unable to determine exactly how to reproduce it, but it seems to occur >>>> fairly frequently (a few times a day). This is happening on both snv91 and >>>> snv96. We''ve run ''zpool scrub'' and this has reported no errors. I can try to >>>> provide more information if needed. Is there a way to turn on more >>>> logging/debugging? >>>> >>>> -- David >>>> -- >>> Have you been using the CIFS server? You should only be going down that >>> path for Windows created files and its trying to load Windows domain SID >>> table. >> >> No. We have a bunch of linux NFS clients. The machines mount from the >> server using a mixture of NFSv3, NFSv4, sys auth, and krb5 auth. >> > > What is the history of this file system? Was is created prior to snv_77 > and then upgraded? You most likely have a bad uid/gid on one or more files. > > Can you post the dump so I can download it? > > -Mark > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- Matthew R. Wilson http://www.mattwilson.org/
Matthew R. Wilson wrote:> I can reliably reproduce this panic with a similar stack trace on a > newly installed Solaris 10 10/08 system (I know, not OpenSolaris but > it appears to be the same problem). I just opened a support case w/ > Sun but then discovered what appear to be the specific steps for me to > reproduce it. > > My setup is a Sol10u6 server, with /export/olddata a ZFS filesystem > with sharenfs=root=zeus.mattwilson.local > > zeus.mattwilson.local is an Ubuntu Linux system. I mount the NFS share > with no options, just mount athena:/export/olddata /mnt > > What I think is causing the problem is that if I copy a file, as root, > with owner UID 4294967294 to the Solaris NFS share, using the -a > option to GNU cp on the Linux box (which, among other things, > preserves the owner), the panic occurs. Other files, with more > "reasonable" owners, don''t panic the server. > > In my case I can avoid the problem by fixing the bad owner ID on the > file I''m copying, but not sure if this helps with your situation. >I believe this panic shouldn''t happen on OpenSolaris. It has some extra protection to prevent the panic that doesn''t exist in the S10 code base. Are there any ACLs on the parent directory that would be inherited to the newly created file you tried to copy? If so what are they?> My stack was: > SolarisCAT(vmcore.2/10X)> stack > unix:vpanic_common+0x165() > unix:0xfffffffffb84d7c2() > genunix:0xfffffffffb9f0c63() > zfs:zfs_fuid_table_load+0xac() > zfs:zfs_fuid_init+0x53() > zfs:zfs_fuid_find_by_idx+0x87() > zfs:zfs_fuid_map_id+0x47() > zfs:zfs_fuid_map_ids+0x42() > zfs:zfs_getattr+0xbc() > zfs:zfs_shim_getattr+0x15() > genunix:fop_getattr+0x25() > nfssrv:rfs4_delegated_getattr+0x9() > nfssrv:rfs3_setattr+0x19d() > nfssrv:common_dispatch+0x5b8() > nfssrv:rfs_dispatch+0x21() > rpcmod:svc_getreq+0x209() > rpcmod:svc_run+0x124() > rpcmod:svc_do_run+0x88() > nfs:nfssys+0x16a() > unix:_sys_sysenter_post_swapgs+0x14b() > -- switch to user thread''s user stack -- > > panic string: assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, > FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 95 > > > On Tue, Sep 9, 2008 at 7:56 AM, Mark Shellenbaum > <Mark.Shellenbaum at sun.com> wrote: >> David Bartley wrote: >>> On Tue, Sep 9, 2008 at 11:43 AM, Mark Shellenbaum >>> <Mark.Shellenbaum at sun.com> wrote: >>>> David Bartley wrote: >>>>> Hello, >>>>> >>>>> We''re repeatedly seeing a kernel panic on our disk server. We''ve been >>>>> unable to determine exactly how to reproduce it, but it seems to occur >>>>> fairly frequently (a few times a day). This is happening on both snv91 and >>>>> snv96. We''ve run ''zpool scrub'' and this has reported no errors. I can try to >>>>> provide more information if needed. Is there a way to turn on more >>>>> logging/debugging? >>>>> >>>>> -- David >>>>> -- >>>> Have you been using the CIFS server? You should only be going down that >>>> path for Windows created files and its trying to load Windows domain SID >>>> table. >>> No. We have a bunch of linux NFS clients. The machines mount from the >>> server using a mixture of NFSv3, NFSv4, sys auth, and krb5 auth. >>> >> What is the history of this file system? Was is created prior to snv_77 >> and then upgraded? You most likely have a bad uid/gid on one or more files. >> >> Can you post the dump so I can download it? >> >> -Mark >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > >
On Sun, Nov 2, 2008 at 4:30 PM, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> I believe this panic shouldn''t happen on OpenSolaris. It has some extra > protection to prevent the panic that doesn''t exist in the S10 code base. > > Are there any ACLs on the parent directory that would be inherited to the > newly created file you tried to copy? If so what are they?Nope, no ACL other than regular POSIX mode 755. I did confirm that copying the same file to an snv_99 system does not cause the panic, it looks like the ID gets remapped to the user ''nobody''. Thanks, Matthew
My home server running snv_94 is tipping with the same assertion when someone list a particular file: ::status Loading modules: [ unix genunix specfs dtrace cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp scsi_vhci ufs md ip hook neti sctp arp usba qlc fctl nca lofs zfs audiosup sd cpc random crypto fcip fcp smbsrv nfs logindmux ptm sppp nsctl sdbc sv ii rdc nsmb ipc mpt emlxs ]> ::statusdebugging crash dump vmcore.17 (64-bit) from pearson operating system: 5.11 snv_94 (i86pc) panic message: assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../comm on/fs/zfs/zfs_fuid.c, line: 116 dump content: kernel pages only> $cvpanic() assfail+0x7e(fffffffff83e3a10, fffffffff83e39f0, 74) zfs_fuid_table_load+0x1ed(ffffff025a1c2448, 0, ffffff025a231e88, ffffff025a231eb0) zfs_fuid_init+0xf8(ffffff025a231e40, 0) zfs_fuid_find_by_idx+0x3f(ffffff025a231e40, 40100) zfs_fuid_map_id+0x3f(ffffff025a231e40, 4010020c00001, ffffff02672d0638, 2) zfs_zaccess_common+0x246(ffffff02bc62f4b0, 20000, ffffff000cfcabd0, ffffff000cfcabd4, 0, ffffff02672d0638) zfs_zaccess+0x114(ffffff02bc62f4b0, 20000, 0, 0, ffffff02672d0638) zfs_getacl+0x4c(ffffff02bc62f4b0, ffffff000cfcadd0, 0, ffffff02672d0638) zfs_getsecattr+0x81(ffffff02bf7f9740, ffffff000cfcadd0, 0, ffffff02672d0638, 0) fop_getsecattr+0x8f(ffffff02bf7f9740, ffffff000cfcadd0, 0, ffffff02672d0638, 0) cacl+0x5ae(6, 0, 0, ffffff02bf7f9740, ffffff000cfcae9c) acl+0x8d(80665d2, 6, 0, 0) sys_syscall32+0x101()> ffffff02bf7f9740::print vnode_t{ v_lock = { _opaque = [ 0 ] } v_flag = 0x10000 v_count = 0x2 v_data = 0xffffff02bc62f4b0 v_vfsp = 0xffffff025a0055d0 v_stream = 0 v_type = 1 (VREG) v_rdev = 0xffffffffffffffff v_vfsmountedhere = 0 v_op = 0xffffff02520d2200 v_pages = 0 v_filocks = 0 v_shrlocks = 0 v_nbllock = { _opaque = [ 0 ] } v_cv = { _opaque = 0 } v_locality = 0 v_femhead = 0 v_path = 0xffffff02859d99c8 "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" v_rdcnt = 0 v_wrcnt = 0 v_mmap_read = 0 v_mmap_write = 0 v_mpssdata = 0 v_fopdata = 0 v_vsd = 0 v_xattrdir = 0 v_count_dnlc = 0x1 } An ls -l of "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" results in the system crashing. Need to investigate this further when I get home -- This message posted from opensolaris.org
Chris Gerhard wrote:> My home server running snv_94 is tipping with the same assertion when someone list a particular file: >Failed assertions indicate software bugs. Please file one. http://en.wikipedia.org/wiki/Assertion_(computing) -- richard> ::status > Loading modules: [ unix genunix specfs dtrace cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp scsi_vhci ufs md ip hook neti sctp arp usba qlc fctl nca lofs zfs audiosup sd cpc random crypto fcip fcp smbsrv nfs logindmux ptm sppp nsctl sdbc sv ii rdc nsmb ipc mpt emlxs ] > >> ::status >> > debugging crash dump vmcore.17 (64-bit) from pearson > operating system: 5.11 snv_94 (i86pc) > panic message: > assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../comm > on/fs/zfs/zfs_fuid.c, line: 116 > dump content: kernel pages only > >> $c >> > vpanic() > assfail+0x7e(fffffffff83e3a10, fffffffff83e39f0, 74) > zfs_fuid_table_load+0x1ed(ffffff025a1c2448, 0, ffffff025a231e88, > ffffff025a231eb0) > zfs_fuid_init+0xf8(ffffff025a231e40, 0) > zfs_fuid_find_by_idx+0x3f(ffffff025a231e40, 40100) > zfs_fuid_map_id+0x3f(ffffff025a231e40, 4010020c00001, ffffff02672d0638, 2) > zfs_zaccess_common+0x246(ffffff02bc62f4b0, 20000, ffffff000cfcabd0, > ffffff000cfcabd4, 0, ffffff02672d0638) > zfs_zaccess+0x114(ffffff02bc62f4b0, 20000, 0, 0, ffffff02672d0638) > zfs_getacl+0x4c(ffffff02bc62f4b0, ffffff000cfcadd0, 0, ffffff02672d0638) > zfs_getsecattr+0x81(ffffff02bf7f9740, ffffff000cfcadd0, 0, ffffff02672d0638, 0) > fop_getsecattr+0x8f(ffffff02bf7f9740, ffffff000cfcadd0, 0, ffffff02672d0638, 0) > cacl+0x5ae(6, 0, 0, ffffff02bf7f9740, ffffff000cfcae9c) > acl+0x8d(80665d2, 6, 0, 0) > sys_syscall32+0x101() > >> ffffff02bf7f9740::print vnode_t >> > { > v_lock = { > _opaque = [ 0 ] > } > v_flag = 0x10000 > v_count = 0x2 > v_data = 0xffffff02bc62f4b0 > v_vfsp = 0xffffff025a0055d0 > v_stream = 0 > v_type = 1 (VREG) > v_rdev = 0xffffffffffffffff > v_vfsmountedhere = 0 > v_op = 0xffffff02520d2200 > v_pages = 0 > v_filocks = 0 > v_shrlocks = 0 > v_nbllock = { > _opaque = [ 0 ] > } > v_cv = { > _opaque = 0 > } > v_locality = 0 > v_femhead = 0 > v_path = 0xffffff02859d99c8 "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" > v_rdcnt = 0 > v_wrcnt = 0 > v_mmap_read = 0 > v_mmap_write = 0 > v_mpssdata = 0 > v_fopdata = 0 > v_vsd = 0 > v_xattrdir = 0 > v_count_dnlc = 0x1 > } > > An ls -l of "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" results in the system crashing. > > Need to investigate this further when I get home >
Richard Elling wrote:> Chris Gerhard wrote: >> My home server running snv_94 is tipping with the same assertion when >> someone list a particular file: >> > > Failed assertions indicate software bugs. Please file one. > http://en.wikipedia.org/wiki/Assertion_(computing)A colleague pointed out that it is an exact match for bug 6746456 so I will upgrade to a later build and check that out. Alas in the mean time the power supply on the system has failed to I can''t check this immediately. If it not fixed then I will file a new bug --chris> -- richard > >> ::status >> Loading modules: [ unix genunix specfs dtrace cpu.generic >> cpu_ms.AuthenticAMD.15 uppc pcplusmp scsi_vhci ufs md ip hook neti >> sctp arp usba qlc fctl nca lofs zfs audiosup sd cpc random crypto fcip >> fcp smbsrv nfs logindmux ptm sppp nsctl sdbc sv ii rdc nsmb ipc mpt >> emlxs ] >> >>> ::status >>> >> debugging crash dump vmcore.17 (64-bit) from pearson >> operating system: 5.11 snv_94 (i86pc) >> panic message: assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, >> FTAG, &db), file: ../../comm >> on/fs/zfs/zfs_fuid.c, line: 116 >> dump content: kernel pages only >> >>> $c >>> >> vpanic() >> assfail+0x7e(fffffffff83e3a10, fffffffff83e39f0, 74) >> zfs_fuid_table_load+0x1ed(ffffff025a1c2448, 0, ffffff025a231e88, >> ffffff025a231eb0) >> zfs_fuid_init+0xf8(ffffff025a231e40, 0) >> zfs_fuid_find_by_idx+0x3f(ffffff025a231e40, 40100) >> zfs_fuid_map_id+0x3f(ffffff025a231e40, 4010020c00001, >> ffffff02672d0638, 2) >> zfs_zaccess_common+0x246(ffffff02bc62f4b0, 20000, ffffff000cfcabd0, >> ffffff000cfcabd4, 0, ffffff02672d0638) >> zfs_zaccess+0x114(ffffff02bc62f4b0, 20000, 0, 0, ffffff02672d0638) >> zfs_getacl+0x4c(ffffff02bc62f4b0, ffffff000cfcadd0, 0, ffffff02672d0638) >> zfs_getsecattr+0x81(ffffff02bf7f9740, ffffff000cfcadd0, 0, >> ffffff02672d0638, 0) >> fop_getsecattr+0x8f(ffffff02bf7f9740, ffffff000cfcadd0, 0, >> ffffff02672d0638, 0) >> cacl+0x5ae(6, 0, 0, ffffff02bf7f9740, ffffff000cfcae9c) >> acl+0x8d(80665d2, 6, 0, 0) >> sys_syscall32+0x101() >> >>> ffffff02bf7f9740::print vnode_t >>> >> { >> v_lock = { >> _opaque = [ 0 ] >> } >> v_flag = 0x10000 >> v_count = 0x2 >> v_data = 0xffffff02bc62f4b0 >> v_vfsp = 0xffffff025a0055d0 >> v_stream = 0 >> v_type = 1 (VREG) >> v_rdev = 0xffffffffffffffff >> v_vfsmountedhere = 0 >> v_op = 0xffffff02520d2200 >> v_pages = 0 >> v_filocks = 0 >> v_shrlocks = 0 >> v_nbllock = { >> _opaque = [ 0 ] >> } >> v_cv = { >> _opaque = 0 >> } >> v_locality = 0 >> v_femhead = 0 v_path = 0xffffff02859d99c8 >> "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" >> v_rdcnt = 0 >> v_wrcnt = 0 >> v_mmap_read = 0 >> v_mmap_write = 0 >> v_mpssdata = 0 >> v_fopdata = 0 >> v_vsd = 0 >> v_xattrdir = 0 >> v_count_dnlc = 0x1 >> } >> >> An ls -l of "/tank/fs/shared/pics/MY_Pictures/SMOV0022.AVI" >> results in the system crashing. >> >> Need to investigate this further when I get home >> >-- Chris Gerhard. __o __o __o Systems TSC Chief Technologist _`\<,`\<,`\<,_ Sun Microsystems Limited (*)/---/---/ (*) Phone: +44 (0) 1252 426033 (ext 26033) http://blogs.sun.com/chrisg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081117/7518f848/attachment.bin>
Richard Elling wrote:> Chris Gerhard wrote: >> My home server running snv_94 is tipping with the same assertion when someone list a particular file: >> > > Failed assertions indicate software bugs. Please file one.We learn something new every day! Gavin