WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] Console problem on domU on tip?

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Console problem on domU on tip?
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Thu, 15 Dec 2005 09:39:22 -0800
Delivery-date: Thu, 15 Dec 2005 17:41:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYBELBGMu7ZHSeYRUaEav49mCDvgwAAVFMwAADLrDAAIbQEoA==
Thread-topic: [Xen-ia64-devel] Console problem on domU on tip?
> >Is this code fragment necessary for VTI to boot domU
> >or is it OK to remove?
> 
>       The comment is inaccurate and it should be domU. That I/D cache
> sync step is mandatory to boot domU on new IA64 processor which has
> split L2 I/D cache. If without such I/D cache sync, control 
> panel loads
> domU's kernel image which only affects D side cache. If there're some
> stale entry on I-side cache within same range of dom0 image, 
> people will
> see machine going weird.

I don't understand... how can there be stale entries in the I-cache?
The instructions have just been written to memory (through D-cache)
and no instructions in this domain have yet been executed.
I do see that the D-cache needs to be flushed so that memory is
coherent but are there better ways to do that without a pal call?

>       Normally I/D cache sync shouldn't force any problem. Possibly
> there's some problem with the pal calling code, like incorrect ITLB
> mapping for pal or similar issue...

Although the ia64_pal_cache_flush routine is defined in linux's pal.h,
it doesn't appear to be used anywhere in Linux so there is no use
model to copy.  I suspect there is some use model for the call that
we don't understand, for example maybe it should only be called with
physical &progress?  It definitely fails every time on one of
my (newer) machines and disabling the pal call makes the problem
go away.

Also, why panic if it fails?

> Though it's intermittent, please 
> keep this code
> there for correctness.

Since the call is definitely failing under some circumstances
that we don't understand, I'm inclined to at least put the code
in an #ifdef CONFIG_SPLIT_CACHE

Does the problem happen only on VTI?  Or both VTI and non-VTI on
split-cache machines?

Thanks,
Dan

P.S. I tried Anthony's patch (which moves the PAL call after
new_thread()) but it still crashes.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

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