Bug 1301374

Summary:	Black screen before luks prompt starting with 4.5.0-0.rc0.git8.2.fc24.i686
Product:	[Fedora] Fedora	Reporter:	Bruno Wolff III <bruno>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bruno, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-09 15:13:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bruno Wolff III 2016-01-24 16:08:02 UTC

User-Agent:       Uknown
Build Identifier: 

4.5.0-0.rc0.git1.2.fc24.i686 boots normally, but starting with 4.5.0-0.rc0.git8.2.fc24.i686 I get a black screen before I get prompted for my luks password.
I tried booting without rhgb and quiet and the screen still went black without an obvious traceback first.
The hardware is an i686 laptop that uses the i915 driver.
I am attempting a bisect and there probably isn't much for you guys to do until I narrow things down.
Last night's HEAD still has the problem. I am building 4.4 the same way to test that it isn't something other than the kernel (in the initramfs) causing the problem.

Reproducible: Always

Comment 1 Bruno Wolff III 2016-01-24 16:12:54 UTC

The machine has F23 on it, except for the kernels. I am using the rawhide nodebug repo.
I did not see this problem on an x86_64 machine with an AMD video card, so the issue does seem to be hardware dependent.

Comment 2 Bruno Wolff III 2016-01-24 19:14:35 UTC

The 4.4 upstream kernel build worked, so it looks like it is a kernel change causing the problem and I'll start doing the bisect.

Comment 3 Bruno Wolff III 2016-01-25 15:32:42 UTC

There was some traffic on lkml about i915 issues today that look like what I am seeing. I might spend tonight's kernel build trying to test those fixes instead of a couple of bisect iterations.

Comment 4 Bruno Wolff III 2016-01-26 09:09:54 UTC

My problem does seem to be caused by 39bfcd5235e0 drm/i915: more virtual south bridge detection, which matches some real hardware in addition to the virtual hardware it meant to match.

I tested one of the proposed patches to fix the problem and it worked.

I'll watch for a patch to go upstream and then into Fedora and take care of closing this then.

Comment 5 Bruno Wolff III 2016-01-29 17:38:27 UTC

The fix has made it into the drm fixes repo, so it should probably show up in Linus' tree soon.
There is another patch posted that changes ID numbers in the above patch to macro references. I doubt that will hold up the fix though.

Comment 6 Bruno Wolff III 2016-01-29 17:42:05 UTC

That should be drm-intel-fixes tree. http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes&id=f2e305108faba0c85eb4ba4066599decb675117e

Comment 7 Bruno Wolff III 2016-02-05 16:12:50 UTC

The fix is now in Airlie's tree. Next stop should be linus'.

Comment 8 Bruno Wolff III 2016-02-06 05:21:06 UTC

The fix is now in linus' tree. So the next Fedora kernel build should have the fix.

Comment 9 Bruno Wolff III 2016-02-09 01:14:14 UTC

The f24 rc3 kernel still doesn't boot, but this may be due to bug 1302071 which came up since the start of the i915 issue. I'm going to build an upstream rc3 kernel and try that.

Comment 10 Bruno Wolff III 2016-02-09 15:13:55 UTC

The vanilla 4.5-rc3 kernel does work for me, so even with bug 1302071 (or something new) preventing a successful boot of the Fedora kernel, I think it is safe to close this.