Re: [XenPPC] copy_page speedup using dcbz on target
On Sat, 16 Dec 2006 11:34, Jimi Xenidis wrote: If you really want to explore mem/page copy for XenPPC then you have to understand that since we run without an MMU, profiling code with MMU on, _including_ RMA, is not helpful because the access is guarded ... Please run your experiments _in_ Xen ... Timing code has been included in Xen, setup.c; however, results match prior timings in userspace: JS20: elapsed time: 0xa8f5 elapsed time using dcbz: 0x5410 elapsed time: 0xa987 elapsed time using dcbz: 0x5361 JS21: elapsed time: 0x0862 elapsed time using dcbz: 0x0420 elapsed time: 0x0859 elapsed time using dcbz: 0x0424 ... You will probably find that grouping (as Hollis suggests) by cache line will be much better. but also prefetch the next line somehow. Somewhat better... (following observations were made running in user space) The unrolling the copy loop (by cache line) improves performance a few percent. (did not record the time; also unrolled loop still used same number of registers and no touching) However, including dcbz at beginning of loop slowed things down. Perhaps need to dcbz a couple lines ahead of usage? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] copy_page speedup using dcbz on target
Using dcbz avoids first reading a cache line from memory before writing to the
line.
Timing results (starting with clean cache, ie no write-backs for dirty lines):
JS20:
elapsed time: 0x9f5e
elapsed time using dcbz: 0x569e
elapsed time: 0x9fe9
elapsed time using dcbz: 0x5765
JS21:
elapsed time: 0x089e
elapsed time using dcbz: 0x0439
elapsed time: 0x0886
elapsed time using dcbz: 0x0438
.
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
typedef unsigned char uchar;
typedef unsigned long ulong;
#define LINE_SIZE 128
#define PAGE_SIZE 0x1000
#define BUF1_SIZE (PAGE_SIZE * 64)
#define BUF2_SIZE (PAGE_SIZE)
#define BUF3_SIZE (0x80)
static __inline__ ulong time_base(void);
static __inline__ void copy_page(void *dp, void *sp);
static __inline__ void cacheable_copy_page(void *dp, void *sp);
static __inline__ void cacheable_clear_page(void *addr);
static uchar clean_cache(uchar *buf3);
int main(int argc, char **argv){
int i;
ulong tb1, tb2;
uchar *buf1, *buf2, *buf3, *bufp;
buf1 = malloc(BUF1_SIZE + PAGE_SIZE);
buf2 = malloc(BUF2_SIZE + PAGE_SIZE);
buf3 = malloc(BUF3_SIZE + PAGE_SIZE);
buf1 = (uchar *)((ulong)(buf1 + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1));
buf2 = (uchar *)((ulong)(buf2 + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1));
buf3 = (uchar *)((ulong)(buf3 + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1));
memset(buf1, 1, BUF1_SIZE);
memset(buf2, 2, BUF2_SIZE);
memset(buf3, 3, BUF3_SIZE);
clean_cache(buf3);
tb1 = time_base();
for (bufp = buf1, i = 0; i 4; i++, bufp += PAGE_SIZE*16){
copy_page(bufp, buf2);
copy_page(bufp+(PAGE_SIZE*1), buf2);
copy_page(bufp+(PAGE_SIZE*2), buf2);
copy_page(bufp+(PAGE_SIZE*3), buf2);
copy_page(bufp+(PAGE_SIZE*4), buf2);
copy_page(bufp+(PAGE_SIZE*5), buf2);
copy_page(bufp+(PAGE_SIZE*6), buf2);
copy_page(bufp+(PAGE_SIZE*7), buf2);
copy_page(bufp+(PAGE_SIZE*8), buf2);
copy_page(bufp+(PAGE_SIZE*9), buf2);
copy_page(bufp+(PAGE_SIZE*10), buf2);
copy_page(bufp+(PAGE_SIZE*11), buf2);
copy_page(bufp+(PAGE_SIZE*12), buf2);
copy_page(bufp+(PAGE_SIZE*13), buf2);
copy_page(bufp+(PAGE_SIZE*14), buf2);
copy_page(bufp+(PAGE_SIZE*15), buf2);
}
tb2 = time_base();
printf(elapsed time: 0x%016lx\n, tb2 - tb1);
clean_cache(buf3);
tb1 = time_base();
for (bufp = buf1, i = 0; i 4; i++, bufp += PAGE_SIZE*16){
cacheable_copy_page(bufp, buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*1), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*2), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*3), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*4), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*5), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*6), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*7), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*8), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*9), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*10), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*11), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*12), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*13), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*14), buf2);
cacheable_copy_page(bufp+(PAGE_SIZE*15), buf2);
}
tb2 = time_base();
printf(elapsed time using dcbz: 0x%016lx\n, tb2 - tb1);
return(0);
}
static __inline__ ulong time_base(void)
{
ulong tb;
__asm__ __volatile__(
mftb %0 # read time base
: =r (tb));
return tb;
}
static __inline__ void cacheable_clear_page(void *addr)
{
ulong lines, line_size;
line_size = LINE_SIZE;
lines = PAGE_SIZE / line_size;
__asm__ __volatile__(
mtctr %1 # clear_page\n\
1: dcbz0,%0\n\
add %0,%0,%3\n\
bdnz1b
: =r (addr)
: r (lines), 0 (addr), r (line_size)
: %ctr, memory);
}
static __inline__ void copy_page(void *dp, void *sp)
{
ulong dwords, dword_size;
dword_size = 8;
dwords = (PAGE_SIZE / dword_size) - 1;
__asm__ __volatile__(
mtctr %2 # copy_page\n\
ld %2,0(%1)\n\
std %2,0(%0)\n\
1: ldu %2,8(%1)\n\
stdu%2,8(%0)\n\
bdnz1b
: /* no result */
: r (dp), r (sp), r (dwords)
: %ctr, memory);
}
static __inline__ void cacheable_copy_page(void *dp, void *sp)
{
cacheable_clear_page(dp);
copy_page(dp, sp);
}
static uchar clean_cache(uchar *buf3)
{
int i;
uchar uc, *ucp = buf3;
for (i = 0; i BUF3_SIZE / LINE_SIZE; i++){
uc += *ucp;
ucp += LINE_SIZE;
}
return(uc);
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
Re: [XenPPC] copy_page speedup using dcbz on target
So do you have a patch for copy_page()?
In Xen for PPC, the only copy_page() is in arch/powerpc/mm.c:
extern void copy_page(void *dp, void *sp)
{
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
memcpy(dp, sp, PAGE_SIZE);
}
}
1) Also copy_page is not referenced in current Xen sources?
2) dcbz depends on cacheability and cache alignment.
Should a newname be given to this version of copy_page()?
3) Useful when PPC must do page copies in place of 'page flipping'.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] copy_page speedup using dcbz on target
3) Useful when PPC must do page copies in place of 'page flipping'.
So you're saying we should worry about it later?
For the future, copy_page using dcbz:
diff -r 7669fca80bfc xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/arch/powerpc/mm.c Fri Dec 15 17:52:58 2006 -0500
@@ -280,7 +280,8 @@ extern void copy_page(void *dp, void *sp
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
-memcpy(dp, sp, PAGE_SIZE);
+ clear_page(dp);
+ __copy_page(dp, sp);
}
}
diff -r 7669fca80bfc xen/include/asm-powerpc/page.h
--- a/xen/include/asm-powerpc/page.hMon Dec 04 11:46:53 2006 -0500
+++ b/xen/include/asm-powerpc/page.hFri Dec 15 17:52:58 2006 -0500
@@ -90,6 +90,25 @@ 1: dcbz0,%0\n\
extern void copy_page(void *dp, void *sp);
+static __inline__ void __copy_page(void *dp, void *sp)
+{
+ ulong dwords, dword_size;
+
+ dword_size = 8;
+ dwords = (PAGE_SIZE / dword_size) - 1;
+
+ __asm__ __volatile__(
+ mtctr %2 # copy_page\n\
+ ld %2,0(%1)\n\
+ std %2,0(%0)\n\
+1: ldu %2,8(%1)\n\
+ stdu%2,8(%0)\n\
+ bdnz1b
+ : /* no result */
+ : r (dp), r (sp), r (dwords)
+ : %ctr, memory);
+}
+
#define linear_pg_table linear_l1_table
static inline int get_order(unsigned long size)
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] xm save / restore
- logical translation array */
+uint64_t *shadow; /* idx - logical translation array */
};
#endif
diff -r 7669fca80bfc xen/include/public/arch-powerpc.h
--- a/xen/include/public/arch-powerpc.h Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/include/public/arch-powerpc.h Wed Dec 13 15:39:32 2006 -0500
@@ -98,11 +98,66 @@ typedef struct cpu_user_regs cpu_user_re
typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */ /* XXX timebase */
+#defineNUM_SLB_ENTRIES 64
+struct slb_entry {
+ uint64_t slb_vsid;
+ uint64_t slb_esid;
+};
+typedef struct slb_entry slb_entry_t;
+
+#ifndef HAS_VMX
+#define HAS_VMX 1
+#endif
+
+#ifndef HAS_FLOAT
+#define HAS_FLOAT 1
+#endif
+
+#ifdef HAS_VMX
+typedef struct {
+ uint32_t u[4];
+} __attribute__((aligned(16))) _vector128;
+#endif /* HAS_VMX */
+
+
/* ONLY used to communicate with dom0! See also struct exec_domain. */
struct vcpu_guest_context {
cpu_user_regs_t user_regs; /* User-level CPU registers */
+slb_entry_tslb_entries[NUM_SLB_ENTRIES]; /* Segment Lookaside
Buffer */
+
+/* Special-Purpose Registers */
+uint64_t sprg[4];
+uint64_t timebase;
+uint64_t dar;
+uint64_t dsisr;
+
+struct cpu_vcpu_tag {
+ uint64_t hid4;
+} cpu; /* CPU-specific bits */
+
+uint32_t dec;
+
+/* XXX etc */
+#ifdef HAS_FLOAT
+#define NUM_FPRS 32
+double fprs[NUM_FPRS];
+#endif
+#ifdef HAS_VMX
+_vector128 vrs[32];
+_vector128 vscr;
+uint32_t vrsave;
+#endif
+
+#if 0
+struct xencomm *xencomm;
+
+/* I/O-port access bitmap. */
+u8 *iobmp;/* Guest kernel virtual address of the bitmap. */
+int iobmp_limit; /* Number of ports represented in the bitmap. */
+int iopl; /* Current IOPL for this VCPU. */
+#endif
+
uint64_t sdr1; /* Pagetable base */
-/* XXX etc */
};
typedef struct vcpu_guest_context vcpu_guest_context_t;
DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
diff -r 7669fca80bfc xen/include/public/domctl.h
--- a/xen/include/public/domctl.h Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/include/public/domctl.h Wed Dec 13 15:39:32 2006 -0500
@@ -392,6 +392,18 @@ typedef struct xen_domctl_real_mode_area
typedef struct xen_domctl_real_mode_area xen_domctl_real_mode_area_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_real_mode_area_t);
+#define XEN_DOMCTL_getshadowlist 29
+struct xen_domctl_getshadowlist {
+ /* OUT variables */
+ /* Start of htab array */
+ uint64_t htab_map;
+ /* Number of ptes within htab */
+ uint32_t htab_num_ptes;
+};
+
+typedef struct xen_domctl_getshadowlistxen_domctl_getshadowlist_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_getshadowlist_t);
+
struct xen_domctl {
uint32_t cmd;
uint32_t interface_version; /* XEN_DOMCTL_INTERFACE_VERSION */
@@ -418,6 +430,7 @@ struct xen_domctl {
struct xen_domctl_arch_setuparch_setup;
struct xen_domctl_settimeoffset settimeoffset;
struct xen_domctl_real_mode_areareal_mode_area;
+struct xen_domctl_getshadowlist getshadowlist;
uint8_t pad[128];
} u;
};
diff -r 7669fca80bfc tools/libxc/powerpc64/xc_linux_restore.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/tools/libxc/powerpc64/xc_linux_restore.c Wed Dec 13 15:39:32 2006 -0500
@@ -0,0 +1,312 @@
+/**
+ * xc_linux_restore.c
+ *
+ * Restore the state of a Linux session.
+ *
+ * Copyright (c) 2003, K A Fraser.
+ * Rewritten for PPC: Dan Poff [EMAIL PROTECTED], Yi Ge [EMAIL PROTECTED]
+ */
+
+#include inttypes.h
+#include stdlib.h
+#include unistd.h
+#include xen/asm/htab.h
+
+#include xg_private.h
+
+#define DECOR 0x8000// indicates htab address
+#define LOG_PTE_SIZE4
+
+#define INVALID_MFN (~0ULL)
+
+#define PFN_TO_KB(_pfn) ((_pfn) (PAGE_SHIFT - 10))
+
+/* total number of pages used by the current guest */
+static unsigned long max_pfn;
+
+static ssize_t
+read_exact(int fd, void *buf, size_t count)
+{
+int r = 0, s;
+unsigned char *b = buf;
+
+while (r count) {
+s = read(fd, b[r], count - r);
+if ((s == -1) (errno == EINTR))
+continue;
+if (s = 0) {
+break;
+}
+r += s;
+}
+
+return (r == count) ? 1 : 0;
+}
+
+static int
+read_page(int xc_handle, int io_fd, uint32_t dom, xen_pfn_t mfn)
+{
+void *mem;
+
+mem = xc_map_foreign_range(xc_handle, dom, PAGE_SIZE,
+ PROT_READ|PROT_WRITE, mfn);
+if (mem == NULL) {
+ERROR(cannot map page);
+ return -1;
+}
+if (!read_exact(io_fd, mem, PAGE_SIZE)) {
+ERROR(Error when reading from state file (5));
+return -1;
+}
+
+munmap(mem, PAGE_SIZE);
+return 0;
+}
+
+int
Re: [XenPPC] xend and routes
If this machine would like 192.x machines to acces the 9.x network the ip_forwrding is necessary. Right - I was thinking of DomU access to only 192.x. For machines on 192.x to access 9.x, you need forwarding... ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
I think the problem is that the bridge favors the default route, so I do not think swapping would work. On my victim JS21, eth0 is the default, and xen scripts work as written. However, in this case, DomU accesses the 9.2x network, rather than 192.x ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
If this machine would like 192.x machines to acces the 9.x network the ip_forwrding is necessary. Right - I was thinking of DomU access to only 192.x. For machines on 192.x to access 9.x, you need forwarding... On the other hand... CSO is setup with 192.168.0.1 as router/gateway (on the 'king node', cso3). DomUs in CSO blades would gain access to the outside through the king rather than ip_forwarding on the local blades. (talking w/ M. Banikazemi) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
BTW: If you would like to have DomUs to have access to the outside world then you also want to make sure you have ip forwarding turned on: # echo 1 /proc/sys/net/ipv4/ip_forward forever change IP_FORWARD= from no to yes in /etc/sysconfig/sysctl 'ip forwarding' is not necessary - I think bridging handles DomU packets without involving Dom0 network stack. For CSO the other issue is ip addresses for DomUs - viz 9.2... vs 192.168... are the addresses routable or not? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
We have had a couple network configuration mysteries, (including setting 'network-bridge netdev=eth0') due to CSO usage of eth1 as default/extenal adapter, rather than eth0. Probably the xen scripts would have worked without mods if eth0 1 were swapped... ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
cso89:~ # netstat -rn netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 9.2.78.10.0.0.0 255.255.255.255 UH0 0 0 eth0 9.2.78.00.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 9.2.78.10.0.0.0 UG0 0 0 eth0 0.0.0.0 9.2.78.10.0.0.0 UG0 0 0 eth1 The next to last route is bogus and interferes with the proper operation of the machine as far as the network goes. I am not sure what the first route in the list above is all about, but seems strange as well. In any case it was not there before. Not clear how this happened, but can fix the problem by deleting the eth0 gateway, 'route del ...' Multiple gateways occur when a second gateway is added without deleting the original gateway, eg with 'route add gw...' However, in this case, the eth0 should not have been added, as you point-out. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [RFC] 'xm restore' following boot
I now think the console prints in previous mail are useless. Example 2 runs while example 3 wedges, yet the prints are roughly equivalent... Also today there have been several runs similar to example 2. I modified python code to skip the 'unpause' at the end of domain restore. The drill: boot, xend start, xm restore, then another activity eg rebuild tools or search kernel tree, finally xm unpause. The guest domain often runs ok! If the 'other activity' is skipped and restored domain is unpaused immediately, almost always wedges. However, sometimes the restored domain will wedge regardless of other activity or multiple trys at restoring. Earlier this week I was sure the wedging occured due to interrupts or execptions in a loop, but have placed some counters, but see nothing when wedging (via BUG() or printk()). Have not installed gdb or tracing patches, thinking would not help with interrupt problems. Yi thought there may be some kernel initialization during boot that is missing with restore... Anyway I see no way to proceed without knowing where the wedge occurs. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [RFC] 'xm restore' following boot
'xm restore' immediately following boot usually wedges the cpu. However, xm save followed by xm restore works fine (even when guest domain and htab are relocated to new memory areas). ^AAA shows: with .plpar_hcall_norets @ c003af78 and .HYPERVISOR_sched_op @ c004415c (XEN) *** Dumping CPU3 state: *** (XEN) [ Xen-3.0-unstable ] (XEN) CPU: 0003 DOMID: 0001 (XEN) pc c003af88 msr 80009032 (XEN) lr c0044210 ctr c0044238 (XEN) srr0 srr1 (XEN) r00: 2448 c065bcb0 c0656630 (XEN) r04: 0001 2442 c000fc24 (XEN) r08: ecf515a8 c0044238 00989680 c00441a4 (XEN) r12: 01a9f9f8 c052e300 (XEN) r16: (XEN) r20: (XEN) r24: 4000 c000 (XEN) r28: 0010 c053d3c8 0001 (XEN) reprogram_timer[00] Timeout in the past 0x004332DBA479 0x0042C2424DF3 Here are typical console with debug prints and execptions: If 'xm restore' is run several times, often it will start working, though the exceptions still occur... (user domain has ramdisk networking) At the bottom, some code specified by a couple Exceptions... 1. 'xm restore' following xm save: cso84:~ # xm console 6 mfdec: -12 TIMEBASE_FREQ: 71592390 Here we're resuming hid4: 0x62001242 arch_gnttab_map: grant table at d8008000 irq_resume() switch_idle_mm() mfdec: 14315899 __sti() xencons_resume() xenbus_resume() smp_resume() mfdec: 63024 returning netfront: device eth0 has copying receive path. [EMAIL PROTECTED] /]# 2. reboot with 'xm restore' that worked 1st time: cso84:~ # xm console 1 mfdec: -14 TIMEBASE_FREQ: 71592390 Here we're resuming hid4: 0x60001241 arch_gnttab_map: grant table at d8008000 irq_resume() switch_idle_mm() mfdec: 14315924 __sti() xencons_resume() xenbus_resume() BUG: soft lockup detected on CPU#0! Call Trace: [C065B090] [C001062C] .show_stack+0x50/0x1cc (unreliable) [C065B140] [C008956C] .softlockup_tick+0x100/0x128 [C065B200] [C0065BC0] .run_local_timers+0x1c/0x30 [C065B280] [C0023C60] .timer_interrupt+0x108/0x4f0 [C065B3B0] [C00034EC] decrementer_common+0xec/0x100 --- Exception: 901 at .handle_IRQ_event+0x4c/0x13c LR = .__do_IRQ+0x1ac/0x2b4 [C065B6A0] [C05AB7B0] 0xc05ab7b0 (unreliable) [C065B740] [C0089FC8] .__do_IRQ+0x1ac/0x2b4 [C065B800] [C02B7134] .evtchn_do_upcall+0x128/0x1a4 [C065B8C0] [C0043664] .xen_get_irq+0x10/0x28 [C065B940] [C000BD7C] .do_IRQ+0x7c/0x100 [C065B9C0] [C00041EC] hardware_interrupt_entry+0xc/0x10 --- Exception: 501 at .plpar_hcall_norets+0x10/0x1c LR = .HYPERVISOR_sched_op+0xb4/0x10c [C065BCB0] [C00BDA74] .kmem_cache_free+0xe4/0x2f4 (unreliable) [C065BD60] [C00455CC] .xen_power_save+0x80/0x98 [C065BDE0] [C00120E4] .cpu_idle+0x14c/0x154 [C065BE70] [C0009174] .rest_init+0x44/0x5c [C065BEF0] [C04E58D8] .start_kernel+0x2a0/0x308 [C065BF90] [C00084FC] .start_here_common+0x50/0x54 smp_resume() mfdec: 90178 returning netfront: device eth0 has copying receive path. [EMAIL PROTECTED] /]# 3. reboot with typical wedge: cso84:~ # xm console 1 mfdec: -12 TIMEBASE_FREQ: 71592390 Here we're resuming hid4: 0x60001241 arch_gnttab_map: grant table at d8008000 irq_resume() switch_idle_mm() mfdec: 14315903 __sti() xencons_resume() xenbus_resume() smp_resume() mfdec: 14218880 returning BUG: soft lockup detected on CPU#0! Call Trace: [C065B090] [C001062C] .show_stack+0x50/0x1cc (unreliable) [C065B140] [C008956C] .softlockup_tick+0x100/0x128 [C065B200] [C0065BC0] .run_local_timers+0x1c/0x30 [C065B280] [C0023C60] .timer_interrupt+0x108/0x4f0 [C065B3B0] [C00034EC] decrementer_common+0xec/0x100 --- Exception: 901 at .handle_IRQ_event+0x4c/0x13c LR = .__do_IRQ+0x1ac/0x2b4 [C065B6A0] [C05AB7B0] 0xc05ab7b0 (unreliable) [C065B740] [C0089FC8] .__do_IRQ+0x1ac/0x2b4 [C065B800] [C02B7134] .evtchn_do_upcall+0x128/0x1a4 [C065B8C0] [C0043664] .xen_get_irq+0x10/0x28 [C065B940] [C000BD7C] .do_IRQ+0x7c/0x100 [C065B9C0] [C00041EC] hardware_interrupt_entry+0xc/0x10 --- Exception: 501 at .plpar_hcall_norets+0x10/0x1c LR = .HYPERVISOR_sched_op+0xb4/0x10c [C065BCB0] [C00BDA74]
Re: [XenPPC] [linux-ppc-2.6] [XEN] The VIO rewrite
Hmm.. I capped my Dom0 to 192M and 64M and it worked fine. The only reason that mempool_create() can fail is if an underlying kmalloc failed, I don't think that we are trying to get so much memory. Hey! did you update Xen as well? because the number of pages was way too large before. Just pulled xen and linux trees before lunch, rebuilt everything, including tools, tried again: a) with initrd-0.8.img worked ok b) with /dev/hdc2 got problems below: c) fsck /dev/hdc2 then reboot tried again - everything worked fine! Built linux kernel in 12 min. Below is some log from vmstat 3: Guest console: netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront: Bad rx response id 256. netfront:lab082:~ # lab082:~ # Dom0 console: Welcome to SUSE Linux Enterprise Server 10 (ppc) - Kernel 2.6.17-Xen (console). lab082 login: (XEN) allocated RMA for Dom[1]: 0x1c00[0x400] (XEN) Domain[1].0: initializing (XEN) allocated RMA for Dom[2]: 0x1c00[0x400] (XEN) Domain[2].0: initializing (XEN) (file=grant_table.c, line=845) copy beyond page area. (XEN) (file=grant_table.c, line=845) copy beyond page area. (XEN) (file=grant_table.c, line=845) copy beyond page area. (XEN) (file=grant_table.c, line=845) copy beyond page area. (XEN) (file=grant_table.c, line=845) copy beyond page area. vmstat 3 during kernel build: procs ---memory-- ---swap-- -io -system-- -cpu-- r b swpd free buff cache si sobibo in cs us sy id wa st 2 0 0 18704 32504 3769600 12988 18 121 41 10 44 5 0 1 2 0 18156 33308 4027200 125 501 44 182 58 22 0 21 0 1 0 0 6740 33316 405240023 192 42 80 80 14 0 6 0 1 1 0 1796 34024 405960031 963 44 109 82 14 0 5 0 1 0 0 18352 32548 405120033 0 14 219 75 20 0 5 0 1 0 0 8800 33452 406480021 667 62 93 59 18 0 23 0 1 0 0 3320 33348 407520025 06 82 85 14 0 1 0 3 1 0 4128 28132 379080049 397 35 149 85 9 0 7 0 1 0 0 19664 28152 3814800 177 0 14 249 78 17 0 5 0 1 0 0 14328 28860 384800036 417 35 92 82 16 0 3 0 2 1 0 22612 29676 389640037 144 10 90 84 14 0 1 0 2 0 0 20352 29696 389440019 467 46 240 73 20 0 7 0 2 0 0 19700 30392 392880017 464 43 223 75 22 0 3 0 1 0 0 20484 30408 392720016 07 245 77 22 0 1 0 1 0 0 2488 31180 398000043 383 21 99 73 18 0 8 0 1 0 0 12812 29044 3803600 428 0 28 152 82 13 0 5 0 1 0 0 2116 29844 382760040 553 44 141 76 8 0 17 0 1 1 0 11592 28732 378280027576 129 87 12 0 2 0 1 0 0 9632 28736 380840017 459 38 184 78 17 0 6 0 1 0 0 12032 29456 381440028 457 43 157 74 17 0 9 0 1 0 0 3464 29464 383960049 04 60 89 9 0 2 0 procs ---memory-- ---swap-- -io -system-- -cpu-- r b swpd free buff cache si sobibo in cs us sy id wa st 0 1 0 27244 26364 381160051 432 41 214 73 15 0 12 0 1 0 0 18076 26412 385880060 0 13 141 78 18 0 4 0 1 0 0 10332 27296 390040056 617 48 151 63 17 0 20 0 1 2 0 19276 28088 392520041 589 12 162 82 15 0 3 0 1 0 0 20172 28088 39252001211 41 178 88 10 0 2 0 1 0 0 18100 28788 395920028 529 44 252 82 17 0 1 0 1 0 0 9168 28800 395800020 04 192 85 14 0 1 0 1 0 0 14960 29520 399000017 528 46 223 74 18 0 8 0 1 0 0 2116 29632 371880044 572 18 64 92 8 0 0 0 2 0 0 25344 29020 372800035 0 35 157 79 16 0 5 0 procs ---memory-- ---swap-- -io -system-- -cpu-- r b swpd free buff cache si sobibo in cs us sy id wa st 2 1 0 18620 27476 3908400 126 105 19 124 44 10 41 5 0 1 1 0 14100 27596 394840071 0 26 146 77 23 0 1 0 2 1 0 15680 28388 3895200 261 665 75 140 80 15 0 5 0 3 1 0 18580 28484 3989600 145 0 18 204 77 22 0 1 0 2 2 0 1544 26328 358120095 769 61 119 82 9 0 9 0 1 2 0 12304 27340 3662000 355 573
Re: [XenPPC] [linux-ppc-2.6] [XEN] The VIO rewrite
size: 0MB Adding PCI host bridge /ht Found U3-HT PCI host bridge. Firmware bus number: 0-239 PCI Host 0, io start: 0; io end: 3f Using Xen idle loop On node 0 totalpages: 49152 DMA zone: 49152 pages, LIFO batch:15 *** : CF15 *** : Setup Done [boot]0015 Setup Done Built 1 zonelists. Total pages: 49152 Kernel command line: root=/dev/hda2 sysrq=1 debug Sharing PIC with Xen mpic: Setting up MPIC Xen-U3-MPIC version 1.2 at f804, max 4 CPUs mpic: ISU size: 124, shift: 7, mask: 7f mpic: Initializing for 124 sources mpic: Setting up HT PICs workarounds for U3/U4 mpic: - HT:01.0 [0xb8] vendor 1022 device 7450 has 4 irqs mpic: - HT:02.0 [0xb8] vendor 1022 device 7450 has 4 irqs mpic: - HT:03.0 [0xf0] vendor 1022 device 7460 has 24 irqs PID hash table entries: 1024 (order: 10, 8192 bytes) time_init: decrementer frequency = 199.839336 MHz time_init: processor frequency = 1600.00 MHz Maple: Found RTC at IO 0x1070 Console: colour dummy device 80x25 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) freeing bootmem node 0 Memory: 186140k/196608k available (5256k kernel code, 10468k reserved, 1228k data, 562k bss, 244k init) Calibrating delay loop... 398.95 BogoMIPS (lpj=1994752) Mount-cache hash table entries: 256 Brought up 1 CPUs smp_xen_setup_cpu(0) migration_cost=0 arch_gnttab_map: grant table at d80082016000 setup_grant_area: mempool_create(): failed kernel BUG in setup_grant_area at /home/poff/linux-ppc-2.6-work.hg/arch/powerpc/platforms/xen/gnttab.c:420! cpu 0x0: Vector: 700 (Program Check) at [c0a3fa50] pc: c0043fc0: .arch_gnttab_map+0x1bc/0x254 lr: c0043fbc: .arch_gnttab_map+0x1b8/0x254 sp: c0a3fcd0 msr: 80028032 current = 0xc0a31800 paca= 0xc052e300 pid = 1, comm = swapper kernel BUG in setup_grant_area at /home/poff/linux-ppc-2.6-work.hg/arch/powerpc/platforms/xen/gnttab.c:420! enter ? for help 0:mon ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xm restore: xc_get_pfn_list() returns bogus mfns
Dan, we assumed that xend built a domain shell before the restor
process, is this not the case.
The restore code does not call initDomain(), so allocMem() is never run:
If I change restore to include initDomain(), then good mfns showup...
Uncomfortable with this 'hack' - don't know where initDomain() came from,
and why it was omitted from restore code?
XendDomainInfo.py:
def create(config):
Create a VM from a configuration.
@param configconfiguration
@raise: VmError for invalid configuration
log.debug(XendDomainInfo.create(%s), config)
vm = findDomainClass()(parseConfig(config))
try:
vm.construct()
vm.initDomain()
vm.storeVmDetails()
vm.storeDomDetails()
vm.registerWatches()
vm.refreshShutdown()
return vm
except:
log.exception('Domain construction failed')
vm.destroy()
raise
def restore(config):
Create a domain and a VM object to do a restore.
@param config: domain configuration
log.debug(XendDomainInfo.restore(%s), config)
vm = findDomainClass()(parseConfig(config), None, None, False, False, True)
try:
vm.construct()
vm.storeVmDetails()
vm.createDevices()
vm.createChannels()
vm.storeDomDetails()
vm.endRestore()
return vm
except:
vm.destroy()
raise
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xm restore: xc_get_pfn_list() returns bogus mfns
It seems like an odd disconnect. I wonder if some of what we have in initDomain should actually be in vm.construct()?! Also, curious that createDevices() and createChannels() is included in initDomain(), while vm.restore() calls them directly. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] xm restore: xc_get_pfn_list() returns bogus mfns
'restore' maps guest memory then reads the saved memory image from disk.
xc_get_pfn_list() provides mfns of guest memory, used for mapping the guest
pages.
When using these mfns, the system crashes. Ki realized these mfns are too small.
Also when creating a new domain, the console prints message whenever RMA is
allocated;
however, when restoring a domain, there is no RMA message...
Looking through python code, RMA is created via allocMem, in XenDomainInfo.py.
However, allocMem is called only during initDomain for 'domain creation'.
'domain recreation' does not invoke allocMem...
Here is xend.log showing typical mfns, eg 2d97, (in this case, no data was
written to these pages):
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:268)
XendDomainInfo.restore(['domain', ['domid', '2'], ['uuid',
'052ea7ad-8567-74dd-3096-6e447cb7f059'], ['vcpus', '1'], ['vcpu_avail', '1'],
['cpu_weight', '1.0'], ['memory', '64'], ['powerpc_rma_log', '26'],
['shadow_memory', '1'], ['maxmem', '64'], ['features'], ['name',
'S-1160762357.95'], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'],
['on_crash', 'restart'], ['image', ['linux', ['kernel', '/root/vmlinux.strip'],
['ramdisk', '/root/ramdisk.image.gz'], ['args', 'xencons=tty128
console=tty128']]], ['state', '--'], ['shutdown_reason', 'poweroff'],
['cpu_time', '1.17065513'], ['online_vcpus', '1'], ['up_time', '59.548593998'],
['start_time', '1160762358.2'], ['store_mfn', '131070'], ['console_mfn',
'131069']])
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:299)
parseConfig: config is ['domain', ['domid', '2'], ['uuid',
'052ea7ad-8567-74dd-3096-6e447cb7f059'], ['vcpus', '1'], ['vcpu_avail', '1'],
['cpu_weight', '1.0'], ['memory', '64'], ['powerpc_rma_log', '26'],
['shadow_memory', '1'], ['maxmem', '64'], ['features'], ['name',
'S-1160762357.95'], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'],
['on_crash', 'restart'], ['image', ['linux', ['kernel', '/root/vmlinux.strip'],
['ramdisk', '/root/ramdisk.image.gz'], ['args', 'xencons=tty128
console=tty128']]], ['state', '--'], ['shutdown_reason', 'poweroff'],
['cpu_time', '1.17065513'], ['online_vcpus', '1'], ['up_time', '59.548593998'],
['start_time', '1160762358.2'], ['store_mfn', '131070'], ['console_mfn',
'131069']]
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:398)
parseConfig: result is {'shadow_memory': 1, 'powerpc_rma_log': 26,
'bootloader': None, 'on_reboot': 'restart', 'localtime': None, 'image':
['linux', ['kernel', '/root/vmlinux.strip'], ['ramdisk',
'/root/ramdisk.image.gz'], ['args', 'xencons=tty128 console=tty128']],
'on_poweroff': 'destroy', 'bootloader_args': None, 'cpus': None, 'on_crash':
'restart', 'name': 'S-1160762357.95', 'backend': [], 'vcpus': 1, 'cpu_weight':
1.0, 'features': None, 'vcpu_avail': 1, 'memory': 64, 'device': [], 'maxmem':
64, 'cpu': None, 'uuid': '052ea7ad-8567-74dd-3096-6e447cb7f059'}
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:1247)
XendDomainInfo.construct: None
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:714)
Storing VM details: {'shadow_memory': '1', 'powerpc_rma_log': '26', 'on_crash':
'restart', 'on_reboot': 'restart', 'image': (linux (kernel
/root/vmlinux.strip) (ramdisk /root/ramdisk.image.gz) (args 'xencons=tty128
console=tty128')), 'on_poweroff': 'destroy', 'name': 'S-1160762357.95',
'xend/restart_count': '0', 'vcpus': '1', 'vcpu_avail': '1', 'memory': '64',
'maxmem': '64', 'uuid': '052ea7ad-8567-74dd-3096-6e447cb7f059'}
[2006-10-14 12:44:23 xend.XendDomainInfo 8887] DEBUG (XendDomainInfo:749)
Storing domain details: {'console/port': '2', 'name': 'S-1160762357.95',
'console/limit': '1048576', 'vm': '/vm/052ea7ad-8567-74dd-3096-6e447cb7f059',
'domid': '6', 'cpu/0/availability': 'online', 'memory/target': '65536',
'store/port': '1'}
[2006-10-14 12:44:23 xend 8887] DEBUG (balloon:127) Balloon: 215472 KiB free;
need 65536; done.
[2006-10-14 12:44:23 xend 8887] DEBUG (XendCheckpoint:155) [xc_restore]:
/usr/lib/xen/bin/xc_restore 4 6 16384 1 2
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore
start: max_pfn = 16384
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) Increased domain
reservation by 65536 KB
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) Reloading memory
pages: 0%
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 0/16384 at 2d97
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 1/16384 at 2d96
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 2/16384 at 2d95
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 3/16384 at 2d94
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 4/16384 at 2d9f
[2006-10-14 12:44:23 xend 8887] ERROR (XendCheckpoint:236) xc_linux_restore:
page 5/16384 at 2d9e
Re: [XenPPC] Where is htab?
Looking at xlate.c, the htab and entries are access in following way: struct vcpu *v = get_current(); struct domain *d = v-domain; struct domain_htab *htab = d-arch.htab; union pte volatile *pte; pte = htab-map[ptex]; htab-map is the HTAB, remember it is treated like an array. I've inserted this code into xen/arch/powerpc/domctl.c, just to see if I could recognize the htab before mapping back to user space. The 'current domain' has some entries that could be htab. However, the guest domain always contains 0s. current domain: (XEN) XEN_DOMCTL_getshadowlist: (XEN) dd-arch.htab.map: 0x0200 (XEN) rma_base_mfn: 0x4000 rma_size_mfn: 0x4000 (XEN) pte: 0x02000800 vsid: 0x181a80047001 rpn: 0x0349b196 (XEN) pte: 0x02000810 vsid: 0x rpn: 0x (XEN) pte: 0x02000820 vsid: 0x rpn: 0x guest domain: (XEN) d-arch.htab.map: 0x0010 (XEN) rma_base_mfn2: 0x0001c000 rma_size_mfn2: 0x4000 (XEN) pte: 0x00100800 vsid: 0x rpn: 0x (XEN) pte: 0x00100810 vsid: 0x rpn: 0x (XEN) pte: 0x00100820 vsid: 0x rpn: 0x How early in the guest run is this? Guest domain is up and running. Printing code is invoked via 'xm save'. Remember the h in htab stands for Hash, though it is odd to see a whole PTEG (group of 8 PTEs) to be clear for Linux (and you are only showing 3). 1) What is the arch.htab.map address? I thought Xen ran with translate off and without RMA? Xen runs that way but the domains run in RMA while in Real Mode and transalted (uses htab) when not. The when we create a domain we allocate the htab it will remain 0 until the domain creates the first entries. The first entries in Linux are created by the domain while it runs in the RMA. -JX After reading your note, I tried printing all non-zero rpns in guest domain. There are lots- in fact 'bios' got a watchdog timeout and reverted out of SLOF while printing... Think I was spooked yesterday, since even page 0 had no rpn address, and I thought every domain had to have 2 or 4 pages setup beginning at 0 ? Thanks ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xm save: adding couple domctl operations to access htab
I don't know if I'm off base but have you added appropriate code to linux? specifically arch/powerpc/platforms/xen/hcall.c ? Yes, this was the problem, but I had been looking at xen/arch/powerpc/hcalls.c, not realizing that you were pointing-out a different file... In face hcall.c resides on linux side while hcalls.c is part of xen. Also was surprise to me that linux was involved in this way... Somehow when Jimi spelled-out more detail, I finally realized a 2nd file was involved. Anyway, thanks for trying ;-) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Where is htab?
Looking at xlate.c, the htab and entries are access in following way: struct vcpu *v = get_current(); struct domain *d = v-domain; struct domain_htab *htab = d-arch.htab; union pte volatile *pte; pte = htab-map[ptex]; I've inserted this code into xen/arch/powerpc/domctl.c, just to see if I could recognize the htab before mapping back to user space. The 'current domain' has some entries that could be htab. However, the guest domain always contains 0s. current domain: (XEN) XEN_DOMCTL_getshadowlist: (XEN) dd-arch.htab.map: 0x0200 (XEN) rma_base_mfn: 0x4000 rma_size_mfn: 0x4000 (XEN) pte: 0x02000800 vsid: 0x181a80047001 rpn: 0x0349b196 (XEN) pte: 0x02000810 vsid: 0x rpn: 0x (XEN) pte: 0x02000820 vsid: 0x rpn: 0x guest domain: (XEN) d-arch.htab.map: 0x0010 (XEN) rma_base_mfn2: 0x0001c000 rma_size_mfn2: 0x4000 (XEN) pte: 0x00100800 vsid: 0x rpn: 0x (XEN) pte: 0x00100810 vsid: 0x rpn: 0x (XEN) pte: 0x00100820 vsid: 0x rpn: 0x 1) What is the arch.htab.map address? I thought Xen ran with translate off and without RMA? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xm-test can panic Xen on JS20
Similar panic whenever 'shutdown -h' on JS20 (using local ide for root fs): ... /dev/hda2 umounted done done Shutting down MD Raiddone Stopping udevd: done proc umounted The system will be halted immediately. Synchronizing SCSI cache for disk sda: Shutdown: hdc Shutdown: hda Power down. (XEN) [F960] 004246C4 .debugger_trap_immediate+0x18/0x28 (XEN) [F9E0] 004245E0 .dom0_shutdown+0x20/0xec (XEN) [FA70] 00405ACC .domain_shutdown+0x44/0x128 (XEN) [FB00] 004232DC .do_sched_op+0x15c/0x2e8 (XEN) [FBF0] 00439388 .hcall_xen+0xc4/0xf0 (XEN) [FC90] 004394A4 .do_hcall+0x54/0x84 (XEN) [FD20] 0044C278 ex_hcall_continued+0xe4/0xf4 (XEN) [00437EC8] 800100017C0802A6 (XEN) SP (60004bd8) is not in xen space (XEN) program_exception: type: 0x700 (XEN) [ Xen-3.0-unstable ] (XEN) CPU: DOMID: (XEN) pc 004246c4 msr 90029002 (XEN) lr 004246c4 ctr 0042f15c (XEN) srr0 srr1 (XEN) r00: 004246c4 f960 0074cb38 90009002 (XEN) r04: 0001 (XEN) r08: 0075229c 0075229c 00752228 (XEN) r12: 00439450 9080 1007 0001 (XEN) r16: 100a 100aa0b0 fff6 (XEN) r20: 0001 (XEN) r24: 1001 0001 4000 (XEN) r28: cb5a3b80 fd90 c0542160 f960 (XEN) dar 0xd8008016, dsisr 0x0220 (XEN) hid4 0x6240 (XEN) ---[ backtrace ]--- (XEN) [F9E0] 004245E0 .dom0_shutdown+0x20/0xec (XEN) [FA70] 00405ACC .domain_shutdown+0x44/0x128 (XEN) [FB00] 004232DC .do_sched_op+0x15c/0x2e8 (XEN) [FBF0] 00439388 .hcall_xen+0xc4/0xf0 (XEN) [FC90] 004394A4 .do_hcall+0x54/0x84 (XEN) [FD20] 0044C278 ex_hcall_continued+0xe4/0xf4 (XEN) [00437EC8] 800100017C0802A6 (XEN) SP (60004bd8) is not in xen space (XEN) machine_halt called (XEN) machine_halt failed, manual powercycle required! ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] save/restore: suspending DomU
2) How do you 'refresh' python? Answer: restart xend ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] LTC Wiki XenPPC/SLOF
Have updated LTC Wiki to include http://watgsa.ibm.com/projects/s/slof as local source for SLOF images. Could you please include local source for 'update_flash' utility as well (ie copy to //watgsa for examaple?) Can find this utility at klinux7:/home/reflash/slof/ ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] JS20 hangs while 'Quiescing Open Firmware ...'
SOL is broken on our older model bladecenter. To be clear, this is a problem with _your_specific_ blade center or older models if you can use SOL to talk to your linux console without Xen and you cannot _with_ Xen then we need to get to the bottom of that. SOL is broken on the 'older model' bladecenters - this has nothing to do with Xen, ie SOL does not work at all, Xen or not. When I place the blade in a newer bladecenter, SOL works ok. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] JS20 hangs while 'Quiescing Open Firmware ...'
sources mpic: Setting up HT PICs workarounds for U3/U4 mpic: - HT:01.0 [0xb8] vendor 1022 device 7450 has 4 irqs mpic: - HT:02.0 [0xb8] vendor 1022 device 7450 has 4 irqs mpic: - HT:03.0 [0xf0] vendor 1022 device 7460 has 24 irqs PID hash table entries: 1024 (order: 10, 8192 bytes) Maple: Found RTC at IO 0x1070 Console: colour dummy device 80x25 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 186004k/196608k available (5276k kernel code, 10264k reserved, 1212k data, 456k bss, 236k init) Mount-cache hash table entries: 256 Brought up 1 CPUs smp_xen_setup_cpu(0) migration_cost=0 grant table at c3ff Grant table initialized NET: Registered protocol family 16 *** : Linux ppc64 *** : 2.6.17-Xen Failed to request PCI IO region on PCI domain IDE Fixup IRQ: Can't find IO-APIC ! IOMMU table initialized, virtual merging enabled - maple_pcibios_fixup - maple_pcibios_fixup SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 2, 16384 bytes) TCP established hash table entries: 8192 (order: 5, 131072 bytes) TCP bind hash table entries: 4096 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered rtas_flash: no firmware flash support scan-log-dump not implemented on this system Initializing Cryptographic API io scheduler noop registered io scheduler deadline registered (default) Generic RTC Driver v1.07 RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize loop: loaded (max 8 devices) Intel(R) PRO/1000 Network Driver - version 7.0.38-k4 Copyright (c) 1999-2006 Intel Corporation. tg3.c:v3.60 (June 17, 2006) eth0: Tigon3 [partno(none) rev 2003 PHY(serdes)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:1e:34:40 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[0] TSOcap[0] eth0: dma_rwctrl[769f4000] dma_mask[64-bit] eth1: Tigon3 [partno(none) rev 2003 PHY(serdes)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:1e:34:41 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1] eth1: dma_rwctrl[769f4000] dma_mask[64-bit] Xen virtual console successfully installed as ttyS0 Event-channel device installed. blkif_init: reqs=64, pages=704, mmap_vstart=0xc0001f80 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx AMD8111: IDE controller at PCI slot :00:04.1 AMD8111: chipset revision 3 AMD8111: :00:04.1 (rev 03) UDMA133 controller AMD8111: 100% native mode on irq 16 ide0: BM-DMA at 0x8020-0x8027, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8028-0x802f, BIOS settings: hdc:pio, hdd:pio hda: TOSHIBA MK4019GAXB, ATA DISK drive ide0 at 0x8000-0x8007,0x800a on irq 16 hdc: TOSHIBA MK4019GAXB, ATA DISK drive ide1 at 0x8010-0x8017,0x801a on irq 16 hda: max request size: 128KiB hda: 78140160 sectors (40007 MB), CHS=65535/16/63 hda: cache flushes supported hda: hda1 hda2 hda3 hdc: max request size: 128KiB hdc: 78140160 sectors (40007 MB), CHS=65535/16/63 hdc: cache flushes supported hdc: hdc1 hdc2 hdc3 ipr: IBM Power RAID SCSI Device Driver version: 2.1.3 (March 29, 2006) scsi0 : scsi_debug, version 1.75 [20050113], dev_size_mb=8, opts=0x0 Vendor: Linux Model: scsi_debugRev: 0004 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 16384 512-byte hdwr sectors (8 MB) sda: Write Protect is off SCSI device sda: drive cache: write back SCSI device sda: 16384 512-byte hdwr sectors (8 MB) sda: Write Protect is off SCSI device sda: drive cache: write back sda: unknown partition table sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 usbmon: debugfs is not available ohci_hcd :03:00.0: OHCI Host Controller ohci_hcd :03:00.0: new USB bus registered, assigned bus number 1 ohci_hcd :03:00.0: irq 19, io mem 0xc010 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd :03:00.1: OHCI Host Controller ohci_hcd :03:00.1: new USB bus registered, assigned bus number 2 ohci_hcd :03:00.1: irq 19, io mem 0xc0101000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected USB Universal Host Controller Interface driver v3.0 usbcore: registered new driver usbhid /home/poff/linux-ppc-2.6-work.hg/drivers/usb/input/hid-core.c: v2.6:USB HID core driver pegasus: v0.6.13 (2005/11/13), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new driver pegasus usbcore: registered new driver usbserial /home/poff/linux-ppc-2.6-work.hg/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new driver usbserial_generic /home/poff/linux-ppc-2.6-work.hg
Re: [XenPPC] JS20 hangs while 'Quiescing Open Firmware ...'
If you want ssh, you need init scripts to run, so you're going to need to drop the init=/bin/bash here. Yes, that worked nicely - Was confused since when booting Dom0 with an nfs root, sshd comes up even though 'init=/sbin/quickinit noshell' ... looks like quickinit provides some services. 2. Looks like system is now sitting with root prompt? Can ping, but ssh gets 'connection refused'. (and cannot type at serial port, per usual) How is that usual? I've never been able to type at a serial port, JS21 or JS20. Thought it was an 'understood feature' (though never been clear to me;-) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] PATCH: Inline assembler for clear_page() and copy_page()
Following code includes assembler versions of clear_page_cacheable(), by
Xenidis,
copy_page(), and copy_page_cacheable(). The 'cacheable' versions use 'dcbz' for
clearing cache lines; the target page is assumed to be cacheable.
This code has been debugged with a small application program on JS21. Also code
has been incorporated into a xen tree and runs on JS21 (though copy_page() is
not
being used).
note: in some documentation, dcbz is for 32 byte cache lines, dcbzl for 128
However, the crossbuild assembler does not recognize dcbzl. The native assembler
(for building the test application) would accept either dcbz or dcbzl, and in
either
case the 128 byte cache line was cleared.
note2: in page_alloc.c, one of the three clear_page() calls breaks the system
when changed to clear_page_cacheable().
diff -r 326e6736d92b xen/include/asm-powerpc/page.h
--- a/xen/include/asm-powerpc/page.hMon Aug 21 10:04:37 2006 -0400
+++ b/xen/include/asm-powerpc/page.hFri Aug 25 17:05:22 2006 -0400
@@ -70,8 +70,67 @@ typedef struct { unsigned long l1_lo; }
#define pfn_to_paddr(pfn) ((paddr_t)(pfn) PAGE_SHIFT)
#define paddr_to_pfn(pa)((unsigned long)((pa) PAGE_SHIFT))
+
extern void clear_page(void *p);
-extern void copy_page(void *dp, void *sp);
+
+static __inline__ void copy_page(void *dp, void *sp)
+{
+ unsigned long dwords, dword_size;
+
+ dword_size = 8;
+ dwords = (PAGE_SIZE / dword_size) - 1;
+
+ __asm__ __volatile__(
+ mtctr %2 # copy_page\n\
+ ld %2,0(%1)\n\
+ std %2,0(%0)\n\
+1: ldu %2,8(%1)\n\
+ stdu%2,8(%0)\n\
+ bdnz1b
+ : /* no result */
+ : r (dp), r (sp), r (dwords)
+ : %ctr, memory);
+}
+
+/* assumes page, *addr, is cacheable */
+static __inline__ void clear_page_cacheable(void *addr)
+{
+ unsigned long lines, line_size;
+
+ line_size = CACHE_LINE_SIZE;
+ lines = PAGE_SIZE / CACHE_LINE_SIZE;
+
+ __asm__ __volatile__(
+ mtctr %1 # clear_page\n\
+1: dcbz 0,%0\n\
+ add %0,%0,%3\n\
+ bdnz1b
+: =r (addr)
+: r (lines), 0 (addr), r (line_size)
+ : %ctr, memory);
+}
+
+/* assumes destination page, *dp, is cacheable */
+static __inline__ void copy_page_cacheable(void *dp, void *sp)
+{
+ unsigned long dwords, dword_size;
+
+ dword_size = 8;
+ dwords = (PAGE_SIZE / dword_size) - 1;
+
+ clear_page_cacheable(dp);
+
+ __asm__ __volatile__(
+ mtctr %2 # copy_page\n\
+ ld %2,0(%1)\n\
+ std %2,0(%0)\n\
+1: ldu %2,8(%1)\n\
+ stdu%2,8(%0)\n\
+ bdnz1b
+ : /* no result */
+ : r (dp), r (sp), r (dwords)
+ : %ctr, memory);
+}
#define linear_pg_table linear_l1_table
diff -r 326e6736d92b xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Mon Aug 21 10:04:37 2006 -0400
+++ b/xen/arch/powerpc/mm.c Fri Aug 25 17:08:02 2006 -0400
@@ -97,16 +97,6 @@ void clear_page(void *page)
}
}
-extern void copy_page(void *dp, void *sp)
-{
-if (on_mambo()) {
-extern void *mambo_memcpy(void *,const void *,__kernel_size_t);
-mambo_memcpy(dp, sp, PAGE_SIZE);
-} else {
-memcpy(dp, sp, PAGE_SIZE);
-}
-}
-
ulong pfn2mfn(struct domain *d, long pfn, int *type)
{
ulong rma_base_mfn = page_to_mfn(d-arch.rma_page);
diff -r 326e6736d92b xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Mon Aug 21 10:04:37 2006 -0400
+++ b/xen/common/page_alloc.c Fri Aug 25 17:09:12 2006 -0400
@@ -412,13 +412,13 @@ void scrub_heap_pages(void)
{
p = page_to_virt(mfn_to_page(pfn));
memguard_unguard_range(p, PAGE_SIZE);
-clear_page(p);
+clear_page_cacheable(p);
memguard_guard_range(p, PAGE_SIZE);
}
else
{
p = map_domain_page(pfn);
-clear_page(p);
+clear_page_cacheable(p);
unmap_domain_page(p);
}
}
@@ -794,7 +794,7 @@ static void page_scrub_softirq(void)
pg = list_entry(ent, struct page_info, list);
ent = ent-prev;
p = map_domain_page(page_to_mfn(pg));
-clear_page(p);
+clear_page(p); /* some pages not
cacheable? */
unmap_domain_page(p);
free_heap_pages(pfn_dom_zone_type(page_to_mfn(pg)), pg, 0);
}
diff -r 326e6736d92b xen/arch/powerpc/domain.c
--- a/xen/arch/powerpc/domain.c Mon Aug 21 10:04:37 2006 -0400
+++ b/xen/arch/powerpc/domain.c Fri Aug 25 17:07:58 2006 -0400
@@ -79,7 +79,7 @@ int arch_domain_create(struct domain *d)
if (d-domain_id == IDLE_DOMAIN_ID) {
d-shared_info = (void *)alloc_xenheap_page();
-clear_page(d-shared_info);
+clear_page_cacheable(d-shared_info);
return 0;
}
[XenPPC] [xenppc-unstable] [POWERPC] RFC: memory clean up
This code walks the OF dev tree, finding end-of-memory and memory holes.
All memory beyond the hypervisor's RMA is added to domheap. (Previously
only memory upto 1st hole was used.) Finally, parts of setup.c have been
swept into memory.c as cleanup.
diff -r 9c72449e4370 xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Fri Aug 18 17:52:04 2006 -0500
+++ b/xen/arch/powerpc/setup.c Tue Aug 22 09:52:03 2006 -0400
@@ -43,6 +43,7 @@
#include asm/percpu.h
#include exceptions.h
#include of-devtree.h
+#include memory.h
#define DEBUG
unsigned long xenheap_phys_end;
@@ -195,7 +196,7 @@ void startup_cpu_idle_loop(void)
reset_stack_and_jump(idle_loop);
}
-static ulong free_xenheap(ulong start, ulong end)
+ulong free_xenheap(ulong start, ulong end)
{
start = ALIGN_UP(start, PAGE_SIZE);
end = ALIGN_DOWN(end, PAGE_SIZE);
@@ -217,10 +218,6 @@ static void __init __start_xen(multiboot
{
char *cmdline;
module_t *mod = (module_t *)((ulong)mbi-mods_addr);
-ulong heap_start;
-ulong eomem = 0;
-ulong heap_size = 0;
-ulong bytes = 0;
ulong freemem;
ulong dom0_start, dom0_len;
ulong initrd_start, initrd_len;
@@ -267,61 +264,8 @@ static void __init __start_xen(multiboot
mod[mbi-mods_count-1].mod_end = 0;
--mbi-mods_count;
-printk(Physical RAM map:\n);
-
-/* lets find out how much memory there is */
-while (bytes mbi-mmap_length) {
-u64 end;
-u64 addr;
-u64 size;
-
-memory_map_t *map = (memory_map_t *)((ulong)mbi-mmap_addr + bytes);
-addr = ((u64)map-base_addr_high 32) | (u64)map-base_addr_low;
-size = ((u64)map-length_high 32) | (u64)map-length_low;
-end = addr + size;
-
-printk( %016lx - %016lx (usable)\n, addr, end);
-
-if (addr eomem) {
-printk(found a hole skipping remainder of memory at:\n
-%016lx and beyond\n, addr);
-break;
-}
-if (end eomem) {
-eomem = end;
-}
-bytes += map-size + 4;
-}
-
-printk(System RAM: %luMB (%lukB)\n, eomem 20, eomem 10);
-
-/* top of memory */
-max_page = PFN_DOWN(ALIGN_DOWN(eomem, PAGE_SIZE));
-total_pages = max_page;
-
-/* Architecturally the first 4 pages are exception hendlers, we
- * will also be copying down some code there */
-heap_start = 4 PAGE_SHIFT;
-if (oftree (ulong)_start)
-heap_start = ALIGN_UP(oftree_end, PAGE_SIZE);
-
-heap_start = init_boot_allocator(heap_start);
-if (heap_start (ulong)_start) {
-panic(space below _start (%p) is not enough memory
- for heap (0x%lx)\n, _start, heap_start);
-}
-
-/* we give the first RMA to the hypervisor */
-xenheap_phys_end = rma_size(cpu_rma_order());
-
-/* allow everything else to be allocated */
-init_boot_pages(xenheap_phys_end, eomem);
-init_frametable();
-end_boot_allocator();
-
-/* Add memory between the beginning of the heap and the beginning
- * of out text */
-free_xenheap(heap_start, (ulong)_start);
+xenheap_phys_end = setup_memory();
+
freemem = ALIGN_UP((ulong)_end, PAGE_SIZE);
for (i = 0; i mbi-mods_count; i++) {
@@ -355,10 +299,6 @@ static void __init __start_xen(multiboot
/* make sure the OF devtree is good */
ofd_walk((void *)oftree, OFD_ROOT, ofd_dump_props, OFD_DUMP_ALL);
#endif
-
-heap_size = xenheap_phys_end - heap_start;
-
-printk(Xen heap: %luMB (%lukB)\n, heap_size 20, heap_size 10);
percpu_init_areas();
./xen/arch/powerpc/memory.c:
#include xen/sched.h
#include xen/mm.h
#include of-devtree.h
#include oftree.h
#include memory.h
typedef ulong (*walk_mem_fn)(ulong *membuf, int entries, ulong ret, ulong arg);
static ulong ofd_walk_mem(void *m, walk_mem_fn fn, ulong arg);
static ulong end_of_mem(ulong *membuf, int entries, ulong end, ulong unused);
static ulong init_unused_pages(ulong *membuf, int entries, ulong ret, ulong
freemem);
ulong setup_memory(void)
{
ulong eomem, holes;
ulong heap_start, xenheap_phys_end, heap_size;
printk(Physical RAM map:\n);
/* lets find out how much memory there is */
eomem = ofd_walk_mem((void *)oftree, end_of_mem, 0 /*unused*/);
if (eomem == 0){
panic(ofd_walk_mem((void *)oftree, end_of_mem, 0 /*unused*/)
failed\n);
}
printk(End of RAM: %luMB (%lukB)\n, eomem 20, eomem 10);
/* top of memory */
max_page = PFN_DOWN(ALIGN_DOWN(eomem, PAGE_SIZE));
/* Architecturally the first 4 pages are exception hendlers, we
* will also be copying down some code there */
heap_start = 4 PAGE_SHIFT;
if (oftree (ulong)_start)
heap_start = ALIGN_UP(oftree_end, PAGE_SIZE);
heap_start = init_boot_allocator(heap_start);
if (heap_start (ulong)_start) {
panic(space below _start (%p) is not enough memory
for heap (0x%lx)\n, _start, heap_start);
}
/* we give the first
Re: [XenPPC] [xenppc-unstable] [POWERPC] Enable gcc -Wshadow and fix the warnings
wow, thats a little unexpected, what version of gcc is that?
anyway, does the following patch solve the issue?
-JX
diff -r dbe9249ba61b xen/include/asm-powerpc/current.h
--- a/xen/include/asm-powerpc/current.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/include/asm-powerpc/current.h Sun Aug 20 21:11:22 2006 -0400
@@ -66,7 +66,7 @@ static inline struct cpu_user_regs *gues
static inline void reset_stack_and_jump(void (*f)(void))
{
-void _reset_stack_and_jump(void (*f)(void), struct cpu_user_regs
*regs);
+void _reset_stack_and_jump(void (*)(void), struct cpu_user_regs *);
struct cpu_user_regs *regs = guest_cpu_user_regs();
#ifdef TRACK_RESUME
Yes, this patch solved the problem.
Yet another shadow problem (this seems to be the last one):
powerpc64-unknown-linux-gnu-gcc -m64 -ffreestanding -fno-builtin -fno-common
-fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe
-I/home/poff/xenppc-unstable-work7.hg/xen/include
-I/home/poff/xenppc-unstable-work7.hg/xen/include/asm-powerpc/mach-generic
-I/home/poff/xenppc-unstable-work7.hg/xen/include/asm-powerpc/mach-default
-Wpointer-arith -Wredundant-decls -Wpacked -msoft-float -O2 -O0 -g -D__XEN__
-DVERBOSE -DCRASH_DEBUG -Wundef -Wmissing-prototypes -Wmissing-declarations
-Wshadow -c dart.c -o dart.o
In file included from dart.c:29:
oftree.h:28: warning: declaration of 'oftree' shadows a global declaration
oftree.h:24: warning: shadowed declaration is here
make[3]: *** [dart.o] Error 1
gcc version:
powerpc64-unknown-linux-gnu-gcc -v
Reading specs from
/opt/crosstool/powerpc64-unknown-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/powerpc64-unknown-linux-gnu/3.4.1/specs
Configured with:
/home/poff/crosstool-0.28-rc35/build/powerpc64-unknown-linux-gnu/gcc-3.4.1-glibc-2.3.3/gcc-3.4.1/configure
--target=powerpc64-unknown-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/opt/crosstool/powerpc64-unknown-linux-gnu/gcc-3.4.1-glibc-2.3.3
--disable-multilib
--with-sysroot=/opt/crosstool/powerpc64-unknown-linux-gnu/gcc-3.4.1-glibc-2.3.3/powerpc64-unknown-linux-gnu/sys-root
--with-local-prefix=/opt/crosstool/powerpc64-unknown-linux-gnu/gcc-3.4.1-glibc-2.3.3/powerpc64-unknown-linux-gnu/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99
--enable-long-long
Thread model: posix
gcc version 3.4.1
--
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [POWERPC] Enable gcc -Wshadow and fix the warnings
Addition of -Wshadow generates warnings when compiling powerpc64/asm-offsets.c diff -r 0af18fd083ed -r b10e48a5d1e3 xen/arch/powerpc/Makefile --- a/xen/arch/powerpc/Makefile Fri Aug 18 05:00:37 2006 -0400 +++ b/xen/arch/powerpc/Makefile Fri Aug 18 05:17:14 2006 -0400 @@ -47,6 +47,7 @@ obj-y += elf32.o # These are extra warnings like for the arch/ppc directory but may not # allow the rest of the tree to build. PPC_C_WARNINGS += -Wundef -Wmissing-prototypes -Wmissing-declarations +PPC_C_WARNINGS += -Wshadow CFLAGS += $(PPC_C_WARNINGS) make -f /home/poff/xenppc-unstable-work7.hg/xen/Rules.mk -C arch/powerpc asm-offsets.s make[2]: Entering directory `/home/poff/xenppc-unstable-work7.hg/xen/arch/powerpc' powerpc64-unknown-linux-gnu-gcc -m64 -ffreestanding -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -pipe -I/home/poff/xenppc-unstable-work7.hg/xen/include -I/home/poff/xenppc-unstable-work7.hg/xen/include/asm-powerpc/mach-generic -I/home/poff/xenppc-unstable-work7.hg/xen/include/asm-powerpc/mach-default -Wpointer-arith -Wredundant-decls -Wpacked -msoft-float -O2 -O0 -g -D__XEN__ -DVERBOSE -DCRASH_DEBUG -Wundef -Wmissing-prototypes -Wmissing-declarations -Wshadow -S -o asm-offsets.s powerpc64/asm-offsets.c In file included from /home/poff/xenppc-unstable-work7.hg/xen/include/asm/smp.h:26, from /home/poff/xenppc-unstable-work7.hg/xen/include/xen/smp.h:13, from /home/poff/xenppc-unstable-work7.hg/xen/include/asm/spinlock.h:25, from /home/poff/xenppc-unstable-work7.hg/xen/include/xen/spinlock.h:39, from /home/poff/xenppc-unstable-work7.hg/xen/include/xen/sched.h:7, from powerpc64/asm-offsets.c:9: /home/poff/xenppc-unstable-work7.hg/xen/include/asm/current.h: In function `reset_stack_and_jump': /home/poff/xenppc-unstable-work7.hg/xen/include/asm/current.h:69: warning: declaration of 'f' shadows a parameter /home/poff/xenppc-unstable-work7.hg/xen/include/asm/current.h:67: warning: shadowed declaration is here make[2]: *** [asm-offsets.s] Error 1 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend error messages
We have xen running on an Intel blade with SuSE10; may be helpful to view scripts logs... ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
