search

Meliox / PVE-mods

Proxmox modifications
198 stars 14 forks source link

freeimpi fan control and more? #60

Open divStar opened 2 weeks ago

divStar commented 2 weeks ago

First of all: thank you very much for building these scripts!

Is your feature request related to a problem? Please describe. I have the ASRockRack W680D4U-2L2T/G5 motherboard and I am running Proxmox on it. Long story short: the default NCT6798D chip does not deliver fan speeds along with quite a bunch of other stuff. Manually enabling the kernel module doesn't help - most if not all of the relevant values are broken.

A proper IPMI driver is also not found by lm-sensors / sensors.

Describe the solution you'd like Use freeipmi - or rather: ipmi-sensors - to retrieve RPM values of the fans. I am not sure how to go about the configuration though. Alternatively ipmitool could be used, but in my experience so far (though I only tried it on this one motherboard) it's every so slightly slower.

Describe alternatives you've considered I considered making a separate script rather than modifying pve-mod-gui-sensors.sh, but I feel it would be a better idea to include it in the original script, because one really would only need any values from ipmi-sensors if the regular sensors did not manage to deliver them for whatever reason.

Additional context None yet, but I can expand and perhaps I could even help with a PR if you would consider the PR to be merged.

Sensors output

ipmi-sensors output ```shell root@pve:~# ipmi-sensors ID | Name | Type | Reading | Units | Event 1 | VOLT_3VSB | Voltage | 3.33 | V | 'OK' 2 | VOLT_5VSB | Voltage | 5.05 | V | 'OK' 3 | VOLT_CPU_VCORE | Voltage | 0.68 | V | 'OK' 4 | VOLT_VCCIN_AUX | Voltage | 1.78 | V | 'OK' 5 | VOLT_VDD2 | Voltage | 1.10 | V | 'OK' 6 | VOLT_1.05V_PCH | Voltage | 1.04 | V | 'OK' 7 | VOLT_0V82SB_PCH | Voltage | 0.82 | V | 'OK' 8 | System Event | System Event | N/A | N/A | 'OK' 9 | VOLT_1V8SB | Voltage | 1.78 | V | 'OK' 10 | VOLT_VCCSA | Voltage | 0.90 | V | 'OK' 11 | VOLT_BAT | Voltage | 3.12 | V | 'OK' 12 | System Event Log | Event Logging Disabled | N/A | N/A | 'OK' 13 | VOLT_3V | Voltage | 3.27 | V | 'OK' 14 | VOLT_5V | Voltage | 4.95 | V | 'OK' 15 | VOLT_12V | Voltage | 12.20 | V | 'OK' 16 | VOLT_PSU1_VIN | Voltage | N/A | V | N/A 17 | VOLT_PSU2_VIN | Voltage | N/A | V | N/A 18 | CUR_PSU1_IOUT | Current | N/A | A | N/A 19 | CUR_PSU2_IOUT | Current | N/A | A | N/A 20 | TEMP_CPU | Temperature | 28.00 | C | 'OK' 21 | FSC_INDEX | Temperature | 28.00 | C | 'OK' 22 | TEMP_MB | Temperature | 33.00 | C | 'OK' 23 | TEMP_CARD_SIDE | Temperature | 33.00 | C | 'OK' 24 | TEMP_X710 | Temperature | 30.00 | C | 'OK' 25 | TEMP_VR | Temperature | 31.00 | C | 'OK' 26 | TEMP_PSU1 | Temperature | N/A | C | N/A 27 | TEMP_PSU2 | Temperature | N/A | C | N/A 28 | TEMP_TR1 | Temperature | N/A | C | N/A 29 | TEMP_M.2 | Temperature | 38.00 | C | 'OK' 30 | FAN1 | Fan | N/A | RPM | N/A 31 | FAN2 | Fan | N/A | RPM | N/A 32 | FAN3 | Fan | N/A | RPM | N/A 33 | FAN4 | Fan | N/A | RPM | N/A 34 | FAN5 | Fan | N/A | RPM | N/A 35 | FAN6 | Fan | 2200.00 | RPM | 'OK' 36 | FAN7 | Fan | 2200.00 | RPM | 'OK' 37 | PWR_PSU1_PIN | Power Supply | N/A | W | N/A 38 | PWR_PSU2_PIN | Power Supply | N/A | W | N/A 39 | PSU1_FAN | Fan | N/A | RPM | N/A 40 | PSU2_FAN | Fan | N/A | RPM | N/A 41 | PWR_PSU1_POUT | Power Supply | N/A | W | N/A 42 | PWR_PSU2_POUT | Power Supply | N/A | W | N/A 43 | ChassisIntr | Physical Security | N/A | N/A | 'OK' 44 | CPU_PROCHOT | Processor | N/A | N/A | 'OK' 45 | CPU_THERMTRIP | Processor | N/A | N/A | 'OK' 46 | STS_PSU1 | Power Supply | N/A | N/A | 'OK' 47 | STS_PSU1_AC_LOST | Power Supply | N/A | N/A | N/A 48 | STS_PSU1_VOUT_OV | Power Supply | N/A | N/A | N/A 49 | STS_PSU1_IOUT_OC | Power Supply | N/A | N/A | N/A 50 | STS_PSU2 | Power Supply | N/A | N/A | 'OK' 51 | STS_PSU2_AC_LOST | Power Supply | N/A | N/A | N/A 52 | STS_PSU2_VOUT_OV | Power Supply | N/A | N/A | N/A 53 | STS_PSU2_IOUT_OC | Power Supply | N/A | N/A | N/A 54 | STS_PSU1_Fan | Power Supply | N/A | N/A | N/A 55 | STS_PSU2_Fan | Power Supply | N/A | N/A | N/A 56 | WATCHDOG2 | Watchdog 2 | N/A | N/A | 'OK' 66 | CPU_CATERR | Processor | N/A | N/A | 'OK' ```
Meliox commented 2 weeks ago

