Re: [Xen-devel] Re: Continuing problems booting

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

M A Young wrote:
> On Wed, 4 Mar 2009, Jeremy Fitzhardinge wrote:
>
> > M A Young wrote:
> > > The QEMU boot still fails (pvops patch up-to-date as of 2 days ago), 
> > > probably because it is emulating an ide style cdrom drive which I 
> > > believe xen still has problems with (I have similar problems booting 
> > > a different system with ide disks). The boot log (bzipped) is attached. 
> > I committed a change to properly initialize legacy irqs, which might 
> > help with IDE devices.
> Yes, a recent update allows my qemu test environment to see its disk. 
> It crashes later, but in what looks to be a non-xen related way. 
> However booting the kernel non-xen crashes much faster with the traceback
> RAMDISK: gzip decompressor not configured!
It looks like you need to configure gzip compression for your initrd.  
Also, make sure you don't use any of the other compression algorithms 
for the kernel itself, or Xen won't be able to parse them.
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<(null)>] (null)
This looks like a bug.  HPA, will it fall down a NULL function pointer 
if you leave compression out?
   J
> PGD 0
> Oops: 0010 [#1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.29-0.114.2.6.rc7.fc10.x86_64 #1
> RIP: 0010:[<0000000000000000>]  [<(null)>] (null)
> RSP: 0018:ffff88003f76de38  EFLAGS: 00010246
> RAX: 0000000000000001 RBX: ffff88003b22dff0 RCX: ffffffff8162e4dc
> RDX: ffffffff8162e49c RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff88003f76ded0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000046 R11: ffff88003f76dde0 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff81625fa8
> FS:  0000000000000000(0000) GS:ffff880003000000(0000) 
> knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff88003f76c000, task 
> ffff88003f770000)
> Stack:
>  ffffffff8162e7a8 ffffffff8162e471 ffffffff811a5fca ffff880000000010
>  ffffffff814c6f0d 000000013f76de70 ffffffff00000000 ffff88003f76dea0
>  ffffffff814f0922 0000000000000000 ffffffff814c6d54 000000005c2d2f7c
> Call Trace:
>  [<ffffffff8162e7a8>] ? rd_load_image+0x27b/0x4dd
>  [<ffffffff8162e471>] ? error+0x0/0x2b
>  [<ffffffff811a5fca>] ? sscanf+0x38/0x3a
>  [<ffffffff8162eaa8>] initrd_load+0x31/0x2ed
>  [<ffffffff8162e37f>] prepare_namespace+0xe2/0x19d
>  [<ffffffff8162d73f>] kernel_init+0x21a/0x22a
>  [<ffffffff81012e6a>] child_rip+0xa/0x20
>  [<ffffffff81012850>] ? restore_args+0x0/0x30
>  [<ffffffff8162d525>] ? kernel_init+0x0/0x22a
>  [<ffffffff81012e60>] ? child_rip+0x0/0x20
> Code:  Bad RIP value.
> RIP  [<(null)>] (null)
>  RSP <ffff88003f76de38>
> CR2: 0000000000000000
> ---[ end trace a678a5d887494ac4 ]---
> swapper used greatest stack depth: 4272 bytes left
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: swapper Tainted: G      D 
> 2.6.29-0.114.2.6.rc7.fc10.x86_64 #1
> Call Trace:
>  [<ffffffff813a6544>] panic+0x7a/0x13b
>  [<ffffffff81071368>] ? trace_hardirqs_on_caller+0x1f/0x151
>  [<ffffffff813a91b3>] ? _write_unlock_irq+0x30/0x3b
>  [<ffffffff8105092f>] ? do_exit+0x37c/0x8a9
>  [<ffffffff81050636>] do_exit+0x83/0x8a9
>  [<ffffffff813a6646>] ? printk+0x41/0x43
>  [<ffffffff813aa944>] oops_end+0xbf/0xc7
>  [<ffffffff81032e8d>] no_context+0x1f2/0x201
>  [<ffffffff81033046>] __bad_area_nosemaphore+0x1aa/0x1d0
>  [<ffffffff8102e046>] ? pvclock_clocksource_read+0x47/0x83
>  [<ffffffff811ab221>] ? debug_check_no_obj_freed+0x152/0x1c8
>  [<ffffffff813abd09>] ? do_page_fault+0x11a/0x27f
>  [<ffffffff8103307f>] bad_area_nosemaphore+0x13/0x15
>  [<ffffffff813abd71>] do_page_fault+0x182/0x27f
>  [<ffffffff813a9d65>] page_fault+0x25/0x30
>  [<ffffffff8162e4dc>] ? compr_flush+0x0/0x51
>  [<ffffffff8162e49c>] ? compr_fill+0x0/0x40
>  [<ffffffff8162e7a8>] ? rd_load_image+0x27b/0x4dd
>  [<ffffffff8162e471>] ? error+0x0/0x2b
>  [<ffffffff811a5fca>] ? sscanf+0x38/0x3a
>  [<ffffffff8162eaa8>] initrd_load+0x31/0x2ed
>  [<ffffffff8162e37f>] prepare_namespace+0xe2/0x19d
>  [<ffffffff8162d73f>] kernel_init+0x21a/0x22a
>  [<ffffffff81012e6a>] child_rip+0xa/0x20
>  [<ffffffff81012850>] ? restore_args+0x0/0x30
>  [<ffffffff8162d525>] ? kernel_init+0x0/0x22a
>  [<ffffffff81012e60>] ? child_rip+0x0/0x20
> so that might indicate that some recent change breaks a non-dom0 boot 
> (if I haven't done something to break it myself).
>     Michael Young
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel