Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Ross Dickson]

>"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote: 
> > On Wed, 3 Mar 2004, Thomas Schlichter wrote: 
> > 
> > > a few days ago I noticed that my Athlon 3000+ was relatively hot (49C) 
> > > although it was completely idle. At that time I was running 2.6.3-mm3 with 
> > > ACPI and IOAPIC-support enabled. 
> > > 
> > > As I tried 2.6.3, the idle temperature was at normal 39C. So I did do some 
> > > binary search with the -bk patches and found the patch that causes the high 
> > > idle temperature. It is ChangeSet@1.1626 aka 8259-timer-ack-fix.patch. 
> > 
> > Interesting -- the patch removes a pair of unnecessary for your 
> > configuration PIC accesses when using an I/O APIC NMI watchdog. You have 
> > the NMI watchdog enabled, don't you? 
 
> No, I don't use the NMI watchdog... 
>  So the optimization of removing these I/O accesses is bogus for my configuration. Btw. I don't know if I already mentioned it, but I use the VIA KT400 chipset. Maybe this is of interest... 
 
> The only way to cool down my CPU was to enable timer_ack. 
>  I don't know how to help you, but of course I am willing to test patches... ;-) 
>   Thomas 
 
I agree with Len Brown's comments to try to examine which power saving state but
if you want to try to brute force C1 state ( only works if chipset supported )
you could try this patch for process.c, 
(ignore the io-apic patch as it is nforce2 specific).

http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-02/6520.html
The KERNEL ARG to invoke it is "idle=C1halt". 
 
It has an extra function pointer to prevent the power management idle routine
hikjacking things after the command line arg has requested an idle routine.

These idle mods appear to assist more than just nforce2 Athlon boards.
Thomas Herrmann has had success with an SIS740

> Hi Ross,
> I just want to let you know that your nforce2_idle patch does work with the
> SiS740 chipset too. While the current ACPI patch already routes the timer of
> the SiS740 to IO-APIC-edge with out the C1halt option of your nforce2_idle
> patch the system locked up when STPGNT was enabled. But after I applied your
> nforce2_idle patch to kernel 2.4.24 together with the C1halt kernel boot
> option, the system runs stable for hours.
> Great work, thanks!
> Best regards,   Thomas

Craig Bradney has put it into the gentoo dev sources also.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/1746.html

Hope this helps,
Ross.

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Craig Bradney]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

> > > > a few days ago I noticed that my Athlon 3000+ was relatively hot (49C) 
> > > > although it was completely idle. At that time I was running 2.6.3-mm3 with 
> > > > ACPI and IOAPIC-support enabled. 
> > > > 
> > > > As I tried 2.6.3, the idle temperature was at normal 39C. So I did do some 
> > > > binary search with the -bk patches and found the patch that causes the high 
> > > > idle temperature. It is ChangeSet@1.1626 aka 8259-timer-ack-fix.patch. 
> > > 
> > > Interesting -- the patch removes a pair of unnecessary for your 
> > > configuration PIC accesses when using an I/O APIC NMI watchdog. You have 
> > > the NMI watchdog enabled, don't you? 
>  
> > No, I don't use the NMI watchdog... 
> >  So the optimization of removing these I/O accesses is bogus for my configuration. Btw. I don't know if I already mentioned it, but I use the VIA KT400 chipset. Maybe this is of interest... 
>  
> > The only way to cool down my CPU was to enable timer_ack. 
> >  I don't know how to help you, but of course I am willing to test patches... ;-) 
> >   Thomas 
>  
> I agree with Len Brown's comments to try to examine which power saving state but
> if you want to try to brute force C1 state ( only works if chipset supported )
> you could try this patch for process.c, 
> (ignore the io-apic patch as it is nforce2 specific).
> 
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-02/6520.html
> The KERNEL ARG to invoke it is "idle=C1halt". 
>  
> It has an extra function pointer to prevent the power management idle routine
> hikjacking things after the command line arg has requested an idle routine.
> 
> These idle mods appear to assist more than just nforce2 Athlon boards.
> Thomas Herrmann has had success with an SIS740
> 
> > Hi Ross,
> > I just want to let you know that your nforce2_idle patch does work with the
> > SiS740 chipset too. While the current ACPI patch already routes the timer of
> > the SiS740 to IO-APIC-edge with out the C1halt option of your nforce2_idle
> > patch the system locked up when STPGNT was enabled. But after I applied your
> > nforce2_idle patch to kernel 2.4.24 together with the C1halt kernel boot
> > option, the system runs stable for hours.
> > Great work, thanks!
> > Best regards,   Thomas
> 
> Craig Bradney has put it into the gentoo dev sources also.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/1746.html

