RE: powernow-k8 and non-standard multipliers
> I've just upgraded to an X2 5000+ black edition. This model > doesn't have a multiple lock and I tried bumping the multiplier > up, which is perfectly stable, but which causes powernow-k8 to > fail to load. I also tried with the updated patch you posted > at the beginning of october (http://lkml.org/lkml/2007/10/9/224) > which didn't make a difference. > > Is it possible to make the driver work in this situation or does > a non-standard multipler inherently mean that powernow stops > working? The standard PowerNow! driver, by design, will stop working in this situation. I'm not going to support a driver that allows non-standard multipliers because it could cause a lot of hard to debug maintenance issues. -Mark Langsdorf Operating System Research Center AMD - 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/
RE: powernow-k8 and non-standard multipliers
I've just upgraded to an X2 5000+ black edition. This model doesn't have a multiple lock and I tried bumping the multiplier up, which is perfectly stable, but which causes powernow-k8 to fail to load. I also tried with the updated patch you posted at the beginning of october (http://lkml.org/lkml/2007/10/9/224) which didn't make a difference. Is it possible to make the driver work in this situation or does a non-standard multipler inherently mean that powernow stops working? The standard PowerNow! driver, by design, will stop working in this situation. I'm not going to support a driver that allows non-standard multipliers because it could cause a lot of hard to debug maintenance issues. -Mark Langsdorf Operating System Research Center AMD - 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/
RE: [PATCH][try 2] architectural pstate driver for powernow-k8
> > Has this been tested on older implementations of powernow yet? > > I'm happy to merge this and give it some time in -mm, before it > > goes to mainline, but if no-one is testing on those older > > opterons/turions etc then we're not going to know we regressed > > until its too late. If it hasn't been tested yet, any chance > > you can scrounge some up at AMD and give it a spin just to be sure? > > > I'd like to see this driver in the next kernel release. Thanks, Andreas. > So I have done some tests with this code - based on kernel > version 2.6.23. I have tested it on Athlon 64 X2, Athlon 64, > Turion X2 and some other parts > (e.g.family 0x10) and with different cpufreq governors. > I did not observe any problems with this driver update. > Behaviour is the same as before. I've also been running it on my Turion X2 laptop for a few weeks without issues. It doesn't touch the legacy code path at all. > So please consider to add the attached patch for 2.6.24. > Patch is against current Linus' git tree. This means the patch > "[CPUFREQ] Support different families in fid/did to frequency > conversion" which is contained in the cpufreq.git should > be ommitted. The issue fixed with that patch is solved > with this driver update, too. Either patch is acceptable; I think they're fundamentally identical anyway. -Mark Langsdorf Operating System Research Center AMD - 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/
RE: [PATCH][try 2] architectural pstate driver for powernow-k8
Has this been tested on older implementations of powernow yet? I'm happy to merge this and give it some time in -mm, before it goes to mainline, but if no-one is testing on those older opterons/turions etc then we're not going to know we regressed until its too late. If it hasn't been tested yet, any chance you can scrounge some up at AMD and give it a spin just to be sure? I'd like to see this driver in the next kernel release. Thanks, Andreas. So I have done some tests with this code - based on kernel version 2.6.23. I have tested it on Athlon 64 X2, Athlon 64, Turion X2 and some other parts (e.g.family 0x10) and with different cpufreq governors. I did not observe any problems with this driver update. Behaviour is the same as before. I've also been running it on my Turion X2 laptop for a few weeks without issues. It doesn't touch the legacy code path at all. So please consider to add the attached patch for 2.6.24. Patch is against current Linus' git tree. This means the patch [CPUFREQ] Support different families in fid/did to frequency conversion which is contained in the cpufreq.git should be ommitted. The issue fixed with that patch is solved with this driver update, too. Either patch is acceptable; I think they're fundamentally identical anyway. -Mark Langsdorf Operating System Research Center AMD - 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/
RE: [PATCH] x86: limit mwait_idle to Intel CPUs
> > Commit 991528d7348667924176f3e29addea0675298944 > > introduced mwait_idle which is supposed to work > > for Intel CPUs starting with Core Duo. > > > > AMD Fam10 processors won't enter C1 on mwait. > > Unfortunate. Will this be fixed? Fam10 processors were not designed to enter C1 on mwait. That feature will not be added for Fam10 processors. -Mark Langsdorf Operating Systems Research Center AMD, Inc. - 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/
RE: [PATCH] x86: limit mwait_idle to Intel CPUs
Commit 991528d7348667924176f3e29addea0675298944 introduced mwait_idle which is supposed to work for Intel CPUs starting with Core Duo. AMD Fam10 processors won't enter C1 on mwait. Unfortunate. Will this be fixed? Fam10 processors were not designed to enter C1 on mwait. That feature will not be added for Fam10 processors. -Mark Langsdorf Operating Systems Research Center AMD, Inc. - 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/
RE: System hang on athlon64 cpufreq change
> On 3/16/07, Langsdorf, Mark <[EMAIL PROTECTED]> wrote: > > The processor is not changing frequency in response to your > > launch of mplayer. The powersave governor forces it to the > > lowest frequency regardless of system load. You really want > > to use ondemand for dynamic frequency scaling. > > > > Can you use a serial or network console to capture any messages > > the kernel is sending when mplayer starts? > > > Well, that's the point - i fix cpu speed at 1ghz and everything works > UNTIL I launch mplayer. I've just reproduced this (set governor, > launched mplayer and waited 15-20 mins) and the whole system seems > frozen - just like before. Network is down (no responses to ping). How > to redirect dmesg to serial port? (I'm running 2.6.19 kernel and > 8.34.8 fglrx driver.) My point is that is there is no cpufreq change when you start mplayer with the powersave governor. Have you disabled powernow! entirely (by removing the module) and demonstrated that mplayer works on your machine at all? To redirect the console, add console=ttyS0,115200 to your kernel command line and run a serial console from the serial port on the test machine to another machine, and then use your preferred serial port capture program (minicom or whatever) to capture the text. > Thanks and sorry for 2week delay... (btw - now it is you [ati] who is > responsible for both my cpu and gpu drivers, yes? :D) AMD bought ATI, not the other way around. That said, elements of AMD are responsible for the PowerNow! driver, and other elements of AMD are responsible for the fglrx driver. -Mark Langsdorf Operating Systems Research Center AMD, Inc. - 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/
RE: System hang on athlon64 cpufreq change
On 3/16/07, Langsdorf, Mark [EMAIL PROTECTED] wrote: The processor is not changing frequency in response to your launch of mplayer. The powersave governor forces it to the lowest frequency regardless of system load. You really want to use ondemand for dynamic frequency scaling. Can you use a serial or network console to capture any messages the kernel is sending when mplayer starts? Well, that's the point - i fix cpu speed at 1ghz and everything works UNTIL I launch mplayer. I've just reproduced this (set governor, launched mplayer and waited 15-20 mins) and the whole system seems frozen - just like before. Network is down (no responses to ping). How to redirect dmesg to serial port? (I'm running 2.6.19 kernel and 8.34.8 fglrx driver.) My point is that is there is no cpufreq change when you start mplayer with the powersave governor. Have you disabled powernow! entirely (by removing the module) and demonstrated that mplayer works on your machine at all? To redirect the console, add console=ttyS0,115200 to your kernel command line and run a serial console from the serial port on the test machine to another machine, and then use your preferred serial port capture program (minicom or whatever) to capture the text. Thanks and sorry for 2week delay... (btw - now it is you [ati] who is responsible for both my cpu and gpu drivers, yes? :D) AMD bought ATI, not the other way around. That said, elements of AMD are responsible for the PowerNow! driver, and other elements of AMD are responsible for the fglrx driver. -Mark Langsdorf Operating Systems Research Center AMD, Inc. - 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/
RE: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
> > If we really care about using the LAPIC timer on systems with deeper
> > than C1 support, the only alternative seems to be to test
> > if it actually works or not at boot and run-time.
> > Otherwise, we wait for future hardware with guaranteed
> > not to break under any (BIOS) conditions ships, and check for that.
> >
> > Based on what I read of the HP nx6325 where the LAPIC timer
> > is breaking C1, AMD is in the same boat.
>
> The nx6325 (Turion 64 X2) exports only C1.
> I'm not sure how the conclusion was drawn that it has
> a broken lapic timer as reflected in the "nolapic_timer" patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
> + /*
> +* BIOS exports only C1 state, but uses deeper power
> +* modes behind the kernels back.
> +*/
> + .callback = lapic_check_broken_bios,
> + .ident = "HP nx6325",
> + .matches = {
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP
> Compaq nx6325"),
> + },
> +},
>
> But if this is true, then I don't know how to determine on
> an AMD system if the LAPIC timer is guaranteed to work --
> even for systems with just C1.
>
> Jordan, William, can you clarify?
For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.
For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
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/
RE: [PATCH] i386: add command line option local_apic_timer_c2_ok
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the nolapic_timer patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
+ /*
+* BIOS exports only C1 state, but uses deeper power
+* modes behind the kernels back.
+*/
+ .callback = lapic_check_broken_bios,
+ .ident = HP nx6325,
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, HP
Compaq nx6325),
+ },
+},
But if this is true, then I don't know how to determine on
an AMD system if the LAPIC timer is guaranteed to work --
even for systems with just C1.
Jordan, William, can you clarify?
For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.
For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
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/
RE: System hang on athlon64 cpufreq change
> My kernel boots up with performance cpufreq governor, thus setting > frequency to 2hgz. Then I change it to powersave governor, thus > setting frequency to 1ghz just like that: > > echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > > Everything works well. Then I launch mplayer and in 1/4 - 1/5 cases > system hangs (I mean nothing works, including numlock and sysrq key). > I suspect it's something with video card driver, and here comes my > problem. I use ati's proprietary fglrx driver (i guess they may be > calibrating they own delay loop, or something, and cputfreq change > ruins it), so kernel is tainted, so you are unable to track the > problem down eh well, but i hope there is some tiny chance > there is something wrong i do, or maybe cpu doesn't like so drastic > freq changes... well, if anybody has some idea, or just experience > like mine, I ask for help. Thanks in advance. The processor is not changing frequency in response to your launch of mplayer. The powersave governor forces it to the lowest frequency regardless of system load. You really want to use ondemand for dynamic frequency scaling. Can you use a serial or network console to capture any messages the kernel is sending when mplayer starts? -Mark Langsdorf AMD, Inc. - 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/
RE: System hang on athlon64 cpufreq change
My kernel boots up with performance cpufreq governor, thus setting frequency to 2hgz. Then I change it to powersave governor, thus setting frequency to 1ghz just like that: echo powersave /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Everything works well. Then I launch mplayer and in 1/4 - 1/5 cases system hangs (I mean nothing works, including numlock and sysrq key). I suspect it's something with video card driver, and here comes my problem. I use ati's proprietary fglrx driver (i guess they may be calibrating they own delay loop, or something, and cputfreq change ruins it), so kernel is tainted, so you are unable to track the problem down eh well, but i hope there is some tiny chance there is something wrong i do, or maybe cpu doesn't like so drastic freq changes... well, if anybody has some idea, or just experience like mine, I ask for help. Thanks in advance. The processor is not changing frequency in response to your launch of mplayer. The powersave governor forces it to the lowest frequency regardless of system load. You really want to use ondemand for dynamic frequency scaling. Can you use a serial or network console to capture any messages the kernel is sending when mplayer starts? -Mark Langsdorf AMD, Inc. - 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/
RE: Slower CPU frequency reported by the kernel
> > I'm using a PC with AMD 64 3000+ cpu which is theoricaly running at > > 2Ghz. But when looking at /proc/cpuinfo, the kernel reports that it > > runs only at 1Ghz: > > ... > > What's going wrong ? > > Do you have feature called "Cool N' Quiet" enabled in BIOS? > I had the same problem and disabling the feature the problem resolved. Linux reports the frequency the processor is currently running at. Cool N' Quiet is a feature that allows the processor to run at a lower frequency and voltage when it is idle, thereby saving you power and letting your fans run slower and quieter. Don't turn it off. -Mark Langsdorf AMD, Inc. - 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/
RE: Slower CPU frequency reported by the kernel
I'm using a PC with AMD 64 3000+ cpu which is theoricaly running at 2Ghz. But when looking at /proc/cpuinfo, the kernel reports that it runs only at 1Ghz: ... What's going wrong ? Do you have feature called Cool N' Quiet enabled in BIOS? I had the same problem and disabling the feature the problem resolved. Linux reports the frequency the processor is currently running at. Cool N' Quiet is a feature that allows the processor to run at a lower frequency and voltage when it is idle, thereby saving you power and letting your fans run slower and quieter. Don't turn it off. -Mark Langsdorf AMD, Inc. - 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/
RE: Understanding cpufreq?
> These machines are running a 2.6.9-42 RHEL4 kernel with the > powernow-k8 module loaded - which I believe have backported > cpufreq support from more recent mainline kernels. To an extent. The problem is not the powernow-k8 driver, but the cpufreq infrastructure. See below. > In trying to achieve what I want, I've become rather confused > as to how cpufreq in a multi-CPU environment works: > > There is a directory under > /sys/devices/system/cpu/cpu*/cpufreq for each > CPU, which seems to imply that each CPU speed can be controlled > separately - can this really be the case? Can separate CPU > cores run at different speeds? No, but prior to 2.6.10, cpufreq discovers each core independently, and creates a directory independently. The powernow-k8 knows which cores are on the same processors, and handles them together. After 2.6.10, cpufreq understands multicore devices and creates 1 directory for the entire processor and then creates symbolic links for all the cores that share the same pstates. > e.g. I can echo 4 different governor names to the > scaling_governor file in each > /sys/devices/system/cpu/cpu[0-3]/cpufreq directory on > a 4 core machine - and the resulting scaling_cur_freq > file can contain a different value. > > However, the "cpu MHz" fields in /proc/cpuinfo are all the > same for each each CPU - I assume the values in /proc/cpuinfo > are the 'correct' values ?? > > Also, if I set all the governors to userspace, and then set > each CPU's speed via scaling_setspeed to a different > (allowed) value, then it appears quite random as to which > value is then reflected in /proc/cpuinfo i.e. sometimes > it will take the value given to CPU 0, > other times it will be CPU 1 etc. It's always the highest requested value of all cores on a processor. powernow-k8 keeps track of the requested frequencies, though, so you can have some weird situations. ie, from boot up: core0 800 MHz core1 800 MHz CPU 800 MHz core0 to 2000 MHz core1 800 MHz CPU 2000 MHz core0 2000 MHz core1 to 1800 MHz CPU 2000 MHz core0 to 800 MHzcore1 1800 MHz CPU 1800 MHz > If I set all the governors to ondemand, the CPUs will from > time to time, clock back their speed in situations where > one or more CPUs are being heavily used. i.e it appears > that each CPU is treated separately, and if > one CPU is deemed to be idle enough by its given metrics, > then it can reduce the speed of all CPUs, regardless of > other CPUs being 'busy' ... That shouldn't happen, unless ondemand requests a low frequency to all cores. > Essentially what I want to achieve is something like: > if _any_ CPU is 'busy' (usage over some threshold over > some sampling period), then run at full speed and > if _all_ CPUs are 'idle' (all below some threshold > over some sampling period) then clock back the CPUs. This should be happening automatically in RHEL4. Note that the 2.6.10 kernel changed cpufreq behavior dramatically, and now the most recent frequency request wins. -Mark Langsdorf powernow-k8 maintainer AMD, Inc. - 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/
RE: Understanding cpufreq?
These machines are running a 2.6.9-42 RHEL4 kernel with the powernow-k8 module loaded - which I believe have backported cpufreq support from more recent mainline kernels. To an extent. The problem is not the powernow-k8 driver, but the cpufreq infrastructure. See below. In trying to achieve what I want, I've become rather confused as to how cpufreq in a multi-CPU environment works: There is a directory under /sys/devices/system/cpu/cpu*/cpufreq for each CPU, which seems to imply that each CPU speed can be controlled separately - can this really be the case? Can separate CPU cores run at different speeds? No, but prior to 2.6.10, cpufreq discovers each core independently, and creates a directory independently. The powernow-k8 knows which cores are on the same processors, and handles them together. After 2.6.10, cpufreq understands multicore devices and creates 1 directory for the entire processor and then creates symbolic links for all the cores that share the same pstates. e.g. I can echo 4 different governor names to the scaling_governor file in each /sys/devices/system/cpu/cpu[0-3]/cpufreq directory on a 4 core machine - and the resulting scaling_cur_freq file can contain a different value. However, the cpu MHz fields in /proc/cpuinfo are all the same for each each CPU - I assume the values in /proc/cpuinfo are the 'correct' values ?? Also, if I set all the governors to userspace, and then set each CPU's speed via scaling_setspeed to a different (allowed) value, then it appears quite random as to which value is then reflected in /proc/cpuinfo i.e. sometimes it will take the value given to CPU 0, other times it will be CPU 1 etc. It's always the highest requested value of all cores on a processor. powernow-k8 keeps track of the requested frequencies, though, so you can have some weird situations. ie, from boot up: core0 800 MHz core1 800 MHz CPU 800 MHz core0 to 2000 MHz core1 800 MHz CPU 2000 MHz core0 2000 MHz core1 to 1800 MHz CPU 2000 MHz core0 to 800 MHzcore1 1800 MHz CPU 1800 MHz If I set all the governors to ondemand, the CPUs will from time to time, clock back their speed in situations where one or more CPUs are being heavily used. i.e it appears that each CPU is treated separately, and if one CPU is deemed to be idle enough by its given metrics, then it can reduce the speed of all CPUs, regardless of other CPUs being 'busy' ... That shouldn't happen, unless ondemand requests a low frequency to all cores. Essentially what I want to achieve is something like: if _any_ CPU is 'busy' (usage over some threshold over some sampling period), then run at full speed and if _all_ CPUs are 'idle' (all below some threshold over some sampling period) then clock back the CPUs. This should be happening automatically in RHEL4. Note that the 2.6.10 kernel changed cpufreq behavior dramatically, and now the most recent frequency request wins. -Mark Langsdorf powernow-k8 maintainer AMD, Inc. - 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/
