similar to: Bug#741319: [xen-system-amd64] Xen 4.4 is available

On Wed, Apr 3, 2013 at 12:12 AM, Török Edwin <edwin+ml-debian at etorok.net> wrote: > On 04/03/2013 01:20 AM, Renato Golin wrote: >> Hi Torok, >> >> I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... >> >> I though the dbdir could be the culprit, but it has only one file.

On 04/03/2013 01:20 AM, Renato Golin wrote: > Hi Torok, > > I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... > > I though the dbdir could be the culprit, but it has only one file. Attached is the output of both. > The version of ClamAV in the LLVM test-suite is quite old, and it first unpacks

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- tools/firmware/ovmf-makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile index c3cd466..073ed44 100644 --- a/tools/firmware/ovmf-makefile +++ b/tools/firmware/ovmf-makefile @@ -10,7 +10,7

On 19 April 2013 17:48, Török Edwin <edwin at etorok.net> wrote: > Otherwise what might seem like a 20% improvement > could very well be just a 0.2% improvement in practice. > This is (maybe to a lesser extent) what happens with most of our benchmarks, and running them 3 times doesn't add that much confidence but makes it run much slower. I end up treating the test-suite as

On 04/15/2013 11:01 AM, David Blaikie wrote: > On Wed, Apr 3, 2013 at 12:12 AM, Török Edwin <edwin+ml-debian at etorok.net> wrote: >> On 04/03/2013 01:20 AM, Renato Golin wrote: >>> Hi Torok, >>> >>> I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... >>> >>>

I have installed dom0 Wheezy 64 bit on Dell PowerEdge T310 with kernel from package and xen-unstable. System is in Uefi mode and booted with grub-efi-amd64. Booting without xen efibootmgr works, while with xen not, efivars kernel module is loaded but show this message: efibootmgr Fatal: Couldn''t open either sysfs or procfs directories for accessing EFI variables. Try ''modprobe

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

- Enable vdagent on upstream qemu if spice is used. Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz> --- tools/libxl/libxl_dm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index a8a36d7..110f1dc 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -427,6 +427,10 @@ static char **

On Fri, 2014-09-05 at 13:39 +0200, trenta wrote: > Additional information: > http://lists.xen.org/archives/html/xen-devel/2013-09/msg00584.html This thread suggests that mmconfig might be the issue, in which case does adding "mmcfg=0" to your hypervisor command line help? I'd recommend continuing to pursue this upstream, there are far more experts on the low level aspect of

Processing commands for control at bugs.debian.org: > reassign 771297 xen-hypervisor-4.4-amd64 4.4.1-3 Bug #771297 [xen-hypervisor-amd64] Jessie i686 and xen-hypervisor-amd64 Warning: Unknown package 'xen-hypervisor-amd64' Bug reassigned from package 'xen-hypervisor-amd64' to 'xen-hypervisor-4.4-amd64'. No longer marked as found in versions 4.4.1-3. Ignoring request to

On Sat, 2015-05-30 at 05:23 +0200, Beno?t Tonnerre wrote: > mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs xenstored > mai 29 22:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing > nothing. > mai 29 23:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing > nothing. This suggests that the xen daemons and in particular xenstored are

I'm afraid I don't know what may or may not have happened to your installation, just that this fake-start-stop-daemon thing is very likely interfering with the operation of Xen by not actually starting daemons. I suggest you try asking somewhere like the debian-users list to see if anyone there knows what this thing is or what to do about it. Ian. On Tue, 2015-06-02 at 15:22 +0200,

On Wed, 2015-09-16 at 01:52 +0200, Arne Klein wrote: > [...] > At the moment when the network in the domU completely stops working, > there is the error message > [2178752.854380] vif vif-33-0 vif33.0: Guest Rx stalled > visible in dmesg in the dom0. This will therefore be a kernel issue not a hypervisor one. It sounds like a backend one given the issue is with both new and

Hi, First of all, thanks for your help. I have made some test with this results debian testing with xen 4.4 can run if we add mmcfg=0 as boot options to kernel boot parameters !!! Remember that with xen kernel <=4.0 works perfect without to add mmcfg=0 I have tried to install citrix xenserver 5.6 and works perfect (remember that this is xen 3 branch) Also we have tried to install xenserver

Dear Debian-Bugteam Unfortunately this problem still exists. I want to use the server in production environment, but can't by reason of this error. Installed XEN-Versions: ii xen-hypervisor-4.4-amd64 4.4.1-9+deb8u5 amd64 Xen Hypervisor on AMD64 ii xen-linux-system-3.16.0-4-amd64 3.16.7-ckt25-2 amd64

Package: xen-hypervisor-4.4-amd64 Version: 4.4.0-4 Severity: normal -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash

>> 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-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