[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.