I suspect that sometimes the order of setting parameters may get in the way. If you comment out everything in that script and run the commands by hand in exactly that order does anything fail or change?
Try removing the -e from the first line. That causes the script to exit immediately on a first error. I think that e.g. trying to put a core online with the echo command returns an error if it’s already online.
thanks, that helped, made it further. (edit: this post is response to linuxdev.)
i did get an error from manually setting cpu0 online. i removed all four of those lines, they don’t seem to make a helpful difference. something else is forcing them all online.
even after successfully setting the scaling_governor, it is falling back to “interactive” anyway. however, the CPU frequency is staying maximized.
at this point i have one command to run manually, which is the last one, line 20 below.
swapping the order of lines 19 & 20 made no difference. calling a bash script (without -e flag) for those two lines made no difference. i had used echo commands directed to a log file so as to find how far rc.local made it.
As mentioned by kulve, you will get errors when you try to set some items to a state they are already in, e.g., cpu0 when you are poking around in a shell will always be online, also during boot; trying to set it online when it is already online returns an error. The acid test for results is actually testing online status before and after the script is complete.
I have not experimented with clock rates, but I’ve seen various people comment that there are often restrictions on various clock rates which might change depending on other setup…the available rates can be a moving target. On my system, I tried echo of “performance” to scaling_governor, and it stayed where it should be. However, if you look at the Jetson performance article on eLinux.org, you’ll see that manually setting a clock rate requires “userspace”, not “performance”. It seems logical that when the governor and clocks are told something incompatible, e.g., performance mode with a clock being overridden, that one of those two parameters will have to be forcibly set by the system to something other than what was requested.
In general terms of I/O errors, some parameters are read-only or write-only and may be the cause. Trying to set a cpu to online when it is already online might cause this when run from a script.
i found i don’t need to set cpu online in that the tegra_cpuquiet setting is doing that job behind the scenes. i get all four online with that. as well, the “G”, the general cluster is active.
i have tried the “userspace” setting, it’s in my rc.local now.
it has not changed the result with GPU clock override, i.e. i still have to manually set the state. both those lines still produce errors when run from rc.local. the two files are writable by root (file mode 644).
in this configuration, scaling_governor still falls back to “interactive” and cpuinfo_cur_freq will move around and definitely hit the max setting with sufficient load on the system.
overall it seems i’m getting the exact same result whether i set scaling for performance or userspace. my “load test” of doing a video conversion completes in about the same time. this is after manually setting the GPU clock override in all cases.
i would still like to get the final piece done properly.