Folks --
During the boot process of FreeBSD 6.0 on Xen 3.0 w/ VT-x hardware,
I'm experiencing a situation where Qemu gets an exception and dies
leaving the FreeBSD domain blocked.
Here is some relevant data I've collected on the Qemu side of the
fault (as opposed to anything on the FreeBSD side). I can't make
heads or tails out of it, but I think there's enough here for someone
to give me directions on where next to look.
(gdb) bt
#0 breakyourboneshere ()
at /home/goodson/xen-3.0-testing/tools/ioemu/exec.c:391
#1 0x0000000000408682 in cpu_physical_memory_rw (addr=3228123076,
buf=0x2abf96849020 <Address 0x2abf96849020 out of bounds>, len=4,
is_write=1) at /home/goodson/xen-3.0-testing/tools/ioemu/exec.c:446
#2 0x000000000043d722 in cpu_ioreq_move (env=Variable "env" is not
available.) at helper2.c:274
#3 0x000000000043d953 in cpu_handle_ioreq (env=0x1831c40) at
helper2.c:431
#4 0x000000000043dbf1 in main_loop () at helper2.c:511
#5 0x0000000000407c90 in main (argc=Variable "argc" is not available.)
at /home/goodson/xen-3.0-testing/tools/ioemu/vl.c:3447
First, "breakyourboneshere()" is a routine I wrote that I could put a
break point on before the seg fault happens. It's called like:
addr1 = (pd & TARGET_PAGE_MASK) + (addr &
~TARGET_PAGE_MASK);
/* RAM case */
ptr = phys_ram_base + addr1;
{ extern void *shared_page;
unsigned long xyz = (unsigned long) ptr,
abc = (unsigned long) shared_page;
if ((xyz - abc) == 0xb0694fc4) {
breakyourboneshere();
}
}
memcpy(ptr, buf, l);
My colleague installed some tracing and found that the ioreq that has
caused this grief looks like:
(gdb) p/x ioreq_buffer[5]
$5 = {addr = 0xc0693fc4, size = 0x4, count = 0x1, u = {data = 0x56f50,
pdata = 0x56f50}, state = 0x1, pdata_valid = 0x0, dir = 0x0, df
= 0x0,
type = 0x1, io_count = 0x6714f}
It's always the same request. What I can't figure out is what the
guest domain code thinks it's doing.
Anybody got any ideas? Any tests you'd like me to perform? Running
tests takes on the order of a few minutes.
What I'd like to know is where in FreeBSD we are, exactly. What I
can say is that in the guest domain we have:
1) Entered grub
2) booted the FreeBSD loader (btx, btxldr for those who know about
these things)
3) "loader" (?) brought up a boot screen of its own (it's Forth code,
if you must know)
4) The timer on the boot screen timed out and immediately after that
the above iorequest arrived and causes Qemu to seg fault.
Is there any way to get the guest domain context from within Qemu?
I'd like to know the guest domain register set for the code issuing
this ioreq.
Any tips or ideas will be appreciated.
-- Randy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home