From owner-freebsd-bugs Thu Sep 18 11:05:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24118 for bugs-outgoing; Thu, 18 Sep 1997 11:05:41 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24108 for ; Thu, 18 Sep 1997 11:05:34 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id UAA08989 for ; Thu, 18 Sep 1997 20:05:23 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id UAA00559; Thu, 18 Sep 1997 20:05:22 +0200 (MET DST) Message-ID: <19970918200521.RX41144@ida.interface-business.de> Date: Thu, 18 Sep 1997 20:05:21 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-bugs@freebsd.org Subject: Re: My 2.2-stable panic reproduced References: <19970908193559.WU22983@ida.interface-business.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) In-Reply-To: <19970908193559.WU22983@ida.interface-business.de>; from J Wunsch on Sep 8, 1997 19:36:00 +0200 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I once wrote: > panic: vref used where vget required > > syncing disks... 50 50 42 32 21 9 done It hit again. This time, i've got a coredump. panic: vref used where vget required panic: from debugger dumping to dev 401, offset 241664 dump 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 #9 0xf0117e0a in panic () #10 0xf0134b62 in vref () #11 0xf0107740 in iso_iget (xp=0xefbffd60, ino=49152, relocated=1, ipp=0xefbffcec, isodir=0xf0aa354c) at ../../isofs/cd9660/cd9660_node.c:247 #12 0xf010979d in cd9660_root (mp=0xf0a98200, vpp=0xefbffe14) at ../../isofs/cd9660/cd9660_vfsops.c:558 #13 0xf0133888 in lookup () #14 0xf013329b in namei () #15 0xf0137450 in lstat () #16 0xf01c9cb7 in syscall () (kgdb) up 11 #11 0xf0107740 in iso_iget (xp=0xefbffd60, ino=49152, relocated=1, ipp=0xefbffcec, isodir=0xf0aa354c) at ../../isofs/cd9660/cd9660_node.c:247 247 VREF(ip->i_devvp); (kgdb) l 242 ISO_ILOCK(ip); 243 244 imp = VFSTOISOFS (mntp); 245 ip->i_mnt = imp; 246 ip->i_devvp = imp->im_devvp; 247 VREF(ip->i_devvp); 248 249 if (relocated) { 250 /* 251 * On relocated directories we must (kgdb) p ipp $4 = (struct iso_node **) 0xefbffcec (kgdb) p **ipp $5 = {i_chain = {0x0, 0x0}, i_vnode = 0x87654321, i_devvp = 0x0, i_flag = 4069182888, i_dev = 4028788080, i_number = 0, i_mnt = 0xf08a8f94, i_lockf = 0xf0a6d400, i_endoff = 1049104, i_diroff = 0, i_offset = 0, i_ino = 28672, i_spare0 = 28672, i_spare1 = 0, iso_extent = 1024, i_size = -211922944, iso_start = -211922944, inode = {iso_atime = { tv_sec = 65536, tv_nsec = 0}, iso_mtime = {tv_sec = 14888, tv_nsec = 14888}, iso_ctime = {tv_sec = -267137396, tv_nsec = 0}, iso_mode = 0, iso_uid = 0, iso_gid = 0, iso_links = 0, iso_rdev = 0}, i_lockcount = 0} (kgdb) up #12 0xf010979d in cd9660_root (mp=0xf0a98200, vpp=0xefbffe14) at ../../isofs/cd9660/cd9660_vfsops.c:558 558 error = iso_iget(ip,ip->i_number, (kgdb) l 553 554 /* 555 * With RRIP we must use the `.' entry of the root directory. 556 * Simply tell iget, that it's a relocated directory. 557 */ 558 error = iso_iget(ip,ip->i_number, 559 imp->iso_ftype == ISO_FTYPE_RRIP, 560 &nip,dp); 561 if (error) 562 return error; So what? Replace the VREF by a VGET? The i_vnode value of 0x87654321 sounds terribly interesting. See this bug report: Subject: Yet another 2.2-stable NFS (client) panic X-Mailer: Mutt 0.60_p2-3,5,8-9 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x87654371 fault code = supervisor read, page not present instruction pointer = 0x8:0xf013476f stack pointer = 0x10:0xefbffdb0 Exactly the same bogus value. So who the heck is dumping 0x87654321's all over my memory??? -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j