Assistance Fixing Bug #5265

Status
Not open for further replies.

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
I am trying to track down when and where the sysctls from the GUI are overwritten during boot, but I'm not having much luck. dmesg -a shows them successfully set by /etc/rc.d/sysctls, but then nothing afterwards that clearly unsets them. I tried looking under the hood a little, but I'm no BSD expert. If anyone could point me in the right direction it would be helpful. I wish there was a way to watch a sysctl the way you can watch a variable in a debugger, or maybe there is.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
It's explained in 5265; the values are getting stomped by later rc scripts. You are invited to go to "Tasks->Init/Shutdown Scripts->Add Init/Shutdown Scripts" and add a sysctl command manually using "When" -> "Post Init". I am 98.23% certain that this will run after the problematic scripts but haven't actually looked, so don't blame me if I'm wrong. :smile:
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
"later rc scripts" doesn't identify which script, and what specifically is "stomping" it.

I am looking to fix the actual bug and submit a patch. I already have the post-init scripts set on my box.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
The bug discusses an issue with a sysctl that includes the string "cx_lowest". One might search for that like so:

Code:
# find /etc -type f -print0 | xargs -0 grep cx_lowest


Note that's print-zero and dash-zero, not Oh-the-lettwe.
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
Duh. I don't know why I just spent 20 minutes looking through startup scripts, and even using grep, without thinking to grep the whole directory. Thanks for the needed kick in the head.

Probably right here:

/etc/defaults/rc.conf: performance_cx_lowest="HIGH"
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
No kick intended. I spend a lot of my life searching for the WTFWHEREISITGETTINGTHATFFFFFFFINTHINGWTFWTFWTF!!!!!!?!?!

:smile: Yell if you get stuck. Pushes in the right direction are free. But it doesn't sound like iX is willing to repair the issue, maybe even if someone hands them a well-designed patch. That's why I suggested the stsrtup script approach.
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
I wonder what the logic of this node in /etc/rc.d/power_profile is:

# Set the various sysctls based on the profile's values.
node="hw.acpi.cpu.cx_lowest"
highest_value="C1"
lowest_value="Cmax"
eval value=\$${profile}_cx_lowest
sysctl_set


Why would anybody bothering to enable powerd want this?
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
Knowing that this may have been set elsewhere, wouldn't it make more sense to do something like this?

# Set the various sysctls based on the profile's values.
node="hw.acpi.cpu.cx_lowest"
highest_value="C1"
lowest_value="`(sysctl -n dev.cpu.0.cx_supported | awk '{ print "C" split($0, a) }' -) 2> /dev/null`"
eval value=\$${profile}_cx_lowest
sysctl_set
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
It is overly elegant shell scripting that's probably been designed to handle a bunch of different cases, and figuring out the why and how is usually a real pain in the arse. The commit logs over at FreeBSD.org and/or actually talking with the committers responsible are sometimes the only way to learn the how and why. I usually just sit down and start tracking what is going on until it makes sense.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Knowing that this may have been set elsewhere, wouldn't it make more sense to do something like this?

# Set the various sysctls based on the profile's values.
node="hw.acpi.cpu.cx_lowest"
highest_value="C1"
lowest_value="`(sysctl -n dev.cpu.0.cx_supported | awk '{ print "C" split($0, a) }' -) 2> /dev/null`"
eval value=\$${profile}_cx_lowest
sysctl_set

Possibly not; I think the usual assumption is that the rc scripts (and rc.conf/rc.conf.local/etcetera) are the definitive source of configuration for those areas of the system that they address, which is why there are usually so many flags, variables, etc., which can be set in rc.conf.

So.... many... variables...
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
And by that I mean that that's how it works in FreeBSD, not FreeNAS, but FreeNAS inherits all the scripts and framework.
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
Perhaps it would be better just to check if dev.cpu.n.cx_lowest already exists, and just bypass that whole node if it does. I think it makes sense that any explicitly set variable should override a default.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
That doesn't make sense within the sysctl framework, where there's no way to identify what might be "explicitly set" and what it would have been explicitly set by. Type "sysctl -a". Most of those are defaults, computed defaults, etc.
 

FreeNASBob

Patron
Joined
Aug 23, 2014
Messages
226
Well, then we're back to the question about why the power profile is setting the CPU to have no power management. That has to be a typo.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Probably because some prerequisite isn't fulfilled correctly.
 
Status
Not open for further replies.
Top