Porteus-v2.0-i486 bug reports

[mcewanw]

CPUFREQ scaling not working for me.

I'm using the Razor-qt desktop standard version of Porteus ver 2 on an old Pentium-M machine (1 GB RAM). First, I would like to comment that Porteus is very nice so I'm putting some effort into tailoring it for my system since I plan to keep it on here.

The only problem I'm having at the moment is that I can't get cpufreq scaling working on demand (same machine running other small Linux is able to step from between 600,000 Hz and 1,600,000 Hz using ondemand cpufreq governor, but on Porteus, no matter what I've tried, it is sticking at 1,600,000 Hz and I like to keep temperature of the system in better control via ondemand). Note that this machine is an old laptop running on AC power (the battery being long dead).

I checked out older forum post on similar problem in Porteus v2 RC1, and, as advised there, edited /etc/laptop-mode/conf.d/cpufreq.conf file and changed every 'CPU_GOVERNOR=performance' to 'CPU_GOVERNOR=ondemand'. NOTE: that I did find one instance of GOVERNOR spelt wrongly in that file as GOVRNOR (missing 'E'), but changing that didn't help. On reboot, I checked /sys/devices/system/cpu/cpu0 folder and found that the governor remained as "performance" with current freq remaining at the maximum 1,600,000.

Don't know if it is relevant, but I noted that /lib/modules/3.7.8-porteus/modules.builtin listed cpufreq_performance.ko but not cpufreq_demand.ko. Anyway, in case that was the issue, I created the file /etc/rc.d/rc.modules and put the entry "modprobe cpufreq_ondemand" in there. On reboot, /sys/devices/system/cpu/cpu0/scaling_governor now said "ondemand" was now active, but alas the scaling_cur_freq never varied from the max 1,600,000 figure. Nevertheless, according to lsmod, the modules cpufreq_ondemand, and acpi_cpufreq had both successfully loaded.

Anyway, thanks for any help you can give.

[fanthom]

hello mcewanw,

please link here 'Porteus System Info' report (run xpsinfo in cli or through Porteus System Centre) which should tell me why your CPU does not scale.
will fix 'GOVRNOR' for next release - thanks.

EDIT:\\
please also show me output of following commnd:

Code: Select all

ls /sys/devices/system/cpu/cpu0/cpufreq | xargs cat

[mcewanw]

EDIT. Sorry, didn't notice I was supposed to link to pastebin rather than putting the requested debug info directly here.

Hope this works. I haven't used pastebin before. Here is the cpufreq scaling results you requested:

http://pastebin.com/eSRHmsex

[mcewanw]

The above results are from immediately after reboot, so very light system load. When I'm running Puppy Slacko 5.3.3 on the same machine with the ondemand governor the scaling_cur_freq is usually the minimum (600,000) unless I'm doing something that requires some CPU power (such as video watching). As you should see, on Porteus v2, (following changing "performance" to "ondemand" in /etc/laptop-mode/conf.d/cpufreq.conf and adding entry "/etc/rc.d/rc.laptop-mode restart" into rc.local and entry "modprobe cpufreq_ondemand" into /etc/rc.d/rc.modules and then rebooting) although the stats say scaling_governor is ondemand the scaling_cur_freq seems stuck at the CPU max freq of 1,600,000

[fanthom]

everything looks ok to me.
available frequencies are listed correctly so i dont know why CPU does not scale. are you sure there is no background process eating your CPU?
please run 'top' in terminal along with watching current CPU frequency.

please also upload full xpsinfo report as maybe there is some info in /var/log/messages which could tell us the reason (more than likely a kernel bug).

[mcewanw]

Running top suggests CPU is pretty much idle. Under these conditions please find my xpsinfo report via pastebin link below:

http://pastebin.com/GKZDPNn4

[fanthom]

@mcewanw
nothing suspicious in the log files.

puppy slacko uses older kernel (3.2.x) so maybe you could use 3.4.9 kernel from porteus-1.2 (vmlinuz and 000-kernel.xzm is enough):
http://ponce.cc/porteus/i486/archive/Po ... inux-3.4.9
and check if that solves your issue.

[Rava]

ls /sys/devices/system/cpu/cpu0/cpufreq | xargs cat gives me:

Code: Select all

cat: affected_cpus: No such file or directory
cat: bios_limit: No such file or directory
cat: cpuinfo_cur_freq: No such file or directory
cat: cpuinfo_max_freq: No such file or directory
cat: cpuinfo_min_freq: No such file or directory
cat: cpuinfo_transition_latency: No such file or directory
cat: related_cpus: No such file or directory
cat: scaling_available_frequencies: No such file or directory
cat: scaling_available_governors: No such file or directory
cat: scaling_cur_freq: No such file or directory
cat: scaling_driver: No such file or directory
cat: scaling_governor: No such file or directory
cat: scaling_max_freq: No such file or directory
cat: scaling_min_freq: No such file or directory
cat: scaling_setspeed: No such file or directory

I also get errors when closing the laptop lid or when it c comes to throttle the CPU, but dunno how to run similar checks as above...

[fanthom]

@Rava
my fault, this command should look like:

Code: Select all

cd /sys/devices/system/cpu/cpu0/cpufreq && ls | xargs cat

please post the errors you get regarding laptop lid and CPU throttling.

[mcewanw]

@mcewanw
nothing suspicious in the log files.

puppy slacko uses older kernel (3.2.x) so maybe you could use 3.4.9 kernel from porteus-1.2 (vmlinuz and 000-kernel.xzm is enough):
http://ponce.cc/porteus/i486/archive/Po ... inux-3.4.9
and check if that solves your issue.

I had already tried Porteus v1.2 itself, but cpufreq scaling didn't work from there on this machine either. It does seem likely to be a kernel issue. If I find anything further I'll report back. It isn't a huge issue. The machine is running reasonably well with Porteus v2.0 otherwise anyway. I will however also try the distribution on one of my other laptops.

[Rava]

Okay, so here the update:

Code: Select all

root@porteus:/mnt/# cd /sys/devices/system/cpu/cpu0/cpufreq && ls | xargs cat
0
800000
800000
1200000
800000
10000
0
1200000 800000 
performance 
800000
acpi-cpufreq
performance
800000
800000
<unsupported>

And the errors I mentioned from /var/log/messages:

Code: Select all

porteus logger: ACPI group processor / action LNXCPU:00 is not defined
porteus logger: ACPI action lid is not defined

[mcewanw]

@mcewanw
nothing suspicious in the log files.

puppy slacko uses older kernel (3.2.x) so maybe you could use 3.4.9 kernel from porteus-1.2 (vmlinuz and 000-kernel.xzm is enough):
http://ponce.cc/porteus/i486/archive/Po ... inux-3.4.9
and check if that solves your issue.

Though freq scaling is not working to my satisfaction with the ondemand governor, I seems to be working with the 'conservative' governor, which I simply activated from a terminal with the following command:

Code: Select all

cd /sys/devices/system/cpu/cpu0/cpufreq && echo conservative > scaling_governor

lsmod revealed that the cpufreq_conservative driver automatically loaded after doing that.

As an alternative, I was also able to automate this by editing /etc/laptop-mode/conf.d/cpufreq.conf and changing default references of governor 'performance' to 'conservative', but I also needed to add the following entry to /etc/rc.d/rc.local:

Code: Select all

/etc/rc.d/rc.laptop-mode restart 

[Rava]

Code: Select all

@porteus:/mnt/live/memory/images$ ls 002-xorg.xzm/usr/share/man/man3/
drmAvailable.3  drmHandleEvent.3  drmModeGetResources.3

Dunno if that is also the case in x86-64 version... but it should be all fixed for 2.1 Porteus.

Also, rpm2txz and rpm2xzm should be updated to not add any man pages in /usr/share/man/man?/ bit instead in /usr/man/man?/

As you can see here

Code: Select all

WARNING:  /usr/share/man (with possibly not gzipped man pages) detected

Slackware package /mnt/sda1/bin/btar-1.1.1-1.20.x86_64.txz created.

the rpm2txz (and since rpm2xzm runs rpm2xzm, it could be tweaked to detect it as well... ) does indeed detect if there are man pages at the wrong place, it just doesn't correct the error...

(In case you might wonder: I was creating the i586 and x86-64 modules while running i586 / i486 Porteus.)

Also, rpm2xzm should be updated to gunzip the man-pages prior creating the module...

[fanthom]

@Rava
updated txz2xzm - thanks.

[Rava]

updated txz2xzm - thanks.

Yay! Is it available online so that it can be used with 2.0 finale and 2.1 rc1? Me thinks it not differs between 32 and 64 bit, or does it?