From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [xen-unstable test] 59040: regressions - FAIL Date: Mon, 6 Jul 2015 16:05:38 +0200 Message-ID: <1436191538.14347.110.camel@citrix.com> References: <1436186029.25646.65.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2234735541558732459==" Return-path: In-Reply-To: <1436186029.25646.65.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org --===============2234735541558732459== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DjaCijUXkt766Z+79fVD" --=-DjaCijUXkt766Z+79fVD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-07-06 at 13:33 +0100, Ian Campbell wrote: > On Fri, 2015-07-03 at 21:59 +0000, osstest service owner wrote: > > test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. v= s. 58965 >=20 > From > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-ar= mhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreli= able on cubietruck, but works just fine on arndale. >=20 > Comparing to > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-ar= mhf-xl/xen-unstable.html=20 > it looks to be credit2 specific. >=20 Yes, noted... I shall have a look. =46rom what I recall, failures varies a bit, in terms of what the state of the system (vcpus active/idle, etc.) when the fail itself happens. If I'm not confusing this with something else, I've seen instances where everything was completely idle and instances, like this one, where there is something going on... As I said, I'll have a look. > d8v0 has a PC at 0xffff000c, which will be the entry point for the > prefetch abort handler. ABT_LR shows it came from 0xffff0010 which is > the data abt handler, which uses the same banked LR as prefetch abt so > we don't know where it came from. >=20 > SVR_LR shows that the last function call done in kernel mode was a call > to fdt_check_header from early_init_dt_verify, but that might have been > ages ago. >=20 Thanks for this. My nonexistent knowledge of ARM internals limits by quite a bit the amount of information that I can extract from this trace... but this is already something. I'll ask if there is anything that is ARM specific that I need but can't figure out. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-DjaCijUXkt766Z+79fVD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWai0AACgkQk4XaBE3IOsTtGgCeLjMGr/f4812jVo5YGqImGBKt xvAAn3r+aiLVJZz05wGy07ijLPGPU+Q6 =dJjo -----END PGP SIGNATURE----- --=-DjaCijUXkt766Z+79fVD-- --===============2234735541558732459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2234735541558732459==--