sys file system blocking reads during heavy load

ewaller · 2015-07-19 03:46:51

I have been struggling with a strange problem I've not seen before, and searching the web has not been overly helpful. I have an HP Envy 15 Laptop with an i7 quad core processor.

When the system is not working hard, everything is fine. When I start a task that heavily loads the processor (compiling octave4 from the AUR, for example), I start to have problems with many things that try to monitor processor load and temperature, but not everything.

Conky stops updating. It is supposed to display battery, temperature, and CPU loads.
lm-sensors blocks.
Trying to read files from the sys file system hang. cat /sys/class/thermal/thermal_zone0/temp will block.
emacs hangs. (I presume because it tries to display system load in the status bar)

But,

i7z works fine.
So does htop

The fan throttles up and down consistent with compile activity and i7z output.
The system remains very responsive. Even though many of my cores are hitting 90%, the machine remains completly usable and responsive using chromium, thunderbird, and thunar. It streams video without hicups. Plenty of RAM is available and page faults are not occurring (The system is not thrashing)

Everything is normal and responsive. It is just that, once the temperatures climb above ~60C, the things I noted just hang. If I kill the build, temperatures drop to normal and everything that had been blocking returns to normal without further intervention.

I could find nothing on Goggle, except for some folks with Raspberry Pis that are having similar issues.
https://www.raspberrypi.org/forums/view … 28&t=28361
But I do not have to reboot to fix the issue.

I think this is a kernel bug. I have seen a few journal messages about kernel processes blocking for 120 Seconds and speculation about mutexes, but they don't happen every time. I suppose this could well be an HP BIOS problem as well.

Any thoughts?

Last edited by ewaller (2015-07-19 03:50:50)

mauritiusdadd · 2015-07-20 18:21:31

For the record, there is also a more recent thread, always on Raspberry Pi forum, that reports a similar issue https://www.raspberrypi.org/forums/view … 7&p=620166. It seems that their problem is caused by an I2C hardware bug but I don't think it's your case: if it was an hardware error (and thus it would not be possible to actually read the temperature), then even the fan wouldn't throttle up and down. I'm sorry, but that's all I was able to find on the web.

ewaller · 2015-07-21 14:37:30

Thanks for that. But, you are right, I don't think that my issue is an i2c hardware bug. I've tried the quick and nasty tricks of specifying acpi={ off | strict | noirq } on the kernel command line. Off was hopeless. the other two had no effect. I also tried pci=use_crs.

So, I fired up iasl and decompiled my dsdt. HP has cases for not 1, not 2. not 3 -- but 10 different operating system built into that DSDT. 10. Eight of them are various incarnations of MS Windows. Is it really reasonable to change the behavior of the hardware based upon which version of windows is running? One of the known systems is Linux. The last choice is "NOT_WINP_KEY", whatever that means.

Picking one of the Windows versions at random and using acpi_os_name=... did cause the kernel to stop carping about invalid critical temperatures being passed from the BIOS. Trying to figure out what the DSDT is doing is not fun -- it is spaghetti code with nested endless if-then-else clauses based upon the OS name. Maybe this evening I'll just sit down with a calming beverage and map out what the 10 choices do.

mauritiusdadd · 2015-07-21 17:22:43

ewaller wrote:

One of the known systems is Linux. The last choice is "NOT_WINP_KEY", whatever that means.

On windows the key combination Win+P is used to switch the video output and apparently on some laptops that key combo is grabbed directly by the firmware. The NOT_WINP_KEY is used to circumvent this issue http://kernel.opensuse.org/cgit/kernel- … 3d61067f98. However, good luck!

ewaller · 2015-07-28 04:45:25

The saga continues.

Trying all the OS names in the dsdt really had no effect.
In preparation to do some serious debugging, I built a custom kernel with all all the modules I need at boot built in. I also set it up to boot as an efi file with no initrd -- (Ohh, nice !)
But the kernel still has the issue. I even turned up the sample rate to 1 kHz.
I tried graysky's -ck kernel. No help.

Then, on a whim, I tried the -lts kernel. I'll be damned if it does not solve all my issues. What is more, using any other kernel, under load, my processor would peak at 99°C, just below my critical temperature. With the -lts kernel, I peaked at just about 80°C in this 27°C room.

As I've not seen anything relevant in my exploration of Google's results, I assume that this is a regression that not many people are seeing. Now I am at a loss. Do I waste my time trying to debug HP's dsdt, or do I try to find out whet has changed since the 3.14 kernel to cause this regression? Did the kernel guys stop supporting a work around of a broken dsdt, or did they introduce a bug?

I'm thinking I am going to find out what it is like to talk to the kernel folk.

R00KIE · 2015-07-28 09:20:25

ewaller wrote:

I'm thinking I am going to find out what it is like to talk to the kernel folk.

From my limited experience they are nice and helpful if you show that you are willing to do your part in finding what caused the problem and testing the proposed solution(s).

ewaller · 2015-08-02 21:13:20

Good news. kernel 4.2.0 has reached rc status. I have built a 4.2 kernel with most of the modules built in. It has solved all of my acpi problems

ewaller@turing /sys/class 1068 %uname -a
Linux turing 4.2.0-rc4-ARCH-HP_Envy #1 SMP PREEMPT Sun Aug 2 13:00:24 PDT 2015 x86_64 GNU/Linux
ewaller@turing /sys/class 1069 %lsmod
Module                  Size  Used by
iwlmvm                229376  0
intel_rapl             20480  0
iosf_mbi               16384  1 intel_rapl
iwlwifi               155648  1 iwlmvm
ewaller@turing /sys/class 1070 %

[ ewaller does Happy Dance ]

Here, I booted an EFI file directly with no initrd. The intel_rapl and iosf_mbi modules are new to this kernel, so I built them as modules. After boot, they were pulled in from /lib/modeules, as they were not available at boot (no initrd, remember ?)

Arch Linux

#1 2015-07-19 03:46:51

sys file system blocking reads during heavy load

#2 2015-07-20 18:21:31

Re: sys file system blocking reads during heavy load

#3 2015-07-21 14:37:30

Re: sys file system blocking reads during heavy load

#4 2015-07-21 17:22:43

Re: sys file system blocking reads during heavy load

#5 2015-07-28 04:45:25

Re: sys file system blocking reads during heavy load

#6 2015-07-28 09:20:25

Re: sys file system blocking reads during heavy load

#7 2015-08-02 21:13:20

Re: sys file system blocking reads during heavy load

Board footer