linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: VCool - cool your Athlon/Duron during idle
@ 2001-08-27 20:57 Grover, Andrew
  0 siblings, 0 replies; 20+ messages in thread
From: Grover, Andrew @ 2001-08-27 20:57 UTC (permalink / raw)
  To: 'Alan Cox'; +Cc: jan, Dieter.Nuetzel, linux-kernel, mpet

> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> > handle a too-hot cpu, but all C2/C3 gets you is reduced power when =
> > idle.
> > This results in better battery life on a laptop but that is 
> irrelevant =
> > on a
> > desktop system.
> 
> Thus speaks the country with chronic californian power 
> shortages, and that
> wouldn't sign up to a global accord on global warming 8)

Hehe. Not my fault, I'm an Oregonian! :)

> C2 and C3 are useful IMHO even on a desktop PC. The slight hit on the
> transition is not noticable, the change on the power bill is.

Of course, I agree. However, my point was that it is not safe to use them
until the platform explicitly supports them. Validating this on desktop
motherboards has traditionally not been deemed worthwhile, though I share
your hope that that changes.

Regards -- Andy

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27  9:26 Grover, Andrew
  2001-08-27  9:53 ` Jan Niehusmann
  2001-08-27 10:42 ` Alan Cox
@ 2001-09-02 22:28 ` Jan Niehusmann
  2 siblings, 0 replies; 20+ messages in thread
From: Jan Niehusmann @ 2001-09-02 22:28 UTC (permalink / raw)
  To: Grover, Andrew; +Cc: Linux Kernel List

On Mon, Aug 27, 2001 at 02:26:09AM -0700, Grover, Andrew wrote:
> Well I don't want to inhibit your hackerly fervor, but C2 and C3 handling
> are already supported by the ACPI driver, in a vendor-neutral manner.

I did look into this, and indeed the ACPI code is doing this much better
than my patch did. 

The only thing it is missing is enabling disconnect in C2 mode. Of course,
enabling a feature that may have been disabled by the BIOS with a good reason
may be dangerous. Still, it seems to work for me ;-) and saves a lot of power.

With the ACPI code and a simple patch that enables bus disconnection, I get
the same power saving as with the lvcool userspace program, but a much better
performance for things like NFS access. (in fact, NFS access is the only
thing where I notice a significant slowdown when running lvcool)

Additionaly, this patch is much smaller than the last one. But of course,
it's only usefull if ACPI is working (which it is for me).
I added the code to quirks.c because it allowed some quick cut&paste ;-)
The code is enabled if the kernel is booted with via_disconnect=yes

To give some numbers (measured with a simple, probably not very accurate
'power monitor'):
Idle without disconnect: ~80W
Idle with disconnect: ~60W
Compiling a kernel: ~90W
(all numbers for a Duron 800, Asus A7V133, Voodoo 3, Maxtor 80GB hard disk,
256MB RAM and some PCI cards)

By the way, does anybody know why modprobe ospm_busmgr doesn't return, but
the module works if I interrupt the modprobe with CTRL-C?

Jan


diff -ur linux-2.4.9-ac5/drivers/pci/quirks.c linux-2.4.9-ac5-vcool/drivers/pci/quirks.c
--- linux-2.4.9-ac5/drivers/pci/quirks.c	Sun Sep  2 15:37:56 2001
+++ linux-2.4.9-ac5-vcool/drivers/pci/quirks.c	Sun Sep  2 23:58:12 2001
@@ -21,6 +21,8 @@
 
 #undef DEBUG
 
+int enable_via_disconnect;
+
 /* Deal with broken BIOS'es that neglect to enable passive release,
    which can cause problems in combination with the 82441FX/PPro MTRRs */
 static void __init quirk_passive_release(struct pci_dev *dev)
@@ -146,6 +148,21 @@
 	printk(KERN_INFO "Applying VIA southbridge workaround.\n");
 }
 
+static void __init quirk_viadisconnect(struct pci_dev *dev)
+{
+	u32 res32;
+
+	if(!enable_via_disconnect) return;
+
+	pci_read_config_dword(dev,0x52&0xfc,&res32);
+	if ((res32&0x00800000)==0) {
+		printk(KERN_INFO "Enabling disconnect in VIA northbridge.\n");
+		res32|=0x00800000;
+		pci_write_config_dword(dev,0x52&0xfc,res32);
+	} else
+		printk(KERN_INFO "Disconnect already anabled in VIA northbridge.\n");
+}
+
 /*
  *	VIA Apollo VP3 needs ETBF on BT848/878
  */
@@ -453,6 +470,8 @@
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_5597,		quirk_nopcipci },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_496,		quirk_nopcipci },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	quirk_vialatency },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	quirk_viadisconnect },
+	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8371_0,	quirk_viadisconnect },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8371_1,	quirk_vialatency },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	0x3112	/* Not out yet ? */,	quirk_vialatency },
 	{ PCI_FIXUP_FINAL,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C597_0,	quirk_viaetbf },
@@ -500,3 +519,12 @@
 	pci_do_fixups(dev, pass, pcibios_fixups);
 	pci_do_fixups(dev, pass, pci_fixups);
 }
+
+static int __init via_disconnect_setup (char *str) {
+	if(!strncmp(str,"yes",3)) {
+		enable_via_disconnect=1;
+	}
+	return 1;
+}
+
+__setup("via_disconnect=", via_disconnect_setup);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 23:00 ` Jan Niehusmann
@ 2001-08-27 22:46   ` Pavel Machek
  0 siblings, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2001-08-27 22:46 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: kernel list

Hi!

> +static void stpclk_idle(void)
> +{
> +	if (current_cpu_data.hlt_works_ok && !hlt_counter) {
> +		__cli();
> +		if (!current->need_resched) 
> +			inb(Reg_PL2);
> +		else
> +			__sti();
> +	}
> +}

You are not using hlt instruction -> you don't need to care about
hlt_works_ok.
							Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27 18:23       ` Liakakis Kostas
