Bug 21710 - [Mac] 945GM with KMS Kernel corrupts VT screen
Summary: [Mac] 945GM with KMS Kernel corrupts VT screen
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 14:34 UTC by Julian
Modified: 2017-07-24 23:10 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Screen (385.60 KB, image/jpeg)
2009-05-12 14:34 UTC, Julian
no flags Details
Register dump after a fresh boot (9.80 KB, text/plain)
2009-06-16 01:39 UTC, Grégoire Henry
no flags Details
Register dump after launching X (9.74 KB, text/plain)
2009-06-16 01:39 UTC, Grégoire Henry
no flags Details
Register dump after suspend to ram (9.72 KB, text/plain)
2009-06-16 01:40 UTC, Grégoire Henry
no flags Details
Xorg.0.log after suspend to ram (30.17 KB, text/plain)
2009-06-16 01:40 UTC, Grégoire Henry
no flags Details
Register dump after killing X (9.72 KB, text/plain)
2009-06-16 01:41 UTC, Grégoire Henry
no flags Details
Register dump with KMS (9.80 KB, text/plain)
2009-06-16 01:43 UTC, Grégoire Henry
no flags Details
Register dump with KMS after a fresh boot (9.80 KB, text/plain)
2009-06-16 01:54 UTC, Grégoire Henry
no flags Details
Unexpected xrandr output (572 bytes, text/plain)
2009-06-16 01:59 UTC, Grégoire Henry
no flags Details
Xorg.0.log when xrandr output is corrupted (20.83 KB, text/plain)
2009-06-16 02:00 UTC, Grégoire Henry
no flags Details
Register dump when xrandr output is corrupted (9.77 KB, text/plain)
2009-06-16 02:01 UTC, Grégoire Henry
no flags Details
Register dump after killing X (9.77 KB, text/plain)
2009-06-16 02:02 UTC, Grégoire Henry
no flags Details
Expected xrandr output (after relaunching X) (626 bytes, text/plain)
2009-06-16 02:03 UTC, Grégoire Henry
no flags Details
Xorg.log when xrandr output is correct (16.34 KB, text/plain)
2009-06-16 02:04 UTC, Grégoire Henry
no flags Details
Register dump when xrandr output is correct (9.77 KB, text/plain)
2009-06-16 02:05 UTC, Grégoire Henry
no flags Details
Dmesg for the whole session (55.30 KB, text/plain)
2009-06-16 02:07 UTC, Grégoire Henry
no flags Details
Initialize fence registers to zero when loading GEM. (604 bytes, patch)
2009-06-17 02:58 UTC, Grégoire Henry
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 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.
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 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.
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 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).
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 <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.