SOLVED: Trying to resolve noisy fans issue, module not loading on boot

archuser_9999 · 2020-02-28 11:52:30

I note that I have a hardware fan control knob, and three case fans, plus the cpu and power fan (not used). The knob did used to work once upon a time. Fan noise has never been a huge issue until recently, and I don't have overheating or warnings. I don't currently understand where the chain of command is broken, if I can put it like that.I hope I'm understanding everything correctly... but obviously asking here because:

I've spent hours reading about various attempts to tame noisy fans on Arch with certain motherboards. Thus far I'm satisfied that

lm_sensors

is doing fine. Here's what it says:

atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage:      920.00 mV (min =  +0.80 V, max =  +1.60 V)
 +3.3 Voltage:        3.26 V  (min =  +2.97 V, max =  +3.63 V)
 +5 Voltage:          4.97 V  (min =  +4.50 V, max =  +5.50 V)
 +12 Voltage:        12.03 V  (min = +10.20 V, max = +13.80 V)
CPU FAN Speed:       703 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS1 FAN Speed:  629 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS2 FAN Speed:  942 RPM  (min =  600 RPM, max = 7200 RPM)
POWER FAN Speed:       0 RPM  (min =    0 RPM, max = 7200 RPM)
CPU Temperature:     +31.5°C  (high = +60.0°C, crit = +75.0°C)
MB Temperature:      +30.0°C  (high = +45.0°C, crit = +75.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +41.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:       +41.0°C  (high = +80.0°C, crit = +100.0°C)
Core 2:       +41.0°C  (high = +80.0°C, crit = +100.0°C)
Core 3:       +41.0°C  (high = +80.0°C, crit = +100.0°C)

Following through the various wiki instructions, I attempted to run

# pwmconfig

and got

/usr/bin/pwmconfig: There are no pwm-capable sensor modules installed

I clipped out what

# sensors-detect

had to say, namely just these three modules:

Driver `w83627ehf':
  * ISA bus, address 0x290
    Chip `Winbond W83667HG Super IO Sensors' (confidence: 9)

Driver `i5500_temp':
  * Chip `Intel 5500/5520/X58 thermal sensor' (confidence: 5)

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

Running

$ lsmod

showed me that both the 'i5500_temp' and the 'coretemp' modules were loading. Not being used, but loaded.

I tried to manually load the Winbond driver believing that this might give me missing control for the fans, but

 # modprobe w83627ehf
modprobe: ERROR: could not insert 'w83627ehf': Device or resource busy

Having read through the section on modules, and noting that the following was the first listed option (ahead of creating a file in '/etc/modprobe.d' l created

/etc/modules-load.d/w83627ehf.conf
# load my Winbond Super IO Sensors
w83627ehf

with just that single line in it, but it didn't work.

 journalctl -b -p3
-- Logs begin at Sat 2020-02-15 05:41:04 UTC, end at Fri 2020-02-28 11:40:49 UTC. --
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.
Feb 28 11:16:22 ArchLin systemd-modules-load[329]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd-modules-load[421]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.

isn't telling me very much!

Am I misunderstanding this thing entirely? Do I simply not have a compatible motherboard?

Last edited by archuser_9999 (2020-03-01 13:02:53)

Wild Penguin · 2020-02-28 13:44:43

archuser_9999 wrote:

I note that I have a hardware fan control knob, and three case fans, plus the cpu and power fan (not used). The knob did used to work once upon a time.

Wait, what you mean by a "knob"? If it is a physical knob, then you most likely can not use H/W control at the same time. How is this "knob" connected to your fans?

archuser_9999 wrote:

Fan noise has never been a huge issue until recently, and I don't have overheating or warnings.

You should really determine why the fans are now noisier than they used to than to just "fix" it with S/W control.

What kind of noise do they emit? Are they just running at a larger RPM now, or are their bearings perhaps broken? Perhaps someone accidentally reset your BIOS fan settings / set them to an unpleasant range? I take it this is not a water cooling setup but a regular air cooling setup. It is possible (but unlikely) parts are clogged with dust (you would most likely notice this before posting here... :-) ). In case it is a water cooling setup, there might be the usual culprits of pump failing / too much air in the loop causing thermal conduction issues.

For most/many regular users, BIOS fan control is enough. Try to set it up (in case there is no H/W problem) and forget S/W control. In case there is some H/W problem, fix it first (obviously).

Otherwise you are doing what is kind of needed for S/W fan control, but you need to figure out what is your MBs sensor chip. Sensors-detect can detect it in many situations, but not always, correctly. Even if it does, sometimes the MB vendors BIOS/ACPI implementation prevent handling the sensor chip directly. There may be ways around that (kernel parameters) but it is always warned that setting those for enabling writing / reading the sensor chip directly, might not be safe (as in: result in H/W damage).

The most important piece of information is missing from your post: what is your hardware? What is your motherboard?

In case / if you get a sensor chip working, you should get /sys/class/hwmon/hwmon?/pwmX entries (with _enable and other additional entries depending on the used driver).

EDIT: One quite probable culprit is that you can not use atk0110-acpi-0 at the same time with the chip specific driver, as they (probably) conflict with one another. You need to blacklist the former, and then probably set the possibly-dangerous kernel parameter to use the chip directly....

Last edited by Wild Penguin (2020-02-28 14:02:01)

archuser_9999 · 2020-02-28 18:08:35

ooh, thanks! Lots of helpful stuff in there, apologies for my omissions.

To start with then you've made one thing clear to me: that using hardware (a knob) directly conflicts with the idea of control under software.

To clarify - my approach was based on thinking that the reason the hardware knob didn't work was because some module wasn't loaded, or some package not installed, and which meant that the control offered went undetected. I had no idea that it presents a direct conflict to implementing software based control.

Onto specifics:

I clean my computer regularly. I hoover out dust and cat hair, and it's got decent filter panels that catch a lot of that. The fans aren't dusty, and they don't make any untoward noises - nothing like faulty bearings. They're simply spinning much faster than they need to be. This seems like the same issue I've seen posted multiple times elsewhere. Whatever my ls_sensors is reporting I don't believe it - they seem to be running full speed, despite the chip and mobo staying well within range.

Board is Asus P6T-SE. The hardware fan control was part of the case (this is a donated machine, I didn't build it. I originally had Windows installed on it. It was built by Novatech back in 2011). Having again taken both sides off the case to chase the wiring through, I can confirm that from this top front "header panel" containing four USB ports, a high speed USB (marked "SS") and firewire (I think?), it has a large round knob in the middle. Following all that wiring down, all of them connect to the various sockets at the bottom edge of the mainboard. Three of those are simple USB connections, the fourth is IE1392_2 [EDIT]: I gather the IE1392 connector is for the firewire port. Ultimately then I don't know how this knob connects. Perhaps it used software under Windows?

BIOS is set correctly. Smart_fan is enabled, "SILENT" mode chosen for each. What used to happen (a long while ago) would be that the fans would spin that slowly that I could barely hear them. Turning the knob gave an audible rise in rate. Now, they just spin at the same rate irrespective.

Out of interest I blacklisted the module 'asus_atk0110'. The only thing that has happened is I've lost fan speed and temp sensing. No other errors, although the "conflicting" module (x83267ehf) has still not loaded. I'll remove the blacklisting as although my machine was running within safe temperature ranges, I'm achieving nothing right now.

From the previous sensor scan it did indeed find two Fujitsu chips - the only mention of fans in the entire 'sensors3.conf'

chip "fschds-*"
# Fujitsu Technology Solutions, "Hades"-Chip

# Temperatures
    label temp1 "CPU Temp"
    label temp2 "Super I/O Temp"
    label temp3 "System Temp"

# Fans
    label fan1 "PSU Fan"
    label fan2 "CPU Fan"
    label fan3 "System FAN2"
    label fan4 "System FAN3"
    label fan5 "System FAN4"

# Voltages
    label in0 "+12V"
    label in1 "+5V"
    label in2 "Vbat"

chip "fscsyl-*"
# Fujitsu Technology Solutions, "Syleus"-Chip

# Temperatures
    label temp1 "CPU Temp"
    label temp4 "Super I/O Temp"
    label temp5 "Northbridge Temp"

# Fans
    label fan1 "CPU Fan"
    label fan2 "System FAN2"
    label fan3 "System FAN3"
    label fan4 "System FAN4"
    label fan7 "PSU Fan"

# Voltages
    label in0 "+12V"
    label in1 "+5V"
    label in2 "Vbat"
    label in3 "+3.3V"
    label in5 "+3.3V-Aux"

but I have no real idea what to do with this information, if anything.

Last edited by archuser_9999 (2020-02-28 18:28:28)

archuser_9999 · 2020-02-28 19:12:13

Interested to understand what's going on, even if no actual solution available. I installed the 'xsensor' package just in case it helped. Now it appears that the very module I'd been trying to load (unsuccessfully) is now loaded!

I ran

$ sensors -u

just to see if it would tell me anything. Some of this output (fans) looks a bit odd to me:

coretemp-isa-0000
Adapter: ISA adapter
Core 0:
  temp2_input: 41.000
  temp2_max: 80.000
  temp2_crit: 100.000
  temp2_crit_alarm: 0.000
Core 1:
  temp3_input: 41.000
  temp3_max: 80.000
  temp3_crit: 100.000
  temp3_crit_alarm: 0.000
Core 2:
  temp4_input: 40.000
  temp4_max: 80.000
  temp4_crit: 100.000
  temp4_crit_alarm: 0.000
Core 3:
  temp5_input: 41.000
  temp5_max: 80.000
  temp5_crit: 100.000
  temp5_crit_alarm: 0.000

w83667hg-isa-0290
Adapter: ISA adapter
Vcore:
  in0_input: 0.920
  in0_min: 0.000
  in0_max: 1.744
  in0_alarm: 0.000
in1:
  in1_input: 1.712
  in1_min: 0.000
  in1_max: 0.016
  in1_alarm: 1.000
AVCC:
  in2_input: 3.280
  in2_min: 2.976
  in2_max: 3.632
  in2_alarm: 0.000
+3.3V:
  in3_input: 3.264
  in3_min: 2.976
  in3_max: 3.632
  in3_alarm: 0.000
in4:
  in4_input: 1.656
  in4_min: 0.064
  in4_max: 0.016
  in4_alarm: 1.000
in5:
  in5_input: 2.040
  in5_min: 0.272
  in5_max: 0.064
  in5_alarm: 1.000
3VSB:
  in7_input: 3.376
  in7_min: 2.976
  in7_max: 3.632
  in7_alarm: 0.000
Vbat:
  in8_input: 3.296
  in8_min: 2.704
  in8_max: 3.632
  in8_alarm: 0.000
fan1:
  fan1_input: 649.000
  fan1_min: 84375.000
  fan1_alarm: 1.000
  fan1_div: 16.000
fan2:
  fan2_input: 675.000
  fan2_min: 0.000
  fan2_alarm: 1.000
  fan2_div: 16.000
fan3:
  fan3_input: 0.000
  fan3_min: 10546.000
  fan3_alarm: 1.000
  fan3_div: 128.000
fan4:
  fan4_input: 953.000
  fan4_min: 3515.000
  fan4_alarm: 1.000
  fan4_div: 8.000
fan5:
  fan5_input: 0.000
  fan5_min: 10546.000
  fan5_alarm: 1.000
  fan5_div: 128.000
temp1:
  temp1_input: 29.000
  temp1_max: 32.000
  temp1_max_hyst: 64.000
  temp1_alarm: 0.000
  temp1_type: 4.000
  temp1_offset: 0.000
temp2:
  temp2_input: 25.500
  temp2_max: 80.000
  temp2_max_hyst: 75.000
  temp2_alarm: 0.000
  temp2_type: 1.000
  temp2_offset: -15.000
temp3:
  temp3_input: 31.500
  temp3_max: 80.000
  temp3_max_hyst: 75.000
  temp3_alarm: 0.000
  temp3_type: 4.000
  temp3_offset: 0.000
cpu0_vid:
  cpu0_vid: 1.200
intrusion0:
  intrusion0_alarm: 0.000

what's going on with fans 1,3,4,5 with the "min" and "alarm" values?? Why do the "div" values differ?

Wild Penguin · 2020-02-29 11:01:15

archuser_9999 wrote:

To start with then you've made one thing clear to me: that using hardware (a knob) directly conflicts with the idea of control under software.
To clarify - my approach was based on thinking that the reason the hardware knob didn't work was because some module wasn't loaded, or some package not installed, and which meant that the control offered went undetected. I had no idea that it presents a direct conflict to implementing software based control.

Typically, a hardware fan adjuster is connected in series to the PSU (in between the PSU and the FAN), and has a simple varistor in there (thinking of old Zahlman Fanmate style adjusters here) and might have a sensor wire (only) going to the MB. But there are other kinds of controls, such as USB-based hubs and controllers. You might have something like that, and those are not usable with lm-sensors (they never have been and probably will not be).

You really need to dig in deeper to know what is going on, as there is still way too little information on what is going on; i.e. check each and every FAN, where they connect to, check out the part number on that front panel header with the knob. Otherwise, you could be as well throwing dice as wasting time trying to ger s/w fan controllig working!

I.e.: get the MB manual, take a piece of paper, draw each and every wire going from the HUB to the MB (and which header), take a look at every fan and draw/list the wire (and several if they exist) and were they are connected to.

Software control (with lm-sensors) is possible if and only if the fans are connected directly to the motherboard fan headers (well, you can put a simple splitter in between, but that is just about it).

USB controllers typically require proprietary software, which is not available on Linuxes (and: are not usable via lm-sensors in any case).

archuser_9999 wrote:

Board is Asus P6T-SE.

You'll want to check the MB manual if it has the chip mentioned. Typically it isn't, as this is not something the manufacturers feel obliged to tell users (sometimes they do). If it is not mentioned there, try to find the information via Google. Chances are some users have installed S/W fan control and hence they might have needed to dig into this information.

If the information is not there via Google, you might look up other MBs with the same chipset and see which sensor chips they use, and then investigate the motherboard (with a magnifying class, unless your eyesight is really good) to spot the actual sensor chip. But this approach will require disassembling the computer, which might not be a viable option for you.

archuser_9999 wrote:

BIOS is set correctly. Smart_fan is enabled, "SILENT" mode chosen for each. What used to happen (a long while ago) would be that the fans would spin that slowly that I could barely hear them. Turning the knob gave an audible rise in rate. Now, they just spin at the same rate irrespective.

This would be relevan if and only if the fans are connected directly to the MB. It can be used as a simple check; if BIOS settings has no effect, fans are not connected to the MB (but you really need to take a look at the physical connections to be sure).

archuser_9999 wrote:

I ran
$ sensors -u
just to see if it would tell me anything. Some of this output (fans) looks a bit odd to me:

Most probably lm-sensors is not correctly configured for your particular motherboard. Unless you have adjusted the configuration yourself, this is expected. It's all outlined in the lm-sensors manual.

A bit more details: The asus_atk0110 uses the ACPI implementation - i.e. requires the BIOS to do it's thing with the sensor chip. This is why it conflicts with the direct chip driver, and also this is different than directly accessing the sensor chip, and has never had fan control (AFAIK). The chip can be wired in various ways to the actual sensors, and the ACPI implementation does some simple maths to get the real, human-readable values from the chip. These values (for the math, something like ((x+a)/b + c) are different for each manufacturers (and even different MBs), even if they are using the same H/W chip, and this information is proprietary. This is why you need to adjust your lm-sensors config to do the math (in /etc/sensors.d). Also, sometimes the driver will get some of the information from the registers in the chip, but misinterpret it (mainly the alarm values). The div values are probably correct for some other M/B, or it is even possible the wrong chip has been detected (look in /etc/sensors3.conf).

Look at man sensors.conf for details.

Last edited by Wild Penguin (2020-02-29 11:37:31)

archuser_9999 · 2020-03-01 12:38:03

Again, a very helpful, clear response. Thank you.

My apologies too because in struggling always to be concise (people don't tend to want to wade through endless stuff just to get to the question) I realise that I hadn't been explicit in earlier posts. This is to say that yes, I had read all through all relevant Arch wiki pages, plus links from those, plus whatever I could find on lm-sensors. Their website I found to be a bit messy, because it seemed they were/are moving content. As such the various sections I wanted to read were blank. For someone coming to certain ideas and principles for the first time I found their "how to" annoyingly brief. For example I did succeed in creating a local config for the sensor information, and within it amend certain output regarding the fan sensors. But what I couldn't work out how to do was to "reset" those bizarre readings for things like

fan1_input "min"

to read as a zero. I'm assuming that setting it to zero is what might turn the fan down?

But allow me to backtrack slightly. I have resolved the issue. You are quite correct - fan control is via one of two essentially incompatible methods. I had confused myself by believing that the hardware control knob would be connected to and affect one of the chips on the mainboard - much like a keyboard does, or a USB volume knob I have. This was not the case for fan control.

What had helped this confusion was that at some point when adding a new piece of hardware (or taking one out) I had seen a fan connector lying loose and thought oh, I'd better find out where that can be connected. Downloading the user manual for the mainboard I found a socket for it, and on it went. What I've now understood that I did, having taken the case sides off, examined all the wiring routes exactly as you suggest, was to mix both types of connection. I had two case fans already connected to the hardware, with this other on the mainboard! And that was the fan which was running at high revs! Now that I've disconnected that and reattached it to the hardware knob all my fans except the CPU fan are controlled by the knob and the machine is virtually silent now. Now I can set the knob at, say, 40 per cent, and fans come on only when needed, run slowly, and then shut down again.

Just going back to software control however, and purely for the purposes of learning more about Arch: I realise that I don't now need this, but in wanting to always understand things where possible, I have to say that overall it's still something of a rather muddy and obscure trail to gain a proper understanding of how BIOS settings, fans and sensors all work together (or don't).

I appreciate that not all boards are supported. I appreciate that despite the fans, the machine has always worked fine with what I might call "Arch defaults" (i.e. however the live install set things up). But by the time I've followed a link from a link to another link and which is now explaining how to "hack" the chip information into a config file and then add a script that can fool sensors into reporting an adjusted reading... yeah, I thought that even had I not found my solution I might have simply left things there. That really didn't feel like 'beginner's territory' if you will, particularly when I'm becoming much more enamoured of the idea of always creating local configs and never writing things into files in /etc/ except in a few specific cases (such as modifying Pulse because I'm happy for it to be system-wide).

Thanks to both of you who responded with helpful posts

archuser_9999 · 2020-03-01 12:39:24

p.s. can't see how to mark the post "solved"?

V1del · 2020-03-01 12:58:57

Edit the title in your first post and add [SOLVED] or so: https://wiki.archlinux.org/index.php/Co … ow_to_post

blitz · 2020-03-01 16:17:05

archuser_9999 wrote:

-- Logs begin at Sat 2020-02-15 05:41:04 UTC, end at Fri 2020-02-28 11:40:49 UTC. --
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.
Feb 28 11:16:22 ArchLin systemd-modules-load[329]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd-modules-load[421]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.

isn't telling me very much!

Am I misunderstanding this thing entirely? Do I simply not have a compatible motherboard?

Especially in case of Feb 28 11:16:22 ArchLin systemd

Archlin? Never heard of.
China driver, written badly off.

Here You go - sudo inxi -Fxzd

System:    Host: inode Kernel: 5.5.6-1-bmq x86_64 bits: 64 compiler: clang v: 9.0.1) Desktop: Cinnamon 4.4.8 
           Distro: Arch Linux 
Graphics:  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics vendor: Lenovo driver: i915 v: kernel 
           bus ID: 00:02.0 
           Display: server: X.Org 1.20.7 driver: intel resolution: 1920x1200~60Hz 
           OpenGL: renderer: Mesa DRI Intel Ivybridge Desktop v: 4.2 Mesa 19.3.4 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Lenovo driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 
           Device-2: C-Media type: USB driver: hid-generic,snd-usb-audio,usbhid bus ID: 3-1.5:3 
           Sound Server: ALSA v: k5.5.6-1-bmq 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Lenovo driver: e1000e v: 3.2.6-k port: f080 bus ID: 00:19.0 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 577.55 GiB used: 436.23 GiB (75.5%) 
           ID-1: /dev/sda vendor: SanDisk model: SDSSDHII120G size: 111.79 GiB temp: [b]30 C[/b]
           ID-2: /dev/sdb vendor: Seagate model: ST500DM002-1BD142 size: 465.76 GiB temp: [b]31 C[/b]
           Optical-1: /dev/sr0 vendor: PLDS model: DVD-RW DH16AESH rev: 3L31 dev-links: cdrom 
           Features: speed: 40 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram state: running 
Partition: ID-1: / size: 47.79 GiB used: 42.64 GiB (89.2%) fs: f2fs dev: /dev/sda5 
           ID-2: /boot size: 96.0 MiB used: 66.9 MiB (69.6%) fs: vfat dev: /dev/sda2 
Sensors:   System Temperatures: cpu: 27.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 230 Uptime: 5d 1h 50m Memory: 7.63 GiB used: 3.55 GiB (46.5%) Init: systemd Compilers: gcc: 9.2.1 
           clang: 9.0.1 Shell: zsh v: 5.8 inxi: 3.0.37

What does matters:
ID-1: /dev/sda vendor: SanDisk model: SDSSDHII120G size: 111.79 GiB temp: 30 C
ID-2: /dev/sdb vendor: Seagate model: ST500DM002-1BD142 size: 465.76 GiB temp: 31 C

Last edited by blitz (2020-03-01 16:25:56)

loqs · 2020-03-01 16:26:11

blitz wrote:

archuser_9999 wrote:
-- Logs begin at Sat 2020-02-15 05:41:04 UTC, end at Fri 2020-02-28 11:40:49 UTC. --
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.
Feb 28 11:16:22 ArchLin systemd-modules-load[329]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd-modules-load[421]: Failed to insert module 'w83627ehf': Device or resource busy
Feb 28 11:16:22 ArchLin systemd[1]: Failed to start Load Kernel Modules.
isn't telling me very much!
Am I misunderstanding this thing entirely? Do I simply not have a compatible motherboard?
Especially in case of Feb 28 11:16:22 ArchLin systemd
Archlin? Never heard of.
China driver, written badly off.

Why would you have heard of another users system name? You are aware the thread is marked as solved?

blitz · 2020-03-01 16:36:17

loqs wrote:

...
Why would you have heard of another users system name? You are aware the thread is marked as solved?

To begin with:
i. Either --user or --system name. Not and never both of them in systemd commandement, You know..
ii. Close Your eyes, but the error is not properly resolved in this case.

Last edited by blitz (2020-03-01 16:36:57)

loqs · 2020-03-01 17:02:48

blitz wrote:

loqs wrote:
...
Why would you have heard of another users system name? You are aware the thread is marked as solved?
To begin with:
i. Either --user or --system name. Not and never both of them in systemd commandement, You know..

man 1 journalctl wrote:

Output is interleaved from all accessible journal files, whether they
are rotated or currently being written, and regardless of whether they
belong to the system itself or are accessible user journals.

Though I fail to see how is that relevant to your post

blitz wrote:

Especially in case of Feb 28 11:16:22 ArchLin systemd
Archlin? Never heard of.
China driver, written badly off.

On your other point.

blitz wrote:

ii. Close Your eyes, but the error is not properly resolved in this case.

Is it not up to archuser_9999 to decide when their issue is solved?

blitz · 2020-03-01 18:37:21

loqs wrote:

man 1 journalctl wrote:
Output is interleaved from all accessible journal files, whether they
are rotated or currently being written, and regardless of whether they
belong to the system itself or are accessible user journals.

Output is interleaved != Output is irrelevant.

On the topic now + meouws Kittie Kiss ))
What she likes, to spring up on warm Hitachi CM 625 professional monitor 17 inches - 160 Hz V-Sync and over 2000 pix screen resolution.

https://www.youtube.com/watch?v=YxAObNcT1zw

Last edited by blitz (2020-03-01 18:39:49)

ewaller · 2020-03-01 18:52:37

Closing this thread to preserve the declining signal to noise ratio.

Edit: archuser_9999, this is not punitive. If you need this reopened, please rport the thread and ask a moderator to reopen it.

Last edited by ewaller (2020-03-01 18:53:43)

Arch Linux

#1 2020-02-28 11:52:30

SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#2 2020-02-28 13:44:43

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#3 2020-02-28 18:08:35

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#4 2020-02-28 19:12:13

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#5 2020-02-29 11:01:15

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#6 2020-03-01 12:38:03

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#7 2020-03-01 12:39:24

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#8 2020-03-01 12:58:57

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#9 2020-03-01 16:17:05

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#10 2020-03-01 16:26:11

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#11 2020-03-01 16:36:17

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#12 2020-03-01 17:02:48

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#13 2020-03-01 18:37:21

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

#14 2020-03-01 18:52:37

Re: SOLVED: Trying to resolve noisy fans issue, module not loading on boot

Board footer