similar to: Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

Hi, On 10/23/18 7:34 PM, Ian Jackson wrote: > Control: retitle -1 max grant frames problem (domu freeze with linux-image-4.9.0-4-amd64) > Control: severity -1 important > Control: reassign -1 src:xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 my last comment in this bts bug was about:

Hello, Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: > > I have forwarded the original mail: all VM I/O get stuck, and thus the > > VM becomes unusable. > > These are in many cases the symptoms of running out of "grant frames". Oh! That could be it indeed. I'm wondering what could be monopolizing them, though, and why +deb9u11 is affected

Control: retitle -1 max grant frames problem (domu freeze with linux-image-4.9.0-4-amd64) Control: severity -1 important Control: reassign -1 src:xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 Just gardening here. (i) Bug title should mention grant frames. (ii) This does not affect all use cases and is not, IMO, RC. Although we should certainly see if we can improve it. (iii) Britney is confused

Hi, I've tried hitting up the CentOS forums and thought I'd try here too as I don't seem to be getting any bites. We've been in the process of migrating all our hypervisors over to CentOS 7 using Xen. Once we had a few up and running we started to notice that the DomU's would randomly freeze. They become unresponsive to any network traffic, stop consuming CPU resources on the

>> We tested the current lenny kernel linux-image-3.16.0-4-amd64 as well >> as the backport linux-image-4.1.0-0.bpo.1-amd64 on the dom0 as well >> as the domU. > > (I suppose you meant s/lenny/jessie/ ;-) Oops, yes :) > These are kernel ABI versions, the package release versions are things > like 3.16.7-ckt17-1 or 4.2.5-1~bpo8+1, which yu can either get from >

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u1 Severity: important A few minutes after starting a domU, network access is no longer possible from and to it. This does not always happen and is not easily reproducible, but seems to occur in all newly started domUs from some point in time on. However, also restarting the dom0 does not necessarily prevent the problem. At the moment when

I''m trying to get two hosts exchange their ssh host keys using virtual exported resources. What happens is that one host gets both keys installed without problems, while the other one fails with the following error message: err: Could not retrieve configuration: Exported resource Sshkey[front.irb.lo] cannot override local resource I found some reference to this in ticket #731, but

Hello Luke, After our services do now successfully restart, we hit now the already opened bug where the restarted service takes over puppetd port if it''s configured to listen. One solution is to remove the listen option but it''s very nice to invoke a puppetrun on the clients from the central server without waiting for its next run. Where you already able to take a look? It

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-3 Severity: important Hi, I have some domUs with two network interfaces, eth0 and eth1. eth0 is not configured in /etc/network/interfaces and so is not brought up at boot time. eth0 is on the host's external network bridge and eth1 is on the host's local network bridge. On dom0 I get messages like 'vif vif-10-0 vif10.0: draining TX

Package: xen-hypervisor-4.1-amd64 Version: 4.1.3-3 Severity: normal Forwarded: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1789 Dear Debian Xen Team, after an upgrade from Squeeze to Wheezy I see about ten of these per second filling my system log (about 8 MB/h): Nov 23 00:15:37 acromantula kernel: [ 462.544193] powernow-k8: fid trans failed, fid 0x2, curr 0x0 Nov 23 00:15:37 acromantula

On 12/10/2010 11:37 PM, Ian Campbell wrote: > severity 606589 important > reassign 606589 xen-hypervisor-4.0-amd64 > merge 606590 606589 > thanks > > At the core this is the same issue as 606590. I think a single report is > enough to allow this to be fixed in the relevant place, if the kernel > ends up being the place to fix then the bug can be reassigned as >

Hi all, I''m trying to get puppet working for the first time, and I''ve run into something that''s got me stumped. This is all on Solaris 10/x64. The initial startup of puppetmasterd wasn''t working, and it appeared to be related to the SSL certs not getting generated properly. I managed to trace that down to the fact that facter isn''t finding the

Hi, I have a Gentoo server running puppetmasterd from Puppet 0.24.1 and a Ubuntu server running puppetd from Puppet 0.23.2. I have added listen=true to the [puppetd] section on the client and run puppetd --debug. I then run puppetrun --debug --host hostname on the puppetmaster server. This is the output I get: Puppetmaster: # puppetrun --debug --host hostname Failed to load ruby LDAP library.

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-4 Severity: important # /etc/init.d/xend start Restarting XEN control daemon: xendTraceback (most recent call last): File "/usr/lib/xen-3.0.3-1/bin/xend", line 40, in <module> from xen.xend.server import SrvDaemon File "/usr/lib/xen-3.0.3-1/lib/python/xen/xend/server/SrvDaemon.py", line 17, in <module> import

Is there a fix for this in the works/coming for squeeze or do I have to patch the package myself? If so, how? Thanks, a grateful Debian user that hasn't patched packages yet! Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20101122/8433308c/attachment.htm>

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9 Severity: critical Justification: breaks the whole system Dear Maintainer, After upgrading the R610 server from Debian 7 to Debian 8, the dom0 becomes unresponsive via ssh after an hour or so, although the domUs still remain accessible. Initially we thought it may be a disk space issue on / or /boot so action was taken to increase those

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u4 Severity: important Dear Maintainer, I installed a fresh Debian Jessie amd64 on our new server with Intel Xeon E3-1270 v5 Skylake CPU and EFI. Linux without Xen boots flawlessly and shows 8 CPU cores. I then tried all combinations of Xen 4.4 (with xsave=off for Skylake support), Xen 4.6 (crashes after a few seconds during boot) and

On 5/10/2021 1:33 PM, Chuck Zmudzinski wrote: > Package: src:linux > Version: 5.10.28-1 > Severity: normal > Tags: upstream > > Dear Maintainer, > > I have been using Xen's PCI and VGA passthrough feature since wheezy and jessie were the stable versions, and back then both Windows HVMs and Linux HVMs would function with the Intel Integrated Graphics Device (IGD), the

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: important Tags: patch Hi, I'm having troubles with windows 2008 server with HVM on XEN. When I allocate more than one CPU to the Windows VM, windows crashes after a few minutes with a BSOD. Other people have this problem, too. The Exact error message (BSOD) is: (the unique lines) A clock interrupt was not received on a

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: wishlist Xen can run 32bit domU clients on 64bit (amd64) dom0. Unfortunately only amd64 linux-image-xen packages are available on arch amd64. Please provide 686 packages as well (if possible). This would enable the installation of 32bit clients without the need to manually compile a kernel. Feel free to reassign this bug to the correct