similar to: Bug#810379: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

On Wed, Jan 27, 2016 at 7:30 PM, Konrad Rzeszutek Wilk < konrad.wilk at oracle.com> wrote: > On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote: > > Xen developers, > > > > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed > > NIC stopped working. > > This bug was probably introduced in Debian Jessie sometime > > between

Xen developers, After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed NIC stopped working. This bug was probably introduced in Debian Jessie sometime between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-12-30 was the last time I upgraded without any problems according to my dpkg.log. This bug has also been reported to Debian Bug (https://bugs.debian.org/810379), where I got

Source: xen Severity: normal Dear Maintainer, After an upgrade, my passthroughed NIC stopped working. I created a new jessie domU and tried to passthrough some PCI devices and found that both USB3 host controller and tg3 NIC generated these lines in domU dmesg: xen:events: Failed to obtain physical IRQ 31 xen:events: Failed to obtain physical IRQ 32 xen:events: Failed to obtain physical IRQ 33

Yes, you can put the 'Tested-by' from me, I'm perfectly fine with that. Thank you for your help! Br, Tommi On Fri, Feb 05, 2016 at 12:35:10AM +0100, Tommi Airikka wrote: > Hi, > > I patched the deb8u2 source with all four patches and built a new deb. .. snip.. > > Next, I upgraded dom0 with the new linux-image deb and rebooted the machine. > > dom0 "uname

On Wed, 2016-02-03 at 15:28 -0500, Konrad Rzeszutek Wilk wrote: > > > And I wonder if the XEN_DOMCTL_irq_permission aka, > > > xc_domain_irq_permission > > > had been called. I remember that at some point we missed it for > > > Xend.. > > > > > False alarm. > > It was all in Linux. Attached are four patches (the first two > are for

Hi, I'm starting to see, on a pretty standard Debian Jessie installation, some error messages that are apparently related to the ETOOMANYREFS errno. Firstly, the mail log shows this: dovecot: pop3-login: Error: fd_send(pop3, 18) failed: Too many references: cannot splice And then the login process fails: dovecot: pop3-login: Internal login failure (pid=34388 id=1) (internal failure, 1

On Mon, Feb 01, 2016 at 09:50:53AM -0500, Konrad Rzeszutek Wilk wrote: > > The second bullet looks at first pretty interesting from this PoV, > > see?http://xenbits.xen.org/xsa/advisory-157.html?for info on the XSA and > > the various patches. Konrad is on the CC already so hopefully he has some > > ideas. > > Thanks. I will try to reproduce this with the upstream

On Wed, Feb 03, 2016 at 10:26:58AM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Feb 03, 2016 at 03:22:30PM +0100, Marek Marczykowski-G?recki wrote: > > On Mon, Feb 01, 2016 at 09:50:53AM -0500, Konrad Rzeszutek Wilk wrote: > > > > The second bullet looks at first pretty interesting from this PoV, > > > > see?http://xenbits.xen.org/xsa/advisory-157.html?for info on

Hi , I am testing pcifront on freebsd domU using following sound card [ Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] Following sound driver is used for this sound card on Freebsd: *snd_csa*-- Crystal Semiconductor CS461x/462x/4280 PCI bridge device driver I am able to detect the card. pci3: <PCI bus> on pcib3 csa0: <CS4280/CS4614/CS4622/CS4624/CS4630> mem

Hi gurus, I used xen 4.1.0 (64bit) + dom0 kernel 2.6.32.39 (32bit) + domu kernel 2.6.32.39 (32bit) environment. I was trying to passthru Broadcom NIC to domu. The NIC can be UP but not RUNNING, on domu #ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:10:18:95:25:90 inet addr:10.0.0.3 Bcast:10.0.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1

Signed-off-by: Yinghai Lu <yinghai at kernel.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Cc: virtualization at lists.linux-foundation.org --- drivers/pci/xen-pcifront.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index 966abc6..c90835f 100644 --- a/drivers/pci/xen-pcifront.c +++

Signed-off-by: Yinghai Lu <yinghai at kernel.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Cc: virtualization at lists.linux-foundation.org --- drivers/pci/xen-pcifront.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index 966abc6..c90835f 100644 --- a/drivers/pci/xen-pcifront.c +++

When destroying pcifront/pciback, the following message appears in the guest linux kernel log. WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! This is caused by the wrong disconnect procedure that pcifront terminates the gnttab foreign access before pciback unmaps the ring. This patch corrects the handling of pcifront/pciback destruction sequence. Firstly pcifront

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Hello all. I''ve upgraded my drives, and in doing so loaded FC8. Latest kernel-xen.x86_64 (2.6.21.7-5) and xen.x86_64 (3.1.2-5) available, using 2 Intel NICs with e1000 driver. All worked fine on FC5 with custom domU FC5 with pcifront and NIC drivers in kernel. Now, I''m unable to get the NICs to function inside my domU. The are visible in lspci, and ipconfig. DomU dmesg

Hi, A while ago I sent an email regarding these "*ETOOMANYREFS* Too many references: cannot splice." that we've seen since Debian updated the Jessie kernel to 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 while older kernels, like 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 showed no errors at all. I was wondering if no one

Dear All, The production server supports Intel Virtualization Technology. Processor is an Intel Xeon 1.86 GHz Quad Core. 8 GB DDR2 memory. There is also an Emulex LightPulse Fiber Channel HBA adapter. The host operating system (Dom 0) is RHEL 5 x86 with Xen Virtualization technology. Dom 0 kernel is 2.6.18-8.el5xen. I have recompiled the Dom 0 kernel so that pciback

Hi, It seems that destroying pcifront/pciback always fails on current xen. This patch fixes the problem, making pciback switch to "Closed" state after pcifront switched to "Closing" state. Regards, ------------------- Yosuke Iwamatsu NEC Corporation _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com