Description of problem: After hibernate and resume filesystem errors show: EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447190(bit 21206 in group 13) EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447191(bit 21207 in group 13) EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447192(bit 21208 in group 13) EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447193(bit 21209 in group 13) EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447194(bit 21210 in group 13) EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 447195(bit 21211 in group 13) fsck: [root@linpus var]# fsck -n /dev/mapper/vg_linpus-lv_root fsck from util-linux-ng 2.17.2 e2fsck 1.41.10 (10-Feb-2009) Warning! /dev/mapper/vg_linpus-lv_root is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Fedora-13-i686-L contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inodes that were part of a corrupted orphan linked list found. Fix? no Inode 6277 was part of the orphaned inode list. IGNORED. Inode 16036 was part of the orphaned inode list. IGNORED. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(33408--33414) -(33432--33445) -(33546--33550) -(34264--34266) -(36374--36375) -(36378--36379) -(48614--48676) -(49970--50213) -(57344--58022) Fix? no Free blocks count wrong for group #2 (371, counted=4649). Fix? no Free blocks count wrong for group #3 (4828, counted=6240). Fix? no Free blocks count wrong for group #4 (4561, counted=5904). Fix? no Free blocks count wrong for group #5 (6245, counted=7015). Fix? no Free blocks count wrong for group #6 (2555, counted=4301). Fix? no Free blocks count wrong for group #7 (4312, counted=10401). Fix? no Free blocks count wrong for group #8 (4455, counted=5201). Fix? no Free blocks count wrong for group #9 (5041, counted=5722). Fix? no Free blocks count wrong for group #10 (8844, counted=8878). Fix? no Free blocks count wrong for group #11 (686, counted=1444). Fix? no Free blocks count wrong for group #12 (11416, counted=11674). Fix? no Free blocks count wrong for group #13 (15721, counted=17183). Fix? no Free blocks count wrong for group #16 (7947, counted=10546). Fix? no Free blocks count wrong (846032, counted=868196). Fix? no Free inodes count wrong for group #0 (0, counted=86). Fix? no Free inodes count wrong for group #1 (0, counted=46). Fix? no Free inodes count wrong for group #2 (1, counted=28). Fix? no Free inodes count wrong for group #3 (0, counted=27). Fix? no Free inodes count wrong for group #4 (3, counted=25). Fix? no Free inodes count wrong for group #6 (0, counted=2). Fix? no Free inodes count wrong for group #7 (0, counted=14). Fix? no Free inodes count wrong for group #8 (1818, counted=1823). Fix? no Free inodes count wrong (311426, counted=311652). Fix? no Fedora-13-i686-L: ********** WARNING: Filesystem still has errors ********** Fedora-13-i686-L: 89982/401408 files (0.1% non-contiguous), 743216/1589248 blocks [root@linpus var]# in /var/run: [root@linpus run]# touch xx touch: setting times of `xx': No such file or directory [root@linpus run]# Version-Release number of selected component (if applicable): Fedora 13 (LXDE spin) How reproducible: suspend/hibernate and resume (sometimes multiple times) Actual results: File system errors Expected results: no file system errors Additional info: [root@linpus smolt]# cat hw-uuid dbb6fc2a-7fac-4633-acbc-35bdfee3e744
Additional info, after reboot I get a ERROR: sil: invalid metadata checksum in area 3 on /dev/dm-1 ERROR: sil: invalid metadata checksum in area 4 on /dev/dm-1 dm-1 is the swap volume
Hi, There seems to be a bug for this over at the kernel.org bugzilla... I'll reference it here: https://bugzilla.kernel.org/show_bug.cgi?id=16019 "Resume from hibernate corrupts ext4" I can confirm this problem on my Acer AspireOne netbook as well, having tested the CPU, RAM, and I/O already, I know it's not a hardware issue. Also, suspending to RAM seems to work fine, but I am still testing that out.
Well, I've been running the machine without any problems for several days now, this time only using suspend to RAM.
Hi, after the update to kernel-2.6.33.6-147.fc13.i686 the problem sees to be gone. The update is a few days old already and I seem to not have this problem any longer. I'll keep testing. Klaus
Klaus, Great news! I was about to say that I don't see the problem anymore on kernel-2.6.35-0.40.rc5.git1.fc14.i686 that I've been testing, but it looks like they backported the fix to the .33 kernels as well. Cheers!
An additional fix may be needed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=cd9f040df6ce46573760a507cb88192d05d27d86
Even with additional fix from comment 6 I see errors from comment 1 on kernel-2.6.34.1-18.mh.fc13.x86_64, that is a version build locally of kernel from http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-13.
Well, I probably was too early, also. I don't have obvious file system errors, but now there are fs related kernel oopses: Jul 18 15:57:45 linpus kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jul 18 15:57:45 linpus kernel: IP: [<c059db0f>] strlen+0xb/0x15 Jul 18 15:57:45 linpus kernel: *pde = 027af067 *pte = 00000000 Jul 18 15:57:45 linpus kernel: Oops: 0000 [#1] SMP Jul 18 15:57:45 linpus kernel: last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1/type Jul 18 15:57:45 linpus kernel: Modules linked in: aes_i586 aes_generic fuse i915 drm_kms_helper drm i2c_algo_bit cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 acerhdf microcode snd_hda_codec_realtek arc4 uvcvideo videodev v4l1_compat snd_hda_intel serio_raw ecb snd_hda_codec joydev snd_hwdep snd_seq snd_seq_device i2c_i801 i2c_core sdhci_pci jmb38x_ms sdhci iTCO_wdt iTCO_vendor_support mmc_core memstick snd_pcm ath5k mac80211 ath r8169 mii cfg80211 rfkill wmi snd_timer snd soundcore snd_page_alloc video output [last unloaded: scsi_wait_scan] Jul 18 15:57:45 linpus kernel: Jul 18 15:57:45 linpus kernel: Pid: 3277, comm: find Not tainted 2.6.33.6-147.fc13.i686 #1 /AOA110 Jul 18 15:57:45 linpus kernel: EIP: 0060:[<c059db0f>] EFLAGS: 00210246 CPU: 1 Jul 18 15:57:45 linpus kernel: EIP is at strlen+0xb/0x15 Jul 18 15:57:45 linpus kernel: EAX: 00000000 EBX: ce298d00 ECX: ffffffff EDX: 00000001 Jul 18 15:57:45 linpus kernel: ESI: dc380000 EDI: 00000000 EBP: d862bf38 ESP: d862bf34 Jul 18 15:57:45 linpus kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Jul 18 15:57:45 linpus kernel: Process find (pid: 3277, ti=d862a000 task=dec1e600 task.ti=d862a000) Jul 18 15:57:45 linpus kernel: Stack: Jul 18 15:57:45 linpus kernel: de40a5a0 d862bf64 c0509ea0 0000000a 00000000 00000003 00000000 c04d35d4 Jul 18 15:57:45 linpus kernel: <0> d862bf90 c0786cc4 ce298d00 c5074ca8 d862bf84 c04d389a d862bf90 c04d35d4 Jul 18 15:57:45 linpus kernel: <0> c5074d20 ce298d00 00000000 00008000 d862bfac c04d3929 c040a645 08d0c030 Jul 18 15:57:45 linpus kernel: Call Trace: Jul 18 15:57:45 linpus kernel: [<c0509ea0>] ? sysfs_readdir+0xb9/0x17b Jul 18 15:57:45 linpus kernel: [<c04d35d4>] ? filldir64+0x0/0xcb Jul 18 15:57:45 linpus kernel: [<c04d389a>] ? vfs_readdir+0x63/0x8f Jul 18 15:57:45 linpus kernel: [<c04d35d4>] ? filldir64+0x0/0xcb Jul 18 15:57:45 linpus kernel: [<c04d3929>] ? sys_getdents64+0x63/0xa5 Jul 18 15:57:45 linpus kernel: [<c040a645>] ? syscall_trace_enter+0xfc/0x111 Jul 18 15:57:45 linpus kernel: [<c0771034>] ? syscall_call+0x7/0xb Jul 18 15:57:45 linpus kernel: [<c0770000>] ? __mutex_lock_common+0x63/0x15f Jul 18 15:57:45 linpus kernel: [<c0770000>] ? __mutex_lock_common+0x63/0x15f Jul 18 15:57:45 linpus kernel: Code: 5d c3 55 89 e5 56 89 c6 89 d0 88 c4 ac 38 e0 74 09 84 c0 75 f7 be 01 00 00 00 89 f0 48 5e 5d c3 55 83 c9 ff 89 e5 57 89 c7 31 c0 <f2> ae f7 d1 49 89 c8 5f 5d c3 55 89 e5 57 31 ff 85 c9 74 0e 89 Jul 18 15:57:45 linpus kernel: EIP: [<c059db0f>] strlen+0xb/0x15 SS:ESP 0068:d862bf34 Jul 18 15:57:45 linpus kernel: CR2: 0000000000000000 Jul 18 15:57:45 linpus kernel: ---[ end trace abec1a791198a304 ]--- and Jul 19 18:21:14 linpus kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Jul 19 18:21:14 linpus kernel: render error detected, EIR: 0x00000000 Jul 19 18:21:14 linpus kernel: [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 213872 at 213870) Jul 19 18:21:30 linpus kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008 Jul 19 18:21:30 linpus kernel: IP: [<c050a4b7>] sysfs_follow_link+0x45/0x121 Jul 19 18:21:30 linpus kernel: *pde = 03d71067 *pte = 00000000 Jul 19 18:21:30 linpus kernel: Oops: 0000 [#1] SMP Jul 19 18:21:30 linpus kernel: last sysfs file: /sys/devices/virtual/block/ram3/uevent Jul 19 18:21:30 linpus kernel: Modules linked in: mmc_block aes_i586 aes_generic fuse i915 drm_kms_helper drm i2c_algo_bit cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 arc4 ecb snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ath5k uvcvideo mac80211 ath iTCO_wdt snd_timer videodev iTCO_vendor_support i2c_i801 sdhci_pci cfg80211 v4l1_compat jmb38x_ms snd sdhci microcode acerhdf r8169 i2c_core joydev serio_raw mmc_core memstick soundcore rfkill wmi mii snd_page_alloc video output [last unloaded: scsi_wait_scan] Jul 19 18:21:30 linpus kernel: Jul 19 18:21:30 linpus kernel: Pid: 3694, comm: udev-acl.ck Not tainted 2.6.33.6-147.fc13.i686 #1 /AOA110 Jul 19 18:21:30 linpus kernel: EIP: 0060:[<c050a4b7>] EFLAGS: 00010286 CPU: 1 Jul 19 18:21:30 linpus kernel: EIP is at sysfs_follow_link+0x45/0x121 Jul 19 18:21:30 linpus kernel: EAX: 00000000 EBX: dc364000 ECX: d1585000 EDX: 0000005e Jul 19 18:21:30 linpus kernel: ESI: de457930 EDI: bff2188c EBP: d339bf04 ESP: d339bee8 Jul 19 18:21:30 linpus kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Jul 19 18:21:30 linpus kernel: Process udev-acl.ck (pid: 3694, ti=d339a000 task=cc4972c0 task.ti=d339a000) Jul 19 18:21:30 linpus kernel: Stack: Jul 19 18:21:30 linpus kernel: d339bef4 d339bf14 d0f13680 d1585000 de36a550 c0786d5c bff2188c d339bf78 Jul 19 18:21:30 linpus kernel: <0> c04cf5a0 00000400 00000000 00000000 00000000 00000000 00000000 00000000 Jul 19 18:21:30 linpus kernel: <0> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Jul 19 18:21:30 linpus kernel: Call Trace: Jul 19 18:21:30 linpus kernel: [<c04cf5a0>] ? generic_readlink+0x28/0x6e Jul 19 18:21:30 linpus kernel: [<c043b0c5>] ? current_fs_time+0x16/0x19 Jul 19 18:21:30 linpus kernel: [<c04d72d0>] ? touch_atime+0x73/0xe6 Jul 19 18:21:30 linpus kernel: [<c056a3d2>] ? selinux_inode_readlink+0x1a/0x1c Jul 19 18:21:30 linpus kernel: [<c04cb477>] ? sys_readlinkat+0x6b/0x7f Jul 19 18:21:30 linpus kernel: [<c04cb49e>] ? sys_readlink+0x13/0x15 Jul 19 18:21:30 linpus kernel: [<c0771034>] ? syscall_call+0x7/0xb Jul 19 18:21:30 linpus kernel: [<c0770000>] ? __mutex_lock_common+0x63/0x15f Jul 19 18:21:30 linpus kernel: Code: 42 f9 ff 85 c0 89 45 f0 0f 84 e3 00 00 00 8b 43 58 8b 70 08 8b 58 14 b8 8c f2 96 c0 e8 0c 5d 26 00 8b 4d f0 eb 2e 8b 43 08 39 c6 <8b> 50 08 74 08 85 d2 74 04 89 d0 eb f1 39 c6 74 23 89 c8 ba a9 Jul 19 18:21:30 linpus kernel: EIP: [<c050a4b7>] sysfs_follow_link+0x45/0x121 SS:ESP 0068:d339bee8 Jul 19 18:21:30 linpus kernel: CR2: 0000000000000008 Jul 19 18:21:30 linpus kernel: ---[ end trace bab1381ba41de4a4 ]--- This is from Jul 18 16:02:57 linpus kernel: Linux version 2.6.33.6-147.fc13.i686 (mockbuild.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Tue Jul 6 22:30:55 UTC 2010 Klaus
I'm still getting those errors, and try to get some usable backtrace. What I can say up to now is, it takes some hibernate cycles, and probably it is necessary to also suspend in between, and, probably more important, the error *always* happens while handling entries in the /sys pseudo file system. I used to use a find /, but I found that find /sys is sufficient, if the system is "ripe" for the panic. I'm playing now with kdump, hoping to get some backtrace Klaus
New feature? After upgrading to kernel-2.6.33.6-147.2.4.fc13.i686 I get kernel oopses with gdb and a few processes, as well as a shutdown failed: Aug 5 18:12:48 linpus kernel: BUG: unable to handle kernel NULL pointer dereference at 00000010 Aug 5 18:12:48 linpus kernel: IP: [<c04c94bd>] __fput+0x19/0x181 Aug 5 18:12:48 linpus kernel: *pde = 1dfa7067 *pte = 00000000 Aug 5 18:12:48 linpus kernel: Oops: 0000 [#1] SMP Aug 5 18:12:48 linpus kernel: last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1/type Aug 5 18:12:48 linpus kernel: Modules linked in: nls_utf8 option usb_wwan usbserial usb_storage aes_i586 aes_generic fuse i915 drm_kms_helper drm i2c_algo_bit cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq acerhdf snd_seq_device microcode arc4 ecb uvcvideo snd_pcm videodev v4l1_compat mmc_block i2c_i801 iTCO_wdt joydev i2c_core iTCO_vendor_support serio_raw ath5k mac80211 ath sdhci_pci snd_timer sdhci snd r8169 mmc_core cfg80211 jmb38x_ms mii rfkill soundcore snd_page_alloc memstick wmi video output [last unloaded: scsi_wait_scan] Aug 5 18:12:48 linpus kernel: Aug 5 18:12:48 linpus kernel: Pid: 6932, comm: gdb Not tainted 2.6.33.6-147.2.4.fc13.i686 #1 /AOA110 Aug 5 18:12:48 linpus kernel: EIP: 0060:[<c04c94bd>] EFLAGS: 00210282 CPU: 0 Aug 5 18:12:48 linpus kernel: EIP is at __fput+0x19/0x181 Aug 5 18:12:48 linpus kernel: EAX: 00000000 EBX: dc2d1000 ECX: 00000000 EDX: 00000000 Aug 5 18:12:48 linpus kernel: ESI: dc94c1c0 EDI: ddf47f64 EBP: ddf47f38 ESP: ddf47f1c Aug 5 18:12:48 linpus kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Aug 5 18:12:48 linpus kernel: Process gdb (pid: 6932, ti=ddf46000 task=de463fc0 task.ti=ddf46000) Aug 5 18:12:48 linpus kernel: Stack: Aug 5 18:12:48 linpus kernel: 00000000 00000000 00200246 dc94c1c0 dc2d1000 dc94c1c0 ddf47f64 ddf47f40 Aug 5 18:12:48 linpus kernel: <0> c04c9638 ddf47f54 c050148e fffffff3 dcfcf098 ddf47f64 ddf47f78 c04fff75 Aug 5 18:12:48 linpus kernel: <0> 0a47ef40 00001000 00000000 00000000 c0784f78 00001000 00000000 ddf47f94 Aug 5 18:12:48 linpus kernel: Call Trace: Aug 5 18:12:48 linpus kernel: [<c04c9638>] ? fput+0x13/0x15 Aug 5 18:12:48 linpus kernel: [<c050148e>] ? proc_exe_link+0x53/0x61 Aug 5 18:12:48 linpus kernel: [<c04fff75>] ? proc_pid_readlink+0x2c/0xa0 Aug 5 18:12:48 linpus kernel: [<c04cb477>] ? sys_readlinkat+0x6b/0x7f Aug 5 18:12:48 linpus kernel: [<c04cb49e>] ? sys_readlink+0x13/0x15 Aug 5 18:12:48 linpus kernel: [<c0771044>] ? syscall_call+0x7/0xb Aug 5 18:12:48 linpus kernel: Code: f4 39 c8 74 04 89 c1 eb d7 83 c4 0c 89 d0 5b 5e 5d c3 55 31 c9 89 e5 57 56 53 89 c3 83 ec 10 8b 40 0c 8b 53 08 89 45 e4 89 55 e8 <8b> 40 10 ba ef 00 00 00 89 45 ec b8 46 9b 89 c0 e8 b0 fa f5 ff Aug 5 18:12:48 linpus kernel: EIP: [<c04c94bd>] __fput+0x19/0x181 SS:ESP 0068:ddf47f1c Aug 5 18:12:48 linpus kernel: CR2: 0000000000000010 Aug 5 18:12:48 linpus kernel: ---[ end trace f3b9beda8e7310b2 ]---
(In reply to comment #9) > I'm still getting those errors, and try to get some usable backtrace. There is no way to get a usable backtrace, because the errors you get are due to random memory corruption from hibernating and resuming. Upstream developers have very recently found another cause of hibernation-related memory corruption that started with kernel 2.6.31 and should soon merge a fix for that.
Just want to add that I have FS corruption when resuming from hibernate with EXT3 as well. Log shows numerous entries like this: Sep 8 12:48:16 469 kernel: EXT3-fs error (device dm-1): ext3_free_blocks_sb: bit already cleared for block 2457500 I'm currently running 2.6.34.6-54.fc13.x86_64, problem appeared a couple of updates back. Will be waiting for the fix that Chuck mentioned.
(In reply to comment #12) > Just want to add that I have FS corruption when resuming from hibernate with > EXT3 as well. > > Log shows numerous entries like this: > Sep 8 12:48:16 469 kernel: EXT3-fs error (device dm-1): ext3_free_blocks_sb: > bit already cleared for block 2457500 > > I'm currently running 2.6.34.6-54.fc13.x86_64, problem appeared a couple of > updates back. > > Will be waiting for the fix that Chuck mentioned. That fix went in 2.6.34.4
Oh.. in this case the problem still persists. Anything I could do to help fix this? I'm on an Acer 8920G laptop, hibernate/resume from hibernate has been working flawlessly until the recent kernel updates; I can reproduce the problem very easily: hibernate resume (at this point the FS will go bad) reboot -> see fsck reporting problems and forcing check
Updated to kernel version 2.6.34.7-56.fc13.x86_64 Looks like the problem is gone. So far no fs corruption after resuming from hibernate.
Well, I guess I was reporting success too early... today after hibernatinv and resumig twice, the 2nd time it hit me. Weird things stated to happen, directories could not be created, etc., so I figured the problem persists and rebooted. Indeed - fsck kicked in. So - unfortunately the problem is still there, also with 2.6.34.7-56.fc13.x86_64
Updated to 2.6.34.7-61.fc13.x86_64, problem remains...
I'm also seeing this after resume on my MSI CR620 (which otherwise seems to work flawlessly with Fedora 13). My machine was exhibiting very very weird behavior (like having problems access /tmp, package manager not working, etc.). Reboot seems to have resolved this, and then I discoved the errors in message.log and this issue. [aaron@msi-cr620 whizpage]$ uname -a Linux msi-cr620 2.6.34.7-61.fc13.x86_64 #1 SMP Tue Oct 19 04:06:30 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Nov 7 16:16:23 msi-cr620 kernel: EXT4-fs error (device dm-1): ext4_free_inode: bit already cleared for inode 38409 Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346586(bit 3098 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346587(bit 3099 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346588(bit 3100 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346589(bit 3101 in group 41) Nov 7 16:16:24 msi-cr620 abrt[22401]: saved core dump of pid 1959 (/usr/bin/nautilus) to /var/spool/abrt/ccpp-1289164577-1959.new/coredump (58798080 bytes) Nov 7 16:16:24 msi-cr620 abrtd: Directory 'ccpp-1289164577-1959' creation detected Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346590(bit 3102 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346591(bit 3103 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346592(bit 3104 in group 41) Nov 7 16:16:24 msi-cr620 kernel: EXT4-fs error (device dm-1): mb_free_blocks: double-free of inode 0's block 1346593(bit 3105 in group 41)
Updated to Fedora 14, 2.6.35.6-48.fc14.x86_64, problem still persists :(
Also in kernel-2.6.35.10-74.fc14.i686
Tried compiling 2.6.37-1.fc14.x86_64 from rawhide - same problem. Is anyone looking into this at all?
2.6.35.10-74.fc14.x86_64 same problem here with Acer 1810T Timeline http://www.smolts.org/client/show/pub_e32dfb0f-7ec8-4d81-93ee-cb0b2e01842d it worked fine till a certain update, don't remember which one unfortunately
After a hint from the kernel side I tried a 2.6.37 kernel (2.6.37-2.fc15.i686), which seems to work fine. But the newer ones from rawhide (e.g. kernel-2.6.38-0.rc4.git0.2.fc15.i686) are even worse...
I've had this issue with Fedora 14 on my HP 6730b with kernel-2.6.35.10-74.fc14.x86_64 EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block
Well, the only kernel working fine seems to be the 2.6.37 kernel. I tried the FC15 kernel (kernel-2.6.38-1.fc15), but this one gives kernel panics after resuming. Looks like it still is somewhere in the fs code, as the top of the oops always has dentry_* in it.. Somebody still looking into this?
(In reply to comment #25) > Well, the only kernel working fine seems to be the 2.6.37 kernel. I tried the > FC15 kernel (kernel-2.6.38-1.fc15), but this one gives kernel panics after > resuming. Looks like it still is somewhere in the fs code, as the top of the > oops always has dentry_* in it.. Please try 2.6.38-3 when it finishes building.
Chuck, I got kernel-2.6.38.1-6.fc15.i686, I guess -3 did not make it into the repo. But still, after the third cycle: kernel panic in __list_del_entry, with a call trace of __free_pipe_info, __free_pipe_info, _raw_spin_lock, list_del_init, iput, dentry_... (Sorry, did not get more, if this is important, I will try) Klaus
I've been trying 2.6.38.2-8.fc15.i686 for some time now, and this one seems to be better. I'm using it right now, and I had a few cycles without problems, already. Only once it did not really hibernate, and I did not see it, so the battery went flat and I had to start anew, but otherwise it looks better!
well, I might have been rejoicing too early, today, after the second resume: [ 522.951336] Restarting tasks ... [ 522.955323] BUG: unable to handle kernel paging request at 00aaaaca [ 522.955561] IP: [<c072c277>] sock_poll+0x14/0x1b [ 522.955732] *pde = 1b0e0067 *pte = 00000000 [ 522.955896] Oops: 0000 [#1] SMP [ 522.956021] last sysfs file: /sys/devices/virtual/vc/vcsa63/uevent [ 522.956146] done. [ 522.956163] PM: Basic memory bitmaps freed [ 522.956174] video LNXVIDEO:00: Restoring backlight state [ 522.956283] Modules linked in: cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep snd_seq snd_seq_device ath5k snd_pcm ath mac80211 snd_timer uvcvideo cfg80211 microcode acerhdf videodev r8169 snd iTCO_wdt soundcore i2c_i801 iTCO_vendor_support jmb38x_ms joydev serio_raw snd_page_alloc rfkill mii memstick wmi sdhci_pci sdhci mmc_core i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 522.956283] [ 522.956283] Pid: 868, comm: modem-manager Not tainted 2.6.38.2-8.fc15.i686 #1 Gateway AOA110/ [ 522.956283] EIP: 0060:[<c072c277>] EFLAGS: 00010202 CPU: 0 [ 522.956283] EIP is at sock_poll+0x14/0x1b [ 522.956283] EAX: dbd81d80 EBX: 00aaaaaa ECX: dec2fc1c EDX: ddbc8000 [ 522.956283] ESI: ddbc8000 EDI: dec2fe78 EBP: dec2fbe4 ESP: dec2fbdc [ 522.956283] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 522.956283] Process modem-manager (pid: 868, ti=dec2e000 task=dcab9920 task.ti=dec2e000) [ 522.956283] Stack: [ 522.956283] dbd81d80 dec2fc1c dec2ff90 c04f1dd6 00000000 00000246 dcab9920 dec2ff08 [ 522.956283] 0984aaa0 00000000 00c2fca8 00000000 dec2fed8 00000000 00000000 00000000 [ 522.956283] c04f1125 00000019 00000000 dcab9920 00000000 00000000 0000000b dbb7d3c0 [ 522.956283] Call Trace: [ 522.956283] [<c04f1dd6>] do_sys_poll+0x1e8/0x360 [ 522.956283] [<c04f1125>] ? __pollwait+0x0/0xa8 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c04023c9>] ? __switch_to+0xf9/0x10a [ 522.956283] [<c042a44b>] ? pick_next_task_fair+0x87/0x8f [ 522.956283] [<c042ce46>] ? finish_task_switch+0x3e/0x98 [ 522.956283] [<c07d440c>] ? schedule+0x66f/0x67f [ 522.956283] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.956283] [<c0447109>] ? recalc_sigpending+0x5d/0x60 [ 522.956283] [<c0447422>] ? dequeue_signal+0xd4/0x13d [ 522.956283] [<c045d6d6>] ? tick_dev_program_event+0x2f/0x137 [ 522.956283] [<c072e918>] ? sys_recvmsg+0x49/0x52 [ 522.956283] [<c04ebe19>] ? path_put+0x1a/0x1d [ 522.956283] [<c04f1f7e>] do_restart_poll+0x30/0x44 [ 522.956283] [<c0448c1c>] sys_restart_syscall+0x16/0x18 [ 522.956283] [<c07d5b44>] syscall_call+0x7/0xb [ 522.956283] Code: 02 0f 95 c0 5d c3 90 90 55 89 e5 3e 8d 74 26 00 b8 fa ff ff ff 5d c3 55 89 e5 56 53 3e 8d 74 26 00 8b 70 74 89 d1 8b 5e 18 89 f2 <ff> 53 20 5b 5e 5d c3 55 89 e5 56 53 3e 8d 74 26 00 8b 70 74 89 [ 522.956283] EIP: [<c072c277>] sock_poll+0x14/0x1b SS:ESP 0068:dec2fbdc [ 522.956283] CR2: 0000000000aaaaca [ 522.957087] ---[ end trace 9577fecd2d3f680a ]--- [ 522.957576] BUG: unable to handle kernel paging request at 00aaaaae [ 522.957586] IP: [<c072ce25>] sock_release+0x14/0x60 [ 522.957601] *pde = 00000000 [ 522.957607] Oops: 0000 [#2] SMP [ 522.957613] last sysfs file: /sys/devices/virtual/vc/vcsa63/uevent [ 522.957620] Modules linked in: cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep snd_seq snd_seq_device ath5k snd_pcm ath mac80211 snd_timer uvcvideo cfg80211 microcode acerhdf videodev r8169 snd iTCO_wdt soundcore i2c_i801 iTCO_vendor_support jmb38x_ms joydev serio_raw snd_page_alloc rfkill mii memstick wmi sdhci_pci sdhci mmc_core i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 522.957695] [ 522.957703] Pid: 868, comm: modem-manager Tainted: G D 2.6.38.2-8.fc15.i686 #1 Gateway AOA110/ [ 522.957716] EIP: 0060:[<c072ce25>] EFLAGS: 00010206 CPU: 0 [ 522.957724] EIP is at sock_release+0x14/0x60 [ 522.957731] EAX: ddbc8000 EBX: ddbc8000 ECX: c072da86 EDX: 00aaaaaa [ 522.957739] ESI: 00000008 EDI: ddbc801c EBP: dec2f9b4 ESP: dec2f9a8 [ 522.957746] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 522.957754] Process modem-manager (pid: 868, ti=dec2e000 task=dcab9920 task.ti=dec2e000) [ 522.957760] Stack: [ 522.957764] 00000008 dbd81d80 00000008 dec2f9c0 c072daa9 dbd81d80 dec2f9f0 c04e590a [ 522.957779] 00000001 00000000 00000000 ddc28300 ddbc801c ddad0d80 dbd81d88 dbd81d80 [ 522.957793] 00000000 db121500 dec2fa08 c04e30cb 00000000 0000000f db121508 db121500 [ 522.957807] Call Trace: [ 522.957818] [<c072daa9>] sock_close+0x23/0x27 [ 522.957829] [<c04e590a>] fput+0x100/0x183 [ 522.957839] [<c04e30cb>] filp_close+0x56/0x5e [ 522.957850] [<c043d468>] put_files_struct+0x5c/0xae [ 522.957859] [<c043d52f>] exit_files+0x38/0x3c [ 522.957867] [<c043d9ec>] do_exit+0x23e/0x61c [ 522.957878] [<c046202c>] ? arch_local_irq_save+0x12/0x17 [ 522.957888] [<c043be58>] ? kmsg_dump+0x3a/0xb6 [ 522.957900] [<c07d6bfb>] oops_end+0xa2/0xa8 [ 522.957910] [<c07cd960>] no_context+0x128/0x130 [ 522.957921] [<c07cda82>] __bad_area_nosemaphore+0x11a/0x122 [ 522.957931] [<c07d440c>] ? schedule+0x66f/0x67f [ 522.957942] [<c04547e9>] ? hrtimer_interrupt+0x110/0x1aa [ 522.957952] [<c07cdadf>] bad_area+0x3c/0x42 [ 522.957961] [<c07d85fe>] do_page_fault+0x1c3/0x30c [ 522.957970] [<c043fdf3>] ? irq_exit+0x4c/0x70 [ 522.957980] [<c07d5fc9>] ? apic_timer_interrupt+0x31/0x38 [ 522.957990] [<c07d4db9>] ? schedule_hrtimeout_range_clock+0x42/0xda [ 522.958002] [<c042007b>] ? handle_vm86_fault+0x3e3/0x605 [ 522.958012] [<c046202c>] ? arch_local_irq_save+0x12/0x17 [ 522.958021] [<c07d843b>] ? do_page_fault+0x0/0x30c [ 522.958030] [<c07d622f>] error_code+0x67/0x6c [ 522.958040] [<c072c277>] ? sock_poll+0x14/0x1b [ 522.958050] [<c04f1dd6>] do_sys_poll+0x1e8/0x360 [ 522.958059] [<c04f1125>] ? __pollwait+0x0/0xa8 [ 522.958068] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c04023c9>] ? __switch_to+0xf9/0x10a [ 522.958073] [<c042a44b>] ? pick_next_task_fair+0x87/0x8f [ 522.958073] [<c042ce46>] ? finish_task_switch+0x3e/0x98 [ 522.958073] [<c07d440c>] ? schedule+0x66f/0x67f [ 522.958073] [<c04f11cd>] ? pollwake+0x0/0x61 [ 522.958073] [<c0447109>] ? recalc_sigpending+0x5d/0x60 [ 522.958073] [<c0447422>] ? dequeue_signal+0xd4/0x13d [ 522.958073] [<c045d6d6>] ? tick_dev_program_event+0x2f/0x137 [ 522.958073] [<c072e918>] ? sys_recvmsg+0x49/0x52 [ 522.958073] [<c04ebe19>] ? path_put+0x1a/0x1d [ 522.958073] [<c04f1f7e>] do_restart_poll+0x30/0x44 [ 522.958073] [<c0448c1c>] sys_restart_syscall+0x16/0x18 [ 522.958073] [<c07d5b44>] syscall_call+0x7/0xb [ 522.958073] Code: 00 00 eb 08 8d 46 0c ba 17 00 00 00 e8 c3 2d dc ff 31 c0 5b 5e 5d c3 55 89 e5 56 53 56 3e 8d 74 26 00 8b 50 18 89 c3 85 d2 74 14 <8b> 72 04 ff 52 08 c7 43 18 00 00 00 00 89 f0 e8 2e 6f d3 ff 8b [ 522.958073] EIP: [<c072ce25>] sock_release+0x14/0x60 SS:ESP 0068:dec2f9a8 [ 522.958073] CR2: 0000000000aaaaae [ 522.958428] ---[ end trace 9577fecd2d3f680b ]--- [ 522.958435] Fixing recursive fault but reboot is needed! [ 524.962107] Uhhuh. NMI received for unknown reason 2d on CPU 0. [ 524.962116] Do you have a strange power saving mode enabled? [ 524.962121] Dazed and confused, but trying to continue [ 527.023742] ehci_hcd 0000:00:1d.7: PME# enabled [ 527.629633] r8169 0000:02:00.0: PME# disabled [ 527.632687] r8169 0000:02:00.0: eth0: link down [ 527.632905] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 527.646236] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 529.372425] type=1400 audit(1302188046.047:13236): avc: denied { sys_module } for pid=904 comm="wpa_supplicant" capability=16 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tclass=capability
Hi, Running F15, kernel kernel-PAE-2.6.38.8-32.fc15.i686, and I'm experiencing the same sort of error after a hibernate. After resume from hibernate filesystem is behaving strange, applications do not find files or are unable to change some of them. The following error is shown on console several times: [118468.839511] EXT4-fs error (device dm-2): mb_free_blocks:1397: group 2block 74162:freeing already freed block (bit 8626) I have to reboot the system fully to recover from this error. I'm preventing hibernate for now. Suspend to RAM works like a charm.
I've been seeing this for quite some time now, from F14 onwards (and probably before, but I never used hibernate before). It seems to be caused by: https://bugzilla.kernel.org/show_bug.cgi?id=37142 Which is a continuation of: https://bugzilla.kernel.org/show_bug.cgi?id=13811 Seems to be memory corruption caused by the Intel GM graphics set-up when it wakes up from hibernate. First reported in July 2009(!). There an interesting patch attached to the kernel.org bug. Be interesting to see if that solves it (don't have time to compile a kernel myself now). For now, I have to figure out how to prevent Gnome3 from hibernating...
Same errors here with 2.6.38.8-35.fc15.x86_64 on Acer Aspire 1810T http://www.smolts.org/client/show/pub_79a20784-2ae1-4971-8ece-be0d3c0521a6
I'm seeing this too, and seems to be more frequent since upgrade to kernel-2.6.35.13-92.fc14.x86_64, on Acer Aspire 1810T. I am using 'intel_iommu=off' because of earlier suspend/resume problems. I don't know whether it is related, but I see lots of these when I suspend/resume: Aug 10 11:41:08 localhost kernel: [ 8781.853584] [drm:init_ring_common] *ERROR* render ring head not reset to zero ctl 00000000 head 02001000 tail 00000000 start 02001000 Aug 10 11:41:08 localhost kernel: [ 8781.853591] [drm:init_ring_common] *ERROR* render ring head forced to zero ctl 00000000 head 00000000 tail 00000000 start 02001000
(In reply to comment #33) > I'm seeing this too,... Well 'this' being ext4 corruption, which seems related to suspend/resume. Here's an instance (kernel 2.6.35.13-92.fc14.x86_64) : Aug 9 20:05:55 localhost kernel: [50677.530238] PM: restore of devices complete after 2369.483 msecs Aug 9 20:05:55 localhost kernel: [50677.530713] Restarting tasks ... done. Aug 9 20:05:55 localhost kernel: [50677.539103] video LNXVIDEO:00: Restoring backlight state Aug 9 20:05:55 localhost rtkit-daemon[1815]: The canary thread is apparently starving. Taking action. Aug 9 20:05:55 localhost rtkit-daemon[1815]: Demoting known real-time threads. Aug 9 20:05:55 localhost rtkit-daemon[1815]: Successfully demoted thread 2020 of process 2015 (/usr/bin/pulseaudio). Aug 9 20:05:55 localhost rtkit-daemon[1815]: Successfully demoted thread 2019 of process 2015 (/usr/bin/pulseaudio). Aug 9 20:05:55 localhost rtkit-daemon[1815]: Successfully demoted thread 2015 of process 2015 (/usr/bin/pulseaudio). Aug 9 20:05:55 localhost rtkit-daemon[1815]: Demoted 3 threads. Aug 9 20:06:03 localhost kernel: [50686.321517] EXT4-fs error (device dm-0): ext4_free_inode: bit already cleared for inode 5045 Aug 9 20:06:03 localhost kernel: [50686.330990] EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 50 : 4754 blocks in bitmap, 4752 in gd Aug 9 20:06:03 localhost kernel: [50686.331066] JBD: Spotted dirty metadata buffer (dev = dm-0, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
(In reply to comment #33) > I'm seeing this too, and seems to be more frequent since upgrade to > kernel-2.6.35.13-92.fc14.x86_64, on Acer Aspire 1810T. On reviewing my logs I think I've only seen it after upgrading to that kernel. Previously installed kernel was kernel-2.6.35.6-48.fc14.x86_64 and I didn't see fs corruption with that.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping