From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] x86: correct socket_cpumask allocation for AP Date: Wed, 8 Jul 2015 18:17:36 +0200 Message-ID: <1436372256.22672.246.camel@citrix.com> References: <1436348218-29172-1-git-send-email-chao.p.peng@linux.intel.com> <559D35FD020000780008E354@mail.emea.novell.com> <1436368264.22672.219.camel@citrix.com> <559D602C020000780008E585@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1613545561473646675==" Return-path: In-Reply-To: <559D602C020000780008E585@mail.emea.novell.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: Jan Beulich Cc: Chao Peng , Boris Ostrovsky , xen-devel@lists.xen.org, keir@xen.org, andrew.cooper3@citrix.com List-Id: xen-devel@lists.xenproject.org --===============1613545561473646675== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-I9mkXV7aiHuYYLswTtHY" --=-I9mkXV7aiHuYYLswTtHY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-07-08 at 16:38 +0100, Jan Beulich wrote: > >>> On 08.07.15 at 17:11, wrote: > > On Wed, 2015-07-08 at 13:38 +0100, Jan Beulich wrote: > >> >>> On 08.07.15 at 11:36, wrote: > >> > @@ -84,11 +85,21 @@ void *stack_base[NR_CPUS]; > >> > static void smp_store_cpu_info(int id) > >> > { > >> > struct cpuinfo_x86 *c =3D cpu_data + id; > >> > + unsigned int socket; > >> > =20 > >> > *c =3D boot_cpu_data; > >> > if ( id !=3D 0 ) > >> > + { > >> > identify_cpu(c); > >> > =20 > >> > + socket =3D cpu_to_socket(id); > >> > + if ( !socket_cpumask[socket] ) > >> > + { > >> > + socket_cpumask[socket] =3D secondary_socket_cpumask; > >> > + secondary_socket_cpumask =3D NULL; > >>=20 > >> I don't think this will build with small enough NR_CPUS. > >> > > And it *does* *not* fix the issue on my box. >=20 > I.e. bad analysis (albeit it seemed correct to me) > Same here, and in fact I triple checked that I had the patch really applied... and, yes, it is, and it's still crashing, with the same (reported) dump as the one we find in Osstest's failure, as reported by Ian. > _and_ new code not tested.=20 > Looking another time, both me and Osstest are probably seeing a different issue, than the one Boris is facing. I don't see Boris' Oops, so I can't be sure, but in my case, this is happening in set_cpu_sibling_map(), called from smp_prepare_cpus() on the boot CPU, not during secondary CPUs bringup. I think it has to do with the fact that I've got CPU #0 on socket #1, while Boris' (and perhaps Chao's too) test box have it on socket #0. I'd be happy to test patches on my box, if that helps (although, I'm about to leave right now, so that will be tomorrow). Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-I9mkXV7aiHuYYLswTtHY 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 iEYEABECAAYFAlWdTScACgkQk4XaBE3IOsRq2QCeKphd2WtLWfhqXEnqWNoxNHjI NVAAnAy/7IVH/McEz9GE8nLf/UJ/hc2L =sJMe -----END PGP SIGNATURE----- --=-I9mkXV7aiHuYYLswTtHY-- --===============1613545561473646675== 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 --===============1613545561473646675==--