4.2 (linux-generic-lts-wily) kernel hangs on Bay Trail based Asus X553MA

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1531865

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Since this bug still exists upstream, it might be best to also cc the message you sent to intel-gfx to the following addresses:

Author: Chris Wilson <email address hidden>
    Cc: Deepak S <email address hidden>
    Cc: Ville Syrjälä <email address hidden>
    Cc: Rodrigo Vivi <email address hidden>
    Cc: Daniel Vetter <email address hidden>

I did cc Chris Wilson and after that someone added Deepak S and then Chris Wilson also replied so I believe it went to right address.

The drm.intel team seems to have come to the conclusion that reverting this change does not fix the issue, at least not for everybody, although it might make the hangs much more rare. There exists a drm-intel bug report for this issue with all the details:
https://bugs.freedesktop.org/show_bug.cgi?id=88012
After it was concluded by the drm-intel developers that the fault was most likely not with the graphics drivers, as it first seemed to be, Daniel Vetter of drm-intel filed a kernel bug, assigned to Len Brown (who wrote the intel_idle driver):
https://bugzilla.kernel.org/show_bug.cgi?id=109051

I will nevertheless try the kernel with that change reverted as soon as I get a chance.

I had been running 4.4-rc8 with the patch reversed three days with no problems but yesterday evening I put an OpenGL application causing heavy load to graphics pipeline running and machine had hanged overnight. Today after booting I ran the OpenGL application couple minutes and then few minutes later I had hang. During those three days I had been streaming video from the web several hours. I'll try if normal video playback would trigger the hang.

Or it could have been something else. I decided to test 4.2.8 with "drm/i915: Agressive downclocking on Baytrail" reversed running that gpu intensive application.

In my test of your kernel image, I also have just had a hang again. The frequency of hangs seems much reduced, but they do seem to still occur, as others had also reported in the freedesktop.org bug report. The symptoms were slightly different this time (the display turned black, which has happened before, but was unusual, and the sound card played junk for a short time), but I do think that this is still the same problem, since it has never happened with much longer testing with intel_idle.max_cstate=1 (also, much of the sound hardware seems to be on-chip on BayTrail processors, so an invalid processor state might conceivably also cause the other on-board hardware to malfunction).

So far it seems that 4.2.8 doesn't have problems with high gpu load.

4.2.8 didn't hang overnight either with the OpenGL application.

Some people have reported this hang happening also with 4.1.x kernels. I wonder have I really been so damn lucky not to have single hang with 4.1.13 since November.

>Thomas Moestl (tmoestl) wrote 18 hours ago: #21
>
>In my test of your kernel image, I also have just had a hang again.

I put the mainline 4.2.8 I've been testing also here:

http://www.helsinki.fi/~jmoheikk/baytrail/

I wasn't able to get it hang with running the OpenGL apllication. Today I played videos with VLC 4 hours and built kernel at the same time with "-j 4" option. Seems as stable as any 4.1.x I've used.

Looking at your BootDmesg.txt it seems that you still have HDD. I've replaced mine with Samsung 840 EVO SSD. That is at least one thing that could make my system behave quite differently.

Now I had VLC running overnight with 4.2.8 and no hang.

At the moment I'm assuming that with 4.2.8 and "drm/i915: Agressive downclocking on Baytrail" I'm getting the same behavior as with 4.1.13. The hangs might happen but something makes them extremely rare for me.

I meant:

and "drm/i915: Agressive downclocking on Baytrail" reversed.

Ok, during third night the OpenGL application had cause hang with 4.2.8.

I will now begint testing how "intel_idle.max_cstate=1" works :)

So far "intel_idle.max_cstate=1" has been working with Ubuntu 4.2.0-23.28 kernel. Uptime is now 2 days 11 hours. I've been playing DVD from the DVD drive, let it run my OpenGL application while streaming online video overnights and also used it for normal web browsing.

Now after over 4 days of uptime with "intel_idle.max_cstate=1" I seemed to have a hang. But that was not the case. Screen was turned off and touching or pressing touchpad didn't bring it back on so I thought it had hanged. Then I decided to try taking ssh connection from my workstation to the ASUS X553MA and it succeed and I was able to reboot it from the ssh shell.

All of the previous "overnight hangs" without "intel_idle.max_cstate=1" happened like this. In the morning I couldn't wake it up using touchpad so I assumed that it had hanged. But I should had also tested if getting connection with ssh would have worked.

But just verified that when it does hang with screen active it is not reachable with ssh via network.

After this I do not have more time to play with this so I conclude that workaroud using kernel command line argument "intel_idle.max_cstate=1" solves the issue for me too.

I'm also affected by this bug. Basically any kernel newer then 3.16 has it. On some kernel versions it runs more on some less stable.

The problem is that even the "intel_idle.max_cstate=1" workaround isn't working on all kernels. I think it is very important to fix this bug. People running Ubuntu 14.04 LTS with the original 3.13 kernel are fine. But once they update to 16.04 and new kernel, their baytrail computers will most likely hang within a few minutes.

I have the same bug in my dell 3531 with debian testing. Also baytrail. I have been going crazy looking for an answer.

FYI I sent the bug to debian as well. They assigned it Bug#818330.

Workaround "intel_idle.max_cstate=1" didn't work completely for me. It did reduce the frequency but the hang eventually returns with the same symptoms.

Patches for Linux 4.4: https://github.com/hadess/rtl8723bs/tree/master/patches
Patches for Linux 4.5: https://github.com/hadess/rtl8723bs/tree/master/patches_4.5

But this won't be enough (this patches doesn't cover all hang cases) so there is more work on this is going on: https://bugzilla.kernel.org/show_bug.cgi?id=109051#c202

Got the same freezes with my ASUS F551 (N2930 Baytrail) - (no more hangs with intel_idle.max_cstate=1 since 2 days)

Interestingly enough I got those freezes after updating from win 8.1 to win10.
In fact, that's why I landed here, because to me it looked like a hardware defect at first sight and my idea was trying a different OS for verification.
Even if it sounds a little weird: It looks like the same bug has made it into Linux AND Windows. Too bad that I don't know how to run Windows with a similar boot option - I'd expect it would fix the problem on that side, too.

I'm on 16.04, kernel 4.4, with the Pentium N3530 CPU and Intel Bay Trail graphics, suffering this same problem. I've implemented the workaround and hopefully that solves the issue because 16.04 has been pretty unusable for me.

I installed 16.04 weeks ago and first hang happened in in less than hour. After that I added the
intel_idle.max_cstate=1 kernel command line parameter and no hangs have happened since.

I have the same problem solved with intel_idle.max_cstate=1

It's not really solved, it's a workaround that makes the machine use more power.
Let's hope that anyone can get intel to fix this?
I am trying to contact people at intel and Canonical to pick this up.
Let's hope someone will act.

A lot of mini pc,tablet x86 and netbooks 2 in 1 have this problem

There's progress for this bug which resulted in this patch:

https://lists.freedesktop.org/archives/intel-gfx/2017-February/120021.html