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:[EMAIL PROTECTED] > Sent: Monday, December 19, 2005 2:02 AM > To: Tian, Kevin; Magenheimer, Dan (HP Labs Fort Collins); > xen-ia64-devel@lists.xensource.com > 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@lists.xensource.com' > >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:[EMAIL PROTECTED] > >>>Sent: 2005年12月16日 1:39 > >>>To: Tian, Kevin; xen-ia64-devel@lists.xensource.com > >>>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@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
