|Summary:||[Mac] 945GM with KMS Kernel corrupts VT screen|
|Component:||DRM/Intel||Assignee:||Jesse Barnes <jbarnes>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||medium||CC:||freedesktop, henry, jcristau, remi|
|i915 platform:||i915 features:|
Description Julian 2009-05-12 14:34:27 UTC
Created attachment 25805 [details] Screen The VT has corrupted pixels at the bottom once the text in that VT reaches the lowest line. (also xorg is not able to start up and shows only a corrupted mouse) type: MacBook 2,1 chipset: 945GM system: i686 packages: xf86-video-intel-2.7.0, xserver-1.6.1, mesa-7.4.1, libdrm-2.4.9 kernel: >=2.6.29 distribution: gentoo Kernel Config: Device Drivers->Graphics Support-> agpart: Intel Chipset Support build in drm: i915 driver with KMS enabled build in support for frame buffer devices: firmware EDID, Video Mode Handling Helpers, Tile Blitting Support build in Reproduceable: On my system with every Kernel that supports KMS :) Not sure of other MacBooks. One MacBook 2,1 Archlinux owner reported a fully functional KMS VT.
Comment 1 Grégoire Henry 2009-05-21 11:07:41 UTC
Same bugs on MacBook1,1 (i686, 945GM) : VT is corrupted and Xorg shows only a corrupted mouse on every kernel with KMS I've tested. But today, at the end of a working session in the following setup : - Debian - kernel: 2.6.29-2 without KMS - Xorg 188.8.131.521 - driver : 184.108.40.206+git+20090521+ad21288 - libdrm : 2.4.11+git+20090519+f355ad8 when I execute the following sequence without restarting : - pkill X - modprobe -r i915 - modprobe i915 modeset=1 everything works fine : VT and Xorg are perfect and stable. I was unable to reproduce after a fresh boot.
Comment 2 Grégoire Henry 2009-06-16 01:39:03 UTC
Created attachment 26827 [details] Register dump after a fresh boot I'm now able to have a correct VT when KMS is enabled. Here is how to reproduce: - macbook1,1: 945GM, i686 - kernel 2.6.29 (Debian) - Xorg 220.127.116.111 - driver : 18.104.22.1681 - libdrm : 2.4.11+git+20090519+f355ad8 0) load i915 without kernel mode-setting 1) start X 2) suspend to ram 3) kill X 4) unload i915 then reload it with kernel mode-setting 5) VT screen is not corrupt. It is still corrupted when KMS is activated at step 0. It does not work when suspending without launching X.
Comment 3 Grégoire Henry 2009-06-16 01:39:49 UTC
Created attachment 26828 [details] Register dump after launching X
Comment 4 Grégoire Henry 2009-06-16 01:40:17 UTC
Created attachment 26829 [details] Register dump after suspend to ram
Comment 5 Grégoire Henry 2009-06-16 01:40:57 UTC
Created attachment 26830 [details] Xorg.0.log after suspend to ram
Comment 6 Grégoire Henry 2009-06-16 01:41:59 UTC
Created attachment 26831 [details] Register dump after killing X
Comment 7 Grégoire Henry 2009-06-16 01:43:10 UTC
Created attachment 26833 [details] Register dump with KMS
Comment 8 Grégoire Henry 2009-06-16 01:54:44 UTC
Created attachment 26834 [details] Register dump with KMS after a fresh boot For information, here is the register dump when KMS is enabled at step 0.
Comment 9 Grégoire Henry 2009-06-16 01:59:32 UTC
Created attachment 26835 [details] Unexpected xrandr output For information, when VT is correct, X seems to be correct and stable. This is not the case when VT is corrupted. But, at first launch Xrandr report wrong resolution, and TV output seems to be wrongly enabled. At second launch, xrandr output is the expected one.
Comment 10 Grégoire Henry 2009-06-16 02:00:10 UTC
Created attachment 26836 [details] Xorg.0.log when xrandr output is corrupted
Comment 11 Grégoire Henry 2009-06-16 02:01:38 UTC
Created attachment 26837 [details] Register dump when xrandr output is corrupted
Comment 12 Grégoire Henry 2009-06-16 02:02:54 UTC
Created attachment 26838 [details] Register dump after killing X
Comment 13 Grégoire Henry 2009-06-16 02:03:44 UTC
Created attachment 26839 [details] Expected xrandr output (after relaunching X)
Comment 14 Grégoire Henry 2009-06-16 02:04:57 UTC
Created attachment 26840 [details] Xorg.log when xrandr output is correct
Comment 15 Grégoire Henry 2009-06-16 02:05:39 UTC
Created attachment 26841 [details] Register dump when xrandr output is correct
Comment 16 Grégoire Henry 2009-06-16 02:07:19 UTC
Created attachment 26842 [details] Dmesg for the whole session
Comment 17 Grégoire Henry 2009-06-17 02:58:16 UTC
Created attachment 26883 [details] [review] Initialize fence registers to zero when loading GEM. Initializing fence registers to zero fixed the corruption on my computer, here the patch I've used. Then I need to apply commit 03d6069912babc07a3da20e715dd6a5dc8f0f867 to get TV correctly detected as disconnected (bug #21204). With those patches, I've eventually achieve to use X with KMS and an EFI bootloader, then play tuxracer at 30 FPS !
Comment 18 Jesse Barnes 2009-06-22 15:24:58 UTC
Grégoire, your fence patch looks like a reasonable thing to do. Can you submit it to email@example.com and cc firstname.lastname@example.org? Just follow the instructions in Documentation/SubmittingPatches in your kernel tree... It would be best if you could add 965 and pre-945 support to it as well though (there's other fence code you can look at for an example, like the suspend/resume stuff).
Comment 19 Grégoire Henry 2009-06-23 07:31:41 UTC
Comment 20 Eric Anholt 2009-06-23 09:39:25 UTC
queued, thanks! commit b5aa8a0fc132dd512c33e7c2621d075e3b77a65e Author: Grégoire Henry <Gregoire.Henry@pps.jussieu.fr> Date: Tue Jun 23 15:41:02 2009 +0200 drm/i915: initialize fence registers to zero when loading GEM Unitialized fence register could leads to corrupted display. Problem encountered on MacBooks (revision 1 and 2), directly booting from EFI or through BIOS emulation. (bug #21710 at freedestop.org) Signed-off-by: Grégoire Henry <email@example.com> Signed-off-by: Eric Anholt <firstname.lastname@example.org>