3

I was stuck when trying to write to a system file to change the cpu frequency:

$ cat   /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
<unsupported>

$ echo 1600000 | sudo tee  /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
1600000
tee: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed: Invalid argument

Changing user to root has the same problem:

$ sudo su
# echo 1600000 >   /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
bash: echo: write error: Invalid argument

The following should probably be unrelated. Previously, the above commands all worked, but then my Ubuntu was frozen an hour ago when I plug the usb plug of my laptop cooler into one usb port of my laptop, so I had to reboot it by hitting the power button of my laptop, and then I have the above problem.

Previously when it worked, cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed output some value instead of <unsupported>. After trying many times with the above invalid argument error, now I just ran echo 1600000 | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed once again, and it works without the invalid argument error. Around the same time, ubuntu reported some cpu frequency utility error, which I don't remember exactly.

Gilles 'SO- stop being evil'
  • 829,060
Tim
  • 101,790

1 Answers1

3

The files in sysfs and procfs are interfaces to the kernel. Reading and writing to these files invokes code in a driver in the kernel. If you get the error “permission denied” (EACCESS), that comes from the file permissions. But if you get an error such as “invalid argument” (EINVAL), it means the driver sent this reply.

The most obvious reason for “invalid argument” is that you're trying to write a value that isn't valid. For example, writing something that isn't a number to modify a numeric setting, or writing a number that's out of the acceptable range.

Given that reading returns the string <unsupported>, at that time on your machine, the driver thought that your hardware did not support this feature. Since it worked previously, this indicates either a bug in the driver or a hardware failure.

You've indicated that it now works again. So it was a transient problem that rebooting fixed. The rest of my answer is advice for people who have just been confronted with a similar problem.

If you upgraded your kernel recently, try reverting to the previous version.

Since the problem is in the kernel, or at least between the kernel or the hardware, you need to dig into the kernel logs to find more information. On a recent enough system with systemd, run sudo journalctl -k to see the kernel logs. Alternatively, look at /var/log/kern*, which includes older saved logs.

Finding the right log message can be difficult. If you can find the approximate time things started, look for log messages around that time. Try accessing the file in /sys now, this may or may not generate a new log message each time depending on how the driver works.

If you had some hardware related failure and rebooted, some firmware (software running on one of the auxiliary chips on the computer) may still have bad data. To completely reset all the firmware to its power-on state, you need to power the system down completely. On a laptop, sometimes it's even necessary to disconnect the power completely (take out the plug to the mains and the battery, then put them back).

Gilles 'SO- stop being evil'
  • 829,060