Re: [XenPPC] Cannot boot from local disk

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

Kawachiya-san, thank you for the exhaustive analysis!

Could you make sure that you show the cmdline as both Xen _and_ Linux  
see it? I suspect that perhpas the order by which we evaluate the  
CMDLINE may be incorrect.
On Oct 6, 2006, at 7:38 AM, Kiyokuni Kawachiya wrote:

> > Kawachiya-san, seems that your problem today is different from
> > yesterday.  You have however not answered any of my questions.
> Some people in this list may be confusing, so let me summarize my boot
> problem.
>
> I am using JS20 (884241X) to run XenPPC, which is booted from local  
> disk
> through the /etc/yaboot.conf like this.
>
>       # header section
>       partition = 2
>       timeout = 600
>       default = xen
>       # image section
>       image = /boot/vmlinux
>           label = linux
>           root = /dev/hda3
>           append = " quiet sysrq=1 insmod=sym53c8xx insmod=ipr"
>           initrd = /boot/initrd
>       # kawatiya 2006/08/24
>       image = /boot/xen-3.0-unstable
>           label = xen
>           append = "xen -- root=/dev/hda3 sysrq=1 insmod=sym53c8xx
> insmod=ipr"
>
> However, I have several boot problems with recent versions.

This yaboot header looks ok.
Is the insmod object comming from the disk or a ramdisk you are  
imbedding into your Dom0 Image?

> 1. I could not boot our internal version which is a little bit old  
> version,
> but contains the SMP patch.
>    It failed like this.
>             :
>       Sharing PIC with Xen<6>mpic: Setting up MPIC "U3-MPIC"  
> version 1.2 at
> f8040000, max 4 CPUs
>       mpic: ISU size: 124, shift: 7, mask: 7f
>       mpic: Initializing for 124 sources
>       mpic: Setting up HT PICs workarounds for U3/U4
>       mpic:   - HT:01.0 [0xb8] vendor 1022 device 7450 has 4 irqs
>       mpic:   - HT:02.0 [0xb8] vendor 1022 device 7450 has 4 irqs
>       mpic:   - HT:03.0 [0xf0] vendor 1022 device 7460 has 24 irqs
>       PID hash table entries: 1024 (order: 10, 8192 bytes)
>       Maple: Found RTC at IO 0x1070
>       Console: colour dummy device 80x25
>       Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
>       Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
>       Memory: 185884k/196608k available (5296k kernel code, 10416k
> reserved, 1240k data,
>
>       I know this is caused by the SMP patch.
Could you synchronize the console here, there are two ways to do this:
  1) add "sync_console" to the cmdline _before_ "--"
  2) apply the follow diff
diff -r 701c68921ff3 xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c  Wed Oct 04 14:06:14 2006 -0400
+++ b/xen/arch/powerpc/setup.c  Fri Oct 06 07:54:26 2006 -0400
@@ -398,7 +398,7 @@ static void __init __start_xen(multiboot
     /* Hide UART from DOM0 if we're using it */
     serial_endboot();
-    console_end_sync();
+//    console_end_sync();
     domain_unpause_by_systemcontroller(dom0);
     startup_cpu_idle_loop();


> 2. When I reverted xen/arch/powerpc/setup.c to non-SMP version, I
> encountered another problem.
>             :
>       All bugs added by David S. Miller <davem@xxxxxxxxxx>
>       Root-NFS: No NFS server available, giving up.
>       VFS: Unable to mount root fs via NFS, trying floppy.
>       VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
>       Please append a correct "root=" boot option
>       Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
>        <0>Rebooting in 180 seconds..
>
>       It seems that boot parameters (root=/dev/hda3) is not passed  
> to dom0
> Linux.
this is probably a cmdline problem, almost always is


> 3. I also cannot boot the official XenPPC in XenSource, which I  
> already
> reported.
>             :
>       Welcome to yaboot version 10.1.14-r716.SuSE
>       booted from '/ht/ata@4,1/disk@0'
>       Enter "help" to get some basic usage information
>       boot: xen
>       Please wait, loading kernel...
>       Can't find a loadable segment !
>       boot:
>
>       I think this is related to the boot wrapper removal.
It probably is, which image do you copy for yaboot to use?

can you try:
  $ objcopy -S xen/xen-syms xen/xen.yaboot
and have yaboot load xen.yaboot

I seem to recall yaboot having difficulties with 32bit images, I'm  
surprised that the change sa made any difference.
-JX






_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel