Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 May 2009 15:28:26 +0400
From:      Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To:        Robert Noland <rnoland@FreeBSD.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Patch for "device_attach: estX attach returned 6" on half of the cores
Message-ID:  <pUAsgDrqwxYS/sC%2BkTmkqjTWM/8@psUvbB26hX94GoQd3C5ThNBxOp8>
In-Reply-To: <1241419338.78715.8.camel@balrog.2hip.net>
References:  <o4xm64iOwjCQABT%2BLyYf4J6bdds@psUvbB26hX94GoQd3C5ThNBxOp8> <1241418372.78715.1.camel@balrog.2hip.net> <z3eD9vm%2BPfdrvO13WMzgYPrBP6U@zJPT6v7ej2A2kHQ7pL5rJQfsxXs> <1241419338.78715.8.camel@balrog.2hip.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <rea-fbsd@codelabs.ru>
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 <rea-fbsd@codelabs.ru>
---
 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pUAsgDrqwxYS/sC%2BkTmkqjTWM/8>