[SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

mhaddir · 2019-01-14 23:20:13

I have a Lenovo IdeaPad that I have dual booted with the original Windows 10 software. It is an Intel i3 8th gen core, so not terribly fast, but it runs as expected in Windows.

However, when I am booted into Linux, the processor is constantly running, the fan always going, and I hear the hard drive boot up every few seconds. The longer the system is on, the more rapidly the hard drive boots. I'll get lags sometimes selecting a new FireFox tab, or writing a word in SublimeText. I don't get it at all, it is a new computer.

I have looked through dmesg and journalctl for error messages or any repeated journaling, and I can't find anything. I run xfce, and there was an issue with virtualbox, but I uninstalled the "dkms" version and reinstalled the "arch" version in the community repo, and I think that solved it.

I was running just Arch Linux on an even slower HP without any of the same issuses. I don't know what is going on, but I am concerned this will wear out my computer. Plus it is incredibly annoying.

Last edited by mhaddir (2019-01-17 03:57:16)

Kirill Bugaev · 2019-01-15 07:08:21

What about `top` output? Is there some processes that load CPU around 100%. Maybe your hdd standby timeout is too short. What is `sudo hdparm -I /dev/sda" output?

Last edited by Kirill Bugaev (2019-01-15 07:11:02)

mhaddir · 2019-01-15 19:05:13

Thanks for your reply, Kirill.

I checked the top output and there is nothing running high, everything below 10%. I noticed last night when I was working that the problem seemed not to be occurring, but then I turned it on today and just left it sitting and it was revving up again and again with absolutely nothing loaded (other than xfce).

Here is some hdparm config info:

Configuration:
	Logical		max	current
	cylinders	16383	0
	heads		16	0
	sectors/track	63	0
	--
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:  1953525168
	Logical  Sector size:                   512 bytes
	Physical Sector size:                  4096 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      953869 MBytes
	device size with M = 1000*1000:     1000204 MBytes (1000 GB)
	cache/buffer size  = unknown
	Form Factor: 2.5 inch
	Nominal Media Rotation Rate: 5400
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 96
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns

mhaddir · 2019-01-15 23:19:28

I started looking into hdparm and standby time, and I think you are right that it is the problem. I found an opensuse forum that talks about the same problem, and I get the same error message as the OP there:

[root@mhaddir ~]# hdparm -S
  -S: bad/missing standby-interval value (0..255)

But when I do

hdparm -S100 /dev/sda

it says that it changed the standby time, but the

hdparm -I /dev/sda

output doesn't change, and the problem doesn't go away. When I change the advanced settings using

hdparm -B255

which is turns off the advanced power management, the info output changes but still no change in the hard drive spinning up.

I am concerned that I can't find a way to add a standby time, although I am thinking maybe this isn't the problem.

mhaddir · 2019-01-16 05:17:25

I think there is something to do with my wireless card that is screwing up my hardware, which is ironically the reason I bought a Lenovo IdeaPad instead of an HP. My wireless card is called wlp2s0, but I have to do rfkill to unblock my wireless LAN and it is displayed as "phy0". Currently, I do not know what the difference is between rfkill and LAN blocking, and regular ip link wireless devicing.

Howerver, it seems that the kernel worker is going double time writing to my hard drive and it has something to do with phy0.

This is what I get with iotop -obtqqq | grep phy0:

00:01:31  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:2-phy0]
00:01:35  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u8:1-phy0]
00:01:37  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
00:01:39  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u8:1-phy0]
00:01:42  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.32 % [kworker/u8:1-phy0]
00:01:47  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:1-phy0]
00:01:49  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.33 % [kworker/u8:1-phy0]
00:01:51  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [kworker/u8:2-phy0]
00:01:53  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.30 % [kworker/u8:2-phy0]
00:01:55  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.33 % [kworker/u8:2-phy0]
00:01:57  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u8:2-phy0]
00:01:59  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:2-phy0]
00:02:03  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
00:02:05  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.32 % [kworker/u8:2-phy0]
00:02:07  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:2-phy0]
00:02:12  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:2-phy0]
00:02:14  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u8:2-phy0]
00:02:16  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 % 28.48 % [kworker/u8:2-phy0]
00:02:18  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:1-phy0]
00:02:20  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:2-phy0]
00:02:25  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.30 % [kworker/u8:1-phy0]
00:02:27  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
00:02:29  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
00:02:38  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
00:02:40  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
00:02:42  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
00:02:44  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:1-phy0]
00:02:46  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
00:02:50  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:1-phy0]
00:02:52  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 % 10.49 % [kworker/u8:1-phy0]
00:02:54  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
00:02:56  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u8:1-phy0]
00:02:57  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 % 14.69 % [kworker/u8:1-phy0]
00:02:59  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:1-phy0]
00:03:01  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:1-phy0]
00:03:03  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
00:03:06  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:1-phy0]
00:03:08  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
00:03:10  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:1-phy0]
00:03:12  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
00:03:14  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
00:03:20  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
00:03:24  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.38 % [kworker/u8:2-phy0]
00:03:26  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-phy0]
00:03:31  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
00:03:35  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:2-phy0]
00:03:38  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.16 % [kworker/u8:1-phy0]
00:03:40  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:2-phy0]
00:03:42  3751 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:1-phy0]
00:03:46  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:2-phy0]
00:03:48  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:2-phy0]
00:03:50  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:2-phy0]
00:03:59  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:2-phy0]
00:04:01  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.34 % [kworker/u8:2-phy0]
00:04:03  3908 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:2-phy0]

It spikes when I do something, otherwise it maintains between 0.25-0.75%.

seth · 2019-01-16 08:28:16

Only the first two cols are actually disk IO.

First step is to actually shut down windows to get the HW into a consistent state: https://wiki.archlinux.org/index.php/Du … t_Start-Up (windows hibernates by default)

Then there's "the processor is constantly running, the fan always going" - apparently it's actually only the fan?
There might be fan control specifc caveats for your device, see https://wiki.archlinux.org/index.php?ti … apad&go=Go

The drive will have to spin up whenever something wants to read or write from it, even the most minor amount of bits.
Things that are über-prone to keep the disk busy are indexers like tracker or baloo (usually found w/ gnome and KDE, not sure whether xfce ships such) but if you're doing something, many programs will just update some files (eg. the shells will write the history whenever you fire a command) - you'll have to actually track iotop to see what constantly wakes up the drive.

Another thing is swapping, you may reduce swappiness to prefer dropping file caches (causing HHD reads when you need the file, of course) or disable the swap partition/file altogether.

Also use lazytime, https://wiki.archlinux.org/index.php/Fs … me_options

mhaddir · 2019-01-16 19:15:14

I went ahead and disabled fast start and put lazytime into my fstab, which I think is just good in general, but no difference. I don't use swap.

I am pretty sure it isn't just the fan, it is a high pitched whir different from the fan sound - that doesn't happen when I run Windows, and my Arch is very bare-bones. I am not sure what the iotop percentage in the fourth column means, but it does strike me as odd that the kworker/u8 line is triggered every couple seconds, and that it changes from "kworker/u8:2-events_power_efficient" to "kworker/u8:2-phy0" after I connected to the internet (phy0 refers to the Atheros wireless card).

I am starting to wonder if this is just the computer model, because I haven't been finding stellar reviews for the Lenovo IdeaPad 320, and this is 330. I am going to keep at this but I am starting to give up. Thanks a lot to the both of you, though, because I was pretty lost. Figuring out the hdparm and standby timers from Kirill set me on the right path, and I think after all I've tried and what you've said, Seth, there isn't much else to do other than wait for a kernel update and see if it resolves.

seth · 2019-01-16 20:02:29

it is a high pitched whir different from the fan sound

But the cpu load isn't reported as high (plus it would be scary to hear the cpu) - or do you just suspect it to be the hard drive?

I/O is I/O - in this case pretty much likely network traffic.
You might want to set all NICs down and then "iotop -oa" should be fairly silent on an idle system and quickly reveal what's waking the disk.

mhaddir · 2019-01-16 20:30:24

Well, I think that it is the hard drive spinning up. As Kirill pointed out, there seems to be something wrong with the the hard drive standby time, hence the hdparming. I guess I don't feel 100% confident that it is the hard drive, but I can't think what else it would be because it isn't the fan and I don't have SSD.

When I run iotop -oa, it gives me basically the same: jdbd2, and 2-3 kworker/u8 threads, including kworker/u8:x-phy0.

When I set all the NICs down, there is no change except instead of getting kworker/u8:x-phy0, I get

15:19:59  2092 be/4 root        0.00 B/s    0.00 B/s  0.00 % 10.19 % [kworker/u8:1+flush-8:0]
15:19:59  1648 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:0-events_freezable_power_]
15:20:00  2092 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [kworker/u8:1+flush-8:0]
15:20:01  2092 be/4 root        0.00 B/s    0.00 B/s  0.00 %  5.97 % [kworker/u8:1-events_freezable_power_]
15:20:05  2092 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.38 % [kworker/u8:1-i915]
15:20:07  2092 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:1-i915]
15:20:09  2215 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.38 % [kworker/u8:2-i915]
15:20:11  2215 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-flush-8:0]
15:20:13  2215 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.33 % [kworker/u8:2-i915]

I don't know, is it flushing or journaling? Sometimes, and especially before I start xfce, I get "events_power_efficient" instead of "events_freezable_power". I had issues with powersaving before where my cpu was stuck on 800 mHz even though the processor is 2.4 gHz. That went away but I couldn't tell you what I did.

This is what ip link gives me after everything is set down:

1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8c:16:45:de:d7:ef brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000
    link/ether 30:d1:6b:ee:45:ff brd ff:ff:ff:ff:ff:ff

seth · 2019-01-16 20:45:34

hdparm -C /dev/sda
hdparm -y /dev/sda
hdparm -C /dev/sda
hdparm -Y /dev/sda
hdparm -C /dev/sda
sleep 30
hdparm -C /dev/sda

mhaddir · 2019-01-16 21:01:35

I put that in a script, plus I added "iotop -obtqqq | grep 'kworker|jdbd'" at the end. And it seems like it works in stopping the constant writes. However, when I stop the script and then run the iotop -obtqqq command manually, it goes back to the same stream of kworker/u8:x micro-writes (0.25%-75%):

[root@mhaddir test]# bash parma

/dev/sda:
 drive state is:  active/idle

/dev/sda:
 issuing standby command

/dev/sda:
 drive state is:  standby

/dev/sda:
 issuing sleep command

/dev/sda:
 drive state is:  standby

/dev/sda:
 drive state is:  active/idle

iotop output
^C[root@mhaddir test]# iotop -obtqqq | grep u8
15:57:42  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-phy0]
15:57:44  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:2-phy0]
15:57:46  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:2-phy0]
15:57:48  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-phy0]
15:57:50  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:2-phy0]
15:57:52  3611 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:2-i915]

seth · 2019-01-16 21:07:27

/dev/sda:
 issuing sleep command

/dev/sda:
 drive state is:  standby

/dev/sda:
 drive state is:  active/idle

Something™ is waking the drive in the 30 second delay.
Forget about those kworker threads - you only care about reads and writes to block devices, ie. the B/s columns - whatever pops up there is the culprit.

mhaddir · 2019-01-16 21:33:51

Nothing pops up there, not even when the HHD is whirring. There are no errors or repeating messages in journalctl logs, or dmesg, or the boot messages. The top output looks normal, no odd processes.

However, the hard drive is constantly running, and thus the fan is, and periodically my computer will lag while typing something in SublimeText, or switching a tab in FireFox (out of a total of 2-3 tabs). Literally doing nothing, no programs - not even X - running, just sitting in post-login in command line - IT STILL DOES THIS. And I am running a bare-bones Arch system on a new computer with an i3 processor and no apparent driver issues. I am flummoxed, and I am wondering if it is the Lenovo model of the laptop.

I will say, though, that there is something weird going on with the power saving on the computer. I have an xfce panel item for CPU info and I can't change any of the cores' governor from powersave - I change it, close the menu, reopen and it is back on powersave. I can't seem to do anything to change hdparm's standby setting - no matter how many times I plug in hdparm -S100 or hdparm -S255 or hdparm -S{any number 0-255}, the hdparm -I output shows:

Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 96
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns

I can change Advanced power management level but it doesn't do anything to solve the problem.

seth · 2019-01-16 21:53:15

Is this a built-in drive or wired via USB?

You can ignore the "-S" setting for now: you know that even if you put the drive to sleep, it will wakeup within less than 30 seconds.
The traffic does not have to be big, but it has to happen in the block device read/write columns. Please stop grepping iotop.
Since there's no corresponding output in your posts: jbd2 has the potential to cause block device I/O - even if it's only 1kB: that'd be the cause.

mhaddir · 2019-01-16 22:16:32

It is the built in drive.

So, without grepping, I ran the hdparm script you suggested while also running iotop -oqtqqq in the background and I saw that during the 30 sleep the weather panel on the xfce was writing in the first two columns. So, I removed the panel and did it again.

Here is the hdparm script out put (I added timestamps so you can reference them in the iotop):

17:08:57 - /dev/sda:
 drive state is:  active/idle

17:08:57 - /dev/sda:
 issuing standby command

17:08:57 - /dev/sda:
 drive state is:  standby

17:08:57 - /dev/sda:
 issuing sleep command

17:08:58 - /dev/sda:
 drive state is:  standby

17:09:28 - /dev/sda:
 drive state is:  standby

Here is the iotop:

17:08:55   234 be/3 root        0.00 B/s   23.70 K/s  0.00 % 11.79 % [jbd2/sda6-8]
17:08:56  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.35 % [kworker/u8:1-phy0]
17:08:57  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u8:1-events_unbound]
17:08:58  2659 be/4 root        0.00 B/s    0.00 B/s  0.00 %  1.11 % [kworker/3:0-events]
17:08:58  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:1-phy0]
17:08:58   260 be/4 root        0.00 B/s   69.73 K/s  0.00 %  0.00 % systemd-journald
17:09:00  4454 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:2-events_freezable_power_]
17:09:03  4454 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-phy0]
17:09:05  4454 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:2-phy0]
17:09:06   234 be/3 root        0.00 B/s    3.95 K/s  0.00 % 99.99 % [jbd2/sda6-8]
17:09:07  4454 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:2-phy0]
17:09:09  4454 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.37 % [kworker/u8:2-phy0]
17:09:11  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:13  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
17:09:15  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:17  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:19  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:22  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.38 % [kworker/u8:1-phy0]
17:09:24  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:26  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.39 % [kworker/u8:1-phy0]
17:09:28  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 % 10.49 % [kworker/u8:1+flush-8:0]
17:09:31  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [kworker/u8:1-phy0]
17:09:33  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
17:09:35  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.36 % [kworker/u8:1-phy0]
17:09:36   234 be/3 root        0.00 B/s    0.00 B/s  0.00 % 10.24 % [jbd2/sda6-8]
17:09:37  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-phy0]
17:09:39  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-events_freezable_power_]
17:09:40  1050 be/4 mhaddir       0.00 B/s    0.00 B/s  0.00 %  0.14 % Xorg -nolisten tcp :0 vt1 vt1
17:09:41  4450 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.40 % [kworker/u8:1-events_freezable_power_]

That is running nothing but xfce and the two terminals, I noticed earlier that firefox was interrupting the sleep.

As far as I can tell, nothing has changed getting rid of the weather panel, but I'm going to reboot and see.

mhaddir · 2019-01-17 03:50:20

I think it is just a flaw with the Lenovo model, everything else seems to be working fine. I found this article which seems to say that this series is just obnoxiously, and famously, loud, so I think I will mark the thread as solved. I didn't figure out what was wrong, but I think I figured out so many things that were not wrong that I'd say it counts as solved.

It has been a learning experience trying to work these things out, but I kind of wish I just let it go. I think that is just my personality, nothing to do with my hard drive. Thanks to Kirill and especially Seth for humoring me.

Last edited by mhaddir (2019-01-17 03:55:48)

mhaddir · 2019-01-25 00:50:56

I kept looking into the problem, because I started to doubt it was the hard drive, especially because it seemed that the sound would start going whenever I changed broswer tabs or windows, so I thought it might be a graphics processing issue. It turns out it was a problem with the GPU fan, which I didn't realize existed. I found this link which was very helpful, informatively speaking.

I updated the mesa graphics driver package, and I tried installing vulkan-intel, and while I thought it was helping apparently it wasn't. I think it is the GPU fan that is running. The computer is annoyingly loud, but the fan shouldn't be kicking on this much while I am in Linux. I want to say it isn't a serious issue, but I suppose time will tell.

Last edited by mhaddir (2019-01-25 22:10:37)

Arch Linux

#1 2019-01-14 23:20:13

[SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#2 2019-01-15 07:08:21

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#3 2019-01-15 19:05:13

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#4 2019-01-15 23:19:28

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#5 2019-01-16 05:17:25

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#6 2019-01-16 08:28:16

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#7 2019-01-16 19:15:14

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#8 2019-01-16 20:02:29

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#9 2019-01-16 20:30:24

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#10 2019-01-16 20:45:34

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#11 2019-01-16 21:01:35

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#12 2019-01-16 21:07:27

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#13 2019-01-16 21:33:51

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#14 2019-01-16 21:53:15

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#15 2019-01-16 22:16:32

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#16 2019-01-17 03:50:20

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

#17 2019-01-25 00:50:56

Re: [SOLVED] Win10 Dual boot Fan/HHD running constantly in Linux

Board footer