Ross, your patch is pretty damn stable.. I had to shut down the PC today
due to expected wiring changes (lucky, a blackout came before the wiring
changes!).. the PC was at over 8 days uptime. At first I thought the box
was cooler.. now my observations are as follows:
At idle and under load the motherboard temp is 1-2C lower.
At idle the CPU is about the same
When compiling it gets to be a bit hotter than before but I have taken
one fan offline so I'm not sure of the result but its still only reaches
45C. I'll try again soon with the 2nd fan on and see what its like.

Craig

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Bernd Schubert]

Hi,

I'm just testing your IdleC1Halt patch (didn't reboot yet) with 2.6.4, but 
there is a problem if apm is enabled in the configuration: 

arch/i386/kernel/built-in.o(.text+0x10b65): In function `apm_cpu_idle':
: undefined reference to `default_idle'

Your patch sets default_idle() static, so its not available in apm.c file. 

Usually I compile with acpi and apm support to switch between both in case of 
an unsual problem, and I think many people also do so.


> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-02/6520.html
> The KERNEL ARG to invoke it is "idle=C1halt".
>

Thanks,
	Bernd

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Ross Dickson]

On Thursday 18 March 2004 21:41, Bernd Schubert wrote:
> Hi,
> 
> I'm just testing your IdleC1Halt patch (didn't reboot yet) with 2.6.4, but 
> there is a problem if apm is enabled in the configuration: 
> 
> arch/i386/kernel/built-in.o(.text+0x10b65): In function `apm_cpu_idle':
> : undefined reference to `default_idle'
> 
> Your patch sets default_idle() static, so its not available in apm.c file. 
> 
Apologies - Unnecessary change, I only use acpi and was cleaning things up.

It should still work fine by removing the static from it as "idle()" get first try.
change
static void default_idle(void) 
back to
void default_idle(void) 

> Usually I compile with acpi and apm support to switch between both in case of 
> an unsual problem, and I think many people also do so.

Please let me know how it goes.

Ross.

> 
> 
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-02/6520.html
> > The KERNEL ARG to invoke it is "idle=C1halt".
> >
> 
> Thanks,
> 	Bernd
> 
> 
> 
> 

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Thomas Schlichter]

Am Donnerstag, 18. März 2004 01:19 schrieb Ross Dickson:

~~ snip ~~

> > The only way to cool down my CPU was to enable timer_ack.
> >  I don't know how to help you, but of course I am willing to test
> > patches... ;-) Thomas
>
> I agree with Len Brown's comments to try to examine which power saving
> state but if you want to try to brute force C1 state ( only works if
> chipset supported ) you could try this patch for process.c,
> (ignore the io-apic patch as it is nforce2 specific).
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-02/6520.html
> The KERNEL ARG to invoke it is "idle=C1halt".
>
> It has an extra function pointer to prevent the power management idle
> routine hikjacking things after the command line arg has requested an idle
> routine.
>
> These idle mods appear to assist more than just nforce2 Athlon boards.
> Thomas Herrmann has had success with an SIS740
>
> > Hi Ross,
> > I just want to let you know that your nforce2_idle patch does work with
> > the SiS740 chipset too. While the current ACPI patch already routes the
> > timer of the SiS740 to IO-APIC-edge with out the C1halt option of your
> > nforce2_idle patch the system locked up when STPGNT was enabled. But
> > after I applied your nforce2_idle patch to kernel 2.4.24 together with
> > the C1halt kernel boot option, the system runs stable for hours.
> > Great work, thanks!
> > Best regards,   Thomas
>
> Craig Bradney has put it into the gentoo dev sources also.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/1746.html

