[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: Booting Xen/ia64
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |