Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-09 15:13:55 UTC
Type: ---
Embargoed:


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.