OK, now I had the time to test if different C states are working with 
following three kernels:

1. 2.6.4-mm2 without the 8259-timer-ack-fix.patch and without the C1halt idle 
function.
2. 2.6.4-mm2 with the 8259-timer-ack-fix.patch and without the C1 halt idle 
function enabled.
3. 2.6.4-mm2 with the 8259-timer-ack-fix.patch and with the C1 halt idle 
function enabled.

I used following script to print the C-state counters on an complete idle 
machine before and after a 10second interval:

# /bin/sh
cat /proc/acpi/processor/CPU0/power
sleep 10
cat /proc/acpi/processor/CPU0/power

Now the results:

1.:
active state:            C2
default state:           C1
bus master activity:     00000000
states:
    C1:                  promotion[C2] demotion[--] latency[000] 
usage[00006280]
   *C2:                  promotion[--] demotion[C1] latency[100] 
usage[00300041]
    C3:                  <not supported>
active state:            C2
default state:           C1
bus master activity:     00000000
states:
    C1:                  promotion[C2] demotion[--] latency[000] 
usage[00006300]
   *C2:                  promotion[--] demotion[C1] latency[100] 
usage[00310045]
    C3:                  <not supported>

2.:
active state:            C1
default state:           C1
bus master activity:     00000000
states:
   *C1:                  promotion[C2] demotion[--] latency[000] 
usage[00000000]
    C2:                  promotion[--] demotion[C1] latency[100] 
usage[00000000]
    C3:                  <not supported>
active state:            C1
default state:           C1
bus master activity:     00000000
states:
   *C1:                  promotion[C2] demotion[--] latency[000] 
usage[00000000]
    C2:                  promotion[--] demotion[C1] latency[100] 
usage[00000000]
    C3:                  <not supported>

3.:
active state:            C1
default state:           C1
bus master activity:     00000000
states:
   *C1:                  promotion[C2] demotion[--] latency[000] 
usage[00000000]
    C2:                  promotion[--] demotion[C1] latency[100] 
usage[00000000]
    C3:                  <not supported>
active state:            C1
default state:           C1
bus master activity:     00000000
states:
   *C1:                  promotion[C2] demotion[--] latency[000] 
usage[00000000]
    C2:                  promotion[--] demotion[C1] latency[100] 
usage[00000000]
    C3:                  <not supported>

So, as you can see, the C1halt patch does not help here... ;-(

Regards
   Thomas Schlichter

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Prakash K. Cheemplavam]

 > OK, now I had the time to test if different C states are working with
 > following three kernels:
 >
 > 1. 2.6.4-mm2 without the 8259-timer-ack-fix.patch and without the 
C1halt idle
 > function.
 > 2. 2.6.4-mm2 with the 8259-timer-ack-fix.patch and without the C1 
halt idle
 > function enabled.
 > 3. 2.6.4-mm2 with the 8259-timer-ack-fix.patch and with the C1 halt idle
 > function enabled.
 >
 > I used following script to print the C-state counters on an complete 
idle
 > machine before and after a 10second interval:
 >
 > # /bin/sh
 > cat /proc/acpi/processor/CPU0/power
 > sleep 10
 > cat /proc/acpi/processor/CPU0/power
 >
 > Now the results:

[snip]

