hi there!
a few month ago someone has posted a patch for enabling the disconneect
on STPGND detect function in the kt133/kt133a chipset. for those who don't
know what this does: it sets a bit in a register of the northbridge of the
chipset to enable the power saving modes of the athlon/duron/athlon xp
prozessors.
i did not found any patch which enables this function on an kt266/kt266a
board. so i modified this patch (
http://groups.google.com/groups?q=via_disconnect&hl=en&selm=linux.kernel.20010903002855.A645%40gondor.com&rnum=1
)
to support the kt266 and kt266a chipset to.
now i am looking for people to test the patch and repord, whether it works
allright on other computers than my computer (i tested this patch on an
epox 8kha+ whith an xp1600+).
if you want to test this patch:
1. first apply the patch
2. enable generel-setup -> acpi , acpi-bus-maager , prozessor
in the kernel config
3. add to the "append" line in /etc/lilo.conf the "amd_disconnect=yes"
statemand (or after reboot enter at the kernel-boot-prompt
"amd_disconnect=yes")
4. build a knew kernel
5. report to me, whether you have problems ...
if the patch gets a good feedback, maybe it is something for the official
kernel tree ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
Maybe.... just maybe... attach the patch?
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Daniel Nofftz
Sent: 22 January 2002 17:15
To: Linux Kernel Mailing List
Subject: [patch] amd athlon cooling on kt266/266a chipset
hi there!
a few month ago someone has posted a patch for enabling the disconneect
on STPGND detect function in the kt133/kt133a chipset. for those who
don't
know what this does: it sets a bit in a register of the northbridge of
the
chipset to enable the power saving modes of the athlon/duron/athlon xp
prozessors.
i did not found any patch which enables this function on an kt266/kt266a
board. so i modified this patch (
http://groups.google.com/groups?q=via_disconnect&hl=en&selm=linux.kernel
.20010903002855.A645%40gondor.com&rnum=1
)
to support the kt266 and kt266a chipset to.
now i am looking for people to test the patch and repord, whether it
works
allright on other computers than my computer (i tested this patch on an
epox 8kha+ whith an xp1600+).
if you want to test this patch:
1. first apply the patch
2. enable generel-setup -> acpi , acpi-bus-maager , prozessor
in the kernel config
3. add to the "append" line in /etc/lilo.conf the "amd_disconnect=yes"
statemand (or after reboot enter at the kernel-boot-prompt
"amd_disconnect=yes")
4. build a knew kernel
5. report to me, whether you have problems ...
if the patch gets a good feedback, maybe it is something for the
official
kernel tree ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Tue, 22 Jan 2002, Lee Packham wrote:
> Maybe.... just maybe... attach the patch?
hi!
allready done ... i forget it in the first mail ... i reposted the mail
around 5 minutes later with the patch aattached :)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
You wrote:
> hi there!
>
> a few month ago someone has posted a patch for enabling the disconneect
> on STPGND detect function in the kt133/kt133a chipset.
Maybe it's time for AMD/VIA/SiS/Nvidia, etc. to come up with there code for
_ALL_ Athlon/Duron chipsets???
As we are in trouble with AMD 4MB pages, yet.
Have a look at http://www.vcool.de
Regards,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Tue, 22 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> Maybe it's time for AMD/VIA/SiS/Nvidia, etc. to come up with there code for
> _ALL_ Athlon/Duron chipsets???
> As we are in trouble with AMD 4MB pages, yet.
>
> Have a look at http://www.vcool.de
yes ... maybee ... the problem is , that the disconnect-function is
enabled by the chipset ... and it is a different register in every
different chipset. so it is a little bit difficult to make a solution for
all chipsets.
by the way ... i know http://www.vcool.de ... my work is partialy based on this.
but the vcool linux patch/version does not support kt266/kt266a chipset.
(only the kt/kx133 chipset)
after some mail exchange with the developer of vcool, i decided to wrote a
kernelpatch, which supports the kt266/kt266a chipset too. (one of my
reasosns for this was, that the developer of vcool will not develop the
linux version further) .
the second thing is, that this patch is a little bit simpler then the
(l)vcool approach ... i think ... :)
ah ... if someone sends me the the needed informations, which registers
(or register-bits) are to be changed on ther chipsets to activate the
disconnect-function, i will add this chipsets to the patch.
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Tuesday, 22. January 2002 23:21, Daniel Nofftz wrote:
> On Tue, 22 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> > Maybe it's time for AMD/VIA/SiS/Nvidia, etc. to come up with there code
> > for _ALL_ Athlon/Duron chipsets???
> > As we are in trouble with AMD 4MB pages, yet.
> >
> > Have a look at http://www.vcool.de
>
> yes ... maybee ... the problem is , that the disconnect-function is
> enabled by the chipset ... and it is a different register in every
> different chipset. so it is a little bit difficult to make a solution for
> all chipsets.
I know that and my intention was that we _NEED_ documentation to support it
on _ALL_ chipsets out there.
AMD should notice how many people using there CPUs and I think they do know
it.
So let's make a call.
> by the way ... i know http://www.vcool.de ... my work is partialy based on this.
> but the vcool linux patch/version does not support kt266/kt266a chipset.
> (only the kt/kx133 chipset)
I know.
> after some mail exchange with the developer of vcool,
I did that, too.
Andreas Jaeger (SuSE) told me that maybe he could help.
He got the USB patch information for the AMD Irongate after a few days out of
them...
> i decided to wrote a kernelpatch, which supports the kt266/kt266a chipset
> too.
Good work.
> (one of my reasosns for this was, that the developer of vcool will not
> develop the linux version further) .
Sadly to hear.
> the second thing is, that this patch is a little bit simpler then the
> (l)vcool approach ... i think ... :)
I can't compare 'cause I have the AMD Irongate C4...;-)
> ah ... if someone sends me the the needed informations, which registers
> (or register-bits) are to be changed on ther chipsets to activate the
> disconnect-function, i will add this chipsets to the patch.
I hope we get some info, now.
-Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
I'm confused by all of the posts and websites that
I've read. In particular, some of the wattage and
temperature claims seem outrageous. So, here's
what I've been able to discover
1. According to AMD specs, the model 3 Duron's don't
use more that 40 Watts maximum.
2. With my Duron 800 on a KT133A chipset
running folding@home and seti@home
continuously, LM sensors reports:
SYS Temp: +45.2?C
CPU Temp: +35.1?C
SBr Temp: +25.8?C
So, I see absolutely no cause for alarm, nor even a need for
lvcool (esp. not when running seti@home). And I certainly
haven't seen any Athlon PSE/AGP lockups. So, are you all
overclockng your systems to an incredible amount (again,
that's something that seems really stupid to me since the
$$ difference between 1GHz and 800MHz is not worth the
potential damage; and the duron is up to 1.3GHz now....)
--
[email protected].
On Wed, 23 Jan 2002, Timothy Covell wrote:
> 1. According to AMD specs, the model 3 Duron's don't
> use more that 40 Watts maximum.
>
> 2. With my Duron 800 on a KT133A chipset
> running folding@home and seti@home
> continuously, LM sensors reports:
>
> SYS Temp: +45.2?C
> CPU Temp: +35.1?C
> SBr Temp: +25.8?C
>
>
> So, I see absolutely no cause for alarm, nor even a need for
> lvcool (esp. not when running seti@home). And I certainly
> haven't seen any Athlon PSE/AGP lockups. So, are you all
> overclockng your systems to an incredible amount (again,
> that's something that seems really stupid to me since the
> $$ difference between 1GHz and 800MHz is not worth the
> potential damage; and the duron is up to 1.3GHz now....)
ok ... here so,e arguments why you could use this power-saving-patch:
1. my cpu is a xp 1600+ ... it is designed for around 56W power
consumption (as far as i know). his temperature is around 47?C under load.
and without the patch this temperatur and power consumptions is by no way
lesser, when he is idle. with the patch the temperature drops by around 10
?C and for the first time i noticed, that i have 2 temperature controlled
fans (cpu and psu fan) in my case. now he isnice quiet when there is no
realy load on it, and he only sounds like a hairdrier when he gets realy
somthing to do (ok ... when you have seti running all the time, the patch
would not make any difference in poer consumption or temperature ... cause
the mashine is under load all the time)
2. power safing is a realy good idea generally !
3. that the amd cpu saves no power before u have activated this
bus-disconnect-function is a bug :) (as far as i know)
oh ... by the way: i have not overclocked my computer ... i only want to
save a little bit of power, when my computer has nothing realy to do (only
surfing, mailing, programming) and i am glad that i now could have some
benefits from temperatur controlled fans (the noise level is much lesser
now)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Tue, 22 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> I know that and my intention was that we _NEED_ documentation to support it
> on _ALL_ chipsets out there.
yes ... i agree ... i send a mail to sis to get the information i need to
implemend this discconnect function for the sis735 but they did not
respond at all to my mail. this is not verry nice ... we want to make
drivers and bug fixes so that their products will work correctly under
linux, and they don't care at all sometimes ...
>
> AMD should notice how many people using there CPUs and I think they do know
> it.
>
> So let's make a call.
yes ... it would be verry nice when amd and the cipset corp. would be a
little bit more supportive.
> I did that, too.
> Andreas Jaeger (SuSE) told me that maybe he could help.
> He got the USB patch information for the AMD Irongate after a few days out of
> them...
ah ... god ... maybe he could send me the imformation to activate the
power saving on the amd cipsets :)
>
> > i decided to wrote a kernelpatch, which supports the kt266/kt266a chipset
> > too.
>
> Good work.
thanks :)
(ok ... the code vfor the kt/k133 chipset allready exists .. .i only
changed it to support the kt266/266a to, which uses other registers for
this)
>
> > (one of my reasosns for this was, that the developer of vcool will not
> > develop the linux version further) .
>
> Sadly to hear.
he told me, that he is not so familiar with linux and at the moment he
have no linux at all at home :( ... but he gave me some hints where to get
the informations i needed ...
> I hope we get some info, now.
i hope it to ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, Jan 23, 2002 at 08:27:29AM +0100, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Timothy Covell wrote:
> > 1. According to AMD specs, the model 3 Duron's don't
> > use more that 40 Watts maximum.
> >
> > 2. With my Duron 800 on a KT133A chipset
> > running folding@home and seti@home
> > continuously, LM sensors reports:
> >
> > SYS Temp: +45.2?C
> > CPU Temp: +35.1?C
> > SBr Temp: +25.8?C
> >
> >
> > So, I see absolutely no cause for alarm, nor even a need for
> > lvcool (esp. not when running seti@home). And I certainly
> > haven't seen any Athlon PSE/AGP lockups. So, are you all
> > overclockng your systems to an incredible amount (again,
> > that's something that seems really stupid to me since the
> > $$ difference between 1GHz and 800MHz is not worth the
> > potential damage; and the duron is up to 1.3GHz now....)
>
> ok ... here so,e arguments why you could use this power-saving-patch:
>
> 1. my cpu is a xp 1600+ ... it is designed for around 56W power
> consumption (as far as i know). his temperature is around 47?C under load.
> and without the patch this temperatur and power consumptions is by no way
> lesser, when he is idle. with the patch the temperature drops by around 10
> ?C and for the first time i noticed, that i have 2 temperature controlled
> fans (cpu and psu fan) in my case. now he isnice quiet when there is no
> realy load on it, and he only sounds like a hairdrier when he gets realy
> somthing to do (ok ... when you have seti running all the time, the patch
> would not make any difference in poer consumption or temperature ... cause
> the mashine is under load all the time)
>
> 2. power safing is a realy good idea generally !
>
> 3. that the amd cpu saves no power before u have activated this
> bus-disconnect-function is a bug :) (as far as i know)
>
> oh ... by the way: i have not overclocked my computer ... i only want to
> save a little bit of power, when my computer has nothing realy to do (only
> surfing, mailing, programming) and i am glad that i now could have some
> benefits from temperatur controlled fans (the noise level is much lesser
> now)
Won't ACPI idle do that well enough?
--
Vojtech Pavlik
SuSE Labs
On Wed, 23 Jan 2002, Vojtech Pavlik wrote:
> Won't ACPI idle do that well enough?
yes ... and no!
first: my patch is useless, if you don't activate acpi idle calls ...
second: the idle calls will not save power on an athlon/duron/athlon xp ,
unless a specific bit in the chipset is set, which will cause the chipset
to disconnect the frontside bus of the cpu ... and this is what the patch
does: it sets only the bit in the northbridge of the kt133/kx133 and
kt266/266a chipset ... -> now the acpi idle calls will bring power saving
and lesser temperature
the patch inserts a pci_quirk function which sets the bit in the
northbridge ... (at the boot-prompt you have to pass the comment
amd_disconnect=yes to use this function ...)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 2002-01-23 at 08:19, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Vojtech Pavlik wrote:
> > Won't ACPI idle do that well enough?
>
> yes ... and no!
> first: my patch is useless, if you don't activate acpi idle calls ...
> second: the idle calls will not save power on an athlon/duron/athlon xp ,
> unless a specific bit in the chipset is set, which will cause the chipset
> to disconnect the frontside bus of the cpu ... and this is what the patch
> does: it sets only the bit in the northbridge of the kt133/kx133 and
> kt266/266a chipset ... -> now the acpi idle calls will bring power saving
> and lesser temperature
> the patch inserts a pci_quirk function which sets the bit in the
> northbridge ... (at the boot-prompt you have to pass the comment
> amd_disconnect=yes to use this function ...)
>
> daniel
What's the official word on the resulting stress on the hardware from
disconnecting and connecting rapidly like that? Has any test ever been
carried out to see if it causes damage after say, a couple months of
use? ...in other operating systems that had this already of course.
always something not so safe sounding about turning the cpu on and off
rapidly added to the greater temperature extremes. Also, can you
relink your patch?
On 23 Jan 2002, Ed Sweetman wrote:
> What's the official word on the resulting stress on the hardware from
> disconnecting and connecting rapidly like that? Has any test ever been
> carried out to see if it causes damage after say, a couple months of
> use? ...in other operating systems that had this already of course.
> always something not so safe sounding about turning the cpu on and off
> rapidly added to the greater temperature extremes. Also, can you
> relink your patch?
i don't know whether there is a official word on the resulting stress. as
far as i heared, there are some stability problems known on some boards
(but i only heared this problems of people with an sis735 based
motherboard like the eltiegroup k7s5a ... but this is not so importend,
cause the sis735 is not supported by my patch ...)
it looks like some "poor" power supplays could not handle well the
changing current draw between the idle and the load states. BUT ... i
realy only heared this problems from one person with an elitegroup k7s5a
board !
cause i know that there maybee computers who have a problem with the
patch, you have to enter "amd_disconnect=yes" at the kernel-boot-prompt
(or in the append statement in /etc/lilo.conf). so it is easy to test the
funktion and to "not use it" when you have problems whith it...
at the university we have several computers running with the lvcool patch
which has a compareable functionality (but only supports kt133/kx133 based
board). they mostly have durons and working like a charm for several
month.
i have nothing heared about problems caused from "temperature-stress".
personally i don't think that this is a problem ....
i put the patch on the web ...
here is the url:
http://cip.uni-trier.de/nofftz/amd_cool.diff
it is a diff from the 2.4.17 kernel and you have to activate acpi, and
acpi-prozessor in the kernel-config to get benefit from the patch.
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 23 Jan 2002, Martin Eriksson wrote:
> Problems (in Windows, with similar patches) have mostly been sound skips and
> general "skippy" behaviour (not the peanut butter). My VIA KT133 based mobo
> with Athlon 1000 had major sound skips, both with onboard VIA sound and
> SB512. Also the graphics in most 3D games stuttered badly.
this is the first time i hear about such problems ...
i have no problems at all and it works great under linux and win 2k
(vcool) ... there are no sound skips or skippy behaviors ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Timothy Covell wrote:
> Hey, don't get me wrong. I'm all for power-saving. That's
> why I own a Via C3 based system. The Via C3 works
> great as an NFS server and draws 12 Watts max (avg.
> is 6 watts). For just email and web browsing, I'd definitely
> recommend it. I'd also recommend it for a small firewall/router
> system. However, for A/V apps and heavy compiling, it's
> definitely not the way to go [BeOS C3 can handle one
> A/V app at a time, but not several].
>
>
> If the patch is really the way to go, then we should get it
> put into the main distribution. But if it is going to hurt
> my performance, then I'd be happy to stick with vanilla
> kapmd (hlt based) power saving.
eenabling the discconect function causes a performance drop of about 2-3 %
as far as i heared ... but this patch is only for athlon processors on an
board with via chipset ... nothing to do with a via c3 cpu :)
what the patch does is that it make the idle calls take effect on this
combination of chipset and cpu ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thursday, 24. January 2002 06:14, Timothy Covell wrote:
> I'm confused by all of the posts and websites that
> I've read. In particular, some of the wattage and
> temperature claims seem outrageous. So, here's
> what I've been able to discover
>
> 1. According to AMD specs, the model 3 Duron's don't
> use more that 40 Watts maximum.
>
> 2. With my Duron 800 on a KT133A chipset
> running folding@home and seti@home
> continuously, LM sensors reports:
>
> SYS Temp: +45.2?C
What should this number mean?
Shouldn't this be the CPU temperature?
> CPU Temp: +35.1?C
Mobo?
> SBr Temp: +25.8?C
Case?
I think this is much to high. Read my other post.
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Tuesday, 22. January 2002 18:15, Daniel Nofftz wrote:
> hi there!
>
[...]
>
> if the patch gets a good feedback, maybe it is something for the official
> kernel tree ?
>
> daniel
Hi Daniel & folks,
just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
Athlon. I normally had 14% base load spend in apmd-idled and a CPU temp.
of 45?C. After getting it to work, I see a base load of around 1% (mostly
spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it it
would be more). Nevertheless, it is a very important patch nowadays where
temperature is the last technical barrier, and energy saving an economic
necessity.
Many thanks and greetings from Berlin to Trier ;)
Hans-Peter
On Wednesday, 23. January 2002 20:24, Daniel Nofftz wrote:
> On Thu, 24 Jan 2002, Timothy Covell wrote:
> > Hey, don't get me wrong. I'm all for power-saving. That's
> > why I own a Via C3 based system. The Via C3 works
> > great as an NFS server and draws 12 Watts max (avg.
> > is 6 watts). For just email and web browsing, I'd definitely
> > recommend it. I'd also recommend it for a small firewall/router
> > system. However, for A/V apps and heavy compiling, it's
> > definitely not the way to go [BeOS C3 can handle one
> > A/V app at a time, but not several].
> >
> >
> > If the patch is really the way to go, then we should get it
> > put into the main distribution. But if it is going to hurt
> > my performance, then I'd be happy to stick with vanilla
> > kapmd (hlt based) power saving.
>
> eenabling the discconect function causes a performance drop of about 2-3 %
> as far as i heared ...
If not smaller. Read the VCool doku.
> but this patch is only for athlon
Athlon and Duron
> processors on an board with via chipset ...
AMD 750/760/maybe MP/MPX, SiS, Ali, Nvidia (?), etc.
> nothing to do with a via c3 cpu :)
> what the patch does is that it make the idle calls take effect on this
> combination of chipset and cpu ...
YES. Without bus disconnet _NO_ real "idle" (cool CPU's).
-Dieter
On Wed, 2002-01-23 at 15:16, Hans-Peter Jansen wrote:
> On Tuesday, 22. January 2002 18:15, Daniel Nofftz wrote:
> > hi there!
> >
> [...]
> >
> > if the patch gets a good feedback, maybe it is something for the official
> > kernel tree ?
> >
> > daniel
>
> Hi Daniel & folks,
>
> just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
> Athlon. I normally had 14% base load spend in apmd-idled and a CPU temp.
> of 45?C. After getting it to work, I see a base load of around 1% (mostly
> spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it it
> would be more). Nevertheless, it is a very important patch nowadays where
> temperature is the last technical barrier, and energy saving an economic
> necessity.
>
> Many thanks and greetings from Berlin to Trier ;)
> Hans-Peter
1-2 degrees is within the sensor's deviation. Either you dont have it
working correctly or it doesn't work at all in your case.
You also need acpi idle calls, not just apm. now this is just my guess
but apm idle calls might either mess things up or be disabled if acpi
idle calls are used and disconnecting the cpu... either way you can't
have this patch work and apm work at the same time.
[Also follow up to my success message befor in this thread]
On Wednesday, 23. January 2002 20:21, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Martin Eriksson wrote:
> > Problems (in Windows, with similar patches) have mostly been sound skips
> > and general "skippy" behaviour (not the peanut butter). My VIA KT133
> > based mobo with Athlon 1000 had major sound skips, both with onboard VIA
> > sound and SB512. Also the graphics in most 3D games stuttered badly.
Oups. Just tried vlc and indeed: skippy sound and picture loss after
switching to fullscreen :( Also uncommon delays on startup noticable.
Will revert it for now (vlc is more important:).
Hans-Peter
> this is the first time i hear about such problems ...
> i have no problems at all and it works great under linux and win 2k
> (vcool) ... there are no sound skips or skippy behaviors ...
>
> daniel
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> Oups. Just tried vlc and indeed: skippy sound and picture loss after
> switching to fullscreen :( Also uncommon delays on startup noticable.
>
> Will revert it for now (vlc is more important:).
what is vlc ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> Hi Daniel & folks,
>
> just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
> Athlon. I normally had 14% base load spend in apmd-idled and a CPU temp.
> of 45?C. After getting it to work, I see a base load of around 1% (mostly
> spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it it
> would be more). Nevertheless, it is a very important patch nowadays where
> temperature is the last technical barrier, and energy saving an economic
> necessity.
hmmm ... 1?-2? lesser than apm or lesser than "without any powersafing
function" ?
do you have entered the amd_disconnect=yes flag at boot-time (LILO ?)
>
> Many thanks and greetings from Berlin to Trier ;)
> Hans-Peter
thanks ... greetings back to you ... :)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 23 Jan 2002, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
>
> > Oups. Just tried vlc and indeed: skippy sound and picture loss after
> > switching to fullscreen :( Also uncommon delays on startup noticable.
> >
> > Will revert it for now (vlc is more important:).
>
> what is vlc ?
video lan client - http://www.videolan.org
> daniel
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli Academic User Services [email protected]
-- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E --
The accumulation of all powers, legislative, executive, and judiciary, in
the same hands, whether of one, a few, or many, and whether hereditary,
selfappointed, or elective, may justly be pronounced the very definition of
tyranny. - James Madison, Federalist Papers 47 - Feb 1, 1788
On Wed, 23 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> > eenabling the discconect function causes a performance drop of about 2-3 %
> > as far as i heared ...
>
> If not smaller. Read the VCool doku.
i know this doku :)
>
> > but this patch is only for athlon
>
> Athlon and Duron
>
ant athlon xp :) ... ok .. .i generalized it ....
> > processors on an board with via chipset ...
>
> AMD 750/760/maybe MP/MPX, SiS, Ali, Nvidia (?), etc.
>
my patch only supports the kt133/kx133 and kt266/kt266a chipset by now ...
maybe it supports the k133a chipset (not tested ... if it has the same
register layout as the kt133 it will work). i have some informations on
the sis735 ... but as far as i know the k7s5a (most common mobo woth
sis735) has some serios problems with the disconnect on STPGNT detect
function ... maybe i will add the sis735 to the patch but it will be a
littlebit risky i think :)
if i get additional informations on the other chipsets, i will add them to
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wednesday, 23. January 2002 21:29, Ed Sweetman wrote:
> On Wed, 2002-01-23 at 15:16, Hans-Peter Jansen wrote:
> > On Tuesday, 22. January 2002 18:15, Daniel Nofftz wrote:
> > > hi there!
> >
> > [...]
> >
> > > if the patch gets a good feedback, maybe it is something for the
> > > official kernel tree ?
> > >
> > > daniel
> >
> > Hi Daniel & folks,
> >
> > just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
> > Athlon. I normally had 14% base load spend in apmd-idled and a CPU temp.
> > of 45?C. After getting it to work, I see a base load of around 1% (mostly
> > spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it it
> > would be more). Nevertheless, it is a very important patch nowadays where
> > temperature is the last technical barrier, and energy saving an economic
> > necessity.
> >
> > Many thanks and greetings from Berlin to Trier ;)
> > Hans-Peter
>
> 1-2 degrees is within the sensor's deviation. Either you dont have it
> working correctly or it doesn't work at all in your case.
It is working somehow, and the 2 degrees are significant in my case, because
the 45?C is pretty stable in unloaded state with apm enabled. Tmax is around
48?C when compiling kde, transcoding divx or the like.
As noted in another message here, I'am going back to apm because it appears
that vlc became sluggish (& back to 45?C CPU base temp. & ~15% base load
from apmd-idled, I bet :)
>
> You also need acpi idle calls, not just apm. now this is just my guess
> but apm idle calls might either mess things up or be disabled if acpi
> idle calls are used and disconnecting the cpu... either way you can't
> have this patch work and apm work at the same time.
I know, and I think Daniel should have noted that one have to disable APM to
get ACPI power savings work. Would have saved me one reboot..
Cheers,
Hans-Peter
On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> It is working somehow, and the 2 degrees are significant in my case, because
> the 45?C is pretty stable in unloaded state with apm enabled. Tmax is around
> 48?C when compiling kde, transcoding divx or the like.
uhh ... this does not sound like any working power saving ... (imho)
> I know, and I think Daniel should have noted that one have to disable APM to
> get ACPI power savings work. Would have saved me one reboot..
sorry ... i didn't know this :) ... i only played around with acpi ... i
haven't tested it with apm and or apm/acp at the same time ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wednesday, 23. January 2002 21:49, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> > Hi Daniel & folks,
> >
> > just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
> > Athlon. I normally had 14% base load spend in apmd-idled and a CPU temp.
> > of 45?C. After getting it to work, I see a base load of around 1% (mostly
> > spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it it
> > would be more). Nevertheless, it is a very important patch nowadays where
> > temperature is the last technical barrier, and energy saving an economic
> > necessity.
>
> hmmm ... 1?-2? lesser than apm or lesser than "without any powersafing
> function" ?
Oups, should have quoted my config:
2.4.18-pre4+
linux-2.4.18-NFS_ALL.dif
pnpbios.patch_latest
apm-idle-2.diff
btaudio-2.4.17.diff.gz
bttv-0.7.88-2.4.17.diff.gz
imon-0.0.2-2.4.12-hp
00_nanosleep-5.dif
ide.2.4.16.12102001.patch.bz2
You see, I'm fiddleing with power saving quite some time.
BTW: Would some enlighted kernel brain explain, why
[ ] RTC stores time in GMT
is only available, when APM is enabled. Does this mean, I cannot
define my RTC mode when using ACPI?
> do you have entered the amd_disconnect=yes flag at boot-time (LILO ?)
Yup, it's called mknbi-linux here :)
I'm going to check ACPI mode without your patch now.
> > Many thanks and greetings from Berlin to Trier ;)
> > Hans-Peter
>
> thanks ... greetings back to you ... :)
>
> daniel
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
Cheers,
Hans-Peter
On Wednesday, 23. January 2002 21:54, Hans-Peter Jansen wrote:
> On Wednesday, 23. January 2002 21:29, Ed Sweetman wrote:
> > On Wed, 2002-01-23 at 15:16, Hans-Peter Jansen wrote:
> > > On Tuesday, 22. January 2002 18:15, Daniel Nofftz wrote:
> > > > hi there!
> > >
> > > [...]
> > >
> > > > if the patch gets a good feedback, maybe it is something for the
> > > > official kernel tree ?
> > > >
> > > > daniel
> > >
> > > Hi Daniel & folks,
> > >
> > > just tried your patch on my (diskless) asus a7v133 (kt133) with 1.2 GHz
> > > Athlon. I normally had 14% base load spend in apmd-idled and a CPU
> > > temp. of 45?C. After getting it to work, I see a base load of around 1%
> > > (mostly spend in artsd), but CPU is only 1?-2? less now :-( I hoped, it
> > > it would be more). Nevertheless, it is a very important patch nowadays
> > > where temperature is the last technical barrier, and energy saving an
> > > economic necessity.
> > >
> > > Many thanks and greetings from Berlin to Trier ;)
> > > Hans-Peter
> >
> > 1-2 degrees is within the sensor's deviation. Either you dont have it
> > working correctly or it doesn't work at all in your case.
>
> It is working somehow, and the 2 degrees are significant in my case,
> because the 45?C is pretty stable in unloaded state with apm enabled. Tmax
> is around 48?C when compiling kde, transcoding divx or the like.
>
> As noted in another message here, I'am going back to apm because it appears
> that vlc became sluggish (& back to 45?C CPU base temp. & ~15% base load
> from apmd-idled, I bet :)
Just testing with ACPI power saving without amd_disconnect. I'm back to
45?C cpuwise, but without 14% background load from apmd. Looks nicer in
gkrellm, but no measurable/noticable difference otherwise. Will stay at
amd unconnected ACPI power savings for now.
Most important: vlc (CVS 0.2.92) is happily working again.
Kernel: linux-2.4.18-pre4+
linux-2.4.18-NFS_ALL.dif (really latest...)
pnpbios.patch_latest
apm-idle-2.diff
btaudio-2.4.17.diff.gz
bttv-0.7.88-2.4.17.diff.gz
imon-0.0.2-2.4.12-hp
00_nanosleep-5.dif
ide.2.4.16.12102001.patch.bz2
Other drivers:
lm_sensors-2.6.2
alsa-driver-0.9.0-beta10
SuSE 7.3 homerolled KDE 2.2.2 NFS diskless setup :-)
> > You also need acpi idle calls, not just apm. now this is just my guess
> > but apm idle calls might either mess things up or be disabled if acpi
> > idle calls are used and disconnecting the cpu... either way you can't
> > have this patch work and apm work at the same time.
>
> I know, and I think Daniel should have noted that one have to disable APM
> to get ACPI power savings work. Would have saved me one reboot..
Cheers,
Hans-Peter
On Thursday, 24. January 2002 23:50, you wrote:
> On Wednesday 23 January 2002 14:18, you wrote:
> > On Thursday, 24. January 2002 06:14, Timothy Covell wrote:
> > > I'm confused by all of the posts and websites that
> > > I've read. In particular, some of the wattage and
> > > temperature claims seem outrageous. So, here's
> > > what I've been able to discover
> > >
> > > 1. According to AMD specs, the model 3 Duron's don't
> > > use more that 40 Watts maximum.
> > >
> > > 2. With my Duron 800 on a KT133A chipset
> > > running folding@home and seti@home
> > > continuously, LM sensors reports:
> > >
> > > SYS Temp: +45.2?C
> >
> > What should this number mean?
> > Shouldn't this be the CPU temperature?
>
> This corresponds to what my BIOS says is the CPU temp.
>
> > > CPU Temp: +35.1?C
> >
> > Mobo?
>
> This corresponds to what my BIOS says is the system temp.
>
> > > SBr Temp: +25.8?C
> >
> > Case?
>
> That's my guess as well.
OK, I see.
The BIOS numbers are all mostly wrong. When you are in the BIOS config (the
Del or ESC key thing)...;-) The CPU is running without any IDLE cycles at
all.
> > I think this is much to high. Read my other post.
>
> Too high for a duron 800 running seti@home type loads nonstop?
Yes, sorry. I overlooked that.
> I think that this is the expected temperature.
What I expect is:
+45?C CPU
The sensor under the CPU 'cause only the Morgan and Athlon XP/MP have the new
integrated sensor but only "latest" mobos support it. Not your KT133A based
one.
+35?C mobo (but I haven't anyone with sensor seen so far)
Could be the CPU -10?C what's sometimes the case with some mobo manufactures.
+25?C System (the case temperature)
With your system load.
An idle system should look like this:
CPU 23-25?C (with IDLE and BUS GRANT)
system (case) 20-23?C (room temperature)
At any time (full load) the case temperature shouldn't go over 40?C with all
stuff running (gfx, disks, lan, etc.). Recommendations from AMD and Intel.
> I've come to the conclusion that the lm_sensors stuff is crap,
No, they have the frame work in place but need the usefull bits.
That's we are hunting for...
> but not totally because of the authors. It looks like the manufacturers
> like VIA are not very helpful to the project.....
Very true!
Regards,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Friday, 25. January 2002 00:33, Timothy Covell wrote:
> I tried lvcool on my KT133A/Duron system. When I ran the
> "sensors" program, it failed to exit and ate up 100% of the
> CPU. Kill -9 refused to kill it. I had to reboot to clear the
> problem which doesn't show up if I haven't run lvcool....
Maybe you can run Windows with VCool for a test? --- Yes, yes, I know...;-)
Have you tried the older VCool Linux patch?
I can't do that 'cause I have the AMD 750 (without doku from AMD) as you
know, already.
-Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Wednesday, 23. January 2002 21:16, Hans-Peter Jansen wrote:
[-]
> BTW: Would some enlighted kernel brain explain, why
> [ ] RTC stores time in GMT
> is only available, when APM is enabled. Does this mean, I cannot
> define my RTC mode when using ACPI?
Hans-Peter,
as you have ACPI running already, you should have noticed that "your" clock
(RTC) is in GMT time without a separate switch.
Mine is (compare with send time):
/home/nuetzel> cat /proc/driver/rtc
rtc_time : 02:33:14
rtc_date : 2002-01-24
rtc_epoch : 1900
alarm : 00:00:00
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 1024
batt_status : okay
Regards,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On 23 Jan 2002, Ed Sweetman wrote:
> 1-2 degrees is within the sensor's deviation. Either you dont have it
> working correctly or it doesn't work at all in your case.
>
> You also need acpi idle calls, not just apm. now this is just my guess
> but apm idle calls might either mess things up or be disabled if acpi
> idle calls are used and disconnecting the cpu... either way you can't
> have this patch work and apm work at the same time.
or the vlc makes enough load on the mashine that there is no realy power
saving ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> You see, I'm fiddleing with power saving quite some time.
oh ,.. by the way : does dmesg show somthing like "dissconect in via
northbridge enabled: kt133 chipset found " or something similar ?
(only if you have my patch ativated)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> Just testing with ACPI power saving without amd_disconnect. I'm back to
> 45?C cpuwise, but without 14% background load from apmd. Looks nicer in
> gkrellm, but no measurable/noticable difference otherwise. Will stay at
> amd unconnected ACPI power savings for now.
as far as i know the normal acpi and apm idle calls will only save
marginaly power without the disconnect function. but if the function does
make problems your on the better way without it ... sadly there is no way
to "tweak" things right for boards wich hafe this problems , cause you
have only a switch (register in the northbridge) which you could trigger
... and if it does not worl allright with it, so only way is to not use
the function ... this is one of the reasons, way there is an flag you have
to set on the boot-prompt ... it is more easy to test and to deactivate if
it doesn't work
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> CPU 23-25?C (with IDLE and BUS GRANT)
> system (case) 20-23?C (room temperature)
hmmm ... my system is at 33 case and 34-35 cpu temperature (?C) when it is
idle ... this are not so bad temperatures ... it has temperature
controlled fans which only reach their maximum spin at around 40-45 ... so
the system is not so good coold when it is cooler but produce lesser noise
...
> At any time (full load) the case temperature shouldn't go over 40?C with all
> stuff running (gfx, disks, lan, etc.). Recommendations from AMD and Intel.
yes ... the case temp should not go over 40?C but the cpu is fine if it
is under 45-50?C under load.
> > I've come to the conclusion that the lm_sensors stuff is crap,
>
> No, they have the frame work in place but need the usefull bits.
> That's we are hunting for...
the lm_sensors package is realy fine ... it was a realy usfull tool when i
was tweaking on this patch ...
> > but not totally because of the authors. It looks like the manufacturers
> > like VIA are not very helpful to the project.....
>
> Very true!
i get my informations from pcr files for wpcredit ... a editor to
manipulate the chipset and bios settign from within windows. this pcr
files contains the adresses for some usefull registers and such things ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thursday, 24. January 2002 10:47, Daniel Nofftz wrote:
> On 23 Jan 2002, Ed Sweetman wrote:
> > 1-2 degrees is within the sensor's deviation. Either you dont have it
> > working correctly or it doesn't work at all in your case.
> >
> > You also need acpi idle calls, not just apm. now this is just my guess
> > but apm idle calls might either mess things up or be disabled if acpi
> > idle calls are used and disconnecting the cpu... either way you can't
> > have this patch work and apm work at the same time.
>
> or the vlc makes enough load on the mashine that there is no realy power
> saving ...
No, vlc creates between 15% and 25% load, when using XVideo output without
scaling: (source are plain unencrypted vob files on the server).
1 0 1 0 51688 16 620376 0 0 0 0 1232 1068 25 1 74
2 0 0 0 50792 16 621272 0 0 0 0 1091 985 22 2 76
0 0 0 0 49772 16 622296 0 0 0 0 1246 1124 21 2 77
0 0 0 0 48620 16 623448 0 0 0 0 1346 1129 24 2 74
3 0 0 0 47720 16 624344 0 0 0 0 1086 960 14 5 81
1 0 0 0 46696 16 625368 0 0 0 0 1227 1096 23 3 74
0 0 0 0 45932 16 626136 0 0 0 0 970 913 19 1 80
0 0 0 0 44908 16 627160 0 0 0 0 1242 1061 21 1 78
2 0 0 0 43756 16 628312 0 0 0 0 1339 1052 18 5 77
1 0 0 0 42852 16 629208 0 0 0 0 1108 1006 18 0 82
0 0 0 0 41828 16 630232 0 0 0 0 1229 1112 17 0 83
3 0 0 0 40676 16 631384 0 0 0 0 1358 1111 18 4 78
0 0 0 0 39524 16 632536 0 0 0 0 1359 1114 17 3 80
0 0 0 0 38628 16 633432 0 0 0 0 1170 1070 14 1 85
4 0 0 0 37600 16 634456 0 0 0 0 1217 1005 18 1 81
0 0 0 0 36836 16 635224 0 0 0 0 1003 997 18 1 81
1 0 0 0 35812 16 636248 0 0 0 0 1241 1035 17 3 80
1 0 1 0 34788 16 637272 0 0 0 0 1232 1020 15 2 83
2 0 1 0 33888 16 638168 0 0 0 0 1092 963 16 2 82
3 0 0 0 32872 16 639192 0 0 0 0 1239 1097 20 2 78
0 0 0 0 31840 16 640216 0 0 0 0 1249 1136 13 4 83
4 0 0 0 30688 16 641368 0 0 0 0 1329 1043 17 4 79
0 0 0 0 29664 16 642392 0 0 0 0 2273 2045 18 9 73
0 0 0 0 28640 16 643416 0 0 0 0 1218 1045 16 2 82
2 0 0 0 27904 16 644184 0 0 0 0 1085 1400 22 1 77
1 0 0 0 27256 16 644824 0 0 0 0 1106 1386 24 3 73
0 0 0 0 26360 16 645720 0 0 0 0 1320 1391 24 2 74
Fullscreen mode (scaling) takes approx. 5% more.
1 0 0 0 4440 16 668124 0 0 0 0 1494 2580 26 2 72
1 0 0 0 4372 16 668252 0 0 0 0 1307 1465 27 2 71
1 0 0 0 4364 16 668252 0 0 0 0 1284 2991 38 1 61
0 0 0 0 4404 16 668252 0 0 0 0 1114 1482 30 2 68
2 0 0 0 4416 16 668252 0 0 0 0 1111 1031 24 1 75
1 0 0 0 4432 16 668252 0 0 0 0 1210 1076 21 2 77
0 0 0 0 4444 16 668252 0 0 0 0 1260 1195 20 3 77
2 0 0 0 4448 16 668252 0 0 0 0 1240 1101 27 1 72
0 0 0 0 4456 16 668252 0 0 0 0 1367 1171 26 1 73
0 0 0 0 4448 16 668252 0 0 0 0 1388 1182 24 2 74
3 0 0 0 4448 16 668252 0 0 0 0 1236 1065 24 2 75
0 0 0 0 4444 16 668252 0 0 0 0 1372 1199 26 1 73
0 0 0 0 4444 16 668252 0 0 0 0 1373 1194 27 0 73
3 0 0 0 4444 16 668252 0 0 0 0 1364 1101 24 2 75
0 0 0 0 4444 16 668252 0 0 0 0 1246 1103 26 2 72
0 0 0 0 4448 16 668252 0 0 0 0 1348 1077 24 2 74
2 0 0 0 4448 16 668252 0 0 0 0 1374 1239 25 3 73
0 0 0 0 4400 16 668252 0 0 0 0 1881 1697 25 4 71
0 0 0 0 4412 16 668252 0 0 0 0 1113 1004 26 0 74
2 0 0 0 4444 16 667996 0 0 0 0 1388 2767 38 3 59
1 0 0 0 4392 16 668124 0 0 0 0 1425 1418 27 3 70
0 0 0 0 4476 16 668252 0 0 0 0 1603 1725 25 4 71
1 0 0 0 4376 16 668380 0 0 0 0 1491 1427 27 3 70
You can see, enough idleness...
The question is, why amd_disconnect=true causes this distortion. I tend to
believe that dis-/reconnecting CPU takes simply too long in this scenario.
> daniel
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
Cheers,
Hans-Peter
On Thu, 24 Jan 2002, Daniel Nofftz wrote:
> On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
>
> > You see, I'm fiddleing with power saving quite some time.
>
> oh ,.. by the way : does dmesg show somthing like "dissconect in via
> northbridge enabled: kt133 chipset found " or something similar ?
> (only if you have my patch ativated)
I tried your patch. I get the message above (I have a KT133A). With only
APM enabled, it makes no difference; witch ACPI, temp goes from 47C ->
38C without stability problems nor preformance drops.
However, after disabling APM and enabling ACPI, my system won't power
off anymore :-(
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
God put me on earth to accomplish a certain number of things.
Right now I am so far behind I will never die.
-Bill Waterson, Calvin and Hobbes
----------------------------------[ moffe at amagerkollegiet dot dk ] --
On Thursday, 24. January 2002 03:33, Dieter N?tzel wrote:
> On Wednesday, 23. January 2002 21:16, Hans-Peter Jansen wrote:
> [-]
>
> > BTW: Would some enlighted kernel brain explain, why
> > [ ] RTC stores time in GMT
> > is only available, when APM is enabled. Does this mean, I cannot
> > define my RTC mode when using ACPI?
>
> Hans-Peter,
> as you have ACPI running already, you should have noticed that "your" clock
> (RTC) is in GMT time without a separate switch.
>
> Mine is (compare with send time):
>
> /home/nuetzel> cat /proc/driver/rtc
> rtc_time : 02:33:14
> rtc_date : 2002-01-24
> rtc_epoch : 1900
> alarm : 00:00:00
> DST_enable : no
> BCD : yes
> 24hr : yes
> square_wave : no
> alarm_IRQ : no
> update_IRQ : no
> periodic_IRQ : no
> periodic_freq : 1024
> batt_status : okay
Hi Dieter,
it took you 22 sec. to finish and send your mail. Pretty quick :)
My RTC seems totally bogus:
elfe:~# date; clock; cat /proc/driver/rtc
Thu Jan 24 13:42:03 CET 2002
Thu Jan 24 19:12:04 2002 -0.144010 seconds
rtc_time : 18:12:04
rtc_date : 2002-01-24
rtc_epoch : 1900
alarm : 09:30:15
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 1024
batt_status : okay
I thought, ntpd would take care of the RTC:
Jan 23 23:38:02 elfe xntpd[356]: ntpd 4.1.0 Fri Sep 21 14:42:26 GMT 2001 (1)
Jan 23 23:38:02 elfe xntpd[356]: signal_no_reset: signal 13 had flags 4000000
Jan 23 23:38:02 elfe xntpd[356]: precision = 9 usec
Jan 23 23:38:02 elfe xntpd[356]: kernel time discipline status 0040
Jan 23 23:38:02 elfe xntpd[356]: frequency initialized 58.785 from
/etc/ntp.drift
Obviously it doesn't.
I will take a look in the SuSE /etc/init.d scripts for this...
> Regards,
> Dieter
Cheers,
Hans-Peter
Hi!
> > Hey, don't get me wrong. I'm all for power-saving. That's
> > why I own a Via C3 based system. The Via C3 works
> > great as an NFS server and draws 12 Watts max (avg.
> > is 6 watts). For just email and web browsing, I'd definitely
> > recommend it. I'd also recommend it for a small firewall/router
> > system. However, for A/V apps and heavy compiling, it's
> > definitely not the way to go [BeOS C3 can handle one
> > A/V app at a time, but not several].
> >
> >
> > If the patch is really the way to go, then we should get it
> > put into the main distribution. But if it is going to hurt
> > my performance, then I'd be happy to stick with vanilla
> > kapmd (hlt based) power saving.
>
> eenabling the discconect function causes a performance drop of about 2-3 %
> as far as i heared ... but this patch is only for athlon processors
> on an
You could look for how long CPU was idle, and only if it was mostly
idle in last 10 seconds enable the bit ;-).
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
[snip]
>
> 2. power safing is a realy good idea generally !
[snip]
Hey, don't get me wrong. I'm all for power-saving. That's
why I own a Via C3 based system. The Via C3 works
great as an NFS server and draws 12 Watts max (avg.
is 6 watts). For just email and web browsing, I'd definitely
recommend it. I'd also recommend it for a small firewall/router
system. However, for A/V apps and heavy compiling, it's
definitely not the way to go [BeOS C3 can handle one
A/V app at a time, but not several].
If the patch is really the way to go, then we should get it
put into the main distribution. But if it is going to hurt
my performance, then I'd be happy to stick with vanilla
kapmd (hlt based) power saving.
--
[email protected].
I tried lvcool on my KT133A/Duron system. When I ran the
"sensors" program, it failed to exit and ate up 100% of the
CPU. Kill -9 refused to kill it. I had to reboot to clear the
problem which doesn't show up if I haven't run lvcool....
--
[email protected].
On Wednesday 23 January 2002 17:48, Dieter N?tzel wrote:
> On Friday, 25. January 2002 00:33, Timothy Covell wrote:
> > I tried lvcool on my KT133A/Duron system. When I ran the
> > "sensors" program, it failed to exit and ate up 100% of the
> > CPU. Kill -9 refused to kill it. I had to reboot to clear the
> > problem which doesn't show up if I haven't run lvcool....
>
> Maybe you can run Windows with VCool for a test? --- Yes, yes, I know...;-)
>
> Have you tried the older VCool Linux patch?
>
> I can't do that 'cause I have the AMD 750 (without doku from AMD) as you
> know, already.
>
> -Dieter
Sorry, I only own an old copy of NT 4.0 and last time I tried to install
it, it was so old that it bluescreened due to hardware problems. That and
it's against my morals to run M$ crap.
--
[email protected].
> I thought, ntpd would take care of the RTC:
It doesn't. init scripts on boot sync the date to the rtc, if your date
isn't near what it should be then ntp wont work. It has to at least be
close then run date --systohc or something like that.
----- Original Message -----
From: "Daniel Nofftz" <[email protected]>
To: "Martin Eriksson" <[email protected]>
Cc: "Ed Sweetman" <[email protected]>; "Vojtech Pavlik"
<[email protected]>; "Timothy Covell" <[email protected]>; "Dieter
N?tzel" <[email protected]>; "Dave Jones" <[email protected]>; "Andreas
Jaeger" <[email protected]>; "Martin Peters" <[email protected]>; "Linux Kernel List"
<[email protected]>
Sent: Wednesday, January 23, 2002 8:21 PM
Subject: Re: [patch] amd athlon cooling on kt266/266a chipset
> On Wed, 23 Jan 2002, Martin Eriksson wrote:
>
> > Problems (in Windows, with similar patches) have mostly been sound skips
and
> > general "skippy" behaviour (not the peanut butter). My VIA KT133 based
mobo
> > with Athlon 1000 had major sound skips, both with onboard VIA sound and
> > SB512. Also the graphics in most 3D games stuttered badly.
>
> this is the first time i hear about such problems ...
> i have no problems at all and it works great under linux and win 2k
> (vcool) ... there are no sound skips or skippy behaviors ...
>
Well I guess it's very mobo-dependent then. What I remember from the VCool
program is that it made windows go crazy on me. I dont know exactly what
happened, just that I removed vcool very quickly.
I just tried the function again, not using vcool, instead *only* enabling
bit 8 of register 0x52 ("Disconnect Enable When STPGNT Detected") with the
following results:
* No other (major) load than Winamp: Minor sound skips
* Winamp when reading from hard disk: Major sound skips
* Winamp when using distributed.net client: Almost no sound skips (one or
two on a 4 minute tune)
* Winamp when using distributed.net & using hard disk: Almost no sound skips
As both the HD controller and soundcard does much DMA, I guess it has some
connection to DMA transfers on the PCI bus?
OS: Windows 2000 Pro
Northbridge: VIA KT133
Southbridge: VIA 686B
CPU: Athlon(B) 1GHz
(Sorry, Linux is running on my BP6)
_____________________________________________________
| Martin Eriksson <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
On Thursday, 24. January 2002 12:40, Rasmus Hansen wrote:
Hello Rasmus,
I hope that I've extracted your name right?
>On Thu, 24 Jan 2002, Daniel Nofftz wrote:
>
> > On Wed, 23 Jan 2002, Hans-Peter Jansen wrote:
> >
> > > You see, I'm fiddleing with power saving quite some time.
> >
> > oh ,.. by the way : does dmesg show somthing like "dissconect in via
> > northbridge enabled: kt133 chipset found " or something similar ?
> > (only if you have my patch ativated)
>
> I tried your patch. I get the message above (I have a KT133A). With only
> APM enabled, it makes no difference; witch ACPI, temp goes from 47C ->
> 38C without stability problems nor preformance drops.
This are very good numbers, which I've expected.
> However, after disabling APM and enabling ACPI, my system won't power
> off anymore :-(
This should be easily solved.
I point on your distro's startup scripts. They only look if apm is enabled
but _NOT ACPI...
Have a look into /etc/init.d/halt (taken from SuSE 7.3, LSB standard).
[-]
case "$0" in
*halt)
message="The system will be halted immediately."
case `/bin/uname -m` in
i?86)
command="halt"
if test -e /proc/apm -o -e /proc/acpi ; then <----!!!!
command="halt -p"
else
read cmdline < /proc/cmdline
case "$cmdline" in
*apm=smp-power-off*|*apm=power-off*)
command="halt -p" ;;
esac
fi
;;
*)
command="halt -p"
[-]
Expand the marked line with acpi like above.
Regards,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
Hello Dieter
> Hello Rasmus,
>
> I hope that I've extracted your name right?
Yup, just a danish letter in my middle-name :-)
> > However, after disabling APM and enabling ACPI, my system won't power
> > off anymore :-(
>
> This should be easily solved.
>
> I point on your distro's startup scripts. They only look if apm is enabled
> but _NOT ACPI...
Well, RedHat 7.2 does not look if apm or acpi is configured, it just
uses -p unless the command run was 'halt' or 'reboot'.
When running '/sbin/poweroff' from single-user, 'halt -i -d p' is the
last command run by the halt script. The I get the message 'Power down.'
from the kernel and my system just hangs here.
When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
again the last command run, follwing this from the kernel:
Power down.
hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
And again my system hangs. Pressing the power button for 4 seconds turns
off the computer (the BIOS is set to 'immediate power off').
Ctrl-Alt-Delete or any other keyboard combinations do not work.
Reboot works fine. APM poweroff also works flawlessly (but then I do not
get the powersaving functions).
In runlevel 3, the following modules are loaded (some are patched in
from the iptables package. They should not cause this, as I can
reproduce this without iptables configured/patched at all):
Module Size Used by Tainted: P
binfmt_misc 5636 1
parport_pc 21416 1 (autoclean)
lp 6016 0 (autoclean)
parport 23680 1 (autoclean) [parport_pc lp]
autofs4 8228 2 (autoclean)
smbfs 31104 1 (autoclean)
eepro100 17136 1
af_packet 11912 0 (autoclean)
ipt_REJECT 2784 1 (autoclean)
ipt_record_rpc 1504 4 (autoclean)
ip_conntrack_rpc_tcp 2880 1 (autoclean) [ipt_record_rpc]
ip_conntrack_rpc_udp 2720 1 (autoclean) [ipt_record_rpc]
ipt_unclean 6816 4 (autoclean)
ipt_state 576 21 (autoclean)
ipt_LOG 3360 13 (autoclean)
ipt_limit 928 12 (autoclean)
iptable_mangle 1696 0 (autoclean) (unused)
iptable_nat 13844 1 (autoclean)
iptable_filter 1664 1 (autoclean)
ip_tables 10688 11 [ipt_REJECT ipt_record_rpc ipt_unclean
ipt_state ipt_LOG ipt_limit iptable_mangle iptable_nat iptable_filter]
ip_conntrack_h323 2208 0 (unused)
ip_conntrack_irc 2624 0 (unused)
ip_conntrack_ftp 3424 0 (unused)
ip_conntrack 14444 8 [ipt_record_rpc ip_conntrack_rpc_tcp
ip_conntrack_rpc_udp ipt_state iptable_nat ip_conntrack_h323
ip_conntrack_irc ip_conntrack_ftp]
ntfs 47936 1 (autoclean)
nls_iso8859-15 3328 2 (autoclean)
nls_cp865 4320 2 (autoclean)
vfat 9564 1 (autoclean)
fat 29944 0 (autoclean) [vfat]
rtc 5656 0 (autoclean)
>From my 'make menuconfig:
[*] Power Management support
[*] ACPI support
[*] ACPI Debug Statements
<*> ACPI Bus Manager
<*> System
<*> Processor
< > Button
< > AC Adapter
< > Embedded Controller
< > Advanced Power Management BIOS support
At bootup I get the following regarding ACPI:
tbxface-0099 [01] Acpi_load_tables : ACPI Tables successfully
loaded
Parsing
Methods:...................................................................................................................
115 Control Methods found and parsed (364 nodes total)
ACPI Namespace successfully loaded at root c0286ee0
ACPI: Core Subsystem version [20011018]
evxfevnt-0081 [02] Acpi_enable : Transition to ACPI mode
successful
Executing device _INI methods:.......................................
39 Devices found: 39 _STA, 0 _INI
Completing Region and Field initialization:...................
17/24 Regions, 2/2 Fields initialized (364 nodes total)
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S4 S5
Processor[0]: C0 C1 C2, 8 throttling states
My motherboard is an Asus A7V133-C. Output from lspci -v:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: bus master, medium devsel, latency 8
Memory at e0000000 (32-bit, prefetchable) [size=128M]
Capabilities: <available only to root>
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: d6000000-d7cfffff
Prefetchable memory behind bridge: d7f00000-dfffffff
Capabilities: <available only to root>
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: <available only to root>
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at d800 [size=16]
Capabilities: <available only to root>
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 9
I/O ports at d000 [size=32]
Capabilities: <available only to root>
00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: medium devsel, IRQ 9
Capabilities: <available only to root>
00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
Subsystem: Unknown device 4942:4c4c
Flags: bus master, slow devsel, latency 32, IRQ 5
I/O ports at a400 [size=64]
00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at d5800000 (32-bit, non-prefetchable) [size=4K]
I/O ports at a000 [size=64]
Memory at d5000000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: <available only to root>
00:0c.0 SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 03)
Subsystem: Advanced System Products, Inc ASC1300 SCSI Adapter
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at 9800 [size=256]
Memory at d4800000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]
01:00.0 VGA compatible controller: nVidia Corporation NV11 (GeForce2 MX DDR) (rev b2) (prog-if 00 [VGA])
Subsystem: Micro-star International Co Ltd: Unknown device 8261
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 11
Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at d7ff0000 [disabled] [size=64K]
Capabilities: <available only to root>
I have tried different ACPI configurations, but I haven't been able to
make any of them work.
I have very little knowledge of ACPI, but I'll be happy to help (if this
is not my fault of course - then I will apologize for taking your time
:-)).
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
God, root, what is difference?
God is more forgiving.
----------------------------------[ moffe at amagerkollegiet dot dk ] --
In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
> When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> again the last command run, follwing this from the kernel:
> Power down.
> hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
> And again my system hangs.
I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
kernel ACPI does not. However, the Intel ACPI patch, available from
http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
kernel 2.4.16, does power down my machine. I was able to forward port
this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
applying the Intel ACPI patch first, and then applying kernel
patch-2.4.17 and kernel patch-2.4.18-pre7.
As to the merits of the amd_disconnect patch that started this thread,
under 2.4.18-pre7-acpi, I get an idle CPU temperature of about 48 C.
With the amd_disconnect patch, it drops to 32-35 C, wow! As
previously discussed, APM + amd_disconnect on an Athlon does not
provide any power savings, one needs ACPI + amd_disconnect.
Note that on this motherboard (and perhaps all ASUS Via chipset
motherboards, including the A7V133), one needs the following line in
/etc/sensors.conf to get reasonable lm_sensors CPU temperatures:
compute temp2 @*2, @/2
This is as described at http://www2.lm-sensors.nu/~lm78/support.html
in Ticket 775.
Best wishes,
Wayne
On Thursday, 24. January 2002 18:24, Mark Hahn wrote:
> > > > 1-2 degrees is within the sensor's deviation. Either you dont have
> > > > it working correctly or it doesn't work at all in your case.
> > > >
> > > > You also need acpi idle calls, not just apm. now this is just my
> > > > guess but apm idle calls might either mess things up or be disabled
> > > > if acpi idle calls are used and disconnecting the cpu... either way
> > > > you can't have this patch work and apm work at the same time.
> > >
> > > or the vlc makes enough load on the mashine that there is no realy
> > > power saving ...
> >
> > No, vlc creates between 15% and 25% load, when using XVideo output
> > without
>
> the issue is whether there is a long-enough period of idleness.
> what's your framerate? that's what matters, not the (known-inaccurate)
> %CPU accounting.
Ordinary pal encoded mpeg2 files plays with 25 frames per sec.
As I wrote, vlc plays smooth and fine _without_ amd_disconnect with the
documented load. With disconnect, vlc suffers from sound drop outs but I
haven't digged further in this vlc issue, as it was clearly related to the
cpu disconnect feature. Also, there were noticable delays in actions
like starting a Xterm via shortcut of approx. 0.5 sec, which I don't
see without disconnect.
Because of the mutual exclusive nature of this feature, I filed it
under unfinished hardware feature.
On behalf of power saving, I will look into swsusp/ACPI suspend again soon.
Cheers,
Hans-Peter
On Thu, Jan 24, 2002 at 09:49:37AM -0800, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
>
> > When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> > again the last command run, follwing this from the kernel:
> > Power down.
> > hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
> > And again my system hangs.
>
> I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
> that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
> kernel ACPI does not. However, the Intel ACPI patch, available from
> http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
> kernel 2.4.16, does power down my machine. I was able to forward port
> this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
> applying the Intel ACPI patch first, and then applying kernel
> patch-2.4.17 and kernel patch-2.4.18-pre7.
I still have this in my tree. I have no idea who is wrong, whether parser
or BIOS.
Best regards,
Petr Vandrovec
[email protected]
diff -urdN linux/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
--- linux/drivers/acpi/hardware/hwsleep.c Wed Oct 24 21:06:22 2001
+++ linux/drivers/acpi/hardware/hwsleep.c Tue Jan 22 16:17:46 2002
@@ -152,6 +152,13 @@
return status;
}
+ /* Broken ACPI table on ASUS A7V... it reports type 7, but poweroff is type 2...
+ sleep is type 1 while ACPI reports type 3, but as I was not able to get
+ machine to wake from this state without unplugging power cord... */
+ if (type_a == 7 && type_b == 7 && sleep_state == ACPI_STATE_S5 && !memcmp(acpi_gbl_DSDT->oem_id, "ASUS\0\0", 6)
+ && !memcmp(acpi_gbl_DSDT->oem_table_id, "A7V ", 8)) {
+ type_a = type_b = 2;
+ }
/* run the _PTS and _GTS methods */
MEMSET(&arg_list, 0, sizeof(arg_list));
> Note that on this motherboard (and perhaps all ASUS Via chipset
> motherboards, including the A7V133), one needs the following line in
> /etc/sensors.conf to get reasonable lm_sensors CPU temperatures:
> compute temp2 @*2, @/2
> This is as described at http://www2.lm-sensors.nu/~lm78/support.html
> in Ticket 775.
>
I have ASUS A7V266-E (AS99127F chip) and lm_sensors 2.6.2
shows 43 C for CPU without any additional lines in /etc/sensors.conf
Which sounds reasonable. However this temperature is rarely ever change !
I typically have 43.1, sometimes 42.8 and that's it. Even after 2-3 min
compiles. So something is wrong
Dmitri
On Thu, 24 Jan 2002, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
>
> > When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> > again the last command run, follwing this from the kernel:
> > Power down.
> > hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
> > And again my system hangs.
>
> I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
> that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
> kernel ACPI does not. However, the Intel ACPI patch, available from
> http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
> kernel 2.4.16, does power down my machine. I was able to forward port
> this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
> applying the Intel ACPI patch first, and then applying kernel
> patch-2.4.17 and kernel patch-2.4.18-pre7.
Thanks for the tip; now it works. And besides I installed acpid - pretty
cool to get a clean shutdown when the power-button is pressed :-)
> As to the merits of the amd_disconnect patch that started this thread,
> under 2.4.18-pre7-acpi, I get an idle CPU temperature of about 48 C.
> With the amd_disconnect patch, it drops to 32-35 C, wow! As
> previously discussed, APM + amd_disconnect on an Athlon does not
> provide any power savings, one needs ACPI + amd_disconnect.
>
> Note that on this motherboard (and perhaps all ASUS Via chipset
> motherboards, including the A7V133), one needs the following line in
> /etc/sensors.conf to get reasonable lm_sensors CPU temperatures:
> compute temp2 @*2, @/2
> This is as described at http://www2.lm-sensors.nu/~lm78/support.html
> in Ticket 775.
Eek, so my BIOS was right after all :-) The system is 63C at high load
and 45C with the disconnection patch and ACPI enabled. With normal APM
and no disconnection it is around 60C.
Thanks anyway.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
Drink wet cement: Get Stoned.
----------------------------------[ moffe at amagerkollegiet dot dk ] --
On Thu, 24 Jan 2002, Hans-Peter Jansen wrote:
> You can see, enough idleness...
>
> The question is, why amd_disconnect=true causes this distortion. I tend to
> believe that dis-/reconnecting CPU takes simply too long in this scenario.
hmmm ... yes ... this would be my idea too ... maybee the dis-reconnect
procedure is to slow on "slow" computers to grant undisrupted audio or
video streams ...
i have no problem with this ... maybee caus i have a "faster" cpu ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Rasmus B?g Hansen wrote:
> I tried your patch. I get the message above (I have a KT133A). With only
> APM enabled, it makes no difference; witch ACPI, temp goes from 47C ->
> 38C without stability problems nor preformance drops.
>
ahhh ... good to hear a "working"-feedback from someone with an kt133a
chipset :)
> However, after disabling APM and enabling ACPI, my system won't power
> off anymore :-(
hmmm ... i noticed this to on my computer ... i have not searched until
now, why this happens ... (to much to do) ... maybe i look later whether i
can find something, or anyone else has a hint ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Martin Eriksson wrote:
> Well I guess it's very mobo-dependent then. What I remember from the VCool
> program is that it made windows go crazy on me. I dont know exactly what
> happened, just that I removed vcool very quickly.
>
> I just tried the function again, not using vcool, instead *only* enabling
> bit 8 of register 0x52 ("Disconnect Enable When STPGNT Detected") with the
> following results:
>
> * No other (major) load than Winamp: Minor sound skips
> * Winamp when reading from hard disk: Major sound skips
> * Winamp when using distributed.net client: Almost no sound skips (one or
> two on a 4 minute tune)
> * Winamp when using distributed.net & using hard disk: Almost no sound skips
>
> As both the HD controller and soundcard does much DMA, I guess it has some
> connection to DMA transfers on the PCI bus?
>
> OS: Windows 2000 Pro
> Northbridge: VIA KT133
> Southbridge: VIA 686B
> CPU: Athlon(B) 1GHz
i agree that this could be connected with dma transfers ... maybe the
disconnect procedure disturbs dma transfers on slower cpus, where the
disconnect/reconnect procedure takes to long ?
maybe it is realy a metter of the motherboard ? who realy knows ? maybe a
amd/via guru could answer this question ... at the moment i can't answer
it ... and my system isn't affected by this sound skips ... so i even
can'T make testes on it ...
maybe someon with this skips could make some tests ?
disabling/enabling dma , change some timings for pci bus in bios or such
things ?
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Daniel Nofftz wrote:
> On Thu, 24 Jan 2002, Rasmus B?g Hansen wrote:
>
> > I tried your patch. I get the message above (I have a KT133A). With only
> > APM enabled, it makes no difference; witch ACPI, temp goes from 47C ->
> > 38C without stability problems nor preformance drops.
> >
>
> ahhh ... good to hear a "working"-feedback from someone with an kt133a
> chipset :)
>
> > However, after disabling APM and enabling ACPI, my system won't power
> > off anymore :-(
>
> hmmm ... i noticed this to on my computer ... i have not searched until
> now, why this happens ... (to much to do) ... maybe i look later whether i
> can find something, or anyone else has a hint ...
Somewhere a long way down the "ACPI troubles (Was:[...]" thread someone
told me, that the Asus A7V family is broken and implement the power-off
funtion in a wrong manner. You have to update ACPI to make it work (but
now it works like a charm). You should be able to find the links in the
other thread.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
I would never kill somebody
- unless they pissed me off!
-- Eric Cartman
----------------------------------[ moffe at amagerkollegiet dot dk ] --
On Thu, 2002-01-24 at 15:54, Daniel Nofftz wrote:
> hmmm ... yes ... this would be my idea too ... maybee the dis-reconnect
> procedure is to slow on "slow" computers to grant undisrupted audio or
> video streams ...
>
> i have no problem with this ... maybee caus i have a "faster" cpu ?
1.3G here.. how much faster does it need to be? (didn't test audio/video
streams due to the unusability of my keyboard.. I can reboot and try it
if it would be useful.)
calibrating APIC timer ...
..... CPU clock speed is 1302.9962 MHz.
..... host bus clock speed is 200.4608 MHz.
On Thursday, 24. January 2002 18:22, Rasmus B?g Hansen wrote:
> Hello Dieter
>
> > Hello Rasmus,
> >
> > I hope that I've extracted your name right?
>
> Yup, just a danish letter in my middle-name :-)
You see, my KDE-2.2.2 (iso-8859-15, Europe) kann handle it easily...;-)
> > > However, after disabling APM and enabling ACPI, my system won't power
> > > off anymore :-(
> >
> > This should be easily solved.
> >
> > I point on your distro's startup scripts. They only look if apm is
> > enabled but _NOT ACPI...
>
> Well, RedHat 7.2 does not look if apm or acpi is configured, it just
> uses -p unless the command run was 'halt' or 'reboot'.
OK.
> When running '/sbin/poweroff' from single-user, 'halt -i -d p' is the
> last command run by the halt script. The I get the message 'Power down.'
> from the kernel and my system just hangs here.
What if you do it by hand?
> When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> again the last command run, follwing this from the kernel:
>
> Power down.
> hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
Maybe this is an indication of broken BIOS.
You should grep for the ACPI diagnosis tools and send your results to the
acpi-devel list.
> And again my system hangs. Pressing the power button for 4 seconds turns
> off the computer (the BIOS is set to 'immediate power off').
What? This is contradictorily.
> In runlevel 3, the following modules are loaded (some are patched in
> from the iptables package. They should not cause this, as I can
> reproduce this without iptables configured/patched at all):
Should all be unrelated.
>
> From my 'make menuconfig:
>
> [*] Power Management support
> [*] ACPI support
> [*] ACPI Debug Statements
> <*> ACPI Bus Manager
> <*> System
> <*> Processor
> < > Button
> < > AC Adapter
> < > Embedded Controller
> < > Advanced Power Management BIOS support
I have Button enabled, too. Please try.
My .config file looks like this:
CONFIG_ACPI=y
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUSMGR=y
CONFIG_ACPI_SYS=y
CONFIG_ACPI_CPU=y
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_EC is not set
# CONFIG_APM is not set
> At bootup I get the following regarding ACPI:
Can you send the fist lines from your boot log?
Maybe you should CC to acpi-devel.
>
> tbxface-0099 [01] Acpi_load_tables : ACPI Tables successfully
> loaded
> Parsing
> Methods:...................................................................
>................................................ 115 Control Methods found
> and parsed (364 nodes total)
> ACPI Namespace successfully loaded at root c0286ee0
> ACPI: Core Subsystem version [20011018]
> evxfevnt-0081 [02] Acpi_enable : Transition to ACPI mode
> successful
> Executing device _INI methods:.......................................
> 39 Devices found: 39 _STA, 0 _INI
> Completing Region and Field initialization:...................
> 17/24 Regions, 2/2 Fields initialized (364 nodes total)
> ACPI: Subsystem enabled
> ACPI: System firmware supports S0 S1 S4 S5
> Processor[0]: C0 C1 C2, 8 throttling states
Here is something missing. Ah, the power button thing.
>
> My motherboard is an Asus A7V133-C. Output from lspci -v:
> 00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
> 40) Subsystem: Asustek Computer, Inc.: Unknown device 8042
> Flags: medium devsel, IRQ 9
> Capabilities: <available only to root>
Unknown device 8042
Maybe here is something missing, too.
The ACPI people should lighten this. --- Andrew?
> I have very little knowledge of ACPI,
I am, too...;-)
But hey, we have OSS and Andrew and his team. They did very good work!
> ut I'll be happy to help
Every "new" ACPI chip need support.
> (if this is not my fault of course - then I will apologize for taking your
> time
Never mind.
Regards,
Dieter
On Thu, 24 Jan 2002, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
>
> I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
> that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
> kernel ACPI does not. However, the Intel ACPI patch, available from
> http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
> kernel 2.4.16, does power down my machine. I was able to forward port
> this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
> applying the Intel ACPI patch first, and then applying kernel
> patch-2.4.17 and kernel patch-2.4.18-pre7.
ok .. .maybe someone should look what the differences for the "halt"
functions are ... i risked a short look in the acpi sources, but i have
not the time to compare the patches at the moment ... maybe at the weekend
... but the acpi sources don't look like easy to understand :) (like many
parts of ther kernel ... imha as a kernel newbee :) )
>
> As to the merits of the amd_disconnect patch that started this thread,
> under 2.4.18-pre7-acpi, I get an idle CPU temperature of about 48 C.
> With the amd_disconnect patch, it drops to 32-35 C, wow! As
> previously discussed, APM + amd_disconnect on an Athlon does not
> provide any power savings, one needs ACPI + amd_disconnect.
ahh ... anopther "it works"- feedback ... :)
daniel
On Thu, 24 Jan 2002, Hans-Peter Jansen wrote:
> Because of the mutual exclusive nature of this feature, I filed it
> under unfinished hardware feature.
hmmm ... maybe it is realy hardware depending ... with my relativly new
motherboard and fast cpu/system componends it is no problem at all ...
looking video, hearing music , ... no problems ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002 [email protected] wrote:
>
> I have ASUS A7V266-E (AS99127F chip) and lm_sensors 2.6.2
> shows 43 C for CPU without any additional lines in /etc/sensors.conf
>
> Which sounds reasonable. However this temperature is rarely ever change !
> I typically have 43.1, sometimes 42.8 and that's it. Even after 2-3 min
>
> compiles. So something is wrong
yes ... you have no working power-saving ... so the cpu runs at full
power all the time ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Pavel Machek wrote:
> Hi!
>
> You could look for how long CPU was idle, and only if it was mostly
> idle in last 10 seconds enable the bit ;-).
> Pavel
i will keep it in my mind ... when nothing other is found which cause the
problems ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 24 Jan 2002, Rasmus B?g Hansen wrote:
> Somewhere a long way down the "ACPI troubles (Was:[...]" thread someone
> told me, that the Asus A7V family is broken and implement the power-off
> funtion in a wrong manner. You have to update ACPI to make it work (but
> now it works like a charm). You should be able to find the links in the
> other thread.
ok ... so it looks like it is a known problem and will be fixed by future
updates to the kernel :)
one thing less i have to look at :)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On 24 Jan 2002, Disconnect wrote:
> 1.3G here.. how much faster does it need to be? (didn't test audio/video
> streams due to the unusability of my keyboard.. I can reboot and try it
> if it would be useful.)
>
> calibrating APIC timer ...
> ..... CPU clock speed is 1302.9962 MHz.
> ..... host bus clock speed is 200.4608 MHz.
ok ... does not look like a speed problen :)
i have 1,4g and it works like a charm ....
hmmm ... maybe acpi problems with the different motherboards ? buggy
implemention of the acpi functions in the bios ? or maybee a fsb problem
(have 133mhz fsb ... does someone with 133mhz fsb have problems to?)
i have no real idea at the moment ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thursday, 24. January 2002 21:54, Daniel Nofftz wrote:
> On Thu, 24 Jan 2002, Hans-Peter Jansen wrote:
> > You can see, enough idleness...
> >
> > The question is, why amd_disconnect=true causes this distortion. I tend
> > to believe that dis-/reconnecting CPU takes simply too long in this
> > scenario.
>
> hmmm ... yes ... this would be my idea too ... maybee the dis-reconnect
> procedure is to slow on "slow" computers to grant undisrupted audio or
> video streams ...
>
> i have no problem with this ... maybee caus i have a "faster" cpu ?
Asus A7V133 with 1.2 GHz Athlon:
<4>Detected 1224.230 MHz processor.
<4>Calibrating delay loop... 2444.49 BogoMIPS
<4>Memory: 771764k/786352k available (1104k kernel code, 14196k reserved,
303k data, 224k
init, 0k highmem)
System feels fast normally, and feels noticable slower with disconnected
feature. The problem with vlc is it's timing fragility to get smooth video
and synchronous audio output. (I also need alsa > 0.9.0 and XVideo scaling
on my Matrox G450 to get there, btw).
System is fast enough to compile the kernel during playback without a
hitch. CD copying with cdrdao is a different story. This would be my
ultimate latency check (but haven't played with low latency, yet).
If you like playing vcds and/or dvds, try vlc 0.2.92:
http://www.videolan.org/pub/videolan/vlc/0.2.92/vlc-0.2.92.tar.bz2
It's my stablest player so far. I'm trying mplayer CVS from time to
time, also xine, ogle but vlc is my personal favorite (I'm using a 0.2.92
CVS version and play plain vob's from my server most of the time).
Ask me privately, if you need any help with such stuff..
> daniel
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
Cheers,
Hans-Peter
> > As to the merits of the amd_disconnect patch that started this thread,
> > under 2.4.18-pre7-acpi, I get an idle CPU temperature of about 48 C.
> > With the amd_disconnect patch, it drops to 32-35 C, wow! As
> > previously discussed, APM + amd_disconnect on an Athlon does not
> > provide any power savings, one needs ACPI + amd_disconnect.
>
> ahh ... anopther "it works"- feedback ... :)
And another. Dropped my CPU from ~50+C down to 39C (I have a hot
case). I haven't had any problems but its a headless, no keyboard/mouse
machine.
On Thursday, 24. January 2002 21:55, Daniel Nofftz wrote:
> On 24 Jan 2002, Disconnect wrote:
>
> > 1.3G here.. how much faster does it need to be? (didn't test audio/video
> > streams due to the unusability of my keyboard.. I can reboot and try it
> > if it would be useful.)
> >
> > calibrating APIC timer ...
> > ..... CPU clock speed is 1302.9962 MHz.
> > ..... host bus clock speed is 200.4608 MHz.
>
> ok ... does not look like a speed problen :)
> i have 1,4g and it works like a charm ....
>
> hmmm ... maybe acpi problems with the different motherboards ? buggy
> implemention of the acpi functions in the bios ? or maybee a fsb problem
> (have 133mhz fsb ... does someone with 133mhz fsb have problems to?)
>
> i have no real idea at the moment ...
I found some additional info for you.
Our famous German c't magazin have:
http://www.heise.de/ct/01/18/036/default.shtml
And you should have a look into this AMD doku (sadly _NO_ AMD 750/760 infos):
"AMD Athlon Processor Model 4 Revision Guide"
http://www.amd.com/products/cpg/athlon/techdocs/pdf/23614.pdf
AMD could be easily enlighten us, of course!
-Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Thu, 24 Jan 2002, Dieter [iso-8859-15] N?tzel wrote:
> > > > However, after disabling APM and enabling ACPI, my system won't power
> > > > off anymore :-(
> > When running '/sbin/poweroff' from single-user, 'halt -i -d p' is the
> > last command run by the halt script. The I get the message 'Power down.'
> > from the kernel and my system just hangs here.
>
> What if you do it by hand?
Eh, it signals init to go to runlevel 0. Apparently it is some kind of
wrapper.
> > When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> > again the last command run, follwing this from the kernel:
> >
> > Power down.
> > hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
>
> Maybe this is an indication of broken BIOS.
Another broken BIOS implementation...
Btw. I'm running with BIOS 1005A. I did not dare to flash to 1007 as the
flash program is telling me, that the 1007 BIOS is for "A7V133-C" while
my current BIOS is for "<A7V133>"...
> You should grep for the ACPI diagnosis tools and send your results to the
> acpi-devel list.
Eh, is that the pmtools package? If so, I have put output from the
programs at http://www.amagerkollegiet.dk/~moffe/acpi/
> > And again my system hangs. Pressing the power button for 4 seconds turns
> > off the computer (the BIOS is set to 'immediate power off').
>
> What? This is contradictorily.
If the Linux ACPI implementation takes over control of the button, it
should be ok or what?
> > From my 'make menuconfig:
> >
> > [*] Power Management support
> > [*] ACPI support
> > [*] ACPI Debug Statements
> > <*> ACPI Bus Manager
> > <*> System
> > <*> Processor
> > < > Button
> > < > AC Adapter
> > < > Embedded Controller
> > < > Advanced Power Management BIOS support
>
> I have Button enabled, too. Please try.
I just tried the same ACPI configuration as you; no change - it still
hangs at 'Power off.'.
> > At bootup I get the following regarding ACPI:
>
> Can you send the fist lines from your boot log?
I have put it in the same place
(http://www.amagerkollegiet.dk/~moffe/acpi/) as acpi-old.txt. Also there
is the dmesg from the kernel with the acpi-patch (from the intel site)
applied.
> Maybe you should CC to acpi-devel.
Done (however I'm not a list member myself).
> > My motherboard is an Asus A7V133-C. Output from lspci -v:
>
> > 00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
> > 40) Subsystem: Asustek Computer, Inc.: Unknown device 8042
> > Flags: medium devsel, IRQ 9
> > Capabilities: <available only to root>
>
> Unknown device 8042
>
> Maybe here is something missing, too.
>
> The ACPI people should lighten this. --- Andrew?
I've put the output from 'lspci -vvv -xx' on the same site
(http://www.amagerkollegiet.dk/~moffe/acpi/) if it should show up to be
helpful.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
He has his own opinions
- just like the others.
- Burnin' Red Ivanhoe
----------------------------------[ moffe at amagerkollegiet dot dk ] --
On Friday, 25. January 2002 00:18, Dieter N?tzel wrote:
> On Thursday, 24. January 2002 21:55, Daniel Nofftz wrote:
> > On 24 Jan 2002, Disconnect wrote:
> > > 1.3G here.. how much faster does it need to be? (didn't test
> > > audio/video streams due to the unusability of my keyboard.. I can
> > > reboot and try it if it would be useful.)
> > >
> > > calibrating APIC timer ...
> > > ..... CPU clock speed is 1302.9962 MHz.
> > > ..... host bus clock speed is 200.4608 MHz.
> >
> > ok ... does not look like a speed problen :)
> > i have 1,4g and it works like a charm ....
> >
> > hmmm ... maybe acpi problems with the different motherboards ? buggy
> > implemention of the acpi functions in the bios ? or maybee a fsb problem
> > (have 133mhz fsb ... does someone with 133mhz fsb have problems to?)
> >
> > i have no real idea at the moment ...
>
> I found some additional info for you.
>
> Our famous German c't magazin have:
> http://www.heise.de/ct/01/18/036/default.shtml
>
> And you should have a look into this AMD doku (sadly _NO_ AMD 750/760
> infos): "AMD Athlon Processor Model 4 Revision Guide"
> http://www.amd.com/products/cpg/athlon/techdocs/pdf/23614.pdf
>
> AMD could be easily enlighten us, of course!
Addition:
Sound skip related (Creative SoundBlaster etc.)
Sorry in German, too:
http://www.heise.de/ct/foren/go.shtml?read=1&msg=11&g=200118036
So I think most trouble should be solvable when we get _MUCH_ better support
by the hardware vendors!
Cheers,
Dieter
Nice job, Petr, you rock! Your patch allows my ASUS A7V BIOS 1009 to
poweroff off under kernel 2.4.18-pre7 with ACPI. Much easier than the big
ACPI patch against 2.4.16 from Intel.
Cheers, Wayne
On Thu, 24 Jan 2002, Petr Vandrovec wrote:
> I still have this in my tree. I have no idea who is wrong, whether
> parser or BIOS.
> Best regards,
> Petr Vandrovec
> [email protected]
>
> diff -urdN linux/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
> --- linux/drivers/acpi/hardware/hwsleep.c Wed Oct 24 21:06:22 2001
> +++ linux/drivers/acpi/hardware/hwsleep.c Tue Jan 22 16:17:46 2002
> @@ -152,6 +152,13 @@
> return status;
> }
>
> + /* Broken ACPI table on ASUS A7V... it reports type 7, but poweroff is type 2...
> + sleep is type 1 while ACPI reports type 3, but as I was not able to get
> + machine to wake from this state without unplugging power cord... */
> + if (type_a == 7 && type_b == 7 && sleep_state == ACPI_STATE_S5 && !memcmp(acpi_gbl_DSDT->oem_id, "ASUS\0\0", 6)
> + && !memcmp(acpi_gbl_DSDT->oem_table_id, "A7V ", 8)) {
> + type_a = type_b = 2;
> + }
> /* run the _PTS and _GTS methods */
>
> MEMSET(&arg_list, 0, sizeof(arg_list));
Daniel wrote:
> hmmm ... maybe it is realy hardware depending ... with my
> relativly new motherboard and fast cpu/system componends
> it is no problem at all ...
> looking video, hearing music , ... no problems ...
I've played with lvcool on my box: Abit KT7A (KT133A), Athlon 1.1 GHz.
When I use my BT848 tv card to watch tv, there usually are some signs
that the PCI transfer rate is not high enough - some bits of image do
not get refreshed, but nothing major when lvcool is off.
But when running lvcool, the whole thing would look like a special
effects show: not even half the image would be refreshed every frame.
The BT848 writes directly over the PCI to AGP bridge to the video card
RAM so the CPU is completely idle. Thus it seems likely that the bus
performance is affected. ISTR that the actual 'disconnect' effect is
caused by a read from a south bridge register. I assume that read takes
a while, and this keeps the bus busy. This may not be a prblem in
itself, unless the PCU has the highest priority in the system, or has
the possibility to 'just do another cycle'.
However, with lvcool the CPU temperature dropped remarkably - from 20
degrees above case to 2 degrees above case.
But after updating the BIOS to version 3R, lvcool only results in a hard
crash. So now I found out how PCI latencies work, I have no change to
test. I can imagine that playing with the host bridge latencies will
solve this, just as it can improve on the video playing without lvcool.
That said, the 3R bios version does not support ACPI based disconnect at
all. But why lvcool wedges the system so well? Maybe some ACPI activity?
But then, my kernel was the same before and after the BIOS update.
Thomas
On Thu, 24 Jan 2002, Petr Vandrovec wrote:
> On Thu, Jan 24, 2002 at 09:49:37AM -0800, Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
> >
> > > When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> > > again the last command run, follwing this from the kernel:
> > > Power down.
> > > hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
> > > And again my system hangs.
> >
> > I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
> > that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
> > kernel ACPI does not. However, the Intel ACPI patch, available from
> > http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
> > kernel 2.4.16, does power down my machine. I was able to forward port
> > this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
> > applying the Intel ACPI patch first, and then applying kernel
> > patch-2.4.17 and kernel patch-2.4.18-pre7.
>
> I still have this in my tree. I have no idea who is wrong, whether parser
> or BIOS.
Your patch might work on the A7V, but it does not on my A7V133-C. If I
modify the OEM string in the patch, it works. It may also be modified to
[...] "A7V-133", 7)[...] but then it probably won't work on a A7V...
As said in another post, the patch from the intel site also solves the
problem.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
A computer without Windows is like a chocolate cake without mustard.
----------------------------------[ moffe at amagerkollegiet dot dk ] --
diff -urdN linux/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
--- linux/drivers/acpi/hardware/hwsleep.c Wed Oct 24 21:06:22 2001
+++ linux/drivers/acpi/hardware/hwsleep.c Tue Jan 22 16:17:46 2002
@@ -152,6 +152,13 @@
return status;
}
+ /* Broken ACPI table on ASUS A7V... it reports type 7, but poweroff is type 2...
+ sleep is type 1 while ACPI reports type 3, but as I was not able to get
+ machine to wake from this state without unplugging power cord... */
+ if (type_a == 7 && type_b == 7 && sleep_state == ACPI_STATE_S5 && !memcmp(acpi_gbl_DSDT->oem_id, "ASUS\0\0", 6)
+ && !memcmp(acpi_gbl_DSDT->oem_table_id, "A7V", 3)) {
+ type_a = type_b = 2;
+ }
/* run the _PTS and _GTS methods */
MEMSET(&arg_list, 0, sizeof(arg_list));
Hi,
I have been watching this thread for a while now. I am surprised everybody
is happy with the temperature drops they get and don't look a bit
further. I might be sounding like a *ickhead but here go my .02 euros:
With STOPGNT enabled, the disconnection happens by the northbridge
actually halting the FSB for the CPU until the next interrupt. The
continuous dis/reconnection causes increased lattency on the PCI bus and
strictly timed PCI transfers needed by TV-Tuner cards/software or sound
software suffer greatly from this. It also results in poorer hd
performance.
Also with such a power hungry CPU as the Athlon, bus dis/reconnection
results in current demand changing from 40A to 5A to 40A ... every few ms.
This puts your motherboards' voltage regulator under unecessary strain as
well those in your PSU.
Furthermore, CPUs do like lower operating temperatures, but even more they
like constant temperatures. Differences like 10-15C every now and then
(load/idle) put the cpu die under mechanichal strain from thermal
contraction/expansion.
Finally, this procedure can actually *hide* severe cooling inefficiency of
the system. People seem to go with the moto: STOPGNT lowers my
temperature, so it is a good thing. Well, it doesn't. Run SETI@HOME and
you are back where you started. It can take only a hot summer day and you
have a fried chip.
There was a thought by somebody, that you should only enable disconnection
after some time of inactivity. This sounds better, but then, don't we
have S1/S3 for this already?
This feature of the AMD processors seemed like a real bargain once but
now, I doupt there is one motherboard vendor out there that allows you to
control it in the BIOS (like they used too). Even more, they suggest you
leave this feature alone. A walk in troubleshooting/support forums
suggests the same: It is a feature you can do without, you'd be better off
with a cooler that can cool and a well ventilated case.
Sorry for the length,
-Kostas
On Fri, 2002-01-25 at 09:17, Liakakis Kostas wrote:
>
> Hi,
>
> I have been watching this thread for a while now. I am surprised everybody
> is happy with the temperature drops they get and don't look a bit
> further. I might be sounding like a *ickhead but here go my .02 euros:
>
> With STOPGNT enabled, the disconnection happens by the northbridge
> actually halting the FSB for the CPU until the next interrupt. The
> continuous dis/reconnection causes increased lattency on the PCI bus and
> strictly timed PCI transfers needed by TV-Tuner cards/software or sound
> software suffer greatly from this. It also results in poorer hd
> performance.
>
> Also with such a power hungry CPU as the Athlon, bus dis/reconnection
> results in current demand changing from 40A to 5A to 40A ... every few ms.
> This puts your motherboards' voltage regulator under unecessary strain as
> well those in your PSU.
>
> Furthermore, CPUs do like lower operating temperatures, but even more they
> like constant temperatures. Differences like 10-15C every now and then
> (load/idle) put the cpu die under mechanichal strain from thermal
> contraction/expansion.
>
> Finally, this procedure can actually *hide* severe cooling inefficiency of
> the system. People seem to go with the moto: STOPGNT lowers my
> temperature, so it is a good thing. Well, it doesn't. Run SETI@HOME and
> you are back where you started. It can take only a hot summer day and you
> have a fried chip.
>
> There was a thought by somebody, that you should only enable disconnection
> after some time of inactivity. This sounds better, but then, don't we
> have S1/S3 for this already?
>
> This feature of the AMD processors seemed like a real bargain once but
> now, I doupt there is one motherboard vendor out there that allows you to
> control it in the BIOS (like they used too). Even more, they suggest you
> leave this feature alone. A walk in troubleshooting/support forums
> suggests the same: It is a feature you can do without, you'd be better off
> with a cooler that can cool and a well ventilated case.
>
> Sorry for the length,
>
> -Kostas
>
I was getting at this earlier. Though the Athlon XP's are much better
power-wise than the earlier athlon's. I wouldn't suggest doing it to
any athlon under XP. But then again, the XP is supposed to have
something similar to clock stepping to gradually move from full power to
lower power, which decreases mechanical stress and psu stress. I
remember when the same concerns were brought over the HLT idle trick but
obviously the HLT instruction isn't harmful enough. Would be nice to
look at the latencies with say, Robert Love's preempt stat patch of a
kernel running with no power management, then with HLT, then with the
vcl patch.
Nice rule of thumb though. If your cpu _ever_ gets into the 50C range
your case and or hsf is not efficient enough for your hardware. Anything
above 50 and you're shortening the life of the cpu. Relying on idle
tricks isn't going to help you.
I'd recommend this patch for Athlon XP's since they're the only chips
that have motherboards built to handle this kind of thing (assuming you
didn't buy some cheap brand). Don't use it on anything earlier. Not that
I dont believe that the chip can take the punishment, but I dont believe
that the motherboard and cpu can if not built to XP specifications.
On 25 Jan 2002, Ed Sweetman wrote:
>
> I was getting at this earlier. Though the Athlon XP's are much better
> power-wise than the earlier athlon's. I wouldn't suggest doing it to
> any athlon under XP. But then again, the XP is supposed to have
I reckon a >1600MHz XP (1800+) has about the same or more power than the
1400MHz T-bird. So it should basically be the same regarding the
STPGNT/disconnect.
> something similar to clock stepping to gradually move from full power to
> lower power, which decreases mechanical stress and psu stress. I
I guess this is the PowerNOW! feature of the mobile Athlons/Durons with
the Palomino core. I think this is totaly different than STPGNT. And this
would be worth implementing if it can be supported on desktop Athlon/Duron
models/mobos.
Anybody has more info about this?
> remember when the same concerns were brought over the HLT idle trick but
> obviously the HLT instruction isn't harmful enough. Would be nice to
> look at the latencies with say, Robert Love's preempt stat patch of a
> kernel running with no power management, then with HLT, then with the
> vcl patch.
True. Although an tv tunner card output on screen tells the tale pretty
well :-)
> Nice rule of thumb though. If your cpu _ever_ gets into the 50C range
> your case and or hsf is not efficient enough for your hardware. Anything
> above 50 and you're shortening the life of the cpu. Relying on idle
> tricks isn't going to help you.
I hope everybody could see it this way.
-K.
On Fri, Jan 25, 2002 at 06:10:35PM +0200, Liakakis Kostas wrote:
> I guess this is the PowerNOW! feature of the mobile Athlons/Durons with
> the Palomino core. I think this is totaly different than STPGNT. And this
> would be worth implementing if it can be supported on desktop Athlon/Duron
> models/mobos.
>
> Anybody has more info about this?
I checked in powernow-k7.c to the cpufreq CVS today.
So far it doesn't do anything other than detect the ability
to scale voltage/speed. I'll add that later.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, Jan 24, 2002 at 09:23:32AM -0500, Ed Sweetman wrote:
>
> > I thought, ntpd would take care of the RTC:
>
> It doesn't. init scripts on boot sync the date to the rtc, if your date
> isn't near what it should be then ntp wont work. It has to at least be
> close then run date --systohc or something like that.
Which is why it's a good idea to have ntpdate run on startup to get the
clock sync'd to one ntp server and then that will guarentee that ntpd will
start up happily and be happy etc.
Matthew
--
Matthew Sackman
Nottingham
England
BOFH Excuse Board:
excessive collisions & not enough packet ambulances
Hi!
> > > In mailing-lists.linux-kernel, Rasmus B?g Hansen wrote:
> > >
> > > > When running /sbin/poweroff from runlevel 3 or 5, 'halt -i -d -p' is
> > > > again the last command run, follwing this from the kernel:
> > > > Power down.
> > > > hwsleep-0178 [02] Acpi_enable_sleep_state: Entering S5
> > > > And again my system hangs.
> > >
> > > I have an ASUS A7V motherboard, similar to your ASUS A7V133. I find
> > > that stock kernel (2.4.18-pre7) APM powers off the machine, but stock
> > > kernel ACPI does not. However, the Intel ACPI patch, available from
> > > http://developer.intel.com/technology/IAPC/acpi/downloads.htm against
> > > kernel 2.4.16, does power down my machine. I was able to forward port
> > > this to 2.4.18-pre7 without too much trouble by starting with 2.4.16,
> > > applying the Intel ACPI patch first, and then applying kernel
> > > patch-2.4.17 and kernel patch-2.4.18-pre7.
> >
> > I still have this in my tree. I have no idea who is wrong, whether parser
> > or BIOS.
>
> Your patch might work on the A7V, but it does not on my A7V133-C. If I
> modify the OEM string in the patch, it works. It may also be modified to
> [...] "A7V-133", 7)[...] but then it probably won't work on a A7V...
This should be done properly by DMI blacklist.
> As said in another post, the patch from the intel site also solves the
> problem.
Which patch?
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Actually, I used a separate temperature sensor to come up with proper values
for lm_sensors to read the CPU temperature on my A7V (ver 1.01). After
testing lowest and highest temperatures, this what I came up with:
compute temp2 28.2+((@-18)*2), ((@-28.2)/2)+18
I know it looks weird, but it makes the "sensors" value for CPU temperate
match (within .5 degrees C) across the entire range I can test (which is
from full load on a 1GHz Thunderbird down to idle and using the old "lvcool"
patch).
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Cc: "Rasmus B?g Hansen" <[email protected]>; "LKML"
<[email protected]>
Sent: Thursday, January 24, 2002 11:48 AM
Subject: Re: ACPI trouble (Was: Re: [patch] amd athlon cooling on kt266/266a
chipset)
> > Note that on this motherboard (and perhaps all ASUS Via chipset
> > motherboards, including the A7V133), one needs the following line in
> > /etc/sensors.conf to get reasonable lm_sensors CPU temperatures:
> > compute temp2 @*2, @/2
> > This is as described at http://www2.lm-sensors.nu/~lm78/support.html
> > in Ticket 775.
> >
>
> I have ASUS A7V266-E (AS99127F chip) and lm_sensors 2.6.2
> shows 43 C for CPU without any additional lines in /etc/sensors.conf
>
> Which sounds reasonable. However this temperature is rarely ever change
!
> I typically have 43.1, sometimes 42.8 and that's it. Even after 2-3
min
>
> compiles. So something is wrong
>
> Dmitri
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> System feels fast normally, and feels noticable slower with disconnected
> feature. The problem with vlc is it's timing fragility to get smooth video
> and synchronous audio output. (I also need alsa > 0.9.0 and XVideo scaling
> on my Matrox G450 to get there, btw).
hi hans-peter
i have uploaded a new testing version of the patch to the webserver. you
can get it from:
http://cip.uni-trier.de/nofftz/linux/amd_cool_new.diff
it is only a testing version and an attempt to fix this skippy behavior on
video and audio playback. after some searching through athlon references i
found some hints, how to set up the athlon processor to perform better
when reconnected to the system bus. so i figgured out a way to make this
processor setup from within the kernel (normaly it should be done by the
bios). i am not sure whether it does that what i wanted, cause i have no
sound video problems, so i need someone who tests this with a computer
which has problems with the patch. maybee you could do this ?
the new patch will modify a msr (mashine specific register) on the athlon
cpu, which is used to reset the clock to the right value, when the bus is
reconnected. i used a different setting, i found in one of the reference
guides. i am not sure whether this is the right value to fix the problem,
cause the documentation for the processor bug is only acessable by
registerd bios programmer (i think ... i didn't find it until yet) ...
so -... please give it a try and report whether the problems are going
better with this new testing version.
as befor, you have to enable acpi and acpi-processor ... then you have to
enter amd_discconet=yes at lilo prompt and this time you also have to
enter force_amd_clk=yes ....
at booting time (dmesg) linux will say something like:
Athlon/Duron CLK_Ctrl Value found : 6003d22f
Enabling disconnect in VIA northbridge: KT266/266A chipset found.
and ... when you have force_amd_clk enabed it will say something like
"Athlon/Duron CLK_Ctrl Value set to: ....." ... please include this output
in the replay ti me :)
if someone else with or without the problems want do give the patch a try:
please include this output lines (the values that are found) in the
posting .... expecialy i am interested to get the values from the people
who have no problems with the patch :)
thanks ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]