From nobody@FreeBSD.org Fri Sep 21 13:27:10 2001 Return-Path: Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C5B0837B40E for ; Fri, 21 Sep 2001 13:27:09 -0700 (PDT) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f8LKR9W93524; Fri, 21 Sep 2001 13:27:09 -0700 (PDT) (envelope-from nobody) Message-Id: <200109212027.f8LKR9W93524@freefall.freebsd.org> Date: Fri, 21 Sep 2001 13:27:09 -0700 (PDT) From: Yevgeniy Aleynikov To: freebsd-gnats-submit@FreeBSD.org Subject: fatal kernel trap during ufs_rename X-Send-Pr-Version: www-1.0 >Number: 30712 >Category: kern >Synopsis: fatal kernel trap during ufs_rename >Confidential: no >Severity: serious >Priority: high >Responsible: remko >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 21 13:30:01 PDT 2001 >Closed-Date: Fri Jun 15 10:38:32 GMT 2007 >Last-Modified: Fri Jun 15 10:38:32 GMT 2007 >Originator: Yevgeniy Aleynikov >Release: RELENG_4 >Organization: Infospace >Environment: FreeBSD myserver.mydomain.net 4.3-MYTAG FreeBSD 4.3-MYTAG #0: Thu Sep 20 01:24:53 GMT 2001 root@machine.com:/usr/src/sys/compile/config i386 >Description: Currently two independed computers hit that problem. Machine is stanard 1Xtreme boxes shipped by BSDi. DualP3, i440Gx, intel MB, onboard adaptec SCSI, connected to winchester RAID box. Here what i've got: gdb -k /kernel.debug vmcore.4 GNU gdb 4.18 SMP 2 cpus IdlePTD 3039232 initial pcb at 2666a0 panicstr: ufs_rename: lost dir entry panic messages: --- panic: ufs_rename: lost dir entry mp_lock = 01000001; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 syncing disks... 16 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1 buffers Uptime: 16h20m39s ... skipped... >How-To-Repeat: Not sure. >Fix: Couldnt figure out what's wrong. >Release-Note: >Audit-Trail: From: Yevgeniy Aleynikov To: freebsd-gnats-submit@FreeBSD.org, eugenea@infospace.com Cc: Subject: Re: kern/30712: fatal kernel trap during ufs_rename Date: Thu, 27 Sep 2001 15:35:39 -0700 This is getting more serious then i thought. 15 server crashes in last week (different servers). I forgot to notice that all servers have jail environment. -- Yevgeniy Aleynikov Infospace, Inc. SysAdmin, USE Work: (206)357-4594 State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Wed Mar 7 21:15:23 UTC 2007 State-Changed-Why: Hello, was this ever resolved? Responsible-Changed-From-To: freebsd-bugs->remko Responsible-Changed-By: remko Responsible-Changed-When: Wed Mar 7 21:15:23 UTC 2007 Responsible-Changed-Why: Grab the PR http://www.freebsd.org/cgi/query-pr.cgi?pr=30712 State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Fri Jun 15 10:37:10 UTC 2007 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=30712 >Unformatted: >bt #0 dumpsys () at ../../kern/kern_shutdown.c:473 473 ../../kern/kern_shutdown.c: No such file or directory. (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:473 #1 0xc015e9df in boot (howto=256) at ../../kern/kern_shutdown.c:313 #2 0xc015ede0 in poweroff_wait (junk=0xc0233c84, howto=-535697984) at ../../kern/kern_shutdown.c:581 #3 0xc01c2239 in ufs_rename (ap=0xdf4fde60) at ../../ufs/ufs/ufs_vnops.c:1237 #4 0xc01c363d in ufs_vnoperate (ap=0xdf4fde60) at ../../ufs/ufs/ufs_vnops.c:2382 #5 0xc019143b in rename (p=0xdf4c8740, uap=0xdf4fdf80) at vnode_if.h:645 #6 0xc0205011 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134590624, tf_esi = 135163912, tf_ebp = -1077937980, tf_isp = -548413484, tf_ebx = 672122988, tf_edx = 134600160, tf_ecx = 0, tf_eax = 128, tf_trapno = 22, tf_err = 2, tf_eip = 672621324, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938040, tf_ss = 47}) at ../../i386/i386/trap.c:1155 #7 0xc01f291b in Xint0x80_syscall () #8 0x2807e125 in ?? () #9 0x280e7f0c in ?? () #10 0x8048e91 in ?? () #11 0x8048d7d in ?? () (kgdb) This is from 19 sep. snapshot kernel. I had exactly the same problem with Jul 10 snapshot. fsck didnt find anything wrong in filesystem.