@ 2001-08-27 20:56         ` Paul G. Allen
  0 siblings, 0 replies; 20+ messages in thread
From: Paul G. Allen @ 2001-08-27 20:56 UTC (permalink / raw)
  Cc: Linux Kernel List, kplug-list

Liakakis Kostas wrote:
> 
> On Mon, 27 Aug 2001, Kurt Roeckx wrote:
> 
> > On Mon, Aug 27, 2001 at 02:48:24PM +0300, Liakakis Kostas wrote:
> > > On Mon, 27 Aug 2001, Jan Niehusmann wrote:
> > >
> > > > (asus writes that one of the problems that can happen with this power
> > > > saving mode are the huge changes in power dissipation, from 60W to 5W
> > > > and back - therefore I assume the power saving mode can save up to 55W)
> > >
> > > The problem they are describing is not the change in power dissipation,
> > > but the change in current draw from the regulated 1.75V (difference of
> > > about 30A or more).
> >
> > And what do you think power is?
> > Maybe it's the voltage times the current?
> 
> Your point being? This is power yeah. However I can get 50W with 1V@50A
> and with 50V@1A ... tell me which will be easier for a regulator when
> going from 10 to 50W while trying to keep the voltage steady.

First of all, let me say that I used to run the lab at NCR Corporation testing and qualifying power supplies, and making design recommendations/changes when
they failed, for main frame computers. 

That would depend upon the power supply, and specifically, the regulator design. Consider that the average PC user buys a cheap $30 - $50 (US Dollars) case and
P/S package. That P/S will never be able to handle this kind of transition and stay within its specified regulation. In the electronics industry, you get what
you pay for (with the exception of a couple of big names that simply sell junk 'cause they can), and there's no exception to this rule when it comes to power
supplies. I have tested PC power supplies by various mfgs. and have found that most do not hold up to the specifications printed on them, let alone to anything
a CPU/MB mfg. may require. Many operate on the fringe of their specified voltage range even under low load, send them up to maximum load and they quickly fly
south (and many never return!). In simple terms, you won't find a P/S under $100 (US) that will be worth the CPUs weight in regulation, let alone will be able
to handle such a large power transition.

> 
> So to rephrase myself the condition of less power dissipation (and that is
> thermal output, not power consumption which isvoltage times current... )
> is the result of less current draw of ~30A. This is a huge difference. And
> this is the problem. There are regulators on certain motherboards which
> can't cope with this. And they increase (not that bad unless you fry a
> chip) when current drops, or decrease voltage when there is current need
> (crash) of the tolerance limmits.

MoBo regulators aside, as stated above, most power supplies can't handle it, so there's nothing the regulator could do no matter how well designed it is. What I
said above does stand for on-board regulators as well. 

BTW, there are two basic power ratings for an electronic component - Power Dissipation (Pd) and Power Consumption (Pc). Pd is the amount of power (V*I or
Voltage times Current) that the component wastes in heat (which is generated by the friction of electrons moving through the component). Pc is the total power
required by the component for operation, and is a function of Pd plus the power actually used by the component and not wasted in heat. Pc is also V*I. Pc is
measured by connecting meters (voltage and current) to the power connections on the component while in operation. Pd can be measured by the amount of heat
coming off of it, or by various other methods. Both Pd and Pc can be decreased by turning off portions of the component, decreasing clock speed (thereby
decreasing friction), and by decreasing voltage and/or current to minimum operational levels. It can be increased by turning off the wrong portions of the
component causing others to exceed their specifications, by increasing clock speed, by increasing voltage and/or current to maximum operational levels (or
beyond - a Bad Thing :), and by decreasing voltage and/or current below operational levels. The last scenario causes the component to do all kinds of things it
wasn't meant to do, which usually causes Pd to rise dramatically and therefore Pc follows.

So, in summary, I wouldn't use power saving modes (and I don't) unless:

1. I had 100% conviction that my P/S would meet or exceed the required specifications.
2. I had 100% conviction that the MoBo would meet or exceed the required specifications.
3. I had 100% conviction that all components in the system would meet or exceed the required specifications.

More often that not, they don't, and most consumers are none the wiser. I have never used any power saving mode because in any given case the system in question
could not meet 1 - 3.

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27 10:42 ` Alan Cox
  2001-08-27 12:16   ` Dieter Nützel
@ 2001-08-27 20:17   ` Paul G. Allen
  1 sibling, 0 replies; 20+ messages in thread