> 3.:
> active state:            C1
> default state:           C1
> bus master activity:     00000000
> states:
>    *C1:                  promotion[C2] demotion[--] latency[000] 
> usage[00000000]
>     C2:                  promotion[--] demotion[C1] latency[100] 
> usage[00000000]
>     C3:                  <not supported>
> active state:            C1
> default state:           C1
> bus master activity:     00000000
> states:
>    *C1:                  promotion[C2] demotion[--] latency[000] 
> usage[00000000]
>     C2:                  promotion[--] demotion[C1] latency[100] 
> usage[00000000]
>     C3:                  <not supported>
> 
> So, as you can see, the C1halt patch does not help here... ;-(

Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
active state:            C1
default state:           C1
bus master activity:     00000000
states:
    *C1:                  promotion[--] demotion[--] latency[000] 
usage[00000000]
     C2:                  <not supported>
     C3:                  <not supported>

I am currently NOT using APIC mode (nforce2, as well) and using vanilla 
2.6.4. It seems C1 halt state isn't used, which exlains why I am having 
trouble to keep my CPU cooler these day. I once started a thread 
suspecting acpi timer, but it is not the case. It seems to be something 
else. As I don't use PIC, it cannot be that  8259-timer-ack-fix.patch 
causin git, or can it? Maybe something broken in ACPI? I might try out 
older kernels to find out...

Prakash

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Len Brown]

On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:

> Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
> active state:            C1
> default state:           C1
> bus master activity:     00000000
> states:
>     *C1:                  promotion[--] demotion[--] latency[000] 
> usage[00000000]
>      C2:                  <not supported>
>      C3:                  <not supported>
> 
> I am currently NOT using APIC mode (nforce2, as well) and using vanilla 
> 2.6.4. It seems C1 halt state isn't used, which exlains why I am having 
> trouble to keep my CPU cooler these day. I once started a thread 
> suspecting acpi timer, but it is not the case. It seems to be something 
> else. As I don't use PIC, it cannot be that  8259-timer-ack-fix.patch 
> causin git, or can it? Maybe something broken in ACPI? I might try out 
> older kernels to find out...
> 
> Prakash

Actually I think it is that we don't _count_ C1 usage.

cheers,
-Len

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Prakash K. Cheemplavam]

Len Brown wrote:
> On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
> 
> 
>>Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
>>active state:            C1
>>default state:           C1
>>bus master activity:     00000000
>>states:
>>    *C1:                  promotion[--] demotion[--] latency[000] 
>>usage[00000000]
>>     C2:                  <not supported>
>>     C3:                  <not supported>
>>
>>I am currently NOT using APIC mode (nforce2, as well) and using vanilla 
>>2.6.4. It seems C1 halt state isn't used, which exlains why I am having 
[snip]
> 
> 
> Actually I think it is that we don't _count_ C1 usage.

Hmm, OK, then I am really puzzled what specifically about mm sources 
make my idle temps hotter, as I still couldn't properly resolve it what 
is causing it. I thought ACPI, but no, using APM only does the same (apm 
only with vanilla is low temp though.)

Prakash

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Ross Dickson]

On Saturday 20 March 2004 19:29, Prakash K. Cheemplavam wrote:
> Len Brown wrote:
> > On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
> > 
> > 
> >>Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
> >>active state:            C1
> >>default state:           C1
> >>bus master activity:     00000000
> >>states:
> >>    *C1:                  promotion[--] demotion[--] latency[000] 
> >>usage[00000000]
> >>     C2:                  <not supported>
> >>     C3:                  <not supported>
> >>
> >>I am currently NOT using APIC mode (nforce2, as well) and using vanilla 
> >>2.6.4. It seems C1 halt state isn't used, which exlains why I am having 
> [snip]
> > 
> > 
> > Actually I think it is that we don't _count_ C1 usage.
> 
> Hmm, OK, then I am really puzzled what specifically about mm sources 
> make my idle temps hotter, as I still couldn't properly resolve it what 
> is causing it. I thought ACPI, but no, using APM only does the same (apm 
> only with vanilla is low temp though.)

