From mboxrd@z Thu Jan 1 00:00:00 1970 From: "AP Xen" Subject: Ubuntu 10.04 stuck in detect_extended_topology() Date: Wed, 9 Jun 2010 14:55:17 -0700 Message-ID: <006c01cb081e$74908320$5db18960$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1714485406==" Return-path: Content-Language: en-us List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============1714485406== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CB07E3.C831AB20" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_006D_01CB07E3.C831AB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am running Xen packaged with CentOS 5.4 and trying to install Ubuntu 10.04 as an HVM guest. xen_major : 3 xen_minor : 1 xen_extra : .2-164.11.1.el5 After sprinkling the kernel with printks, I am seeing that it is stuck in the function detect_extended_topology() in the following loop: sub_index = 1; do { cpuid_count(0xb, sub_index, &eax, &ebx, &ecx, &edx); printk("%s: after cpuid_count %d\n", __FUNCTION__, sub_index); /* * Check for the Core type in the implemented sub leaves. */ if (LEAFB_SUBTYPE(ecx) == CORE_TYPE) { core_level_siblings = LEVEL_MAX_SIBLINGS(ebx); core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); break; } sub_index++; } while (LEAFB_SUBTYPE(ecx) != INVALID_TYPE); The ECX leaf subtype never returns CORE_TYPE or INVALID_TYPE. So think I might be running in to a bug / quirk in the CPUID handling code in Xen packaged with CentOS 5.4. Is there a work around for it? Maybe specifying something in the cpuid option in the config file. Thanks! ------=_NextPart_000_006D_01CB07E3.C831AB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am running Xen packaged with CentOS 5.4 and = trying to install Ubuntu 10.04 as an HVM guest.

xen_major &nbs= p; : 3

xen_minor &nbs= p; : 1

xen_extra &nbs= p; : .2-164.11.1.el5

After sprinkling the kernel with printks, I am = seeing that it is stuck in the function detect_extended_topology() in the following = loop:

<snip>

sub_index =3D 1;

do {

&= nbsp; cpuid_count(0xb, sub_index, &eax, &ebx, &ecx, = &edx);

&= nbsp; printk("%s: after cpuid_count %d\n", __FUNCTION__, = sub_index);

&= nbsp; /*

&= nbsp; * Check for the Core type in the implemented sub = leaves.

&= nbsp; */

&= nbsp; if (LEAFB_SUBTYPE(ecx) =3D=3D CORE_TYPE) {

&= nbsp; core_level_siblings =3D LEVEL_MAX_SIBLINGS(ebx);

&= nbsp; core_plus_mask_width =3D = BITS_SHIFT_NEXT_LEVEL(eax);

&= nbsp; break;

&= nbsp; }

&= nbsp; sub_index++;

} while (LEAFB_SUBTYPE(ecx) !=3D INVALID_TYPE);

<snip>

The ECX leaf subtype never returns CORE_TYPE or INVALID_TYPE. So think I might be running in to a bug / quirk in the = CPUID handling code in Xen packaged with CentOS 5.4. Is there a work around = for it? Maybe specifying something in the cpuid option in the config = file.

Thanks!

------=_NextPart_000_006D_01CB07E3.C831AB20-- --===============1714485406== 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.xensource.com http://lists.xensource.com/xen-devel --===============1714485406==--