https://bugzilla.kernel.org/show_bug.cgi?id=204807 --- Comment #292 from Denis Pauk (pauk.denis@xxxxxxxxx) --- (In reply to Robert Kling from comment #291) > I let the mainboard/bios handle > cpu/aux fan speed, I'm not running any fan control programs at the moment. > Would that be fine? It depends on luck, bioses, hw schematic and so on. Main issue is bios does not provide known methods for sensor access and does not use global mutex before access to the region related to sensors, and mutual access could be not possible with such bios implementation. It works without known issues for other boards with mutex lock (P8H67, X99-E WS/USB 3.1). Other boards could have issues, like example it can be such: https://github.com/electrified/asus-wmi-sensors#known-issues. Its different driver but issues could be the same. > The WMI implementation in some of Asus' BIOSes is buggy. This can result in > fans stopping, fans getting stuck at max speed, or temperature readouts > getting stuck. This is not an issue with the driver, but the BIOS. The Prime > X470 Pro seems particularly bad for this. The more frequently the WMI > interface is polled the greater the potential for this to happen. Until you > have subjected your computer to an extended soak test while polling the > sensors frequently, don't leave you computer unattended. I can personally say > I've seen the issue on the Crosshair VII with BIOS 2606 and a Ryzen 2700X, > upgrading to 3004 rectified the issue. Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c37 > Sensor hardware frequently uses indexed addressing, which means that > accessing a sensor requires something like the following: > > 1) Write the desired sensor to the index register > 2) Read the sensor value from the data register > > These can't occur simultaneously, so if both the OS and the firmware are > accessing it you risk ending up with something like: > 1) Write sensor A to the index register (from the OS) > 2) Write sensor B to the index register (from the firmware) > 3) Read the sensor value from the data register (returns the value of sensor > B to the firmware) > 4) Read the sensor value from the data register (returns the value of sensor > B to the OS) Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c69 > the lm_sensors sensors-detect script had overvolted his RAM ruining both his > expensive high-end RAM as well as his expensive top of the line CPU. The user > was surprisingly relaxed about all this, which I really appreciated. > > And that was while the script was not doing anything which we (the > developers) considered dangerous. But the motherboard had a funky setup > causing a SMbus *read* transaction to change the voltage. Thank you! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
