On 23/07/2019 18:58, Roman Shaposhnik wrote: > On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper > wrote: >> On 23/07/2019 18:48, Roman Shaposhnik wrote: >>> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper >>> wrote: >>>> On 23/07/2019 18:32, Roman Shaposhnik wrote: >>>>> Hi Roger! >>>>> >>>>> I applied your patch, removed no-igfx and I still see the original >>>>> problem. Please let me know what other logs/debugs would you need at >>>>> this point. >>>> Please can you collect a full boot log with iommu=debug >>> How long of an output should I expect when iommu=debug is enabled? >>> I've just enabled it and I'm looking at what appears to be an endless >>> scroll of debug info. >>> >>> This is all I see for the good 5 minutes at this point. Culminating with: >>> (XEN) (XEN) APIC error on CPU0: 40(00) >>> >>> and a failure to boot. >>> >>> Note that this is still without no-igfx >>> >>> I'm attaching the tail end of this log. >> Sadly, what is useful is the head of the log, before it starts >> complaining loudly about every DMA fault. > No worries. Take a look at the head of the log attached. > > Btw, I'm kind of curious why iommu=debug would actually make it crash The system is rather sickly, and is debugging at a rate slower than incoming faults, which is going to starve whichever CPU is taking the IOMMU interrupt. I wouldn't worry about the APIC error now. Curiously, there is one single intremap error on boot, which is likely unrelated. (XEN) [VT-D]INTR-REMAP: Request device [0000:f0:1f.0] fault index 0, iommu reg = ffff82c0008e0000 (XEN) [VT-D]INTR-REMAP: reason 22 - Present field in the IRTE entry is clear This will be irq0 from the IO-APIC. Can you try booting following the guidance from (XEN) [VT-D]found ACPI_DMAR_RMRR: (XEN) [VT-D]  RMRR address range 8d800000..8fffffff not in reserved memory; need "iommu_inclusive_mapping=1"? (XEN) [VT-D] endpoint: 0000:00:02.0 which I noted on my first reply?  Given that Rogers patch didn't help, something else is going on. ~Andrew