Bug 35635

Summary: Booting with vga=0x0F04 results in garbage on the screen when drm driver starts
Product: DRI Reporter: Rick Bramley <richard.bramley>
Component: DRM/IntelAssignee: Chris Wilson <chris>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: jbarnes
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Blurred Screen video
none
Move the irq queue init onto the rings
none
Disable outputs first none

Description Rick Bramley 2011-03-24 12:22:10 UTC
When the kernel is given control the video mode is 1024x768x32 and linear frame buffer mode.   With vga=0x0f04 the mode doesn't get changed early in the kernel and then when drm initialization occurs garbage appears on the screen.

In earlier versions (from the mid-November timeframe) of the driver this didn't occur - it appears to have been introduced with changes to the hardware ring buffer initialization code that are in 2.6.38-rc6.
Comment 1 Chris Wilson 2011-03-25 11:10:54 UTC
I think I can guess what the garbage is. Can you take a photograph of it? And it does clear once overdrawn?
Comment 2 Rick Bramley 2011-03-29 05:26:02 UTC
Created attachment 44993 [details]
Blurred Screen video
Comment 3 Rick Bramley 2011-03-29 05:26:36 UTC
Attached is a video showing the corruption (I suspect it's a distorted splash screen).
Comment 4 Chris Wilson 2011-03-29 05:43:28 UTC
Ok, I think the patches on the tip of drm-intel-staging should clear that up.

In particular:

commit f8acdf5aa142926961e1f7ddb9e86490c50f8e6a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 29 10:40:27 2011 +0100

    drm/i915: Disable all outputs early, before KMS takeover
    
    If the outputs are active and continuing to access the GATT when we
    teardown the PTEs, then there is a potential for us to hang the GPU.
    The hang tends to be a PGTBL_ER with either an invalid host access or
    an invalid display plane fetch.
    
    Reported-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

which requires

commit ea1167d6601f370f5d7e425eb0b3c7577edd02cd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 29 13:19:09 2011 +0100

    drm/i915: Move the irq wait queue initialisation into the ring init
    
    Required so that we don't obliterate the queue if initialising the
    rings after the global IRQ handler is installed.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 5 Chris Wilson 2011-03-29 05:44:12 UTC
Created attachment 44996 [details] [review]
Move the irq queue init onto the rings
Comment 6 Chris Wilson 2011-03-29 05:44:50 UTC
Created attachment 44997 [details] [review]
Disable outputs first
Comment 7 Rick Bramley 2011-03-29 05:52:57 UTC
Thanks, we'll give it a try and let you know.
Comment 8 Rick Bramley 2011-04-14 10:53:39 UTC
Thanks guys, this fixed the issue.
Comment 9 Chris Wilson 2011-04-14 13:12:44 UTC
Lets not close this until I have the patches upstream (even if you are happy to patch your systems for the time being).

What would be really, really valuable for me is your tested-by. Do I have you permission to use your results from testing?
Comment 10 Rick Bramley 2011-04-15 08:22:56 UTC
If you mean saying that we tested it and it worked, sure that's fine.
Comment 11 Chris Wilson 2011-04-17 00:20:40 UTC
Thank you, I've added your tested-by to the patch and with Ben's review I think I have enough for it to go upstream.
Comment 12 Jesse Barnes 2011-06-16 12:36:31 UTC
commit b259f6730c09bc356df932ba9188f291de816808
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 29 13:19:09 2011 +0100

    drm/i915: Move the irq wait queue initialisation into the ring init

and

commit 2c7111dbaec72b01c804afb8ad77c6c7523986fd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 29 10:40:27 2011 +0100

    drm/i915: Disable all outputs early, before KMS takeover

have landed, yay.

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.