This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] problems with latest unstable

To: Kip Macy <kmacy@xxxxxxxxxxx>
Subject: Re: [Xen-devel] problems with latest unstable
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 28 Apr 2004 01:28:17 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Wed, 28 Apr 2004 01:36:41 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 27 Apr 2004 11:56:08 PDT." <20040427113709.P31878@xxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> I have a dual-processor Opteron 242 with 8GB of RAM running 32-bit
> Fedora Core 1 (yes that means that 4GB is unused). I installed the
> latest unstable on it last night.
> I'm not sure what was happening because as currently configured it
> doesn't print anything past:
> (XEN) Device eth0 opened and ready for use.
> (XEN) Xen trace buffers: initialised
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Xen-ELF header found: 'GUEST_OS=linux,GUEST_VER=2.4,XEN_VER=1.3'
> (XEN)  Kernel image:  02800000->02992810
> (XEN)  Initrd image:  00000000->00000000
> (XEN)  Dom0 alloc.:   02c00000->12c00000
> (XEN)  Loaded kernel: c0000000->c01c6f08
> (XEN)  Init. ramdisk: c01c7000->c01c7000
> (XEN)  Phys-Mach map: c01c7000->c0207000
> (XEN)  Page tables:   c0207000->c0209000
> (XEN)  Start info:    c0209000->c020a000
> (XEN)  Boot stack:    c020a000->c020b000
> (XEN)  TOTAL:         c0000000->c0400000
> (XEN)  ENTRY ADDRESS: c0000000
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen).
> (XEN) Give DOM0 read access to all PCI devices
> (XEN) tg3: eth0: Link is up at 1000 Mbps, full duplex.
> (XEN) tg3: eth0: Flow control is off for TX and off for RX.
> 'ping' indicated that it would come up for about 20 seconds and then
> reboot. I enabled "debug ?= y" in Rules.mk and now it more or less
> works :-O. 


What compiler are you using?

The lack of DOM0 output with the non debug build suggests that
Linux is dieing before its got the console subsystem up (which
happens annoyingly late in the init sequence. 

To get around this, I often add a
'HYPERVISOR_console_write(printk_buf, sizeof(printk_buf)' to
printk in kernel/printk.c

> One interesting thing that is probably worth noting is that
> every time I type 'ls', I get the following on the console:
> (XEN) (file=traps.c, line=460) GPF (0004): fc5e3fa8 -> fc5f1fc5

Hmm. This may suggest that Fedora has yet another sick and
twisted way of abusing segment registers for referencing thread
local storage for posix threads, and we're hitting an unexpected
(and probably slow) code path...

It might help to see an strace and an output of ldconfig -v, but
I suspect we'd need to recreate the setup to get anywhere. 


This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
Xen-devel mailing list