From: Paul G. Allen @ 2001-08-27 20:17 UTC (permalink / raw)
  To: linux-kernel

Alan Cox wrote:
> 
> > handle a too-hot cpu, but all C2/C3 gets you is reduced power when =
> > idle.
> > This results in better battery life on a laptop but that is irrelevant =
> > on a
> > desktop system.
> 
> Thus speaks the country with chronic californian power shortages, and that
> wouldn't sign up to a global accord on global warming 8)
> 

In reality, California has no power shortage. The problem is deregulation and greed together causing an artificial power shortage. Tell those of us in San Diego
that we're using too much power and there's a shortage. We started conserving a year before the "shortage" - an average of 20% in fact - and we still had
blackouts and higher rates and were told to cut back even more or pay even more. But, this thread digresses.

> C2 and C3 are useful IMHO even on a desktop PC. The slight hit on the
> transition is not noticable, the change on the power bill is.

At our rates, you're darn right it is. An average PC costs ~$.05 per hour to run in California.

PGA

-- 
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27 15:03     ` Kurt Roeckx
@ 2001-08-27 18:23       ` Liakakis Kostas
  2001-08-27 20:56         ` Paul G. Allen
  0 siblings, 1 reply; 20+ messages in thread
From: Liakakis Kostas @ 2001-08-27 18:23 UTC (permalink / raw)
  To: Kurt Roeckx; +Cc: Jan Niehusmann, Grover, Andrew, Linux Kernel List

On Mon, 27 Aug 2001, Kurt Roeckx wrote:

> On Mon, Aug 27, 2001 at 02:48:24PM +0300, Liakakis Kostas wrote:
> > On Mon, 27 Aug 2001, Jan Niehusmann wrote:
> > 
> > > (asus writes that one of the problems that can happen with this power
> > > saving mode are the huge changes in power dissipation, from 60W to 5W
> > > and back - therefore I assume the power saving mode can save up to 55W)
> > 
> > The problem they are describing is not the change in power dissipation,
> > but the change in current draw from the regulated 1.75V (difference of
> > about 30A or more).
> 
> And what do you think power is?
> Maybe it's the voltage times the current?

Your point being? This is power yeah. However I can get 50W with 1V@50A
and with 50V@1A ... tell me which will be easier for a regulator when
going from 10 to 50W while trying to keep the voltage steady.

So to rephrase myself the condition of less power dissipation (and that is
thermal output, not power consumption which isvoltage times current... )
is the result of less current draw of ~30A. This is a huge difference. And
this is the problem. There are regulators on certain motherboards which
can't cope with this. And they increase (not that bad unless you fry a 
chip) when current drops, or decrease voltage when there is current need
(crash) of the tolerance limmits.

Sorry for the OT.

-K.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27 11:48   ` Liakakis Kostas
@ 2001-08-27 15:03     ` Kurt Roeckx
  2001-08-27 18:23       ` Liakakis Kostas
  0 siblings, 1 reply; 20+ messages in thread
From: Kurt Roeckx @ 2001-08-27 15:03 UTC (permalink / raw)
  To: Liakakis Kostas; +Cc: Jan Niehusmann, Grover, Andrew, Linux Kernel List

On Mon, Aug 27, 2001 at 02:48:24PM +0300, Liakakis Kostas wrote:
> On Mon, 27 Aug 2001, Jan Niehusmann wrote:
> 
> > (asus writes that one of the problems that can happen with this power
> > saving mode are the huge changes in power dissipation, from 60W to 5W
> > and back - therefore I assume the power saving mode can save up to 55W)
> 
> The problem they are describing is not the change in power dissipation,
> but the change in current draw from the regulated 1.75V (difference of
> about 30A or more).

And what do you think power is?
Maybe it's the voltage times the current?


