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.
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 1.6.1.901 - driver : 2.7.99.1+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.
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 1.6.1.901 - driver : 2.7.99.901 - 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.
Created attachment 26828 [details] Register dump after launching X
Created attachment 26829 [details] Register dump after suspend to ram
Created attachment 26830 [details] Xorg.0.log after suspend to ram
Created attachment 26831 [details] Register dump after killing X
Created attachment 26833 [details] Register dump with KMS
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.
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.
Created attachment 26836 [details] Xorg.0.log when xrandr output is corrupted
Created attachment 26837 [details] Register dump when xrandr output is corrupted
Created attachment 26838 [details] Register dump after killing X
Created attachment 26839 [details] Expected xrandr output (after relaunching X)
Created attachment 26840 [details] Xorg.log when xrandr output is correct
Created attachment 26841 [details] Register dump when xrandr output is correct
Created attachment 26842 [details] Dmesg for the whole session
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 !
Grégoire, your fence patch looks like a reasonable thing to do. Can you submit it to intel-gfx@lists.freedesktop.org and cc eric@anholt.net? 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).
Done: http://lists.freedesktop.org/archives/intel-gfx/2009-June/002975.html
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 <henry@pps.jussieu.fr> Signed-off-by: Eric Anholt <eric@anholt.net>
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.