Bug 1301374 - Black screen before luks prompt starting with 4.5.0-0.rc0.git8.2.fc24.i686
Summary: Black screen before luks prompt starting with 4.5.0-0.rc0.git8.2.fc24.i686
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-01-24 16:08 UTC by Bruno Wolff III
Modified: 2016-02-09 15:13 UTC (History)
7 users (show)

Clone Of:
Last Closed: 2016-02-09 15:13:55 UTC

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.