Re: btrfs suddenly think's it's raid6
On 2018年06月30日 06:11, marble wrote: > Hey, > Thanks for the quick reply :-) > >> Is there anything like unexpected power loss happens? > Power loss may have happened. >> And would you provide the following data for debugging? >> >> # btrfs ins dump-super -fFa /dev/mapper/black > I attached it. Looks pretty good. Then we could go through normal salvage routine. Please try the following commands and especially keep an eye on the stderr output: (The follow option is added in recent btrfs-progs releases, so please ensure your btrfs-progs is up to date) # btrfs ins dump-tree -b 1084653568 --follow /dev/mapper/black # btrfs ins dump-tree -b 1083604992 --follow /dev/mapper/black # btrfs ins dump-tree -b 1083981824 --follow /dev/mapper/black # btrfs ins dump-tree -b 1084325888 --follow /dev/mapper/black Or just use old roots and let btrfs check to judge: # btrfs check --tree-root 1084751872 /dev/mapper/black # btrfs check --tree-root 1083801600 /dev/mapper/black # btrfs check --tree-root 1084145664 /dev/mapper/black # btrfs check --tree-root 1084473344 /dev/mapper/black >> And further more, what's the device mapper setup for /dev/mapper/black? >> Is there anything like RAID here? > I think this is the result of luks. "black" is the name I passed to > cryptsetup open. Maybe some powerloss screwed up encryption? I'm not pretty sure how things will happen when power loss happens. Anyway, let's see how above btrfs check and dump-tree ends. Thanks, Qu >> Thanks, >> Qu > Cheers, > marble > signature.asc Description: OpenPGP digital signature
Re: btrfs suddenly think's it's raid6
> No log_root* in the super. So no fsyncing at the time? What was > happening at the time of the power loss? That I don't know. > Pretty weird, all three supers are OK and yet two copies of the fs > tree are corrupt. Why doesn't it fall back automatically to one of the > other roots? > > You could try 'mount -o usebackuproot,ro' and see if that's permissive > enough to succeed. That yields the same result ``` marble@archlinux ~ % sudo mount -o usebackuproot,ro /dev/mapper/black /tmp/black mount: /tmp/black: can't read superblock on /dev/mapper/black. ``` > I wonder if the drive firmware reordered things contrary to Btrfs > expectation right at the powerfail - or even if the powerfail caused > the drive firmware to do the writes in the wrong order? > > -- 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: btrfs suddenly think's it's raid6
On Fri, Jun 29, 2018 at 4:09 PM, marble wrote: > Hey, > Thanks for the quick reply :-) > >> Is there anything like unexpected power loss happens? > Power loos may have happened. It was power via a RPi. >> And would you provide the following data for debugging? >> >> # btrfs ins dump-super -fFa /dev/mapper/black > See attachment. >> And further more, what's the device mapper setup for /dev/mapper/black? >> Is there anything like RAID here? > This is due to LUKS I think. "black" is the name I gave to cryptsetup open. No log_root* in the super. So no fsyncing at the time? What was happening at the time of the power loss? Pretty weird, all three supers are OK and yet two copies of the fs tree are corrupt. Why doesn't it fall back automatically to one of the other roots? You could try 'mount -o usebackuproot,ro' and see if that's permissive enough to succeed. I wonder if the drive firmware reordered things contrary to Btrfs expectation right at the powerfail - or even if the powerfail caused the drive firmware to do the writes in the wrong order? -- 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: btrfs suddenly think's it's raid6
Hey, Thanks for the quick reply :-) > Is there anything like unexpected power loss happens? Power loss may have happened. > And would you provide the following data for debugging? > > # btrfs ins dump-super -fFa /dev/mapper/black I attached it. > And further more, what's the device mapper setup for /dev/mapper/black? > Is there anything like RAID here? I think this is the result of luks. "black" is the name I passed to cryptsetup open. > Thanks, > Qu Cheers, marble superblock: bytenr=65536, device=/dev/mapper/black - csum_type 0 (crc32c) csum_size 4 csum0x9814744c [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 label black generation 352 root30736384 sys_array_size 129 chunk_root_generation 145 root_level 1 chunk_root 22020096 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 500105764864 bytes_used 153954693120 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 1 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation187 uuid_tree_generation187 dev_item.uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 dev_item.fsid 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 [match] dev_item.type 0 dev_item.total_bytes500105764864 dev_item.bytes_used 184708759552 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 22020096) length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP io_align 65536 io_width 65536 sector_size 4096 num_stripes 2 sub_stripes 0 stripe 0 devid 1 offset 22020096 dev_uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 stripe 1 devid 1 offset 30408704 dev_uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 backup_roots[4]: backup 0: backup_tree_root: 1084751872 gen: 187level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084702720 gen: 187level: 2 backup_fs_root: 1084653568 gen: 187level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1084817408 gen: 187level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 1: backup_tree_root: 1083801600 gen: 184level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1083752448 gen: 184level: 2 backup_fs_root: 1083604992 gen: 184level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1083867136 gen: 184level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 2: backup_tree_root: 1084145664 gen: 185level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084080128 gen: 185level: 2 backup_fs_root: 1083981824 gen: 185level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1084211200 gen: 185level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 3: backup_tree_root: 1084473344 gen: 186level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084424192 gen: 186level: 2 backup_fs_root:
Re: btrfs suddenly think's it's raid6
Hey, Thanks for the quick reply :-) > Is there anything like unexpected power loss happens? Power loos may have happened. It was power via a RPi. > And would you provide the following data for debugging? > > # btrfs ins dump-super -fFa /dev/mapper/black See attachment. > And further more, what's the device mapper setup for /dev/mapper/black? > Is there anything like RAID here? This is due to LUKS I think. "black" is the name I gave to cryptsetup open. Cheers, marble superblock: bytenr=65536, device=/dev/mapper/black - csum_type 0 (crc32c) csum_size 4 csum0x9814744c [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 label black generation 352 root30736384 sys_array_size 129 chunk_root_generation 145 root_level 1 chunk_root 22020096 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 500105764864 bytes_used 153954693120 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 1 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation187 uuid_tree_generation187 dev_item.uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 dev_item.fsid 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 [match] dev_item.type 0 dev_item.total_bytes500105764864 dev_item.bytes_used 184708759552 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 22020096) length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP io_align 65536 io_width 65536 sector_size 4096 num_stripes 2 sub_stripes 0 stripe 0 devid 1 offset 22020096 dev_uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 stripe 1 devid 1 offset 30408704 dev_uuid cbf2a2ce-9487-4c2d-98e9-5cc69ae59b26 backup_roots[4]: backup 0: backup_tree_root: 1084751872 gen: 187level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084702720 gen: 187level: 2 backup_fs_root: 1084653568 gen: 187level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1084817408 gen: 187level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 1: backup_tree_root: 1083801600 gen: 184level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1083752448 gen: 184level: 2 backup_fs_root: 1083604992 gen: 184level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1083867136 gen: 184level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 2: backup_tree_root: 1084145664 gen: 185level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084080128 gen: 185level: 2 backup_fs_root: 1083981824 gen: 185level: 2 backup_dev_root:1081655296 gen: 178level: 0 backup_csum_root: 1084211200 gen: 185level: 2 backup_total_bytes: 500105764864 backup_bytes_used: 153957298176 backup_num_devices: 1 backup 3: backup_tree_root: 1084473344 gen: 186level: 1 backup_chunk_root: 22020096gen: 145level: 1 backup_extent_root: 1084424192 gen: 186level: 2 backup_fs_root:
Re: btrfs suddenly think's it's raid6
On 2018年06月29日 19:04, marble wrote: > Hello, > I have an external HDD. The HDD contains no partition. > I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs. > It's used to store some media files. > The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux > to play music from the drive. > > After disconnecting the drive from the Pi and connecting it to my laptop > again, I couldn't mount it anymore. If I read the dmesg right, it now > thinks that it's part of a raid6. Don't panic, the raid6 module is always loaded by btrfs, no matter if btrfs uses or not. > > btrfs check --repair also didn't help. Normally you shouldn't try it anyway. > > ``` > marble@archlinux ~ % uname -a > Linux archlinux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC > 2018 x86_64 GNU/Linux > > marble@archlinux ~ % btrfs --version > btrfs-progs v4.16.1 > > marble@archlinux ~ % sudo cryptsetup open /dev/sda black > [sudo] password for marble: > Enter passphrase for /dev/sda: > > marble@archlinux ~ % mkdir /tmp/black > marble@archlinux ~ % sudo mount /dev/mapper/black /tmp/black > mount: /tmp/black: can't read superblock on /dev/mapper/black. > > marble@archlinux ~ % sudo btrfs fi show > Label: 'black' uuid: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 > Total devices 1 FS bytes used 143.38GiB > devid1 size 465.76GiB used 172.02GiB path /dev/mapper/black > > marble@archlinux ~ % sudo btrfs check --repair /dev/mapper/black > enabling repair mode > Checking filesystem on /dev/mapper/black > UUID: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 > Fixed 0 roots. > checking extents > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 This means, both copies for logical bytenr 1082114048 are corrupted. > bytenr mismatch, want=1082114048, have=9385453728028469028 > owner ref check failed [1082114048 16384] > repair deleting extent record: key [1082114048,168,16384] You shouldn't really use --repair here. Your extent tree is corrupted, --repair could make things worse here. > adding new tree backref on start 1082114048 len 16384 parent 0 root 5 > Repaired extent references for 1082114048 > ref mismatch on [59038556160 4096] extent item 1, found 0 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > bytenr mismatch, want=1082114048, have=9385453728028469028 > incorrect local backref count on 59038556160 root 5 owner 334393 offset > 0 found 0 wanted 1 back 0x56348aee5de0 > backref disk bytenr does not match extent record, bytenr=59038556160, > ref bytenr=0 > backpointer mismatch on [59038556160 4096] > owner ref check failed [59038556160 4096] > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 > checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 > bytenr mismatch, want=1082114048, have=9385453728028469028 > failed to repair damaged filesystem, aborting > > marble@archlinux ~ % dmesg > /tmp/dmesg.log This is the root cause: [ 124.544439] BTRFS error (device dm-1): bad tree block start 9385453728028469028 1082114048 [ 124.555229] BTRFS error (device dm-1): bad tree block start 2365503423870651471 1082114048 [ 124.555275] BTRFS warning (device dm-1): failed to read fs tree: -5 Your fs tree is corrupted. I'm not sure how it's corrupted, but corruption to fs tree is a little rare. Is there anything like unexpected power loss happens? And would you provide the following data for debugging? # btrfs ins dump-super -fFa /dev/mapper/black And further more, what's the device mapper setup for /dev/mapper/black? Is there anything like RAID here? Thanks, Qu > ``` > > Any clues? > > Best regards, > marble > signature.asc Description: OpenPGP digital signature
Re: btrfs suddenly think's it's raid6
On 2018-06-29 07:04, marble wrote: Hello, I have an external HDD. The HDD contains no partition. I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs. It's used to store some media files. The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux to play music from the drive. After disconnecting the drive from the Pi and connecting it to my laptop again, I couldn't mount it anymore. If I read the dmesg right, it now thinks that it's part of a raid6. btrfs check --repair also didn't help. ``` marble@archlinux ~ % uname -a Linux archlinux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 GNU/Linux marble@archlinux ~ % btrfs --version btrfs-progs v4.16.1 marble@archlinux ~ % sudo cryptsetup open /dev/sda black [sudo] password for marble: Enter passphrase for /dev/sda: marble@archlinux ~ % mkdir /tmp/black marble@archlinux ~ % sudo mount /dev/mapper/black /tmp/black mount: /tmp/black: can't read superblock on /dev/mapper/black. marble@archlinux ~ % sudo btrfs fi show Label: 'black' uuid: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 Total devices 1 FS bytes used 143.38GiB devid1 size 465.76GiB used 172.02GiB path /dev/mapper/black marble@archlinux ~ % sudo btrfs check --repair /dev/mapper/black enabling repair mode Checking filesystem on /dev/mapper/black UUID: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 Fixed 0 roots. checking extents checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 owner ref check failed [1082114048 16384] repair deleting extent record: key [1082114048,168,16384] adding new tree backref on start 1082114048 len 16384 parent 0 root 5 Repaired extent references for 1082114048 ref mismatch on [59038556160 4096] extent item 1, found 0 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 incorrect local backref count on 59038556160 root 5 owner 334393 offset 0 found 0 wanted 1 back 0x56348aee5de0 backref disk bytenr does not match extent record, bytenr=59038556160, ref bytenr=0 backpointer mismatch on [59038556160 4096] owner ref check failed [59038556160 4096] checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 failed to repair damaged filesystem, aborting marble@archlinux ~ % dmesg > /tmp/dmesg.log ``` Any clues? It's not thinking it's a raid6 array. All the messages before this one: Btrfs loaded, crc32c=crc32c-intel Are completely unrelated to BTRFS (because anything before that message happened before any BTRFS code ran). The raid6 messages are actually from the startup code for the kernel's generic parity RAID implementation. These: BTRFS error (device dm-1): bad tree block start 9385453728028469028 1082114048 BTRFS error (device dm-1): bad tree block start 2365503423870651471 1082114048 Are the relevant error messages. Unfortunately, I don't really know what's wrong in this case though. Hopefully one of the developers will have some further insight. -- 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
btrfs suddenly think's it's raid6
Hello, I have an external HDD. The HDD contains no partition. I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs. It's used to store some media files. The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux to play music from the drive. After disconnecting the drive from the Pi and connecting it to my laptop again, I couldn't mount it anymore. If I read the dmesg right, it now thinks that it's part of a raid6. btrfs check --repair also didn't help. ``` marble@archlinux ~ % uname -a Linux archlinux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 GNU/Linux marble@archlinux ~ % btrfs --version btrfs-progs v4.16.1 marble@archlinux ~ % sudo cryptsetup open /dev/sda black [sudo] password for marble: Enter passphrase for /dev/sda: marble@archlinux ~ % mkdir /tmp/black marble@archlinux ~ % sudo mount /dev/mapper/black /tmp/black mount: /tmp/black: can't read superblock on /dev/mapper/black. marble@archlinux ~ % sudo btrfs fi show Label: 'black' uuid: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 Total devices 1 FS bytes used 143.38GiB devid1 size 465.76GiB used 172.02GiB path /dev/mapper/black marble@archlinux ~ % sudo btrfs check --repair /dev/mapper/black enabling repair mode Checking filesystem on /dev/mapper/black UUID: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5 Fixed 0 roots. checking extents checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 owner ref check failed [1082114048 16384] repair deleting extent record: key [1082114048,168,16384] adding new tree backref on start 1082114048 len 16384 parent 0 root 5 Repaired extent references for 1082114048 ref mismatch on [59038556160 4096] extent item 1, found 0 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 incorrect local backref count on 59038556160 root 5 owner 334393 offset 0 found 0 wanted 1 back 0x56348aee5de0 backref disk bytenr does not match extent record, bytenr=59038556160, ref bytenr=0 backpointer mismatch on [59038556160 4096] owner ref check failed [59038556160 4096] checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979 checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3 bytenr mismatch, want=1082114048, have=9385453728028469028 failed to repair damaged filesystem, aborting marble@archlinux ~ % dmesg > /tmp/dmesg.log ``` Any clues? Best regards, marble [0.00] Linux version 4.17.2-1-ARCH (builduser@heftig-9574) (gcc version 8.1.1 20180531 (GCC)) #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 [0.00] Command line: initrd=\initramfs-linux.img cryptdevice=PARTLABEL=root:root_luks root=/dev/mapper/root_luks quiet rw [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable [0.00] BIOS-e820: [mem 0x0008c000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xb50dcfff] usable [0.00] BIOS-e820: [mem 0xb50dd000-0xb50ddfff] ACPI NVS [0.00] BIOS-e820: [mem 0xb50de000-0xb50defff] reserved [0.00] BIOS-e820: [mem 0xb50df000-0xbea16fff] usable [0.00] BIOS-e820: [mem 0xbea17000-0xbff2dfff] reserved [0.00] BIOS-e820: [mem 0xbff2e000-0xbff99fff] ACPI NVS [
