Bug 1301374 - Black screen before luks prompt starting with 4.5.0-0.rc0.git8.2.fc24.i686
Black screen before luks prompt starting with 4.5.0-0.rc0.git8.2.fc24.i686
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-24 11:08 EST by Bruno Wolff III
Modified: 2016-02-09 10:13 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-09 10:13:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2016-01-24 11:08:02 EST
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 11:12:54 EST
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 14:14:35 EST
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 10:32:42 EST
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 04:09:54 EST
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 12:38:27 EST
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 12:42:05 EST
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 11:12:50 EST
The fix is now in Airlie's tree. Next stop should be linus'.
Comment 8 Bruno Wolff III 2016-02-06 00:21:06 EST
The fix is now in linus' tree. So the next Fedora kernel build should have the fix.
Comment 9 Bruno Wolff III 2016-02-08 20:14:14 EST
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 10:13:55 EST
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.