Hello! Thanks and you're welcome. Interesting problem. My fans are actually not showing in sensors as well, yet I found a workaround by using another id e.g. modprobe it87 force_id=0x8620 && /etc/init.d/kmod start. But that's maybe not the issue here.

Going back to ipmi. I tried to install it, but kept on getting the following error:

root@pve:~# ipmi-sensors
Caching SDR repository information: /root/.freeipmi/....
ipmi_sdr_cache_create: internal IPMI error

During the investigation of the issue, I found several comments mentioning that it requires that the motherboard supports ipmi. That it is a feature that is only available on enterprise/server grade hardware. Looking up your motherboard, IPMI is mentioned as a feature. So that could confirm my assumption. If that is a correct assumption, that means all the current users of the scripts are using consumer hardware and that also implies it's not an either or case. Both ways of retrieving data must be working.

The output of ipmi-sensors is also quite different, though much easier to parse. The current parser is for json and I don't find a json output mentioned in their docs: https://www.gnu.org/software/freeipmi/manpages/man8/ipmi-sensors.8.html. In order words quite much code needs rewriting to keep support for both sensors programs. Coding everything in one bash script may be too much and it could be more simple to have two separat scripts.

@eremem I'd like get your view on this as well. Thanks.

eremem commented 2 weeks ago

@Meliox based on your analysis the support for IPMI with all of the adjustments/changes that would be required in the current solution seems not really to be the justified development direction. As you wrote, we would need a converter for the output data. Ideally we could come up with some intermediate format which we could also use for the sensors output to be able to handle the readings in a unified way for further processing, regardless of their actual source. This is not trivial and should also be efficient since this had to be executed repeatedly. I'm not quite sure but I wouldn't also consider using both tools on the same system at the same time as a use-case, so a separate script/project, if anything, seems a better/logical solution to me.

divStar commented 2 weeks ago

So I suppose if we could have some sort of plugin-like architecture where there are data sources (e.g. sensors and possibly ipmi-sensors), which collect and update the sensor values, yet all the values are then written into some sort of intermediate JSON, that is then accessed via the frontend - that would help getting all values, right?

Also I'd like to argue in favor of using both "data sources" at the same time, but their update intervals would most likely differ due to IPMI making requests to the IPMI/BMC rather than just reading raw chip values (like e.g. sensors does for NCT6788D normally when it's supported).

eremem commented 2 weeks ago

So I suppose if we could have some sort of plugin-like architecture where there are data sources (e.g. sensors and possibly ipmi-sensors), which collect and update the sensor values, yet all the values are then written into some sort of intermediate JSON, that is then accessed via the frontend - that would help getting all values, right?

This could be a possible approach but it would also mean that the current "architecture" had to be fundamentally reworked and the whole solution would most likely have to be incomparably more complex.

Also I'd like to argue in favor of using both "data sources" at the same time, but their update intervals would most likely differ due to IPMI making requests to the IPMI/BMC rather than just reading raw chip values (like e.g. sensors does for NCT6788D normally when it's supported).

Yes, I can also see both tools used in tandem for providing sensor readings. I would expect though that both programs (as soon as they can read anything usable) provide redundant rather than complementary information.