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: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] problems with latest unstable
From: Kip Macy <kmacy@xxxxxxxxxxx>
Date: Tue, 27 Apr 2004 18:24:28 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 28 Apr 2004 02:26:14 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1BIcvy-000260-00@xxxxxxxxxxxxxxxxx>
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>
References: <E1BIcvy-000260-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> What compiler are you using?

gcc 3.3.2 - I just recompiled a non-debug xen with Fedora's stock gcc
instead of one that I had compiled. It works fine for the moment, but
I haven't been running it for very long.

> 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.

I may just be passing the wrong parameter to grub, com1 is what is
mentioned in the HOWTO, that doesn't appear to be correct.

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

If futzing with the parameters doesn't work I'll do that.

> 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...

Probably. Might "set_tid_address()" or "set_thread_area()" be the

execve("/bin/ls", ["ls"], [/* 42 vars */]) = 0
uname({sys="Linux", node="curly.lab.netapp.com", ...}) = 0
set_tid_address(0)                      = -1 ENOSYS (Function not implemented)
brk(0)                                  = 0x805a40e
set_thread_area({entry_number:-1 -> -1, base_addr:0x805a680,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = -1 ENOSYS (Function
not implemented)


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