Re: [Xen-devel] Guest start issue on ARM (maybe related to Credit2) [Was: Re: [xen-unstable test] 113807: regressions - FAIL]

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2017-09-25 at 17:23 +0100, Julien Grall wrote:
> On 09/25/2017 03:07 PM, Dario Faggioli wrote:
> > I don't see much in the logs, TBH, but both `xl vcpu-list' and the
> > 'r'
> > debug key seem to suggest that vCPU 0 is running, while the other
> > vCPUs
> > have never run... like it was an issue with secondary (v)CPU
> > bringup.
> > 
> > It indeed shows up with Credit2, as it were _specific_ to it, but
> > I'm
> > not 100% sure. In fact, it indeed seems to never show up here:
> > http://logs.test-lab.xenproject.org/osstest/results/history/test-ar
> > mhf-
> > armhf-xl/xen-unstable
> > 
> Most of the time guest-start/debian.repeat fails, vCPU 0 is in 
> data/prefetch abort state. My guess is a latent cache bug that
> credit2 
> appears to expose.
> 
So, forgive my ARM ignorance, but how do you tell that the vCPU(s)
is(are) in that particular state?

I'm asking because I now wonder whether this same issue could also be
the cause of these other failures, which we see from time to time:

  flight 113816 xen-unstable real [real]
  http://logs.test-lab.xenproject.org/osstest/logs/113816/

  [...]

  Tests which did not succeed, but are not blocking:
   test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 
113387

Here's the logs:
http://logs.test-lab.xenproject.org/osstest/logs/113816/test-armhf-armhf-xl-rtds/info.html

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel