[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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;

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.