On Tue, 01 Nov 2016, Martin Kepplinger <mart...@posteo.de> wrote: > Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel <jroe...@suse.de>: >>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote: >>> This is one machine booting a bad kernel. I could provide another >>> example later this week. >> >>You have an Intel system without any IOMMU (enabled), otherwise you >>would have a DMAR-ACPI table, but there is none: >> >>> [ 0.000000] ACPI: RSDP 0x00000000000FE020 000024 (v02 ACRSYS) >>> [ 0.000000] ACPI: XSDT 0x00000000A6FFE210 00008C (v01 ACRSYS >>ACRPRDCT 00000001 01000013) >>> [ 0.000000] ACPI: FACP 0x00000000A6FFB000 0000F4 (v04 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: DSDT 0x00000000A6FEC000 00B903 (v01 ACRSYS >>ACRPRDCT 00000000 1025 00040000) >>> [ 0.000000] ACPI: FACS 0x00000000A6FBB000 000040 >>> [ 0.000000] ACPI: FACS 0x00000000A6FBB000 000040 >>> [ 0.000000] ACPI: UEFI 0x00000000A6FFD000 000236 (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: ASF! 0x00000000A6FFC000 0000A5 (v32 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: HPET 0x00000000A6FFA000 000038 (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: APIC 0x00000000A6FF9000 00008C (v02 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: MCFG 0x00000000A6FF8000 00003C (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: SLIC 0x00000000A6FEB000 000176 (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: SSDT 0x00000000A6FEA000 0006FE (v01 ACRSYS >>ACRPRDCT 00001000 1025 00040000) >>> [ 0.000000] ACPI: BOOT 0x00000000A6FE8000 000028 (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: ASPT 0x00000000A6FE3000 000034 (v07 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: FPDT 0x00000000A6FE1000 000044 (v01 ACRSYS >>ACRPRDCT 00000001 1025 00040000) >>> [ 0.000000] ACPI: SSDT 0x00000000A6FE0000 00079A (v01 ACRSYS >>ACRPRDCT 00003000 1025 00040000) >>> [ 0.000000] ACPI: SSDT 0x00000000A6FDF000 000A92 (v01 ACRSYS >>ACRPRDCT 00003000 1025 00040000) >> >>So it is pretty unlikely that any change in IOMMU code causes your >>issue. Not sure why your bisecting ended up there. You also have an >>Intel GPU in the system: >> >>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation >>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if >>00 [VGA controller]) >>> Subsystem: Acer Incorporated [ALI] Device 0748 >>> Flags: bus master, fast devsel, latency 0, IRQ 28 >>> Memory at c0000000 (64-bit, non-prefetchable) [size=4M] >>> Memory at b0000000 (64-bit, prefetchable) [size=256M] >>> I/O ports at 2000 [size=64] >>> [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] >>> Capabilities: <access denied> >>> Kernel driver in use: i915 >> >>My best guess is that some changes in the i915 driver cause your issue, >>I add the maintainers of i915 to the cc-list, maybe they have an idea. >> >> >> Joerg > > > I'll come up with a nouveau system example and it was quite easy to bisect. > To quote the merge commit msg: > > This also required some changes outside of the IOMMU code, but these are > acked by the respective maintainers. > > Any help on bisecting into it would be awesome.
So the information here is pretty scarce. Please file a bug at [1], describe the problem, perhaps add drm.debug=14 module parameter and attach dmesg from boot to reproducing the problem. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center
