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

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


  • To: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
  • From: Alexia Benington <alexbenington@xxxxxxxxx>
  • Date: Sat, 21 Feb 2009 18:18:14 -0500
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 21 Feb 2009 15:18:38 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wvATjj9snWQd7c5sAEFYos+MTckNoOl6yETyzJ9WyQ8r0n2OhUGszs0o7h6ENfenv1 M7nPau1Iw+MwgZCKF0P4EO5HEo48mtAFarqfLVpmW+Ygi5NH6lnBmO3TLQT1SWn9ECwF KXcO5EYsznmvEVNZ0cNSiEMxPnryiVTk2qWv4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi all,

This doesn't seem to be going anywhere. Has anyone encountered this
before? Why would it try to write to 7e000000 with Reason 2, followed
by 7d000000 with Reason 5? Note that this differs from my first post
where it tries to write to fffff000.

What does the numbers represent for the various reasons? Is the
interrupt request triggered due to the series of illegal writes?

Thanks and have a good weekend.

-Alex

On Thu, Feb 19, 2009 at 9:37 AM, Alexia Benington
<alexbenington@xxxxxxxxx> wrote:
> 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
>>
>

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


 


Rackspace

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