Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Mar 2009 22:40:04 GMT
From:      Bruce Cran <bruce@cran.org.uk>
To:        freebsd-acpi@FreeBSD.org
Subject:   Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument
Message-ID:  <200903252240.n2PMe4eZ073657@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/108581; it has been noted by GNATS.

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com
Cc:  
Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid
 argument
Date: Wed, 25 Mar 2009 22:32:16 +0000

 In acpi_cpu_startup in /sys/dev/acpi_cpu.c cpu_cx_count is initialized
 to 0. If the generic Cx mode is being used (which it appears to be on
 older CPUs) then a loop is run over all the CPUs to find the highest Cx
 state common to all of them.  However that code assumes that
 cpu_cx_count has been initialized too *high*, since it only sets it if
 it finds a CPU with a maximum Cx state lower than the current value of
 cpu_cx_count. This means that while setting the per-CPU cx_lowest
 sysctl works because it correctly gets
 initialized to 1 in acpi_cpu_generic_cx_probe, the global systl
 hw.acpi.cpu.cx_lowest always fails because it thinks there are no Cx
 states.  Initializing cpu_cx_count to 3 instead of 0 should fix the
 problem.
 
 There appears to be a related bug in the _CST mode handling below; if
 there exists a CPU in the system which supports a higher Cx state than
 the others, the global cx_cpu_count will be set too high if the
 purpose of that sysctl is to reflect the maximum Cx state that all
 CPUs support. 
 
 -- 
 Bruce



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