Re: panic: ffs_blkfree_cg: freeing free block
Date: Fri, 28 Oct 2011 11:16:59 +0200 From: deeptec...@gmail.com deeptec...@gmail.com To: freebsd-current@freebsd.org Subject: panic: ffs_blkfree_cg: freeing free block A panic occured while I was ``rm -rf''ing a large filedirectory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. This panic happens when the free-block bitmap is corrupted. That can happen due to: 1) An unclean filesystem being mounted (though you should get a warning when you attempt to do this). 2) Bit-rot on the disk that is not checked for before mounting. This is typically only an issue for a disk that has been offline for a long time. 3) Write errors to the disk. There have been no changes to the code that manage the filesystem bitmaps in decades (nearly three decades), so a software cause of this panic is unlikely to have been recently introduced. Hence, I would not spend a lot of time trying to get a backtrace, etc. Kirk McKusick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: ffs_blkfree_cg: freeing free block
A panic occured while I was ``rm -rf''ing a large filedirectory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, 28 Oct 2011, deeptec...@gmail.com wrote: A panic occured while I was ``rm -rf''ing a large filedirectory tree (that I just created with untar) on an old drive that I have not used for a long time. Unfortunately I'm not 100% sure that the filesystem was clean when I mounted it today. Could that result in such a panic? I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. Do you know at which revision the kernel was or about from when? Consult uname -a. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 3:40 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Fri, 28 Oct 2011, deeptec...@gmail.com wrote: I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? Meanwhile, I'll take any debug info requests, which I'll attempt to address shortly. Do you know at which revision the kernel was or about from when? Of course. r226289. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: ffs_blkfree_cg: freeing free block
With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com deeptec...@gmail.com wrote: With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? Something stomped on the stack. What was the previous version of FreeBSD (major.minor.subminor, svn revision) at worked? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: ffs_blkfree_cg: freeing free block
On Fri, Oct 28, 2011 at 11:16 AM, deeptec...@gmail.com deeptec...@gmail.com wrote: I don't have the intermediate object files for the kernel; now I'm building the kernel again (from the appropriate, exact sources). That shouldn't harm debugging, should it? On Sat, Oct 29, 2011 at 2:35 AM, Garrett Cooper yaneg...@gmail.com wrote: On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com deeptec...@gmail.com wrote: With object files which were built using the original kernel configuration file (no debugging symbols included): #kgdb kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xc0687d88 in doadump () (kgdb) bt #0 0xc0687d88 in doadump () #1 0xc0688302 in kern_reboot () #2 0xc0688768 in panic () #3 0xc07f92bf in ffs_blkfree_cg () #4 0xc07f9417 in ffs_blkfree () #5 0xc0803259 in ffs_indirtrunc () #6 0xc08042e1 in ffs_truncate () #7 0xc083171c in ufs_inactive () #8 0xc0712718 in vinactive () #9 0xc0716e2a in vputx () #10 0xc071affb in kern_unlinkat () #11 0xc071b1a6 in kern_unlink () #12 0xc071b1ca in sys_unlink () #13 0xc089c954 in syscall () #14 0xc0887021 in Xint0x80_syscall () #15 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) wtf? With object files which were built using a kernel configuration file that had ``makeoptions DEBUG=-g'' inserted compared to the original configuration file: #kgdb kernel.debug /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () wtf? Something stomped on the stack. More like: the release build doesn't have enough debug information in itself, and the release build is not debuggable at all using debug objects that have been built posteriorly. What was the previous version of FreeBSD (major.minor.subminor, svn revision) at worked? Not applicable. The panic occured, out of nowhere, on an r226289 kernel that has been working well and is still working well, with the exception of the panic. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
