Bug 97529 - i915 kms turns display black on Asus T100HA (Intel Atom x5-Z8500)
Summary: i915 kms turns display black on Asus T100HA (Intel Atom x5-Z8500)
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2016-08-29 08:26 UTC by Pavel
Modified: 2017-06-02 20:12 UTC (History)
6 users (show)

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


Attachments
dmesg output from drm-intel-nightly 4.8-rc3 (97.46 KB, text/plain)
2016-08-29 08:26 UTC, Pavel
no flags Details
dmesg output from drm-intel-nightly 4.8-rc3 - new config (86.90 KB, text/plain)
2016-08-29 13:49 UTC, Pavel
no flags Details
dmesg after "drm/i915: Ignore OpRegion panel type except on select machines" (84.82 KB, text/plain)
2016-09-18 01:32 UTC, Elie Morisse
no flags Details
4.9.0-rc1+ drm-intel-nightly (3.77 KB, text/plain)
2016-10-21 04:03 UTC, rafael cepeda
no flags Details
my 4.9.0-rc1+ config (111.98 KB, text/plain)
2016-10-21 04:06 UTC, rafael cepeda
no flags Details
patch for T100HA against 874703062650d24d701aa79e6ab25bc14ace0475 (2.03 KB, patch)
2016-10-31 15:01 UTC, Pavel
no flags Details | Splinter Review
cat /sys/kernel/debug/dri/0/i915_vbt (1.71 KB, application/x-bzip2)
2016-11-24 11:18 UTC, Jonas Aaberg
no flags Details
patch for T100HA against 9a2f9111a94a851e53bad3fd6a92f77dbd3a95e2 (13.24 KB, patch)
2016-12-11 11:16 UTC, Pavel
no flags Details | Splinter Review
[PATCH] drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail (4.91 KB, patch)
2016-12-13 21:00 UTC, Ville Syrjala
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel 2016-08-29 08:26:43 UTC
Created attachment 126095 [details]
dmesg output from drm-intel-nightly 4.8-rc3

Hi,
I have a problem on my Asus T100HA (Intel Atom x5-Z8500, Intel HD Graphics Gen 8-LP) with i915 driver. After modeset (kms) the display turns black until reboot. The situation is the same when I boot without nomodest or with it and reload the i915 module with modeset=1. I am using Debian and kernel build from drm-intel-nightly from last week (commit 30de872fd5cf71a51994375fb4f76856c05b1c4c) – 4.8.0-rc3+, architecture is x86_64. The dmesg output is attached – it is from boot without nomodeset and with drm.debug=0x1e parameter.   

There are several timeouts, so I guess there could some problem with some irq. I`ve tried to find what could be wrong but the code is too unknown for me. Please let me know if I can provide some more diagnostics, test some patches etc. I`ll be happy to help to make this work.

Thank you

Pavel
Comment 1 Jani Nikula 2016-08-29 09:01:22 UTC
Try building with these kconfig settings:

https://bugs.freedesktop.org/show_bug.cgi?id=85977#c38
Comment 2 Pavel 2016-08-29 13:49:55 UTC
Created attachment 126099 [details]
dmesg output from drm-intel-nightly 4.8-rc3 - new config

dmesg with followin options:
CONFIG_PWM=y
CONFIG_PWM_CRC=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_PCI=y
CONFIG_INTEL_SOC_PMIC=y
CONFIG_DRM_I915=m
Comment 3 Pavel 2016-08-29 13:51:44 UTC
Hi, 
I tried those options, the result is the same, please, see the attached dmesg. One positive detail is, that the backlight control started to work :) but otherwise there is still no image, just black screen.
Comment 4 Pavel 2016-09-07 10:22:05 UTC
Unfortunately I have to correct my previous statement. The backlight control is not working even with those options. The error message "Failed to own the pwm chip" disappeared and the file /sys/class/backlight/intel_backlight/brightness is present and writable, but backlight doesn`t change after writing any value in it.  I`ll do some more tests, maybe I am doing something wrong. The only kernel I`ve found which has working backlight control is this http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-rc5-unstable , but there is also no image after kms.

I`ve also tested yesterdays drm-intel-nightly (507a1d98d13f18acd36d9b81f4b316a3f79af00e 4.8.0-rc4+) and the behavior is still the same.

