[Xen-ia64-devel] Weekly benchmark results [ww04]

2007-01-26 Thread KUWAMURA Shin'ya
Hi,

I report a benchmark result of this week.

In LTP, pselect01 and syslog05 failed.  Both cases passed when
testing manually.


TEST ENVIRONMENT
Machine  : Tiger4
Kernel   : 2.6.16.33-xen
Changeset: 13475:b4df7de0cbf7 (xen-ia64-unstable)
Dom0 OS  : RHEL4 U2 (2P)
DomU OS  : RHEL4 U2 (8P)
#DomU: 1
Scheduler: credit
Device   : tap (tap:aio)

TEST RESULT
unixbench4.1.0: Pass
bonnie++-1.03 : Pass
ltp-full-20061121 : 3/831 FAIL (see attachment)
iozone3_191   : Pass
lmbench-3.0-a5: Pass

Best regards,
KUWAMURA and Fujitsu members
Test Start Time: Thu Jan 25 19:45:11 2007
-
Testcase   Result Exit Value
   -- --
abort01PASS   0
accept01   PASS   0
access01   PASS   0
access02   PASS   0
access03   PASS   0
access04   PASS   0
access05   PASS   0
acct01 PASS   0
acct02 PASS   0
adjtimex01 PASS   0
adjtimex02 PASS   0
alarm01PASS   0
alarm02PASS   0
alarm03PASS   0
alarm04PASS   0
alarm05PASS   0
alarm06PASS   0
alarm07PASS   0
asyncio02  PASS   0
bind01 PASS   0
bind02 PASS   0
brk01  PASS   0
capget01   PASS   0
capget02   PASS   0
capset01   PASS   0
capset02   PASS   0
chdir01PASS   0
chdir01A   PASS   0
chdir02PASS   0
chdir03PASS   0
chdir04PASS   0
chmod01PASS   0
chmod01A   PASS   0
chmod02PASS   0
chmod03PASS   0
chmod04PASS   0
chmod05PASS   0
chmod06PASS   0
chmod07PASS   0
chown01PASS   0
chown02PASS   0
chown03PASS   0
chown04PASS   0
chown05PASS   0
chroot01   PASS   0
chroot02   PASS   0
chroot03   PASS   0
chroot04   PASS   0
clone01PASS   0
clone02PASS   0
clone03PASS   0
clone04PASS   0
clone05PASS   0
clone06PASS   0
clone07PASS   0
close01PASS   0
close02PASS   0
close08PASS   0
confstr01  PASS   0
connect01  PASS   0
creat01PASS   0
creat03PASS   0
creat04PASS   0
creat05PASS   0
creat06PASS   0
creat07PASS   0
creat08PASS   0
creat09PASS   0
dup01  PASS   0
dup02  PASS   0
dup03  PASS   0
dup04  PASS   0
dup05  PASS   0
dup06  PASS   0
dup07  PASS   0
dup201 PASS   0
dup202 PASS   0
dup203 PASS   0
dup204 PASS   0
dup205 PASS   0
execl01PASS   0
execle01   PASS   0
execlp01   PASS   0
execv01PASS   0
execve01   PASS   0
execve02   PASS   0
execve03 

[Xen-ia64-devel] [PATCH] NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is not registered.

2007-01-26 Thread Kouya SHIMURA
Hi

NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is used but not registered.
I've never experienced but system will panic in the very long run. 
I wonder why Isaku missed it.

Thanks,
Kouya

Signed-off-by: Kouya Shimura [EMAIL PROTECTED]

diff -r b4df7de0cbf7 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c  Wed Jan 24 12:28:05 2007 -0700
+++ b/xen/arch/ia64/xen/xensetup.c  Fri Jan 26 18:57:54 2007 +0900
@@ -26,6 +26,7 @@
 #include asm/vmx.h
 #include linux/efi.h
 #include asm/iosapic.h
+#include xen/softirq.h
 
 unsigned long xenheap_phys_end, total_pages;
 
@@ -436,6 +437,10 @@ void start_kernel(void)
 init_xen_time(); /* initialise the time */
 timer_init();
 
+#ifdef CONFIG_XEN_IA64_TLBFLUSH_CLOCK
+open_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ, new_tlbflush_clock_period);
+#endif
+
 #ifdef CONFIG_SMP
 if ( opt_nosmp )
 {
diff -r b4df7de0cbf7 xen/include/asm-ia64/flushtlb.h
--- a/xen/include/asm-ia64/flushtlb.h   Wed Jan 24 12:28:05 2007 -0700
+++ b/xen/include/asm-ia64/flushtlb.h   Fri Jan 26 18:57:54 2007 +0900
@@ -32,6 +32,7 @@ extern volatile u32 tlbflush_clock;
 #define tlbflush_current_time() tlbflush_clock
 
 u32 tlbflush_clock_inc_and_return(void);
+void new_tlbflush_clock_period(void);
 
 static inline void
 tlbflush_update_time(volatile u32* time, u32 timestamp)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Patch][RFC] fix PAL_HALT ( is Re: [Xen-ia64-devel] [RFC] dumpcore is failed for PAL_HALT)

