SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

[Robert Dunkley]

Hi Everyone,



I was wondering if there is a known fix for this issue? HVMs are fine.

I'm using the IGB driver and after guest reboot and xm destroy and
create I get the following error:
msix entry 0 for dev 05:10:0 are
not freed before acquire again.
msix entry 1 for dev 05:10:0 are
not freed before acquire again.
msix entry 2 for dev 05:10:0 are
not freed before acquire again.
msix entry 0 for dev 09:10:0 are
not freed before acquire again.
msix entry 1 for dev 09:10:0 are
not freed before acquire again.
msix entry 2 for dev 09:10:0 are
not freed before acquire again.

I was wondering if this is related to the first RHEL kernel note here:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.6_Te
chnical_Notes/Known_Issues-kernel-xen.html

"A virtual function NIC might fail to get an IP address after several
iterations of creating and destroying a guest. To work around this
issue, diable interrupt remapping in the system BIOS for kernel-xen."

I don't have a bios setting for that and setting iommu=no-intremap in
Dom0 doesn't help either. Has anyone seen this problem before? Or know
how to fix it?



Thanks in advance,


Rob

The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.

ISPA Member

Re: SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

[Jan Beulich]

>>> On 16.03.11 at 18:16, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> Hi Everyone,
> 
> 
> 
> I was wondering if there is a known fix for this issue? HVMs are fine.
> 
> I'm using the IGB driver and after guest reboot and xm destroy and
> create I get the following error:
> msix entry 0 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 1 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 2 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 0 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 1 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 2 for dev 09:10:0 are
> not freed before acquire again.

You didn't say what kernel you use.

Jan

RE: SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

[Robert Dunkley]

Hi Jan,

Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat
settings among others. Default Centos 5.5 kernel doesn't detect any VF
PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works
perfectly first boot but any subsequent boot gives  error as below:
msix entry 0 for dev 09:10:0 are
not freed before acquire again.
msix entry 1 for dev 09:10:0 are
not freed before acquire again.
msix entry 2 for dev 09:10:0 are
not freed before acquire again.

HVMs are fine with either kernel.

Can you give me any idea where the problem might be? Could this be a
bios ACPI type issue?


Thanks,

Rob