Kurt


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27 10:42 ` Alan Cox
@ 2001-08-27 12:16   ` Dieter Nützel
  2001-08-27 20:17   ` Paul G. Allen
  1 sibling, 0 replies; 20+ messages in thread
From: Dieter Nützel @ 2001-08-27 12:16 UTC (permalink / raw)
  To: Andrew Grover; +Cc: Linux Kernel List

Am Montag, 27. August 2001 12:42 schrieb Alan Cox:
> > handle a too-hot cpu, but all C2/C3 gets you is reduced power when =
> > idle.
> > This results in better battery life on a laptop but that is irrelevant =
> > on a
> > desktop system.
>
> Thus speaks the country with chronic californian power shortages, and that
> wouldn't sign up to a global accord on global warming 8)

We are one step further, here in "old" Germany...

http://www.powerplant-for-sale.com/en/index.htm :-)))

> C2 and C3 are useful IMHO even on a desktop PC. The slight hit on the
> transition is not noticable, the change on the power bill is.

I second that.

-Dieter


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27  9:53 ` Jan Niehusmann
@ 2001-08-27 11:48   ` Liakakis Kostas
  2001-08-27 15:03     ` Kurt Roeckx
  0 siblings, 1 reply; 20+ messages in thread
From: Liakakis Kostas @ 2001-08-27 11:48 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: Grover, Andrew, Linux Kernel List

On Mon, 27 Aug 2001, Jan Niehusmann wrote:

> Motherboard vendors may have disabled the bus disconnection because of a
> 3% performance hit, to make their boards look better in benchmarks.
> In that case, the system may run perfectly stable with disconnection reenabled.

There is still another reason..

> (asus writes that one of the problems that can happen with this power
> saving mode are the huge changes in power dissipation, from 60W to 5W
> and back - therefore I assume the power saving mode can save up to 55W)

The problem they are describing is not the change in power dissipation,
but the change in current draw from the regulated 1.75V (difference of
about 30A or more). During this almost instantaneous transition either
your mobo regulator or your PSU can give up for a while and you get a nice
crash. This tends to happen more often with the 1400-Cs.

-K.




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27  9:26 Grover, Andrew
  2001-08-27  9:53 ` Jan Niehusmann
@ 2001-08-27 10:42 ` Alan Cox
  2001-08-27 12:16   ` Dieter Nützel
  2001-08-27 20:17   ` Paul G. Allen
  2001-09-02 22:28 ` Jan Niehusmann
  2 siblings, 2 replies; 20+ messages in thread
From: Alan Cox @ 2001-08-27 10:42 UTC (permalink / raw)
  To: Grover, Andrew
  Cc: 'Jan Niehusmann',
	Dieter Nützel, Alan Cox, Linux Kernel List,
	'mpet@bigfoot.de'

> handle a too-hot cpu, but all C2/C3 gets you is reduced power when =
> idle.
> This results in better battery life on a laptop but that is irrelevant =
> on a
> desktop system.

Thus speaks the country with chronic californian power shortages, and that
wouldn't sign up to a global accord on global warming 8)

C2 and C3 are useful IMHO even on a desktop PC. The slight hit on the
transition is not noticable, the change on the power bill is.

Alan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-27  9:26 Grover, Andrew
@ 2001-08-27  9:53 ` Jan Niehusmann
  2001-08-27 11:48   ` Liakakis Kostas
  2001-08-27 10:42 ` Alan Cox
  2001-09-02 22:28 ` Jan Niehusmann
  2 siblings, 1 reply; 20+ messages in thread
From: Jan Niehusmann @ 2001-08-27  9:53 UTC (permalink / raw)
  To: Grover, Andrew; +Cc: Linux Kernel List

On Mon, Aug 27, 2001 at 02:26:09AM -0700, Grover, Andrew wrote:
> system's ACPI tables indicates they can be used. If you are attempting to
> use C2 even if your system explicitly does not support it, you are asking
> for trouble, just like AMD's errata says.

Motherboard vendors may have disabled the bus disconnection because of a
3% performance hit, to make their boards look better in benchmarks.
In that case, the system may run perfectly stable with disconnection reenabled.

I agree that these experiments should not be performed on a production
system :) 

> This results in better battery life on a laptop but that is irrelevant on a
> desktop system.

Well, I think saving ~55W is relevant, even on a desktop system. I plan
to measure how much power these hacks really save, and if it's more than
10W, I think it's worth some more work in this area.

Jan

(asus writes that one of the problems that can happen with this power
saving mode are the huge changes in power dissipation, from 60W to 5W
and back - therefore I assume the power saving mode can save up to 55W)

^ permalink raw reply	[flat|nested] 20+ messages in thread

* RE: VCool - cool your Athlon/Duron during idle
@ 2001-08-27  9:26 Grover, Andrew
  2001-08-27  9:53 ` Jan Niehusmann
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Grover, Andrew @ 2001-08-27  9:26 UTC (permalink / raw)
  To: 'Jan Niehusmann', Dieter Nützel
  Cc: Alan Cox, Linux Kernel List, 'mpet@bigfoot.de'

