Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Mar 2009 10:49:02 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Bruce Cran <bruce@cran.org.uk>
Cc:        Daniel =?utf-8?q?Dvo=C5=99=C3=A1k?= <dandee@hellteam.net>, freebsd-acpi@freebsd.org
Subject:   Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
Message-ID:  <200903261049.02977.jhb@freebsd.org>
In-Reply-To: <20090326142456.042ea2f0@gluon.draftnet>
References:  <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326142456.042ea2f0@gluon.draftnet>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 26 March 2009 10:24:56 am Bruce Cran wrote:
> On Thu, 26 Mar 2009 09:37:50 -0400
> John Baldwin <jhb@freebsd.org> wrote:
>=20
> > On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote:
> > > On Fri, 20 Mar 2009 00:30:03 GMT
> > > Daniel Dvo=C5=99=C3=A1k <dandee@hellteam.net> wrote:
> > >=20
> > > > The following reply was made to PR kern/108581; it has been noted
> > > > by GNATS.
> > > >=20
> > > > From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D <dandee@hellt=
eam.net>
> > > > To: <bug-followup@FreeBSD.org>,
> > > > 	<lars.stokholm@gmail.com>
> > > > Cc: =20
> > > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest:
> > > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100
> > > >=20
> > > >  This is a multi-part message in MIME format.
> > > > =20
> > > >  ------=3D_NextPart_000_0007_01C9A8F7.746C4190
> > > >  Content-Type: text/plain;
> > > >  	charset=3D"UTF-8"
> > > >  Content-Transfer-Encoding: quoted-printable
> > > > =20
> > > >  Hi acpi team,
> > > >  =3D20
> > > >  today I have installed fbsd 7.1R on one box with this relativly
> > > > old =3D error and I was surprised about results .. it is the same:
> > > >  =3D20
> > > >  # uname -a
> > > >  FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1
> > > > 14:37:25 =3D UTC 2009
> > > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  =3D i386
> > > > =20
> > > >  # sysctl dev.cpu.0.cx_supported
> > > >  dev.cpu.0.cx_supported: C1/0
> > > > =20
> > > >  # sysctl hw.acpi.cpu.cx_lowest=3D3DC1
> > > >  hw.acpi.cpu.cx_lowest: C1
> > > >  sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> > > >  =3D20
> > > >  # sysctl hw.acpi.cpu.cx_lowest=3D3DC0
> > > >  hw.acpi.cpu.cx_lowest: C1
> > > >  sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> > > >  =3D20
> > > >  # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0
> > > >  hw.acpi.cpu.cx_lowest: C1
> > > >  sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> > > > =20
> > > >  # dmesg -a | grep "acpi"
> > > >  acpi0: <ASUS P4S8X-X> on motherboard
> > > >  acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20
> > > >  acpi0: [ITHREAD]
> > > >  acpi0: Power Button (fixed)
> > > >  acpi0: reservation of 0, a0000 (3) failed
> > > >  acpi0: reservation of 100000, ff00000 (3) failed
> > > >  acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on
> > > > acpi0 acpi_button0: <Power Button> on acpi0
> > > >  pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > > >  atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on
> > > > acpi0 cpu0: <ACPI CPU> on acpi0
> > > >  hw.acpi.cpu.cx_lowest:
> > > >  hw.acpi.cpu.cx_lowest
> > >=20
> > > I think I've found the problem and have updated the PR kern/108581
> > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global
> > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup
> > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume
> > > that it's been intialized to 3 because it only sets it if it's
> > > higher than the current CPU supports - that is, cpu_cx_count should
> > > reflect the highest Cx state that all CPUs support.
> > >=20
> > > There's also a bug in the _CST section just below it; I think the
> > > line:
> > >=20
> > > if (sc->cpu_cx_count > cpu_cx_count)
> > >=20
> > > should be
> > >=20
> > > if (sc->cpu_cx_count < cpu_cx_count)
> >=20
> > No, the code is doing things differently on purpose (though I'm not
> > completely sure why).  For _CST it sets cpu_cx_count to the maximum
> > Cx level supported by any CPU in the system.  For non-_CST it sets it
> > to the maximum Cx level supported by all CPUs in the system.  I think
> > it is correct for cpu_cx_count to always start at 0 and only be
> > bumped up to a higher setting.  Setting it to 3 would be very wrong
> > for the _CST case as I've seen CPUs that support C4.
> >=20
> > Note that C1 _always_ exists as it is simply the "hlt" instruction
> > that has existed since the 8086.  Only C2+ require power-saving
> > extension support in the CPU, so cpu_cx_count should always end up >=3D
> > 1.  It would be interesting if you could add some debug printfs to
> > print out the values that acpi_cpu_generic_cx_probe() computes for
> > 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well
> > as all changes to the 'cpu_cx_count' global variable.
> >=20
>=20
> For my Athlon XP CPU, acpi_cpu_generic_cx_probe sets sc->cpu_cx_count
> to 1, and subsequently dev.cpu.0.cx_lowest has always worked.  After
> adding printfs I found that the problem is that the cpu_cx_generic
> block in acpi_cpu_startup is being run and because cpu_cx_count is set
> to 0 it never gets updated; the statement "if (sc->cpu_cx_count <
> cpu_cx_count)" is never true.

Err, you missed the end of acpi_cpu_generic_cx_probe() where it does this:

    /* Update the largest cx_count seen so far */
    if (sc->cpu_cx_count > cpu_cx_count)
	cpu_cx_count =3D sc->cpu_cx_count;

That is effectively the same as the for loop in the _CST case that finds th=
e=20
maximum supported state of all CPUs.  It would probably be clearer to move=
=20
that into acpi_cpu_startup() instead.

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903261049.02977.jhb>