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

Re: [Xen-devel] PCI passthrough problems after legacy update of xen 4.1



Hi,

I started by looking at xm dmesg with max log level, before adding debug code anywhere. It turns out that when starting the failing config, I get (only) this message:

(XEN) physdev.c:209: dom4: pirq 19 conflicts with irq 19

 That is when I pass the USB controller first, "pci = [04:00.0, 41:00.0, 41:00.1]" If I try to pass only the HDMI audio (pci = 41:00.1), I get:

(XEN) physdev.c:209: dom5: pirq 17 conflicts with irq 17

It may be also in the standard log level, I might have missed it before.

Output from 'xm dmesg' from running the working config "pci = [ 41:00.0, 41:00.1, 04:00.0 ]", with which the devices gets irq:s 16, 17 and 19 (in that order):

http://pastebin.com/NNWTrk8H

Output from 'xm dmesg' before starting any VM:

http://pastebin.com/QmZJpvP9

The last line
 
(XEN) physdev.c:171: dom0: wrong map_pirq type 3

has always been around on my system, as long as I can remember. I realize now that it may be related.

From your answers so far I assume that debugging further is simply a matter of putting printfs at sensible points in physdev_map_pirq() and/or dumping values. I'll give compiling a try during the weekend.

Regards,
Andreas


2013/5/3 Jan Beulich <JBeulich@xxxxxxxx>
>>> On 03.05.13 at 16:56, Andreas Falck <falck.andreas.lists@xxxxxxxxx> wrote:
>>
>> But from what Andreas told us he's not even getting here
>> anymore after the small xend adjustment. As written earlier,
>> he'll need to add some extra printing to the physdev_map_pirq()
>> path.
>
>
> Just tell me what I should add and I'll try to add it. If we have concluded
> that the change in pciif.py is valid, I can skip that part of the debugging
> search space. Unless you want more information from the error as of before
> the change.

The reason for the error before that change is understood (hence
the adjustment to the xend code).

I can of course work on handing you a debugging patch, but you
doing so yourself would improve the turnaround quite significantly.

And yes, even without any debugging patch, seeing a full hypervisor
log especially for the case where you got the EEXIST error in xend
might already help.

Jan


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

 


Rackspace

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