Bug 96540 - Celeron N3150 : random display off instants and occasional full-system freezes
Summary: Celeron N3150 : random display off instants and occasional full-system freezes
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-15 18:21 UTC by René J.V. Bertin
Modified: 2017-01-03 15:58 UTC (History)
3 users (show)

See Also:
i915 platform: BSW/CHT
i915 features:


Attachments
lspci -v (6.42 KB, text/plain)
2016-06-15 18:21 UTC, René J.V. Bertin
no flags Details
kern.log with 4.6.2 (81.74 KB, text/x-log)
2016-06-19 18:28 UTC, René J.V. Bertin
no flags Details
dmesg, kernel 4.6.2 (116.01 KB, text/x-log)
2016-06-19 18:29 UTC, René J.V. Bertin
no flags Details

Description René J.V. Bertin 2016-06-15 18:21:18 UTC
Created attachment 124548 [details]
lspci -v

I've taken a new notebook into service, a Clevo W510LU with Intel Celeron N3150 (Cherryview/Braswell graphics), 8Gh RAM. Currently I'm running an updated Kubuntu 14.04.4LTS with

- mainline kernel 4.5.6, home-built
- Ubuntu's LTS-Wily versions of the Xorg (1.17.2) and Mesa (11.0.2), including the XOrg Intel drivers 2:2.99.917+git20150808-0ubuntu4~trusty2, and libxcb-dri3 1.10-2ubuntu1 .

I have several issues that seem to correspond to what others are reporting:
- at random times the display will turn off while I'm typing, as if I use the Fn-F2 shortcut which is supposed to do exactly that. Just as with that feature, a stroke on the touchpad turns the screen back on, nothing else.
- the screen turns off after a period of inactivity, not sure if and how that's related to the screensaver. Audio-over-hdmi continues when that happens. XDPMS is off.
- Once or twice the screen turned off and wouldn't come back on, except after suspending and waking the machine
- From time to time the whole machine freezes. This has only happened until now when doing a biggish compile job, but the last time it happened it shouldn't have been related to overheating (fans were barely running).

The difference with what others report is that I get no feedback whatsoever in my logs or dmesg. I do see an occasional 

