You are not logged in.
Pages: 1
Yesterday I installed arch on a NUC10i3FNK (it has only keyboard, mouse, and hdmi connected).
After installing the basics, I noticed that the fan would spin up every few minutes, which is very annoying. (Even while I selected the 'quiet' fan profile in bios). For an idle system this seems strange.
I checked the load, it is at 1.00 continuously:
[user@nuci3 ~]$ uptime
12:16:36 up 2:15, 1 user, load average: 1.01, 1.00, 1.00
vmstat:
[user@nuci3 ~]$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 6879240 23604 498240 0 0 13 2 125 92 0 0 99 0 0
0 0 0 6878980 23604 498240 0 0 0 0 8946 625 0 2 98 0 0
0 0 0 6878968 23604 497860 0 0 0 13 8951 654 0 2 98 0 0
0 0 0 6878980 23608 497860 0 0 0 2 9014 703 0 2 98 0 0
0 0 0 6879988 23608 496736 0 0 0 2 8966 618 0 2 98 0 0
Looks like quite some interrupts/cs for an idle system.
From comparing the content of /proc/interrrupts 2 times, 10s apart, there is one line that stands out:
18: 0 12121735 0 0 IR-IO-APIC 18-fasteoi idma64.1, i2c_designware.1
10 seconds later:
18: 0 12210287 0 0 IR-IO-APIC 18-fasteoi idma64.1, i2c_designware.1
(full output at http://ix.io/2pup , also contains dmesg, lsmod)
I don't know exactly what that is for. But if it generates heat (the fan turning on) it's probably consuming power, so I had a look with powertop.
#1 in top10 power consumers: 0.0% 215.1 Interrupt [18] idma64.1 850 mW
Seems to match the interrupt 18.
I then forgot how I arrived at the following fix last night, but "rmmod tps6598x" 'fixes' the issue. It is of course not a real fix, because something else does probably not work now (supposed to be a usb-c power delivery component, according to some searching on the net).
After removing the module, the fan turns off when idle, vmstat shows normal values.
Side effect is some increased annoyingly noticeable coil whine now. The coil whine is different if I compare it between that module loaded/unloaded (even with the fans noise masking it a bit)
[user@nuci3 bbs]$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 6755028 25808 538924 0 0 10 2 631 165 0 1 99 0 0
0 0 0 6760152 25808 533432 0 0 0 0 40 101 0 0 100 0 0
0 0 0 6762084 25816 533360 0 0 0 3 29 61 0 0 100 0 0
0 0 0 6762084 25816 533368 0 0 0 0 22 45 0 0 100 0 0
0 0 0 6762588 25824 532976 0 0 0 3 29 56 0 0 100 0 0
What could be the next best step into fixing this?
Offline
I remembered someone with the same problem here:
https://www.reddit.com/r/archlinux/comm … nterrupts/
For that person, the following kernel command line argument works to suppress the problem, perhaps try booting with it and see what happens:
initcall_blacklist=dw_i2c_init_driver
Offline
Adding that parameter to the kernel boot options results in the following kernel modules not being loaded:
msr
tps6598x
typec
This also 'fixes' the problem, but the same result could probably be obtained by not loading tps6598x (ie blacklisting it).
(Also coil whine remains.)
Is there are way to figure out why the high number of interrupts from this driver happen in the first place (and maybe getting a step closer to getting it fixed properly?)
Offline
I'd try searching around for bug reports about this on the kernel bug tracker website. Thinking about things some more, you are right and that tps6598x module is the real cause for the problem. This i2c-designware thingy seems to be a sort of communication bus and is probably not at fault.
About how to help fix this thing yourself, I don't really know what to recommend. The only time I could successfully help fix a kernel problem was when I had both a bad and a good kernel version. There was a kernel version where things ran fine here for me, and there was a kernel version where it was bad. I could then bisect between the two and mention that in my bug report. A person working on that driver was then responding very fast and sharing a fix immediately. If you don't have a "good" version to compare to, I don't know how to help speed things up.
Just thinking about theory: the interrupt events are created by the hardware. The system has to react to the interrupts. Can a driver change fix this kind of problem where the hardware decides to send 9000 interrupts per second? If it's the driver that's at fault, then the reason has to be something about how the driver is configuring the hardware?
Coil whine is mysterious stuff. My experiences with coil whine are:
My current motherboard had strange coil whine while I was moving the mouse around. I tried finding out where the coil whine came from with the help of a cardboard tube (I tried listening through the tube and holding it over different parts in the open PC case), and I'm pretty sure it was the motherboard. For some reason this problem is not there anymore and I don't know what happened. It might be different BIOS settings or different BIOS version or different RAM speed settings.
Another story, I had a graphics card here that over time (kind of) fixed itself. At first its coil whine was terrible, and then after running it hot for hours every day, the coil whine reduced so much that it wasn't noticeable anymore with a closed PC case.
Offline
Pages: 1