Re: [Xen-ia64-devel] FC6 Test3 Xentest result
Hi Aron and Akio, I reported a new bug about Xen0 crashing, when I try to insert xennet.ko in XenU. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208062 Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006年9月21日 22:45 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com; [EMAIL PROTECTED] Subject: [Fedora-xen] Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xentest result You, Yongkang wrote: [Wed Sep 20 2006, 01:46:22AM EDT] [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. I think this is a duplicate of bug 203032. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203032 [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I think the front-end and back-end drivers aren't communicating. I see the same problem with both network and block drivers when attempting xenguest-install. Aron -- Fedora-xen mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-xen ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Grub for ia64
Le Jeudi 07 Septembre 2006 21:07, Bjorn Helgaas a écrit : On Tuesday 05 September 2006 05:45, Tristan Gingold wrote: here is my port of grub to ia64. I hope it has all the requested features (kernel, initrd, modules, relocation and fpswa). This is a port of grub 1.94, which is not the legacy grub used by x86. The syntax is slightly different. See an attached example. Attached is grub.efi, patch and grub.cfg example as well as modifications for Xen (to support acm). Tested in many configurations (including acm). I will post the patches to grub-devel later. You might copy linux-ia64@vger.kernel.org, too. Ok. How does this grub port relate to elilo? I have copied a few low-level files from elilo. Does grub support all the features (e.g., netboot) of elilo? netboot is not supported. It should be as soon as grub supports it! Do you envision using grub only for xen? grub also works for linux. Do you want grub to replace elilo in general? This is not my concern. Distribs choose Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] sparsemem/discontig?
Le Vendredi 22 Septembre 2006 15:16, Jes Sorensen a écrit : Hi Kouya, Thank you for your suggestion - I tried making this change, but it made no difference at all. I think elilo relocates it or something like that, otherwise we would have the same problem with the Linux kernel. Yes elilo relocates Xen (if relocate option is set). But Xen does not support relocation yet. It will crash during the boot. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
Le Vendredi 22 Septembre 2006 11:39, Magnus Damm a écrit : On 9/22/06, Xu, Anthony [EMAIL PROTECTED] wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月22日 17:09 I think xencomm is the way to go. If Tristan ceases pushing it, we, VA Linux, are willing to take over it. -- I guess Tristan ceased doing that. That would be great that VA linux can do that. I will give it a try. My current knowledge about xencomm is kind of limited, so if you have any suggestions please let me know! Hi, Please do not work yet on xencomm. I am now back from holidays and I will work on xencomm now. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] sparsemem/discontig?
Le Mardi 26 Septembre 2006 10:24, Jes Sorensen a écrit : Tristan Gingold wrote: Le Vendredi 22 Septembre 2006 15:16, Jes Sorensen a écrit : Hi Kouya, Thank you for your suggestion - I tried making this change, but it made no difference at all. I think elilo relocates it or something like that, otherwise we would have the same problem with the Linux kernel. Yes elilo relocates Xen (if relocate option is set). But Xen does not support relocation yet. It will crash during the boot. Hmmm, so why did it make no difference whether I changed those addresses? This is not an early crash. Xen boots rather far before crashing. Any idea if there's some hard coded places that I need to track down? I don't know the altix at all. It seems the memory is very sparse. Have you post the boot log ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Fully virtualized doamin passed 48hr stress tests
Fred, Thanks for sharing info. I'd like to do similar stress tests on DomU. 1. Helltest: 16 hours 2. Crashme: 16 hours Could you give me a pointer to Helltest? I suppose it's not a inhouse testtool, but can't find a reference. Even XenTest page didn't give me a clue. http://wiki.xensource.com/xenwiki/XenTest/StressTests Thanks, Yoshi Oguchi --- Yang, Fred [EMAIL PROTECTED] wrote: FYI, Fully virtualized Domain, run on Xen/VTi, has successfully passed continuous 48 hours stress tests. Environment: Dual-Core Intel(r) Itanium(r) 2 processor 9000 series Tiger4 system 4 sockets with MT disabled Xen Cset# 11460 Guest OS: RHEL4U2 Xen environment: Xen0: Dual Processors DomainVTi: 2 SMP domains, each with 3 vcpus Stress Tests: 1. Helltest: 16 hours 2. Crashme: 16 hours 3. In-house compatability validation suites: 16 hours The system has passed total 48 hours stress tests -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] FC6 Test3 Xentest result
Hi, Yongkang Thank you for your report. I have the same bug. Aron reported the likely bug of xenguest-install.py. I try to debug this issue. Best Regards, Akio Takebe Hi Aron and Akio, I reported a new bug about Xen0 crashing, when I try to insert xennet.ko in XenU. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208062 Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006ト\xF3ヤツ21ネユ 22:45 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com; [EMAIL PROTECTED] Subject: [Fedora-xen] Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xentest result You, Yongkang wrote: [Wed Sep 20 2006, 01:46:22AM EDT] [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. I think this is a duplicate of bug 203032. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203032 [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I think the front-end and back-end drivers aren't communicating. I see the same problem with both network and block drivers when attempting xenguest-install. Aron -- Fedora-xen mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-xen ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Fully virtualized doamin passed 48hr stress tests
On Tue, 2006-09-26 at 20:21 +0900, [EMAIL PROTECTED] wrote: Fred, Thanks for sharing info. I'd like to do similar stress tests on DomU. 1. Helltest: 16 hours 2. Crashme: 16 hours Could you give me a pointer to Helltest? I suppose it's not a inhouse testtool, but can't find a reference. I would also appreciate a pointer to helltest. Even XenTest page didn't give me a clue. http://wiki.xensource.com/xenwiki/XenTest/StressTests Correct. I have not been able to find a pointer to helltest either. Not even google has been able to find this test, even though I have heard it mentioned from several different sources. Thanks, Yoshi Oguchi --- Yang, Fred [EMAIL PROTECTED] wrote: FYI, Fully virtualized Domain, run on Xen/VTi, has successfully passed continuous 48 hours stress tests. Environment: Dual-Core Intel(r) Itanium(r) 2 processor 9000 series Tiger4 system 4 sockets with MT disabled Xen Cset# 11460 Guest OS: RHEL4U2 Xen environment: Xen0: Dual Processors DomainVTi: 2 SMP domains, each with 3 vcpus Stress Tests: 1. Helltest: 16 hours 2. Crashme: 16 hours 3. In-house compatability validation suites: 16 hours The system has passed total 48 hours stress tests -Fred ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Grub for ia64
On Tuesday 26 September 2006 01:11, Tristan Gingold wrote: Le Jeudi 07 Septembre 2006 21:07, Bjorn Helgaas a écrit : On Tuesday 05 September 2006 05:45, Tristan Gingold wrote: Do you want grub to replace elilo in general? This is not my concern. Distribs choose Sure. But why did you decide to port grub to ia64? A preference for grub config files? A particular feature of grub that elilo lacks? Is grub's design better in some way? I'm not trying to discourage you from working on grub or elilo. I'm just trying to understand the benefits of having two projects that do basically the same thing. Bjorn ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] small speedup to boot allocator
Hi,
This is a small speedup, but I think it's a good thing to dotm.
Jes
Small speedup for the boot allocator to avoid it scanning through a
space which is known to be empty.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 7b250cf49e50 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Sun Sep 24 14:55:57 2006 -0600
+++ b/xen/common/page_alloc.c Mon Sep 25 18:47:57 2006 +0200
@@ -112,6 +117,7 @@ static void map_alloc(unsigned long firs
}
}
+static unsigned long first_pg = -1UL;
static void map_free(unsigned long first_page, unsigned long nr_pages)
{
@@ -128,6 +134,10 @@ static void map_free(unsigned long first
start_off = first_page (PAGES_PER_MAPWORD-1);
end_idx = (first_page + nr_pages) / PAGES_PER_MAPWORD;
end_off = (first_page + nr_pages) (PAGES_PER_MAPWORD-1);
+
+if (curr_idx first_pg)
+first_pg = curr_idx;
+
if ( curr_idx == end_idx )
{
@@ -217,7 +229,7 @@ unsigned long alloc_boot_pages(unsigned
{
unsigned long pg, i;
-for ( pg = 0; (pg + nr_pfns) max_page; pg += pfn_align )
+for ( pg = first_pg; (pg + nr_pfns) max_page; pg += pfn_align )
{
for ( i = 0; i nr_pfns; i++ )
if ( allocated_in_map(pg + i) )
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: xencomm porting and inline handles
Le Mardi 12 Septembre 2006 20:37, Hollis Blanchard a écrit : Hi Tristan, I've just implemented your inline handle idea. The Xen changes are committed to xenppc-unstable.hg . In Xen, architectures need to provide: - XENCOMM_INLINE_FLAG in arch-foo.h - paddr_to_maddr(). I'm open to alternative names, but a standard function seems useful outside xencomm. (I wish we had one for Linux.) - asm/guest_access.h that just #includes xen/xencomm.h Once you have IA64-specific implementations for the above, I will submit the whole thing to xen-devel. (Note that Linux doesn't actually have to use it right now; it won't break anything.) The Linux are committed to linux-ppc-2.6.hg . I think for Linux architectures just need to supply: - XENCOMM_INLINE_FLAG in arch-foo.h - xencomm_vtop() I did end up sticking with a separate xencomm_create_inline() function because inline handles aren't kernel-accessible pointers, yet normal handles are. It does also simplify the code not to have to deal with free, as you pointed out. However, notice the problem in HYPERVISOR_xen_version(). :( We still need to figure out how to share arch/powerpc/platforms/xen/hcall.c . If you have any changes you need for IA64, please send them to me as individual patches so I can incrementally merge them into linux-ppc-2.6.hg. (That will make it much easier to understand than the patches you sent out before.) There's no rush; this code is working fine for PowerPC so I won't worry about IA64 unless/until you have time for it. Hi, sorry for the late reply. I am just back from holidays. After more work, inline xencomm is not that magic: it doesn't work for modules which are loaded in virtual memory. So I have to use mini xencomm at least for modules. I have have to check performances. If mini xencomm is good compared to inline, we could drop inline. We are really converging! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts
Le Mercredi 13 Septembre 2006 18:42, Stefan Berger a écrit : [EMAIL PROTECTED] wrote on 09/13/2006 11:00:16 AM: That is where the (non-inline) ACM/multiboot functions should live; not in a header file. I could move them there but that would include the architecture-dependent #ifdef's. What about the multiboot code. Do you think PPC will be able to also use this part? Not that I would move it, it's more out of curiosity. Well, that ifdef will need changing. Why must it exist at all, is it some weirdness of Xen/x86-64? Yes, on x86-64 we need that. It would be possible to define MACROs for x86-64 and i386 so the code could look the same. It will be necessary to do either that for ia64 and ppc as well, or we just leave the #ifdef's in the ACM code. Hi, sorry for the late reply, I am just back from holidays. It seems you patch has not yet been merged. Is there any reason ? I'd like to see it in the repository, it will help me to enable ACM on ia64. Either way is fine by me. From what I could find, there's at least grub available for ia64, so chances that ia64 can also use the multiboot code are high. Yes I am porting grub to ia64. I am not sure it could use multiboot as is because multiboot is not 64 bits ready. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts
Le Mardi 26 Septembre 2006 13:56, Stefan Berger a écrit : Tristan Gingold [EMAIL PROTECTED] wrote on 09/26/2006 07:54:27 [...] Hi, sorry for the late reply, I am just back from holidays. It seems you patch has not yet been merged. Is there any reason ? I'd like to see it in the repository, it will help me to enable ACM on ia64. We wanted to wait for the 3.0.3 close and submit them soon after that. Sound reasonnable. Thanks. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] sparsemem/discontig?
Tristan Gingold wrote: Le Vendredi 22 Septembre 2006 15:16, Jes Sorensen a écrit : Hi Kouya, Thank you for your suggestion - I tried making this change, but it made no difference at all. I think elilo relocates it or something like that, otherwise we would have the same problem with the Linux kernel. Yes elilo relocates Xen (if relocate option is set). But Xen does not support relocation yet. It will crash during the boot. Hmmm, so why did it make no difference whether I changed those addresses? Any idea if there's some hard coded places that I need to track down? Thanks, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] small speedup to boot allocator
On Tue, 2006-09-26 at 17:04 +0200, Jes Sorensen wrote:
Hi,
This is a small speedup, but I think it's a good thing to dotm.
Hi Jes,
Looks good to me, but this needs to go to xen-devel since it's common
code. Thanks,
Alex
plain text document attachment (boot-alloc-speed.diff)
Small speedup for the boot allocator to avoid it scanning through a
space which is known to be empty.
diff -r 7b250cf49e50 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Sun Sep 24 14:55:57 2006 -0600
+++ b/xen/common/page_alloc.c Mon Sep 25 18:47:57 2006 +0200
@@ -112,6 +117,7 @@ static void map_alloc(unsigned long firs
}
}
+static unsigned long first_pg = -1UL;
static void map_free(unsigned long first_page, unsigned long nr_pages)
{
@@ -128,6 +134,10 @@ static void map_free(unsigned long first
start_off = first_page (PAGES_PER_MAPWORD-1);
end_idx = (first_page + nr_pages) / PAGES_PER_MAPWORD;
end_off = (first_page + nr_pages) (PAGES_PER_MAPWORD-1);
+
+if (curr_idx first_pg)
+first_pg = curr_idx;
+
if ( curr_idx == end_idx )
{
@@ -217,7 +229,7 @@ unsigned long alloc_boot_pages(unsigned
{
unsigned long pg, i;
-for ( pg = 0; (pg + nr_pfns) max_page; pg += pfn_align )
+for ( pg = first_pg; (pg + nr_pfns) max_page; pg += pfn_align )
{
for ( i = 0; i nr_pfns; i++ )
if ( allocated_in_map(pg + i) )
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]Complete fpswa handler retry mechanism
On Mon, 2006-09-25 at 22:43 +0800, Xu, Anthony wrote: Hi Alex, Thanks for your comment, The purpose of changing IA64_RETRY is to avoid conflicting with return value of handle_fpu_swa(). Attached is updated one. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