Please let me know if I can help with this somehow.

Thanks

Pavel
Comment 5 Pavel 2016-09-14 19:46:03 UTC
I have to correct again my previous statement. The backlight control works with those options on 4.8.0-rc3, just the computer is terribly slowed down and finally it freezes (that is why I thought that the backlight control doesn`t work). I suppose that it is related to those timeouts. I saw several more of them in dmesg. With the kernel, which I mentioned in my prevoius post (v4.3-rc5-unstable), works the trick described here https://bugs.freedesktop.org/show_bug.cgi?id=94807 (only the output name is DSI-1 not DSI1). I wasn`t able to do the same with 4.8.0-rc3, because the computer froze. I am planning to test the actual drm-intel-nightly, I`ll post the result.
Comment 6 Elie Morisse 2016-09-18 01:32:13 UTC
Created attachment 126596 [details]
dmesg after "drm/i915: Ignore OpRegion panel type except on select machines"

https://cgit.freedesktop.org/drm-intel/commit/?id=ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 sounded promising and got rid of the warnings about display timings but still results in a black screen with new errors:

[    6.680073] WARNING: CPU: 1 PID: 6 at drivers/gpu/drm/i915/intel_display.c:14141 intel_atomic_commit_tail+0x111a/0x1120 [i915]
[    6.680074] pipe A vblank wait timed out

[   27.111348] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:26:pipe A] flip_done timed out
[   37.351009] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:26:pipe A] flip_done timed out
Comment 7 rafael cepeda 2016-10-21 02:40:52 UTC
I am also having this exact same error on my dell

[    4.054901] WARNING: CPU: 0 PID: 423 at drivers/gpu/drm/i915/intel_display.c:1782 vlv_wait_port_ready+0xa8/0xe0
[    4.054903] timed out waiting for port C ready: got 0x20, expected 0xe0
[    4.054907] CPU: 0 PID: 423 Comm: kworker/u4:2 Not tainted 4.8.2-gentoo #4
[    4.054909] Hardware name: Dell Inc. Inspiron 14-3452/0HHRWV, BIOS 4.0.11 08/24/2016
Comment 8 rafael cepeda 2016-10-21 04:03:56 UTC
Created attachment 127444 [details]
4.9.0-rc1+ drm-intel-nightly

I also have added the suggested CONFIGs to the kernel with no luck.
Comment 9 rafael cepeda 2016-10-21 04:06:25 UTC
Created attachment 127445 [details]
my 4.9.0-rc1+ config
Comment 10 rafael cepeda 2016-10-21 04:10:14 UTC
My laptop goes to turn on, in boots up, I see a couple lines of output. Then the screen goes black indefinitely. The only way to get the laptop screen on is by connecting an external display (hdmi in my case) and then removing said external display. Needless to say, my laptop is useless without an external monitor around. Which is not too much of an issue because my laptop is used like a desktop pc anyway. I am willing to follow this issue and help in any way I can. Thanks! BTW the nightly i915 has really nice colors and rendering my fonts look way smoother and the colors look way better now. my urxvt is now rendering fast!
Comment 11 rafael cepeda 2016-10-21 05:45:21 UTC
This is strange, I was able to get my screen working simply by disabling "Legacy ROM" in my BIOS. I checked dmseg, no more issues. My system appears to be more responsive too. Hope this helps!
Comment 12 rafael cepeda 2016-10-21 05:53:02 UTC
(In reply to rafael cepeda from comment #11)
> This is strange, I was able to get my screen working simply by disabling
> "Legacy ROM" in my BIOS. I checked dmseg, no more issues. My system appears
> to be more responsive too. Hope this helps!

I have double verified this by toggling the "Load Legacy ROM" option and rebooting multiple times and checking dmesg.
Comment 13 Jani Nikula 2016-10-21 09:51:15 UTC
(In reply to rafael cepeda from comment #11)
> This is strange, I was able to get my screen working simply by disabling
> "Legacy ROM" in my BIOS. I checked dmseg, no more issues. My system appears
> to be more responsive too. Hope this helps!

This is neither strange nor surprising. It's likely only UEFI boot was tested with the Windows the machine presumably came preinstalled. I can't recommend legacy boot for any modern hardware.
Comment 14 Jonas Aaberg 2016-10-25 07:22:10 UTC
I managed to make a duplicate bug report on the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=180041

Short summary, i915 works sometimes on 4.7, never on 4.8.
Comment 15 Pavel 2016-10-31 15:01:32 UTC
Created attachment 127640 [details] [review]
patch for T100HA against 874703062650d24d701aa79e6ab25bc14ace0475

Hi,
I`ve done some bisecting and found two problematic commits - a0a6d4ffd2adc76c192ebe7ef89b81e3f2f4a078 and ea0000f0d369a59c2086fe9c489e0a2a86e080ba. Without any deeper analyses I created a patch which simply reverts them.  With this patch today drm-nightly (commit 874703062650d24d701aa79e6ab25bc14ace0475, 4.9.0) works on ASUS T100HA with this trick:

DISPLAY=:0 xrandr --output DSI-1 --off
sleep 1
DISPLAY=:0 xrandr --output DSI-1 --auto

Maybe even without, I have to do more tests. I have Xorg running with kms and I can control brightness.
Comment 16 Jonas Aaberg 2016-11-03 13:12:10 UTC
Pavel's workaround works for me, both with 4.9rc3 and 4.8.6.
Comment 17 Elie Morisse 2016-11-07 23:56:05 UTC
Awesome find once again Pavel! I can confirm that it is working, although the kernel often crashes during the Xorg startup, and my KDE session always freezes at some point, after a few minutes or up to a few hours of usage. It can stay up for more than a day however if I don't use it. All of this with intel_idle.max_cstate=1 set.
Comment 18 Jonas Aaberg 2016-11-08 06:27:58 UTC
Elie, I use DWM (http://dwm.suckless.org/) which is very light weight with no fancy stuff, and I've had zero crashes (except the time outs at modprobe which xrandr fixes) since I've started with Pavel's workaround. And my Asus T100HA have been powered on for about 14h/day (used maybe 4-5h) for the last week.
I get 8h+ before I need to attach the charger.
I have not set cstates. But I've not ran anything that uses opengl.
Comment 19 Jim Rees 2016-11-20 20:42:12 UTC
I've got a patch against 4.8.9 that reverts ea0000f0d369a59c2086fe9c489e0a2a86e080ba, which is also causing problems for other i915 equipped laptops. It's at Bug 96781.
Comment 20 Jani Nikula 2016-11-23 15:29:32 UTC
Pavel, and anyone for whom reverting a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") helps:

Please attach /sys/kernel/debug/dri/0/i915_vbt.
Comment 21 Jonas Aaberg 2016-11-24 11:18:00 UTC
Created attachment 128177 [details]
cat /sys/kernel/debug/dri/0/i915_vbt
Comment 22 Jonas Aaberg 2016-11-24 11:19:12 UTC
Output from 4.9-rc4 with both patches that Pavel mentions in comment 15 reverted.
Comment 23 Jani Nikula 2016-12-05 09:29:36 UTC
Please try this series on top of v4.9-rc8 or drm-tip branch of https://cgit.freedesktop.org/drm-tip

https://patchwork.freedesktop.org/series/16242/
Comment 24 Jonas Aaberg 2016-12-05 13:02:08 UTC

The patch series didn't help on my T100HAN. I will ssh and see if I can get a dmesg out.

I did apply the patch series on 4.9rc8. I had to manually resolve some patches, all trivial, but one patch wanted to remove more code that was there.
So there are possibilities that I broke something, and/or that 4.9-rc8 includes/misses something that drm-tip has/hasn't.

I'll set up a build on drm-tip to test with as well.
Comment 25 Jonas Aaberg 2016-12-07 11:29:46 UTC
I applied the patch series upon drm-tip, commit 7955526172a2154393986eb78de44e61cabd81f3
and they work just fine! :-)

I rebooted and modprobe'd i915 seven-eight times, and it worked every time.

Thanks a lot!!

There were still some minor conflicts, different from rc8.
Comment 26 Jani Nikula 2016-12-07 13:12:54 UTC
(In reply to Jonas Aaberg from comment #25)
> I applied the patch series upon drm-tip, commit
> 7955526172a2154393986eb78de44e61cabd81f3
> and they work just fine! :-)
> 
> I rebooted and modprobe'd i915 seven-eight times, and it worked every time.
> 
> Thanks a lot!!
> 
> There were still some minor conflicts, different from rc8.

Thanks for testing. How does just plain drm-tip fare, without any patches on top?
Comment 27 Jonas Aaberg 2016-12-07 15:04:58 UTC
drm-tip does only turn the screen black. modprobe did finish properly and no time out/oops in dmesg.
Comment 28 Andre Heider 2016-12-09 09:46:29 UTC
Can we please get a revert of ea0000f0d369a59c2086fe9c489e0a2a86e080ba posted to the current stable kernels until the series in comment #23 lands?

Thanks in advance,
Andre
Comment 29 Pavel 2016-12-11 11:16:32 UTC
Created attachment 128410 [details] [review]
patch for T100HA against 9a2f9111a94a851e53bad3fd6a92f77dbd3a95e2

I confirm Jonas Aabergs results and to make the patching easier I attached full patch to be applied against drm-tip commit 9a2f9111a94a851e53bad3fd6a92f77dbd3a95e2.
Comment 30 Jonas Aaberg 2016-12-13 10:15:31 UTC
I get a few error prints from time to time:
--
[  264.110049] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=13947 end=13948) time 14 us, min 1272, max 1279, scanline start 1280, end 1282
[  974.205415] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=56621 end=56622) time 14 us, min 1272, max 1279, scanline start 1280, end 1281
[ 1007.285699] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=58609 end=58610) time 12 us, min 1272, max 1279, scanline start 1280, end 1281
[ 1738.181215] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=102533 end=102534) time 18 us, min 1272, max 1279, scanline start 1280, end 1282
[ 2140.719325] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=126724 end=126725) time 14 us, min 1272, max 1279, scanline start 1280, end 1282
[ 2189.495157] perf: interrupt took too long (3161 > 2500), lowering kernel.perf_event_max_sample_rate to 63000
[ 2215.699125] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=131230 end=131231) time 11 us, min 1272, max 1279, scanline start 1280, end 1280
[ 2371.366424] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=140585 end=140586) time 16 us, min 1272, max 1279, scanline start 1280, end 1283
[ 2573.159594] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=152712 end=152713) time 8 us, min 1272, max 1279, scanline start 1280, end 1280
[ 2584.990646] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=153423 end=153424) time 10 us, min 1272, max 1279, scanline start 1280, end 1282
[ 2612.613070] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=155083 end=155084) time 12 us, min 1272, max 1279, scanline start 1280, end 1282
[ 6636.810230] perf: interrupt took too long (3960 > 3951), lowering kernel.perf_event_max_sample_rate to 50400
[ 7502.095591] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=56156 end=56157) time 13 us, min 1272, max 1279, scanline start 1280, end 1283
[ 7688.813003] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=67377 end=67378) time 12 us, min 1272, max 1279, scanline start 1280, end 1280
[ 7826.841908] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=75672 end=75673) time 16 us, min 1272, max 1279, scanline start 1280, end 1282
[ 7884.332997] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=79127 end=79128) time 13 us, min 1272, max 1279, scanline start 1280, end 1282
[ 8303.544507] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=104320 end=104321) time 11 us, min 1272, max 1279, scanline start 1280, end 1280
[ 8304.592885] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=104383 end=104384) time 13 us, min 1272, max 1279, scanline start 1280, end 1281
[ 8388.040672] perf: interrupt took too long (5142 > 4950), lowering kernel.perf_event_max_sample_rate to 38700
[ 8891.835131] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=139674 end=139675) time 15 us, min 1272, max 1279, scanline start 1280, end 1281
[ 8952.404675] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=143314 end=143315) time 14 us, min 1272, max 1279, scanline start 1280, end 1282
[ 9156.877055] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=155602 end=155603) time 15 us, min 1272, max 1279, scanline start 1280, end 1283
[ 9172.085946] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=156516 end=156517) time 12 us, min 1272, max 1279, scanline start 1280, end 1280
--

