The console from today's Xen booting on JS21, 4gb memory
Booting just hangs
SLOF
u4 DDR2 memory controller setup
---
> detecting DIMM configuration: 4096Mb @ 400Mhz, CL 3
> initializing memory :
[reset core clock: ]OK
[register setup :
>Are you building your dom0 as a vmlinux.strip?
Yes, switching to zImage worked, thanks.
Can you explain what changed? - ie vmlinux.strip used to work.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc
gt; @@ -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_WA
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
ding -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
-Wpoint
> hey dan, could you make -k (which tell make to keep going on failure)
> and see if any more crop up
> -JX
Just pulled xen tree again, and now compiles clean.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.co
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
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 JS2
> Break how? build? run? hang?
Never mind - Turns-out to be an out-of-memory problem.
Booting goes all way to 'Waiting for /dev to be fully populated... '
then soon starts out-of-memory info, repeatedly. Had assumed it was
caused by something wrong in dcbz code. But when I added debug code
to
First time trying to boot Xen on JS20 -
using SLOF_633 and Xen tree pulled this morning.
SLOF
***
JS2XBlade Starting
Check ROM = OK
Build Date = Aug 14 2006 16:51:58
FW Version = JS2XFW6331
Press "s" to enter Open Firmw
: 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 H
> 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.
>
> hollis is correct, you should be able to get input even from SOL.
The input is not working with _serial_ port.
SOL is broken on our older model bladecenter.
Will SOL be necessary for 'reasonable debugging'?
___
Xen-ppc-devel mailing list
Xen-ppc-deve
>> 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 'o
n 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
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
c
>> 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.
> sorry to keep beating on this, but is this some early access
> bladecenter, you have a model
> I haven't seen this. Could you describe your platform (including memory,
> steps to reproduce, bug frequency), and attach your xm config file and
> boot log to a bug report please?
> http://bugzilla.xensource.com/bugzilla/, and assign to me.
Submitted, please let me know if need additional info
0 type 0
usbmon: debugfs is not available
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: regis
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/
___
1) As part of 'save', DomU is suspended, including some type of 'device
migration'.
cf 'def save' in XendCheckpoint.py Anyway, device migration does not return.
Wondering
if anyone has run this type of code?
2) How do you 'refresh' python? Modifying tools/python/xen/xend/*py for
debugging
the
> 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
Verified booting problems on JS20... Tail of serial output is below.
(SOL is not available on this blade chassis.)
Ping does not work, even after a few minutes.
...
Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 3.4.1) Mon Sep 25
17:42:43 ED6
Latest ChangeSet: Mon Sep 25 11:19:55 20
When saving a domain, its htab must be copied, real page numbers replaced with
physical,
then written to disk. To copy the htab, I've tried for many hours to add a
domctl operation,
#define XEN_DOMCTL_gethtab 29, using code and structures similar to
XEN_DOMCTL_getmemlist.
This new command make
> I don't know if I'm off base but have you added appropriate code to
> linux? specifically arch/powerpc/platforms/xen/hcall.c ?
An existing hypercall, viz #36, do_domctl, provides several commands to access
guest domains.
For example, XEN_DOMCTL_getmemlist and XEN_DOMCTL_max_mem. Thought I woul
Similar panic whenever 'shutdown -h' on JS20 (using local ide for root fs):
...
/dev/hda2 umounted done
done
Shutting down MD Raidd
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
>> 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, reme
> 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
'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
> 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 ini
> 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.
__
t)
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-
> 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 befo
'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 @ c004415
> 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
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, xen
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...
__
> 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 ne
> 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-p
> 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
>> 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
uct 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_res
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 usi
> 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
> > 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.
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 experiment
46 matches
Mail list logo
