From owner-freebsd-current@FreeBSD.ORG Mon May 4 11:28:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0EE106564A; Mon, 4 May 2009 11:28:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 416D18FC20; Mon, 4 May 2009 11:28:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=quhd1/QuAZZEWbFBJjx5IHZBlNB03/NoiGdxwmcxsRfVGFQ7+0NZgD9iPc+0c1nh/+ddS7HfW6agvFSwflsUJde8KPco+eSS7wuFIFLCBsG9mG9SVuQ9tavFV4RkTKjseQDr663EEjt6imgmDrmbD/GFSfk48YAANluDqHo/Or0=; Received: from amnesiac.at.no.dns (ppp85-141-64-167.pppoe.mtu-net.ru [85.141.64.167]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1M0wLU-000PGL-SV; Mon, 04 May 2009 15:28:29 +0400 Date: Mon, 4 May 2009 15:28:26 +0400 From: Eygene Ryabinkin To: Robert Noland Message-ID: References: <1241418372.78715.1.camel@balrog.2hip.net> <1241419338.78715.8.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <1241419338.78715.8.camel@balrog.2hip.net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 11:28:31 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Robert, Mon, May 04, 2009 at 01:42:18AM -0500, Robert Noland wrote: > Without this patch, cpu0 does attach correctly. On the Intel MB? If yes and you'll be able to to some debugging, please, try the attached patch and send the output of 'dmesg', 'sysctl dev.cpu', 'sysctl dev.cpufreq' and 'sysctl dev.est'. > > One could check if the patch will help by examining the output of > > 'apicdump -d' and looking for the Alias () directives for the Processor > > objects. Here's what I have for my laptop: > > ----- > > Scope (_PR) > > { > > Processor (P001, 0x01, 0x00000810, 0x06) {} > > Alias (P001, CPU1) > > } > > > > Scope (_PR) > > { > > Processor (P002, 0x02, 0x00000810, 0x06) {} > > Alias (P002, CPU2) > > } > > ----- > > So in this case we essentially have 4 Processor objects under _PR, > > but only two objects are real ones and only they should be attached. > > > > For the completeness, could you, please, show the output of 'acpidump > > -dt 2>&1' for both of your machines? > > Attached. The Asus does appear to use aliases as you described. Then you should have est attached to cpu0/cpu2 and rejected on cpu1/cpu3, aren't you? The output of 'sysctl dev.cpu', 'sysctl dev.est' and 'sysctl dev.cpufreq' will be also helpful. Will you be able to try my original patch on the Asus system? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="acpi_perf-provide-debugging-statements.diff" Content-Transfer-Encoding: quoted-printable =46rom 11e32a567a0e92a26d2226c8ca28478ca8f1135b Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Mon, 4 May 2009 15:10:03 +0400 Subject: [PATCH] ACPI perf: provide debugging statements to diagnose attach= ment problems Signed-off-by: Eygene Ryabinkin --- sys/dev/acpica/acpi.c | 1 + sys/dev/acpica/acpi_cpu.c | 2 ++ sys/dev/acpica/acpi_perf.c | 28 ++++++++++++++++++++++++---- 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index d79b413..669de02 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -1742,6 +1742,7 @@ acpi_probe_child(ACPI_HANDLE handle, UINT32 level, vo= id *context, void **status) * At least \_SB and \_TZ are detected as devices (ACPI-CA bug?) */ handle_str =3D acpi_name(handle); + device_printf(bus, "Working with child '%s'\n", handle_str); for (search =3D scopes; *search !=3D NULL; search++) { if (strcmp(handle_str, *search) =3D=3D 0) break; diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c index a65faee..283a8bb 100644 --- a/sys/dev/acpica/acpi_cpu.c +++ b/sys/dev/acpica/acpi_cpu.c @@ -214,6 +214,7 @@ acpi_cpu_probe(device_t dev) return (ENXIO); =20 handle =3D acpi_get_handle(dev); + device_printf(dev, "Going to probe CPU %s\n", acpi_name(handle)); if (cpu_softc =3D=3D NULL) cpu_softc =3D malloc(sizeof(struct acpi_cpu_softc *) * (mp_maxid + 1), M_TEMP /* XXX */, M_WAITOK | M_ZERO); @@ -240,6 +241,7 @@ acpi_cpu_probe(device_t dev) * in their Processor object as the ProcId values in the MADT. */ acpi_id =3D obj->Processor.ProcId; + device_printf(dev, "ACPI ProcId =3D %d\n", acpi_id); AcpiOsFree(obj); if (acpi_pcpu_get_id(device_get_unit(dev), &acpi_id, &cpu_id) !=3D 0) return (ENXIO); diff --git a/sys/dev/acpica/acpi_perf.c b/sys/dev/acpica/acpi_perf.c index e517ad3..87860a8 100644 --- a/sys/dev/acpica/acpi_perf.c +++ b/sys/dev/acpica/acpi_perf.c @@ -139,6 +139,7 @@ MALLOC_DEFINE(M_ACPIPERF, "acpi_perf", "ACPI Performanc= e states"); static void acpi_perf_identify(driver_t *driver, device_t parent) { + ACPI_STATUS status; ACPI_HANDLE handle; device_t dev; =20 @@ -150,8 +151,14 @@ acpi_perf_identify(driver_t *driver, device_t parent) handle =3D acpi_get_handle(parent); if (handle =3D=3D NULL) return; - if (ACPI_FAILURE(AcpiEvaluateObject(handle, "_PSS", NULL, NULL))) + if (ACPI_FAILURE(status =3D + AcpiEvaluateObject(handle, "_PSS", NULL, NULL))) { + device_printf(parent, + "%s: ACPI_FAILURE(evaluate _PSS for %s): %s\n", + __func__, acpi_name(handle), AcpiFormatException(status)); + return; + } =20 /* * Add a child to every CPU that has the right methods. In future @@ -168,6 +175,7 @@ acpi_perf_identify(driver_t *driver, device_t parent) static int acpi_perf_probe(device_t dev) { + ACPI_STATUS status; ACPI_HANDLE handle; ACPI_OBJECT *pkg; struct resource *res; @@ -186,8 +194,12 @@ acpi_perf_probe(device_t dev) handle =3D acpi_get_handle(dev); buf.Pointer =3D NULL; buf.Length =3D ACPI_ALLOCATE_BUFFER; - if (ACPI_FAILURE(AcpiEvaluateObject(handle, "_PCT", NULL, &buf))) + if (ACPI_FAILURE(status =3D + AcpiEvaluateObject(handle, "_PCT", NULL, &buf))) { + device_printf(dev, "%s: failed to evaluate _PCT: %s\n", + __func__, AcpiFormatException(status)); return (error); + } pkg =3D (ACPI_OBJECT *)buf.Pointer; if (ACPI_PKG_VALID(pkg, 2)) { rid =3D 0; @@ -253,8 +265,11 @@ acpi_perf_evaluate(device_t dev) buf.Pointer =3D NULL; buf.Length =3D ACPI_ALLOCATE_BUFFER; status =3D AcpiEvaluateObject(sc->handle, "_PSS", NULL, &buf); - if (ACPI_FAILURE(status)) + if (ACPI_FAILURE(status)) { + device_printf(dev, "%s: failed to evaluate _PSS: %s\n", + __func__, AcpiFormatException(status)); return (ENXIO); + } =20 pkg =3D (ACPI_OBJECT *)buf.Pointer; if (!ACPI_PKG_VALID(pkg, 1)) { @@ -429,14 +444,19 @@ acpi_px_available(struct acpi_perf_softc *sc) =20 /* If the old state is too high, set current state to the new max. */ if (ACPI_SUCCESS(status)) { + device_printf(sc->dev, "Max P-state is %d\n", + sc->px_max_avail); if (sc->px_curr_state !=3D CPUFREQ_VAL_UNKNOWN && sc->px_curr_state > sc->px_max_avail) { acpi_px_to_set(sc->dev, &sc->px_states[sc->px_max_avail], &set); acpi_px_set(sc->dev, &set); } - } else + } else { + device_printf(sc->dev, "Failed to get max P-state (_PPC): %s\n", + AcpiFormatException(status)); sc->px_max_avail =3D 0; + } } =20 static int --=20 1.6.2.4 --X1bOJ3K7DJ5YkBrT--