However, I don't  notice anything.
Comment 31 Ville Syrjala 2016-12-13 14:09:45 UTC
(In reply to Jonas Aaberg from comment #30)
> I get a few error prints from time to time:
> --
> [  264.110049] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update
> failure on pipe A (start=13947 end=13948) time 14 us, min 1272, max 1279,
> scanline start 1280, end 1282

Interesting. That would suggest that scanline_offset is a bit off for DSI. I'll fire up intel_display_poller on my DSI machine and see what it says.
Comment 32 Ville Syrjala 2016-12-13 14:39:21 UTC
(In reply to Ville Syrjala from comment #31)
> (In reply to Jonas Aaberg from comment #30)
> > I get a few error prints from time to time:
> > --
> > [  264.110049] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update
> > failure on pipe A (start=13947 end=13948) time 14 us, min 1272, max 1279,
> > scanline start 1280, end 1282
> 
> Interesting. That would suggest that scanline_offset is a bit off for DSI.
> I'll fire up intel_display_poller on my DSI machine and see what it says.

Oh dear. It looks like the frame counter increments somewhere in the middle of the line rather than at the start of hsync like it does on every other output type :(
Comment 33 Jani Nikula 2016-12-13 15:04:15 UTC
So there are a few recent-ish patches that were committed after comment #27, which should fix a bunch of CHV DSI issues:

b2b45fcd921e drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
2b8208ac93be drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
721d484563e1 drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

Please try current drm-tip again.

It seems to me comment #30, comment #31 and comment #32 are something else?
Comment 34 Ville Syrjala 2016-12-13 21:00:57 UTC
Created attachment 128453 [details] [review]
[PATCH] drm/i915: Workaround VLV/CHV DSI scanline counter hardware  fail

This should hopefully cure the atomic update fails. Please give it a go.
Comment 35 Jonas Aaberg 2016-12-14 08:16:28 UTC
Jani, tested drm-tip commit e75e28e88de6cf33423337a64ad377116ae2141c
and it works just fine!
Yes, comment 30, 31 and 32 is
Comment 36 Jonas Aaberg 2016-12-14 08:18:07 UTC
an follow up error. Sorry, should have filed a new bug.

Ville, I'm testing currently with your patch upon drm-tip.
Comment 37 Jani Nikula 2016-12-14 12:00:59 UTC
Jonas, thanks for the follow up. Kindly please file a new bug, with your comment #30 as the report, add a link back to this bug, and attach Ville's patch. I'm closing this one as fixed.
Comment 38 Elie Morisse 2017-01-06 23:22:26 UTC
Thanks to the attached dmesg I finally found why the X server was still crashing the laptop at launch, or after a few minutes, or a few hours at most : newer BIOSes. I reverted the BIOS from 221 to 214 (only version available on the ASUS website before 220), and I haven't gotten a crash for days, my T100HA is finally usable, thank you Pavel, Jonas and Intel!

Asus' Winflash doesn't allow downgrading to an earlier BIOS version, unless it's launched with: "Winflash.exe /nodate"


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.