1. Please describe the problem: [98070.003257] BTRFS error (device sda3): Unsupported V0 extent filesystem detected. Aborting. Please re-create your filesystem with a newer kernel [98070.016180] ------------[ cut here ]------------ [98070.020848] BTRFS: Transaction aborted (error -22) [98070.020919] WARNING: CPU: 6 PID: 1175325 at fs/btrfs/extent-tree.c:872 lookup_inline_extent_backref+0x5b4/0x5e0 [98070.031001] Modules linked in: nfnetlink crypto_user rfkill xgene_enet dwc3 sdhci_acpi sdhci udc_core at803x ulpi mdio_xgene xgene_rng mailbox_xgene_slimpro cppc_cpufreq vfat fat fuse drm zram ip_tables crct10dif_ce i2c_xgene_slimpro xgene_hwmon gpio_dwapb gpio_xgene_sb xhci_plat_hcd aes_neon_bs [98070.057184] CPU: 6 PID: 1175325 Comm: kworker/u16:2 Not tainted 5.13.12-200.fc34.aarch64 #1 [98070.065512] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board, BIOS 3.06.25 Oct 17 2016 [98070.075213] Workqueue: events_unbound btrfs_preempt_reclaim_metadata_space [98070.082060] pstate: 40400005 (nZcv daif +PAN -UAO -TCO BTYPE=--) [98070.088039] pc : lookup_inline_extent_backref+0x5b4/0x5e0 [98070.093415] lr : lookup_inline_extent_backref+0x5b4/0x5e0 [98070.098789] sp : ffff800018e0b900 [98070.102085] x29: ffff800018e0b900 x28: 0000000000000019 x27: 0000000000000065 [98070.109189] x26: 0000000000000065 x25: ffff00000a70f000 x24: 00000000ffffffff [98070.116293] x23: ffff00000603e750 x22: ffff0001c4a1b600 x21: 00000001d8c74000 [98070.123398] x20: 0000000000000001 x19: ffff00000bb825b0 x18: ffffffffffffffff [98070.130523] x17: 0000000100000000 x16: 0000000000000000 x15: ffff80001275987a [98070.137648] x14: 00000000fffffffe x13: ffff800012759875 x12: 7220657361656c50 [98070.144773] x11: ffff8000123bccc8 x10: 00000000ffffe000 x9 : ffff800010302810 [98070.151899] x8 : 00000000ffffdfff x7 : ffff8000123bccc8 x6 : 0000000000000001 [98070.159025] x5 : ffff0003fdefb148 x4 : 0000000000000000 x3 : 0000000000000027 [98070.166149] x2 : 0000000000000023 x1 : ffff0003fdefb150 x0 : 0000000000000026 [98070.173272] Call trace: [98070.175707] lookup_inline_extent_backref+0x5b4/0x5e0 [98070.180737] lookup_extent_backref+0x54/0x110 [98070.185072] __btrfs_free_extent+0xcc/0xce0 [98070.189233] run_delayed_data_ref+0x98/0x190 [98070.193482] btrfs_run_delayed_refs_for_head+0x1ac/0x47c [98070.198767] __btrfs_run_delayed_refs+0xa8/0x280 [98070.203361] btrfs_run_delayed_refs+0x7c/0x2b4 [98070.207782] flush_space+0x354/0x430 [98070.211341] btrfs_preempt_reclaim_metadata_space+0x180/0x2e0 [98070.217059] process_one_work+0x1f0/0x4ac [98070.221051] worker_thread+0x184/0x500 [98070.224783] kthread+0x110/0x114 [98070.227996] ret_from_fork+0x10/0x18 [98070.231548] ---[ end trace e40182db389567a8 ]--- [98070.236189] BTRFS: error (device sda3) in lookup_inline_extent_backref:872: errno=-22 unknown [98070.242064] systemd-journald[521]: /var/log/journal/b678600db30b48c583d660c7503b29a6/system.journal: IO error, rotating. [98070.244696] BTRFS info (device sda3): forced readonly [98070.258648] systemd-journald[521]: Failed to rotate /var/log/journal/b678600db30b48c583d660c7503b29a6/system.journal: Read-only file system [98070.260560] BTRFS: error (device sda3) in __btrfs_free_extent:3084: errno=-22 unknown [98070.274101] systemd-journald[521]: Failed to rotate /var/log/journal/b678600db30b48c583d660c7503b29a6/user-1003.journal: Read-only file system [98070.280866] BTRFS: error (device sda3) in btrfs_run_delayed_refs:2163: errno=-22 unknown [98070.342771] systemd-journald[521]: Failed to write entry (9 items, 350 bytes) despite vacuuming, ignoring: Input/output error ... 2. What is the Version-Release number of the kernel: 5.13.12-200.fc34.aarch64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : N/A 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: N/A 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: N/A 6. Are you running any modules that not shipped with directly Fedora's kernel?: no 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. see 1 additional information - this was a fresh network installation of F-34 on a aarch64 system installed 2 days ago - the filesystem was created under the kernel of the GA installation media - there are no I/O related errors in the kernel log
Does the problem happen with 5.13.11? Or 5.14.6?
Upstream report: https://lore.kernel.org/linux-btrfs/CAJCQCtQsqsDwzUegUgYAo2PccUP9q=DKKA7kUNtRcbttW-nQrw@mail.gmail.com/T/#u
We could use more information how to reproduce the bug. What version btrfs-progs was used for mkfs? And what kernel version first mounted and wrote to this file system, if it wasn't kernel 5.13.12? Was it ever written to by any other architecture? Thanks.
The system was a fresh installation of F-34 on the hw and then updated. So the filesystem was created by the F-34 GA versions of kernel and btrfs-progs. The system is part of our production CI and got re-provisioned (with ext4) since then. But there is a suspicion that the 5.13 kernels brought some instability for the APM Mustang systems, because we saw a number of issues even with ext4 on them. I mean this report might be only a symptom of some other underlying issue that specific to the Mustangs ... Theoretically it could be even a hw issue, but the 5.11 or 5.12 kernels seems to work OK there. Unfortunately we don't have a spare Mustang currently for further experiments. IMO it would be good to know if there are any similar reports for 5.13 kernels from the same aarch64 hw (APM Mustang). FWIW the ext4 related issue looks like this Sep 08 11:14:52 apm-mustang-ev3-05 kernel: watchdog: BUG: soft lockup - CPU#5 stuck for 50557s! [tar:3389598] Sep 08 11:14:52 apm-mustang-ev3-05 kernel: Modules linked in: crypto_user nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_> Sep 08 11:14:53 apm-mustang-ev3-05 kernel: CPU: 5 PID: 3389598 Comm: tar Tainted: G D W L 5.13.12-200.fc34.aarch64 #1 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board, BIOS 3.06.25 Oct 17 2016 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: pstate: 00400005 (nzcv daif +PAN -UAO -TCO BTYPE=--) Sep 08 11:14:53 apm-mustang-ev3-05 kernel: pc : queued_spin_lock_slowpath+0x204/0x390 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: lr : locked_inode_to_wb_and_lock_list+0xf0/0x174 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: sp : ffff800019843930 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x29: ffff800019843930 x28: ffff0000d2d885d8 x27: ffff0000c2a94620 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x26: ffff800019843af8 x25: 0000000000000000 x24: ffff0000d2d88660 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x23: 0000000000000000 x22: 0000000000000001 x21: 0000000000000001 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x20: ffff0000d2d885d8 x19: ffff00000c4ba800 x18: 0000000023b9dafb Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x17: 0000000030e349b1 x16: 0000000000001800 x15: 0000000000000007 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x14: 0000000000001400 x13: 0000000000001c00 x12: 0000000000000040 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x11: ffff0001487ef230 x10: 0000000000000000 x9 : 0000000000180000 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x8 : 0000000000000000 x7 : ffff0003fdeeba40 x6 : ffff800011da5a40 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x5 : ffff0003fdeeba40 x4 : 0000000000180101 x3 : ffff00000c4ba858 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: x2 : 0000000000000000 x1 : 0000000000180101 x0 : 0000000000000000 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: Call trace: Sep 08 11:14:53 apm-mustang-ev3-05 kernel: queued_spin_lock_slowpath+0x204/0x390 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: __mark_inode_dirty+0x2e8/0x3c0 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_mb_new_blocks+0x108/0x660 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_ext_map_blocks+0x64c/0x8c0 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_map_blocks+0x180/0x5ac Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_getblk+0x58/0x280 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_bread+0x20/0xd0 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_append+0x58/0x110 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_init_new_dir+0x78/0x1c0 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: ext4_mkdir+0x19c/0x370 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: vfs_mkdir+0x140/0x1ec Sep 08 11:14:53 apm-mustang-ev3-05 kernel: do_mkdirat+0x12c/0x14c Sep 08 11:14:53 apm-mustang-ev3-05 kernel: __arm64_sys_mkdirat+0x2c/0x40 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: invoke_syscall+0x50/0x120 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: el0_svc_common.constprop.0+0x4c/0x100 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: do_el0_svc+0x34/0xa0 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: el0_svc+0x2c/0x54 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: el0_sync_handler+0xa4/0x130 Sep 08 11:14:53 apm-mustang-ev3-05 kernel: el0_sync+0x19c/0x1c0
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Also looks like a dup: https://bugzilla.redhat.com/show_bug.cgi?id=2000482
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.