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
Try building with these kconfig settings: https://bugs.freedesktop.org/show_bug.cgi?id=85977#c38
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
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.
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
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.
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
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
Created attachment 127444 [details] 4.9.0-rc1+ drm-intel-nightly I also have added the suggested CONFIGs to the kernel with no luck.
Created attachment 127445 [details] my 4.9.0-rc1+ config
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!
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!
(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.
(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.
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.
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.
Pavel's workaround works for me, both with 4.9rc3 and 4.8.6.
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.
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.
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.
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.
Created attachment 128177 [details] cat /sys/kernel/debug/dri/0/i915_vbt
Output from 4.9-rc4 with both patches that Pavel mentions in comment 15 reverted.
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/
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.
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.
(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?
drm-tip does only turn the screen black. modprobe did finish properly and no time out/oops in dmesg.
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
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.
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.
(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.
(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 :(
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?
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.
Jani, tested drm-tip commit e75e28e88de6cf33423337a64ad377116ae2141c and it works just fine! Yes, comment 30, 31 and 32 is
an follow up error. Sorry, should have filed a new bug. Ville, I'm testing currently with your patch upon drm-tip.
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.
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.