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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Xu, Anthony
>Sent: 2005年12月16日 9:54
>
>>Also, why panic if it fails?
>>

Panic is not required here, and we could just print out a warning message. 
Previously panic is kept there to help our debug in early stage.

>
>
>>Does the problem happen only on VTI?  Or both VTI and non-VTI on
>>split-cache machines?
>
>Sometimes, it makes domain0 crash at the very beginning of the domain0 boot
>process, especially on MP machine.
>
>
>Thanks
>-Anthony

One complement is, that problem definitely exists on new split-cache 
processors, for dom0/domU. For VTI domain, we have logic within device model to 
ensure consistence.

Thanks,
Kevin
>
>
>>-----Original Message-----
>>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@xxxxxx]
>>Sent: 2005年12月16日 1:39
>>To: Tian, Kevin; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>Cc: Xu, Anthony
>>Subject: RE: [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.
>>
>>> 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