Well I don't want to inhibit your hackerly fervor, but C2 and C3 handling
are already supported by the ACPI driver, in a vendor-neutral manner.

If you take a look at the code, you will notice a few things. First, it only
transitions to a deeper sleep state after doing some number of lighter
sleeps. This is to minimize the performance hit caused by C2/C3 entry and
exit latencies. Second, it only uses a given processor power state if the
system's ACPI tables indicates they can be used. If you are attempting to
use C2 even if your system explicitly does not support it, you are asking
for trouble, just like AMD's errata says.

Besides I'd think any cooling issues would occur when the CPU was 100%
utilized, yes? Why are you trying to optimize the idle loop for power when
it's not the problem? You can throttle the processor or turn a fan on to
handle a too-hot cpu, but all C2/C3 gets you is reduced power when idle.
This results in better battery life on a laptop but that is irrelevant on a
desktop system.

Regards -- Andy

> -----Original Message-----
> From: Jan Niehusmann [mailto:jan@gondor.com]
> Sent: Sunday, August 26, 2001 4:01 PM
> To: Dieter Nützel
> Cc: Alan Cox; Linux Kernel List
> Subject: Re: VCool - cool your Athlon/Duron during idle
> Importance: High
> 
> 
> On Sun, Aug 26, 2001 at 08:09:34PM +0200, Dieter Nützel wrote:
> > Have you read something about this Athlon/Duron cooling problem?
> > Can this code included into your (and/or the official) tree?
> 
> I haven't yet measured if this really saves a significant amount of
> power, but I made a kernel patch closely based on the vcool patch
> from http://www.naggelgames.de/vcool/
> 
> This patch is extremely experimental, but it didn't crash my 
> machine, yet ;-) Some things could probably be more elegant.
> 
> Feel free to comment or use this patch as you like.
> It does only use stpclk if you boot with idle=stpclk
> 
> Jan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
       [not found] ` <E15b6Rz-0002hM-00@the-village.bc.nu.suse.lists.linux.kernel>
@ 2001-08-27  6:55   ` Andi Kleen
  0 siblings, 0 replies; 20+ messages in thread
From: Andi Kleen @ 2001-08-27  6:55 UTC (permalink / raw)
  To: alan, linux-kernel

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Streaming video is not really different to most bus mastering IDE. Its
> just pci card initiated memory writes with timing constraints. For some
> reason having my disk do that makes me very nervous

The bus shutdown is clearly something which shouldn't be done in the normal
idle loop, but only when explicit sleep mode is requested and when the
kernel makes sure that all IO is quiescied [similar to what the sleep code
on the ppc/mac port does; see e.g. 
drivers/macintosh/via-pmu.c:powerbook_sleep_G3]. Such a thing could be 
e.g. controlled from apmd.

