All of lore.kernel.org
 help / color / mirror / Atom feed
* Xen on Bochs
@ 2007-03-26 10:23 Richard W.M. Jones
  2007-03-26 12:14 ` Jan Beulich
  0 siblings, 1 reply; 2+ messages in thread
From: Richard W.M. Jones @ 2007-03-26 10:23 UTC (permalink / raw)
  To: xen-devel

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)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Xen on Bochs
  2007-03-26 10:23 Xen on Bochs Richard W.M. Jones
@ 2007-03-26 12:14 ` Jan Beulich
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Beulich @ 2007-03-26 12:14 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: xen-devel

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@redhat.com> 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@lists.xensource.com 
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-03-26 12:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-26 10:23 Xen on Bochs Richard W.M. Jones
2007-03-26 12:14 ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.