linux-kernel - polling (Re: [PATCH] ACPI: add "auto" to acpi_enforce

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.0904021828110.9182@localhost.localdomain>
Date:	Thu, 02 Apr 2009 18:45:59 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Luca Tettamanti <kronos.it@...il.com>,
	Thomas Renninger <trenn@...e.de>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>,
	khali@...ux-fr.org
Subject: polling (Re: [PATCH] ACPI: add "auto" to acpi_enforce_resources)

On Wed, 4 Feb 2009, Matthew Garrett wrote:

> On Wed, Feb 04, 2009 at 12:52:06AM -0500, Len Brown wrote:
> 
> > While it is slightly off-topic of the (I agree, real)
> > technical issue here, note that polling is not "normal" on ACPI systems.
> > [1] was on  SuSE Linux 10.0, which on their own decided to
> > over-ride the kernel and enable thermal zone polling by default.
> 
> Checking the DSDTs I have to hand, it seems that polling is expected on 
> about 5% of systems via an explicit _TZP and on almost all machines via 
> _TSP. Even on systems where thermal notifications are provided, it's 
> still up to the OS to poll the zone to find the current temperature and 
> take appropriate action. There's still a window for native smbus drivers 
> to screw everything up.

FWIW

In the last 6 years, I've seen exactly 3 systems with a non-zero _TZP.
An old Averatec laptop asked for 1 second, and two recent EEE-PC's ask for 
30 seconds.  Dunno why Asus has made this leap backwards.

_TSP is a different beast.  It only exists in the context of _PSV and 
_PSL.

-Len

ps. I just noticed something in the spec under _PSL...
"If a linear performance control register is not defined(..) for a 
processor defined in _PSL or for a processor device in the zone as 
indicated
by _TZM, then the processor must support processor performance states
(in other words, the processor's processor object must include _PCT, _PSS, 
and _PPC).

Interesting, here is an official tie in of P-states and passive trip 
points that I'd not noticed before....

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/