Hi,
If you were referring to the mail "iommu hangs boot", then yes, I'm
referring to the integrated Intel gfx, which I managed to get
passthrough to work, briefly, before this happened. I never got the
ATI gfx to work, although somehow it needs to be present for Dom0 to
even boot correctly. But I think these are two different issues.
The lspci output is in "090219.2.log". It's a HVM guest.
This is the output after the patch: sp = 1, peoi[sp-1].vector = 184,
vector = 184
The complete log is in "090219.1.log".
Thanks.
-Alex
On Thu, Feb 19, 2009 at 9:04 AM, Espen Skoglund
<espen.skoglund@xxxxxxxxxxxxx> wrote:
> I presume that 00:02.0 is the graphics card you mentioned in your
> earlier mail? Could you do an lspci on the device in question ('lspci
> -vv -s 0:2.0'). Is the dumU a PV or a HVM guest? If it is a PV
> guest, is iommu=pv enabled or not?
>
> Looks like the device is trying to write to 'fffff000' which seems
> like a bit of an odd address to be accessing.
>
> Anyhow, even if the accesses of the device seem a bit mad it still
> should not be able to access random xen internal memory. I can't see
> any good reason why the assertion should be triggered. Could you
> perhaps apply the patch below to give us some more clue as to what is
> happening?
>
> Keir, could this assertion possibly be related to the recent IRQ
> acktype changes?
>
> eSk
>
090219.1.log
Description: Text Data
090219.2.log
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|