-Andi

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 18:09 Dieter Nützel
  2001-08-26 19:24 ` Alan Cox
@ 2001-08-26 23:00 ` Jan Niehusmann
  2001-08-27 22:46   ` Pavel Machek
  1 sibling, 1 reply; 20+ messages in thread
From: Jan Niehusmann @ 2001-08-26 23:00 UTC (permalink / raw)
  To: Dieter Nützel; +Cc: Alan Cox, Linux Kernel List

On Sun, Aug 26, 2001 at 08:09:34PM +0200, Dieter Nützel wrote:
> Have you read something about this Athlon/Duron cooling problem?
> Can this code included into your (and/or the official) tree?

I haven't yet measured if this really saves a significant amount of
power, but I made a kernel patch closely based on the vcool patch
from http://www.naggelgames.de/vcool/

This patch is extremely experimental, but it didn't crash my 
machine, yet ;-) Some things could probably be more elegant.

Feel free to comment or use this patch as you like.
It does only use stpclk if you boot with idle=stpclk

Jan


diff -ur linux-2.4.8-ac7-orig/arch/i386/kernel/pci-i386.h linux-2.4.8-ac7/arch/i386/kernel/pci-i386.h
--- linux-2.4.8-ac7-orig/arch/i386/kernel/pci-i386.h	Fri Jul 13 19:26:14 2001
+++ linux-2.4.8-ac7/arch/i386/kernel/pci-i386.h	Sun Aug 26 21:05:37 2001
@@ -70,3 +70,6 @@
 void pcibios_irq_init(void);
 void pcibios_fixup_irqs(void);
 void pcibios_enable_irq(struct pci_dev *dev);
+
+extern int use_stpclk;
+void idle_setup_stpclk(void);
diff -ur linux-2.4.8-ac7-orig/arch/i386/kernel/pci-pc.c linux-2.4.8-ac7/arch/i386/kernel/pci-pc.c
--- linux-2.4.8-ac7-orig/arch/i386/kernel/pci-pc.c	Sun Aug 19 20:19:49 2001
+++ linux-2.4.8-ac7/arch/i386/kernel/pci-pc.c	Sun Aug 26 21:03:57 2001
@@ -1053,6 +1053,8 @@
 	if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
 		pcibios_sort();
 #endif
+	if(use_stpclk)
+		idle_setup_stpclk();
 }
 
 char * __init pcibios_setup(char *str)
diff -ur linux-2.4.8-ac7-orig/arch/i386/kernel/process.c linux-2.4.8-ac7/arch/i386/kernel/process.c
--- linux-2.4.8-ac7-orig/arch/i386/kernel/process.c	Sun Aug 19 20:19:49 2001
+++ linux-2.4.8-ac7/arch/i386/kernel/process.c	Sun Aug 26 21:56:32 2001
@@ -33,6 +33,7 @@
 #include <linux/reboot.h>
 #include <linux/init.h>
 #include <linux/mc146818rtc.h>
+#include <linux/pci.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
@@ -48,10 +49,13 @@
 #endif
 
 #include <linux/irq.h>
+#include "pci-i386.h"
 
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 
 int hlt_counter;
+int use_stpclk;
+u16 Reg_PL2;
 
 /*
  * Powermanagement idle function, if any..
@@ -88,6 +92,17 @@
 	}
 }
 
+static void stpclk_idle(void)
+{
+	if (current_cpu_data.hlt_works_ok && !hlt_counter) {
+		__cli();
+		if (!current->need_resched) 
+			inb(Reg_PL2);
+		else
+			__sti();
+	}
+}
+
 /*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->need_resched flag instead of waiting for the
@@ -138,11 +153,56 @@
 	}
 }
 
+void __init idle_setup_stpclk (void) {
+	struct pci_dev *nb, *sb;
+	u8 res;
+	u16 io_base;
+	u32 res32;
+	printk("using stpclk# instead of hlt\n");
+	nb=pci_find_subsys(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8363_0,PCI_ANY_ID,PCI_ANY_ID,NULL);
+	if(!nb) 
+		nb=pci_find_subsys(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_8371_0,PCI_ANY_ID,PCI_ANY_ID,NULL);
+	if(!nb) {
+		printk("via northbridge not found - falling back to default idle task\n");
+		return;
+	}
+	sb=pci_find_subsys(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_82C686_4,PCI_ANY_ID,PCI_ANY_ID,NULL);
+	if(!sb) {
+		printk("via southbridge not found - falling back to default idle task\n");
+		return;
+	}
+	pci_read_config_byte(sb,0x41,&res);
+	if ((res &0x8000)==0)
+	{
+		printk("ACPI I/O space disabled - enabling\n");
+		res|=0x8000;
+		pci_write_config_byte(sb,0x41,res);
+	}
+	pci_read_config_word(sb,0x48,&io_base);
+	Reg_PL2=(io_base&0xff80)+0x14;
+	
+
+	pci_read_config_dword(nb,0x90,&res32);
+	if ((res32&0x00800000)==0) {
+		printk("bus disconnect disabled - enabling\n");
+		res32|=0x00800000;
+		pci_write_config_dword(nb,0x90,res32);
+		return;
+	}
+
+	
+	pm_idle = stpclk_idle;
+	return;
+}
+
 static int __init idle_setup (char *str)
 {
 	if (!strncmp(str, "poll", 4)) {
 		printk("using polling idle threads.\n");
 		pm_idle = poll_idle;
+	}
+	if (!strncmp(str, "stpclk",6)) {
+		use_stpclk=1;
 	}
 
 	return 1;


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 20:00   ` Lehmann 
@ 2001-08-26 22:40     ` Andreas Bombe
  0 siblings, 0 replies; 20+ messages in thread
From: Andreas Bombe @ 2001-08-26 22:40 UTC (permalink / raw)
  To: Alan Cox, Dieter Nützel, Linux Kernel List

On Sun, Aug 26, 2001 at 10:00:23PM +0200,  Marc A. Lehmann  wrote:
> On Sun, Aug 26, 2001 at 08:24:20PM +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Well my German isnt that good,
>    
> the page is in english (at least the one you get while clicking on
> linux, which is german and english alike, and gthe source code is rather
> international ;)
> 
> > but it appears to be just another variant
> > on CPU idling.
> 
> The linux version only fiddles with a single bit in the northbridge that
> is claimed to be necessary so the cpu goes into the "real" idle mode. It
> also warns that some streaming applications might react to this with frame
> drops or similar.

According to c't 18/2001 p.36, the real power saving in halt and STPCLK
is only in effect when the CPU disconnects from the FSB.  In the VIA
north bridges there is one bit (bit 7 at offset 0x52) which controls
whether the north bridge performs the disconnect protocol.  For various
reasons, this is usually disabled by the BIOS:

1. Lower quality power supplies and motherboard voltage regulators may
   not be able to deal with the large and fast current changes.

2. Disconnect costs 2% - 3% on common benchmarks.  Incidentally, this is
   also the difference between the fastest and slowest Athlon
   motherboards.  Disconnect doesn't sell, benchmarks do.

3. The internal clock generator of the CPU may lose sync or something on
   reconnect.  (erratum #11, can be worked around by software)

4. In rare cases, Athlons with non-integer frequency multipliers (e.g.
   7.5) may fail to reconnect altogether.  (erratum #14, work around:
   don't sleep in C1 or C2 with disconnect)

Errata as quoted from the article, referring to "AMD Athlon Processor
Model 4 Revision Guide",
http://www.amd.com/products/cpg/athlon/techdocs/pdf/23614.pdf

-- 
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 19:24 ` Alan Cox
  2001-08-26 20:00   ` Lehmann 
@ 2001-08-26 20:25   ` Dieter Nützel
  1 sibling, 0 replies; 20+ messages in thread
