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 [email protected] 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!
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 [email protected] 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: [email protected], PGP key available +
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
"Maciej W. Rozycki" <[email protected]> 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 [email protected] 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
>"Maciej W. Rozycki" <[email protected]> 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 [email protected] 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.
> > > > 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 [email protected] 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
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
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
>
>
>
>
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
> 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
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
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
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
>
>
>
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
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
>
>
>
>
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
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
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
>
>
>
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