The stack trace isn't too meaningful without disassembly, but may it be that
you simply have a NULL initrd pointer with a non-zero initrd length? Something
like that must be happening, as what you're dying on is apparently the
ClearPageReserved() in free_init_pages(), which means you have a bad
'struct page' here (which is being derived from a virtual address).
Jan
>>> "Richard W.M. Jones" <rjones@xxxxxxxxxx> 26.03.07 12:23 >>>
As a sort of evening/weekend project I've been trying to boot Xen on
Bochs. Latest version of Bochs, compiled with x86_64 support. Latest
unstable Xen (as of yesterday), also compiled for x86_64.
Currently dom0 oopses on boot as below.
I'll probably look into why this is happening later on, but just
wondered if anyone had any comments - eg. they've seen this before, or
running Xen on Bochs is a fool's errand, or whatever.
Rich.
Software IO TLB enabled:
Aperture: 2 megabytes
Kernel range: ffff880000967000 - ffff880000b67000
Address size: 25 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 929016k/962352k available (1992k kernel code, 24512k reserved,
866k data
, 172k init)
calibrate_delay_direct() failed to get a good estimate for loops_per_jiffy.
Probably due to long platform interrupts. Consider using "lpj=" boot option.
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 0K (0 bytes/line), D cache 0K (0 bytes/line)
CPU: L2 Cache: 0K (0 bytes/line)
SMP alternatives: switching to UP code
Freeing SMP alternatives: 24k freed
Unable to handle kernel paging request at 0000000001011218 RIP:
[<ffffffff80217d44>] free_init_pages+0x73/0x30a
PGD 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.18-xen #1
RIP: e030:[<ffffffff80217d44>] [<ffffffff80217d44>]
free_init_pages+0x73/0x30a
RSP: e02b:ffffffff804e3f78 EFLAGS: 00010206
RAX: 0000000001011218 RBX: ffffffff804e5000 RCX: 0000000000000000
RDX: ffff880001000000 RSI: 00000000deadbeef RDI: 00000000deadbeef
RBP: 00000000004e5000 R08: 0000000000000024 R09: 0000000000000001
R10: 00000000ffffffff R11: ffffffff802ff73a R12: 000077ff804e5000
R13: ffffffff804eb000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff804cb000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000
Process swapper (pid: 0, threadinfo ffffffff804e2000, task ffffffff80457d60)
Stack: 0000000000000297 0000000000000000 0000000000000000 0000000000000000
0000000000000000 ffffffff804eb7c3 0000000000000000 0000000000000000
ffffffff80523fe0 ffffffff804eb20d ffff800000000000 ffff804000000000
Call Trace:
[<ffffffff804eb7c3>] start_kernel+0x25f/0x26e
[<ffffffff804eb20d>] _sinittext+0x20d/0x213
Code: 0f ba 30 0a 48 b8 ff ff ff 7f ff ff ff ff 48 8b 15 9f 5a 33
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home