Date: Tue, 10 Jul 2012 02:06:07 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Nate Lawson <nate@root.org> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: disabled CST_CNT write Message-ID: <20120710014934.J42038@sola.nimnet.asn.au> In-Reply-To: <023CA42F-C5FD-4F67-AD70-84DE68B3FBA8@root.org> References: <4FF94EC4.1060109@FreeBSD.org> <023CA42F-C5FD-4F67-AD70-84DE68B3FBA8@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Jul 2012 09:49:57 -0700, Nate Lawson wrote: > On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote: > > > acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is > > under #ifdef notyet. It seems that the code was added that many years ago and > > never enabled. > > Now, judging from the reports I've seen on this mailing list, it appears that > > _CST changes do happen and the driver seem to handle them sufficiently well. > > I think that a lot of modern platforms do not even provide CST_CNT and assume > > that an OS is able to handle C-state change notifications. > > So, I guess that it should be safe to enable the code in question now. > > > > Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT > > please test this? This Thinkpad T23 with latest (Oct2006) BIOS & EC shows no FADT .. but FACP has CST_CNT=0xf4. Is that relevant at all? > It was only under an #ifdef because at the time our CST > implementation couldn't handle CST changes cleanly. I had added some > support for it, but since it couldn't be tested, I wasn't sure how > actual hardware would behave. > > I think it's fine to enable now. I think 2007-era Thinkpads were some > of the first to add this feature. T43? Maybe it's time I upgraded :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120710014934.J42038>