Thanks for reporting this bug; nice finding on pci=noats.
$ grep -A1 noats ~/git/linux/Documentation/admin-guide/kernel-parameters.txt
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
Wondering if the amd gfx drivers with ats/iommu (ie, w/out pci=noats) causes memory corruption:
The screenshot in #1 shows that initramfs unpacking failed -- say, something corrupted the compressed initramfs image loaded in memory -- and this happened closely to when AMD-Vi failed to access an IOMMU perf count(er? I guess.)
And it seems to be graphics related, not just ats/iommu code alone, which prints 'AMD-Vi' (it's in linux/drivers/iommu/amd/) since recovery mode, with 'nomodeset', works fine.
When you boot in recovery mode, do you see initramfs unpacking failed as well? (please check 'dmesg | grep -i initramfs')
Hi Rauno,
Thanks for reporting this bug; nice finding on pci=noats.
$ grep -A1 noats ~/git/linux/ Documentation/ admin-guide/ kernel- parameters. txt
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
Wondering if the amd gfx drivers with ats/iommu (ie, w/out pci=noats) causes memory corruption:
The screenshot in #1 shows that initramfs unpacking failed -- say, something corrupted the compressed initramfs image loaded in memory -- and this happened closely to when AMD-Vi failed to access an IOMMU perf count(er? I guess.)
And it seems to be graphics related, not just ats/iommu code alone, which prints 'AMD-Vi' (it's in linux/drivers/ iommu/amd/ ) since recovery mode, with 'nomodeset', works fine.
When you boot in recovery mode, do you see initramfs unpacking failed as well? (please check 'dmesg | grep -i initramfs')