Date: Tue, 05 Sep 2000 15:00:51 -0700 From: Peter Wemm <peter@netplex.com.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: Charlie & <root@pavilion.net>, freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). Message-ID: <200009052200.e85M0pG47083@netplex.com.au> In-Reply-To: <Pine.NEB.3.96L.1000905111845.97056F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Basically a VOP_xxx() only exists somewhere when a filesystem instantiates
it somewhere in its vnode op table. A vop vector is initialized by
implementing it in a filesystem somewhere.
ffs_vnops has:
#ifdef FFS_EXTATTR
{ &vop_getextattr_desc, (vop_t *) ufs_vop_getextattr },
{ &vop_setextattr_desc, (vop_t *) ufs_vop_setextattr },
#endif
As far as vnode_if is concerned, it looks like somebody is calling a
VOP that doesn't exist or is corrupt - it has never been instantiated
anywhere.
Perhaps the vop_panic sanity checking stuff is overly agressive and should
only be activated if there is no vop_default for a filesystem layer.
(I estimate the Terry activation probability at around 99.97% in this thread)
Robert Watson wrote:
>
> So, after even more code reading and debugging -- it appears that
> somewhere in {vnode.h,vnode_if.h->vnode_if.pl,vfs_init.c), the default
> operation is indeed being set to vop_panic() (0?) instead of
> vop_eopnotsupp() (1) as suggested in the vfs_defaults.c source. I'm a bit
> confused by the vnode_if.pl source code, but I suspect that somewhere, a
> set of 0's should be 1's.
>
> So if someone who understands this could take a look, it would be much
> appreciated. In the mean time, to reproduce on -CURRENT, simply make a
> call to acl_get_file(), pointing at a file in UFS. A simple program to do
> this is included in one of the quotes below.
>
> Robert N M Watson
>
> robert@fledge.watson.org http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
>
> On Tue, 5 Sep 2000, Robert Watson wrote:
>
> >
> > Hmm. Sheldon Hearn also seems to be able to reproduce this on -CURRENT,
> > but the ACL code hasn't changed from -STABLE. This leads me to suspect
> > that perhaps it's a change in the vnode interface generating code in
> > vnode_if.pl, possibly the difference between the sh version and the .pl
> > version.
> >
> > vop_getacl is an unusual case in vfs_default.c. Most VOP's have explicit
> > defaults defined in an array in vfs_default, mapping them to a particular
> > error response. vop_getacl (and other VOP's like it) fall back on the
> > default array's default (slot 0, vop_eopnotsupp). In -STABLE, this
> > happens correctly, but in -CURRENT it appears to be broken, instead
> > invoking slot 1, vop_panic() (which should never be called).
> >
> > I've CC'd Peter, because the commit logs seem to suggest that the building
> > of vnode_if.[ch] are currently his baby.
> >
> > Robert N M Watson
> >
> > robert@fledge.watson.org http://www.watson.org/~robert/
> > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
> > TIS Labs at Network Associates, Safeport Network Services
> >
> > On Tue, 5 Sep 2000, Robert Watson wrote:
> >
> > >
> > > On Tue, 5 Sep 2000, Charlie & wrote:
> > >
> > > > Hi Robert,
> > > >
> > > > I'm having kernel panics in the vop_getacl area. Any ideas?
> > > >
> > > > Joe
> > > >
> > > > vop_panic[vop_getacl]
> > > > panic: Filesystem goof
> > > >
> > > (remainder of panic message below, for those curious)
> > >
> > > I'm a bit puzzled by this. On my 4.1-STABLE box, it appears to correctly
> > > return EOPNOTSUPP in the simplist invocation:
> > >
> > > > cat > tmp.c
> > > #include <sys/types.h>
> > > #include <sys/acl.h>
> > >
> > > int
> > > main(int argc, char *argv[])
> > > {
> > > acl_t acl;
> > > int error;
> > >
> > > acl = acl_get_file("/bin/sh", ACL_TYPE_ACCESS);
> > > if (error)
> > > perror("acl_get_file");
> > > }
> > >
> > > > gcc -o tmp tmp.c -lposix1e
> > > > ./tmp
> > > acl_get_file: Operation not supported
> > >
> > > Which is the correct behavior, as none of the base file systems currently
> > > defines ACL functionality. The same should occur for acl_check_file() an
d
> > > acl_set_file(). I haven't tried this on 5.0-CURRENT recently, but
> > > vop_panic() should only be invoked when there is an attempt to call slot
0
> > > of the VOP table for the file system. Slot 1, the default slot, should
> > > return EOPNOTSUPP.
> > >
> > > It looks like you attempted to invoke acl_get_file() much as above. Are
> > > you using any file system modules, and what file system was the target of
> > > acl_get_file() in? Could it be the case that your modules are out of
> > > sync with your kernel? (Not that I'd hope this was the result, but...)
> > >
> > > Robert N M Watson
> > >
> > > robert@fledge.watson.org http://www.watson.org/~robert/
> > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
> > > TIS Labs at Network Associates, Safeport Network Services
> > >
> > > > syncing disks... 59 59 11 2 1
> > > > done
> > > > Uptime: 6m50s
> > > >
> > > > dumping to dev ad0s2b, offset 630912
> > > > dump ata0: resetting devices .. done
> > > > 191 failed, reason: aborted from console
> > > > Automatic reboot in 15 seconds - press a key on the console to abort
> > > > Rebooting...
> > > > Copyright (c) 1992-2000 The FreeBSD Project.
> > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199
4
> > > > The Regents of the University of California. All rights reserve
d.
> > > > FreeBSD 5.0-CURRENT #11: Tue Sep 5 12:45:45 BST 2000
> > > > joe@genius.systems.pavilion.net:/usr/obj/usr/src/sys/GENIUS
> > > > Timecounter "i8254" frequency 1193182 Hz
> > > > Timecounter "TSC" frequency 397896116 Hz
> > > > CPU: Pentium II/Pentium II Xeon/Celeron (397.90-MHz 686-class CPU)
> > > > Origin = "GenuineIntel" Id = 0x66d Stepping = 13
> > > > Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MC
A,CMOV,PAT,PSE36,MMX,FXSR>
> > > > real memory = 201261056 (196544K bytes)
> > > > avail memory = 189722624 (185276K bytes)
> > > > Preloaded elf kernel "kernel" at 0xc0573000.
> > > > Pentium Pro MTRR support enabled
> > > > npx0: <math processor> on motherboard
> > > > npx0: INT 16 interface
> > > > pcib0: <Intel 82443BX host to PCI bridge (AGP disabled)> on motherboard
> > > > pci0: <PCI bus> on pcib0
> > > > isab0: <Intel 82371AB PCI to ISA bridge> at device 7.0 on pci0
> > > > isa0: <ISA bus> on isab0
> > > > atapci0: <Intel PIIX4 ATA33 controller> port 0xfcd0-0xfcdf at device 7.
1 on pci0
> > > > ata0: at 0x1f0 irq 14 on atapci0
> > > > ata1: at 0x170 irq 15 on atapci0
> > > > pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 7.2 irq 9
> > > > pci0: <Intel 82371AB Power management controller> at 7.3
> > > > pci0: <NeoMagic MagicMedia 256AV SVGA controller> at 8.0 irq 9
> > > > pcm0: <NeoMagic 256AV> mem 0xfec00000-0xfecfffff,0xfe000000-0xfe3fffff
irq 9 at device 8.1 on pci0
> > > > pci0: <Sony CXD1947A FireWire Host Controller> at 9.0 irq 9
> > > > pcic-pci0: <Ricoh RL5C478 PCI-CardBus Bridge> at device 10.0 on pci0
> > > > pcic-pci1: <Ricoh RL5C478 PCI-CardBus Bridge> at device 10.1 on pci0
> > > > acpi0: <PTLTD > on motherboard
> > > > acpi0: at 0xb2 irq 9
> > > > fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on is
a0
> > > > fdc0: FIFO enabled, 8 bytes threshold
> > > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> > > > atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> > > > atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
> > > > kbd0 at atkbd0
> > > > psm0: <PS/2 Mouse> irq 12 on atkbdc0
> > > > psm0: model GlidePoint, device ID 0
> > > > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is
a0
> > > > sc0: <System console> at flags 0x100 on isa0
> > > > sc0: VGA <16 virtual consoles, flags=0x300>
> > > > pcic0: <Intel i82365> at port 0x3e0 iomem 0xd0000 irq 10 on isa0
> > > > pcic0: management irq 10
> > > > pccard0: <PC Card bus -- kludge version> on pcic0
> > > > pccard1: <PC Card bus -- kludge version> on pcic0
> > > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> > > > sio0: type 16550A
> > > > sio1: configured irq 3 not in bitmap of probed irqs 0
> > > > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
> > > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
> > > > ppc0: FIFO with 16/16/8 bytes threshold
> > > > plip0: <PLIP network interface> on ppbus0
> > > > lpt0: <Printer> on ppbus0
> > > > lpt0: Interrupt-driven port
> > > > ppi0: <Parallel I/O> on ppbus0
> > > > unknown: <PNP0303> can't assign resources
> > > > unknown: <PNP0700> can't assign resources
> > > > unknown: <PNP0401> can't assign resources
> > > > unknown: <PNP0501> can't assign resources
> > > > unknown: <PNP0f13> can't assign resources
> > > > BRIDGE 990810, have 7 interfaces
> > > > pccard: card inserted, slot 1
> > > > ata1-slave: ata_command: timeout waiting for intr
> > > > ata1-slave: identify failed
> > > > ad0: 19077MB <IBM-DJSA-220> [38760/16/63] at ata0-master using UDMA33
> > > > acd0: DVD-ROM <TOSHIBA DVD-ROM SD-C2202> at ata1-master using UDMA33
> > > > Mounting root from ufs:/dev/ad0s2a
> > > > WARNING: / was not properly dismounted
> > > > pid 115 (savecore), uid 0: exited on signal 10 (core dumped)
> > > > xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 3 slot 1 on pccard1
> > > > xe0: Xircom CE3, bonding version 0x45, 100Mbps capable
> > > > xe0: DingoID = 0, RevisionID = 0, VendorID = 0
> > > > xe0: Ethernet address 00:80:c7:f5:24:e0
> > > > BRIDGE 990810, have 8 interfaces
> > > > -- index 8 type 6 phy 0 addrl 6 addr 00.80.c7.f5.24.e0
> > > > xe0: watchdog timeout; resetting card
> > > > vop_panic[vop_getacl]
> > > > panic: Filesystem goof
> > > > panic: from debugger
> > > > Uptime: 14m53s
> > > >
> > > > dumping to dev ad0s2b, offset 630912
> > > > dump ata0: resetting devices .. done
> > > > 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174
173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 15
5 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 1
36 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118
117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99
98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74
73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49
48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> > > > ---
> > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461
> > > > 461 dumppcb.pcb_cr3 = rcr3();
> > > > (kgdb) bt
> > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461
> > > > #1 0xc017ce0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c
:302
> > > > #2 0xc017d1b1 in panic (fmt=0xc0265f94 "from debugger")
> > > > at /usr/src/sys/kern/kern_shutdown.c:550
> > > > #3 0xc0131dbd in db_panic (addr=-1071373264, have_addr=0, count=-1,
> > > > modif=0xcca77b9c "") at /usr/src/sys/ddb/db_command.c:433
> > > > #4 0xc0131d5d in db_command (last_cmdp=0xc02988f0, cmd_table=0xc029875
0,
> > > > aux_cmd_tablep=0xc02d8128) at /usr/src/sys/ddb/db_command.c:333
> > > > #5 0xc0131e22 in db_command_loop () at /usr/src/sys/ddb/db_command.c:4
55
> > > > #6 0xc0133fdf in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.
c:71
> > > > #7 0xc02421d2 in kdb_trap (type=3, code=0, regs=0xcca77ca4)
> > > > at /usr/src/sys/i386/i386/db_interface.c:158
> > > > #8 0xc024dbb8 in trap (frame={tf_fs = -1072234480, tf_es = -900136944,
> > > > tf_ds = -861470704, tf_edi = -861438236, tf_esi = 256,
> > > > tf_ebp = -861438740, tf_isp = -861438768, tf_ebx = -1071170537,
> > > > tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0,
> > > > tf_eip = -1071373264, tf_cs = 8, tf_eflags = 582, tf_esp = -10710
67969,
> > > > tf_ss = -1071186621}) at /usr/src/sys/i386/i386/trap.c:569
> > > > #9 0xc0242430 in Debugger (msg=0xc026fd43 "panic") at machine/cpufunc.
h:64
> > > > #10 0xc017d1a8 in panic (fmt=0xc0273c17 "Filesystem goof")
> > > > at /usr/src/sys/kern/kern_shutdown.c:548
> > > > #11 0xc01a9653 in vop_panic (ap=0xcca77d24)
> > > > at /usr/src/sys/kern/vfs_default.c:142
> > > > #12 0xc016f377 in vacl_get_acl (p=0xcca69920, vp=0xcbb3da40, type=1,
> > > > ---Type <return> to continue, or q <return> to quit---
> > > > aclp=0x81bd800) at vnode_if.h:1247
> > > > #13 0xc016f52c in __acl_get_file (p=0xcca69920, uap=0xcca77f80)
> > > > at /usr/src/sys/kern/kern_acl.c:155
> > > > #14 0xc024e511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> > > > tf_edi = 1, tf_esi = 136042496, tf_ebp = -1077947632,
> > > > tf_isp = -861437996, tf_ebx = 673380380, tf_edx = 0, tf_ecx = 0,
> > > > tf_eax = 347, tf_trapno = 7, tf_err = 2, tf_eip = 673616088, tf_c
s = 31,
> > > > tf_eflags = 659, tf_esp = -1077947676, tf_ss = 47})
> > > > at /usr/src/sys/i386/i386/trap.c:1150
> > > > #15 0xc0242b15 in Xint0x80_syscall ()
> > > > #16 0x80af7c7 in ?? ()
> > > > #17 0x8077805 in ?? ()
> > > > #18 0x8064275 in ?? ()
> > > > #19 0x806d1f5 in ?? ()
> > > > #20 0x8069041 in ?? ()
> > > > #21 0x8067c63 in ?? ()
> > > > #22 0x809e8b3 in ?? ()
> > > > #23 0x809b0a5 in ?? ()
> > > > #24 0x8082cee in ?? ()
> > > > #25 0x804f345 in ?? ()
> > > > (kgdb) l\11 \11 #11
> > > > Function "" not defined.
> > > > (kgdb) l l /usr/src/sys/kern/vfs_degfaul faui;lt lt.c:142
> > > > 137 int
> > > > 138 vop_panic(struct vop_generic_args *ap)
> > > > 139 {
> > > > 140
> > > > 141 printf("vop_panic[%s]\n", ap->a_desc->vdesc_name);
> > > > 142 panic("Filesystem goof");
> > > > 143 return (0);
> > > > 144 }
> > > > 145
> > > > 146 /*
> > > > (kgdb) quit
> > > > # exit
> > > >
> > > > Script done on Tue Sep 5 15:12:48 2000
> > > >
> > >
> > >
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-fs" in the body of the message
> > >
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-fs" in the body of the message
> >
>
>
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009052200.e85M0pG47083>