From: Dieter Nützel @ 2001-08-26 20:25 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel List, Marc Lehmann

Am Sonntag, 26. August 2001 21:24 schrieb Alan Cox:
> > Have you read something about this Athlon/Duron cooling problem?
> > Can this code included into your (and/or the official) tree?
> > Maybe it is needed for the AMD 750/760/760MP/760MPX, too?
>
> Well my German isnt that good, but it appears to be just another variant
> on CPU idling. We do hlt or APM already, and APM should be doing other
> work if appropriate.

OK, sorry. There is an English version, already...;-)
http://www.naggelgames.de/vcool/

The site deals with the Athlon/Duron and chipset (VIA) short comings and 
current bugs (power saving related). I think it is one of the best (put all 
info together and provide a solution) for the AMD Athlon/Duron hardware 
throttling.

[-]
VCool 1.6

This little utility will cool your Athlon/Duron processor on Via KT133 or 
KX133(A) (VT8363 or VT8371/VT82C686x) chipsets during idle


Features

Controls the "Northbridge Bus Disconnect Bit" to lower your CPUs power level 
during idle

An idle loop that puts your CPU into STPGNT state if your OS won't

Displays the current CPU temperature in your system tray (optional)

Optional hardware throttling of the CPU when it gets too hot (50%, 10%, 
shutdown)

Lightweight: 30K


Requirements

Chipset with a VT8371 or VT8363 Northbridge and a VT82C686x Southbridge (VIA 
KT133x or KX133) - limited support for AMD 761

A Win32 OS (Windows 98 or better - no that does not include LINUX *g*)

For Windows 2000 and NT you'll need the "GiveIO" driver 


How it works

The Athlon (or Duron) enters a lower power state only when its system bus is 
disconnected. However the (VIA-)Northbridge will only disconnect the bus if 
its "Bus Disconnect Enable" bit is set and the CPU is in STPGNT state.
 VCool allows you to enable this bit so your CPU can relax when there's 
nothing to do.

Setting this bit might not be enough on some systems as the idle loop 
provided with the OS will not put the CPU into the STPGNT state recognized by 
the Northbridge.
 For those cases VCool includes an internal idle loop that forces the CPU 
into the STPGNT mode required by the Northbridge to initiate a bus 
disconnect. 

If you want to read more about how this works follow this link.

Note that the system monitor will report 100% utilization when the idle loop 
is active.
 That's because it takes away all idle time from the OS idle loop and the OS 
calculates the utilization like:
 Utilization = 100 % - %age of time spent in OS idle loop.

Also note that disconnecting the system bus to save power might interfere 
with "realtime" applications like TV or sound capturing - causing dropouts or 
other oddities.


What's new in VCool 1.6

The temperature readout on 686 chips was a bit low at high temperatures - now 
VCool uses a new formula based on inofficial data. The "TempDiv" and 
"TempSub" registry keys have been removed.

Added and Apply button in the options dialog

The status of the SBMus is now restored after readout to solve problems with 
ASUS probe. There's also a busy wait option to prevent asus probe from 
interfering with VCools reading - however so far this seems to work only on 
W9x and ME as the preemptive scheduling of W2K and NT requires a driver to 
achieve this - maybe in a later version *g*.

The status of the cool bit and the idle loop are now indicated by small dots 
on the lower left and right of the icon.

<shift>+LClick (<crtl>+LClick) on the icon toggles the Cool bit (idle loop)

The idle loop is turned off now when the temperature drops below T50 (if it 
was off before T50 was exceeded).

There's now a custom shutdown option that will execute a user definable 
program when Tshutdown is exceeded.
[-]