Hi Prakash,

Have you seen this thread, it may be relevant?
Re: [2.6.4-rc2] bogus semicolon behind if()
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html

I have not looked to see which kern sources besides 2.6.4-rc2 may have it.

Regards
Ross.


> 
> Prakash
> 
> 
> 

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Prakash K. Cheemplavam]

Ross Dickson wrote:
> On Saturday 20 March 2004 19:29, Prakash K. Cheemplavam wrote:
> 
>>Len Brown wrote:
>>
>>>On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>
>>>>Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
>>>>active state:            C1
>>>>default state:           C1
>>>>bus master activity:     00000000
>>>>states:
>>>>   *C1:                  promotion[--] demotion[--] latency[000] 
>>>>usage[00000000]
>>>>    C2:                  <not supported>
>>>>    C3:                  <not supported>
>>>>
>>>>I am currently NOT using APIC mode (nforce2, as well) and using vanilla 
>>>>2.6.4. It seems C1 halt state isn't used, which exlains why I am having 
>>
>>[snip]
>>
>>>
>>>Actually I think it is that we don't _count_ C1 usage.
>>
>>Hmm, OK, then I am really puzzled what specifically about mm sources 
>>make my idle temps hotter, as I still couldn't properly resolve it what 
>>is causing it. I thought ACPI, but no, using APM only does the same (apm 
>>only with vanilla is low temp though.)
> 
> 
> Have you seen this thread, it may be relevant?
> Re: [2.6.4-rc2] bogus semicolon behind if()
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html

Hi Ross, I don't think so, as I currently don't use APIC and thus fix in 
above post wouldn't help me. Or should I read further?

cya,

Prakash

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Ross Dickson]

On Saturday 20 March 2004 20:25, Prakash K. Cheemplavam wrote:
> Ross Dickson wrote:
> >>[snip]
> >>
> >>>
> >>>Actually I think it is that we don't _count_ C1 usage.
> >>
> >>Hmm, OK, then I am really puzzled what specifically about mm sources 
> >>make my idle temps hotter, as I still couldn't properly resolve it what 
> >>is causing it. I thought ACPI, but no, using APM only does the same (apm 
> >>only with vanilla is low temp though.)
> > 
> > 
> > Have you seen this thread, it may be relevant?
> > Re: [2.6.4-rc2] bogus semicolon behind if()
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html
> 
> Hi Ross, I don't think so, as I currently don't use APIC and thus fix in 
> above post wouldn't help me. Or should I read further?

Hmm Valid point.
bye
Ross.

> 
> cya,
> 
> Prakash
> 
> 
> 
> 

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On 20.03.2004, at 00:20, Len Brown wrote:

> Actually I think it is that we don't _count_ C1 usage.

Are you sure? At least it seems we do in 2.6.4:
active state:            C2
default state:           C1
bus master activity:     00000000
states:
     C1:                  promotion[C2] demotion[--] latency[000] 
usage[00067690]
    *C2:                  promotion[--] demotion[C1] latency[090] 
usage[00673373]
     C3:                  <not supported>

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Prakash K. Cheemplavam]

Prakash K. Cheemplavam wrote:
> Ross Dickson wrote:
> 
>> On Saturday 20 March 2004 19:29, Prakash K. Cheemplavam wrote:
>>
>>> Len Brown wrote:
>>>
>>>> On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
>>>>
>>>>
>>>>
>>>>> Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
>>>>> active state:            C1
>>>>> default state:           C1
>>>>> bus master activity:     00000000
>>>>> states:
>>>>>   *C1:                  promotion[--] demotion[--] latency[000] 
>>>>> usage[00000000]
>>>>>    C2:                  <not supported>
>>>>>    C3:                  <not supported>
>>>>>
>>>>> I am currently NOT using APIC mode (nforce2, as well) and using 
>>>>> vanilla 2.6.4. It seems C1 halt state isn't used, which exlains why 
>>>>> I am having 
>>>
>>>
>>> [snip]
>>>
>>>>
>>>> Actually I think it is that we don't _count_ C1 usage.
>>>
>>>
>>> Hmm, OK, then I am really puzzled what specifically about mm sources 
>>> make my idle temps hotter, as I still couldn't properly resolve it 
>>> what is causing it. I thought ACPI, but no, using APM only does the 
>>> same (apm only with vanilla is low temp though.)
>>
>>
>>
>> Have you seen this thread, it may be relevant?
>> Re: [2.6.4-rc2] bogus semicolon behind if()
>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html
> 
> 

