Re: [Xen-devel] eDP screen corruption using linux 3.8 & xen 4.2

[Ben Guthro <ben@xxxxxxxxxx>]

OK

This appears to be related to the iommu code, as Kevin alluded to a bit.

Booting with iommu=off seems to work around this problem.

This probably is not a viable solution, however.

Other iommu= options I have used in the past seem to not make a difference (no-intremap, eg)

If I bail out and disable the iommu when I find a bad RMRR, the system will boot properly:

diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c

index 3fbc5e6..e1b8df5 100644

--- a/xen/drivers/passthrough/vtd/dmar.c

+++ b/xen/drivers/passthrough/vtd/dmar.c

@@ -533,6 +533,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)

                 "base = %"PRIx64" end = %"PRIx64"; "

                 "iommu_inclusive_mapping=1 parameter may be needed.\n",

                 base_addr, end_addr);

+       iommu_enabled = 0;

+       return 0;

     }

 #endif

This seems like a clearly incorrect solution - but I'm not sure what I should be doing in this case here...

On Tue, Mar 5, 2013 at 1:35 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

On Tue, Mar 05, 2013 at 04:42:42PM +0000, Jan Beulich wrote:
> >>> On 05.03.13 at 17:33, Ben Guthro <ben@xxxxxxxxxx> wrote:
> > I turned up the debug, but didn't see this
> > I am seeing other oops messages in the log now though...not sure if these
> > are related.
>
> The first one likely is related (rax being 000000aa000000aa and
> apparently used as memory address, and that value very much
> looks like 2 pixels from a 32-bit pixel map). So I'd guess that
> there's once again some physical/machine address mixup.

Good spotting! Ben I think the i915 driver is innocent this time.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel