linux-kernel - e_powersaver driver considered DANGEROUS (was Re: Linux 2.6.30-rc8 [also: VIA Support])

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090608075312.GK4106@prithivi.gnumonks.org>
Date:	Mon, 8 Jun 2009 15:53:12 +0800
From:	Harald Welte <HaraldWelte@...tech.com>
To:	"Michael S. Zick" <lkml@...ethan.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Duane Griffin <duaneg@...da.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: e_powersaver driver considered DANGEROUS (was Re: Linux 2.6.30-rc8
	[also: VIA Support])

Dear Michael and others,

On Sat, Jun 06, 2009 at 08:56:12AM -0500, Michael S. Zick wrote:

> > > > The mainstream kernel, e_powersaver, is *under-clocking* my machine -
> > > > 
> > > > The cpuid instruction provides the minimum and maximum GSF values 
> > > > (Guaranteed Stable Frequency) for that processor mask run -
> > > > Passing that on as the lower and upper limits to e_powersaver should
> > > > stop that problem.  Will be testing this RSN.
> > > 
> > > It's really surprising to me that none of this seems to be handled correct so
> > > far, I'll talk to Centaur and try to find out how we could have ended up in
> > > this situation.
> > >
> > 
> > Ah, but we are talking here of the *second* NetBook ever produced.
> > If one is to believe the dmidecode output - it is using the VIA demo board
> > BIOS. 
> > 
> > I bet the demo board BIOS is intended to demo the features of the product -
> > not the correctness or completeness of the ACPI support.  ;)

So I've just been told the VIA reference BIOS has full support for the
processor p-state support.  I'd therefore suppose every production BIOS
contains that code, too.  The kernel should never use a native driver such as
e_powersaver on any C7 or Nano system, but use the ACPI provided
tables/methods, which are intel compatible.  A native driver would only be
needed on really old C3 systems. 

The e_powersaver.c driver neither respects the maximum/minimum frequency
constraints specified in the MSR's, nor does it take care of the inflection
ratio, parallax and other advanced stuff that C7 and Nano are doing in this
area.

I would consider the e_powersaver driver DANGEROUS on any C7 or Nano system,
i.e. on every system it supports.  It is bound to cause system instability,
as it will most likely operate the CPU out of spec on virtually every system.

I'll do some actual testing on getting the intel-compatible ACPI method
for p-states working on my c7 and nano demo boards, and submit any patches
(if required).

I'll also meanwhile submit a patch to mark e_powersaver as DANGEROUS and
EXPERIMENTAL.

-- 
- Harald Welte <HaraldWelte@...tech.com>	    http://linux.via.com.tw/
============================================================================
VIA Free and Open Source Software Liaison
--
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/