Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Tue, Jul 23, 2019 at 11:12 AM Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 23/07/2019 18:58, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:50 AM Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 23/07/2019 18:48, Roman Shaposhnik wrote:
>
> On Tue, Jul 23, 2019 at 10:35 AM Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx> 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.

Got it. Makes sense.

> 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.

Sorry -- missed that option the first time around.

Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
booted the system just fine.

There are no issues with screen.

I am attaching a full log.

Btw, my understanding is that this may point to a BIOS issue. Which
would be fair conclusion, but I've got to wonder why Xen 4.11 didn't
seem to be susceptible to this BIOS issue.

Thanks,
Roman.

Attachment: xen-log3.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel