kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument

[John Baldwin]

On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote:
> 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.
> 
> There's also a bug in the _CST section just below it; I think the line:
> 
> if (sc->cpu_cx_count > cpu_cx_count)
> 
> should be
> 
> if (sc->cpu_cx_count < cpu_cx_count)

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.

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 >= 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.

-- 
John Baldwin