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

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

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 */
-    console_end_sync();
+//    console_end_sync();

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@redhat.com>
      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
       <0>Rebooting in 180 seconds..

It seems that boot parameters (root=/dev/hda3) is not passed to dom0

this is probably a cmdline problem, almost always is

3. I also cannot boot the official XenPPC in XenSource, which I already
      Welcome to yaboot version 10.1.14-r716.SuSE
      booted from '/ht/[EMAIL PROTECTED],1/[EMAIL PROTECTED]'
      Enter "help" to get some basic usage information
      boot: xen
      Please wait, loading kernel...
      Can't find a loadable segment !

      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.

Xen-ppc-devel mailing list

Reply via email to