hi!
i spend the morning (on my work *grin*) reading some papers (amd reviion
guide), rereading many of the mails on this topic and reading some reports
in the german c't magazin.
so...
let me "review" what problems we had:
* sound skips
* video skips / slowdown
* ultra-dma disk transfer slowdown
* system instability (one time : deadlock)
* generel performance loss on some computers
...
first: i found the answer why my patch works with acpi and not with apm:
apm only issues a halt signal loop. this does not trigger the disconnect
on STPGNT function which will cause significant power saving !!! ... the
c1 state also only provides halt (as far as i understand it). the c2 state
provides the stop-grant signal our searched STPGNT) -> ACPI C2 states
trigger the disconnect function in the northbridge, which will cause
power-saving ....
ok ....
now to the problems:
there are two known athlon bugs which cause trouble with the disconnect
function (errata 11 and errata 14 on the "AMD Athlon Processor Model 4
Revision Guide"). this bugs are present in ALL Athlon and Duron Revisions!
It looks like this bugs are not present in the Athlon XP and the new
Duron. (could be an answer to the question, why i don't have problems with
the disconnect function. i have an athlon xp 1600+)
what are now this errata bugs ?
bug 11:
when the processor is disconnected from the fsb, the internal clock is
slowed down to save power. when the processor is reconnected, it should
return to the normal clock ratio. but ... in some cases it doesn't ! "the
pll can exceed ther normal operating frequency, causing a failure to
maintain suffient system bus I/O drive strength levels in the driver
compension circuit. the compensation circuit attempts to correct this
drive strength, but if there is not sufficient time to perform this
function, the system bus cannot operate properly" (taken form the rev.
guide)
the laste few words could be a explanation for the video / sound skips ...
?
the guide also says, that a workaround is possible by bios manipulation
... so the manufacturer of the motherboard could make a bios which
corrects this problem ... (dimm it to a level where no system influence is
noticable)
bug14:
processors with half-frequency multipliers (like 11.5, 12.5, ...) may hang
upon wake-up from disconnect. this problem comes from a circuit which is
used to wake up from low-power states (c2 and c3) and which could glitch
when coming out of the c2 and c3 states.
this could cause an system hang!
-> suggested workaround from the guide: the bios programmer should disable
c2 and c3 (leastwise for the cpus with half frequency multio.)... very
helpfull :(
what other problems could be ?
some motherboards or cheaper powersuplies can't handle the jumps of
power-consumption when entering or leaving the 1/c2 states ... sometimes
this could be such extrem jumps like from 5W to 50W ... (information taken
from an asus page and vcool faq)
a suggestion which came up in the thread was, that pci latancy or other
pci-bios options could influence the "skips"-problem in video and
soundstreams ... i will test this today or tomorrow at my computer ...
but i am not shure whether i have a chance to reproduce any of the
problems, cause i have a cp cpu and a good motherboard and good
powersuply ...
oh ... and after what i have read the reconnect could take "some time"
maybe this could also be an answer for the skips if your system requires a
continual stream of data ....
what could you do ?
if you have problem: test whether some tuning on the pci settings in the
bios influences your problems ... maybe use some "slower" setting and lokk
whether the problems vanishes or get fewer ...
are there any people who have problems with the patch and an athlon xp ?
maybe test a newer bios ... !
does the "delay transaction" function influence the behavior ? Beware !
this function could cause data loss on some computers !
ok ... enough for now ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
It sounds like you'll have to make the patch work just for Athlon XP's
... unless of course you're not expecting it to be included in the
kernel ever.
On Fri, 2002-01-25 at 08:23, Daniel Nofftz wrote:
> hi!
> i spend the morning (on my work *grin*) reading some papers (amd reviion
> guide), rereading many of the mails on this topic and reading some reports
> in the german c't magazin.
> so...
> let me "review" what problems we had:
> * sound skips
> * video skips / slowdown
> * ultra-dma disk transfer slowdown
> * system instability (one time : deadlock)
> * generel performance loss on some computers
> ...
>
> first: i found the answer why my patch works with acpi and not with apm:
> apm only issues a halt signal loop. this does not trigger the disconnect
> on STPGNT function which will cause significant power saving !!! ... the
> c1 state also only provides halt (as far as i understand it). the c2 state
> provides the stop-grant signal our searched STPGNT) -> ACPI C2 states
> trigger the disconnect function in the northbridge, which will cause
> power-saving ....
>
> ok ....
>
> now to the problems:
> there are two known athlon bugs which cause trouble with the disconnect
> function (errata 11 and errata 14 on the "AMD Athlon Processor Model 4
> Revision Guide"). this bugs are present in ALL Athlon and Duron Revisions!
> It looks like this bugs are not present in the Athlon XP and the new
> Duron. (could be an answer to the question, why i don't have problems with
> the disconnect function. i have an athlon xp 1600+)
>
> what are now this errata bugs ?
>
> bug 11:
> when the processor is disconnected from the fsb, the internal clock is
> slowed down to save power. when the processor is reconnected, it should
> return to the normal clock ratio. but ... in some cases it doesn't ! "the
> pll can exceed ther normal operating frequency, causing a failure to
> maintain suffient system bus I/O drive strength levels in the driver
> compension circuit. the compensation circuit attempts to correct this
> drive strength, but if there is not sufficient time to perform this
> function, the system bus cannot operate properly" (taken form the rev.
> guide)
> the laste few words could be a explanation for the video / sound skips ...
> ?
>
> the guide also says, that a workaround is possible by bios manipulation
> ... so the manufacturer of the motherboard could make a bios which
> corrects this problem ... (dimm it to a level where no system influence is
> noticable)
>
> bug14:
> processors with half-frequency multipliers (like 11.5, 12.5, ...) may hang
> upon wake-up from disconnect. this problem comes from a circuit which is
> used to wake up from low-power states (c2 and c3) and which could glitch
> when coming out of the c2 and c3 states.
> this could cause an system hang!
> -> suggested workaround from the guide: the bios programmer should disable
> c2 and c3 (leastwise for the cpus with half frequency multio.)... very
> helpfull :(
>
>
> what other problems could be ?
>
> some motherboards or cheaper powersuplies can't handle the jumps of
> power-consumption when entering or leaving the 1/c2 states ... sometimes
> this could be such extrem jumps like from 5W to 50W ... (information taken
> from an asus page and vcool faq)
>
> a suggestion which came up in the thread was, that pci latancy or other
> pci-bios options could influence the "skips"-problem in video and
> soundstreams ... i will test this today or tomorrow at my computer ...
> but i am not shure whether i have a chance to reproduce any of the
> problems, cause i have a cp cpu and a good motherboard and good
> powersuply ...
>
> oh ... and after what i have read the reconnect could take "some time"
> maybe this could also be an answer for the skips if your system requires a
> continual stream of data ....
>
> what could you do ?
>
> if you have problem: test whether some tuning on the pci settings in the
> bios influences your problems ... maybe use some "slower" setting and lokk
> whether the problems vanishes or get fewer ...
>
> are there any people who have problems with the patch and an athlon xp ?
>
> maybe test a newer bios ... !
>
> does the "delay transaction" function influence the behavior ? Beware !
> this function could cause data loss on some computers !
>
> ok ... enough for now ...
>
> daniel
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: [email protected]
On Friday, 25. January 2002 15:25, Ed Sweetman wrote:
> It sounds like you'll have to make the patch work just for Athlon XP's
> ... unless of course you're not expecting it to be included in the
> kernel ever.
Nonsense!
I had seen more than 2500 Athlon/Duron system since 26. August 1999.
Most system can handle it.
Best case today, again. Even better than ever.
1.2 GHz Athlon TB (133 FSB, 9.0 multiplier)
MSI MS-6330 v3.0 (K7T Turbo-R, KT133A, 686B)
open case
Win98SE with full VCool 1.7.2 active
BIOS CPU max. 84?C!!!
Then starting Winbloze
drop from 74?C to 23?C CPU, 23?C system temperature
even the cooler was "cool"
During DVD playback
~56?C than down to 23?C, again
And did you forget?
It _is_ an option. --- You can try it and disable it when it fails for you.
Just my 0.02 ?.
-Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
Hi!
> > It sounds like you'll have to make the patch work just for Athlon XP's
> > ... unless of course you're not expecting it to be included in the
> > kernel ever.
>
> Nonsense!
>
> I had seen more than 2500 Athlon/Duron system since 26. August 1999.
> Most system can handle it.
>
> Best case today, again. Even better than ever.
>
> 1.2 GHz Athlon TB (133 FSB, 9.0 multiplier)
> MSI MS-6330 v3.0 (K7T Turbo-R, KT133A, 686B)
>
> open case
> Win98SE with full VCool 1.7.2 active
>
> BIOS CPU max. 84?C!!!
> Then starting Winbloze
> drop from 74?C to 23?C CPU, 23?C system temperature
> even the cooler was "cool"
>
> During DVD playback
> ~56?C than down to 23?C, again
>
> And did you forget?
> It _is_ an option. --- You can try it and disable it when it fails for you.
Option having random strange consequences...? Maybe okay, but you
should think twice.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Friday, 25. January 2002 21:32, Dieter N?tzel wrote:
> On Friday, 25. January 2002 15:25, Ed Sweetman wrote:
> > It sounds like you'll have to make the patch work just for Athlon XP's
> > ... unless of course you're not expecting it to be included in the
> > kernel ever.
>
> Nonsense!
>
> I had seen more than 2500 Athlon/Duron system since 26. August 1999.
> Most system can handle it.
>
> Best case today, again. Even better than ever.
>
> 1.2 GHz Athlon TB (133 FSB, 9.0 multiplier)
> MSI MS-6330 v3.0 (K7T Turbo-R, KT133A, 686B)
>
> open case
> Win98SE with full VCool 1.7.2 active
>
> BIOS CPU max. 84?C!!!
> Then starting Winbloze
> drop from 74?C to 23?C CPU, 23?C system temperature
> even the cooler was "cool"
>
> During DVD playback
> ~56?C than down to 23?C, again
>
> And did you forget?
> It _is_ an option. --- You can try it and disable it when it fails for you.
>
Let's try to sort out things chipset wise:
asus a7v133 (KT133, 100 FSB, 12*): system flaky
>
> Just my 0.02 ?.
0.02 ? returned.
>
> -Dieter
Hans-Peter
On Sat, 2002-01-26 at 13:21, Hans-Peter Jansen wrote:
> Let's try to sort out things chipset wise:
>
> asus a7v133 (KT133, 100 FSB, 12*): system flaky
asus a7v133 (KT133A, 133(266)FSB, *10.5, 1.4Ghz Thunderbird, 768MB RAM).
Stable, no obvious problems or performance issues. CPU temperature at
32C during xmms, ssh usage.
mp3 playback is rock solid, even during heavy system load (two plus
compiles, mozilla etc), and also with no system load. mpeg-video
playback is smooth as always (mplayer with /dev/mga_vid), both with
heavy load and without heavy load.
kernel is 2.4.18-pre7 with preempt and lockbreak, plust a readlatency
patch.
However, I prefer amd_disconnect disabled, for obvious reasons pointed
out by other people on this list.. Temperature is now at an acceptable
42C after a while of normal load, using just acpi in kernel.
# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
03)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev
40)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
06)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
40)
00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10000
(rev 07)
00:09.1 Input device controller: Creative Labs SB Live! (rev 07)
00:0b.0 Multimedia video controller: Brooktree Corporation Bt848 TV with
DMA push (rev 12)
00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c1010 Ultra3 SCSI Adapter (rev 01)
00:0c.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c1010 Ultra3 SCSI Adapter (rev 01)
00:0d.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 34)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.:
Unknown device 0d30 (rev 02)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP
(rev 04)
just my 2 kr.
--
Mvh,
Andr? Tomt
[email protected]
On 25 Jan 2002, Ed Sweetman wrote:
> It sounds like you'll have to make the patch work just for Athlon XP's
> ... unless of course you're not expecting it to be included in the
> kernel ever.
hmmm ...
i am not quite shure that this is only working with an xp processor ... at
the moment i'm looking for some additional informations, how to tune the
processor registers to implement the fix for the errata 11 bug. it must be
possible from within the kernel to do this. you have to modify the
CLK_CTRL MSR to a different value. i hope amd will send me the document
#24478 where the right values are described ...
has someone experiences how to modify msr ? i found 2 assambler commands
("rdmsr/wtmsr") but i have no experiences with assamambler ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Sat, 26 Jan 2002, Hans-Peter Jansen wrote:
> Let's try to sort out things chipset wise:
>
> asus a7v133 (KT133, 100 FSB, 12*): system flaky
i think it is not a chipset problem ... most likly it depends on the
motherboard/bios ... sometimes on the cpu/multiplicator ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
Daniel Nofftz wrote:
>On 25 Jan 2002, Ed Sweetman wrote:
>
>>It sounds like you'll have to make the patch work just for Athlon XP's
>>... unless of course you're not expecting it to be included in the
>>kernel ever.
>>
>
>hmmm ...
>i am not quite shure that this is only working with an xp processor ... at
>the moment i'm looking for some additional informations, how to tune the
>processor registers to implement the fix for the errata 11 bug. it must be
>possible from within the kernel to do this. you have to modify the
>CLK_CTRL MSR to a different value. i hope amd will send me the document
>#24478 where the right values are described ...
>has someone experiences how to modify msr ? i found 2 assambler commands
>("rdmsr/wtmsr") but i have no experiences with assamambler ...
>
If you configure the MSR support in when compiling the kernel, you get
/dev/cpu/0/msr
which you can use to read/write them.
I don't see that doc on their website, and others have failed to find it
as well. It's probably NDA, so ask your motherboard/BIOS MFR for an
update...
>
>
>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/
>