[Xen-devel] RE: Booting Xen/ia64

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

I've asked for info on this from an HP-internal mailing list.
Today is a US Holiday so I may not get a reply until tomorrow.

I think the problem is that firmware is considering lack
of response from the second CPU to be a boot error.  On my
machine, it is not, but my machine has older firmware.

On my machine, I get a pause for several seconds at this
point and then the boot continues.   It looks like yours
is expecting user input... perhaps if you have a USB
keyboard connected, firmware will accept input from it?

Dan

> -----Original Message-----
> From: Håvard Bjerke [mailto:Havard.Bjerke@xxxxxxxxxxx] 
> Sent: Monday, January 17, 2005 3:44 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: Booting Xen/ia64
> 
> I tried to build again, freshly from ftp, and this is how far 
> it booted:
> 
> Loading.: Scientific Linux CERN                                     
> Starting: Scientific Linux CERN
> 
> ELILO boot: Loading xen...Loading Linux... ..done
> Loading initrd xenlinux...done
> Linux version 2.6.9 (root@oplapro05) (gcc version 3.2.3 
> 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Mon Jan 17 10:03:22
> EFI v1.00 by Xen/ia64: SALsystab=0x8000178 ACPI 
> 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000
> warning: unable to switch EFI into virtual mode 
> (status=9223372036854775811)
> No I/O port range found in EFI memory map, falling back to AR.KR0
> I/O port base = 0x0
> SAL 0.1: Xen/ia64 Xen/ia64 version 0.0
> get_max_cacheline_size: ia64_pal_cache_summary() failed (status=-1)
> PAL_VM_PAGE_SIZE failed with status=-1;defaulting to 
> architected purge page-sizes.
> cpu_init: PAL VM summary failed, assuming 18 RID bits
> ACPI: Local APIC address c0000000fee00000
> GSI 36 (level, low) -> CPU 0 (0x0000) vector 48
> 2 CPUs available, 2 CPUs total
> PCDPt 0xe00000003fb2c000
> GSI 82 (level, low) -> CPU 0 (0x0000) vector 49
> PCDP: serial console at MMIO 0xf8030000 (ttyS0, options 9
> Built 1 zonelists
> Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\xen  nomca 
> console=ttyS0 console=tty0 root=/dev/sda2 ro
> P table entries: 1024 (order: 10, 32768 bytes)
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 65536 (order: 5, 524288 bytes)
> Inode-cache hash table entries: 32768 (order: 4, 262144 bytes)
> Memory: 508288k/523264k available (6786k code, 14592rved, 
> 3278k data, 208k init)
> McKinley Errata 9 workaround not needed; disabling it
> Mount-cache hash table entries: 1024 (order 0, 16384 bytes)
> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> 
> ************* SYSTEM ALERT **************
> SYSTEM NAME: moplapro05
> 
> 17 Jan 2005 10:21:59
> Alert Level 3: Warning
> Keyword: BOOT_SLAVE_NO_FINAL_WAKEUP_VECTOR
> Slave wakeup before vector registered
> Logged by: System Firmware  1
> Data: Implementation dependent data field
> 0x7680005B01E01F50 0000000000000001
> 
> A: ack read of this entry - X: Disable all future alert messages
> Anything else skip redisplay the log entry
> ->Choice:Timeout!
> *****************************************
> 
> 
> Your *.good binaries still boot fine, and we're using the 
> same gcc version:
> 
> >gcc --version
> gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
> 
> 
> Håvard
> 
> On Fri, Jan 14, 2005 at 11:21:27AM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> > Just wanted to let you know I am still working on your problem.
> > (I was tied up with other commitments most of yesterday.)
> > 
> > Just to verify, I rebuilt everything from the ftp site to ensure
> > I had the same xen/xenlinux bits as you and was able to successfully
> > boot and run.  I'm wondering if we might be seeing compiler
> > or hardware differences?  Now that you have serial port output,
> > could you rebuild from the ftp bits and let me know if you
> > are still having problems.  And if you still have problems,
> > could you send me the serial output (as you did below).
> > 
> > Regarding the output below, after studying it a bit, I realize
> > it is a result of an unprivified xenlinux. 
> > 
> > > -----Original Message-----
> > > From: Håvard Bjerke [mailto:havarbj@xxxxxxxxxxx] 
> > > Sent: Wednesday, January 12, 2005 9:53 AM
> > > To: Magenheimer, Dan (HP Labs Fort Collins)
> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > > Subject: Re: Booting Xen/ia64
> > > 
> > > On Wed, Jan 12, 2005 at 07:30:49AM -0600, 
> > > dan.magenheimer@xxxxxx wrote:
> > > > Did you try your binaries with the changed serial?  If so,
> > > > how far did it get?  (no output or did a few messages 
> get printed)
> > > 
> > > This is how far it gets when using my own built xen and your 
> > > xenlinux.good binary:
> > > 
> > > (XEN) domain mem: type=40631872, attr=0x10000008000761, 
> > > range=[0xfffc00000a6bfc30-0xfffc0000126bfc30) (128MB)
> > > (XEN) About to call init_trace_bufs()
> > > (XEN) get_time_delta: called, not implemented
> > > (XEN) About to call startup_cpu_idle_loop()
> > > (XEN) get_time_delta: called, not implemented
> > > (XEN) update_dom_time: called, not implemented, skipping
> > > (XEN) current=fffc0000026b8000,shared_info=fffc00003f59c000
> > > (XEN) next=fffc000004074000,shared_info=0
> > > (XEN) schedule_tail: change to rr7 not yet implemented
> > > (XEN) vcpu_get_lid: WARNING: Getting cr.lid always returns zero
> > > (XEN) vcpu_get_lid: WARNING: Getting cr.lid always returns zero
> > > (XEN) **** vcpu_set_itv(65536): vitm=0, setting to 0
> > > (XEN) vcpu_get_lid: WARNING: Getting cr.lid always returns zero
> > > (XEN) vcpu_get_lid: WARNING: Getting cr.lid always returns zero
> > > (XEN) vcpu_get_lid: WARNING: Getting cr.lid always returns zero
> > > (XEN) *** CALLED SAL_SET_VECTORS.  IGNORED...
> > > (XEN) vcpu_enable_timer(1000000): interval set to 69882928 cycles
> > > Linux version 2.6.9 (djm@sportsman) (gcc version 3.2.3 
> > > 20030502 (Red Hat Linux 3.2.3-34)) #1 SMP Tue Dec 7 
> 21:25:04 MST 2004
> > > EFI v1.00 by Xen/ia64: SALsystab=0x8000178 ACPI 
> > > 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000
> > > warning: unable to switch EFI into virtual mode 
> > > (status=9223372036854775811)
> > > No I/O port range found in EFI memory map, falling back to AR.KR0
> > > I/O port base = 0x3fffffc000000
> > > SAL 0.1: Xen/ia64 Xen/ia64 version 0.0
> > > get_max_cacheline_size: ia64_pal_cache_summary() failed 
> (status=-1)
> > > PAL_VM_PAGE_SIZE failed with status=-1;defaulting to 
> > > architected purge page-sizes.
> > > cpu_init: PAL VM summary failed, assuming 18 RID bits
> > > ACPI: Local APIC address c0000000fee00000
> > > GSI 36 (level, low) -> CPU 0 (0x0000) vector 48
> > > 2 CPUs available, 2 CPUs total
> > > PCDP: v0 at 0xe00000003fb2c000
> > > GSI 34 (edge, high) -> CPU 0 (0x0000) vector 49
> > > PCDP: serial console at MMIO 0xff5e0000 (ttyS0, options 9600n8)
> > > Built 1 zonelists
> > > Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\xen  nomca 
> > > console=ttyS0 console=tty0 root=/dev/sda2 ro
> > > PID hash table entries: 2048 (order: 11, 65536 bytes)
> > > Console: colour VGA+ 80x25
> > > (XEN) Delivering first extint to domain: 
> > > ifa=0000000000000000, isr=0000020000000000, 
> > > itir=0000000000000000, iip=a0000001007c0cf0
> > > (XEN) psr.ic off, delivering 
> > > fault=5300,iip=a000000100003040,isr=00000a0400000000,PSCB.iip=
> > > a0000001007c0cf0
> > > 
> > > 
> 
> -- 
> Håvard K. F. Bjerke
> http://www.idi.ntnu.no/~havarbj/
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel