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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 28 Apr 2004 07:52:40 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 28 Apr 2004 07:56:47 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 27 Apr 2004 18:24:28 PDT." <20040427181626.I31878@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
> >
> > 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.

Try adding some tracing to do_console_io() in Xen. If the problem is
fixed by rebuilding Xen with debugging enabled then the problem is
almost certainly somewhere in that function. It's rather a small
function so it shouldn't be very hard to find.

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

If Xen's own output is going to the serial line then your options on
Xen's command line are correct. Xenolinux's command line should
contain 'console=xencons0'.

> >
> > 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
> offender?

Nope, they're not supported in stock 2.4 kernels.

The fault is entirely harmless --- XL has switched LDT before
rewriting FS and GS. The old GS is no longer valid and so Xen can't
restore it. It gets pushed on XL's stack and a special handler in XL
gets called. This handler simply throws away GS and resets it to zero
(correct behaviour in this case because this is probably happening
during an exec(), when old execution state will be thrown away

 -- Keir

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

<Prev in Thread] Current Thread [Next in Thread>