Source is available (even for Linux).

-Dieter


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
       [not found] <87pu9i7frm.fsf@psyche.kn-bremen.de>
@ 2001-08-26 20:24 ` Alan Cox
  0 siblings, 0 replies; 20+ messages in thread
From: Alan Cox @ 2001-08-26 20:24 UTC (permalink / raw)
  To: 520028810828-0001; +Cc: Alan Cox

> Try <http://mpet.freeservers.com/LVCool.html>
> and <http://mpet.freeservers.com/VC_Theory.html>

That says it all for me

"For example I noticed that with the bus disconnect enabled a captured video
is full of dropped or garbled lines."

Streaming video is not really different to most bus mastering IDE. Its
just pci card initiated memory writes with timing constraints. For some
reason having my disk do that makes me very nervous


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 19:24 ` Alan Cox
@ 2001-08-26 20:00   ` Lehmann 
  2001-08-26 22:40     ` Andreas Bombe
  2001-08-26 20:25   ` Dieter Nützel
  1 sibling, 1 reply; 20+ messages in thread
From: Lehmann  @ 2001-08-26 20:00 UTC (permalink / raw)
  To: Alan Cox; +Cc: Dieter Nützel, Linux Kernel List

On Sun, Aug 26, 2001 at 08:24:20PM +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Well my German isnt that good,
   
the page is in english (at least the one you get while clicking on
linux, which is german and english alike, and gthe source code is rather
international ;)

> but it appears to be just another variant
> on CPU idling.

The linux version only fiddles with a single bit in the northbridge that
is claimed to be necessary so the cpu goes into the "real" idle mode. It
also warns that some streaming applications might react to this with frame
drops or similar.

So :/

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: VCool - cool your Athlon/Duron during idle
  2001-08-26 18:09 Dieter Nützel
@ 2001-08-26 19:24 ` Alan Cox
  2001-08-26 20:00   ` Lehmann 
  2001-08-26 20:25   ` Dieter Nützel
  2001-08-26 23:00 ` Jan Niehusmann
  1 sibling, 2 replies; 20+ messages in thread
From: Alan Cox @ 2001-08-26 19:24 UTC (permalink / raw)
  To: Dieter Nützel; +Cc: Alan Cox, Linux Kernel List

> Have you read something about this Athlon/Duron cooling problem?
> Can this code included into your (and/or the official) tree?
> Maybe it is needed for the AMD 750/760/760MP/760MPX, too?

Well my German isnt that good, but it appears to be just another variant
on CPU idling. We do hlt or APM already, and APM should be doing other
work if appropriate.

Alan

^ permalink raw reply	[flat|nested] 20+ messages in thread

* VCool - cool your Athlon/Duron during idle
@ 2001-08-26 18:09 Dieter Nützel
  2001-08-26 19:24 ` Alan Cox
  2001-08-26 23:00 ` Jan Niehusmann
  0 siblings, 2 replies; 20+ messages in thread
From: Dieter Nützel @ 2001-08-26 18:09 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel List

Hello Alan,

Have you read something about this Athlon/Duron cooling problem?
Can this code included into your (and/or the official) tree?
Maybe it is needed for the AMD 750/760/760MP/760MPX, too?

http://www.naggelgames.de/vcool/VCool_de.html

Regards,
	Dieter


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2001-09-02 22:29 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-27 20:57 VCool - cool your Athlon/Duron during idle Grover, Andrew
  -- strict thread matches above, loose matches on Subject: below --
2001-08-27  9:26 Grover, Andrew
2001-08-27  9:53 ` Jan Niehusmann
2001-08-27 11:48   ` Liakakis Kostas
2001-08-27 15:03     ` Kurt Roeckx
2001-08-27 18:23       ` Liakakis Kostas
2001-08-27 20:56         ` Paul G. Allen
2001-08-27 10:42 ` Alan Cox
2001-08-27 12:16   ` Dieter Nützel
2001-08-27 20:17   ` Paul G. Allen
2001-09-02 22:28 ` Jan Niehusmann
     [not found] <87pu9i7frm.fsf@psyche.kn-bremen.de.suse.lists.linux.kernel>
     [not found] ` <E15b6Rz-0002hM-00@the-village.bc.nu.suse.lists.linux.kernel>
2001-08-27  6:55   ` Andi Kleen
     [not found] <87pu9i7frm.fsf@psyche.kn-bremen.de>
2001-08-26 20:24 ` Alan Cox
2001-08-26 18:09 Dieter Nützel
2001-08-26 19:24 ` Alan Cox
2001-08-26 20:00   ` Lehmann 
2001-08-26 22:40     ` Andreas Bombe
2001-08-26 20:25   ` Dieter Nützel
2001-08-26 23:00 ` Jan Niehusmann
2001-08-27 22:46   ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).