Hello,
I was wondering if there has been some development concerning the northbridge
disconnection bit and the joined apm saving you can do... I have an amd box,
and it is running rather warm... during the periods that it isn't doing
anything, i would love to have it 'reduce the heat'...
I've found the vcool page on the net, but it's an linux-2.4.13 patch... and
we're at 17 (stable)... even though i'll probably be able to apply it (with
some offsets), i am wondering what the status is.
Thanks!
DK
On Wed, 6 Feb 2002, DevilKin wrote:
> Hello,
>
> I was wondering if there has been some development concerning the northbridge
> disconnection bit and the joined apm saving you can do... I have an amd box,
> and it is running rather warm... during the periods that it isn't doing
> anything, i would love to have it 'reduce the heat'...
>
> I've found the vcool page on the net, but it's an linux-2.4.13 patch... and
> we're at 17 (stable)... even though i'll probably be able to apply it (with
> some offsets), i am wondering what the status is.
>
> Thanks!
i am working on an patch which performs power saving on athlon cpu's with
the acpi function of the kernel ... at the moment only via's kt 133/133a
and kt266/266a chipsets are supported, but other will follow soon (amd
760) ...
if you want, you could try my patch.
you can get it under:
http://cip.uni-trier.de/nofftz/linux/amd_cool.diff
it is a patch against the 2.4.17 kernel .
you have to enable acpi-processor idle states in the kernel and you have
to activate the patch at the kernel boot prompt with "amd_disconnect=yes".
this is cause there are several problems known with the power saving
function of the athlon/duron cpus ... i am working on this ....
there is also a newer testing version which reads a special register on
the cpu and shows the value at booting time ... if you have problems with
the patch, or ... better ... if you have no problems with the patch, it
would be verry nice if you could mail me the value it shows at boot :)
the newer version is:
http://cip.uni-trier.de/nofftz/linux/amd_cool_new.diff
there is no big difference between the to versions ... the new version
only reads the register (and ... if you say force_amd_clk=yes at the boot
prompt it modifys the register, but at the moment it is not clear whether
this function does write the right value ... so use this with care ... )
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Wed, 6 Feb 2002, Daniel Nofftz wrote:
> i am working on an patch which performs power saving on athlon cpu's with
> the acpi function of the kernel ... at the moment only via's kt 133/133a
> and kt266/266a chipsets are supported, but other will follow soon (amd
> 760) ...
> if you want, you could try my patch.
> you can get it under:
> http://cip.uni-trier.de/nofftz/linux/amd_cool.diff
>
> it is a patch against the 2.4.17 kernel .
>
> you have to enable acpi-processor idle states in the kernel and you have
> to activate the patch at the kernel boot prompt with "amd_disconnect=yes".
> this is cause there are several problems known with the power saving
> function of the athlon/duron cpus ... i am working on this ....
>
> there is also a newer testing version which reads a special register on
> the cpu and shows the value at booting time ... if you have problems with
> the patch, or ... better ... if you have no problems with the patch, it
> would be verry nice if you could mail me the value it shows at boot :)
>
> the newer version is:
> http://cip.uni-trier.de/nofftz/linux/amd_cool_new.diff
>
> there is no big difference between the to versions ... the new version
> only reads the register (and ... if you say force_amd_clk=yes at the boot
> prompt it modifys the register, but at the moment it is not clear whether
> this function does write the right value ... so use this with care ... )
I just flashed my BIOS today (upgrading my Asus A7V133-C from BIOS
rev. 1005A to rev. 1007). Suddenly I begin to experience the sound-skips
reported by other people. The CPU is a TB (9x133, 1200MHz, family 6,
model 4, stepping 2).
Before flashing I had no trouble at all and the CPU cooled just fine, so
it might not only be a chipset issue.
I tried the new version of the patch and get:
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
Applying VIA southbridge workaround.
Athlon/Duron CLK_Ctrl Value found : fff0d22f
Athlon/Duron CLK_Ctrl Value set to : fff0d22f
Enabling disconnect in VIA northbridge: KT133/KX133 chipset found
I have no idea, what those register values were before flashing. When
using the patch from http://www.vcool.de I experience the same problem - it was
not present before either. I also experience the problem when running
the user-land tool from http://www.vcool.de. It does not matter whether I
specify force_amd_clk=yes or not.
No hardware changes nor kernel config changes were made.
I send output of lspci along if it might help.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
[...] Note that 120 sec is defined in the protocol as the maximum
possible RTT. I guess we'll have to use something other than TCP
to talk to the University of Mars.
----------------------------------[ moffe at amagerkollegiet dot dk ] --
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 e4000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
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-e3ffffff
Capabilities: [80] Power Management version 2
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: [c0] Power Management version 2
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: [c0] Power Management version 2
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: [80] Power Management version 2
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: [68] Power Management version 2
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: [dc] Power Management version 2
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 DDR (rev b2) (prog-if 00 [VGA])
Subsystem: Micro-star International Co Ltd: Unknown device 8261
Flags: bus master, 66Mhz, medium devsel, latency 64, 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: [60] Power Management version 2
Capabilities: [44] AGP version 2.0
On Thu, 7 Feb 2002, Rasmus B?g Hansen wrote:
> I just flashed my BIOS today (upgrading my Asus A7V133-C from BIOS
> rev. 1005A to rev. 1007). Suddenly I begin to experience the sound-skips
> reported by other people. The CPU is a TB (9x133, 1200MHz, family 6,
> model 4, stepping 2).
>
> Before flashing I had no trouble at all and the CPU cooled just fine, so
> it might not only be a chipset issue.
>
> I tried the new version of the patch and get:
> Athlon/Duron CLK_Ctrl Value found : fff0d22f
> Athlon/Duron CLK_Ctrl Value set to : fff0d22f
ahh ... the value already was set ... ok ... that means that this value is
not the right one for this cpu. i got some new informations which say that
you need different values for different cpus ... at the moment i wait
for an answer from amd. i send them an email and asked for some support on
this toppic. maybe i get the table withe the right settings.
until then i see no way to get further ... so we must wait what their
answer is ...
>
> I have no idea, what those register values were before flashing. When
> using the patch from http://www.vcool.de I experience the same problem - it was
> not present before either. I also experience the problem when running
> the user-land tool from http://www.vcool.de. It does not matter whether I
> specify force_amd_clk=yes or not.
yes ... of cause ... as you see above, the value it founds was already the
value i thought the patch has to programm. so there could be no difference
in the behavoir. maybe you could do some additional testing ?
could you please change some setting for the pci latency timer in bios or
so ? there were some discussions whether the skippy behavior has something
to do with dma transfers and maybe the latency setting could have
something to do with this. the problem is, that i have no possibility to
test this, cause my system has no problems at all with the patch ...
daniel
> No hardware changes nor kernel config changes were made.
>
i think the bios has changed some settings ... the new one handels
something different than the old one ... maybe you could send me both bios
files on my emailadress (no cc to lkml) and i will look whether i find
differences ? (haven't done this before, but maybe i find something)
> I send output of lspci along if it might help.
>
> Regards
> Rasmus
thank you for testing ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 7 Feb 2002, Daniel Nofftz wrote:
> On Thu, 7 Feb 2002, Rasmus B?g Hansen wrote:
>
> > I just flashed my BIOS today (upgrading my Asus A7V133-C from BIOS
> > rev. 1005A to rev. 1007). Suddenly I begin to experience the sound-skips
> > reported by other people. The CPU is a TB (9x133, 1200MHz, family 6,
> > model 4, stepping 2).
> >
> > Before flashing I had no trouble at all and the CPU cooled just fine, so
> > it might not only be a chipset issue.
> >
> > I tried the new version of the patch and get:
>
> > Athlon/Duron CLK_Ctrl Value found : fff0d22f
> > Athlon/Duron CLK_Ctrl Value set to : fff0d22f
>
> ahh ... the value already was set ... ok ... that means that this value is
> not the right one for this cpu. i got some new informations which say that
> you need different values for different cpus ... at the moment i wait
> for an answer from amd. i send them an email and asked for some support on
> this toppic. maybe i get the table withe the right settings.
> until then i see no way to get further ... so we must wait what their
> answer is ...
I now fiddled a little with the PCI settings in the BIOS...
When 'PCI master read cahing' is enabled everything works fine (sound
works, cooling works. When disabled I get sound skips. The above flags
are exactly the same:
Athlon/Duron CLK_Ctrl Value found : fff0d22f
Athlon/Duron CLK_Ctrl Value set to : fff0d22f
Enabling disconnect in VIA northbridge: KT133/KX133 chipset found
As I think i noted earlier, my motherboard is KT133A-based.
My system functions perfectly stable with the 'PCI master read caching'
enabled - I have no idea whether this is true in general.
Regards
Rasmus
--
-- [ Rasmus "M?ffe" B?g Hansen ] ---------------------------------------
Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
-- Alan Cox
----------------------------------[ moffe at amagerkollegiet dot dk ] --
On Thu, 7 Feb 2002, Rasmus B?g Hansen wrote:
> I now fiddled a little with the PCI settings in the BIOS...
>
> When 'PCI master read cahing' is enabled everything works fine (sound
> works, cooling works. When disabled I get sound skips. The above flags
> are exactly the same:
>
> Athlon/Duron CLK_Ctrl Value found : fff0d22f
> Athlon/Duron CLK_Ctrl Value set to : fff0d22f
> Enabling disconnect in VIA northbridge: KT133/KX133 chipset found
>
> As I think i noted earlier, my motherboard is KT133A-based.
>
> My system functions perfectly stable with the 'PCI master read caching'
> enabled - I have no idea whether this is true in general.
hey ... that are great news ... i think i have also something like this in
the bios and i will test it when i am at home... maybe i get the problems
to, when i deactivate this option ... that would give me the possibility
to test this error at my own ...
thanks for testing and for this hint :)
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 7 Feb 2002, Daniel Nofftz wrote:
> > Athlon/Duron CLK_Ctrl Value found : fff0d22f
> > Athlon/Duron CLK_Ctrl Value set to : fff0d22f
>
> ahh ... the value already was set ... ok ... that means that this value is
> not the right one for this cpu. i got some new informations which say that
> you need different values for different cpus ... at the moment i wait
> for an answer from amd. i send them an email and asked for some support on
> this toppic. maybe i get the table withe the right settings.
> until then i see no way to get further ... so we must wait what their
> answer is ...
Hello Daniel,
have you ask for _ALL_ AMD chipsets (750/760/760MP/760MPX)???
You know, I'm waiting to test the AMD 750 stuff...;-)
Thanks,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Thu, 7 Feb 2002, Dieter [iso-8859-15] N?tzel wrote:
> Hello Daniel,
>
> have you ask for _ALL_ AMD chipsets (750/760/760MP/760MPX)???
>
> You know, I'm waiting to test the AMD 750 stuff...;-)
oh .. .i'm sorry . i only asked for some prozessor and bios programming
documentation ... sorry: no chipset documentation ...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Thu, 7 Feb 2002, Wayne Whitney wrote:
> I have an ASUS A7V (KT133) motherboard, BIOS 1009, with Athlon 100MHz
> (100MHz FSB). I also find that if the PCI Master Read Caching is
> disabled in the BIOS, then the amd_disconnect kills audio playback (it
> sounds like molasses or something). There are actually three related
> BIOS options on this motherboard:
>
> System Performance: Optimal or Normal
> PCI Master Read Caching: Enabled or Disabled
> PCI Delayed Transaction: Enabled or Disabled
>
> This System Performance option is a sort of master option, setting it
> to normal forces the other two to disabled.
>
> Anyway, below are some diffs of the output of "lspci -s 0:0 -xxx".
> What is surprising to me is that setting the PCI Master Read Caching
> to Disabled changes the Northbridge settings in a way that is a
> superset of just setting PCI Delayed Transaction to Disabled.
>
> Hope this helps.
>
> Cheers, Wayne
of cause this helps ... thank you :)
we know now, that there are pci setting which affect the behavior in
relation fot audio playback.
as far as i know on some boards it could be, that the system bus hangs for
a short time, when the cpu is reconnected after a disconnect. it looks
like some caching for the pci bus could "cure" the sound skips which
happens when the system bus hangs for a short time.
so everyone who has problems with his audio and vidio playback while the
diconnect patch is active should look at his bios settings ... maybe he
could activate this pci master read cashing and his problems went away.
hmmm ... by the way: i could not reproduce your experiences, cause i have
no bios siwtch for pci master read cashing ...
oh ... and the pci delayed transaction could be dangerous on older via
chipsets cause the famous soutbridge bug in combination with an sound
blaster card. so be carefull if you have a sound blaster live ....
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]
On Fri, 8 Feb 2002, Wayne Whitney wrote:
> Well, if you have a KT133 (or even KT133A?), I provided the diffs on the
> northbridge register settings, there were only about 6 points of
> difference. So you could check how your BIOS programs them and then
> explicitly change them with setpci.
>
> Wayne
i'm sorry ... i have no kt133/kt133a chipset ... i have a kt266a chipset
... i will look whether i could fiddle out how to deactivate the pci
master read caching in my board to look whether i get the problems to.
(that is the problem: i have no problems with the patch and can't
reproduce the problems on my board ... so i can't do testing stuff to find
out how to correct the problems)...
daniel
# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: [email protected]