sch5627 on Fujitsu Celsius W280
A message that is not in the archive (sent off-list or not yet received): [email protected]
Guenter Roeck
maintainerQuoted 6 lines · Ian Nartowicz
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that hardware monitoring was gone. Was working in 5.10. When I added it to the
dmi_override_table, it started working again (with a slightly different device name). dmidecode shows it as an on board device, type other, status disabled (just the watchdog?), and description "SMsC SuperI/O".
Weird, this is the second private e-mail I get in a single day. Is there some information out there suggesting that kernel maintainers should be contacted without copying the mailing list ? If so, tell them it is wrong. As warning to everyone, I won't reply any further to private e-mails like this.
Looking at the code, try adding ignore_dmi=1 as module parameter when loading the driver. I think commit 393935baa45e5c messed it up and prevents the driver from loading if the parameter is not provided. Maybe the conditions in sch56xx_init() are wrong or too generic. Armin, any comments ? Do we need to revert your patch ?
Guenter
Am 24.10.23 um 16:48 schrieb Guenter Roeck:
Quoted 17 lines · Ian Nartowicz
Quoted 9 lines
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that hardware
monitoring was gone. Was working in 5.10. When I added it to thedmi_override_table, it started working again (with a slightly different device
name). dmidecode shows it as an on board device, type other, status disabled
(just the watchdog?), and description "SMsC SuperI/O".Weird, this is the second private e-mail I get in a single day. Is there some information out there suggesting that kernel maintainers should be contacted without copying the mailing list ? If so, tell them it is wrong. As warning to everyone, I won't reply any further to private e-mails like this.
Quoted 8 lines
Looking at the code, try adding ignore_dmi=1 as module parameter when loading the driver. I think commit
393935baa45e5cmessed it up and prevents the driver from loading if the parameter is not provided. Maybe the conditions insch56xx_init()are wrong or too generic. Armin, any comments ? Do we need to revert your patch ?Guenter
I think so, it seems that the DMI devices are not always present. We better revert the DMI autodetection patch to prevent anymore regressions like this.
Armin Wolf
Guenter Roeck
maintainerQuoted 25 lines · Armin Wolf
Am 24.10.23 um 16:48 schrieb Guenter Roeck:
Quoted 23 lines · Ian Nartowicz
Quoted 9 lines
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that hardware
monitoring was gone. Was working in 5.10. When I added it to thedmi_override_table, it started working again (with a slightly different device
name). dmidecode shows it as an on board device, type other, status disabled
(just the watchdog?), and description "SMsC SuperI/O".Weird, this is the second private e-mail I get in a single day. Is there some information out there suggesting that kernel maintainers should be contacted without copying the mailing list ? If so, tell them it is wrong. As warning to everyone, I won't reply any further to private e-mails like this.
Looking at the code, try adding ignore_dmi=1 as module parameter when loading the driver. I think commit
393935baa45e5cmessed it up and prevents the driver from loading if the parameter is not provided. Maybe the conditions insch56xx_init()are wrong or too generic. Armin, any comments ? Do we need to revert your patch ?
Quoted 6 lines
Quoted 2 lines
Guenter
I think so, it seems that the DMI devices are not always present. We better revert the DMI autodetection patch to prevent anymore regressions like this.
Not sure what I'd need to revert. Would it be all of the following ?
fd2d53c367ae hwmon: (sch56xx-common) Add DMI override table393935baa45e hwmon: (sch56xx-common) Add automatic module loading on supported devices 4db3c09228a0 hwmon: (sch56xx) Autoload modules on platform device creation
Alternatively, we could add Celsius W280 to the dmi override table. After all, the code has been present since 6.1, and the functional gain seems to be sufficient. Adding W280 with a Fixes: tag pointing to fd2d53c367ae would make more sense to me than reverting the above patches.
Guenter
Am 24.10.23 um 20:21 schrieb Guenter Roeck:
Quoted 27 lines · Armin Wolf
Quoted 26 lines
Am 24.10.23 um 16:48 schrieb Guenter Roeck:
Quoted 24 lines · Ian Nartowicz
Quoted 9 lines
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that hardware
monitoring was gone. Was working in 5.10. When I added it to thedmi_override_table, it started working again (with a slightly different device
name). dmidecode shows it as an on board device, type other, status disabled
(just the watchdog?), and description "SMsC SuperI/O".Weird, this is the second private e-mail I get in a single day. Is there some information out there suggesting that kernel maintainers should be contacted without copying the mailing list ? If so, tell them it is wrong. As warning to everyone, I won't reply any further to private e-mails like this.
Looking at the code, try adding ignore_dmi=1 as module parameter when loading the driver. I think commit
393935baa45e5cmessed it up and prevents the driver from loading if the parameter is not provided. Maybe the conditions insch56xx_init()are wrong or too generic. Armin, any comments ? Do we need to revert your patch ?Guenter
Quoted 8 lines
Quoted 4 lines
I think so, it seems that the DMI devices are not always present. We better revert the DMI autodetection patch to prevent anymore regressions like this.
Not sure what I'd need to revert. Would it be all of the following ?
fd2d53c367aehwmon: (sch56xx-common) Add DMI override table393935baa45ehwmon: (sch56xx-common) Add automatic module loading on supported devices
Those two commits should be reverted. The other commit is still useful without the DMI autoloading, since it allows user to just load sch56xx-common without having to load sch5627/sch5636 manually afterwards.
Quoted 7 lines
4db3c09228a0hwmon: (sch56xx) Autoload modules on platform device creationAlternatively, we could add Celsius W280 to the dmi override table. After all, the code has been present since 6.1, and the functional gain seems to be sufficient. Adding W280 with a Fixes: tag pointing to
fd2d53c367aewould make more sense to me than reverting the above patches.
I fear that there are far more machines suffering from this exact same issue. It seems to me now that the DMI device is only optional, possibly to signal the availability of some sort of management technology of which the hwmon interface seems to be part of.
We could solve this problem by somehow making it possible to send uevents if DMI onboard devices are detected. They could then be used to load the necessary drivers.
However since we currently cannot do this, i would revert the two patches for the time being.
Armin Wolf
Quoted 2 lines
Guenter
Quoted 14 lines · On Tue, 24 Oct 2023 07:48:50 -0700 Guenter Roeck <[email protected]> wrote:
Quoted 6 lines · Ian Nartowicz
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that hardware monitoring was gone. Was working in 5.10. When I added it to the
dmi_override_table, it started working again (with a slightly different device name). dmidecode shows it as an on board device, type other, status disabled (just the watchdog?), and description "SMsC SuperI/O".Weird, this is the second private e-mail I get in a single day. Is there some information out there suggesting that kernel maintainers should be contacted without copying the mailing list ? If so, tell them it is wrong. As warning to everyone, I won't reply any further to private e-mails like this.
Quoted 8 lines
Looking at the code, try adding ignore_dmi=1 as module parameter when loading the driver. I think commit
393935baa45e5cmessed it up and prevents the driver from loading if the parameter is not provided. Maybe the conditions insch56xx_init()are wrong or too generic. Armin, any comments ? Do we need to revert your patch ?Guenter
Apologies for the spam. I didn't know about the mailing list. Hopefully this will be more correct.
I tried the ignore_dmi option. Used manually on sch56xx-common, I was then able to modprobe sch5627 and it started working. Slightly clumsy, loading sch5627 first wouldn't work. It all worked more smoothly with the modules built in to the kernel and the option on the command line.
I have no idea how many machines use this chip, but I can't imagine the current list is comprehensive. Quite old, though? Let me know if you need more data or testing on a relevant machine.
--ian