similar to: [IA64] Weekly benchmark results [ww39]

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 18872:3acca92b9597 (ia64/xen-unstable) 753:17adc5c344fe (ia64/linux-2.6.18-xen) 131:9210bd27a551 (efi-vfirmware) b4d410a

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 17133:daf39fc8038a (ia64/xen-unstable) 442:0c1e6a1b8e90 (ia64/linux-2.6.18-xen) 70:b6ea2d6130fb (efi-vfirmware) Dom0 OS : RHEL4

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 16540:8ba08f2244b2 (ia64/xen-unstable) 337:4108b5c64f86 (ia64/linux-2.6.18-xen) 35:ebf7052731ec (efi-vfirmware) Dom0 OS : RHEL4

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. Building the xen-vnif PV-on-HVM driver failed. This issue has already fixed on staging trees by the following patches: http://xenbits.xensource.com/staging/xen-unstable.hg?rev/48c8244c47c7 http://xenbits.xensource.com/staging/linux-2.6.18-xen.hg?rev/670f8d5305d2 In LTP, test cases related

Hi, I report a benchmark result of this week on IPF using xen-ia64-unstable. I did not test a VT-i domain because compiling PV-on-HVM drivers failed. In LTP, test cases related with direct IO still failed. # dio02 dio03 dio06 dio08 dio09 dio12 dio14 dio15 dio17 dio18 dio19 # dio21 dio22 dio23 dio25 dio26 dio27 dio28 And syslog10 failed but passed manually. TEST ENVIRONMENT Machine

Hi, I report a benchmark result of this week on IPF using xen-ia64-unstable. I did not test a VT-i domain because linking PV-on-HVM drivers still failed. In LTP, test cases related with direct IO still failed. # dio02 dio03 dio06 dio08 dio09 dio12 dio14 dio15 dio17 dio18 dio19 # dio21 dio22 dio23 dio25 dio26 dio27 dio28 TEST ENVIRONMENT Machine : Tiger4 Kernel :

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2006年5月22日 17:51 >To: Keir Fraser > >>> We just need to reverse the whole change for ia64, since both >domU >>> and domVTI are insert a hole by this auto-balloon patch. Due to >>> missing balloon support on xen/ia64 as you said, both domU and >domVTI >>> failed due to this change.

Hi, This patch adds more user registers to show them to xenctx for ia64. Tested domU/domVTi on ia64. Sample is the below. # ./xenctx 1 0 iip: e000000000000810 ipsr: 00001012087a6010 b0: a000000100068a70 b6: a00000010014ff60 b7: e000000000000800 cr_ifs: 800000000000050a ar_unat:

Hi, Xiantao >+3. Get Guest Firmware named as Flash.fd, and put it under right place: >+ (1) If you have the guest firmware (binary)released by Intel >Corp for Xen, you can use it directly. >+ (2) If you want to build a guest firmware form source code. >Please download the source from >+ hg clone >http://xenbits.xensource.com/ext/efi-vfirmware.hg >+ Use the Guide of the

Hello all, I've installed AAH 1.1 on my VIA C3 powered mini PC. I've made the necessary changes to the * makefile, so the compilation went well. The first thing I did was configuring two extensions from AMP, namely 200 and 201. Then I installed X-lite on two PC's and configured them with one of the extensions: System settings - SIP proxy - Default: Username: 200 Authorisation user:

Hi all, Currently we have severe problem and are struggling to investigate it. The problem is data broken. Reproduce pocess is following, 0. test FTP function between guest domain and FTP client(other PC). 1. put data from FTP client to guest domain. 2. get data from guest domain to FTP client. 3. compare put data and get data on FTP client. 4. repeat process from step1 to step3.

I am updating this patch to use the tools/ioemu-dir symlink as qemu source directory in case CONFIG_QEMU != ioemu. Before we were trying to figure out where is the actual qemu source dir again. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- diff -r f5e72cbfbb17 stubdom/Makefile --- a/stubdom/Makefile Wed Sep 10 11:26:16 2008 +0100 +++ b/stubdom/Makefile Thu Sep

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

Hi, until recently, the hvm guest firmware for xen-ia64 was a private binary file owned and delivered by Intel. I have written an open-source implementation based on tianocore.org. The ia64 firmware is roughly speaking EFI. I have also ported tianocore to Qemu/x86. It shouldn''t be hard to port it to x86. Because the sources are big (at least 40MB) and the buildery is not easy (build

Hi Bastian, I had a couple of build failures trying to build the current pkg-xen SVN tree. The following made it work for me... Cheers, Ian. commit e9a08d8d5afa92da73ab09b3ed53dc9f1f084381 Author: Ian Campbell <ijc at hellion.org.uk> Date: Thu Aug 15 17:14:56 2013 +0100 * debian/patches/series: Add new patch * debian/patches/qemu-without-blktap1.patch: Backport upstream patch

Hey everyone, I hope you guys can help me explaining a pretty strange result that came up when benchmarking a native Red Hat installation against a Xen DomU (installed in a file container). I used lmbench3 on a dualcore AMD-machine. To make the results comparable, I "unplugged" all CPU cores but one in the native installation (setting the "online"-entry to 0). The DomU had

Hey everyone, I hope you guys can help me explaining a pretty strange result that came up when benchmarking a native Red Hat installation against a Xen DomU (installed in a file container). I used lmbench3 on a dualcore AMD-machine. To make the results comparable, I "unplugged" all CPU cores but one in the native installation (setting the "online"-entry to 0). The DomU had

Package: xen-utils-3.2-1 Severity: grave Hi, maintainer! This message about the error concerns a few packages at once. I've tested all the packages (for Lenny) on my Debian mirror. All scripts of packages (marked as executable) were tested. In some packages I've discovered scripts with errors which may be used by a user for damaging important system files or user's files. For

stubdom: fix build dependency newlib now depends on mini-os header links diff -r 4c2d9a4d11f2 stubdom/Makefile --- a/stubdom/Makefile Fri Jul 18 13:58:29 2008 +0100 +++ b/stubdom/Makefile Fri Jul 18 14:19:52 2008 +0100 @@ -86,7 +86,7 @@ NEWLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libc.a .PHONY: cross-newlib cross-newlib: $(NEWLIB_STAMPFILE) -$(NEWLIB_STAMPFILE):