Hello,
running autoboot with coreboot as of commit a3e41c089602c58409e8dfd4aceecbdd7d4f4a5b being the latest not breaking USB and PCI-E on my ThinkPad X201.
Writing data to USB storage appears bugged.
I tested this using different disks on three different machines:
- ThinkPad X201, autoboot, latest Parabola - ThinkPad T43, stock firmware, Debian 8 - Asus EeePC 901, stock firmware, latest Arch
In all combinations, I created a btrfs filesystem inside a LUKS container on the whole disk, using both USB and internal SATA (except for the 901):
$ crytpsetup luksFormat /dev/sdb $ cryptsetup open /dev/sdb test $ mkfs.btrfs /dev/mapper/test $ mount -o compress=lzo /dev/mapper/test /mnt $ dd if=/dev/urandom of=/mnt/20M bs=1M count=20 iflag=fullblock $ umount /mnt $ btrfs check /dev/mapper/test
Only when using my X201 *with coreboot and USB*, this procedure resulted in the following error:
$ btrfs check /dev/mapper/test Checking filesystem on /dev/mapper/test UUID: 33c88ec2-2c4e-4844-905f-c0fbebc00a1f checking extents bad metadata [29605888, 29622272) crossing stripe boundary bad metadata [29736960, 29753344) crossing stripe boundary Errors found in extent allocation tree or chunk allocation checking free space cache checking fs roots checking csums checking root refs found 21135362 bytes used err is 0 total csum bytes: 20480 total tree bytes: 163840 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 129312 file data blocks allocated: 21495808 referenced 21495808 btrfs-progs v4.1.2-32-g6054018
Using the same disk with my internal SATA port and testing from a live USB stick showed no errors at all.
Every other setup worked fine and didn't show any error either. I also tested this with ext4, but as expected, with ext4 everything seems to be ok since it doesn't even provide this type of error detection.
This clearly seems to be a coreboot related issue. I used to run the latest coreboot with autoboot, but booting from USB somehow didn't work and someone in #coreboot told me USB an PCI-E was broken as of commit 456f495d, so I reset to the above mentioned. USB boot worked again, but then I noticed this faulty behaviour.
I attached the coreboot config used to build my current autoboot image with.
Hopefully this report is useful to find the bug and eventually fix it asap.