I've only been able to reproduce this on systems with an Intel IOMMU. Disabling the IOMMU in the firmware (usually labelled "VT-d") lets the latest 4.13 i386 kernel boot. It's also reproducible in qemu if you give it an IOMMU, eg. "-machine q35 -device intel-iommu".
The problem is that the IDT page (0xffc00000) overlaps the FIX_BTMAPS range. IOMMU detection tries to read ACPI tables, which eventually calls early_ioremap, which maps an ACPI table over the IDT, and then eventually unmaps it completely. The first kernel interrupt after that (usually in test_wp_bit) triple-faults when it can't find the IDT.
I've only been able to reproduce this on systems with an Intel IOMMU. Disabling the IOMMU in the firmware (usually labelled "VT-d") lets the latest 4.13 i386 kernel boot. It's also reproducible in qemu if you give it an IOMMU, eg. "-machine q35 -device intel-iommu".
The problem is that the IDT page (0xffc00000) overlaps the FIX_BTMAPS range. IOMMU detection tries to read ACPI tables, which eventually calls early_ioremap, which maps an ACPI table over the IDT, and then eventually unmaps it completely. The first kernel interrupt after that (usually in test_wp_bit) triple-faults when it can't find the IDT.
I've built an experimental kernel with the FIX_BTMAPS vs IDT conflict fixed at https:/ /people. canonical. com/~wgrant/ linux-image- 4.13.0- 31-generic_ 4.13.0- 31.34~16. 04.1_i386. deb. It works on my affected hardware and qemu, but it would be good to confirm that it's the same issue that others have.