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

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

>From: Magenheimer,
>Dan (HP Labs Fort Collins)
>
>False alarm on the relationship to console. But...
>
>(Kevin or Anthony, please see question below.)
>
>In case anyone else sees this problem, I worked around it by
>commenting out the code in xen/arch/ia64/xen/domain.c
>in arch_set_info_guest after the comment "Sync d/I cache
>conservatively".  Note that after it does a pal_cache_flush,
>it printk's "Sync i/d cache for dom0 image SUCC".  Note
>the reference to dom0 even though this is domU booting...
>
>It appears this code got added as part of a VTI bug
>fix update.  (Email attached below... the xen-ia64-devel
>archive seems to be broken right now.)
>
>Is this code fragment necessary for VTI to boot domU
>or is it OK to remove?

Hi, Dan,

        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. Though it's intermittent, please keep this code
there for correctness.

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

Thanks,
Kevin

>
>Thanks,
>Dan
>
>> -----Original Message-----
>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>> Sent: Thursday, October 13, 2005 3:28 AM
>> To: Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-ia64-devel] [PATCH] fixed some bugs to make
>> xen0 more stable
>>
>> Dan,
>>
>> When we debugged VTIdomainN, we found and fixed some bugs.
>> This patch is based on ver 7332
>>
>> - Consistence of region id mangling algrithm:
>>     - Metaphysical RID is not mangled, which may conflict
>> with other domain's virtual RID
>>     - Sometimes rr0 is mangled, but sometimes not
>>     - Sometimes only rid value is saved to
>> saved_rr0_metaphysical, but sometimes the whole value.
>>
>> - Nat bit consumption happens but handled as priv_emulate to
>> forward progress.But this is definitely wrong. We found
>> reason of nat consumption from fast_rfi,which doesn't save
>> unat again after spill guest states, and then use guest unat
>> to fill guest states when return.
>>
>> - In some corner case, timer interrupt handler won't update
>> itm and then return directly. When that happens, machine
>> timer interrupt disappears until guest timer interrupt sets
>> v_itm actively. But vti domain depends on ac_timer while the
>> latter will stop when above condition happens. Then if
>> current context is vti domain, context switch disappears and
>> machine halt.
>>
>> Also many compatibility issues to support non-vti and vti
>> domain are solved,eg:
>> - Changing lazy PAL mapping switch to eager switch per domain
>> switch, since vti domain always depends on pal call.
>> - evtchn_notify should also vcpu_wake target domain, since
>> vti domain may block for io emulation. Xenolinux is free of
>> this issue, since it's always runnable.
>>
>>
>> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
>> Signed-off-by Anthony Xu <anthony.xu@xxxxxxxxx>
>>
>>
>> Thanks
>> Anthony
>>
>>
>
>> -----Original Message-----
>> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Magenheimer, Dan (HP Labs Fort Collins)
>> Sent: Wednesday, December 14, 2005 5:44 PM
>> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-ia64-devel] Console problem on domU on tip?
>>
>> I have a system crash when I boot domU (built from tip)
>> on my rx2620, but not on my rx2600.  All bits were built
>> from scratch on both machines so no version mismatch
>> or anything like that.  I think everything is identical
>> except for the boxes are different.
>>
>> Just after launching domU, I get a General Exception trap.
>> I added some debug output and it appears that xen
>> is trying to do a printf and ifa=0xe8000000ff5e0005,
>> which I think is a memory-mapped serial port.
>>
>> The crash occurs right after xen prints:
>>
>>      (XEN) arch_set_info_guest
>>
>> and just before
>>
>>      (XEN) Sync i/d cache for dom0 image SUCC
>>
>> Anybody else see this on tip?
>>
>> Thanks,
>> Dan
>>
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel
>>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

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