Date: Thu, 26 Mar 2009 16:09:10 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Bruce Cran <bruce@cran.org.uk> Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <49CB8C86.4020800@icyb.net.ua> In-Reply-To: <20090325223914.4387eeae@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet>
next in thread | previous in thread | raw e-mail | index | archive | help
on 26/03/2009 00:39 Bruce Cran said the following: > On Fri, 20 Mar 2009 00:30:03 GMT > Daniel Dvořák <dandee@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@hellteam.net> >> To: <bug-followup@FreeBSD.org>, >> <lars.stokholm@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@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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CB8C86.4020800>