Below is an xmdmesg extract:
[root@missplendid xenvmconfig]# xm dmesg | grep iommu
(XEN) Command line: apic_verbosity=debug dom0_mem=2048M dom0_max_vcpus=1
numa=on guest_loglvl=debug iommu=pv msi=1
(XEN) [VT-D]iommu.c:1731:d32767 DMAR: Forcing write-buffer flush
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 0:0.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:13.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:14.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:14.1
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:14.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:14.3
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.1
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.2
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.3
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.4
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.5
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.6
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf =
0:16.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1f.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.4
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.5
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.6
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.7
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 2:0.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 4:0.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 5:0.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 5:0.1
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 7:0.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 7:0.1
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 9:0.0
(XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 9:0.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:0.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:0.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.4
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.5
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.4
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.3
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2
(XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.0
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.2
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.4
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.6
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.0
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.2
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.4
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.1
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.3
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.5
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.7
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.1
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.3
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.5
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.0
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.2
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.4
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.6
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.0
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.2
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.4
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.1
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.3
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.5
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.7
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.1
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.3
(XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.5


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@novell.com] 
Sent: 17 March 2011 10:21
To: Robert Dunkley
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ
after first boot

>>> On 16.03.11 at 18:16, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> Hi Everyone,
> 
> 
> 
> I was wondering if there is a known fix for this issue? HVMs are fine.
> 
> I'm using the IGB driver and after guest reboot and xm destroy and 
> create I get the following error:
> msix entry 0 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 1 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 2 for dev 05:10:0 are
> not freed before acquire again.
> msix entry 0 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 1 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 2 for dev 09:10:0 are
> not freed before acquire again.

You didn't say what kernel you use.

Jan


The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.

ISPA Member

Member

RE: SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

[Jan Beulich]

>>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> Hi Jan,
> 
> Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat
> settings among others. Default Centos 5.5 kernel doesn't detect any VF
> PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works
> perfectly first boot but any subsequent boot gives  error as below:
> msix entry 0 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 1 for dev 09:10:0 are
> not freed before acquire again.
> msix entry 2 for dev 09:10:0 are
> not freed before acquire again.
> 
> HVMs are fine with either kernel.
> 
> Can you give me any idea where the problem might be? Could this be a
> bios ACPI type issue?

Quite possibly your kernel is missing c/s 1070:2994d2997f9d
(http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d).

Jan

Re: SR-IOV, Paravirt Guest fails to obtain IRQ after first boot

[Pasi Kärkkäinen]

On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:
> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> > Hi Jan,
> > 
> > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat
> > settings among others. Default Centos 5.5 kernel doesn't detect any VF
> > PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works
> > perfectly first boot but any subsequent boot gives  error as below:
> > msix entry 0 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 1 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 2 for dev 09:10:0 are
> > not freed before acquire again.
> > 
> > HVMs are fine with either kernel.
> > 
> > Can you give me any idea where the problem might be? Could this be a
> > bios ACPI type issue?
> 
> Quite possibly your kernel is missing c/s 1070:2994d2997f9d
> (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d).
> 

Robert: Want to open RHEL5 bugzilla entry about this issue? 

-- Pasi

RE: SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot

[Robert Dunkley]

Hi Pasi,



Just got your email but I actually opened a Redhat bug last night:
https://bugzilla.redhat.com/show_bug.cgi?id=688673

Have collected some additional RH employees for cc but no actual comment yet, looking at other bugs the fact that it has not been rejected yet is probably encouraging.

I'm going to try to patch the Centos 5.5 Pciback module myself in the next few hours, hopefully that will get things up and running for me and I won't be waiting on Redhat. I think Redhat must have some interest in VF pass through to paravirt working otherwise they wouldn't have applied change set 998/999 between kernels 194 and 247.


Thanks,

Rob

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: 17 March 2011 20:43
To: Jan Beulich
Cc: Robert Dunkley; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot

On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:
> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> > Hi Jan,
> > 
> > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red 
> > hat settings among others. Default Centos 5.5 kernel doesn't detect 
> > any VF PCI deviavirt VM. Centos 5.5 with 247 kernel detects and 
> > works perfectly first boot but any subsequent boot gives  error as below:
> > msix entry 0 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 1 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 2 for dev 09:10:0 are
> > not freed before acquire again.
> > 
> > HVMs are fine with either kernel.
> > 
> > Can you give me any idea where the problem might be? Could this be a 
> > bios ACPI type issue?
> 
> Quite possibly your kernel is missing c/s 1070:2994d2997f9d 
> (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d).
> 

Robert: Want to open RHEL5 bugzilla entry about this issue? 

-- Pasi


The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.

ISPA Member

RE: SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot

[Robert Dunkley]

Hi Jan,

I just wanted to let you know that I applied you patch to pciback and it partially fixes the problem. It seems to me that the Redhat paravirt VM is not properly detaching itself from the VF on clean shutdown or reboot. Redhat have responded and here is the message I left them:

I've just finished building pciback from the 247 kernel source with the patch.
The patch applied cleanly and partially fixes the problem.

Abrupt paravirt VM restart is now OK (eg. xm destroy testvm && xm create testvm
now works)
Clean restart or clean shutdown of the VM and then xm create of VM still shows
the problem.

Additional information is appearing in Dom console when the failures occur, the
VM has 2 Intel 82576 VF assignments from 2 different Intel 82576 lan chips and
the increased info in dom0 console looks like this:
msix entry 0 for dev 05:10:0 are not freed before acquire again.
msix entry 1 for dev 05:10:0 are not freed before acquire again.
msix entry 2 for dev 05:10:0 are not freed before acquire again.
msix entry 0 for dev 09:10:0 are not freed before acquire again.
msix entry 1 for dev 09:10:0 are not freed before acquire again.
msix entry 2 for dev 09:10:0 are not freed before acquire again.
unmap irq ff failed
unmap irq fe failed
unmap irq fd failed
unmap irq fc failed
unmap irq fb failed
unmap irq fa failed

What is responsible for un-assigning the MSIX IRQ when the VM is shutdown or
rebooted? I'm using the igbvf driver that is included with the 247 kernel.



Thanks,


Rob Dunkley

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: 17 March 2011 20:43
To: Jan Beulich
Cc: Robert Dunkley; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot

On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:
> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote:
> > Hi Jan,
> > 
> > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red 
> > hat settings among others. Default Centos 5.5 kernel doesn't detect 
> > any VF PCI deviavirt VM. Centos 5.5 with 247 kernel detects and 
> > works perfectly first boot but any subsequent boot gives  error as below:
> > msix entry 0 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 1 for dev 09:10:0 are
> > not freed before acquire again.
> > msix entry 2 for dev 09:10:0 are
> > not freed before acquire again.
> > 
> > HVMs are fine with either kernel.
> > 
> > Can you give me any idea where the problem might be? Could this be a 
> > bios ACPI type issue?
> 
> Quite possibly your kernel is missing c/s 1070:2994d2997f9d 
> (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d).
> 

Robert: Want to open RHEL5 bugzilla entry about this issue? 

-- Pasi


The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.

ISPA Member