On Monday 24 April 2006 13:03, Mattia Dongili wrote: > On Mon, Apr 24, 2006 at 12:38:35PM -0500, anoop aryal wrote: > > On Monday 24 April 2006 12:13, you wrote: > > > Hello! > > > > > > On Mon, Apr 24, 2006 at 01:51:09AM -0500, anoop aryal wrote: > > [...] > > > > But do really the Duo processor can swith frequencies independently for > > > the 2 cores? > > > Just for the records, could you send the output of cpufreq-info? > > > > it looks like it. at least under /sys there are cpu0 and cpu1 directories > > with what looks like independent settings. let me know if you want me to > > try > > Yes, but it's the affected_cpus thing which matters here (as you already > figured) > > > something specific to figure out for sure. > > > > ----------- cpufreq-info output > > cpufrequtils 001: cpufreq-info (C) Dominik Brodowski 2004-2006 > > Report errors and bugs to [EMAIL PROTECTED], please. > > analyzing CPU 0: > > driver: centrino > > CPUs which need to switch frequency at the same time: 0 > > hardware limits: 1000 MHz - 2.00 GHz > > available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz > > available cpufreq governors: ondemand, performance > > current policy: frequency should be within 1000 MHz and 2.00 GHz. > > The governor "ondemand" may decide which speed to use > > within this range. > > current CPU frequency is 1000 MHz (asserted by call to hardware). > > analyzing CPU 1: > > driver: centrino > > CPUs which need to switch frequency at the same time: 1 > > hardware limits: 1000 MHz - 2.00 GHz > > available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz > > available cpufreq governors: ondemand, performance > > current policy: frequency should be within 1000 MHz and 2.00 GHz. > > The governor "ondemand" may decide which speed to use > > within this range. > > current CPU frequency is 1000 MHz (asserted by call to hardware). > > ----------- end cpufreq output > > > > i have had cpu0 in ondemand and cpu1 in performance before i tried fixing > > it. so i guess you can do it independently. > > wow. Here's an small insight on the possibilities: > http://marc.theaimsgroup.com/?l=linux-kernel&m=114308539123334&w=2 > > I think Duo's fall in case #2. > > [...] > > > ------- start > > # cpufreq-info -a > > 0 > > -------- end > > > > prints just '0' by it's lonesome. does that mean that only cpu0 can be > > changed? > > > > -------- start > > # cpufreq-info --cpu 0 -a > > 0 > > #cpufreq-info --cpu 1 -a > > 1 > > -------- end > > [...] > > > i'm not sure it's related > > but /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus had '1' and the > > corresponding file in cpu0 has '0' > > yes, that's what cpufreq-info reads :) > > > > for cpu in $(cpufreq-info -a | xargs echo) ; do > > given the above this line is not enough to loop through all available > cpus. > > [...] > > > > Anyway the issue remains, can you test (and fix eventually :)) the code > > > I provided? > > > > yeah. more than happy to do it for you. i'll try it in the evening and > > send you the results. > > hmmm... don't bother to try it, it's clearly bugged. > > I'd say thing are getting too complex for such a stupid shell script. > I'm thinking of some different approach: > > 1- provide per-cpu variables in /etc/defaults/cpufrequtils, eg: MAXFREQ0 > MAXFREQ1 and so on
as i said in my earlier email, independent settings for each core doesn't sound that appealing to me. i can't think of any good reason to have the two cores operating at different speeds even if it were possible. > > or > > 2- provide a CPUS="0 1" variable in /etc/... to tell the script which > cpus the user wants to change at boot time i understand that in other cases things might be different but in my case, i would like both the cores running at the same speed - the min possible with ondemand so that it ramps up to max if i'm compiling stuff. since it's really not an 'option' as to which CPUs to change, i don't see those being configuration option. the configuration file in /etc/default/cpufreqtutils is fine. > > or > > 3- really implement that complex logic: read how many cpus (even an ls > on /sys/devices/system/cpu/ could suffice) and for each cpu check if it > has to be set (cpufreq-info -a -c $cpu) or if it was already affected by > a previous change, based on that run cpufreq-set this sounds the most attractive. altho i don't see a need for checking to see if those options need setting. just go ahead and set them. > > Ideas from a user perspective? summry: the config file seems fine the way it is. i really don't see setting individual CPU cores to different speeds/governors. in fact, it seems that it's undesirable in my case - i have explained the reasons in my earlier email. if the script could pick up the different cpus and then apply the settings, it would work very well in my case. the script doesn't need to try and determine if the settings have already been applied. just go ahead and apply the setting - can't see any harm being done by re-applying the settings. i'm putting in the patch i had sent to you earlier with your suggested changes for the RETVAL. i think that is exactly what i want. you might want to tweak the detection of the different CPUs as you mentioned but it also works the way it is - at least on my system. btw, KDEs acpi stuff also only sets one core. and since the other defaults to performance and since the Duo falls under category 2, the result is not what i want - both cores running at the higher of the two speeds. so i will be using cpufrequtils with the patch for Duo core. let me know if you need me to try something out. > > > sorry about sending it twice. forgot to hit reply-to-all. > > don't worry, thanks for keeping the bug address :) > > Thanks -- anoop aryal [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]