RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi Akio, Sorry for response late. I just tried with the config you provide (I changed xenU modprobe.conf and fstab). But unfortunately it still couldn't work. XenU booting still report can not find filesystem /dev/root/ and kernel panic. Well, after add ide0=noprobe etc. xenU won't complain to check hda, hdb etc. again. Thanks for this information. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年9月21日 10:18 To: Akio Takebe; You, Yongkang; Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,hda1,w' ] root = /dev/hda1 ro extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe this Best Regards, Akio Takebe Hi, I have reported 2 bugs to redhat bugzilla: [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I also notice FC6-test3 Xen0 operation is a little slower, compared with RHEL4u3. I assign 2 vcpus to Xen0. When I destroy domains or do some heavy IO operations, Xen0 operations will be blocked for a while. I didn't track this to bugzilla. There are also a lot of unaligned accessing from some applications. They should be common FC6-test3 issues. Sometime Xen0 monitor will print Bug: soft lockup detected on CPU#0(or #1) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006トsヤツ20ネユ 10:07 To: Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi Fred Yoshi, The former XenU creating failure issue seemed to be the config issue. Now I can create XenU. But XenU booting process met an old bug. It will cost a long time to check hard disk IRQ response from hda to hdh. After that, xenU met the problem of mounting root partition to start services, and then XenU booting failed (Kill init). I am not sure if it is because initrd issue. I will continue to check it. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006トsヤツ20ネユ 8:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Here it comes! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 4:23 PM To: Yang, Fred; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Fred, Yongkang, Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. I can't find the attachment. Could you repost the serial log? Thanks, Yoshi Oguchi Yang, Fred [EMAIL PROTECTED] wrote」コ Following is the quick Xen test result with FC6 Test3. We will file BZ for the issues tonight; the early data is to get community to fix Xen issues ASAP Thanks, -Fred I have followed Redhat instructions (FC6-test3 can not be installed from CDs) to install FC6-Test3 and do some testing. Both Xen0 and VTI can all boot up, but XenU couldn't be created successfully. Detailed Items: 1. Using yum to upgrade FC6 Test2 to FC6 Test3[almost Pass] need manually reinstall kernel-xen rpm package. 2. Boot Native Linux of FC6 Test3 [Pass] 3. Boot Xen of FC6 Test3 [Pass] 4. xend and xm commands are working.[Pass] 5. XenU Domain creating failed.
Re: [Xen-ia64-devel] pickled code
Isaku Yamahata wrote: Hi Jes. It tries to keep struct page_info compact layout by avoiding padding before _domain member. Please notice u32 count_info member in front of _domain. struct domain is allocated from xen heap, i.e. the range [PAGE_OFFSET, PAGE_OFFSET + 64MB). It means that struct domain* can be expressed as PAGE_OFFSET + 32bit offset(=machine phsyiacal address). pickle PAGE_OFFSET + 32bit offset = 32 bit offset i.e. discarding most significant 32bit. It can be don by casting u64 to u32 because Xen assumes little endian. Hi Isaku The problem is that the theory that one can discard the top 32 bit from the physical address is flawed. Some machines, like SN2 have a memory layout which makes this impossible to do. Ie. our physical memory starts at 0x300300 (think I got the zeros right), there is no memory at all below 4GB. I am not sure how to solve this correctly, and I understand that my patch broke the kernel for Masaki too, but the existing code is broken by design, so we need to try and come up with something else - maybe we can do a pickle function based on a dynamic mask, ie. not use PAGE_OFFSET, but rather xen_heap_base or something like that? Best regards, Jes ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [IPF-stress] Stress test result in VTI domain, Cset 11456
Hi all, I did stress tests in the VTI domain in Cset11456. The steps are: 1. Set the xen0 by using dom0_max_vcpus=2 and dom0_vcpus_pin in the elilo.conf. 2. Create two SMP_VTI (with 3 vcpus each); 3. Manually use xm vcpu-pin to bind the domains' vcpus. Then run the stress test on both domains. The test results are: --- Env: LP number: 8 (xen0:2, domain1:3, domain2:3) Xen0: SMP (with 2 vcpus, and pin) Sched: credit Casetime (hours)pass/fail Crashme 18 pass Helltest18 fail in the first hour CVworkloads 12 pass --- Thanks, Zhangjingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH]Instruction emualtion patch
This is the first patch sent from me. This patch fixes the instruction emulation issue, e.g. when executing such instruction ld.1 r31=[r32], the loaded value should be zero extended and placed in r31, but more than lowest 8 bits of r31 are set. emulate_io_inst.patch Signed-off-by: xinmei.huang [EMAIL PROTECTED] emulate_io_inst.patch Description: emulate_io_inst.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pickled code
On Thu, Sep 21, 2006 at 08:42:29AM +0200, Jes Sorensen wrote: I am not sure how to solve this correctly, and I understand that my patch broke the kernel for Masaki too, but the existing code is broken by design, so we need to try and come up with something else - maybe we can do a pickle function based on a dynamic mask, ie. not use PAGE_OFFSET, but rather xen_heap_base or something like that? I agree that The current design is broken. It comes from Xen/x86 and must be adjusted to IA64. Value based on xen_pstart, xenheap_phys_end or heap_start in start_kernel() can be used for that. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pickled code
Isaku Yamahata wrote:
I agree that The current design is broken.
It comes from Xen/x86 and must be adjusted to IA64.
Value based on xen_pstart, xenheap_phys_end or
heap_start in start_kernel() can be used for that.
Hi Isaku,
How does this look to you then? I get as far with this patch as I got
with the previous one I sent out, so thats a good sign :) Without any of
the patches I get an MCA as soon as I start touching the mpt_table.
Cheers,
Jes
Do the pickling based on xen_heap_start, rather than __va/__pa. The
__va/__pa approach doesn't work as some systems do not have their heap
located within the 4GB window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/xensetup.c Thu Sep 21 10:47:20 2006 +0200
@@ -85,6 +87,7 @@ unsigned long xenheap_size = XENHEAP_DEF
unsigned long xenheap_size = XENHEAP_DEFAULT_SIZE;
extern long running_on_sim;
unsigned long xen_pstart;
+void *xen_heap_start;
static int
xen_count_pages(u64 start, u64 end, void *arg)
@@ -246,7 +249,6 @@ void start_kernel(void)
void start_kernel(void)
{
char *cmdline;
-void *heap_start;
unsigned long nr_pages;
unsigned long dom0_memory_start, dom0_memory_size;
unsigned long dom0_initrd_start, dom0_initrd_size;
@@ -393,10 +398,10 @@ void start_kernel(void)
printf(find_memory: efi_memmap_walk returns max_page=%lx\n,max_page);
efi_print();
-heap_start = memguard_init(ia64_imva(_end));
-printf(Before heap_start: %p\n, heap_start);
-heap_start = __va(init_boot_allocator(__pa(heap_start)));
-printf(After heap_start: %p\n, heap_start);
+xen_heap_start = memguard_init(ia64_imva(_end));
+printf(Before xen_heap_start: %p\n, xen_heap_start);
+xen_heap_start = __va(init_boot_allocator(__pa(xen_heap_start)));
+printf(After xen_heap_start: %p\n, xen_heap_start);
efi_memmap_walk(filter_rsvd_memory, init_boot_pages);
efi_memmap_walk(xen_count_pages, nr_pages);
@@ -414,10 +419,10 @@ void start_kernel(void)
end_boot_allocator();
-init_xenheap_pages(__pa(heap_start), xenheap_phys_end);
+init_xenheap_pages(__pa(xen_heap_start), xenheap_phys_end);
printk(Xen heap: %luMB (%lukB)\n,
- (xenheap_phys_end-__pa(heap_start)) 20,
- (xenheap_phys_end-__pa(heap_start)) 10);
+ (xenheap_phys_end-__pa(xen_heap_start)) 20,
+ (xenheap_phys_end-__pa(xen_heap_start)) 10);
late_setup_arch(cmdline);
diff -r 3e4fa8b5b245 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/include/asm-ia64/mm.h Thu Sep 21 10:42:04 2006 +0200
@@ -125,10 +125,14 @@ struct page_info
#define IS_XEN_HEAP_FRAME(_pfn) ((page_to_maddr(_pfn) xenheap_phys_end) \
(page_to_maddr(_pfn) = xen_pstart))
-static inline struct domain *unpickle_domptr(u32 _d)
-{ return (_d == 0) ? NULL : __va(_d); }
+extern void *xen_heap_start;
+#define __pickle(a)((unsigned long)a - (unsigned long)xen_heap_start)
+#define __unpickle(a) (void *)(a + xen_heap_start)
+
+static inline struct domain *unpickle_domptr(u64 _d)
+{ return (_d == 0) ? NULL : __unpickle(_d); }
static inline u32 pickle_domptr(struct domain *_d)
-{ return (_d == NULL) ? 0 : (u32)__pa(_d); }
+{ return (_d == NULL) ? 0 : (u64)__pickle(_d); }
#define page_get_owner(_p) (unpickle_domptr((_p)-u.inuse._domain))
#define page_set_owner(_p, _d) ((_p)-u.inuse._domain = pickle_domptr(_d))
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] alloc_page_dir() should return a virtual address
Hi,
I sent this patch to Alex last week, but it didn't make it onto the list
because it's wrongly configured, so here we go again.
I know that this patch is causing problems on ZX1, but I have looked at
it over and over again and I feel pretty certain it is correct. In fact
I cannot understand that Xen could boot on any ia64 platform prior to
this at all.
I would be very interested in hearing how this patch affects other
platforms such as DIG and Fujitsu's machines (if they are not DIG :)
Any input or comments on this is most welcome - if you think I am wrong
about this patch, please tell me, I really want to understand why this
worked in the past.
Thanks,
Jes
alloc_dir_page() must return a virtual address so it can handle being
passed to the p*d_populate() functions which do a __pa() on the address
before sticking them into the page tables.
To match this it is also necessary to correctly check the faulting
address for being in the virtual frame table range, otherwise page
faults for this space weren't being served at all.
This could probably be done more efficiently, but for now I think it's
better to keep the code explicit.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/ivt.S
--- a/xen/arch/ia64/xen/ivt.S Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/ivt.S Wed Sep 20 14:56:37 2006 +0200
@@ -542,8 +542,16 @@ late_alt_dtlb_miss:
;;
#ifdef CONFIG_VIRTUAL_FRAME_TABLE
shr r22=r16,56 // Test for the address of virtual frame_table
+#if 1
+ mov r23=VIRT_FRAME_TABLE_ADDR56
+ ;;
+ xor r23=r22,r23
+ ;;
+ cmp.eq p8,p0=r23,r0
+#else
;;
cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22
+#endif
(p8) br.cond.sptk frametable_miss ;;
#endif
// If it is not a Xen address, handle it via page_fault.
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/xenmem.c
--- a/xen/arch/ia64/xen/xenmem.cTue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/xenmem.cWed Sep 20 17:14:01 2006 +0200
@@ -76,13 +76,13 @@ alloc_dir_page(void)
alloc_dir_page(void)
{
unsigned long mfn = alloc_boot_pages(1, 1);
- unsigned long dir;
+ unsigned char *virtual;
if (!mfn)
panic(Not enough memory for virtual frame table!\n);
++table_size;
- dir = mfn PAGE_SHIFT;
- memset(__va(dir), 0, PAGE_SIZE);
- return (void *)dir;
+ virtual = __va(mfn PAGE_SHIFT);
+ memset(virtual, 0, PAGE_SIZE);
+ return virtual;
}
static inline unsigned long
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch] alloc_page_dir() should return a virtual address
Kouya SHIMURA wrote:
Hi Jes,
I wrote the patch corresponding to discontig. You are wrong.
alloc_dir_page() must return a physical address because the page table
walker for frame_table runs under off-state of data-address-translation.
(i.e. psr.dt=0)
p*d_populate() functions never be called while handling TLB miss to
frame_table. The page table walker for frame_table is written in
assembler in xen/arch/ia64/xen/ivt.S. See the code between
'GLOBAL_ENTRY(frametable_miss)' and 'END(frametable_miss)'
Hi Kouya,
I am not talking about during the TLB miss but during the creation
of the tables. I changed the code in ivt.S to make sure what was
happening was explicit, ie. if we are trying to resolve things in the
VIRT_FRAME_TABLE_ADDR space, then the test I put into ivt.S should be
identical to your original code, but I cannot boot with your code, it
MCA's because frametable_miss is never called since we are comparing for
the wrong address.
Please take a look at this code:
arch/ia64/xen/xenmem.c:
static int
create_frametable_page_table (u64 start, u64 end, void *arg)
{
...
[snip]
...
if (pud_none(*pud))
pud_populate(NULL, pud, alloc_dir_page());
pmd = pmd_offset(pud, address);
if (pmd_none(*pmd))
pmd_populate_kernel(NULL, pmd,
alloc_dir_page());
pte = pte_offset_kernel(pmd, address);
Then in include/asm-ia64/linux-xen/asm/pgalloc.h you have this:
static inline void
pud_populate(struct mm_struct *mm, pud_t * pud_entry, pmd_t * pmd)
{
pud_val(*pud_entry) = __pa(pmd);
}
and
static inline void
pmd_populate_kernel(struct mm_struct *mm, pmd_t * pmd_entry, pte_t * pte)
{
pmd_val(*pmd_entry) = __pa(pte);
}
In other words, if alloc_dir_page() returns a physical address as it
did before, you end up doing __pa() on the physical address which
just cannot be correct.
My guess is that we were in fact doing a __pa() on the physical address
and the compare in ivt.S somehow was made to look at this address
instead of what it was pretending to do.
I'd like to be proven wrong though, but without this patch Xen on SN2
only gets to an MCA at the moment it tries to initialize the page table.
You'd better have a look at the thread below:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-04/msg00014.html
I'll take a look.
Cheers,
Jes
Thanks,
Kouya
Jes Sorensen writes:
Hi,
I sent this patch to Alex last week, but it didn't make it onto the list
because it's wrongly configured, so here we go again.
I know that this patch is causing problems on ZX1, but I have looked at
it over and over again and I feel pretty certain it is correct. In fact
I cannot understand that Xen could boot on any ia64 platform prior to
this at all.
I would be very interested in hearing how this patch affects other
platforms such as DIG and Fujitsu's machines (if they are not DIG :)
Any input or comments on this is most welcome - if you think I am wrong
about this patch, please tell me, I really want to understand why this
worked in the past.
Thanks,
Jes
alloc_dir_page() must return a virtual address so it can handle being
passed to the p*d_populate() functions which do a __pa() on the address
before sticking them into the page tables.
To match this it is also necessary to correctly check the faulting
address for being in the virtual frame table range, otherwise page
faults for this space weren't being served at all.
This could probably be done more efficiently, but for now I think it's
better to keep the code explicit.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/ivt.S
--- a/xen/arch/ia64/xen/ivt.S Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/ivt.S Wed Sep 20 14:56:37 2006 +0200
@@ -542,8 +542,16 @@ late_alt_dtlb_miss:
;;
#ifdef CONFIG_VIRTUAL_FRAME_TABLE
shr r22=r16,56 // Test for the address of virtual frame_table
+#if 1
+ mov r23=VIRT_FRAME_TABLE_ADDR56
+ ;;
+ xor r23=r22,r23
+ ;;
+ cmp.eq p8,p0=r23,r0
+#else
;;
cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22
+#endif
(p8) br.cond.sptk frametable_miss ;;
#endif
// If it is not a Xen address, handle it via page_fault.
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/xenmem.c
--- a/xen/arch/ia64/xen/xenmem.c Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/xenmem.c Wed Sep 20 17:14:01 2006 +0200
@@ -76,13 +76,13 @@ alloc_dir_page(void)
alloc_dir_page(void)
{
unsigned long mfn = alloc_boot_pages(1, 1);
- unsigned long dir;
+ unsigned char *virtual;
if (!mfn)
panic(Not enough memory for virtual frame table!\n);
++table_size;
- dir = mfn PAGE_SHIFT;
-
Re: [Xen-ia64-devel][PATCH]fix a bug about vhpi
On Wed, 2006-09-20 at 12:27 +0800, Xu, Anthony wrote: Fix a bug about vhpi Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Fix a bug about set_rse_reg
On Thu, 2006-09-21 at 12:16 +0800, Xu, Anthony wrote: When setting rse register, XEN needs to modify banking store memory. This operation can't be interrupted, otherwise contents of stack registers may be destroyed. BTW, after this patch, crashme can pass on SMP VTI-domain. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Instruction emualtion patch
On Thu, 2006-09-21 at 15:03 +0800, Huang, Xinmei wrote: This is the first patch sent from me. This patch fixes the instruction emulation issue, e.g. when executing such instruction ld.1 r31=[r32], the loaded value should be zero extended and placed in r31, but more than lowest 8 bits of r31 are set. Welcome to the list. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Cleanup for PV-on-HVM for IPF
Hi Alex, Please import xen-unstable.hg(cs:11464:3bff5c5b9206) for enabling PV-on-HVM for IPF. changeset: 11464:3bff5c5b9206 user:[EMAIL PROTECTED] date:Wed Sep 13 14:34:34 2006 +0100 summary: Fix unmodified drivers for PV-on-HVM on IA64. Thanks, - Tsunehisa ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Cleanup for PV-on-HVM for IPF
On Fri, 2006-09-22 at 08:29 +0900, [EMAIL PROTECTED] wrote: Hi Alex, Please import xen-unstable.hg(cs:11464:3bff5c5b9206) for enabling PV-on-HVM for IPF. changeset: 11464:3bff5c5b9206 I will as soon as Al's buildconfig patch gets accepted in xen-unstable to fix the autobuild failure. Thanks, Alex ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] blkbk/netbk modules fail to load on fedora xen/ia64
Presently the showstopper bug in Fedora Xen/ia64 is the failure of the blkbk/netbk modules to load. Akio Takebe and Kouya Shimura worked on a patch to fix this earlier (changeset bef360142b62), unfortunately it doesn't seem to have fixed the problem on the Fedora kernel. I filed the bug at RH: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 In that report, I suggest three options: (1) statically link the modules, (2) wait for xen-ia64-devel to finish xencomm, (3) debug the issue preventing the current drivers from loading. Regarding #1, I don't think RH will do it. Jeremy Katz has mentioned on the ML that Fedora is depending on the front/back-end drivers being compiled as modules. I'm looking forward to the completion of #2, but I think it would be wise to fix #3 if we can, especially since it might be easier. I have looked at it but I'm out of my depth. Would Kouya, Akio or somebody else mind trying to fix it? Note: I will have sporadic email contact starting tomorrow until Wednesday 9/27, so I may not respond until then. Thanks, Aron pgpuwYoPqkZwL.pgp Description: PGP signature ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Hi, Aron and all I can solve this problem by using dom0_mem=1G. FC6 test3 uses many daemons and services. Because booting xend is late, we fail insmod blk/netbk if dom0_mem=512M(default size). We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) Please give me some comments. Best Regards, Akio Takebe Presently the showstopper bug in Fedora Xen/ia64 is the failure of the blkbk/netbk modules to load. Akio Takebe and Kouya Shimura worked on a patch to fix this earlier (changeset bef360142b62), unfortunately it doesn't seem to have fixed the problem on the Fedora kernel. I filed the bug at RH: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202971 In that report, I suggest three options: (1) statically link the modules, (2) wait for xen-ia64-devel to finish xencomm, (3) debug the issue preventing the current drivers from loading. Regarding #1, I don't think RH will do it. Jeremy Katz has mentioned on the ML that Fedora is depending on the front/back-end drivers being compiled as modules. I'm looking forward to the completion of #2, but I think it would be wise to fix #3 if we can, especially since it might be easier. I have looked at it but I'm out of my depth. Would Kouya, Akio or somebody else mind trying to fix it? Note: I will have sporadic email contact starting tomorrow until Wednesday 9/27, so I may not respond until then. Thanks, Aron ---application/pgp-signature--- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEzj8JrHF4yAQTrARAuLWAJ4v2e4HFnmyq01n48SC0PKIK3gjyACdGRI+ Wv/7SXoRNtXgssrk42mlfB8= =hoQO -END PGP SIGNATURE- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. FC6 test3 uses many daemons and services. Because booting xend is late, we fail insmod blk/netbk if dom0_mem=512M(default size). Wow, thank you! That is a big relief. We may have to change dom0_mem of FC6 default to 1GB. But I think the best fix is (1) statically link the modules. (Because all kernel-xen need blkbk/netbk and xenblk/net. ide module is also static link. And because xen community member test the statically linked modules, I think the statically linked modules is stabler than the dynamic linked modlues.) I don't mind asking RH to statically link the modules if there is good reason. However I don't understand why it is needed. 512M is a lot of memory! How can it be filled to the extent that the blkbk/netbk modules won't load? What are their requirements? It is possible that knowing the dom0_mem=1G workaround will be enough until Tristan's xencomm work is finished (I think he's almost done) Thanks again, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: blkbk/netbk modules fail to load on fedora xen/ia64
Akio Takebe wrote: [Thu Sep 21 2006, 09:53:16PM EDT] I can solve this problem by using dom0_mem=1G. This allows blkbk/netbk to load, but I guess a domU won't install yet. xenguest-install fails with a panic in dom0. I used this command: xenguest-install -n domu -r 1024 -f /root/domu.img \ -l http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ \ -s 4 --nographics -p -x 'ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe' Here is the output on the dom0 console: (XEN) ### domain f7bb4080: rid=8-c mp_rid=2000 (XEN) arch_domain_create: domain=f7bb4080 (XEN) DomainU EFI build up: ACPI 2.0=0x1000 (XEN) dom mem: type=13, attr=0x8008, range=[0x-0x1000) (4KB) (XEN) dom mem: type=10, attr=0x8008, range=[0x1000-0x2000) (4KB) (XEN) dom mem: type= 6, attr=0x8008, range=[0x2000-0x3000) (4KB) (XEN) dom mem: type= 7, attr=0x0008, range=[0x3000-0x3fff4000) (1023MB) (XEN) dom mem: type=12, attr=0x0001, range=[0x0c00-0x1000) (64MB) audit(1158891786.948:4): dev=vif1.0 prom=256 old_prom=0 auid=4294967295 kernel unaligned access to 0xa002009e405f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4067, ip=0xa00100295e91 kernel unaligned access to 0xa002009e406f, ip=0xa00100295e91 kernel unaligned access to 0xa002009e4077, ip=0xa00100295e91 kernel unaligned access to 0xa002009e407f, ip=0xa00100295e91 (XEN) vcpu_get_lrr0: Unmasked interrupts unsupported (XEN) vcpu_get_lrr1: Unmasked interrupts unsupported (XEN) Linux version 2.6.18-1.2679.fc6xen ([EMAIL PROTECTED]) (gcc version 4.1.1 20060917 (Red Hat 4.1.1-23)) #1 SMP Wed Sep 20 01:18:10 EDT 2006 EFI v1.00 by Xen/ia64: SALsystab=0x2178 ACPI 2.0=0x1000 rsvd_region[0]: [0xe0002228, 0xe00022f0) rsvd_region[1]: [0xe0003000, 0xe0003030) rsvd_region[2]: [0xe400, 0xe4c2899b) rsvd_region[3]: [0xe4c2c000, 0xe597ac00) rsvd_region[4]: [0xe0003fff4000, 0xe0003fff8000) rsvd_region[5]: [0x, 0x) Initial ramdisk at: 0xe4c2c000 (13954048 bytes) 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 ACPI: Local APIC address c000fee0 ACPI: Error parsing MADT - no IOSAPIC entries 1 CPUs available, 1 CPUs total Running on Xen! start_info_pfn=0xfffd nr_pages=65536 flags=0x0 *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_MC_SET_PARAMS. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 0. IGNORED... (XEN) *** CALLED SAL_SET_VECTORS 1. IGNORED... (XEN) MCA related initialization done SMP: Allowing 1 CPUs, 0 hotplug CPUs Built 1 zonelists. Total pages: 61440 Kernel command line: method=http://hummer.zko.hp.com/fedora/linux/core/development/ia64/os/ ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide_setup: ide0=noprobe ide_setup: ide1=noprobe ide_setup: ide2=noprobe ide_setup: ide3=noprobe PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 80x25 (file=grant_table.c, line=704) gnttab_transfer: error writing resp 0/1 kernel BUG at drivers/xen/netback/netback.c:631! swapper[0]: bugcheck! 0 [1] Modules linked in: loop xt_physdev bridge netloop netbk blkbk autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables xt_state ip_conntrack nfnetlink xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 vfat fat dm_multipath button parport_pc lp parport ide_cd sg e1000 cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, CPU 0, comm: swapper psr : 001008026010 ifs : 8694 ip : [a00200c80590]Not tainted ip is at net_rx_action+0x990/0x17a0 [netbk] unat: pfs : 8694 rsc : 0008 rnat: bsps: pr : 00019665 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a00200c80590 b6 : a001000b80c0 b7 : a002007c36c0 f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf f8 : 1003e04e2 f9 : 1003e0fa0 f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db r1 : a00100bcee60 r2 : a001009e5758 r3 : a001009e59f0 r8 : 0034 r9 : a001009da5e0 r10 : a001009e5788 r11 : a001009e5788 r12 : a00100733b10 r13 : a0010072c000 r14 : a001009e5758 r15 : r16 : f1004c18 r17 : a001009e59f0 r18 : a001008978fc r19 : 0001 r20 : r21 : a001009cf4b0 r22 : r23 :
Re: [Xen-ia64-devel] [patch] alloc_page_dir() should return a virtual address
Hi.
As Jes explained, p?d_populate() requires virtual address for third argument.
So alloc_dir_page() should return virtual address.
On the otherhand __pa(__pa(va)) == __pa(va) because __pa() masks high 3bits
instead of __pa(va) = va - PAGE_OFFSET. Thus the current alloc_dir_page()
creates correct frame tables fortunately.
However alloc_dir_page() should be fixed, I think.
About ivt.S part. You might have missed that shr is signed extended shift.
Probably the following is more readable.
#ifdef CONFIG_VIRTUAL_FRAME_TABLE
- shr r22=r16,56 // Test for the address of virtual frame_table
+ shr.u r22=r16,56// Test for the address of virtual frame_table
;;
- cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22
+ cmp.eq p8,p0=(VIRT_FRAME_TABLE_ADDR56),r22
(p8)br.cond.sptk frametable_miss ;;
#endif
thanks.
On Thu, Sep 21, 2006 at 01:26:57PM +0200, Jes Sorensen wrote:
Kouya SHIMURA wrote:
Hi Jes,
I wrote the patch corresponding to discontig. You are wrong.
alloc_dir_page() must return a physical address because the page table
walker for frame_table runs under off-state of data-address-translation.
(i.e. psr.dt=0)
p*d_populate() functions never be called while handling TLB miss to
frame_table. The page table walker for frame_table is written in
assembler in xen/arch/ia64/xen/ivt.S. See the code between
'GLOBAL_ENTRY(frametable_miss)' and 'END(frametable_miss)'
Hi Kouya,
I am not talking about during the TLB miss but during the creation
of the tables. I changed the code in ivt.S to make sure what was
happening was explicit, ie. if we are trying to resolve things in the
VIRT_FRAME_TABLE_ADDR space, then the test I put into ivt.S should be
identical to your original code, but I cannot boot with your code, it
MCA's because frametable_miss is never called since we are comparing for
the wrong address.
Please take a look at this code:
arch/ia64/xen/xenmem.c:
static int
create_frametable_page_table (u64 start, u64 end, void *arg)
{
...
[snip]
...
if (pud_none(*pud))
pud_populate(NULL, pud, alloc_dir_page());
pmd = pmd_offset(pud, address);
if (pmd_none(*pmd))
pmd_populate_kernel(NULL, pmd,
alloc_dir_page());
pte = pte_offset_kernel(pmd, address);
Then in include/asm-ia64/linux-xen/asm/pgalloc.h you have this:
static inline void
pud_populate(struct mm_struct *mm, pud_t * pud_entry, pmd_t * pmd)
{
pud_val(*pud_entry) = __pa(pmd);
}
and
static inline void
pmd_populate_kernel(struct mm_struct *mm, pmd_t * pmd_entry, pte_t * pte)
{
pmd_val(*pmd_entry) = __pa(pte);
}
In other words, if alloc_dir_page() returns a physical address as it
did before, you end up doing __pa() on the physical address which
just cannot be correct.
My guess is that we were in fact doing a __pa() on the physical address
and the compare in ivt.S somehow was made to look at this address
instead of what it was pretending to do.
I'd like to be proven wrong though, but without this patch Xen on SN2
only gets to an MCA at the moment it tries to initialize the page table.
You'd better have a look at the thread below:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-04/msg00014.html
I'll take a look.
Cheers,
Jes
Thanks,
Kouya
Jes Sorensen writes:
Hi,
I sent this patch to Alex last week, but it didn't make it onto the list
because it's wrongly configured, so here we go again.
I know that this patch is causing problems on ZX1, but I have looked at
it over and over again and I feel pretty certain it is correct. In fact
I cannot understand that Xen could boot on any ia64 platform prior to
this at all.
I would be very interested in hearing how this patch affects other
platforms such as DIG and Fujitsu's machines (if they are not DIG :)
Any input or comments on this is most welcome - if you think I am wrong
about this patch, please tell me, I really want to understand why this
worked in the past.
Thanks,
Jes
alloc_dir_page() must return a virtual address so it can handle being
passed to the p*d_populate() functions which do a __pa() on the address
before sticking them into the page tables.
To match this it is also necessary to correctly check the faulting
address for being in the virtual frame table range, otherwise page
faults for this space weren't being served at all.
This could probably be done more efficiently, but for now I think it's
better to keep the code explicit.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/ivt.S
--- a/xen/arch/ia64/xen/ivt.STue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/ivt.SWed Sep
Re: [Xen-ia64-devel] pickled code
On Thu, Sep 21, 2006 at 10:52:17AM +0200, Jes Sorensen wrote: How does this look to you then? I get as far with this patch as I got with the previous one I sent out, so thats a good sign :) Without any of the patches I get an MCA as soon as I start touching the mpt_table. Hi Jes. Your patch works for me. However I have two comments. - xen_heap_start xenheap_virt_start might be consistent compared to xenheap_phys_end. But this is only my preference. I'm not sure which is consistent for others. - Probably this variable is a good candidate for __read_mostly. However Currently Xen/IA64 defines __read_mostly as nothing. So I think it's good time to support __read_mostly. Common codes utilize it. Thanks. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang and all I can boot up domU by using my special initrd without vif. I think mkinitrd of fc6 make initrd by using dom0 infomation. (for example dom0's /etc/fstab, dom0's pci infomaition. ) So when xm boot domU, domU kernel don't use bootparmeter of domU. The below is a recipe of making my special inird 1. copy initrd # mkdir tmp # cp /boot/efi/efi/redhat/initrd-2.6.18-1.2679.fc6xenU.img tmp/ 2. expand inird # cd tmp # gzip -cd ../initrd-2.6.18-1.2679.fc6xenU.img |cpio -id 3. modify init in initrd # vi init insmod /lib/ohci-hcd.ko echo Loading ehci-hcd.ko module insmod /lib/ehci-hcd.ko mount -t usbfs /proc/bus/usb /proc/bus/usb echo Loading jbd.ko module insmod /lib/jbd.ko echo Loading ext3.ko module insmod /lib/ext3.ko #echo Loading scsi_mod.ko modulecomment out #insmod /lib/scsi_mod.ko comment out #echo Loading sd_mod.ko module comment out #insmod /lib/sd_mod.kocomment out #echo Loading scsi_transport_spi.ko module comment out #insmod /lib/scsi_transport_spi.kocomment out #echo Loading mptbase.ko module comment out #insmod /lib/mptbase.ko comment out #echo Loading mptscsih.ko modulecomment out #insmod /lib/mptscsih.ko comment out #echo Loading mptspi.ko module comment out #insmod /lib/mptspi.kocomment out echo Loading xenblk.ko module insmod /lib/xenblk.ko mkblkdevs #resume LABEL=SWAP-sda3 comment out echo Creating root device. mkrootdev -t ext3 -o defaults,ro sda1 change device to sda1 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot 4. make new initrd # find . -print | cpio --quiet -c -o | gzip -9 ../initrd-new.img 5. my domU configuration kernel = /boot/efi/efi/redhat/vmlinuz-2.6.18-1.2679.fc6xen ramdisk = /xen/initrd-new.img memory = 1024 name = fc6.DomU #vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] root = /dev/sda1 ro extra = 4 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe selinux=0 rhgb 6. etc 6.1. copy modlues into domU image file # mount -o loop domU.img /mnt # cp -a /lib/modules/2.6.18-1.2679.fc6xen/ /mnt/lib/modules/ 6.2. disable selinux # vi /etc/sysconfig/selinux SELINUX=disabled change enforcing to disabled 6.3. modify /etc/fstab in domU.img /dev/sda1 / ext3defaults1 1 devpts/dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults0 0 proc /proc procdefaults0 0 sysfs /sys sysfs defaults0 0 But I cannot use network on domU. I'll check the src.rpm of kernel-xen. Best Regards, Akio Takebe Hi Akio, Sorry for response late. I just tried with the config you provide (I changed xenU modprobe.conf and fstab). But unfortunately it still couldn't work. XenU booting still report can not find filesystem /dev/root/ and kernel panic. Well, after add ide0=noprobe etc. xenU won't complain to check hda, hdb etc. again. Thanks for this information. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006ト\xF3ヤツ21ネユ 10:18 To: Akio Takebe; You, Yongkang; Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [
