kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid
argument
Bruce Cran
bruce at cran.org.uk
Thu Mar 26 07:28:55 PDT 2009
On Thu, 26 Mar 2009 16:09:10 +0200
Andriy Gapon <avg at icyb.net.ua> wrote:
> on 26/03/2009 00:39 Bruce Cran said the following:
> > On Fri, 20 Mar 2009 00:30:03 GMT
> > Daniel Dvořák <dandee at hellteam.net> wrote:
> >
> >> The following reply was made to PR kern/108581; it has been noted
> >> by GNATS.
> >>
> >> From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= <dandee at hellteam.net>
> >> To: <bug-followup at FreeBSD.org>,
> >> <lars.stokholm at gmail.com>
> >> Cc:
> >> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest:
> >> Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100
> >>
> >> This is a multi-part message in MIME format.
> >>
> >> ------=_NextPart_000_0007_01C9A8F7.746C4190
> >> Content-Type: text/plain;
> >> charset="UTF-8"
> >> Content-Transfer-Encoding: quoted-printable
> >>
> >> Hi acpi team,
> >> =20
> >> today I have installed fbsd 7.1R on one box with this relativly
> >> old = error and I was surprised about results .. it is the same:
> >> =20
> >> # uname -a
> >> FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1
> >> 14:37:25 = UTC 2009
> >> root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386
> >>
> >> # sysctl dev.cpu.0.cx_supported
> >> dev.cpu.0.cx_supported: C1/0
> >>
> >> # sysctl hw.acpi.cpu.cx_lowest=3DC1
> >> hw.acpi.cpu.cx_lowest: C1
> >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> >> =20
> >> # sysctl hw.acpi.cpu.cx_lowest=3DC0
> >> hw.acpi.cpu.cx_lowest: C1
> >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> >> =20
> >> # sysctl hw.acpi.cpu.cx_lowest=3DC1/0
> >> hw.acpi.cpu.cx_lowest: C1
> >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
> >>
> >> # 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
> >
> > I think I've found the problem and have updated the PR kern/108581
> > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/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.
>
> If you specifically mean the generic case (non-cst) as you mention in
> the PR, then I think that you didn't notice that cpu_cx_count (the
> global variable) gets updated in acpi_cpu_generic_cx_probe, So after
> looping over all CPUs it has the value of the maximum Cx level
> supported by at least one CPU. Only then we loop again and determine
> the smallest of the supported maximums.
Yes, I had missed that. I think the problem however is still that in
the generic cx case the global is re-initialized to 0 and never gets
updated.
--
Bruce Cran
More information about the freebsd-acpi
mailing list