[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

but I cannot yet confirm if that's related to any of the events mentioned above.

I'll be trying the UXA suggestion mentioned here: https://bbs.archlinux.org/viewtopic.php?pid=1533863#p1533863 but if there are other things I could do other than wait for an updated i915 driver I'd love to know.
Comment 1 Jani Nikula 2016-06-16 06:55:17 UTC
(In reply to René J.V. Bertin from comment #0)
> - mainline kernel 4.5.6, home-built

Please try 4.6.2 or newer.
Comment 2 René J.V. Bertin 2016-06-16 09:59:44 UTC
Building right now, will take >3h on my hardware.

In the meantime, is there somewhere where one can see exactly what classifies as "preliminary hardware" w.r.t. a kernel release?
Comment 3 Jani Nikula 2016-06-16 12:19:32 UTC
(In reply to René J.V. Bertin from comment #2)
> Building right now, will take >3h on my hardware.

Feels like you must be doing something wrong. For trying out stuff, it's usually not necessary to use the full distro config, for example.

> In the meantime, is there somewhere where one can see exactly what
> classifies as "preliminary hardware" w.r.t. a kernel release?

It's more like "preliminary support" for certain hardware in certain kernel versions. There's no table or anything you could look at, though one could certainly be created.

See drivers/gpu/drm/i915/i915_drv.c and look for .is_preliminary = 1 to see for which platforms the support is still considered preliminary (in the kernel sources you have).

'git log --grep=preliminary -- drivers/gpu/drm/i915/i915_drv.c' will give you a fairly accurate list of when the support was considered good enough not to be preliminary for each platform.

'git tag --contains <commit-id> | grep "^v" | sort -V | head -1' on a commit-id to see which kernel release that happened.
Comment 4 René J.V. Bertin 2016-06-16 13:14:24 UTC
Oh, I know I could build a minimal kernel, but I was planning to upgrade to 4.6x anyway once it hit 4.6.2 or above, also for the wife's machine which has a 6th gen i3 and thus stands to gain even more from a newer kernel. And which doesn't mind churning away on the build while I use my system for other things.

I'll have a look at your "preliminary suggestions" and see if that tells me things that I know how to link to specific hardware that actually means something to me. I search the 4.6.2 changelog for i915 already, and that only confirmed that quite a few issues were addressed ^^
Comment 5 René J.V. Bertin 2016-06-16 13:16:16 UTC
One other thing: I've been presuming that my Celeron won't choke on code compiled with -march=core2 - not mistakingly I hope?
Comment 6 René J.V. Bertin 2016-06-16 15:01:45 UTC
I just noticed this while creating the 4.6.2 initrd:

W: Possible missing firmware /lib/firmware/i915/skl_guc_ver4.bin for module i915

Supposing that's a relevant missing file, where could I find it? I have these:

> ls /lib/firmware/i915/
bxt_dmc_ver1_04.bin  skl_dmc_ver1_19.bin  skl_dmc_ver1_21.bin  skl_guc_ver1_1059.bin
bxt_dmc_ver1.bin     skl_dmc_ver1_20.bin  skl_dmc_ver1.bin     skl_guc_ver1.bin
Comment 7 Jani Nikula 2016-06-16 15:08:07 UTC
(In reply to René J.V. Bertin from comment #6)
> I just noticed this while creating the 4.6.2 initrd:
> 
> W: Possible missing firmware /lib/firmware/i915/skl_guc_ver4.bin for module
> i915
> 
> Supposing that's a relevant missing file, where could I find it? I have
> these:
> 
> > ls /lib/firmware/i915/
> bxt_dmc_ver1_04.bin  skl_dmc_ver1_19.bin  skl_dmc_ver1_21.bin 
> skl_guc_ver1_1059.bin
> bxt_dmc_ver1.bin     skl_dmc_ver1_20.bin  skl_dmc_ver1.bin    
> skl_guc_ver1.bin

Only relevant for Skylake. It should be in linux-firmware or https://01.org/linuxgraphics/downloads
Comment 8 René J.V. Bertin 2016-06-16 17:40:09 UTC
Well, that was a painful experience. I installed the 4.6.2 kernel plus the 1.57 firmware (cf. https://bbs.archlinux.org/viewtopic.php?pid=1533863#p1533863), rebooted. Apart from the illegible text during the initial initrd loading which 4.6.2 didn't change all looked fine until I was about to come report here.

Switching tabs a couple of times my display froze except for the mouse cursor. I tried the sleep/wake trick, and saw something about the GPU being banned for some reason on the virtual terminal, and then when back in X11 everything started to flicker until, apparently, KWin crashed. I coud quit most KDE apps, but Chrome no longer responded to keystrokes.

I booted back into 4.5.6, and had similar things happen; compositing effect no longer worked, switching to a virtual terminal and back to X11 gave me a black screen, and those are just the dysfunctions I remember. It took multiple reboots and quite a bit of trial and error to get back to where I came from. I tried one last time with 4.6.2, and again everything was fine until I started Chrome. This time I just let it start, and at some point KWin crashed and Chrome again couldn't be quit.

I've put back the firmware files I had before, and kicked 4.6.2 off the system (even if I know it shouldn't be required).

My next attempt will be to test the UXA acceleration again. Clearly 4.6.2 isn't ripe yet for my hardware (it seems to run fine on the wife's i3). Normally I wouldn't mind filing bug reports and testing patches, but not if it's so hard to get back to a working state.
Comment 9 René J.V. Bertin 2016-06-19 18:27:42 UTC
I've tried once more, this time from the external boot/install I use with the i3 laptop (which also excludes potential artefacts from running off a ZFS pool).

Same thing: as soon as I started Chrome and surfed to youtube.com I started getting problems. I'll be attaching kern.log and dmesg output; it looks like 4.6.2 causes GPU crashes as a result of certain compositing (DRI) operations. The crashing PID mentioned in kern.log is the X server.
Comment 10 René J.V. Bertin 2016-06-19 18:28:44 UTC
Created attachment 124605 [details]
kern.log with 4.6.2
Comment 11 René J.V. Bertin 2016-06-19 18:29:18 UTC
Created attachment 124606 [details]
dmesg, kernel 4.6.2
Comment 12 Jani Saarinen 2016-12-09 10:55:24 UTC
Reporter, is this still issue with latest kernel?
Comment 13 René J.V. Bertin 2016-12-09 11:32:20 UTC
I can't tell, I've been too busy with other things to follow kernel development on a secondary install. My main installation runs off a ZFS root which for now keeps me at the 4.5 kernel series, currently 4.5.7 which runs fine. I'm hoping the pending 4.7+ support will land soon in an official ZoL release.

I do think though that the full-system freezes were unrelated to graphics, but the result of thermald trying to throttle down the CPU.
Comment 14 René J.V. Bertin 2016-12-27 09:15:58 UTC
I have now been able to update my ZFS drivers, build, install and test the 4.8.15 kernel for a while.

No display deactivations, no freezes.

As I said in my previous comment, the freezes were most likely due to the thermald. I stopped getting them when I uninstalled thermald, and since this is a notebook where thermal and energy control is handled fully by the firmware I'm not seeing overheating problems either.

I haven't had display deactivations for a while either, probably since I upgraded to Ubuntu's lts-xenial Xorg and Mesa.

I'm closing this as fixed (would be nice to know what was fixed of course). I hope I won't have to reopen it when I try 4.9.2 ;)
Comment 15 yann 2017-01-03 15:58:47 UTC
(In reply to René J.V. Bertin from comment #14)
> I have now been able to update my ZFS drivers, build, install and test the
> 4.8.15 kernel for a while.
> 
> No display deactivations, no freezes.
> 
> As I said in my previous comment, the freezes were most likely due to the
> thermald. I stopped getting them when I uninstalled thermald, and since this
> is a notebook where thermal and energy control is handled fully by the
> firmware I'm not seeing overheating problems either.
> 
> I haven't had display deactivations for a while either, probably since I
> upgraded to Ubuntu's lts-xenial Xorg and Mesa.
> 
> I'm closing this as fixed (would be nice to know what was fixed of course).
> I hope I won't have to reopen it when I try 4.9.2 ;)

thanks René for your feedback and confirmation.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.