[Xen-ia64-devel] [FYI] Recipe of build and boot of Xen/IA64
Hi,
We can boot RHEL4 domU without initrd.
I have written the recipe.
(Thank you for many advice, everyone :-))
My enviroment is;
Machine : Tiger4
Dom0 OS : RHEL4 U2
DomU OS : RHEL4 U2
changeset: 8241:0255f48b757f
Build xen
1. Download source
# hg clone http://xenbits.xensource.com/ext/xen-ia64-unstable.hg
2. # make world -j4
3. make menuconfig in Dom0
# cd linux-2.6.12-xen0
# make menuconfig
CONFIG_IA64_DIG=y
# cd ..
4. make menuconfig in DomU
# cd linux-2.6.12-xenU
# make menuconfig
CONFIG_IA64_DIG=y
# CONFIG_EFI_RTC is not set
# cd ..
5. # make kernels -j4
6. # make uninstall
7. # make install-tools
8. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/xen/
# cp linux-2.6.12-xen0/vmlinux.gz /boot/efi/efi/xen/vmlinuz-2.6.12-xen0
# cp linux-2.6.12-xenU/vmlinux.gz /boot/vmlinux-2.6.12-xenU
9. make initrd for Dom0
# cd linux-2.6.12-xen0/
# make modules_install
# mkinitrd -f /boot/efi/efi/xen/initrd-2.6.12-xen0.img 2.6.12.6-xen0
--builtin mptbase --builtin mptscsih
# cd ..
-
Make OSimg for DomU
1. make file
# dd if=/dev/zero of=/root/rhel4.img bs=1M count=4096
# mke2fs -F -j /root/rhel4.img
# mount -o loop /root/rhel4.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/hda1 /ext3defaults1 1
none/dev/pts devpts gid=5,mode=620 0 0
none/dev/shm tmpfs defaults0 0
none/procprocdefaults0 0
none/sys sysfs defaults0 0
3. modify inittab (runlevel and tty)
# vi /mnt/etc/inittab
id:3:initdefault:
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty0
#1:2345:respawn:/sbin/mingetty tty1
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6
4. add tty0 into /etc/securetty
# vi /mnt/etc/securetty (add tty0)
5. umount
# umount /mnt
-
Boot Xen
1. replace elilo
download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
2. modify elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.12-xen0
label=xen
vmm=xen-.gz
initrd=initrd-2.6.12-xen0.img
read-only
append=com2=115200,8n1 console=com2 sched=bvt tbuf_size=128 --
nomca nosmp console=tty0 console=ttyS1,115200,8n1 rhgb root=/dev/sda2
image=vmlinuz-2.6.9-22.EL
label=linux
initrd=initrd-2.6.9-22.EL.img
read-only
append=rhgb root=/dev/sda2
3. make config of DomU
# vi /etc/xen/rhel4
kernel = /boot/vmlinux-2.6.12-xenU
memory = 384
name = rhel4
nics=0
disk = [ 'file:/root/rhel4.img,hda1,w' ]
root = /dev/hda1 ro
extra = 3
4. After boot xen and dom0, start xend
# /etc/init.d/xend start
( In the debugging case, # XEND_DEBUG=1 xend trace_start )
5. start domU
# xm create -c rhel4
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch]initrd support for DomainU
Hi,
This is a patch to boot domU with initrd.
I confirmed domU could boot with initrd.
It is necessary for runninig xm-test that domU support initrd.
Please comment.
Best Regards,
Akio Takebe
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r 7ef565a7cc86 tools/libxc/xc_linux_build.c
--- a/tools/libxc/xc_linux_build.c Thu Dec 15 23:17:06 2005
+++ b/tools/libxc/xc_linux_build.c Mon Dec 19 19:28:12 2005
@@ -296,9 +296,13 @@
unsigned long *page_array = NULL;
struct load_funcs load_funcs;
struct domain_setup_info dsi;
+unsigned long vinitrd_start;
+unsigned long vinitrd_end;
+unsigned long v_end;
unsigned long start_page, pgnr;
start_info_t *start_info;
int rc;
+unsigned long i;
rc = probeimageformat(image, image_size, load_funcs);
if ( rc != 0 )
@@ -310,11 +314,13 @@
if ( rc != 0 )
goto error_out;
-dsi.v_start = round_pgdown(dsi.v_start);
-dsi.v_end = round_pgup(dsi.v_end);
+dsi.v_start = round_pgdown(dsi.v_start);
+vinitrd_start= round_pgup(dsi.v_end);
+vinitrd_end = vinitrd_start + initrd_len;
+v_end= round_pgup(vinitrd_end);
start_page = dsi.v_start PAGE_SHIFT;
-pgnr = (dsi.v_end - dsi.v_start) PAGE_SHIFT;
+pgnr = (v_end - dsi.v_start) PAGE_SHIFT;
if ( (page_array = malloc(pgnr * sizeof(unsigned long))) == NULL )
{
PERROR(Could not allocate memory);
@@ -326,9 +332,38 @@
PERROR(Could not get the page frame list);
goto error_out;
}
+
+#define _p(a) ((void *) (a))
+
+printf(VIRTUAL MEMORY ARRANGEMENT:\n
+Loaded kernel: %p-%p\n
+Init. ramdisk: %p-%p\n
+TOTAL: %p-%p\n,
+ _p(dsi.v_kernstart), _p(dsi.v_kernend),
+ _p(vinitrd_start), _p(vinitrd_end),
+ _p(dsi.v_start), _p(v_end));
+printf( ENTRY ADDRESS: %p\n, _p(dsi.v_kernentry));
(load_funcs.loadimage)(image, image_size, xc_handle, dom, page_array,
dsi);
+
+/* Load the initial ramdisk image. */
+if ( initrd_len != 0 )
+{
+for ( i = (vinitrd_start - dsi.v_start);
+ i (vinitrd_end - dsi.v_start); i += PAGE_SIZE )
+{
+char page[PAGE_SIZE];
+if ( gzread(initrd_gfd, page, PAGE_SIZE) == -1 )
+{
+PERROR(Error reading initrd image, could not);
+goto error_out;
+}
+xc_copy_to_domain_page(xc_handle, dom,
+ page_array[iPAGE_SHIFT], page);
+}
+}
+
*pvke = dsi.v_kernentry;
@@ -358,6 +393,11 @@
start_info-store_evtchn = store_evtchn;
start_info-console_mfn = nr_pages - 1;
start_info-console_evtchn = console_evtchn;
+if ( initrd_len != 0 )
+{
+ctxt-initrd.start= vinitrd_start;
+ctxt-initrd.size = initrd_len;
+}
munmap(start_info, PAGE_SIZE);
free(page_array);
diff -r 7ef565a7cc86 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch/ia64/xen/dom_fw.cThu Dec 15 23:17:06 2005
+++ b/xen/arch/ia64/xen/dom_fw.cMon Dec 19 19:28:12 2005
@@ -842,9 +842,15 @@
bp-console_info.orig_x = 0;
bp-console_info.orig_y = 24;
bp-fpswa = 0;
-bp-initrd_start = (dom0_start+dom0_size) -
-(PAGE_ALIGN(ia64_boot_param-initrd_size) + 4*1024*1024);
-bp-initrd_size = ia64_boot_param-initrd_size;
+if (d == dom0){
+bp-initrd_start = (dom0_start+dom0_size) -
+(PAGE_ALIGN(ia64_boot_param-initrd_size) +
4*1024*1024);
+bp-initrd_size = ia64_boot_param-initrd_size;
+}else{
+bp-initrd_start = d-arch.initrd_start;
+bp-initrd_size = d-arch.initrd_len;
+
+ }
printf( initrd start %0xlx, bp-initrd_start);
printf( initrd size %0xlx, bp-initrd_size);
diff -r 7ef565a7cc86 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cThu Dec 15 23:17:06 2005
+++ b/xen/arch/ia64/xen/domain.cMon Dec 19 19:28:12 2005
@@ -297,6 +297,8 @@
*regs = c-regs;
d-arch.sys_pgnr = c-sys_pgnr;
+d-arch.initrd_start = c-initrd.start;
+d-arch.initrd_len = c-initrd.size;
new_thread(v, regs-cr_iip, 0, 0);
v-vcpu_info-arch.evtchn_vector = c-vcpu.evtchn_vector;
diff -r 7ef565a7cc86 xen/include/asm-ia64/domain.h
--- a/xen/include/asm-ia64/domain.h Thu Dec 15 23:17:06 2005
+++ b/xen/include/asm-ia64/domain.h Mon Dec 19 19:28:12 2005
@@ -38,6 +38,8 @@
u64 image_len;
u64 entry;
#endif
+unsigned long initrd_start;
+unsigned long initrd_len;
};
#define xen_vastart arch.xen_vastart
#define xen_vaend arch.xen_vaend
diff -r 7ef565a7cc86 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hThu Dec 15 23:17:06 2005
+++ b/xen/include/public/arch-ia64.hMon Dec 19
Re: [Xen-ia64-devel] Xen/IA64 on RHEL
I'm sorry. I mistake the English word. Please __SEE__ the following thread when you build and install. [Xen-ia64-devel] [FYI] Recipe of build and boot of Xen/IA64 http://lists.xensource.com/archives/html/xen-ia64-devel/2005-12/msg00090 .html I'm not good at English. : Best Regards, Akio Takebe Hi, You should use Mercurial-0.6c and do the below. :) # hg clone http://xenbits.xensource.com/ext/xen-ia64-unstable.hg Please show the following thread when you build and install. [Xen-ia64-devel] [FYI] Recipe of build and boot of Xen/IA64 http://lists.xensource.com/archives/html/xen-ia64-devel/2005-12/msg00090 .html Best Regards, Akio Takebe Hi, I like to know the location from where I can download and install Xen/IA64 soruce on RHEL 2.1 or RHEL 4.0 m/c. Kindly provide the information. Jhelum ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel html-part included links--- http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/ signature-home.htm/[EMAIL PROTECTED] ___ 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] name conflict(map_domain_page)
Hi, Yamahata and all I think good sugesstion. Should map_new_domain0_page() also be renamed? How are alloc_? (I'm also bad at naming...) Best Regards, Akio Takebe I found that name map_domain_page is defined in two places. one is defined in xen/include/xen/domain_page.h. another is defined in xen/arch/ia64/xen/domain.c. Luckily this name conflict doesn't cause problem for now. However this is a bad practice, so it should be fixed. The one in xen/include/xen/domain_page.h is used in xen commonly, so the one defined in xen/arch/ia64/xen/domain.c should be renamed. I propose following name changes. (Only the name map_domain_page() is conflicted, For consistency others should also be changed.) map_new_domain_page() - assign_new_domain_page() map_domain_page() - assign_domain_page() map_domain_io_page() - assign_domain_io_page() I am bad at naming, I hope someone propose better names. Any suggenstions? Once new names are decided, I will make a patch. Or if no objections, I will go with above name. -- yamahata ___ 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
[Xen-ia64-devel] [Patch] different type of argument in vcpu_set_gr()
Hi, I tested Page reference counter. I had a problem which DomU have a General Exception at DomU's booting time. I fixed Reserved Register/Field fault in printf(). This bug is probably occurred by wrong type arguments in sal_emulate(). This bug was very difficult. I checked compile warnnigs, and I could fix this problem. So I will fix compile warnnings one step at a time. ;-) Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe vcpu_set_gr_different_type.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] wrong type cast in ia64_hypercall
Hi,
This is wrong type cast.
This patch fix warnning of incompatible pointer type.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r 982b9678af2c xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Fri Feb 10 23:16:33 2006
+++ b/xen/arch/ia64/xen/hypercall.c Wed Feb 15 10:15:40 2006
@@ -63,7 +63,7 @@
int
ia64_hypercall (struct pt_regs *regs)
{
- struct vcpu *v = (struct domain *) current;
+ struct vcpu *v = current;
struct sal_ret_values x;
unsigned long *tv, *tc;
int pi;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
Hi, Dan and Alex I think this issue is only on ia64. I seem that [EMAIL PROTECTED]/char/mem.c is used on ia64, but [EMAIL PROTECTED]/xen/char/mem.c is used on x86. So I think pfn or kva aren't set correctly. We tried to boot domU with revesing cset xen-ia64-ustable.8790 and it was good work. I'm still debugging it. :- Best Regards, Akio Takebe Confirmed cset xen-unstable 8783 fails while 8782 succeeds. Perhaps there's something different about mmap on RH vs Suse and Debian? Perhaps only on ia64? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi, Tristan Thank you. I'll try to reinstall soon. If reinstall is a root cause, it is mean some tools are not overwrite when we run make install-tools. Best Regards, Akio Takebe Le Mercredi 01 Mars 2006 02:30, Xu, Anthony a ィヲcrit : It is likely some subtle difference (or bug), perhaps in mmap? Hi all, yesterday I got the same bug as Akio. Today it is working again. I have just reinstalled tools+xen+kernel. Akio, could you try to reinstall xen+tools+kernel using a clean repository ? (make clean may be not enough). It seems *really* strange that only a few of us got the bug because it seems to be related only to Xen+Xenstore+Linux. Therefore it should not depend on the distribution. 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] Help? Red Hat fails, Suse/Debian both work fine
Hi, Kevin
Thank you for your advice.
I tried to compile define ARCH_HAS_DEV_MEM.
but nothing changed.
Best Regards,
Akio Takebe
Hi, Akio,
Currently linux-2.6-xen-sparse/driver/xen/char/ is not included
in compilation for xen/ia64, so you're still using linux-style kmem
path.
Try to compile that directory into your xenlinux image, and
define ARCH_HAS_DEV_MEM, and then see anything changed
for you.
However the interesting thing is, following Cset is only for
changing way to map dom0's store page, instead of domU. DomU's
store page is still mapped by foreign page map. If above hint is real
cause, xend start can fail earlier due to incorrect mapping when
introducing dom0 into xenstore. However you all observe the bug
bothering only when domU is booting...
Thanks,
Kevin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Akio Takebe
Sent: 2006年3月2日 8:44
To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins); xen-devel
Cc: yo.fujita; Akio Takebe; xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi, Anthony
Thank you for your advice.
I checked retun value of mmap(), and it is not NULL.
I'll check vcpu_translate().
Best Regards,
Akio Takebe
It is likely some subtle difference (or bug), perhaps in mmap?
As I know, in Redhat, mmap can return NULL address, but seems xen
can't handle this situation, see below code segment:
In function vcpu_translate() of vcpu.c file
else if (!region warn_region0_address) {
REGS *regs = vcpu_regs(vcpu);
unsigned long viip = PSCB(vcpu,iip);
unsigned long vipsr = PSCB(vcpu,ipsr);
unsigned long iip = regs-cr_iip;
unsigned long ipsr = regs-cr_ipsr;
printk(vcpu_translate: bad address %p, viip=%p, vipsr=%p, iip=%p,
ipsr=%p continuing\n, address, viip, vipsr, iip, ipsr);
}
warn_region0_address is turned off by default,
so maybe we can turn on warn_region0_address to see whether this is the
root cause.
Thanks,
-Anthony
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Magenheimer, Dan
(HP Labs Fort Collins)
Sent: 2006ト・ヤツ1ネユ 5:45
To: xen-devel
Cc: yo.fujita; Akio Takebe; xen-ia64-devel@lists.xensource.com
Subject: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi all --
We are seeing a strange problem where a recent cset causes
Red Hat to fail domU boot on ia64 complaining of a hotplug
problem but doesn't cause any problem for Suse or Debian.
It is likely some subtle difference (or bug), perhaps in mmap?
Suggestions/advice from anyone more familiar with distro
differences (on ia64) would be appreciated.
Changeset is xen-unstable 8783 (Use /dev/kmem to map dom0
xenstore page instead of abusing the foreign mapping interface.,
Feb 8, committed by Christian). Backing out this changeset
or using the small patch below causes the problem to go away,
so we have a workaround, but a root cause would be nice
to know and fix.
Full thread of discussion can be found here:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-02/msg00104
.html
Thanks,
Dan
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 28, 2006 2:47 AM
To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita;
xen-ia64-devel@lists.xensource.com
Cc: Akio Takebe
Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
Hi, Dan
I'm still debuging, but it is very difficult...
Much advice is welcome. :-)
Now I can boot domU by using the following patch.
diff -r 6c43118bdba8 tools/xenstore/xenstored_domain.c
--- a/tools/xenstore/xenstored_domain.c Fri Feb 24 15:41:08 2006 -0700
+++ b/tools/xenstore/xenstored_domain.c Tue Feb 28 18:20:16 2006
+0900
@@ -467,6 +467,7 @@ static int dom0_init(void)
int rc, fd;
evtchn_port_t port;
unsigned long kva;
+ unsigned long mfn;
char str[20];
struct domain *dom0;
@@ -500,9 +501,16 @@ static int dom0_init(void)
if (fd == -1)
return -1;
- dom0-interface = mmap(NULL, getpagesize(),
PROT_READ|PROT_WRITE,
- MAP_SHARED, fd, kva);
- if (dom0-interface == MAP_FAILED)
+ mfn=((0x0fff kva) 14);
+/*
+dom0-interface = mmap(NULL, getpagesize(),
PROT_READ|PROT_WRITE,
+ MAP_SHARED, fd, kva);
+*/
+ dom0-interface = xc_map_foreign_range(
+ *xc_handle, 0,
+ getpagesize(), PROT_READ|PROT_WRITE, mfn);
+ if (!dom0-interface)
+// if (dom0-interface == MAP_FAILED)
goto outfd;
close(fd);
Best Regards,
Akio Takebe
Hi Akio --
Any more progress on this issue? If you are stuck,
maybe we should post the problem to xen-devel to
see if we can get help from a Red Hat person (since
the problem doesn't occur on Suse or Debian
RE: [Xen-ia64-devel] [PATCH] [RESEND] domU destroy page ref counter
Hi, Kevin and Anthony Thank you for your comments. For refcount: - You may want to change PGT_va_shift to 32 like x86-64 since unsigned long type_info is 64bit width on IA64. Or you either can define it as u32 type_info to save space since higher half is not used by your patch. I thought I wanted to be the same struct page as x86. So I think changing PGT_va_shift to 32 is better since u32 type_info cannot be saved space. (because inuse and free are union.) For domain destroy: - Also need to free metaphysical rid, which is null by far. Current metaphysical rid allocation policy is monotonic-incremental-allocation-no- free style. Though it's unlikely to see exhaust of this area (one block reserved by far), it's better to change it to a cleaner, more efficient policy. You may at least put a call there if delayed with lower priority. As you said, VHPT and TLB flush may be not necessary, but we use these flush for safe destroy. So Kan made a feature of allocating rid, then we may be able to remove these flush. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [RFC][Patch] complie error at kmap_flush_unused in include/linux/highmem.h
Hi,
blkback.c has the following compile error.
I don't know why this error is occurred.
This error is sometimes occurred when I run make world.
This error caused by redifine kmap_flush_unused
in include/linux/highmem.h and include/asm-ia64/hypervisor.h.
I tried to remove difine kmap_flush_unused
in include/asm-ia64/hypervisor.h, then it is good.
Am I correct?
The bellow is the compile error.
===
LOGO drivers/video/logo/logo_mac_clut224.c
LOGO drivers/video/logo/logo_parisc_clut224.c
LOGO drivers/video/logo/logo_sgi_clut224.c
LOGO drivers/video/logo/logo_sun_clut224.c
LOGO drivers/video/logo/logo_superh_clut224.c
CC drivers/video/fbmem.o
CC drivers/video/fbmon.o
CC drivers/video/fbcmap.o
CC drivers/video/fbsysfs.o
CC drivers/video/modedb.o
CC drivers/video/fbcvt.o
LD drivers/video/fb.o
CC drivers/video/cfbfillrect.o
CC drivers/video/cfbcopyarea.o
CC drivers/video/cfbimgblt.o
LD drivers/video/built-in.o
CC drivers/xen/util.o
CC drivers/xen/blkback/blkback.o
In file included from include/linux/pagemap.h:10,
from include/linux/blkdev.h:10,
from drivers/xen/blkback/common.h:10,
from drivers/xen/blkback/blkback.c:19:
include/linux/highmem.h:24:42: macro kmap_flush_unused passed 1
arguments, but takes just 0
In file included from include/linux/pagemap.h:10,
from include/linux/blkdev.h:10,
from drivers/xen/blkback/common.h:10,
from drivers/xen/blkback/blkback.c:19:
include/linux/highmem.h:24: error: syntax error before '{' token
drivers/xen/blkback/blkback.c: In function `blkif_init':
drivers/xen/blkback/blkback.c:528: warning: implicit declaration of
function `xen_init'
drivers/xen/blkback/blkback.c:550: warning: ISO C90 forbids mixed
declarations and code
drivers/xen/blkback/blkback.c:525: warning: unused variable `page'
make[7]: *** [drivers/xen/blkback/blkback.o] Error 1
make[6]: *** [drivers/xen/blkback] Error 2
make[5]: *** [drivers/xen] Error 2
make[4]: *** [drivers] Error 2
make[4]: Leaving directory `/home/takebe/xen-ia64-unstable.hg.060313/
linux-2.6.16-rc5-xen0'
make[3]: *** [build] Error 2
make[3]: Leaving directory `/home/takebe/xen-ia64-unstable.hg.060313'
make[2]: *** [linux-2.6-xen0-install] Error 2
make[2]: Leaving directory `/home/takebe/xen-ia64-unstable.hg.060313'
make[1]: *** [install-kernels] Error 1
make[1]: Leaving directory `/home/takebe/xen-ia64-unstable.hg.060313'
make: *** [world] Error 2
The bellow is my patch.
=
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r 551f7935f79a linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hFri Mar
10 08:25:54 2006 -0700
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hMon Mar
13 18:10:16 2006 +0900
@@ -62,7 +62,7 @@ void force_evtchn_callback(void);
#define INVALID_P2M_ENTRY (~0UL)
#define __pte_ma(_x) ((pte_t) {(_x)})
#define phys_to_machine_mapping_valid(_x) (1)
-#definekmap_flush_unused() do {} while (0)
+//#define kmap_flush_unused() do {} while (0)
#define set_phys_to_machine(_x,_y) do {} while (0)
#define xen_machphys_update(_x,_y) do {} while (0)
#define pfn_pte_ma(_x,_y) __pte_ma(0)
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] remove warning of xen_init()
Hi, The below is cleanup warning patch. Signed-off-by: Akio Takebe [EMAIL PROTECTED] --- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hTue Mar 14 14:38:22 2006 -0700 +++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hWed Mar 15 09:30:28 2006 +0900 @@ -44,6 +44,8 @@ extern start_info_t *xen_start_info; void force_evtchn_callback(void); +int xen_init(void); + /* Turn jiffies into Xen system time. XXX Implement me. */ #define jiffies_to_st(j) 0 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] fix AFLAGS in Rules.mk
Hi, When we compile xen, we use local include files. (e.g. /usr/include) So this patch fix the issue. Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] diff -r 142a3eec56bd xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mkFri Mar 10 10:00:31 2006 -0700 +++ b/xen/arch/ia64/Rules.mkTue Mar 14 19:57:46 2006 +0900 @@ -5,7 +5,7 @@ ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) CROSS_COMPILE ?= /usr/local/sp_env/v2.2.5/i686/bin/ia64-unknown-linux- endif -AFLAGS += -D__ASSEMBLY__ +AFLAGS += -D__ASSEMBLY__ $(CPPFLAGS) -nostdinc -fno-builtin -fno-common -fno-strict-aliasing CPPFLAGS += -I$(BASEDIR)/include -I$(BASEDIR)/include/asm-ia64\ -I$(BASEDIR)/include/asm-ia64/linux \ -I$(BASEDIR)/include/asm-ia64/linux-xen\ 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] [Patch] fix AFLAGS in Rules.mk
Hi, Tristan Thank you. You are right. These are my mistake. I fix my patch. diff -r 911c04274f14 xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mkTue Mar 14 14:38:22 2006 -0700 +++ b/xen/arch/ia64/Rules.mkThu Mar 16 09:07:33 2006 +0900 @@ -5,7 +5,7 @@ ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) CROSS_COMPILE ?= /usr/local/sp_env/v2.2.5/i686/bin/ia64-unknown-linux- endif -AFLAGS += -D__ASSEMBLY__ +AFLAGS += -D__ASSEMBLY__ -nostdinc $(CPPFLAGS) CPPFLAGS += -I$(BASEDIR)/include -I$(BASEDIR)/include/asm-ia64\ -I$(BASEDIR)/include/asm-ia64/linux \ -I$(BASEDIR)/include/asm-ia64/linux-xen\ Best Regards, Akio Takebe Le Mercredi 15 Mars 2006 05:06, Akio Takebe a 馗rit : Hi, When we compile xen, we use local include files. (e.g. /usr/include) So this patch fix the issue. I don't understand why you need -fno-builtin -fno-common and -fno-strict-aliasing. These are C flags and not ASM flags. Maybe I missed something ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one
Hi, YongKang and Tristan I suspect this error may be happened by too early destroy. Please try to create domU after waiting about 20 sec. 1. boot Xen0 2. create XenU 3. sleep 20 3. destroy xenU 4. sleep 20 5. create 2nd XenU 6. sleep 20 7. destroy 2nd XenU Best Regards, Akio and Kan Hi all, I am very glad to see xm destroy xenU will release memory. But when I try this feature, I found I couldn't create 2nd xenU successfully. I do the following steps: 1. boot Xen0 2. create XenU 3. After xenU boot up, use poweroff in xenU to kill xenU. 4. create 2nd XenU 5. when 2nd XenU boot up to start udev, xenU stop to boot and serial port kept reporting bad hyperprivop. (please see the attachment) If I destroy the 2nd xenU, the whole system seems hang. I catch this issue in Cset 9268. Best Regards, Yongkang (Kangkang) モタソオ ---text/plain--- ___ 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] Create 2nd XenU fail after destroy 1st one
Hi, Yongkang and all I have reproduced your problem. Hmm... I look like this fault is occurred at srlz instruction. I try to debug it. # Do everyone think xen's printf is buggy? My environment: Machine : Tiger4 OS : RHEL4 Update2 gestOS : RHEL4 Update2 How to reproduce 1. xend start 2. xm create domU 3. xm console domU - and hit poweroff command. 4. xm create domU then call trace is happend in xm dmesg. 5. xm destroy domU - then system hang up... Best Regards, Akio Takebe Hi Akio, I do poweroff in XenU to kill it. It means xenU has been booted up. This should more than 20 seconds. :) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト\xF3ヤツ16ネユ 17:42 To: You, Yongkang; xen-ia64-devel@lists.xensource.com; Tristan Gingold Subject: Re: [Xen-ia64-devel] Create 2nd XenU fail after destroy 1st one Hi, YongKang and Tristan I suspect this error may be happened by too early destroy. Please try to create domU after waiting about 20 sec. 1. boot Xen0 2. create XenU 3. sleep 20 3. destroy xenU 4. sleep 20 5. create 2nd XenU 6. sleep 20 7. destroy 2nd XenU Best Regards, Akio and Kan Hi all, I am very glad to see xm destroy xenU will release memory. But when I try this feature, I found I couldn't create 2nd xenU successfully. I do the following steps: 1. boot Xen0 2. create XenU 3. After xenU boot up, use poweroff in xenU to kill xenU. 4. create 2nd XenU 5. when 2nd XenU boot up to start udev, xenU stop to boot and serial port kept reporting bad hyperprivop. (please see the attachment) If I destroy the 2nd xenU, the whole system seems hang. I catch this issue in Cset 9268. Best Regards, Yongkang (Kangkang) ・筵ソ・ス・ェ ---text/plain--- ___ 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] [PATCH] XEN: fixed a vcpu_translate bug
Yes, it great! I also confirm it. Best Regards, Akio Takebe Great! This patch can fix the two DomU creates issue. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: 2006ト\xF3ヤツ17ネユ 11:22 To: Xu, Anthony; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH] XEN: fixed a vcpu_translate bug Please desert the old one and use this new one Thanks, -Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xu, Anthony Sent: 2006ト\xF3ヤツ17ネユ 10:17 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] XEN: fixed a vcpu_translate bug There are some below code segments in guest OS 1. Rsm psr.dt ... 2. itc.d r18 ... 3. rfi After executing instruction 1, domain is in metaphysical mode. When executing instruction 2, VMM gets control to emulate this instruction. Firstly VMM will try to get opcode, which may trigger a tlb miss. At this time domain is in metaphysical mode and the fault address is in region 5. vcpu_translate handles this as normal guest metaphysical mode. It's not correct; sometimes this will make dom0 hang. cpu_translate should handle this situation as if guest is not in metaphysical mode. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony ___ 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] SAL INFO virtualization
Hi, 2) Xen merges all error records to dom0 cpu 0. According to SAL specs, it seems possible, since all CPU error logs have lid. I agree. 3) Xen creates a new interface to access error records. The linux driver must be modified for Xen. Why must linux driver be modified? Do linux device drivers use salinfo? Or other reasons? Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] massage of elf_sanity_check as x86
Hi,
This small patch output message of elf_sanity_check as x86.
Currently this panic is the only following message.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN)
(XEN)
(XEN) Reboot in five seconds...
(XEN) machine_restart called: spinning
Best Regards,
Akio Takebe
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r de0c04ed4ab7 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri Apr 21 10:40:17 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cMon Apr 24 15:05:38 2006 +0900
@@ -751,7 +751,12 @@ unsigned long domain_mpa_to_imva(struct
// see arch/x86/xxx/domain_build.c
int elf_sanity_check(Elf_Ehdr *ehdr)
{
- return (IS_ELF(*ehdr));
+ if (!(IS_ELF(*ehdr)))
+ {
+ printk(DOM0 image is not a Xen-compatible Elf image.\n);
+ return 0;
+ }
+ return 1;
}
static void copy_memory(void *dst, void *src, int size)
msg_of_elf_sanity_check.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Reseve memory of domain0 (fix dom0 boot panic)
Hi, Our patch fix domain0 boot panic on large memory system. (e.g. amount of installed memory is 16GB) Memory of domain0 is not reserved now. Our patch can make this memory reserved. And we clean up initrd_start of domain0. Signed-off-by: Kouya Shimura [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe rsv_dom0_mem.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Reseve memory of domain0 (fix dom0 boot panic)
Hi, Isaku
Why does the region need reservation?
dom0/initrd images are copied by construct_dom0().
The dom0/initrd regions must not be used before contruct_dom0(),
but they can be used after construct_dom0().
Yes, dom0/inird images are copied by construct_dom0().
But the region is clean up by init_virtual_frametable()
before construct_dom0 is called.
So the region need reservation.
I have the following error message at that time.
(XEN) Boot processor id 0x0/0xc418
(XEN) SMP mode deactivated.
(XEN) num_online_cpus=1, max_cpus=0
(XEN) Brought up 1 CPUs
(XEN) Total of 1 processors activated (0.26 BogoMIPS).
(XEN) About to call sort_main_extable()
(XEN) Maximum number of domains: 63; 18 RID bits per domain
(XEN) About to call domain_create()
(XEN) ### domain f41356b8: rid=4-8 mp_rid=1000
(XEN) arch_domain_create: domain=f41356b8
(XEN) About to call construct_dom0()
(XEN) *** LOADING DOMAIN 0 ***
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN)
(XEN)
(XEN) Reboot in five seconds...
(XEN) machine_restart called: spinning
The above change is wrong. Please backout or fix somehow.
With P=M model it works but it isn't right. It breaks the P2M/VP patches.
Please see construct_dom0().
I attach a patch which fix the above bug.
Am I correct?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r adb151aaf3f8 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch/ia64/xen/dom_fw.cWed Apr 26 20:55:42 2006 -0600
+++ b/xen/arch/ia64/xen/dom_fw.cWed May 3 14:29:26 2006 +0900
@@ -1019,7 +1019,8 @@ dom_fw_init (struct domain *d, const cha
if (d == dom0) {
// XXX CONFIG_XEN_IA64_DOM0_VP
// initrd_start address is hard coded in start_kernel()
- bp-initrd_start = ia64_boot_param-initrd_start;
+ bp-initrd_start = (dom0_start+dom0_size) -
+ (PAGE_ALIGN(ia64_boot_param-initrd_size) + 4*1024*1024);
bp-initrd_size = ia64_boot_param-initrd_size;
}
else {
diff -r adb151aaf3f8 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Wed Apr 26 20:55:42 2006 -0600
+++ b/xen/arch/ia64/xen/xensetup.c Wed May 3 14:29:26 2006 +0900
@@ -415,8 +415,7 @@ printk(About to call domain_create()\n
printk(About to call construct_dom0()\n);
dom0_memory_start = (unsigned long) __va(initial_images_start);
dom0_memory_size = ia64_boot_param-domain_size;
-dom0_initrd_start = (unsigned long) __va(initial_images_start +
-PAGE_ALIGN(ia64_boot_param-domain_size));
+dom0_initrd_start = (unsigned long) __va(ia64_boot_param-initrd_start);
dom0_initrd_size = ia64_boot_param-initrd_size;
if ( construct_dom0(dom0, dom0_memory_start, dom0_memory_size,
Best Regards,
Akio Takebe
fix_initrd_start.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Reseve memory of domain0 (fix dom0 boot panic)
Hi, Why does the region need reservation? dom0/initrd images are copied by construct_dom0(). The dom0/initrd regions must not be used before contruct_dom0(), but they can be used after construct_dom0(). Yes, dom0/inird images are copied by construct_dom0(). But the region is clean up by init_virtual_frametable() before construct_dom0 is called. So the region need reservation. You only explained the region shouldn't have been used until the copy by construct_dom0(). Why do you waste memory of the regions? The reservation can be accepted as a temporal work around. But it isn't right. You are right. I want to free the reserved regions after construct_dom0(). But now, please leave the reserved code since the waste memory is small. I'll make free_initrd_mem() like a linux and fix it. What do you think about it? The above change is wrong. Please backout or fix somehow. With P=M model it works but it isn't right. It breaks the P2M/VP patches. Please see construct_dom0(). I attach a patch which fix the above bug. Am I correct? It looks correct with respect to bp-initrd_start. Thank you, another is cleanup. :- Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [PATCH] compilation fix of ia64 hypervisor.c, utils.c (was Re:[Xen-ia64-devel] latest tree building fail.)
Hi, I have the following error with default config. Does everyone have the same? cset #9992. SAL 0.1: Xen/ia64 Xen/ia64 version 0.0 SAL: AP wakeup using external interrupt vector 0xf3 xen_pal_emulator: UNIMPLEMENTED PAL CALL 42 (XEN) No logical to physical processor mapping available vcpu_set_itc: Setting ar.itc is currently disabled (XEN) (this message is only displayed one) (XEN) ACPI: Local APIC address ffda ACPI: [APIC:0x07] ignored 12 entries of 16 found register_intr: No IOSAPIC for GSI 4294967295 (XEN) ia64_fault, vector=0x001e, ifa=, iip=f409b260, ipsr=121008222018, isr=0a02 (XEN) Unaligned Reference. (XEN) d 0xf4136280 domid 0 (XEN) vcpu 0xf7fa vcpu 0 (XEN) (XEN) CPU 0 (XEN) psr : 121008222018 ifs : 8998 ip : [f409b261] (XEN) ip is at iosapic_guest_write+0x591/0x670 (XEN) unat: pfs : 0998 rsc : 0003 (XEN) rnat: bsps: pr : aaa9 (XEN) ldrs: ccv : fpsr: 0009804c8a70033f (XEN) csd : ssd : (XEN) b0 : f409b210 b6 : f4043b70 b7 : ec100800 (XEN) f6 : 0fffbc8c0 f7 : 0ffdba200 (XEN) f8 : 100018000 f9 : 10002a000 (XEN) f10 : 0fffdc8c0 f11 : 1003e (XEN) r1 : f42f2900 r2 : 4137 r3 : a00100c0fe29 (XEN) r8 : ffed r9 : r10 : (XEN) r11 : 0ae9 r12 : f7fa78d0 r13 : f7fa (XEN) r14 : f4106670 r15 : r16 : c318 (XEN) r17 : f01804108838 r18 : 0011 r19 : f4106e44 (XEN) r20 : f4106e48 r21 : 0010 r22 : a00100c7f198 (XEN) r23 : 3fda r24 : 0001012f0010 r25 : 0001012f0010 (XEN) r26 : r27 : r28 : (XEN) r29 : r30 : r31 : f4103900 (XEN) (XEN) Call Trace: (XEN) [f40888e0] show_stack+0x80/0xa0 (XEN) sp=f7fa7480 bsp=f7fa10b8 (XEN) [f405f770] ia64_fault+0x290/0x680 (XEN) sp=f7fa7650 bsp=f7fa1080 (XEN) [f4087580] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7fa76d0 bsp=f7fa1080 (XEN) [f409b260] iosapic_guest_write+0x590/0x670 (XEN) sp=f7fa78d0 bsp=f7fa0fb8 (XEN) [f4054ce0] do_physdev_op+0x500/0x640 (XEN) sp=f7fa78d0 bsp=f7fa0f88 (XEN) [f4054ed0] do_physdev_op_compat+0xb0/0xd0 (XEN) sp=f7fa7920 bsp=f7fa0f68 (XEN) [f4053e90] ia64_hypercall+0x390/0xce0 (XEN) sp=f7fa7940 bsp=f7fa0f08 (XEN) [f40603a0] ia64_handle_break+0x1b0/0x2d0 (XEN) sp=f7fa7e00 bsp=f7fa0eb8 (XEN) [f4087580] ia64_leave_kernel+0x0/0x310 (XEN) sp=f7fa7e00 bsp=f7fa0eb8 (XEN) [a00100057010] ??? (XEN) sp=f7fa8000 bsp=f7fa0e38 (XEN) [a00100056f10] ??? (XEN) sp=f7fa8000 bsp=f7fa0dc8 (XEN) [a00100056f10] ??? (XEN) sp=f7fa8000 bsp=f7fa0d60 (XEN) [a00100056f10] ??? (XEN) sp=f7fa8000 bsp=f7fa0cf8 (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Fault in Xen. (XEN) (XEN) (XEN) Reboot in five seconds... (XEN) machine_restart called: spinning ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [PATCH] compilation fix of ia64 hypervisor.c, utils.c (was Re:[Xen-ia64-devel] latest tree building fail.)
Hi, Kevin I'm sorry. I tried again. I can boot up with VP off. I have a mistake(I used old kernel(2.6.16-xen)). My auto build scripts was stupid... Best Regards, Akio Takebe Hi, Akio, I just tried the tip (9992) and succeed with creating dom0/domU. Do you make a fresh compile upon the tip? Your problem seems similar to the one with VP model enabled, though the error indicator seems to be incorrect GSI number... Thanks Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] fedora-xen-ia64 first pass
Hi, Aron Which distro do you use on your rpmbuild system? Fedora5-ia64? or RHEL4? Cannot we completely make fedora-xen-ia64 yet? I had the following error. Did I have mistakes? + rm -rf /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + /bin/mkdir -p /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr COPYING README /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr docs/pdf/ /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr docs/misc/ /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + exit 0 warning: File listed twice: /usr/lib/xen warning: File listed twice: /usr/lib/xen/boot Provides: _pyext2.so()(64bit) acm.so()(64bit) config(xen) = 3.0.2-4 libxenctrl.so.3.0()(64bit) libxenguest.so.3.0()(64bit) libxenstore.so()(64bit) xc.so()(64bit) xs.so()(64bit) Requires(interp): /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Requires(post): /bin/sh Requires(preun): /bin/sh Requires: /bin/bash /bin/sh /usr/bin/env /usr/bin/python bridge-utils config(xen) = 3.0.2-4 libSDL-1.2.so.0()(64bit) libc.so.6.1()(64bit) libc.so.6.1(GLIBC_2.2)(64bit) libc.so.6. 1(GLIBC_2.3)(64bit) libc.so.6.1(GLIBC_2.3.4)(64bit) libc.so.6.1(GLIBC_2.4)(64bit) libext2fs.so.2()(64bit) libjpeg.so.62()(64bit) libm.so.6.1()(64bit) libncurses.so.5()(64bit) lib nsl.so.1()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libutil.so.1()(64bit) libutil.so.1(GLIBC_2.0)(64bit) libvirt-pyth on libxenctrl.so.3.0()(64bit) libxenguest.so.3.0()(64bit) libxenstore.so()(64bit) libz.so.1()(64bit) python(abi) = 2.4 python-abi = 2.4 udev = 059 Processing files: xen-debuginfo-3.0.2-4 Provides: _pyext2.so.debug()(64bit) acm.so.debug()(64bit) libxenctrl.so.3.0.0.debug()(64bit) libxenguest.so.3.0.0.debug()(64bit) xc.so.debug()(64bit) xs.so.debug()(64bit) Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/xen-3.0.2-4-root warning: Could not canonicalize hostname: tiger72 error: Could not open /root/fedora/fedora-xen-ia64/SRPMS/xen-3.0.2-4.src.rpm: No such file or directory So I do the following step. Is this step the same as yours? 1. make rpm of kernel (as-is Anil's step) hg clone http://free.linux.hp.com/~agriffis/fedora-kernel-ia64 cd fedora-kernel-ia64 mkdir -p BUILD RPMS/ia64 source bashrc-snippet # might want this in your ~/.bashrc cd SPECS rpmbuild -ba kernel-2.6.spec 2. make xen # rpmbuild -bp xen.spec # cd ../BUILD/xen-unstable.hg/ # make xen # make tools # make install-tools # cp xen/xen.gz /boot/efi/efi/redhat/ Best Regards, Akio Takebe Hello, I've made a first pass at modifying the Fedora Rawhide xen and kernel rpms to support ia64. There is still a lot of work to do before this would be suitable for inclusion in Fedora, but hopefully this represents a proof-of-concept that can be improved to that point. If you'd like to browse or contribute, the bits are available as mercurial repositories at: http://free.linux.hp.com/~agriffis/ There are 5 repositories presently: fedora-xen-rpm Tracks xen.src.rpm from rawhide. fedora-xen-ia64 Pulls from fedora-xen-rpm, contains (trivial) modifications for ia64 fedora-kernel-rpm Tracks kernel.src.rpm from rawhide. fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains modifications for ia64 xen-ia64-unstable-2.6.17Forward port of xen-ia64-unstable sparse tree from 2.6.16.13 to 2.6.17, generates linux-2.6-xen.patch for fedora-kernel-ia64 Here is my non-comprehensive list of notes/issues for fedora-kernel-ia64: 1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the most maintainable method seems to be to do the port in the context of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17 above). Using this method makes it relatively easy to: (a) port forward to a new kernel at any time using the sparse-merge script (b) pull new changes from upstream xen and avoid most manual merging (c) extract a patch at any time that represents the forward-port of xen to a new kernel (d) generate a patch at any time that adds xen support to the fedora kernel (linux-2.6-xen.patch generated with make mkpatches) The only caveat here is that I probably didn't do the forward port perfectly. In particular I know I bungled the TPM stuff because there are lots of changes going into kernel.org and xen simultaneously. Additionally I didn't pay a lot of attention to other architectures for the moment. Hopefully 2.6.17 will pop
Re: [Xen-ia64-devel] fedora-xen-ia64 first pass
Hi, Aron
Thank you for your help.
I can make RPMS/ia64/xen-3.0.2-4.ia64.rpm.
fedora-xen-ia64/RPMS/ia64/xen-3.0.2-4.ia64.rpm includes all tools of xen.
(don't includes xen(hypervisor) and domain's kernel)
But I cannot make fedora-kernel-ia64 yet.
===
gcc -Wp,-MD,arch/ia64/kernel/.irq_lsapic.o.d -nostdinc -isystem
/usr/lib/gcc/ia64-redhat-linux/4.1.0/include -D__KERNEL__ -Iinclude -include
include/linux/autoconf.h -DHAVE_W
ORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Os -fomit-frame-poin
ter -g -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -falign-functions=32
-frename-registers -fno-optimize-sibling-calls -Wdeclaration-after-statement
-Wno-pointer-sign -mc
onstant-gp -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(irq_lsapic)
-DKBUILD_MODNAME=KBUILD_STR(irq_lsapic) -c -o
arch/ia64/kernel/.tmp_irq_lsapic.o arch/ia64/kernel/ir
q_lsapic.c
mm/page_alloc.c: In function 'alloc_node_mem_map':
mm/page_alloc.c:2143: error: 'MAX_ORDER_NR_PAGES' undeclared (first use in this
function)
mm/page_alloc.c:2143: error: (Each undeclared identifier is reported only once
mm/page_alloc.c:2143: error: for each function it appears in.)
make[1]: *** [mm/page_alloc.o] Error 1
make: *** [mm] Error 2
make: *** Waiting for unfinished jobs
===
This error is caused by SOURCES/linux-2.6-xen-ia64-10022.patch
MAX_ORDER_NR_PAGES is not defined.
What does this patch mean?
===
@@ -2124,14 +2127,22 @@ static void __init alloc_node_mem_map(st
#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat-node_mem_map) {
- unsigned long size;
+ unsigned long size, start, end;
struct page *map;
- size = (pgdat-node_spanned_pages + 1) * sizeof(struct page);
+ /*
+* The zone's endpoints aren't required to be MAX_ORDER
+* aligned but the node_mem_map endpoints must be in order
+* for the buddy allocator to function correctly.
+*/
+ start = pgdat-node_start_pfn ~(MAX_ORDER_NR_PAGES - 1);
+ end = pgdat-node_start_pfn + pgdat-node_spanned_pages;
+ end = ALIGN(end, MAX_ORDER_NR_PAGES);
+ size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat-node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
- pgdat-node_mem_map = map;
+ pgdat-node_mem_map = map + (pgdat-node_start_pfn - start);
}
#ifdef CONFIG_FLATMEM
/*
===
I'm not clear about directory construction.
What do each directory mean?
I want to know the following directory's meaning.
# ls -F fedora-kernel-ia64/BUILD/kernel-2.6.16/
Config.mk extract.pub kernel.pub kernel.sec linux-2.6.16.ia64/
pubring.gpg random_seed secring.gpg vanilla/ xen/ xen-10022/
Are kernels of domain0/domainU made at linux-2.6.16.ia64?
If so, each linux-2.6.16.ia64 must be remade at each building time.
Am I right?
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] fix AFLAGS again
Hi, AFLAGS = -nostdinc $CPPFLAGS is removed. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=11b7dc3529b9 I think we cannot cross compile xen. See xen/arch/ia64/linux/Makefile. I make a fix patch. Best Regards, Akio Takebe add_nostdinc_to_aflags.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Patch] fix AFLAGS again
Hi, I'm sorry. I forgot our signed-off-by. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Kouya Shimura [EMAIL PROTECTED] Best Regards, Akio Takebe Hi, AFLAGS = -nostdinc $CPPFLAGS is removed. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=11b7dc3529b9 I think we cannot cross compile xen. See xen/arch/ia64/linux/Makefile. I make a fix patch. 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] Re: [Xen-users] XEN on machines with EFI
Hi, Rodrigo You should not run new elilo.efi on bash. You should install new elilo.efi into /boot/efi of vfat filesystem. And you should run it on EFI shell. In the case of RHEL, we install it into /boot/efi/EFI/redhat/ . Best Regards, Akio Takebe Hi! I tried ./xen/arch/ia64/tools/xelilo/xlilo.efi as Xiantao said, but: debian-ia64:/home/peso/xen-ia64-unstable.hg#./xen/arch/ia64/tools/xelilo/ xlilo.efi bash: ./xen/arch/ia64/tools/xelilo/xlilo.efi: cannot execute binary file I downloaded elilo-3.6-ia64.efi in http://elilo.sourceforge.net/cgi-bin/blosxom as Akio Takebe said, but occurs the same thing: debian-ia64:/home/peso# ./elilo-3.6-ia64.efi bash: ./elilo-3.6-ia64.efi: cannot execute binary file ps: I`m root, and I do chmod +x Any solution? Thanks! :) 2006/5/26, Jones, Chris [EMAIL PROTECTED]: I have found the efibootmgr that allows you to build a new label in EFI. Every time I try to boot off this new kernel I get a file not found. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Lord Sent: Thursday, May 25, 2006 7:32 AM To: [EMAIL PROTECTED] Subject: [Xen-users] XEN on machines with EFI Hello! I installed the xen3-unstable on an Itanium2. I`m using Debian Sarge 3.1! I configured the elilo.conf normally, but when I reboot... not shows the option XEN on my elilo! How do I boot the xen using EFI? Anything different? Thanks! ___ Xen-users mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-users ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ---html-part included links--- mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [FYI] Recipe of Booting up the latest Xen
Hi, Rodrigo
My RHEL4 recipe is the below.
This recipe is not tested, but almost correct. ;-)
If you have a problem, then please let me know.
My enviroment is;
Machine : Tiger4
Dom0 OS : RHEL4 U2
DomU OS : RHEL4 U2
Build xen
1. Download source
# hg clone http://xenbits.xensource.com/ext/xen-ia64-unstable.hg
2. # make world -j4
3. # make install-tools
4. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp linux-2.6.16.13-xen0/vmlinux.gz
/boot/efi/efi/redhat/vmlinuz-2.6.16.13-xen
5. make initrd for Dom0/DomU
# cd linux-2.6.16.13-xen/
# make modules_install
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.16.13-xen.img 2.6.16.13-xen
--builtin mptbase --builtin mptscsih
# cd ..
-
Make OSimg for DomU
1. make file
# dd if=/dev/zero of=/root/rhel4.img bs=1M count=4096
# mke2fs -F -j /root/rhel4.img
# mount -o loop /root/rhel4.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/hda1 /ext3defaults1 1
none/dev/pts devpts gid=5,mode=620 0 0
none/dev/shm tmpfs defaults0 0
none/procprocdefaults0 0
none/sys sysfs defaults0 0
3. modify inittab (runlevel)
# vi /mnt/etc/inittab
id:3:initdefault:
4. add tty0 into /etc/securetty
# vi /mnt/etc/securetty (add tty0)
5. umount
# umount /mnt
-
Boot Xen
1. replace elilo
download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/EFI/redhat/
# cp elilo-3.6-ia64.efi /boot/efi/EFI/redhat/elilo.efi
2. modify elilo.conf
# vi /boot/efi/EFI/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.16.13-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.16.13-xen.img
read-only
append=com2=115200,8n1 console=com2 -- nomca nosmp console=tty0
console=ttyS1,115200,8n1 rhgb root=/dev/sda2
image=vmlinuz-2.6.9-22.EL
label=linux
initrd=initrd-2.6.9-22.EL.img
read-only
append=rhgb root=/dev/sda2
3. make config of DomU
# vi /etc/xen/rhel4
kernel = /boot/efi/efi/redhat/vmlinuz-2.6.16.13-xen
memory = 384
name = rhel4
nics=0
disk = [ 'file:/root/rhel4.img,hda1,w' ]
root = /dev/hda1 ro
extra = 3
4. After boot xen and dom0, start xend
# /etc/init.d/xend start
( In the debugging case, # XEND_DEBUG=1 xend trace_start )
5. start domU
# xm create -c rhel4
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] [FYI] Recipe of Booting up the latest Xen
Hi, Kevin I remembered that several people ever cried for same request and some others also threw out good receipts like following. Then... is it possible to record such receipts in the repository, to avoid future duplicated post on same puzzle? :-) This is good idea. xen/arch/ia64/tools/README.* are old. I'll make patch to fix these. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] cleanup linux-2.6-xen-sparce
Hi, Alex and Aron
This is a cleanup patch.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
Best Regards,
Akio Takebe
diff -r acabf4bdec4f linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Wed May 31 13:
05:21 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Mon Jun 05 18:
55:47 2006 +0900
@@ -564,7 +564,7 @@ xen_ia64_privcmd_entry_munmap(struct xen
entry-gpfn = INVALID_GPFN;
}
-static int
+static void
xen_ia64_privcmd_entry_open(struct xen_ia64_privcmd_range*
privcmd_range,
int i)
{
@@ -576,7 +576,7 @@ xen_ia64_privcmd_entry_open(struct xen_i
}
}
-static int
+static void
xen_ia64_privcmd_entry_close(struct xen_ia64_privcmd_range*
privcmd_range,
int i)
{
fix_non-void.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] [RFC] README patch of booting xen
Hi, We make a patch to remake README.xenia64. Welcome to commets. :-) Signed-off-by: Yutaka Ezaki [EMAIL PROTECTED] Signed-off-by: nakato [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe Hi, Kevin I remembered that several people ever cried for same request and some others also threw out good receipts like following. Then... is it possible to record such receipts in the repository, to avoid future duplicated post on same puzzle? :-) This is good idea. xen/arch/ia64/tools/README.* are old. I'll make patch to fix these. Best Regards, Akio Takebe readme.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI
Hi, Option -f is overwrite option. If you don't have /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img, -f isn't necessary. You try to do that without -f option. Best Regards, Akio Takebe Hello! Yes, I do the make modules_install in linux-2.6.16.13-xen0 and in linux-2.6.16.13-xenU. I don`t understand why I can`t execute the mkinitrd correctly... the option -f is illegal: debian-ia64:/home/peso/xen-ia64-unstable.hg/linux-2.6.16.13-xen0# mkinitrd -f /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 --buildin mptbase --buildin mptscsih /usr/sbin/mkinitrd: illegal option -- f $Id: mkinitrd,v 1.201 2004/05/16 22:00:48 herbert Exp $ Usage: /usr/sbin/mkinitrd [OPTION]... -o outfile [version] Options: -d confdir Specify an alternative configuration directory. -k Keep temporary directory used to make the image. -m command Set the command to make an initrd image. -o outfile Write to outfile. -r root Override ROOT setting in mkinitrd.conf. Thanks! 2006/6/1, Zhang, Xiantao [EMAIL PROTECTED]: Hi Rodrigo, Akio is right. Of course, you can make a try with old initrd.img . Maybe it is OK for your system. Thanks -Xiantao -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト\xF3ヤツ2ネユ 9:46 To: Rodrigo Lord; Zhang, Xiantao; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI Hi, Rodrigo # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . Did you do the below? 5. make initrd for Dom0/DomU # cd linux-2.6.16.13-xen/ # make modules_install --this one # mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.16.13-xen.img 2.6.16. 13-xen --builtin mptbase --builtin mptscsih # cd .. And you may use --builtin option. Whenever I mkinitrd, I do the below. mkinitrd -f /boot/efi/efi/xen/initrd-2.6.16.13-xen.img 2.6.16.13-xen -- builtin mptbase --builtin mptscsih Best Regards, Akio Takebe Hello! Yes, I understood! I think that the EFI isn`t more my problem! :) I`m with problems to create my initrd! # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . . . Any help? Thanks! ---html-part included links--- mailto:[EMAIL PROTECTED] mailto:xen-ia64-devel@lists.xensource.com ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problems booting domU
Hi, Rodrigo Please try the below. # xm create -c -f /etc/xen/vm01-config.sxp Best Regards, Akio Takebe I`m trying to boot my domU and occurrs the error below: debian-ia64:~# xm create -c /etc/xen/vm01-config.sxp ERROR: Could not obtain handle on privileged command interface (2 = No such file or directory) Using config file /etc/xen/vm01-config.sxp. Error: (2, 'No such file or directory') ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Problems booting domU
Hi, Rodrigo Please try it as root user. And you may need to confirm that there is /etc/xen/vm01-config.sxp. Best Regards, Akio Takebe Hi, Rodrigo Please try the below. # xm create -c -f /etc/xen/vm01-config.sxp Best Regards, Akio Takebe I`m trying to boot my domU and occurrs the error below: debian-ia64:~# xm create -c /etc/xen/vm01-config.sxp ERROR: Could not obtain handle on privileged command interface (2 = No such file or directory) Using config file /etc/xen/vm01-config.sxp. Error: (2, 'No such file or directory') ___ 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] Problems booting domU
Hi, Rodrigo You can add xencons=tty0 console=tty0 into extra option. My config is the below. == kernel = /boot/vmlinux-2.6.16.13-xenU ramdisk = /boot/initrd-2.6.16.13-xenU.img memory = 512 name = rhel4 disk = [ 'file:/xen/image/rhel4.img,hda1,w' ] root = /dev/hda1 ro extra = nomca xencons=tty0 console=tty0 root=/dev/hda1 3 vcpus= 2 cpus= 1-2 == Best Regards, Akio Takebe Hi Akio Takebe! That problem was resolved. Now, my domU boot, but don`t load... It`s stays stopped in Started domain vm01! debian-ia64:/home/peso# xm create -c -f /etc/xen/vm01-config.sxp Using config file /etc/xen/vm01-config.sxp. Started domain vm01 debian-ia64:/home/peso# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 236 1 r- 235.5 vm01 2 150 1 -- 143.3 Thanks! 2006/6/7, Akio Takebe [EMAIL PROTECTED]: Hi, Rodrigo Please try it as root user. And you may need to confirm that there is /etc/xen/vm01-config.sxp. Best Regards, Akio Takebe Hi, Rodrigo Please try the below. # xm create -c -f /etc/xen/vm01-config.sxp Best Regards, Akio Takebe I`m trying to boot my domU and occurrs the error below: debian-ia64:~# xm create -c /etc/xen/vm01-config.sxp ERROR: Could not obtain handle on privileged command interface (2 = No such file or directory) Using config file /etc/xen/vm01-config.sxp. Error: (2, 'No such file or directory') ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ---html-part included links--- mailto:[EMAIL PROTECTED] mailto:Xen-ia64-devel@lists.xensource.com ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] sparse tree cleanups
Hi, Alex Without seeing the changes, it's hard to say. What I mean by simple checks are that it cannot call functions or declare variables that are only defined in CONFIG_XEN code. It's minor cleanup that you may not be able to use. Thanks, OK, I understand it. And I wanted to cleanup xenpage in linux-2.6-sparse/mm/memory.c But this xenpage isn't already used. So I simply remove it. I'll post this patch with another mail. Best Regards, Akio Takebe On Wed, 2006-06-07 at 15:08 +0900, Akio Takebe wrote: Hi, Alex I agree your suggestion. But your patch use ifdef CONFIG_XEN. You say we use simple is_running_on_xen() checks, aren't you? Is this mistake? or do I mis-understand? I want to clean up mm/memory.c. (This work is for cleanup fedora-xen's warning.) I should use is_running_on_xen() in mm/memory.c, shouldn't I? Hi Akio, Without seeing the changes, it's hard to say. What I mean by simple checks are that it cannot call functions or declare variables that are only defined in CONFIG_XEN code. It's minor cleanup that you may not be able to use. 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
[Xen-ia64-devel] [patch] cleanup warning for fedora core
Hi,
I remove xenpage in linux-2.6-xen-sparse/mm/memory.c
This xenpage isn't used already.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r b87ff075dab9 linux-2.6-xen-sparse/mm/memory.c
--- a/linux-2.6-xen-sparse/mm/memory.c Thu Jun 08 11:08:35 2006 -0600
+++ b/linux-2.6-xen-sparse/mm/memory.c Fri Jun 09 13:07:28 2006 +0900
@@ -968,7 +968,6 @@ int get_user_pages(struct task_struct *t
{
int i;
unsigned int vm_flags;
- int xenpage = 0;
/*
* Require read or write permissions.
@@ -1026,7 +1025,6 @@ int get_user_pages(struct task_struct *t
if (vma (vma-vm_flags VM_FOREIGN)) {
struct page **map = vma-vm_private_data;
int offset = (start - vma-vm_start)
PAGE_SHIFT;
- xenpage =1;
if (map[offset] != NULL) {
if (pages) {
struct page *page = map[offset];
Best Regards,
Akio Takebe
remove_xenpage.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] [0/4] Support INIT handler of xen
Hi, all I make patches which support INIT handler. This is the first work for IA64 MCA/INIT support. If look like good, please apply the following patch. INIT handler works good when I tested. MCA dispatcher is infinity loop now. Comments are welcome. :-) Signed-off-by: Akio Takebe [EMAIL PROTECTED] [1/4]: fix_get_this_paddr.patch [2/4]: asmmacro_h.patch [3/4]: mca_utils.patch [4/4]: mca_main.patch 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] [patch] [3/4] Support INIT handler of xen
Hi, Alex Thank you for your comments. There's quite a bit changed in this patch that doesn't seem to be covered by #ifdef XEN. Could you look into adding those in? Thanks, I'm sorry. I forgot adding #ifdef XEN when we change linx-xen/ for XEN. I'll add #ifdef XEN. Best Regards, Akio Takebe On Mon, 2006-06-12 at 15:06 +0900, Akio Takebe wrote: fix macro to support INIT handler arch/ia64/linux-xen/minstate.h | 70 ++--- --- arch/ia64/linux-xen/unwind.c| 23 ++ include/asm-ia64/linux-xen/asm/system.h |5 +- 3 files changed, 67 insertions(+), 31 deletions(-) Hi Akio, There's quite a bit changed in this patch that doesn't seem to be covered by #ifdef XEN. Could you look into adding those in? 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
Re: [Xen-ia64-devel] [patch] [4/4] Support INIT handler of xen
Hi, Alex Thank you for your comments. OK. I'll send the small new patch. I'll go in arch/ia64/xen. Best Regards, Akio Takebe On Thu, 2006-06-15 at 06:36 +0900, Akio Takebe wrote: Hi, Alex I forgot README.origin update, I'm sorry. The first I made a small patch with cutpaste without ifdef. But I remade a big patch with ifdef, because I think we may leverage the original mac code. I don't know this leverage, because another fujitsu member will make other mca code. I think my ifdef is ugly, so I want to remake non-ifdef patch. But I refer linux code, can I make xen-mca code wiht cutpaste without ifdef in arch/ia64/linux-xen? Hi Akio, The ifdefs are kind of ugly, and I wasn't sure how many lines of code were actually left enabled in those files. How many lines of code was the original cutpaste version? If only a few hundred lines, maybe it does make sense to separate it out. I think it should probably go in arch/ia64/xen though, not linux-xen. 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
Re: [Xen-ia64-devel] [Patch] cleanup warning in xen/arch/ia64/linux-xen/time.c
Hi, Tristan
I use gcc-3.4.4.
I also check gcc-4.1.1, and I also get warning.
This warning is happened in only the case of gcc-4.1.1.
I'll also reseach the warning.
Best Regards,
Akio Takebe
Le Samedi 10 Juin 2006 07:50, Akio Takebe a 馗rit :
Hi,
I remove a wrong cleanup in xen/arch/ia64/linux-xen/time.c
itc_ratio.num and itc_ratio.den are defined u64
in xen/include/asm-ia64/linux-xen/asm/pal.h.
These are the below.
typedef struct pal_freq_ratio {
u64 den : 32, num : 32; /* numerator denominator */
} itc_ratio, proc_ratio;
Which version of gcc are you using ?
gcc 4.1.1 now reports a warning.
I'll check the C standard.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: enable xenctx on ia64.
Hi, Tristan Your patch is very cool and good work! I also want to use xenctx. (I was working the same work as you. But you work faster than me. :-)) So I update your patch for printing more register and fixing small part. I think better if print_stack is enable. But FRAME_POINTER cannot get yet... Signed-off-by: Tristan Gingold [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe Hi, this patch makes xenctx compiling and running on xen/ia64. Tested on domU. Tristan. ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel xenctx.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: enable xenctx on ia64.
Hi, Tristan and Alex My patch is included some mistakes. So please ignore it's patch. I update my patch. This is depended on Tristan's patch. My fix is that xenctx show more register and is_kernel_text. Best Regards, Akio Takebe Hi, Tristan Your patch is very cool and good work! I also want to use xenctx. (I was working the same work as you. But you work faster than me. :-)) So I update your patch for printing more register and fixing small part. I think better if print_stack is enable. But FRAME_POINTER cannot get yet... Signed-off-by: Tristan Gingold [EMAIL PROTECTED] Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe Hi, this patch makes xenctx compiling and running on xen/ia64. Tested on domU. Tristan. ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel xencxt_more_regs.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xenctx, add dummy print_stack()
Hi, Alex How about my patch? I remove NO_TRANSLATION. NO_TRANSLATION is used by only ia64. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe The patch below consolidates the NO_TRANSLATION xenctx code to avoid additional #ifdef/#endif code blocks. Comments? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel cleanup_xenctx.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xenctx, add dummy print_stack()
Hi, Alex I also actually think your patch is better. I only proposed another way. :-) Best Regards, Akio Takebe On Tue, 2006-06-20 at 10:00 +0900, Akio Takebe wrote: Hi, Alex How about my patch? I remove NO_TRANSLATION. NO_TRANSLATION is used by only ia64. Hi Akio, I actually prefer the NO_TRANSLATION define instead of using an architecture define. It's a bit more generic. I just thought it might be nice to get rid of the one extra #ifdef/#endif around the call to print_stack(). 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
[Xen-ia64-devel] [Patch] remove CONFIG_ARCH_XEN
Hi, We don't already need CONFIG_ARCH_XEN in buildconfigs. Am I right? Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe remove_config_arch_xen.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] [0/9] Support INIT handler of xen (Take2)
Hi, I updated my init handler patches. I reflected commets. And to make it easy to read, I devide my patch to piaces. [1/9] fix GET_THIS_PADDR [2/9] fix GATE_ADDR [3/9] fix LOAD_PHYSCAL [4/9] add unw_init_from_interruption() [5/9] fix MINSTATE_START/END_SAVE_MIN_PHYS for INIT handler [6/9] fix MINSTATE_GET_CURRENT [7/9] add mca_asm.S for supporting ia64_monarch_init_handler() [8/9] add mca.c for supporting INIT handler [9/9] add mca_asm, mca into Makefile Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [1/9] fix GET_THIS_PADDR
fix GET_THIS_PADDR. Signed-off-by: Akio Takebe [EMAIL PROTECTED] mca_asm.h |4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) fix_get_this_paddr.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [2/9] fix GATE_ADDR
fix GATE_ADDR for ia64_do_show_stack(). I use KERNEL_START which is Xen's text start address. Signed-off-by: Akio Takebe [EMAIL PROTECTED] system.h |5 - 1 files changed, 4 insertions(+), 1 deletion(-) fix_gate_addr.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [3/9] fix LOAD_PHYSCAL
This fix is workaround. Now LOAD_PHYSCAL is used only by MCA/INIT handler. I'll try to make dinamic patch function. I'll remove this fix if I make it. So please apply for supporting INIT handler. Signed-off-by: Akio Takebe [EMAIL PROTECTED] a/xen/include/asm-ia64/linux/asm/asmmacro.h | 111 - b/xen/include/asm-ia64/linux-xen/asm/asmmacro.h | 119 +++ xen/include/asm-ia64/linux-xen/asm/README.origin |1 xen/include/asm-ia64/linux/asm/README.origin |1 4 files changed, 120 insertions(+), 112 deletions(-) ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [4/9] add unw_init_from_interruption()
This is used in init_handler_platform(). Signed-off-by: Akio Takebe [EMAIL PROTECTED] unwind.c | 23 +++ 1 files changed, 23 insertions(+) add_unw_init_from_interruption.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [3/9] fix LOAD_PHYSCAL
Hi, I forgot attach file. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe This fix is workaround. Now LOAD_PHYSCAL is used only by MCA/INIT handler. I'll try to make dinamic patch function. I'll remove this fix if I make it. So please apply for supporting INIT handler. Signed-off-by: Akio Takebe [EMAIL PROTECTED] a/xen/include/asm-ia64/linux/asm/asmmacro.h | 111 -- --- b/xen/include/asm-ia64/linux-xen/asm/asmmacro.h | 119 ++ + xen/include/asm-ia64/linux-xen/asm/README.origin |1 xen/include/asm-ia64/linux/asm/README.origin |1 4 files changed, 120 insertions(+), 112 deletions(-) fix_load_physcal.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [5/9] Fix MINSTATE_START/END_SAVE_MIN_PHYS for INIT handler
I modified linux code to make this fix. difference between linux and my fix - ia64_init_stack_addr have address of ia64_mca_data[i].init_stack. I computed address of init_stack by using it. - from dep r12=-1,r12,61,3; to dep r12=-1,r12,60,4; to computed xen virtual address. Signed-off-by: Akio Takebe [EMAIL PROTECTED] minstate.h | 30 -- 1 files changed, 28 insertions(+), 2 deletions(-) fix_minstate_save_min_phys.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [6/9] Fix MINSTATE_GET_CURRENT
To get virtual cuurent address in both physcal mode and virtual mode, I add MINSTATE_GET_CURRENT_VIRT. Signed-off-by: Akio Takebe [EMAIL PROTECTED] minstate.h | 17 +++-- 1 files changed, 15 insertions(+), 2 deletions(-) fix_minstate_get_current.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [7/9] Add mca_asm.S for supporting ia64_monarch_init_handler()
I remove unused code from original linux code. I don't modify this file. Signed-off-by: Akio Takebe [EMAIL PROTECTED] b/xen/arch/ia64/linux-xen/mca_asm.S | 209 ++ xen/arch/ia64/linux-xen/README.origin |1 2 files changed, 210 insertions(+) add_mca_asm_S.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [8/9] add mca.c for supporting INIT handler
This is main patch for supporting INIT handler. I update this patch. - into xen/arch/ia64/xen - make smaller mca.c. (non-ifdef code) In ia64_mca_init(), MCA/INIT handler is registered by ia64_sal_set_vectors(). MCA handler is ia64_monarch_init_handler in mca_asm.S INIT handler is ia64_os_mca_dispatch in mca_asm.S Now MCA handler is infinity loop. but we'll remake MCA hadler. Corrected MCA handler is not register now. INIT handler can show call trace, and I think this can be dump entry like kexec/kdump. Signed-off-by: Akio Takebe [EMAIL PROTECTED] mca.c | 448 ++ 1 files changed, 448 insertions(+) add_mca_init.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch] [0/9] Support INIT handler of xen (Take2)
[9/9] Add mca_asm, mca into Makefile I add mca.o, mca_asm.o into Makefile. And I remove dummy ia64_mca_init(). Signed-off-by: Akio Takebe [EMAIL PROTECTED] linux-xen/Makefile |1 + xen/Makefile |1 + xen/xenmisc.c |1 - 3 files changed, 2 insertions(+), 1 deletion(-) makefile.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [1/9] fix GET_THIS_PADDR
Hi, Tristan GET_THIS_PADDR translate from only per_cpu virtual address to per_cpu physcal address. per_cpu address is in TLB. So GET_THIS_PADDR don't cause TLB fault. Best Regards, Akio Takebe Le Jeudi 22 Juin 2006 18:31, Akio Takebe a 馗rit : fix GET_THIS_PADDR. Humm, does this work ? What prevents Alternate Data TLB fault from being raised ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [2/9] fix GATE_ADDR
Hi, Tristan Thanks. Good point. I'll update my patch. Best Regards, Akio Takebe Le Jeudi 22 Juin 2006 18:34, Akio Takebe a 馗rit : fix GATE_ADDR for ia64_do_show_stack(). I use KERNEL_START which is Xen's text start address. I suppose GATE_ADDR should be defined in xensystem.h for Xen. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [1/9] fix GET_THIS_PADDR
Hi, Tristan Le Vendredi 23 Juin 2006 13:15, Akio Takebe a 馗rit : Hi, Tristan GET_THIS_PADDR translate from only per_cpu virtual address to per_cpu physcal address. Yes. per_cpu address is in TLB. Is it true even within MCA handler ? Yes, TR is unchanged by SAL/PAL when INIT is occerred. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] [0/11] Support INIT handler of xen (Take3)
Hi, I updated my init handler patches. These patches are base on 2.6.13. I reflected commets. [1/11] add IA64_MCA_CPU_INIT_STACK_OFFSET [2/11] Fix GATE_ADDR for ia64_do_show_stack() [3/11] Fix GET_THIS_PADDR [4/11] Fix LOAD_PHYSCAL macro. (This fix is workaround) [5/11] add unw_init_from_interruption() [6/11] Fix MINSTATE_START/END_SAVE_MIN_PHYS for INIT handler [7/11] Fix MINSTATE_GET_CURRENT [8/11] Add mca_asm.S for supporting ia64_monarch_init_handler() [9/11] Add mca.c for supporting init_handler [10/11] Add mca_asm, mca into Makefile [11/11] INIT hadler for support coredumping feature Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][1/11] add IA64_MCA_CPU_INIT_STACK_OFFSET
add IA64_MCA_CPU_INIT_STACK_OFFSET which is used in MINSTATE_START_SAVE_MIN_PHYS Signed-off-by: Akio Takebe [EMAIL PROTECTED] asm-offsets.c |4 1 files changed, 4 insertions(+) add_init_stack_offset.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][2/11] Fix GATE_ADDR for ia64_do_show_stack()
I fix GATE_ADDR and define it in include/asm-ia64/xensystem.h. Signed-off-by: Akio Takebe [EMAIL PROTECTED] linux-xen/asm/system.h |2 +- xensystem.h|1 + 2 files changed, 2 insertions(+), 1 deletion(-) fix_gate_addr.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][4/11] Fix LOAD_PHYSCAL macro. (This fix is workaround)
This fix is workaround. Now LOAD_PHYSCAL is used only by MCA/INIT handler. I'll try to make dinamic patch function. I'll remove this fix if I make it. So please apply for supporting INIT handler. Signed-off-by: Akio Takebe [EMAIL PROTECTED] a/xen/include/asm-ia64/linux/asm/asmmacro.h | 111 - b/xen/include/asm-ia64/linux-xen/asm/asmmacro.h | 119 +++ xen/include/asm-ia64/linux-xen/asm/README.origin |1 xen/include/asm-ia64/linux/asm/README.origin |1 4 files changed, 120 insertions(+), 112 deletions(-) ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][5/11] add unw_init_from_interruption()
add unw_init_from_interruption() into unwind.c Signed-off-by: Akio Takebe [EMAIL PROTECTED] unwind.c | 23 +++ 1 files changed, 23 insertions(+) add_unw_init_from_interruption.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][6/11] Fix MINSTATE_START/END_SAVE_MIN_PHYS for INIT handler
I modified linux code to make this fix. difference between linux and my fix - THIS_CPU(ia64_mca_data) have physcal address of each cpu's ia64_mca_cpu. I computed address of init_stack by using it. - from dep r12=-1,r12,61,3; to dep r12=-1,r12,60,4; to computed xen virtual address. Signed-off-by: Akio Takebe [EMAIL PROTECTED] minstate.h | 29 +++-- 1 files changed, 27 insertions(+), 2 deletions(-) fix_minstate_save_min_phys.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][7/11] Fix MINSTATE_GET_CURRENT
To get virtual cuurent address in both physcal mode and virtual mode, I add MINSTATE_GET_CURRENT_VIRT. Signed-off-by: Akio Takebe [EMAIL PROTECTED] minstate.h | 29 +++-- 1 files changed, 27 insertions(+), 2 deletions(-) fix_minstate_get_current.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][8/11] Add mca_asm.S for supporting ia64_monarch_init_handler()
I remove unused code from original linux code. Now ia64_os_mca_dispatch is infinity loop for debug. Signed-off-by: Akio Takebe [EMAIL PROTECTED] b/xen/arch/ia64/linux-xen/mca_asm.S | 159 ++ xen/arch/ia64/linux-xen/README.origin |1 2 files changed, 160 insertions(+) add_mca_asm_S.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][9/11] Add mca.c for supporting init_handler
In ia64_mca_cpu_init(), I use alloc_xenheap_pages() for allocation of ia64_mca_cpu. In linux, alloc_bootmem is used. Signed-off-by: Akio Takebe [EMAIL PROTECTED] mca.c | 442 ++ 1 files changed, 442 insertions(+) add_mca_init.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch][10/11] Add mca_asm, mca into Makefile
This patch turn on new init handler. Signed-off-by: Akio Takebe [EMAIL PROTECTED] linux-xen/Makefile |1 + xen/Makefile |1 + xen/xenmisc.c |2 -- 3 files changed, 2 insertions(+), 2 deletions(-) makefile.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] why does xenU console stop at Freeingunusedkernel memory:304KB freed?
Hi, Fujita The compile error is a bug of fedora core6. fedoracore6 don't have linux/compile.h in glibc-kernheaders. Best Regards, Akio Takebe Hi Zhang and all, We also had same your issue on cset 10665 too. And as you said, that's okay to ping/ssh domU. In addition, we found a new issue that is compile failure(make tools) when using the same cset on FedoraCore6. please see attachment. Thanks, Fujita From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Jingke Sent: Friday, July 07, 2006 11:14 AM To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] why does xenU console stop at Freeing unusedkernel memory:304KB freed? Hi all, On Cset 10665, when I create a xenU domain I find the console stayed at “Freeing unused kernel memory:304KB freed”. But I am sure that it has been created. Because I can ping its dhcp_hostname and I can use ssh to log on it. What is wrong in the xenU console? Thank you. ---text/plain--- ___ 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] [patch] [0/11] Support INIT handler of xen(Take3)
Hi Akio, I still have some issues with these patches being maintainable. I've spent some time cleaning up the patches, moving them back into the linux-xen structure, and making them match upstream. I've committed the changes into a test tree here: http://free.linux.hp.com/~awilliam/20060706-init/ Please review changesets 10666 through 10679 of this tree and let me know if you approve of the modifications. If so, I'll push it to xen-ia64-unstable.hg. Thanks, Hi, Alex Thank you very much! I reviewed your test tree, and these changes are almost good. I tested dom0/domU booting and INIT work with the test tree and the results are good. BTW, I appreciate your work. I'd like to reduce your maintenance work. :-) I learned about the following things by seeing your test tree. We should do the below for reducing your maintenace work, shouldn't we? 1. If we port some features from linux, we add normal file into xen/arch/ia64/linux-xen. 2. Then we modify xen/arch/ia64/linux-xen/README.orig 3. We make the above patch. This is the first patch 4. We add the changes to porting to xen. 5. We make a patch of the chages. This is second patch. And we send the two patch to xen-ia64-devel. We should use linux-2.6.13 for porting to xen. The latest stable linux from www.kernel.org is better than linux-2.6.13. Am I correct? 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] why does xenU console stop atFreeingunusedkernel memory:304KB freed?
Hi, Fujita I can use domU's console with http://free.linux.hp.com/~awilliam/20060706-init/. The below is my config file. [EMAIL PROTECTED] fujita]# cat /etc/xen/takebe kernel = /boot/efi/efi/xen/vmlinuz-2.6.16.13-xen-takebe ramdisk = /boot/efi/efi/xen/initrd-2.6.16.13-xen.img-takebe memory = 512 name = rhel4-060707 disk = [ 'file:/root/rhel4_1.img,hda1,w' ] vif = [ '' ] root = /dev/hda1 ro extra = nomca nosmp console=tty0 3 [EMAIL PROTECTED] fujita]# mount -o loop /root/rhel4_1.img /mnt/ [EMAIL PROTECTED] fujita]# cat /mnt/etc/inittab # # inittab This file describes how the INIT process should set up # the system in a certain run-level. # # Author: Miquel van Smoorenburg, [EMAIL PROTECTED] # Modified for RHS Linux by Marc Ewing and Donnie Barnes # # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 Power Failure; System Shutting Down # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c Power Restored; Shutdown Cancelled # Run gettys in standard runlevels #1:2345:respawn:/sbin/mingetty tty0 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 # Run xdm in runlevel 5 x:5:respawn:/etc/X11/prefdm -nodaemon Best Regards, Akio Takebe Hi Alex, Akio, Thanks for your advice. Hopefully the domU console issues are related to using older tools. The domU console issues occurred on RHEL4U2 which had no compile error. Thanks, Fujita -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 1:56 PM To: Akio Takebe Cc: yo.fujita; 'Zhang, Jingke'; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] why does xenU console stop atFreeingunusedkernel memory:304KB freed? On Fri, 2006-07-07 at 13:41 +0900, Akio Takebe wrote: Hi, Fujita The compile error is a bug of fedora core6. fedoracore6 don't have linux/compile.h in glibc-kernheaders. I agree, my build system has compiler.h provided by the linux-kernel-headers package (Debian). You could try copying linux-2.6.16.13-xen/include/linux/compiler.h to /usr/include/linux to see if tools will build. Hopefully the domU console issues are related to using older tools. 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
[Xen-ia64-devel] [Patch] Force make symbolic link when make xen
Hi, When I move top directory of xen-ia64-unstable.hg, I have errors of ln -s command by re-compileing xen. I fixed it by using ln -sf. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe Makefile.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch] [0/11] Support INIT handler ofxen(Take3)
Hi, Alex On Fri, 2006-07-07 at 14:12 +0900, Akio Takebe wrote: Thank you very much! I reviewed your test tree, and these changes are almost good. I tested dom0/domU booting and INIT work with the test tree and the results are good. Hi Akio, almost good? Is there something that still needs to be fixed, or should I go ahead a push it into xen-ia64-unstable? I'm sorry for my poor English. That is Japanese expression... All of these changes are good. Please push it into xen-ia64-unstable. BTW, I appreciate your work. I'd like to reduce your maintenance work. :-) I learned about the following things by seeing your test tree. We should do the below for reducing your maintenace work, shouldn't we? 1. If we port some features from linux, we add normal file into xen/arch/ia64/linux-xen. 2. Then we modify xen/arch/ia64/linux-xen/README.orig 3. We make the above patch. This is the first patch 4. We add the changes to porting to xen. 5. We make a patch of the chages. This is second patch. And we send the two patch to xen-ia64-devel. We should use linux-2.6.13 for porting to xen. The latest stable linux from www.kernel.org is better than linux-2.6.13. Am I correct? Yes, this makes things much easier. It gives a known starting point with changesets incrementally changing from the base. It also makes review on the mailing list much easier. We can typically skip over reviewing the details of patches that are only adding files from Linux and concentrate on the changes we're making to the files. Isaku did this for the P2M/VP patches and I thought it was a good idea. Linux-2.6.13 is the current Xen/ia64 base and the preferred base for pulling in new files. However, if we need features and bug fixes from newer versions of Linux, I'll accept those too (try to make note of the different base in the README.origin file, see the iosapic.c entry for example). At some point we should update the Linux base files in the Xen/ia64 tree, but I think we've all been too busy adding new features and stabilizing to make that jump. Thank you for your explanation. We'd like to update the code, and we'd like to cleanup ifdef at some point, wouldn't we? If do it, we also do it. Sorry for leading you down the path of pulling code out of mca.c into a non-linux-xen file. In the end, I think the leverage from the upstream file became more obvious and the upcoming MCA work made me reluctant to proceed down that path. The #ifdef/#endifs can get ugly and tedious, but I think we just need to get more creative in organizing the modifications to account for that. Thanks, I don't care. I also sorry for increasing your maintenance work. Yes, I also think the upcoming MCA work is more ifdef. I think maybe better way that a function having many ifdef separate between changed function and original function. We're making MCA now, and If we'll have made it, we'll make the patches with above way. So we'll reduce your maintenance work. :-) Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Support domU of coredump on ia64
Hi, This patch support domU of coredump on ia64. xen_panic_event() is registered to panic_notifier_list, and xen_panic_event() call HYPERVISOR_shutdown(SHUTDOWN_crash) at panic time. If xend notify crashed status, xend call dumpCore() and create domU's core in /var/xen/dump. Signed-off-by: Akio Takebe [EMAIL PROTECTED] I tested the following step (I used a attached crash.c to panic domU.) 1. xm create -c domU 2. insmod crash.ko (in domU) 3. checked /var/xen/dump and there was domU's core. I check domU's core by using size and strings. Best Regards, Akio Takebe dumpcore.patch Description: Binary data crash.c Description: Binary data Makefile Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC] Enable dom0 to start X
Le Lundi 24 Juillet 2006 14:22, Akio Takebe a 馗rit :
Hi, all
I'm debugging Xwindow system of dom0.
[...]
At the results, I could startx, but not completely.
I found X run while using 100% CPU with top command.
The following messages were shown at that time.
(XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0
I think this 0xf4288080 is I/O page to be used by X.
(this 0xf4288080 is also not shown in memmap of Tiger4)
The I/O page seem to be not allocated.
How/When should xen allocate this page?
Hi,
you are misreading the message.
The bad mpa is 0xfbfd0738!
0xf4288080 is the address of struct domain, which is a valid virtual
address.
Hi,
Thanks, I understand this messages.
I overlooked the following comment.
unsigned long lookup_domain_mpa(struct domain *d, unsigned long mpaddr)
{
[snip...]
//XXX This is a work around until the emulation memory access to a region
//where memory or device are attached is implemented.
return pte_val(pfn_pte(0, __pgprot(__DIRTY_BITS | _PAGE_PL_2 |
_PAGE_AR_RWX)));
}
Hmmm... I'll continue to debug this issue.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-ia64-list] Re: Four ways RH could help with xen-ia64
Hi, Juan, Aron and all I fix Juan's http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora to build on ia64. But I have not booted linux kernel (not xen), and there are many compile warnings. I'm fixing the tree now. I used the attach config. Please check them. My fix patcheds are the blew. Please comments. 1. build_ia64_add_files.patch simple import gate.S, gate.ld.S, patch.c into arch/ia64/kernel (these are from linux-2.6.18-rc2) 2. build_ia64.patch some fix (resend_irq, ioremap, and so on) Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe build_patches.tar.bz2 Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Re: [Fedora-ia64-list] Re: Four ways RH could helpwith xen-ia64
Hi, Anthony, Juan and Aron Hmm.. I don't know. I have thought that merge base is linux-2.6.18-rc2, because of reading the following mail. Juan and Aron, am I wrong? If necessary, I'll update my patches. My patches work good on RHEL4 as native linux. Now I'm updating my fedora system by yum. After update, I'll try my patches on FC6. - Juan's wrote -- It is based on 2.6.18-rc2. It is on: http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora It is public only since Tuesday (I was waiting for a place where to publish it). Tree will not work on ia64, I didn't forward ported the ia64 changes, noly x86 x86_64 (and it was painfull enough, time source, smp-alternatives x86_64, irqtrace, vDSO on x86 friends meaned that I had to go back re-apply series of patches one at a time to find a coulpe of bugs). - Best Regards, Akio Takebe Hi Akio, Is this merge based on linux-2.6.18-rc2? When I diff linux-2.6-xen-fedora with linux-2.6.18-rc2, There are some modifications which are not marked by #ifdef CONFIG_XEN Thanks, Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akio Takebe Sent: 2006年7月25日 17:29 To: ia64 Fedora Core Development; Aron Griffis; Juan Quintela Cc: Chris Wright; xen-ia64-devel@lists.xensource.com; [EMAIL PROTECTED] Subject: [Xen-ia64-devel] Re: [Fedora-ia64-list] Re: Four ways RH could helpwith xen-ia64 Hi, Juan, Aron and all I fix Juan's http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora to build on ia64. But I have not booted linux kernel (not xen), and there are many compile warnings. I'm fixing the tree now. I used the attach config. Please check them. My fix patcheds are the blew. Please comments. 1. build_ia64_add_files.patch simple import gate.S, gate.ld.S, patch.c into arch/ia64/kernel (these are from linux-2.6.18-rc2) 2. build_ia64.patch some fix (resend_irq, ioremap, and so on) Signed-off-by: Akio Takebe [EMAIL PROTECTED] 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] Re: [Fedora-ia64-list] Re: Four ways RH could helpwith xen-ia64
Hi, Anthony I found the base version in Makefile. - VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 18 EXTRAVERSION = -rc2 NAME=Crazed Snow-Weasel # *DOCUMENTATION* # To see a list of typical targets execute make help # More info can be located in ./README # Comments in this file are [snip...] - Best Regards, Akio Takebe Hi, Anthony, Juan and Aron Hmm.. I don't know. I have thought that merge base is linux-2.6.18-rc2, because of reading the following mail. Juan and Aron, am I wrong? If necessary, I'll update my patches. My patches work good on RHEL4 as native linux. Now I'm updating my fedora system by yum. After update, I'll try my patches on FC6. - Juan's wrote -- It is based on 2.6.18-rc2. It is on: http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora It is public only since Tuesday (I was waiting for a place where to publish it). Tree will not work on ia64, I didn't forward ported the ia64 changes, noly x86 x86_64 (and it was painfull enough, time source, smp-alternatives x86_64, irqtrace, vDSO on x86 friends meaned that I had to go back re-apply series of patches one at a time to find a coulpe of bugs). - Best Regards, Akio Takebe Hi Akio, Is this merge based on linux-2.6.18-rc2? When I diff linux-2.6-xen-fedora with linux-2.6.18-rc2, There are some modifications which are not marked by #ifdef CONFIG_XEN Thanks, Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akio Takebe Sent: 2006年7月25日 17:29 To: ia64 Fedora Core Development; Aron Griffis; Juan Quintela Cc: Chris Wright; xen-ia64-devel@lists.xensource.com; [EMAIL PROTECTED] Subject: [Xen-ia64-devel] Re: [Fedora-ia64-list] Re: Four ways RH could helpwith xen-ia64 Hi, Juan, Aron and all I fix Juan's http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora to build on ia64. But I have not booted linux kernel (not xen), and there are many compile warnings. I'm fixing the tree now. I used the attach config. Please check them. My fix patcheds are the blew. Please comments. 1. build_ia64_add_files.patch simple import gate.S, gate.ld.S, patch.c into arch/ia64/kernel (these are from linux-2.6.18-rc2) 2. build_ia64.patch some fix (resend_irq, ioremap, and so on) Signed-off-by: Akio Takebe [EMAIL PROTECTED] 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] Hi, a question about 32bit OS running at xen-ia64
Hi, Tom Xen-ia64 support only ia64 OS. Xen-x86_64 can support both x86_64 OS and x86_32 OS. Best Regards, Akio Takebe hi,guys. I guess it may seem pretty much weird. I am not sure if 32bit OS such as 32bit Red Hat Linux distribution can run at xen-ia64? I really appreciate any suggestion, thanks a million. Tom ---text/plain--- ___ 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
[Xen-ia64-devel] Fedora-xen-ia64 test status
Hi, Aron, Juan, all We could not boot dom0 with kernel-xen-2.6.17-1.2488.fc6 on Tiger4. So I and Kouya debuged it, and found kernel text area is cleared. Isuku make a patch which resolve the issue. And I tested booting dom0 with Isuku's patch. So My test results is below. I used the below as dom0 kernel http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora ＋kernel-2.6.17-ia64-xen.config＋rsvd_region.patch And I used the latest xen-ia64-unstable.hg and xen-unstable. With the dom0 and the xen, I can boot dom0. Then I research the recently cset, I found the following mismatch. http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora have vDSO linux-2.6- saparse changes, but Hypervisor don't have the changes. changeset: 10703:8d501f39286c user:[EMAIL PROTECTED] date:Mon Jul 24 13:43:35 2006 -0600 summary: [IA64] vDSO paravirtualization: paravirtualize vDSO changeset: 10702:614deef19299 user:[EMAIL PROTECTED] date:Mon Jul 24 13:04:40 2006 -0600 summary: [IA64] vDSO paravirtualization: import linux files I think we need to update Hypervisor. Is this possible? Best Regards, Akio Takebe rsvd_region.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Fedora-xen-ia64 test status
Hi, Dave and Xen people Do we need CONFIG_DEBUG_SPINLOCK_SLEEP? Yes, because it highlights bugs like the above. If we need CONFIG_DEBUG_SPINLOCK_SLEEP, we must modify __might_sleep(). No, you must fix ia64 so that it doesn't call down_read with interrupts disabled. OK, but I think this is not bug. I thik this messages are caused by domain scheduler of Xen. Time slice of domain schedule is longer than HZ. (probably) Am I right, xen people? Please comments. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Why do you set xen's driver m?
Hi, Juan Thank you for your comments. I can boot domU with the following modprobe.conf. alias scsi_hostadapter xenblk But I have some ide errors. After I add extra = 'ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe' into domU's config, ide errors are not occurred. (Thanks Kouya) Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Why do you set xen's driver m?
On Fri, 2006-08-04 at 13:36 +0900, Akio Takebe wrote: Hi, Juan Thank you for your comments. I can boot domU with the following modprobe.conf. alias scsi_hostadapter xenblk But I have some ide errors. After I add extra = 'ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe' into domU's config, ide errors are not occurred. I don't get them. Could you post a log, and I will add that ide line to the kernel rpm :p Later, Juan. Hi, Juan The below is the boot log w/o ideX=noprobe. [EMAIL PROTECTED] linux-2.6-xen-fedora.0802]# xm create /xen/conf/domU.conf -c Using config file /xen/conf/domU.conf. Started domain paravm1 Dentry cache hash table entries: 65536 (order: 5, 524288 bytes) Inode-cache hash table entries: 32768 (order: 4, 262144 bytes) Software IO TLB disabled Memory: 240640k/393216k available (5832k code, 152368k reserved, 4032k data, 272k init) McKinley Errata 9 workaround not needed; disabling it register RESCHEDULE_VECTOR (RESCHED0) to xen irq (256) register IPI_VECTOR (IPI0) to xen irq (257) Percpu irq 238 is unsupported by xen! register VIRQ_ITC (timer0) to xen irq (258) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 1024 ACPI: Core revision 20060707 Boot processor id 0x0/0x0 SMP mode deactivated. Brought up 1 CPUs Total of 1 processors activated (2236.41 BogoMIPS). migration_cost=0 checking if image is initramfs... it is Freeing initrd memory: 6416kB freed DMI not present or invalid. grant table at e100 Grant table initialized NET: Registered protocol family 16 ACPI: bus type pci registered Brought up 1 CPUs ACPI: SCI (ACPI GSI 0) not registered ACPI: Interpreter enabled ACPI: Using IOSAPIC for interrupt routing Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 0 devices xen_mem: Initialising balloon driver. usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 1, 32768 bytes) TCP established hash table entries: 16384 (order: 5, 524288 bytes) TCP bind hash table entries: 8192 (order: 4, 262144 bytes) TCP: Hash tables configured (established 16384 bind 8192) TCP reno registered perfmon: version 2.0 IRQ 238 perfmon: Itanium 2 PMU detected, 16 PMCs, 18 PMDs, 4 counters (47 bits) PAL Information Facility v0.5 perfmon: added sampling format default_format perfmon_default_smpl: default_format v2.0 registered audit: initializing netlink socket (disabled) audit(1154659468.196:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 2048 (order 0, 16384 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x1 ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] ACPI: Getting cpuindex for acpiid 0x2 EFI Time Services Driver v0.4 Linux agpgart interface v0.101 (c) Dave Jones RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize Xen virtual console successfully installed as tty1 Event-channel device installed. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx hda: probing with STATUS(0xa1) instead of ALTSTATUS(0x08) hda: IRQ probe failed (0xfffe) hda: probing with STATUS(0xa1) instead of ALTSTATUS(0x08) hda: IRQ probe failed (0xfffe) hda: no response (status = 0xa1), resetting drive hda: IRQ probe failed (0xfffe) hdb: probing with STATUS(0xa1) instead of ALTSTATUS(0x08) hdb: IRQ probe failed (0xfffe) hdb: probing with STATUS(0xa1) instead of ALTSTATUS(0x08) hdb: IRQ probe failed (0xfffe) hdb: no response (status = 0xa1), resetting drive hdb: IRQ probe failed (0xfffe) hdc: probing with STATUS(0xa1) instead of ALTSTATUS(0x08) hdc: IRQ probe failed
[Patch] fix vDSO paravirtualization for fedora-xen-ia64 (is Re: [Fedora-xen] Re: [Xen-ia64-devel] Fedora-xen-ia64 test status)
Hi, The following error messages are occurred by a bug of vDSO paravirtualization. (Thanks, Isaku.) This fix of Isaku has been commited in xen-ia64-unstable, but has not been commited in xen-unstable yet. So this patch need to is commit to fedora-kernel util fedora-kernel catch up with current xen-ia64-unstable. BUG: sleeping function called from invalid context at kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 Call Trace: [a0010001c7a0] show_stack+0x40/0xa0 sp=e0002f7dfbb0 bsp=e0002f7d91a8 [a0010001c830] dump_stack+0x30/0x60 sp=e0002f7dfd80 bsp=e0002f7d9190 [a0010006c920] __might_sleep+0x2a0/0x2c0 sp=e0002f7dfd80 bsp=e0002f7d9168 [a001000bce80] down_read+0x20/0x60 sp=e0002f7dfd80 bsp=e0002f7d9148 [a001005b14f0] ia64_do_page_fault+0x110/0x9e0 sp=e0002f7dfd80 bsp=e0002f7d90f8 [a00100064be0] xen_leave_kernel+0x0/0x3b0 sp=e0002f7dfe30 bsp=e0002f7d90f8 The below is F.Y.I. http://lists.xensource.com/archives/html/xen-ia64-devel/2006-08/msg00042.html Best Regards, Akio Takebe fix_vdso_paravirtualization.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen with fedora kernel 2.6.18
Hi, Jan A machine you build seems like a x86_64 machine. I have not try to build fedora-kernel on x86_64 yet. (I have build fedora-kernel on ia64.) You can ask it in ML of xen-devel. Best Regards, Akio Takebe I ubuntu edgy with gcc 4.1 When i want compile the kernel: I got this message: CHK include/linux/compile.h CC arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.o arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.c: In function ‘pci_iommu_alloc’: arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.c:60: error: implicit declaration of function ‘detect_calgary?make[1]: *** [arch/x86_64/kernel/. ./../i386/kernel/pci-dma-xen.o] Fehler 1 ___ 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
[Xen-ia64-devel] [BUGREPORT] Panic dom0 by using module netbk.ko
=a0010070f700 bsp=a00100709598 [a0010001c950] dump_stack+0x30/0x60 sp=a0010070f8d0 bsp=a00100709580 [a00100069340] __might_sleep+0x2a0/0x2c0 sp=a0010070f8d0 bsp=a00100709558 [a001000b75a0] down_read+0x20/0x60 sp=a0010070f8d0 bsp=a00100709538 [a001000a0980] blocking_notifier_call_chain+0x20/0x80 sp=a0010070f8d0 bsp=a00100709500 [a0010007ee50] profile_task_exit+0x30/0x60 sp=a0010070f8d0 bsp=a001007094e0 [a00100082f00] do_exit+0x40/0x1460 sp=a0010070f8d0 bsp=a00100709488 [a0010003d300] die+0x280/0x2a0 sp=a0010070f8f0 bsp=a00100709440 [a0010003d370] die_if_kernel+0x50/0x80 sp=a0010070f910 bsp=a00100709410 [a001005be890] ia64_bad_break+0x270/0x4a0 sp=a0010070f910 bsp=a001007093e0 [a001000615e0] xen_leave_kernel+0x0/0x3b0 sp=a0010070f9c0 bsp=a001007093e0 [a00200865ad0] net_tx_action+0xd50/0x1ae0 [netbk] sp=a0010070fb90 bsp=a00100709340 [a0010008ade0] tasklet_action+0x320/0x5e0 sp=a0010070fbb0 bsp=a00100709318 [a00100089bd0] __do_softirq+0x1f0/0x3a0 sp=a0010070fbb0 bsp=a001007092a0 [a00100089ec0] do_softirq+0x140/0x2a0 sp=a0010070fbb0 bsp=a00100709240 [a0010008a0a0] irq_exit+0x80/0xa0 sp=a0010070fbb0 bsp=a00100709228 [a001003a1670] evtchn_do_upcall+0x170/0x260 sp=a0010070fbb0 bsp=a00100709190 [a001000615e0] xen_leave_kernel+0x0/0x3b0 sp=a0010070fbb0 bsp=a00100709190 [a00100061d30] xen_pal_call_static+0xd0/0x100 sp=a0010070fd80 bsp=a00100709140 [a0010001d830] default_idle+0x190/0x260 sp=a0010070fd80 bsp=a00100709120 [a0010001c3f0] cpu_idle+0x1f0/0x440 sp=a0010070fe20 bsp=a001007090e0 [a00100011fc0] rest_init+0x60/0x80 sp=a0010070fe20 bsp=a001007090c8 [a001006c13c0] start_kernel+0x880/0x8a0 sp=a0010070fe20 bsp=a00100709068 [a001000105f0] __end_ivt_text+0x6d0/0x6f0 sp=a0010070fe30 bsp=a00100709060 Kernel panic - not syncing: Aiee, killing interrupt handler! Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Add EXPORT_SYMBOL to modularize netback
Hi, This patch add EXPORT_SYMBOL to modularize netback. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe export_symbol.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Add EXPORT_SYMBOL to modularize netback
Hi, I'm sorry. I add EXPORT_SYMBOL(xen_start_info) into my patch. xen_start_info is used by netfront and so on. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe Hi, This patch add EXPORT_SYMBOL to modularize netback. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Best Regards, Akio Takebe ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel export_symbol.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH RFC] fix noreboot behaviour on clean reboot(was: intended behaviour of noreboot)
Hi, I tested Muil's patch on ia64. The below is test results. - Before patch reboot reboot halt reboot panic reboot - After patch reboot reboot halt reboot panic reboot This results is caused by calling EFI_RESET_SHUTDOWN in ia64's machine_halt(). Ia64's machine_halt require system reboot because EFI_RESET_SHUTDOWN (used by ia64's machine_halt()) enter ACPI G2/S5 or G3 state. This is ia64 issue, I think Muli's patch is good. :-) Best Regards, Akio Takebe On Mon, Aug 07, 2006 at 08:17:44AM +0100, Keir Fraser wrote: On 6/8/06 7:50 am, Muli Ben-Yehuda [EMAIL PROTECTED] wrote: Setting 'noreboot' on the Xen command line stops reboot(1) from working in dom0. Is this the intended behaviour? I would expect noreboot to only apply to reboots that are trigerred as a result of kernel panis or oopses. Clean shutdown of domain0 could clear the noreboot flag in Xen. Itt's a bit too hacky that machine_restart() either restarts or halts, depends on opt_noreboot. How about something like this: - move code specific to dom0 out of domain_shutdown() into dom0_shutdown() - dom0_shutdown() has the following semantics: if reason is SHUTDOWN_poweroff: halt if reason is SHUTDOWN_crash: halt if opt_noreboot is set, reboot otherwise. if reason is SHUTDOWN_reboot: reboot (regardless of noreboot) if reason is anything else: halt if opt_noreboot is set, reboot otherwise (preserve backward compatible behaviour). - I checked and PV Linux i386/x86-64 uses SHUTDOWN_crash/SHUTDOWN_reboot appropriately to give the above semantics. - since opt_noreboot is now referenced in common code, add definitions for it for ia64 and ppc as well. Hooking it in in arch code is simple - just parse the command line options and set opt_noreboot appropriately. Tested on x86-64, comments appreciated! Cheers, Muli ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [BUGREPORT] Panic dom0 by using modulenetbk.ko
Hi, Alex and Al Thank you for your suggestion. I report Bugzilla, too. We research this issue. We look like this issue caused by fail of copy_from/to_guest. Best Regards, Akio Takebe On Mon, 2006-08-07 at 12:35 -0600, Al Stone wrote: This is a question to the list in general, as much as it is a response to this bug report: would it not make more sense to start filing bug reports using the bugzilla site already set up [1]? I do appreciate seeing these reports here -- even if I'm not sure what is causing the problem -- but I tend to loose them in my mailbox after a while. If nothing else, regular use of bugzilla will allow us to get a better feel for the quality of the ia64 work (which is, of course, awesome :). I agree, Kevin, Yongkang and I talked about this at OLS, but I haven't had a chance to actually implement anything. Given where we are in development, I think sending bug reports to the mailing list is an effective way of getting it in front of people that can fix problems. However, when a problem doesn't get resolution on the mailing list, we should definitely start tracking things in bugzilla. It's certainly reasonable that these can be done in parallel too. 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
[Xen-ia64-devel] Re: [Fedora-ia64-list] Some testing result about Xen in FC6-test2
Hi, Xiantao and all
It's not known exactly why, but this problem is occured
by making wrong elf header of gate.so.
The following patch fix this issue.
But this problem is not related to xen code, is related to linux code.
I look like this problem is fixed in linux-2.6.18-rc4.
So I think fedora-xen workers don't worry about this issue.
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r d42e9a6f5378 linux-2.6-xen-sparse/arch/ia64/kernel/gate.lds.S
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/gate.lds.S Fri Aug 18 15:01:04
2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/gate.lds.S Thu Aug 24 06:01:30
2006 +0900
@@ -13,6 +13,7 @@ SECTIONS
. = GATE_ADDR + SIZEOF_HEADERS;
.hash: { *(.hash) }
:readable
+ .gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
diff -r d42e9a6f5378 tools/ioemu/usb-linux.c
--- a/tools/ioemu/usb-linux.c Fri Aug 18 15:01:04 2006 -0600
+++ b/tools/ioemu/usb-linux.c Thu Aug 24 06:01:30 2006 +0900
@@ -26,7 +26,6 @@
#if defined(__linux__)
#include dirent.h
#include sys/ioctl.h
-#include linux/compiler.h
#include linux/usbdevice_fs.h
#include linux/version.h
--- linux-2.6.16.13-xen/arch/ia64/kernel/Makefile.orig 2006-05-03
06:38:44.0 +0900
+++ linux-2.6.16.13-xen/arch/ia64/kernel/Makefile 2006-08-24
05:51:10.0 +0900
@@ -44,7 +44,8 @@ CPPFLAGS_gate.lds := -P -C -U$(ARCH)
quiet_cmd_gate = GATE $@
cmd_gate = $(CC) -nostdlib $(GATECFLAGS_$(@F)) -Wl,-T,$(filter-out
FORCE,$^) -o $@
-GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1
+GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1 \
+ $(call ld-option, -Wl$(comma)--hash-style=sysv)
$(obj)/gate.so: $(obj)/gate.lds $(obj)/gate.o FORCE
$(call if_changed,gate)
Best Regards,
Akio Takebe
Hi all,
I have installed FC6-test2 in a Tiger4 (I just tried NFS installation from
local monitor, it is okay).
As its original Xen RPM couldn't bring up Tiger4 (I have reported last time
.), I tried the other 2 ways to test Xen.
Way1, use FC6-test2 to build xen-ia64 unstable source/make/install
The changeset is 11031 (xen-ia64 unstable tree), kernel is 2.6.16.13.
Didn't meet issue in build and installation. But I couldn't boot up
Xen0,
because Xen0 kept rebooting. Please see the attachment for the serial port
log. Is it a compiler issue?
Way2, use RHEL4u3 to build xen-ia64 unstable source/install/testing
This time, I used RHEL4u3 to build Xen. The source is same with way1.
Then, I installed the built out xen into FC6-test2 and its booting is
okay.
XenU and VTI domain can be created successfully.
Best Regards,
Yongkang (Kangkang) モタソオ
---text/plain---
--
Fedora-ia64-list mailing list
[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/fedora-ia64-list
elf.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-ia64-list] Some testing result about Xen in FC6-test2
Hi, Hi, Xiantao and all Oops. I'm mistake, I wanted to write Hi, YongKang. I'm sorry to Xiantao and YongKang. It's not known exactly why, but this problem is occured by making wrong elf header of gate.so. The following patch fix this issue. But this problem is not related to xen code, is related to linux code. I look like this problem is fixed in linux-2.6.18-rc4. So I think fedora-xen workers don't worry about this issue. The below is F.Y.I. http://lkml.org/lkml/2006/7/26/262 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [FYI] FC6 kernel and latest xen
Hi, I tried to boot dom0/domU with netfront/netback module. I can boot up dom0/domU with Kouya's patch. My environment is; - dom0/domU kernel http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora cset #35247 - xen tools http://xenbits.xensource.com/ext/xen-ia64-unstable.hg cset #11048 - Machine Tiger4 But I have many error message. [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-ia64-list] [FYI] FC6 kernel and latest xen
Hi, Prarit I enter BZ. Bugzilla Bug 204011: kernel unaligned access Best Regards, Akio Takebe Akio Takebe wrote: [EMAIL PROTECTED] ~]# kernel unaligned access to 0xe000187a4e1e, ip= 0xa001004fad50 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fae21 Akio, these are caused by the kernel making unaligned accesses to memory. Please enter a BZ against these and we'll try to track them down. P. kernel unaligned access to 0xe000187a4e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a4e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a4e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xe0001662921e, ip=0xa001004fad50 kernel unaligned access to 0xe0001662921e, ip=0xa001004fae21 kernel unaligned access to 0xe0001662921e, ip=0xa001004faed0 kernel unaligned access to 0xe0001662922e, ip=0xa001004fb130 kernel unaligned access to 0xe0001662921e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a5e2e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a5e1e, ip=0xa001004fb2e0 kernel unaligned access to 0xedf1a61e, ip=0xa001004fad50 kernel unaligned access to 0xedf1a61e, ip=0xa001004fae21 kernel unaligned access to 0xedf1a61e, ip=0xa001004faed0 kernel unaligned access to 0xedf1a62e, ip=0xa001004fb130 kernel unaligned access to 0xedf1a61e, ip=0xa001004fb2e0 kernel unaligned access to 0xe000187a501e, ip=0xa001004fad50 kernel unaligned access to 0xe000187a501e, ip=0xa001004fae21 kernel unaligned access to 0xe000187a501e, ip=0xa001004faed0 kernel unaligned access to 0xe000187a502e, ip=0xa001004fb130 kernel unaligned access to 0xe000187a501e, ip=0xa001004fb2e0 Best Regards, Akio Takebe -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list -- Fedora-ia64-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/fedora-ia64-list ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms and Magnus Good work. :-) I have one commet. I believe crash_kexec should be directly called when unknown NMI is occurred. In your patch, crash_kexec is called as the bellow. 1. unknown NMI is occurred. (e.g. by pushing NMI botton) 2. xen recieved NMI and call do_nmi. 3. xen report to dom0 by using raise_softirq(NMI_SOFTIRQ). 4. dom0 call crash_kexec of dom0. 5. crash_kexec of dom0 call crash_kexec of xen Am I correct? The above process is not reliable if I'm correct. So I belive crash_kexec of xen should be directly called like the following patch. diff -r 9611a5c9e1a1 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Thu Aug 31 13:12:26 2006 +0900 +++ b/xen/arch/x86/traps.c Thu Aug 31 17:40:19 2006 +0900 @@ -1612,6 +1612,7 @@ asmlinkage void do_nmi(struct cpu_user_r else if ( reason 0x40 ) io_check_error(regs); else if ( !nmi_watchdog ) +crash_kexec(NULL); unknown_nmi_error((unsigned char)(reason0xff)); } } What do you think about it? Best Regards, Akio Takebe Hi, here is an update of the kexec/kdump patchset. Summary: * Up port to xen-unstable.hg-11296 (45f6ee334fcc) - kexec hypercall number fragment is now in xen-unstable * Make kexec_page_to_pfn and friends need to be architecture specific - this abstraction is needed to support ia64 * Use kexec_page_to_pfn in machine_kexec_setup_load_arg() - this abstraction is needed to support ia64 * Rename do_kexec to do_kexec_op to make it consistent with other hypercalls * Add ppc stubs * Add ia64 support Architectures: x86_32: Seems to be working fine x86_64: Probably working fine, but I can't test this as dom0 refuses to boot for me on xen-unstable-11388 (50aea0ec406b). That is, even without the kexec patches. I'm not sure what the problem is and I've devicided to get these patches out rather and investigate later. ia64: This patchset also, for the first time, includes ia64 code. Please note that this currently does _not_ work. I am actually struggling to work out why, and would really appreaciate it if someone could cast an eye over it. One possible area of concern is that relocate_kernel wipes out TLB entries. However many of the entries instated in arch/ia64/xen/xenasm.S:ia64_new_rr7() are not wiped. In particular, VHPT_ADDR, Shared info, and Map mapped_reg are not handled by relocate_kernel(), and the handling of current seems to be different. There are also problems with constants inside kexec_fake_sal_rendez. However this function probably also suffers the same problems as relocate_kernel. And it is easy not ro run kexec_fake_sal_rendez by booting xen with maxcpus=1, thus avoiding calling kexec_fake_sal_rendez, which is used in cpu shutdown. ppc: stubs only Patches 1. 51.1-kexec-generic-upstream.patch * Common code for all architectures, the basic plumbing for kexec/kdump 2. 51.1.1-kexec-trigger_crash_dump.patch * xen-console trigger crash_dump * Depends on 1 3. 51.2.1-kexec-x86-upstream.patch * Glue between 1, and 3 and 4. * Depends on 1 4. 51.2.1.1-kexec-x86_32-upstream.patch * Kexec/kdump for x86_32 * Depends on 3 (and 1) 5. 51.2.31.2-kexec-x86_64-upstream.patch * Kexec/kdump for x86_64 * Depends on 3 (and 1) 6. 51.2.2-kexec-ia64-upstream.patch * Kexec/kdump for ia64 * Depends 1 Discussion: Email is always good. Also my partner in crime, Magnus Damm, will be at Xen Summit. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] fix buildconfigs of domU
Hi, I fix buildconfigs of domU. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Yoshiro Fujita [EMAIL PROTECTED] Best Regards, Akio Takebe domU_config.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
