Re: Upgrade to 3.19.2 Kernel fails to boot
Eric found something like this and has a fix with in the email. Sub: I think btrfs: fix leak of path in btrfs_find_item broke stable trees ... Anand On 03/24/2015 06:40 PM, Rich Freeman wrote: On Tue, Mar 24, 2015 at 2:31 AM, Anand Jain anand.j...@oracle.com wrote: Do you have this fix .. [PATCH] Btrfs: release path before starting transaction in can_nocow_extent could you try ?. I believe I already have this patch. 3.18.9 contains this: commit bdeeab62a611f1f7cd48fd285ce568e8dcd0455a Merge: 797afdf 1bda19e Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Oct 18 16:46:21 2013 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fix from Chris Mason: Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a regression in our initial rc1 pull. When doing nocow writes we were sometimes starting a transaction with locks held * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: release path before starting transaction in can_nocow_extent -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
On Wed, Apr 1, 2015 at 2:50 AM, Anand Jain anand.j...@oracle.com wrote: Eric found something like this and has a fix with in the email. Sub: I think btrfs: fix leak of path in btrfs_find_item broke stable trees ... I don't mind trying this patch if the maintainers recommend it. I'm still getting panics every few days and 3.18.10 won't mount my root filesystem, so I've been running on 3.18.8. -- Rich -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
G. Richard Bellamy rbellamy at pteradigm.com writes: When I upgrade to the 3.19.2 Kernel I get a deadlocked boot: INFO: task mount:302 blocked for more than 120 seconds. INFO: task btrfs-transacti:329 blocked for more than 120 seconds. I have an LTS Kernel at 3.14.35 that also fails to boot with the same behavior. My 3.18.6 works just fine. -rb -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Same issue here. Rebooted after updating to 3.19.2 and now I get the mount blocked message and can't boot. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
On Tue, Mar 31, 2015 at 3:24 PM, Benjamin Hodgetts b...@xnode.org wrote: G. Richard Bellamy rbellamy at pteradigm.com writes: When I upgrade to the 3.19.2 Kernel I get a deadlocked boot: INFO: task mount:302 blocked for more than 120 seconds. INFO: task btrfs-transacti:329 blocked for more than 120 seconds. I have an LTS Kernel at 3.14.35 that also fails to boot with the same behavior. My 3.18.6 works just fine. Well there are only two backports in 3.14.35. Most of the ones found in 3.19.2 are in 3.14.36. commit f9e2ba638c32dff17ee6404e2c8245fd49d99b8b Author: David Sterba dste...@suse.cz Date: Fri Jan 2 18:45:16 2015 +0100 btrfs: fix leak of path in btrfs_find_item commit 381cf6587f8a8a8e981bc0c18859b51dc756 upstream. If btrfs_find_item is called with NULL path it allocates one locally but does not free it. Affected paths are inserting an orphan item for a file and for a subvol root. Move the path allocation to the callers. Fixes: 3f870c289900 (btrfs: expand btrfs_find_item() to include find_orphan_item functionality) Signed-off-by: David Sterba dste...@suse.cz Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org commit 74e42361fa3bc102647ad1e1ec7c21b747658843 Author: David Sterba dste...@suse.cz Date: Fri Dec 19 18:38:47 2014 +0100 btrfs: set proper message level for skinny metadata commit 5efa0490cc94aee06cd8d282683e22a8ce0a0026 upstream. This has been confusing people for too long, the message is really just informative. -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
On Tue, Mar 24, 2015 at 2:31 AM, Anand Jain anand.j...@oracle.com wrote: Do you have this fix .. [PATCH] Btrfs: release path before starting transaction in can_nocow_extent could you try ?. I believe I already have this patch. 3.18.9 contains this: commit bdeeab62a611f1f7cd48fd285ce568e8dcd0455a Merge: 797afdf 1bda19e Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Oct 18 16:46:21 2013 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fix from Chris Mason: Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a regression in our initial rc1 pull. When doing nocow writes we were sometimes starting a transaction with locks held * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: release path before starting transaction in can_nocow_extent -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
Do you have this fix .. [PATCH] Btrfs: release path before starting transaction in can_nocow_extent could you try ?. Thanks, Anand On 03/24/2015 12:37 AM, Rich Freeman wrote: On Mon, Mar 23, 2015 at 9:22 AM, Rich Freeman r-bt...@thefreemanclan.net wrote: I'm having a similar problem. I'm getting some kind of btrfs corruption that causes a panic/reboot, and then the initramfs won't mount root for 3.18.9, but it will mount it for 3.18.8. Running on 3.18.8 eventually caused the panic to repeat, so I'm not sure that 3.18.9 is necessarily breaking things - it might just be fussier about not mounting a dirty fs. This continues to happen. The filesystem won't mount with 3.18.9, but will mount with 3.18.8. Here is the dmesg output from dracut on 3.18.9: [ 240.765147] INFO: task mount:395 blocked for more than 120 seconds. [ 240.765224] Not tainted 3.18.9-gentoo #1 [ 240.765274] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.765809] mount D 880427c51900 11800 395 1 0x0004 [ 240.765927] 88040d2f76a8 0082 8804106170f0 00011900 [ 240.766181] 88040d2f7fd8 00011900 88041593d6e0 8804106170f0 [ 240.766373] 88040d2f76b8 8800cb505c70 8800cb505cf0 8800cb505cd8 [ 240.766556] Call Trace: [ 240.766618] [81504084] schedule+0x24/0x60 [ 240.766719] [a032fe9d] btrfs_tree_lock+0x4d/0x1c0 [btrfs] [ 240.766780] [810882f0] ? prepare_to_wait_event+0x100/0x100 [ 240.766859] [a02d3859] btrfs_search_slot+0x6e9/0x9f0 [btrfs] [ 240.766939] [a02d5503] btrfs_insert_empty_items+0x73/0xd0 [btrfs] [ 240.767017] [a02ce495] ? btrfs_alloc_path+0x15/0x20 [btrfs] [ 240.767118] [a033012a] btrfs_insert_orphan_item+0x5a/0x80 [btrfs] [ 240.767211] [a03316c5] insert_orphan_item+0x65/0xa0 [btrfs] [ 240.767301] [a0336589] replay_one_buffer+0x349/0x360 [btrfs] [ 240.767391] [a0330ff5] walk_up_log_tree+0xc5/0x220 [btrfs] [ 240.767481] [a03311eb] walk_log_tree+0x9b/0x1a0 [btrfs] [ 240.767572] [a0338932] btrfs_recover_log_trees+0x262/0x4d0 [btrfs] [ 240.767662] [a0336240] ? replay_one_extent+0x780/0x780 [btrfs] [ 240.767749] [a02f4b9f] open_ctree+0x17ef/0x2100 [btrfs] [ 240.767827] [a02cb876] btrfs_mount+0x766/0x900 [btrfs] [ 240.767886] [81175bef] mount_fs+0x3f/0x1b0 [ 240.767940] [811331b0] ? __alloc_percpu+0x10/0x20 [ 240.767997] [8118fc53] vfs_kern_mount+0x63/0x100 [ 240.768087] [a02cb28b] btrfs_mount+0x17b/0x900 [btrfs] [ 240.768146] [81132e8a] ? pcpu_alloc+0x35a/0x660 [ 240.768201] [81175bef] mount_fs+0x3f/0x1b0 [ 240.768255] [811331b0] ? __alloc_percpu+0x10/0x20 [ 240.768311] [8118fc53] vfs_kern_mount+0x63/0x100 [ 240.768365] [8119289c] do_mount+0x20c/0xaf0 [ 240.768420] [81118eb9] ? __get_free_pages+0x9/0x40 [ 240.768474] [81192555] ? copy_mount_options+0x35/0x150 [ 240.768528] [81193497] SyS_mount+0x97/0xf0 [ 240.768582] [81507ad2] system_call_fastpath+0x12/0x17 [ 240.768638] INFO: task btrfs-transacti:435 blocked for more than 120 seconds. [ 240.768693] Not tainted 3.18.9-gentoo #1 [ 240.768742] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.768811] btrfs-transacti D 880427c11900 12424 435 2 0x [ 240.768928] 8800cfab7dc8 0046 880410f01a10 00011900 [ 240.769119] 8800cfab7fd8 00011900 81a16460 880410f01a10 [ 240.769302] 8800cfab7dd8 88040c7ab000 8800cb554000 8800cb5301a0 [ 240.769485] Call Trace: [ 240.769540] [81504084] schedule+0x24/0x60 [ 240.769625] [a02f73e5] btrfs_commit_transaction+0x275/0xa40 [btrfs] [ 240.769698] [810882f0] ? prepare_to_wait_event+0x100/0x100 [ 240.769784] [a02f305d] transaction_kthread+0x1ad/0x240 [btrfs] [ 240.769870] [a02f2eb0] ? btrfs_cleanup_transaction+0x530/0x530 [btrfs] [ 240.769942] [8106aa04] kthread+0xc4/0xe0 [ 240.769997] [8106a940] ? kthread_create_on_node+0x190/0x190 [ 240.770064] [81507a2c] ret_from_fork+0x7c/0xb0 [ 240.770119] [8106a940] ? kthread_create_on_node+0x190/0x190 [ 360.832426] INFO: task mount:395 blocked for more than 120 seconds. [ 360.832488] Not tainted 3.18.9-gentoo #1 [ 360.832539] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 360.832609] mount D 880427c51900 11800 395 1 0x0004 [ 360.832727] 88040d2f76a8 0082 8804106170f0 00011900 [ 360.832911] 88040d2f7fd8 00011900 88041593d6e0 8804106170f0 [ 360.833093] 88040d2f76b8 8800cb505c70 8800cb505cf0 8800cb505cd8 [ 360.833276] Call Trace: [ 360.833385]
Re: Upgrade to 3.19.2 Kernel fails to boot
On Mon, Mar 23, 2015 at 4:23 AM, Anand Jain anand.j...@oracle.com wrote: Do you still have the problem ? Can you pls confirm on the latest btrfs ? Since I am fixing the devices part of the btrfs, I am bit nervous. I'm having a similar problem. I'm getting some kind of btrfs corruption that causes a panic/reboot, and then the initramfs won't mount root for 3.18.9, but it will mount it for 3.18.8. Running on 3.18.8 eventually caused the panic to repeat, so I'm not sure that 3.18.9 is necessarily breaking things - it might just be fussier about not mounting a dirty fs. I did run a btrfs check --repair and it ended up moving some chromium preferences from the user profile folder to lost+found. That got the system to run for about 8 hours, but it still paniced the next morning. I'm now running on 3.18.7 to see what happens. Unfortunately I haven't been doing a good job about capturing logs. I'll try to capture more the next time this happens. I've been running fine on 3.18 for a while now, so I'm not sure where all of this is coming from. -- Rich -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
On Mon, Mar 23, 2015 at 9:22 AM, Rich Freeman r-bt...@thefreemanclan.net wrote: I'm having a similar problem. I'm getting some kind of btrfs corruption that causes a panic/reboot, and then the initramfs won't mount root for 3.18.9, but it will mount it for 3.18.8. Running on 3.18.8 eventually caused the panic to repeat, so I'm not sure that 3.18.9 is necessarily breaking things - it might just be fussier about not mounting a dirty fs. This continues to happen. The filesystem won't mount with 3.18.9, but will mount with 3.18.8. Here is the dmesg output from dracut on 3.18.9: [ 240.765147] INFO: task mount:395 blocked for more than 120 seconds. [ 240.765224] Not tainted 3.18.9-gentoo #1 [ 240.765274] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.765809] mount D 880427c51900 11800 395 1 0x0004 [ 240.765927] 88040d2f76a8 0082 8804106170f0 00011900 [ 240.766181] 88040d2f7fd8 00011900 88041593d6e0 8804106170f0 [ 240.766373] 88040d2f76b8 8800cb505c70 8800cb505cf0 8800cb505cd8 [ 240.766556] Call Trace: [ 240.766618] [81504084] schedule+0x24/0x60 [ 240.766719] [a032fe9d] btrfs_tree_lock+0x4d/0x1c0 [btrfs] [ 240.766780] [810882f0] ? prepare_to_wait_event+0x100/0x100 [ 240.766859] [a02d3859] btrfs_search_slot+0x6e9/0x9f0 [btrfs] [ 240.766939] [a02d5503] btrfs_insert_empty_items+0x73/0xd0 [btrfs] [ 240.767017] [a02ce495] ? btrfs_alloc_path+0x15/0x20 [btrfs] [ 240.767118] [a033012a] btrfs_insert_orphan_item+0x5a/0x80 [btrfs] [ 240.767211] [a03316c5] insert_orphan_item+0x65/0xa0 [btrfs] [ 240.767301] [a0336589] replay_one_buffer+0x349/0x360 [btrfs] [ 240.767391] [a0330ff5] walk_up_log_tree+0xc5/0x220 [btrfs] [ 240.767481] [a03311eb] walk_log_tree+0x9b/0x1a0 [btrfs] [ 240.767572] [a0338932] btrfs_recover_log_trees+0x262/0x4d0 [btrfs] [ 240.767662] [a0336240] ? replay_one_extent+0x780/0x780 [btrfs] [ 240.767749] [a02f4b9f] open_ctree+0x17ef/0x2100 [btrfs] [ 240.767827] [a02cb876] btrfs_mount+0x766/0x900 [btrfs] [ 240.767886] [81175bef] mount_fs+0x3f/0x1b0 [ 240.767940] [811331b0] ? __alloc_percpu+0x10/0x20 [ 240.767997] [8118fc53] vfs_kern_mount+0x63/0x100 [ 240.768087] [a02cb28b] btrfs_mount+0x17b/0x900 [btrfs] [ 240.768146] [81132e8a] ? pcpu_alloc+0x35a/0x660 [ 240.768201] [81175bef] mount_fs+0x3f/0x1b0 [ 240.768255] [811331b0] ? __alloc_percpu+0x10/0x20 [ 240.768311] [8118fc53] vfs_kern_mount+0x63/0x100 [ 240.768365] [8119289c] do_mount+0x20c/0xaf0 [ 240.768420] [81118eb9] ? __get_free_pages+0x9/0x40 [ 240.768474] [81192555] ? copy_mount_options+0x35/0x150 [ 240.768528] [81193497] SyS_mount+0x97/0xf0 [ 240.768582] [81507ad2] system_call_fastpath+0x12/0x17 [ 240.768638] INFO: task btrfs-transacti:435 blocked for more than 120 seconds. [ 240.768693] Not tainted 3.18.9-gentoo #1 [ 240.768742] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.768811] btrfs-transacti D 880427c11900 12424 435 2 0x [ 240.768928] 8800cfab7dc8 0046 880410f01a10 00011900 [ 240.769119] 8800cfab7fd8 00011900 81a16460 880410f01a10 [ 240.769302] 8800cfab7dd8 88040c7ab000 8800cb554000 8800cb5301a0 [ 240.769485] Call Trace: [ 240.769540] [81504084] schedule+0x24/0x60 [ 240.769625] [a02f73e5] btrfs_commit_transaction+0x275/0xa40 [btrfs] [ 240.769698] [810882f0] ? prepare_to_wait_event+0x100/0x100 [ 240.769784] [a02f305d] transaction_kthread+0x1ad/0x240 [btrfs] [ 240.769870] [a02f2eb0] ? btrfs_cleanup_transaction+0x530/0x530 [btrfs] [ 240.769942] [8106aa04] kthread+0xc4/0xe0 [ 240.769997] [8106a940] ? kthread_create_on_node+0x190/0x190 [ 240.770064] [81507a2c] ret_from_fork+0x7c/0xb0 [ 240.770119] [8106a940] ? kthread_create_on_node+0x190/0x190 [ 360.832426] INFO: task mount:395 blocked for more than 120 seconds. [ 360.832488] Not tainted 3.18.9-gentoo #1 [ 360.832539] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 360.832609] mount D 880427c51900 11800 395 1 0x0004 [ 360.832727] 88040d2f76a8 0082 8804106170f0 00011900 [ 360.832911] 88040d2f7fd8 00011900 88041593d6e0 8804106170f0 [ 360.833093] 88040d2f76b8 8800cb505c70 8800cb505cf0 8800cb505cd8 [ 360.833276] Call Trace: [ 360.833385] [81504084] schedule+0x24/0x60 [ 360.833495] [a032fe9d] btrfs_tree_lock+0x4d/0x1c0 [btrfs] [ 360.833555] [810882f0] ? prepare_to_wait_event+0x100/0x100 [ 360.833634]
Re: Upgrade to 3.19.2 Kernel fails to boot
Do you still have the problem ? Can you pls confirm on the latest btrfs ? Since I am fixing the devices part of the btrfs, I am bit nervous. Thanks, Anand On 03/20/2015 07:06 AM, G. Richard Bellamy wrote: When I upgrade to the 3.19.2 Kernel I get a deadlocked boot: INFO: task mount:302 blocked for more than 120 seconds. INFO: task btrfs-transacti:329 blocked for more than 120 seconds. I have an LTS Kernel at 3.14.35 that also fails to boot with the same behavior. My 3.18.6 works just fine. -rb -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrade to 3.19.2 Kernel fails to boot
On Sun, 22 Mar 2015 22:15:47 +0100 Ochi o...@arcor.de wrote: When I upgrade to the 3.19.2 Kernel I get a deadlocked boot: INFO: task mount:302 blocked for more than 120 seconds. INFO: task btrfs-transacti:329 blocked for more than 120 seconds. I had a similar behavior today after I accidentally pulled the power plug of my machine (Arch Linux, Kernel 3.19.2). I tried to boot several times, but mount timed out. This message by itself is not a time out of any kind, it's just a warning which says exactly what it says and nothing more. If you are certain that there was no access whatsoever to the HDD/SSD (the access light not flashing), then yeah maybe it got stuck. But it also could be it simply needed 1-2 more minutes to complete whatever it was doing. -- With respect, Roman signature.asc Description: PGP signature
Re: Upgrade to 3.19.2 Kernel fails to boot
On Thu, Mar 19, 2015 at 5:06 PM, G. Richard Bellamy rbell...@pteradigm.com wrote: When I upgrade to the 3.19.2 Kernel I get a deadlocked boot: INFO: task mount:302 blocked for more than 120 seconds. INFO: task btrfs-transacti:329 blocked for more than 120 seconds. If you boot single user is it semi-responsive enough to sysrq+w [1] and post the resulting dmesg? My 3.18.6 works just fine. What do you get for 'btrfs check dev' You either need to run this from the initramfs (totally unmounted file system) or rescue media with a decently recent btrfs progs. [1] https://www.kernel.org/doc/Documentation/sysrq.txt -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
