Re: pvgrub boot problems

[Jeremy Fitzhardinge <jeremy@goop.org>]

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.
>>      
>