Description of problem: sensors-detect does not correctly recognize Nuvoton nct6687d-w io chip. When the appropriate kernel module loaded manually, sensors still can't display any information given by this chip. Version-Release number of selected component (if applicable): kernel: 6.0.10-300.fc37.x86_64 lm_sensors: 3.6.0 How reproducible: every time Steps to Reproduce: 1. run sensors-detect - no Nuvoton chip detected 2. modprobe nct6683 3. run sensors - no voltage or fan info displayed Actual results: $ sensors nvme-pci-0200 Adapter: PCI adapter Composite: +40.9°C (low = -5.2°C, high = +89.8°C) (crit = +93.8°C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C (crit = +105.0°C) coretemp-isa-0000 Adapter: ISA adapter Package id 0: +32.0°C (high = +80.0°C, crit = +100.0°C) Core 0: +30.0°C (high = +80.0°C, crit = +100.0°C) Core 1: +30.0°C (high = +80.0°C, crit = +100.0°C) Core 2: +32.0°C (high = +80.0°C, crit = +100.0°C) Core 3: +29.0°C (high = +80.0°C, crit = +100.0°C) Core 4: +30.0°C (high = +80.0°C, crit = +100.0°C) Core 5: +27.0°C (high = +80.0°C, crit = +100.0°C) nvme-pci-0300 Adapter: PCI adapter Composite: +40.9°C (low = -5.2°C, high = +89.8°C) (crit = +93.8°C) Expected results: fan and voltage info - in addition to the above Additional info: after the manual modeprobe: # dmesg | grep -i nct nct6683: Found NCT6687D or compatible chip at 0x4e:0xa20 # sensors-detect # sensors-detect version 3.6.0 # System: Micro-Star International Co., Ltd. MS-7D25 [1.0] # Board: Micro-Star International Co., Ltd. PRO Z690-A DDR4(MS-7D25) # Kernel: 6.0.10-300.fc37.x86_64 x86_64 # Processor: 12th Gen Intel(R) Core(TM) i5-12400F (6/151/5) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 19h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): /dev/port: Operation not permitted Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): /dev/port: Operation not permitted Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): /dev/port: Operation not permitted Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): Found unknown SMBus adapter 8086:7aa3 at 0000:00:1f.4. Sorry, no supported PCI bus adapters found. Module i2c-dev loaded successfully. Next adapter: SMBus I801 adapter at efa0 (i2c-0) Do you want to scan it? (YES/no/selectively): Client found at address 0x19 Probing for `Analog Devices ADM1021'... No Probing for `Analog Devices ADM1021A/ADM1023'... No Probing for `Maxim MAX1617'... No Probing for `Maxim MAX1617A'... No Probing for `Maxim MAX1668'... No Probing for `Maxim MAX1805'... No Probing for `Maxim MAX1989'... No Probing for `Maxim MAX6655/MAX6656'... No Probing for `TI THMC10'... No Probing for `National Semiconductor LM84'... No Probing for `Genesys Logic GL523SM'... No Probing for `Onsemi MC1066'... No Probing for `Maxim MAX1618'... No Probing for `Maxim MAX1619'... No Probing for `National Semiconductor LM82/LM83'... No Probing for `Maxim MAX6654'... No Probing for `Maxim MAX6690'... No Probing for `Maxim MAX6680/MAX6681'... No Probing for `Maxim MAX6695/MAX6696'... No Probing for `Texas Instruments TMP400'... No Probing for `Texas Instruments AMC6821'... No Probing for `National Semiconductor LM95231'... No Probing for `National Semiconductor LM95241'... No Probing for `National Semiconductor LM95245'... No Probing for `ST STTS424'... No Probing for `ST STTS424E'... No Probing for `ST STTS2002'... No Probing for `ST STTS3000'... No Probing for `NXP SE97/SE97B'... No Probing for `NXP SE98'... No Probing for `Analog Devices ADT7408'... No Probing for `IDT TS3000/TSE2002'... No Probing for `IDT TSE2004'... No Probing for `IDT TS3001'... No Probing for `Maxim MAX6604'... No Probing for `Microchip MCP9804'... No Probing for `Microchip MCP9808'... No Probing for `Microchip MCP98242'... No Probing for `Microchip MCP98243'... No Probing for `Microchip MCP98244'... No Probing for `Microchip MCP9843'... No Probing for `ON CAT6095/CAT34TS02'... No Probing for `ON CAT34TS02C'... No Probing for `ON CAT34TS04'... No Probing for `Atmel AT30TS00'... No Probing for `Giantec GT30TS00'... No Client found at address 0x1b Probing for `ST STTS424'... No Probing for `ST STTS424E'... No Probing for `ST STTS2002'... No Probing for `ST STTS3000'... No Probing for `NXP SE97/SE97B'... No Probing for `NXP SE98'... No Probing for `Analog Devices ADT7408'... No Probing for `IDT TS3000/TSE2002'... No Probing for `IDT TSE2004'... No Probing for `IDT TS3001'... No Probing for `Maxim MAX6604'... No Probing for `Microchip MCP9804'... No Probing for `Microchip MCP9808'... No Probing for `Microchip MCP98242'... No Probing for `Microchip MCP98243'... No Probing for `Microchip MCP98244'... No Probing for `Microchip MCP9843'... No Probing for `ON CAT6095/CAT34TS02'... No Probing for `ON CAT34TS02C'... No Probing for `ON CAT34TS04'... No Probing for `Atmel AT30TS00'... No Probing for `Giantec GT30TS00'... No Client found at address 0x4f Probing for `National Semiconductor LM75'... No Probing for `National Semiconductor LM75A'... No Probing for `Dallas Semiconductor DS75'... No Probing for `Maxim MAX6642'... No Probing for `Texas Instruments TMP421'... No Probing for `Texas Instruments TMP422'... No Probing for `Texas Instruments TMP435'... No Probing for `Texas Instruments TMP441'... No Probing for `Maxim MAX6633/MAX6634/MAX6635'... No Probing for `NXP/Philips SA56004'... No Client found at address 0x51 Handled by driver `ee1004' (already loaded), chip type `ee1004' (note: this is probably NOT a sensor chip!) Client found at address 0x53 Handled by driver `ee1004' (already loaded), chip type `ee1004' (note: this is probably NOT a sensor chip!) Next adapter: NVIDIA i2c adapter 1 at 1:00.0 (i2c-1) Do you want to scan it? (yes/NO/selectively): Next adapter: NVIDIA i2c adapter 5 at 1:00.0 (i2c-2) Do you want to scan it? (yes/NO/selectively): Next adapter: NVIDIA i2c adapter 6 at 1:00.0 (i2c-3) Do you want to scan it? (yes/NO/selectively): Next adapter: NVIDIA i2c adapter 7 at 1:00.0 (i2c-4) Do you want to scan it? (yes/NO/selectively): Next adapter: NVIDIA i2c adapter 8 at 1:00.0 (i2c-5) Do you want to scan it? (yes/NO/selectively): Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `coretemp': * Chip `Intel digital thermal sensor' (confidence: 9) Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): Unloading i2c-dev... OK
I'm on kernel 6.5.11 now (F39) and sensors-detect (3.6.0-14) still reports "Found unknown SMBus adapter 8086:7aa3"
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I'm not the maintainer - I'm the reporter, and I'd like the bug to remain open, as it is still valid on Fedora 39. How do I change the version?
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopened for F39
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I've reopened the bug for Fedora 41, but the severity has changed: the chipset still can not be auto-detected by "sensors-detect" command, however if I manually load the correct kernel module with "modprobe nct6683", now I can see all the relevant Vin and FANs info. I'm currently on kernel 6.11.6-300.fc41.x86_64 and lm_sensors 3.6.0-20.fc41.x86_64.
I think it is related to the fact that the sensors-detect script is missing that chip entry. The following commit was made to the lm-sensors github after 3.6 was out: https://github.com/lm-sensors/lm-sensors/commit/ac03cccaf92bdb2661d6e8bdde6ea78f60527b0a
Your commit mentioned "devid => 0xD590". How can I make sure this is indeed the correct Chip ID for my device?
Check the sensors-detect results for the detected superIO chip id: Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes Found unknown chip with ID 0xd592 If the ID is 0xd592, then that commit will make sensors-detect recognize it. With the commit applied: Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes Found `Nuvoton NCT6687D eSIO' Success! (address 0xa20, driver `nct6683') One issue is that the PWM controls aren't writeable with that driver: https://bugzilla.kernel.org/show_bug.cgi?id=217591 More info: https://github.com/lm-sensors/lm-sensors/issues/451
My output for this is (running as root): Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): /dev/port: Operation not permitted The permissions of /dev/port are as following: root@fedora:~# ls -l /dev/port crw-r-----. 1 root kmem 1, 4 Nov 16 00:46 /dev/port
Do you have have secure boot enabled? Because I remember reading that secure boot disable access to the io port which sensors-detect uses.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.