Date: Mon, 16 Jul 2001 12:09:48 -0400 From: Bill Moran <wmoran@iowna.com> To: freebsd-stable@freebsd.org Subject: panic in ufs/ffs code Message-ID: <3B5311CC.CC166BE9@iowna.com>
next in thread | raw e-mail | index | archive | help
This is a follow up to the problem I described here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=603165+0+/usr/local/www/db/text/2001/freebsd-hackers/20010624.freebsd-hackers <RANT>The thing wouldn't go a week without a crash - I finally get kernel debugging set up properly and the damn thing goes 24 days without a panic! </RANT> Anyway, I've now got a kernel crash dump. The problem appears to be in the ufs/ffs code. Here is a script of gdb: Script started on Mon Jul 16 11:07:02 2001 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 IdlePTD 3174400 initial pcb at 286640 panicstr: ffs_blkfree: freeing free block panic messages: --- panic: ffs_blkfree: freeing free block syncing disks... 128 123 110 92 66 34 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers Uptime: 24d9h59m3s dumping to dev #ad/0x20021, offset 380616 dump ata2: resetting devices .. done 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:469 469 if (dumping++) { (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469 #1 0xc0152017 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:309 #2 0xc0152394 in poweroff_wait (junk=0xc0252400, howto=-1071307808) at /usr/src/sys/kern/kern_shutdown.c:556 #3 0xc01dada2 in ffs_blkfree (ip=0xc1b57000, bno=0, size=8192) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 #4 0xc01dd06d in ffs_indirtrunc (ip=0xc1b57000, lbn=-12, dbn=115240768, lastbn=-1, level=0, countp=0xcc441d88) at /usr/src/sys/ufs/ffs/ffs_inode.c:498 #5 0xc01dcbbd in ffs_truncate (vp=0xcc78fac0, length=0, flags=0, cred=0x0, p=0xcb0eba00) at /usr/src/sys/ufs/ffs/ffs_inode.c:314 #6 0xc01e719e in ufs_inactive (ap=0xcc441eb4) at /usr/src/sys/ufs/ufs/ufs_inode.c:84 #7 0xc01ec3ed in ufs_vnoperate (ap=0xcc441eb4) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2373 #8 0xc017df9a in vput (vp=0xcc78fac0) at vnode_if.h:815 #9 0xc01811d9 in unlink (p=0xcb0eba00, uap=0xcc441f80) at /usr/src/sys/kern/vfs_syscalls.c:1471 #10 0xc0227ee2 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = 134721536, tf_ebp = -1077936872, tf_isp = -867950636, tf_ebx = 134768128, tf_edx = 134768200, tf_ecx = 0, tf_eax = 10, tf_trapno = 7, tf_err = 2, tf_eip = 134533564, tf_cs = 31, tf_eflags = 643, tf_esp = -1077936916, tf_ss = 47}) ---Type <return> to continue, or q <return> to quit--- at /usr/src/sys/i386/i386/trap.c:1150 #11 0xc021cda5 in Xint0x80_syscall () #12 0x804832b in ?? () #13 0x8048135 in ?? () (kgdb) quit Script done on Mon Jul 16 11:09:29 2001 The machine is running 4.3 at this time, and I checked the ffs file versions against the CVS tree. They are the same versions as are currently availabe in -STABLE. An additional bit of info on this system. The partition that seems to be causing the problem was newfsed with -i 131072. I know this is large, but the average filesize on this partition is almost 500k. I wanted to point that out, however, since it is a large number and might have something to do with the problem. Since I have to newfs the partition to correct the problem anyway, I'll do it with -i at default this time, to see if the problem goes away under those conditions. (It may be another 3 weeks before I get another crash dump, however, since it seems to wait that long when I WANT it to crash!) -Bill -- It may be that true happiness is nothing more than the ability to *always* know the right thing to say at the right time, whereas true misery is the state of perpetually saying to oneself, "What I *should* have said was..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B5311CC.CC166BE9>