So, I seem to have found the bugger causing higher temps: It is NVidia 
binary driver, or rather its AGP part of the 53.36 driver. Using AGPGART 
and Nvidia driver leaves my system cool. Using NVAGP it seems as though 
C1 state isn't actually used anymore thus making the CPU hotter.

Tested with (and without) ACPI and APIC (and Ross' tack patch). 
Currently running in PIC mode (with ACPI) and idle temp of 44°C (instead 
of about 50°C...). But it was as cool in APIC mode.

Of course I have to test few more days, but at least currently I am 
happy again. :-)

Prakash

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Ross Dickson]

On Tuesday 30 March 2004 05:59, Prakash K. Cheemplavam wrote:
> Prakash K. Cheemplavam wrote:
> > Ross Dickson wrote:
> > 
> >> On Saturday 20 March 2004 19:29, Prakash K. Cheemplavam wrote:
> >>
> >>> Len Brown wrote:
> >>>
> >>>> On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
> >>>>> active state:            C1
> >>>>> default state:           C1
> >>>>> bus master activity:     00000000
> >>>>> states:
> >>>>>   *C1:                  promotion[--] demotion[--] latency[000] 
> >>>>> usage[00000000]
> >>>>>    C2:                  <not supported>
> >>>>>    C3:                  <not supported>
> >>>>>
> >>>>> I am currently NOT using APIC mode (nforce2, as well) and using 
> >>>>> vanilla 2.6.4. It seems C1 halt state isn't used, which exlains why 
> >>>>> I am having 
> >>>
> >>>
> >>> [snip]
> >>>
> >>>>
> >>>> Actually I think it is that we don't _count_ C1 usage.
> >>>
> >>>
> >>> Hmm, OK, then I am really puzzled what specifically about mm sources 
> >>> make my idle temps hotter, as I still couldn't properly resolve it 
> >>> what is causing it. I thought ACPI, but no, using APM only does the 
> >>> same (apm only with vanilla is low temp though.)
> >>
> >>
> >>
> >> Have you seen this thread, it may be relevant?
> >> Re: [2.6.4-rc2] bogus semicolon behind if()
> >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html
> > 
> > 
> 
> So, I seem to have found the bugger causing higher temps: It is NVidia 
> binary driver, or rather its AGP part of the 53.36 driver. Using AGPGART 
> and Nvidia driver leaves my system cool. Using NVAGP it seems as though 
> C1 state isn't actually used anymore thus making the CPU hotter.

Hmmm.
Would you happen to have a copy of athcool handy - it would be interesting to
see the northbridge disconnect bit status - if its been turned off by their driver?

> 
> Tested with (and without) ACPI and APIC (and Ross' tack patch). 
> Currently running in PIC mode (with ACPI) and idle temp of 44°C (instead 
> of about 50°C...). But it was as cool in APIC mode.
> 
> Of course I have to test few more days, but at least currently I am 
> happy again. :-)
> 
> Prakash
> 
> 
> 

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Prakash K. Cheemplavam]

