|
xen-devel
Re: [Xen-devel] pvgrub boot problems
On 04/05/2010 04:57 PM, Samuel Thibault wrote:
Jeremy, just to make sure, does the kbd semaphore patch not fix this
case too?
No, afraid not. I applied all the patches you posted today but I get
the same failure when using vfb.
But! With vfb disabled I could successfully boot. So there's some progress.
J
Jeremy Fitzhardinge, le Sat 27 Mar 2010 16:08:01 -0700, a écrit :
But with vfb enabled, I get a crash in "main":
sh-4.0# xm create -c f13pv64
Using config file "/etc/xen/f13pv64".
Started domain f13pv64 (id=2)
Xen Minimal OS!
start_info: 0xa99000(VA)
nr_pages: 0x20000
shared_inf: 0xbf450000(MA)
pt_base: 0xa9c000(VA)
nr_pt_frames: 0x9
mfn_list: 0x999000(VA)
mod_start: 0x0(VA)
mod_len: 0
flags: 0x0
cmd_line: (hd0,0)/grub/grub.conf
stack: 0x958980-0x978980
MM: Init
_text: 0x0(VA)
_etext: 0x691c4(VA)
_erodata: 0x82000(VA)
_edata: 0x8aae0(VA)
stack start: 0x958980(VA)
_end: 0x998f88(VA)
start_pfn: aa8
max_pfn: 20000
Mapping memory range 0xc00000 - 0x20000000
setting 0x0-0x82000 readonly
skipped 0x1000
MM: Initialise page allocator for ba2000(ba2000)-20000000(20000000)
MM: done
Demand map pfns at 20001000-2020001000.
Heap resides at 2020002000-4020002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x20001000.
Initialising scheduler
Thread "Idle": pointer: 0x2020002050, stack: 0xcb0000
Initialising xenbus
Thread "xenstore": pointer: 0x2020002800, stack: 0xcc0000
Dummy main: start_info=0x978a80
Thread "main": pointer: 0x2020002fb0, stack: 0xcd0000
Thread "pcifront": pointer: 0x2020003760, stack: 0xce0000
"main" "(hd0,0)/grub/grub.conf"
pcifront_watches: waiting for backend path to happear device/pci/0/backend
vbd 51712 is hd0
******************* BLKFRONT for device/vbd/51712 **********
backend at /local/domain/0/backend/vbd/2/51712
Failed to read /local/domain/0/backend/vbd/2/51712/feature-flush-cache.
20971520 sectors of 512 bytes
**************************
Thread "kbdfront": pointer: 0x2020004590, stack: 0xcf0000
******************* FBFRONT for device/vfb/0 **********
******************* KBDFRONT for device/vkbd/0 **********
backend at /local/domain/0/backend/vkbd/2/0
/local/domain/0/backend/vkbd/2/0 connected
************************** KBDFRONT
Thread "kbdfront" exited.
backend at /local/domain/0/backend/vfb/2/0
/local/domain/0/backend/vfb/2/0 connected
************************** FBFRONT
Thread "kbdfront close": pointer: 0x2020004590, stack: 0xcf0000
close fb: backend at /local/domain/0/backend/vfb/2/0
close kbd: backend at /local/domain/0/backend/vkbd/2/0
shutdown_kbdfront: error changing state to 5: ENOENT
Thread "kbdfront close" exited.
Booting 'Xen 2.6.32'
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /xen.gz console=com1,vga
kernel /xen.gz? Do you really want to load the Xen hypervisor?
:) Actually this is odd: if I try the same, I get
xc_dom_bzimageloader.c:350: panic: xc_dom_probe_bzimage_kernel: kernel is not a
bzImage
ERROR Invalid kernel: elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF
notes or '__xen_guest' section found.
instead. I do not have any issue booting the PV linux kernels, using a
3.4 hypervisor.
Samuel
Page fault at linear address 0x100953340, rip 0x4b798, regs 0xcdfa68, sp
0xcdfb18, our_sp 0xcdfa20, code 2
Thread: main
RIP: e030:[<000000000004b798>]
RSP: e02b:0000000000cdfb18 EFLAGS: 00010293
RAX: 0000000000e2e000 RBX: 0000000000cdfb98 RCX: 0000000100953338
RDX: 0000000000000001 RSI: 0000000000953188 RDI: 0000000000000000
RBP: 0000000000cdfb28 R08: 0000000100953338 R09: 0000000000e2c000
R10: 0000000000007ff0 R11: 0000000000200030 R12: 0000000000000003
R13: 0000002020304e18 R14: 0000000000000000 R15: 0000000000001200
base is 0xcdfb28 caller is 0x57ced
base is 0xcdfb88 caller is 0x3067
base is 0xcdfc88 caller is 0x5c1e3
base is 0xcdfcd8 caller is 0x5be3a
base is 0xcdfcf8 caller is 0x3db6
base is 0xcdfd38 caller is 0x402e
base is 0xcdfd58 caller is 0x8341
base is 0xcdfd98 caller is 0xaa2f
base is 0xcdfdd8 caller is 0x108ca
base is 0xcdfe88 caller is 0x10f62
base is 0xcdff48 caller is 0x4343
base is 0xcdff58 caller is 0x4b4ba
base is 0xcdffe8 caller is 0x33da
cdfb00: 18 fb cd 00 00 00 00 00 2b e0 00 00 00 00 00 00
cdfb10: 18 e8 0d 34 01 00 00 00 25 a0 d8 34 01 00 00 00
cdfb20: 98 fb cd 00 00 00 00 00 88 fb cd 00 00 00 00 00
cdfb30: ed 7c 05 00 00 00 00 00 25 a0 d8 34 01 00 00 00
cdfb10: 18 e8 0d 34 01 00 00 00 25 a0 d8 34 01 00 00 00
cdfb20: 98 fb cd 00 00 00 00 00 88 fb cd 00 00 00 00 00
cdfb30: ed 7c 05 00 00 00 00 00 25 a0 d8 34 01 00 00 00
cdfb40: 30 e8 0d 34 01 00 00 00 03 00 00 00 01 00 00 00
4b780: f2 b9 80 31 95 00 48 8b 04 f1 4c 8b 00 4c 89 04
4b790: f1 48 8b 08 48 8b 70 08 48 89 71 08 39 d7 74 49
4b7a0: be 01 00 00 00 41 b8 80 31 95 00 83 ea 01 8d 4a
4b7b0: 0c 48 89 f3 48 d3 e3 4c 8d 0c 18 41 89 51 10 4c
Pagetable walk from virt 100953340, base a9c000:
L4 = 000000013446d067 (0xa9d000) [offset = 0]
L3 = 0000000000000000 (0xfffffffffffff000) [offset = 4]
Page fault in pagetable walk (access to invalid memory?).
In this case the rip is:
(gdb) list *0x000000000004b798
0x4b798 is in alloc_pages (mm.c:276).
271 if ( i == FREELIST_SIZE ) goto no_memory;
272
273 /* Unlink a chunk. */
274 alloc_ch = free_head[i];
275 free_head[i] = alloc_ch->next;
276 alloc_ch->next->pprev = alloc_ch->pprev;
277
278 /* We may have to break the chunk a number of times. */
279 while ( i != order )
280 {
The stack backtrace maps to:
0x57ced:
handle_cow
/home/jeremy/hg/xen/unstable/extras/mini-os/arch/x86/traps.c:147
do_page_fault
/home/jeremy/hg/xen/unstable/extras/mini-os/arch/x86/traps.c:202
0x3067:
error_call_handler
??:0
0x5c1e3:
_realloc_r
/home/jeremy/hg/xen/unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/stdlib/../../../../../newlib-1.16.0/newlib/libc/stdlib/mallocr.c:2947
0x5be3a:
realloc
/home/jeremy/hg/xen/unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/stdlib/../../../../../newlib-1.16.0/newlib/libc/stdlib/realloc.c:19
0x3db6:
load_file
/home/jeremy/hg/xen/unstable/stubdom/grub/mini-os.c:165
0x402e:
load_image
/home/jeremy/hg/xen/unstable/stubdom/grub/mini-os.c:187
0x8341:
kernel_func
/home/jeremy/hg/xen/unstable/stubdom/grub/../grub-upstream/stage2/builtins.c:2713
0xaa2f:
run_script
/home/jeremy/hg/xen/unstable/stubdom/grub/../grub-upstream/stage2/cmdline.c:256
0x108ca:
run_menu
/home/jeremy/hg/xen/unstable/stubdom/grub/../grub-upstream/stage2/stage2.c:769
0x10f62:
cmain
/home/jeremy/hg/xen/unstable/stubdom/grub/../grub-upstream/stage2/stage2.c:1121
0x4343:
main
/home/jeremy/hg/xen/unstable/stubdom/grub/mini-os.c:763
0x4b4ba:
call_main
/home/jeremy/hg/xen/unstable/extras/mini-os/main.c:162
0x33da:
thread_starter
gdtoa-hexnan.c:0
Which looks to me like something about the kernel bzImage is upsetting it.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home