A typo just led me to a panic.. # ls /home/eric/.zfs/snapshots This panics every time I do it. # mdb 3 Loading modules: [ unix krtld genunix specfs ufs ip sctp usba uhci fctl nca lofs zfs random nfs audiosup sppp crypto ipc ptm ]> ::statusdebugging crash dump vmcore.3 (32-bit) from yamano operating system: 5.11 snv_27 (i86pc) panic message: vn_rele: vnode ref count 0 dump content: kernel pages only> ::stackvpanic(3, fe9a2dac) vn_rele+0x5f(d5292704) lo_lookup+0x48c(d85b53c0, d5433cc0, d5433e14, d5433e90, 0, d3c47cc0) fop_lookup+0x2f(d85b53c0, d5433cc0, d5433e14, d5433e90, 0, d3c47cc0) lookuppnvp+0x2c8(d5433e90, 0, 0, 0, d5433f58, d3c47cc0) lookuppnat+0xea(d5433e90, 0, 0, 0, d5433f58, 0) lookupnameat+0x54(8047443, 0, 0, 0, d5433f58, 0) cstatat_getvp+0x13f(ffd19553, 8047443, 1, 0, d5433f58, d5433f5c) cstatat64+0x37() lstat64+0x1f() sys_sysenter+0x100() Running stock snv_27a. -- Eric Enright
Eric Enright wrote:> A typo just led me to a panic.. > # ls /home/eric/.zfs/snapshots > This panics every time I do it. > # mdb 3 > Loading modules: [ unix krtld genunix specfs ufs ip sctp usba uhci > fctl nca lofs zfs random nfs audiosup sppp crypto ipc ptm ] >> ::status > debugging crash dump vmcore.3 (32-bit) from yamano > operating system: 5.11 snv_27 (i86pc) > panic message: vn_rele: vnode ref count 0 > dump content: kernel pages only >> ::stack > vpanic(3, fe9a2dac) > vn_rele+0x5f(d5292704)^^^^^^^^> lo_lookup+0x48c(d85b53c0, d5433cc0, d5433e14, d5433e90, 0, d3c47cc0)Eric, could you please dump the arg to vn_rele for us: 0xd5292704::print struct vnode Is it possible for you to make the core available somewhere? thanks and regards, James C. McPherson -- Solaris Datapath Engineering Data Management Group Sun Microsystems
On 12/9/05, James C. McPherson <James.McPherson at sun.com> wrote:> Eric Enright wrote: > > A typo just led me to a panic.. > > # ls /home/eric/.zfs/snapshots > > This panics every time I do it. > > # mdb 3 > > Loading modules: [ unix krtld genunix specfs ufs ip sctp usba uhci > > fctl nca lofs zfs random nfs audiosup sppp crypto ipc ptm ] > >> ::status > > debugging crash dump vmcore.3 (32-bit) from yamano > > operating system: 5.11 snv_27 (i86pc) > > panic message: vn_rele: vnode ref count 0 > > dump content: kernel pages only > >> ::stack > > vpanic(3, fe9a2dac) > > vn_rele+0x5f(d5292704) > ^^^^^^^^ > > lo_lookup+0x48c(d85b53c0, d5433cc0, d5433e14, d5433e90, 0, d3c47cc0) > > > Eric, > could you please dump the arg to vn_rele for us: > > > 0xd5292704::print struct vnode> 0xd5292704::print struct vnode{ v_lock = { _opaque = [ 0, 0 ] } v_flag = 0 v_count = 0 v_data = 1 v_vfsp = 1 v_stream = 1 v_type = 1 (VREG) v_rdev = 0 v_vfsmountedhere = 0 v_op = 0x74 v_pages = 8 v_npages = 0xd5292734 v_msnpages = 0xd5292734 v_scanfront = 0x74 v_scanback = 0x50 v_filocks = 0xd63fbdf0 v_shrlocks = 0xd7b67330 v_nbllock = { _opaque = [ 0 ] } v_cv = { _opaque = 0 } v_locality = 0xd6619e40 v_femhead = 1 v_path = 0 v_rdcnt = 0 v_wrcnt = 0 v_mmap_read = 0 v_mmap_write = 0 v_mpssdata = 0 v_scantime = 0 v_mset = 0 v_msflags = 0 v_msnext = 0 v_msprev = 0 v_mslock = { _opaque = [ 0 ] } }> Is it possible for you to make the core available somewhere?I''ll post the core shortly and then mail you a link privately. Regards, Eric Enright
Eric Enright wrote:> On 12/9/05, James C. McPherson <James.McPherson at sun.com> wrote: >> Eric Enright wrote: >>> A typo just led me to a panic.. >>> # ls /home/eric/.zfs/snapshots >>> This panics every time I do it..... Hi Eric, This appears to be an instance of 6360864 lofs blows chunks when file does not exist which was logged by Casper Dik this morning. I''ve added your details to the call records for this bug. For Sun folks, Eric''s core is on mdb.eng: cores/jmcp/6360864 cheers, James C. McPherson -- Solaris Datapath Engineering Data Management Group Sun Microsystems
>A typo just led me to a panic.. > ># ls /home/eric/.zfs/snapshots > >This panics every time I do it.I ran into this yesterday; it''s an interaction between lofs and zfs. 6360864 lofs blows chunks when file does not exist (However, I get is only on files that do not exist and not on snapshots) Casper
>Eric Enright wrote: >> On 12/9/05, James C. McPherson <James.McPherson at sun.com> wrote: >>> Eric Enright wrote: >>>> A typo just led me to a panic.. >>>> # ls /home/eric/.zfs/snapshots >>>> This panics every time I do it. >.... > > >Hi Eric, > >This appears to be an instance of > >6360864 lofs blows chunks when file does not exist > >which was logged by Casper Dik this morning.yes, because the name of the snapshot directory is "snapshot" not "snapshots". For those of you who want to serve samba from zfs home directories, mark the snap directory "hidden" so samba doesn''t try to find ".zfs/desktop.ini" in your home directory. The bug is present in builds 27-29 and is caused by an interaction between lofs and zfs (so the bug is in lofs but unique to zfs/lofs) Casper
Thanks a lot Casper. The workaround works fine. I had the same problem and setting the snapdir property to hidden worked. For those who don''t know how to do that, just enter the following command: zfs set snapdir=hidden <zfs name> Thanks a lot, Bertrand. This message posted from opensolaris.org
`mv`ing files from a zfs dir to another zfs filesystem in the same pool will panic a 8 sata zraid http://supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCE.cfm system with ::status debugging crash dump vmcore.3 (64-bit) from zfs operating system: 5.11 opensol-20060523 (i86pc) panic message: assertion failed: !(status & 0x80), file: ../../intel/io/dktp/controller/ata/ata _disk.c, line: 2212 dump content: kernel pages only ::stack vpanic() assfail+0x83(fffffffff3afb508, fffffffff3afb4d8, 8a4) ata_disk_intr_pio_out+0x1dd(ffffffff8f51b840, ffffffff84ff5440, ffffffff911a8d50) ata_ctlr_fsm+0x237(2, ffffffff8f51b840, 0, 0, 0) ata_process_intr+0x3e(ffffffff8f51b840, fffffe80000b3be4) ghd_intr+0x72(ffffffff8f51b958, fffffe80000b3be4) ata_intr+0x25(ffffffff8f51b840) av_dispatch_autovect+0x97(2d) intr_thread+0x50() every time...
It''s curious that your drive is not using DMA. Please append ::msgbuf output and if you can provide access to the core that would be even better. On Fri, 2006-05-26 at 18:55 -0400, Rob Logan wrote:> `mv`ing files from a zfs dir to another zfs filesystem > in the same pool will panic a 8 sata zraid > http://supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCE.cfm > system with > > ::status > debugging crash dump vmcore.3 (64-bit) from zfs > operating system: 5.11 opensol-20060523 (i86pc) > panic message: > assertion failed: !(status & 0x80), file: ../../intel/io/dktp/controller/ata/ata > _disk.c, line: 2212 > dump content: kernel pages only > > ::stack > vpanic() > assfail+0x83(fffffffff3afb508, fffffffff3afb4d8, 8a4) > ata_disk_intr_pio_out+0x1dd(ffffffff8f51b840, ffffffff84ff5440, ffffffff911a8d50) > ata_ctlr_fsm+0x237(2, ffffffff8f51b840, 0, 0, 0) > ata_process_intr+0x3e(ffffffff8f51b840, fffffe80000b3be4) > ghd_intr+0x72(ffffffff8f51b958, fffffe80000b3be4) > ata_intr+0x25(ffffffff8f51b840) > av_dispatch_autovect+0x97(2d) > intr_thread+0x50() > > every time... > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
int sharing issues in bios 1.0c, [XSDT] v1 OEM ID [A M I ] OEM TABLE ID [OEMXSDT ] OEM rev 9000514 [FACP] v3 OEM ID [A M I ] OEM TABLE ID [OEMFACP ] OEM rev 9000514 [DSDT](id 5) - 859 Objects with 89 Devices 277 Methods 17 Regions [APIC] v1 OEM ID [A M I ] OEM TABLE ID [OEMAPIC ] OEM rev 9000514 works correctly with bios 1.1a [XSDT] v1 OEM ID [A M I ] OEM TABLE ID [OEMXSDT ] OEM rev 4000607 [FACP] v3 OEM ID [A M I ] OEM TABLE ID [OEMFACP ] OEM rev 4000607 [DSDT](id 5) - 872 Objects with 89 Devices 277 Methods 17 Regions [APIC] v1 OEM ID [A M I ] OEM TABLE ID [OEMAPIC ] OEM rev 4000607 found via source trail in: nge1: automatic recovery activated fixed in: nge1: ddi_intr_get_supported_types() returned: 1 nge1: nge_add_intrs: interrupt type 0x1 nge1: Using FIXED interrupt type still might turn off audio8100: audio8100: xid=0x05c7, vid1=0x414c, vid2=0x4720 IRQ21 is being shared by drivers with different interrupt levels. zfs group: wow, your stuff is way cool...> It''s curious that your drive is not using DMA. Please append ::msgbuf > output and if you can provide access to the core that would be even > better. > > > On Fri, 2006-05-26 at 18:55 -0400, Rob Logan wrote: >> > `mv`ing files from a zfs dir to another zfs filesystem >> > in the same pool will panic a 8 sata zraid >> > http://supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCE.cfm >> > system with >> > >> > ::status >> > debugging crash dump vmcore.3 (64-bit) from zfs >> > operating system: 5.11 opensol-20060523 (i86pc) >> > panic message: >> > assertion failed: !(status & 0x80), file: ../../intel/io/dktp/controller/ata/ata >> > _disk.c, line: 2212 >> > dump content: kernel pages only >> > >> > ::stack >> > vpanic() >> > assfail+0x83(fffffffff3afb508, fffffffff3afb4d8, 8a4) >> > ata_disk_intr_pio_out+0x1dd(ffffffff8f51b840, ffffffff84ff5440, ffffffff911a8d50) >> > ata_ctlr_fsm+0x237(2, ffffffff8f51b840, 0, 0, 0) >> > ata_process_intr+0x3e(ffffffff8f51b840, fffffe80000b3be4) >> > ghd_intr+0x72(ffffffff8f51b958, fffffe80000b3be4) >> > ata_intr+0x25(ffffffff8f51b840) >> > av_dispatch_autovect+0x97(2d) >> > intr_thread+0x50()