Make bus substitution optional#11
Conversation
Bus substitution is not implemented for most buses for which it is currently required: I²C is supported, but SPI, HID and SCSI are not. Trying to rename the temperature sensor from a specific hard drive with: chip "drivetemp-scsi-0-0" label temp1 "Samsung 840 EVO" currently results in: Error: [...]: Undeclared bus id referenced sensors_init: Can't parse bus name While bus substitution should still be implemented for these missing buses, it may also be overkill in a lot of scenarios. Like the example above (drivetemp chips), assuming a typical and fairly stable hardware configuration. To simplify things, make bus substitution optional, and allow users to configure their system directly with bus numbers, even if they might be unstable. Related: lm-sensors#230 ("cannot label 'drivetemp' sensors - bus handling for scsi busted?") Related: lm-sensors#369 ("Undeclared bus id referenced")
|
Unfortunately, specifically for SCSI the bus number is very much unstable so long as you have more than one SCSI host. |
|
Do you have any suggestions on how we could handle/improve this? On the one hand, bailing out as lm-sensors currently does just breaks things even when bus numbers are enough. On the other, maybe making (the promise that) bus substitution (has become) optional might be a step too far. Maybe we could still report it as an error or unstable feature, just not bail out when substitution isn't implemented for the bus. I mean, actually implementing substitution for HID, SPI and SCSI would be ideal, but, while it has been a looong time since I looked into it (the original PR was opened on 2021), I vaguely remember it not being an easy problem. |
|
Not really. If sensors do not bail out people will complain that their sensors reports something different on every boot. SPI would likely be fine if only built-in but we now also have USB SPI controllers. |
|
USB is generally quite stable unless you physically connect that the device to a different port, which is not a normal use case for HWMON. Not sure about USB SPI controllers specifically, though. |
|
Hm, I just remembered: I actually rename 4 drive sensors using this patch, and haven't seen their SCSI bus numbers change. I'm not saying they can't change, of course they can, but maybe it isn't as common as you think, at least on some hardware configurations. On the other hand, is lm_sensors useful today, without this patch, in systems with more than one drive? I mean, other than for displaying the data form |
|
What about a command-line option to enable incomplete-but-good-enough implementations like this? Not reporting anything is worse than reporting that drives are too hot. |
|
To add another data point about forced bus substitution being detrimental in some cases, on my motherboard with 4 DDR5 channels (config: https://gist.github.com/kotarou3/d2cdf50286b96d45c17e3ea39ac2d673#file-asus-trx50-sage-wifi-sensors-conf-L70-L78) All 4 sensors are named exactly the same, so it would be impossible to use bus substitution as currently implemented: The only way for me to add these sensors is to include this patch so I can match on the bus number directly, which is stable for this board |
8a41efc to
0b5fc76
Compare
3ba5942 to
cb9a02a
Compare
Hi,
I see that Arch and OpenSUSE are currently using this repository as upstream for lm_sensors.
This is a patch I've made and been using for quite a few years now, that fixes an "Undeclared bus id referenced" issue when trying to specify a HID/SCSI/etc. device in a config file.
From the original PR lm-sensors#371 ("Make bus substitution optional") on the old/previous upstream repository:
Bus substitution is not implemented for most buses for which it is currently required: I²C is supported, but SPI, HID and SCSI are not. Trying to rename the temperature sensor from a specific hard drive with:
currently results in:12
While bus substitution should still be implemented for these missing buses, it may also be overkill in a lot of scenarios. Like the example above (drivetemp chips), assuming a typical and fairly stable hardware configuration.
To simplify things, make bus substitution optional, and allow users to configure their system directly with bus numbers, even if they might be unstable.
Also note that it is probably more common for multiple hard drives or HID cooling devices of the same model to be present in a system. This means that, in order for bus substitution to be useful for buses like SCSI and HID, it would need to be implemented using unique device identifiers. And not all "serial numbers" reported by devices in the wild are truly unique; in the case of HIDs, manufacturers sometimes omit or repurpose the serial number descriptor.
Footnotes
cannot label 'drivetemp' sensors - bus handling for scsi busted? lm-sensors/lm-sensors#230 ↩
(With HID devices:) Undeclared bus id referenced lm-sensors/lm-sensors#369. ↩