2007-01-26 Thread Akio Takebe
Hi, Anthony

Hi, Anthony

In VTI side, ACPI is emulated by ACPI module of Qemu.
I think it supports S5.
Good news. But I look like Qemu don't trap acpi_power_off called by linux on
 VTI.
I'll investigate it.
I'm sorry, the GFW was very old.
If I update the latest GFW, I can shutdown domVTi with my patch.
As you said, Linux on domVTi call acpi_power_off(),
then Qemu-dm emulate ACPI S5 state.

Best Regards,

Akio Takebe


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


Re: [Xen-ia64-devel] Mini-OS on ia64

2007-01-26 Thread Dietmar Hahn
Hi Alex,

it took a long time, but now it's going on. I got managed the re-architecture 
of the x86 part of mini-os.
Please can you update the extras/mini-os directory in the ia64-xen tree from 
the x86-xen tree! Then I'll be able to send a first patch with the ia64 
extensions for mini-os.
Thanks.

Dietmar.

Am Montag, 24. Juli 2006 16:31 schrieb Alex Williamson:
 On Mon, 2006-07-24 at 15:12 +0200, Dietmar Hahn wrote:
   As far as I know nobody is working on it.
 
  OK, then I will start.

Thanks Dietmar.  I think this is something we need to watch closely
 so that ia64 can be ready should mini-os start being used for fully
 virtualized domains.

  At the moment I have running a rudimentary trap handler for the
  physically addresses (start_info, bootinfo and console page) and the
  event handler for timer and console events.
  Are there any guidelines to get in the sources?

I imagine you'll have to do some re-architecture of the code to allow
 ia64 to fit cleanly into the existing code.  The might mean making
 architecture specific sub-directories under extras/mini-os and moving
 the existing architecture specific files under them.  That should
 probably be coordinated on xen-devel, but please keep xen-ia64-devel in
 the loop.  When you're ready to add the ia64 code, submit that to the
 xen-ia64-devel list.  Thanks,

   Alex

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] New domain builder in xen-unstable

2007-01-26 Thread Keir Fraser
Hi,

This is a heads up, mainly to the PowerPC and IA64 folks, that Gerd's new
domain builder (including new Elf parser) is now checked into xen-unstable.
This has disabled the old builder and elf-parsing code which will shortly be
removed entirely.

So far the new libelf has only been run-tested on x86, so...

For IA64: most of the code is in place, but the new code needs some
run-testing and possibly some small fixups to get it working.

For PPC: looks like you have your own domain builder, which you may or may
not decide to merge with the main code (it would be nice to!). Either way,
you *do* use the common elf parser, and so your domain builder code needs to
be changed to talk to Gerd's libelf.

 -- Keir



___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: New domain builder in xen-unstable

2007-01-26 Thread Keir Fraser
On 26/1/07 5:04 pm, Hollis Blanchard [EMAIL PROTECTED] wrote:

 Not sure what you mean by our own domain builder; we've been
 implementing xc_linux_build() for quite a while now (and thus integrated
 with xend).
 
 Sorry, I misunderstood. I was seeing all the libelf churn, and I missed
 the fact that xc_linux_build() is going away entirely (?).
 
 I'm still not sure what you mean by our own domain builder -- there is
 simply no way we're going to add more ifdefs to
 tools/libxc/xc_linux_build.c (or equivalent)...

xc_linux_build() is still provided in the 'new world' and is still used by
xend. For ia64/x86 it is now a thin wrapper around Gerd's new
domain-building infrastructure. For ppc you can continue to have your very
own version under libxc/powerpc if you want to, and not use Gerd's new
domain-building infrastructure. But the elf code that you rely on is going
away, so you need to move to using libelf, which I'm sure Gerd can give you
some pointers about.

 -- Keir



___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


Re: [Xen-ia64-devel][Patch]move vmx_vcpu_thash() to assemble

2007-01-26 Thread Alex Williamson
On Thu, 2007-01-25 at 12:55 +0800, Zhang, Xing Z wrote:
 move vmx_vcpu_thash() to assemble.
 
 It’s good to performance.

   Applied.  Thanks,

Alex


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


Re: [Xen-ia64-devel][PATCH] Remove dead code

2007-01-26 Thread Alex Williamson
On Fri, 2007-01-26 at 15:13 +0800, Xu, Anthony wrote:
 Remove dead code,

   Applied.  Thanks,

Alex


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


Re: [Xen-ia64-devel] [PATCH] NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is not registered.

2007-01-26 Thread Alex Williamson
On Fri, 2007-01-26 at 20:05 +0900, Kouya SHIMURA wrote:
 Hi
 
 NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is used but not registered.
 I've never experienced but system will panic in the very long run. 

   Applied.  Thanks,

Alex


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel