Bug 32078 - Intel N10 graphics does not initialise correctly if GRUB hands off the display in a graphics mode
Summary: Intel N10 graphics does not initialise correctly if GRUB hands off the displa...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: highest major
Assignee: Chris Wilson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-03 06:26 UTC by Andy Whitcroft
Modified: 2016-09-23 09:53 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
Intel register dump in early boot with GRUB using text mode (8.43 KB, text/plain)
2010-12-03 06:29 UTC, Andy Whitcroft 		no flags Details
Intel register dump in early boot with GRUB using graphics mode (8.43 KB, text/plain)
2010-12-03 06:30 UTC, Andy Whitcroft 		no flags Details
Intel register dump at gdm prompt, display solid purple (8.67 KB, text/plain)
2010-12-03 06:30 UTC, Andy Whitcroft 		no flags Details
Intel register dump at gdm prompt following suspend/resume cycle, display normal (8.63 KB, text/plain)
2010-12-03 06:31 UTC, Andy Whitcroft 		no flags Details
Sanitize modesetting registers. (2.43 KB, patch)
2010-12-03 07:43 UTC, Chris Wilson 		no flags Details | Splinter Review
Sanitize modesetting registers.(v2) (2.44 KB, patch)
2010-12-03 07:53 UTC, Chris Wilson 		no flags Details | Splinter Review
View All

Description Andy Whitcroft 2010-12-03 06:26:34 UTC 
When grub2 starts the kernel it may hand off the VGA controller either initialised in text or graphics mode, up till now text has been the common case.  When handing off the console in graphics mode the display is not correctly initialised by the intel i915 kernel driver leading to either an all black or all purple display (it is likely this is a corner of the background colour which X is attempting to display on the framebuffer at the time).  gdm starts normally and if you type blind you can login, the display does not change.  If you then suspend and resume the machine the display is restored to normal.

As recommended I have picked up intel_reg_dumper dumps for the display as handed off from GRUB in both text and graphics mode and dumps when the display is solid purple and when it is working.

Looking at the difference between the GRUB text mode and the GRUB graphics mode dumps it appears there is very little difference:

$ diff -u GRUB-TEXT GRUB-GRAPHICS
[...]
-            DSPBBASE: 0x00000000
+            DSPBBASE: 0x0012c000
[...]

And although there are a number of other differences between the purple and working dumps, there is a similar discrepancy:


$ diff -u PURPLE-DUMP WORKING-DUMP  | grep BASE
-            DSPBBASE: 0x0012c000
+            DSPBBASE: 0x00000000

Could this register account for the behaviour differences. I will attach these dumps below.  All of this is testing with grub 1.99 and with v2.6.37-rc3 of the kernel.
Comment 1 Andy Whitcroft 2010-12-03 06:29:25 UTC 
Created attachment 40771 [details]
Intel register dump in early boot with GRUB using text mode
Comment 2 Andy Whitcroft 2010-12-03 06:30:09 UTC 
Created attachment 40772 [details]
Intel register dump in early boot with GRUB using graphics mode
Comment 3 Andy Whitcroft 2010-12-03 06:30:55 UTC 
Created attachment 40773 [details]
Intel register dump at gdm prompt, display solid purple
Comment 4 Andy Whitcroft 2010-12-03 06:31:39 UTC 
Created attachment 40774 [details]
Intel register dump at gdm prompt following suspend/resume cycle, display normal
Comment 5 Chris Wilson 2010-12-03 06:58:48 UTC 
I think the key clue is the FIFO_UNDERRUN on pipe B.

BIOS starts on pipe A, plane A (probably).
grub2 switches to pipe B, plane B (though neither plane is actually enabled!)
i915.ko starts on pipe B, plane A.

My hypothesis is that we fail to actually teardown the state correctly (because it doesn't match our pipe/plane coupling) so there is a small window where the registers are misconfigured, leading to undefined behaviour.
Comment 6 Chris Wilson 2010-12-03 07:43:51 UTC 
Created attachment 40777 [details] [review]
Sanitize modesetting registers.
Comment 7 Chris Wilson 2010-12-03 07:53:55 UTC 
Created attachment 40778 [details] [review]
Sanitize modesetting registers.(v2)

Second version that should hopefully not also clear a uninitialised plane.
Comment 8 Andy Whitcroft 2010-12-03 09:37:36 UTC 
I have pulled the V2 patch and tested it on the affected hardware.  Over 30 reboots I have had no failures at all, all consistantly displaying the gdm screen as expected.  Without the patch we are 0/5 for a warm reboot.

Thank you for your work on this:

Tested-by: Andy Whitcroft <apw@canonical.com>
Comment 9 Chris Wilson 2010-12-04 16:36:21 UTC 
I've pushed the patch to -fixes and will be sending a pull request to Dave in a couple of days if nothing turns up.

Thanks.

commit 47f1c6c9ffdec0c0e5a2c2709bd63c7380b325c4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Dec 3 15:37:31 2010 +0000

    drm/i915: Clean conflicting modesetting registers upon init
    
    If we leave the registers in a conflicting state then when we attempt
    to teardown the active mode, we will not disable the pipes and planes
    in the correct order -- leaving a plane reading from a disabled pipe and
    possibly leading to undefined behaviour.
    
    Reported-and-tested-by: Andy Whitcroft <apw@canonical.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32078
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@kernel.org
Comment 10 Jari Tahvanainen 2016-09-23 09:53:04 UTC 
Andy did verify, and couple days have gone and nothing turned up ... closing.

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.