Bug 76189 - [HSW fastboot] Black cursor and crash after boot with fastboot=1 on drm-intel-nightly
Summary: [HSW fastboot] Black cursor and crash after boot with fastboot=1 on drm-intel...
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-15 00:15 UTC by Patrik Jakobsson
Modified: 2017-07-24 22:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
Black cursor (78.92 KB, image/png)
2014-03-15 00:15 UTC, Patrik Jakobsson 		no flags Details
dmesg (247.92 KB, text/plain)
2014-03-15 00:16 UTC, Patrik Jakobsson 		no flags Details
dmesg on an i7-4500U with fastboot=1 (57.44 KB, text/plain)
2014-08-15 11:26 UTC, frederic 		no flags Details
reg dump with fastboot=0 (12.92 KB, text/plain)
2014-08-15 11:27 UTC, frederic 		no flags Details
reg dump with fastboot=1 (12.92 KB, text/plain)
2014-08-15 11:27 UTC, frederic 		no flags Details
reg dump with fastboot=1 after VT switching (12.92 KB, text/plain)
2014-08-15 11:28 UTC, frederic 		no flags Details
View All

Description Patrik Jakobsson 2014-03-15 00:15:18 UTC 
Created attachment 95836 [details]
Black cursor

After booting the drm-intel-nightly (2014-03-14) on a Haswell with fastboot=1 the cursor is all black (see attachment). After a while the system stops responding for a few seconds and starts spitting out warnings (see dmesg).

Doing a suspend/resume brings back the normal cursor and all is fine. I'm having trouble bisecting this since I get hit by the EDP_FORCE_VDD regression and have to suspend/resume in order to see anything at all.

The problem is present at b3064154dfd37deb386b1e459c54e1ca2460b3d5
where the EDP_FORCE_VDD bit (and my screen) is back.

I can bisect this by adding the EDP_FORCE_VDD fix on top of every bisect but I would be happy if I can get a pointer to possible suspects first.

Thanks
Comment 1 Patrik Jakobsson 2014-03-15 00:16:42 UTC 
Created attachment 95837 [details]
dmesg
Comment 2 Chris Wilson 2014-03-17 09:37:47 UTC 
To check, this is only with fastboot=1?

Can you grab intel_reg_dumper with and without fastboot?
Comment 3 Jesse Barnes 2014-03-17 15:39:01 UTC 
Looks like some PM refcounting issue too if we're seeing suspend warnings from our reg writes...
Comment 4 Jani Nikula 2014-08-14 13:46:32 UTC 
(In reply to comment #3)
> Looks like some PM refcounting issue too if we're seeing suspend warnings
> from our reg writes...

We've fixed a bunch of that recently haven't we? Patrik, please retest current drm-intel-nightly.
Comment 5 Patrik Jakobsson 2014-08-14 16:25:21 UTC 
Oh, sorry forgot about this one. With the latest nightly the system hangs when starting X with fastboot enabled so I cannot really tell. I'll see if I can bisect that and post a separate bug report.
Comment 6 frederic 2014-08-15 11:26:09 UTC 
Can confirm on a Lenovo U430 notebook with an i7-4500U (HD 4400 graphics).

Everything perfect with i915.fastboot=0. Black cursor with i915.fastboot=1, but switching to a text VT and back to Xorg fixes this.

Will attach dmesg and intel_reg_dumper files...
Comment 7 frederic 2014-08-15 11:26:59 UTC 
Created attachment 104668 [details]
dmesg on an i7-4500U with fastboot=1
Comment 8 frederic 2014-08-15 11:27:28 UTC 
Created attachment 104669 [details]
reg dump with fastboot=0
Comment 9 frederic 2014-08-15 11:27:59 UTC 
Created attachment 104670 [details]
reg dump with fastboot=1
Comment 10 frederic 2014-08-15 11:28:29 UTC 
Created attachment 104671 [details]
reg dump with fastboot=1 after VT switching
Comment 11 Damien Lespiau 2014-12-03 17:55:30 UTC 
So I tried to reproduce this bug on my HSW machine, to no avail. Could you provide a dmesg log with drm.debug=7 i915.fastboot=1 so we have a chance to see the decisions made on your machine?

Thanks,
Comment 12 Jesse Barnes 2014-12-10 21:48:52 UTC 
Timing out on this one; hopefully it's resolved now.

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.