Ross Dickson wrote:
> On Tuesday 30 March 2004 05:59, Prakash K. Cheemplavam wrote:
> 
>>Prakash K. Cheemplavam wrote:
>>
>>>Ross Dickson wrote:
>>>
>>>
>>>>On Saturday 20 March 2004 19:29, Prakash K. Cheemplavam wrote:
>>>>
>>>>
>>>>>Len Brown wrote:
>>>>>
>>>>>
>>>>>>On Fri, 2004-03-19 at 14:22, Prakash K. Cheemplavam wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hmm, I just did a cat /proc/acpi/processor/CPU0/power:
>>>>>>>active state:            C1
>>>>>>>default state:           C1
>>>>>>>bus master activity:     00000000
>>>>>>>states:
>>>>>>>  *C1:                  promotion[--] demotion[--] latency[000] 
>>>>>>>usage[00000000]
>>>>>>>   C2:                  <not supported>
>>>>>>>   C3:                  <not supported>
>>>>>>>
>>>>>>>I am currently NOT using APIC mode (nforce2, as well) and using 
>>>>>>>vanilla 2.6.4. It seems C1 halt state isn't used, which exlains why 
>>>>>>>I am having 
>>>>>
>>>>>
>>>>>[snip]
>>>>>
>>>>>
>>>>>>Actually I think it is that we don't _count_ C1 usage.
>>>>>
>>>>>
>>>>>Hmm, OK, then I am really puzzled what specifically about mm sources 
>>>>>make my idle temps hotter, as I still couldn't properly resolve it 
>>>>>what is causing it. I thought ACPI, but no, using APM only does the 
>>>>>same (apm only with vanilla is low temp though.)
>>>>
>>>>
>>>>
>>>>Have you seen this thread, it may be relevant?
>>>>Re: [2.6.4-rc2] bogus semicolon behind if()
>>>>http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/4170.html
>>>
>>>
>>So, I seem to have found the bugger causing higher temps: It is NVidia 
>>binary driver, or rather its AGP part of the 53.36 driver. Using AGPGART 
>>and Nvidia driver leaves my system cool. Using NVAGP it seems as though 
>>C1 state isn't actually used anymore thus making the CPU hotter.
> 
> 
> Hmmm.
> Would you happen to have a copy of athcool handy - it would be interesting to
> see the northbridge disconnect bit status - if its been turned off by their driver?

That is the funny thing: Athcool reports it is on. So something from 
their AGP code seems to prevent the CPU going "full idle", I guess. 
Well, now I am using 53.41 driver with agpgart and everything finally 
seems to be stable, cool and nice. :)

Prakash

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Thomas Schlichter]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:
> On Wed, 3 Mar 2004, Thomas Schlichter wrote:
> 
> > a few days ago I noticed that my Athlon 3000+ was relatively hot (49C) 
> > although it was completely idle. At that time I was running 2.6.3-mm3 with 
> > ACPI and IOAPIC-support enabled.
> > 
> > As I tried 2.6.3, the idle temperature was at normal 39C. So I did do some 
> > binary search with the -bk patches and found the patch that causes the high 
> > idle temperature. It is ChangeSet@1.1626 aka 8259-timer-ack-fix.patch.
> 
> Interesting -- the patch removes a pair of unnecessary for your
> configuration PIC accesses when using an I/O APIC NMI watchdog. You have 
> the NMI watchdog enabled, don't you?

No, I don't use the NMI watchdog...
So the optimization of removing these I/O accesses is bogus for my configuration. Btw. I don't know if I already mentioned it, but I use the VIA KT400 chipset. Maybe this is of interest...

The only way to cool down my CPU was to enable timer_ack.
I don't know how to help you, but of course I am willing to test patches... ;-)

   Thomas

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Len Brown]

Look in /proc/acpi/processor/CPU0/power
and see if the usage for the higher C-state numbers
is different between the two kernels.

Higher c-states save more power.

cheers,
-Len

Re: idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Maciej W. Rozycki]

On Wed, 3 Mar 2004, Thomas Schlichter wrote:

