Does anyone use Asrock X670E Taichi on Linux? Can you please check if sensors for it are working? I just got one, but sensors-detect can’t figure out what to pick for its Nuvoton super I/O chip.
According to their spec it’s NCT6796D-S / NCT6686D (see page 11 in the manual):
At least NCT6796D should be supported (see kernel hwmon documentation for nct6775).
If it’s not working for anyone, I can open the hwmon bug.
Do you have the lm-sensors package installed? It’s the actual workhorse, so it should. If not, install it.
Yes, of course. I’m using actual sensors tool from it and sensors-detect as well. Problem is that it’s not working, even though it finds some Nuvoton chip during probing.
What I’m asking is if you (or anyone) has the same board and has sensors working or not working. If my board is defective (not very likely), I can try RMAing it, but more likely hwmon is missing something for sensors to work on this board. I can open a bug, but first I want more confirmations that it’s not working not just for me.
I have the X670E Taichi and ran sensors-detect, using the default option in all prompts, and I see some unknown chips:
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'... Yes
Found unknown chip with ID 0xd802
(logical device B has address 0x290, could be sensors)
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 0xd441
Thanks, and after that it says that “Sorry, no sensors were detected”, right?
It at least realized that it’s Nuvoton, but then can’t match it with any specific driver.
Yup!
Got it, thanks! I’ll open the hwmon bug then, sounds like something is missing there.
By the way, do you get a bunch of ACPI errors during booting for this board? I can see it dmesg. Using UEFI 1.24.
Kernel - 6.5-rc1.
I do. Although I have the Steel Legend board. Seems like an AsRock AM5 problem, seen people mentioning it several times.
Yup - I still have ACPI errors with v1.24.AS02.
I’m just happy the boot time was significantly improved with this BIOS version, it was annoyingly slow before this.
Thanks. I don’t see matching bug report either on the kernel bugzilla. I’ll open one.
Thanks for opening the bug reports!
Btw, there is already an open bug for ALSA issues in case you need it (bug 229 for alsa-project/alsa-ucm-conf on Github, can’t post links for some reason).
You probably don’t have the reputation to post links yet…
Here’s a the bug link for future readers:
I use a usb DAC, so I haven’t run across this bug yet.
Yeah, I use S/PDIF attached DAC+amp myself (and S/PDIF output works), but I just noticed that audio settings were very bare-bones and something was missing, so I found that bug.
You have to force load the nct6775 driver module for the SIO chip to get loaded and polled.
Faced the same situation with my Asus X670E Crosshair Hero board. Lm-sensors sensors-detect finds “somethings” but can’t figure out what and where to load it.
Expected I guess since that software hasn’t been updated in 5 years.
The dmesg errors are probably with the ITE USB chip which is unsupported still.
Try this for the nct6775 module:
sudo modprobe nct6775 force_id=0xd420
I have had to use the force load on every kernel since 6.1
Even still at 6.5-rc2
sudo dmesg |grep nct6775
[ 4.310583] nct6775: Found NCT6796D or compatible chip at 0x2e:0x290
sensors
nct6796-isa-0290
Adapter: ISA adapter
Vcore: 744.00 mV (min = +0.00 V, max = +1.74 V)
in1: 992.00 mV (min = +0.00 V, max = +0.00 V) ALARM
AVCC: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM
+3.3V: 3.31 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM
in6: 1.13 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM
Vbat: 3.31 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 1.66 V (min = +0.00 V, max = +0.00 V) ALARM
in10: 528.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 528.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in13: 1.21 V (min = +0.00 V, max = +0.00 V) ALARM
in14: 1.23 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 0 RPM (min = 0 RPM)
fan2: 2000 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 1928 RPM (min = 0 RPM)
SYSTIN: +34.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +32.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +19.0°C sensor = thermistor
AUXTIN1: +22.0°C sensor = thermistor
AUXTIN2: +22.0°C sensor = thermistor
AUXTIN3: +14.0°C sensor = thermistor
PECI Agent 0 Calibration: +34.0°C
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
TSI0_TEMP: +45.1°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
Thanks. Is 0xd420 in this case one of the chips that sensors-detect lists? So I should use the corresponding id for my case?
Ideally, simply doing sudo modprobe nct6775 should work, but if it works with explicit id, it means nct6775 upstream is missing something and that id can be added may be.
I’ve read the kernel merge posts for the nct6775 branch code and from my perusing, it looks like it should be looking for the chip at that address. But it isn’t on the mainline PPA pull of the 6.5-rc2 kernel.
But I am unfamiliar with the exacts of when the pull merges or patches get applied to the kernel mainline images. I didn’t do any patches. I just kept the same force load that has worked for the past kernels.
If you are going to submit a bug report, I would just go ahead and mention it. I’m sure that the responders will tell you one way or another whether it is implemented yet for the chip to be found at the correct address.
I’ve read the kernel merge posts for the nct6775 branch code and from my perusing, it looks like it should be looking for the chip at that address.
Ah, do you mean it was submitted as a patch and not merged yet? Do you have a link to it? I can try to find the place in the driver and will check when it’s merged. Probably no need for bug report, unless it’s missing the id that’s used in my case.
It looks like it already is there if I can read code correctly.
nct6775.core.c
At the 6.5-rc1 branch level. Picks up the nct6779 chip
My board supposedly uses a nct6799D chip. But a simple modprobe does not load the driver.
When I tried to force load it at the 0xd802 address listed in the code, it does not find the chip. Only the address for the nct6796D is found.