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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Committed (but without removal of ifdefs until we
track down this problem). 

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Monday, December 19, 2005 7:15 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); Tian, Kevin; 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] Console problem on domU on tip?
> 
> I guest maybe the firmware on your machine doesn't implement 
> this pal call due to there is no split I/D cache at that 
> time, so when you call this pal call, it will return 
> PAL_STATUS_UNIMPLEMENTED, Could you please turn on 
> CONFIG_IA64_SPLIT_CACHE  and try this new patch to see 
> whether your machine can boot domain0?
> If this patch works, could you please remove all 
> CONFIG_IA64_SPLIT_CACHE macro?
> 
> Thanks
> -Anthony
> 
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins) 
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005å12æ19æ 23:48
> >To: Xu, Anthony; Tian, Kevin; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] Console problem on domU on tip?
> >
> >I have been distracted tracking another bug...
> >
> >Here's where I got:
> >
> >The machine is a new (April 2005) HP rx2620 so it is
> >not old firmware.   I can't reproduce it on a machine
> >with an ITP (which does have older firmware).
> >
> >This PAL call is never used in Linux, though there is a
> >routine coded for it.  It is the only
> >PAL call coded in Linux that occurs with psr.ic off.
> >
> >The crash I am seeing occurs either during the PAL call or
> >immediately upon return.
> >
> >Is it OK to
> >
> >
> >> -----Original Message-----
> >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >> Sent: Monday, December 19, 2005 2:02 AM
> >> To: Tian, Kevin; Magenheimer, Dan (HP Labs Fort Collins);
> >> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: RE: [Xen-ia64-devel] Console problem on domU on tip?
> >>
> >> Dan,
> >> Have you got time to verify below discussion?
> >>
> >> Thanks
> >> -Anthony
> >>
> >> >-----Original Message-----
> >> >From: Tian, Kevin
> >> >Sent: 2005å12æ16æ 10:16
> >> >To: Xu, Anthony; 'Magenheimer, Dan (HP Labs Fort Collins)';
> >> >'xen-ia64-devel@xxxxxxxxxxxxxxxxxxx'
> >> >Subject: RE: [Xen-ia64-devel] Console problem on domU on tip?
> >> >
> >> >>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