> a few days ago I noticed that my Athlon 3000+ was relatively hot (49C) 
> although it was completely idle. At that time I was running 2.6.3-mm3 with 
> ACPI and IOAPIC-support enabled.
> 
> As I tried 2.6.3, the idle temperature was at normal 39C. So I did do some 
> binary search with the -bk patches and found the patch that causes the high 
> idle temperature. It is ChangeSet@1.1626 aka 8259-timer-ack-fix.patch.

 Interesting -- the patch removes a pair of unnecessary for your
configuration PIC accesses when using an I/O APIC NMI watchdog.  You have 
the NMI watchdog enabled, don't you?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

idle Athlon with IOAPIC is 10C warmer since 2.6.3-bk1

[Thomas Schlichter]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

Hi,

a few days ago I noticed that my Athlon 3000+ was relatively hot (49C) 
although it was completely idle. At that time I was running 2.6.3-mm3 with 
ACPI and IOAPIC-support enabled.

As I tried 2.6.3, the idle temperature was at normal 39C. So I did do some 
binary search with the -bk patches and found the patch that causes the high 
idle temperature. It is ChangeSet@1.1626 aka 8259-timer-ack-fix.patch.

A patch to revert that ChangeSet for 2.6.4-rc1-mm2 is attached.

Best regards
   Thomas Schlichter

P.S.: The high idle temperature only shows if the  IOAPIC is used.
P.P.S: I already sent this mail last saturday, but as it seems to have never 
reached LKML I send it again. I'm sorry if you got it twice!

[-- Attachment #2: revert-8259-timer-ack-fix.patch --]
[-- Type: text/x-diff, Size: 1705 bytes --]

--- linux-2.6.4-rc1-mm2/arch/i386/kernel/io_apic.c.orig	2004-03-03 14:56:10.000000000 +0100
+++ linux-2.6.4-rc1-mm2/arch/i386/kernel/io_apic.c	2004-03-03 17:35:03.000000000 +0100
@@ -2157,10 +2157,6 @@ static inline void check_timer(void)
 {
 	int pin1, pin2;
 	int vector;
-	unsigned int ver;
-
-	ver = apic_read(APIC_LVR);
-	ver = GET_APIC_VERSION(ver);
 
 	/*
 	 * get/set the timer IRQ vector:
@@ -2174,17 +2170,11 @@ static inline void check_timer(void)
 	 * mode for the 8259A whenever interrupts are routed
 	 * through I/O APICs.  Also IRQ0 has to be enabled in
 	 * the 8259A which implies the virtual wire has to be
-	 * disabled in the local APIC.  Finally timer interrupts
-	 * need to be acknowledged manually in the 8259A for
-	 * do_slow_timeoffset() and for the i82489DX when using
-	 * the NMI watchdog.
+	 * disabled in the local APIC.
 	 */
 	apic_write_around(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT);
 	init_8259A(1);
-	if (nmi_watchdog == NMI_IO_APIC && !APIC_INTEGRATED(ver))
-		timer_ack = 1;
-	else
-		timer_ack = !cpu_has_tsc;
+	timer_ack = 1;
 	enable_8259A_irq(0);
 
 	pin1 = find_isa_irq_pin(0, mp_INT);
@@ -2202,8 +2192,7 @@ static inline void check_timer(void)
 				disable_8259A_irq(0);
 				setup_nmi();
 				enable_8259A_irq(0);
-				if (check_nmi_watchdog() < 0);
-					timer_ack = !cpu_has_tsc;
+				check_nmi_watchdog();
 			}
 			return;
 		}
@@ -2226,8 +2215,7 @@ static inline void check_timer(void)
 				add_pin_to_irq(0, 0, pin2);
 			if (nmi_watchdog == NMI_IO_APIC) {
 				setup_nmi();
-				if (check_nmi_watchdog() < 0);
-					timer_ack = !cpu_has_tsc;
+				check_nmi_watchdog();
 			}
 			return;
 		}