Re: [Xen-devel] Panic when starting DomU with passthrough

[Alexia Benington <alexbenington@xxxxxxxxx>]

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
>

Attachment: 090219.1.log
Description: Text Data

Attachment: 090219.2.log
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel