Bug 1342755

Created attachment 1164802 [details]
File: dmesg

The initial oops taints the kernel.

Still broken in kernel-4.5.6-300.fc24.x86_64

*** Bug 1251994 has been marked as a duplicate of this bug. ***

Still broken in kernel-4.7.2-201.fc24.x86_64

Here is Not tainted (first) trace for kernel-4.7.2-201.  Looks like a slightly different routine it is timing out on.

[    3.370046] ------------[ cut here ]------------
[    3.370089] WARNING: CPU: 1 PID: 98 at drivers/gpu/drm/drm_irq.c:1318 drm_wait_one_vblank+0x1b5/0x1c0 [drm]
[    3.370093] vblank wait timed out on crtc 0
[    3.370095] Modules linked in: i915 i2c_algo_bit sdhci_pci drm_kms_helper sdhci firewire_ohci serio_raw firewire_core drm mmc_core 8021q crc_itu_t ata_generic garp pata_acpi stp llc mrp sky2 fjes wmi video hid_logitech_hidpp hid_logitech_dj sunrpc scsi_transport_iscsi
[    3.370127] CPU: 1 PID: 98 Comm: kworker/u4:4 Not tainted 4.7.2-201.fc24.x86_64 #1
[    3.370129] Hardware name: Dell Inc. Inspiron 1525                   /0U990C, BIOS A16 10/16/2008
[    3.370137] Workqueue: events_unbound async_run_entry_fn
[    3.370140]  0000000000000286 0000000060557848 ffff8800752339d8 ffffffff813d941f
[    3.370144]  ffff880075233a28 0000000000000000 ffff880075233a18 ffffffff8109facb
[    3.370148]  0000052600000286 ffff8800345e3800 0000000000000000 0000000000000000
[    3.370152] Call Trace:
[    3.370160]  [<ffffffff813d941f>] dump_stack+0x63/0x84
[    3.370164]  [<ffffffff8109facb>] __warn+0xcb/0xf0
[    3.370168]  [<ffffffff8109fb4f>] warn_slowpath_fmt+0x5f/0x80
[    3.370172]  [<ffffffff810e33e3>] ? finish_wait+0x53/0x70
[    3.370187]  [<ffffffffc0116d95>] drm_wait_one_vblank+0x1b5/0x1c0 [drm]
[    3.370191]  [<ffffffff810e3640>] ? prepare_to_wait_event+0xf0/0xf0
[    3.370267]  [<ffffffffc024ecb6>] intel_get_load_detect_pipe+0x666/0x680 [i915]
[    3.370312]  [<ffffffffc028cb3f>] intel_tv_detect+0x13f/0x5d0 [i915]
[    3.370333]  [<ffffffffc01a5fae>] drm_helper_probe_single_connector_modes+0x30e/0x500 [drm_kms_helper]
[    3.370343]  [<ffffffffc01b371e>] drm_fb_helper_initial_config+0xae/0x420 [drm_kms_helper]
[    3.370348]  [<ffffffff8102574a>] ? __switch_to+0x29a/0x4a0
[    3.370393]  [<ffffffffc02643af>] intel_fbdev_initial_config+0x1f/0x30 [i915]
[    3.370396]  [<ffffffff810c1f2a>] async_run_entry_fn+0x4a/0x140
[    3.370400]  [<ffffffff810b9314>] process_one_work+0x184/0x440
[    3.370403]  [<ffffffff810b961e>] worker_thread+0x4e/0x480
[    3.370406]  [<ffffffff810b95d0>] ? process_one_work+0x440/0x440
[    3.370409]  [<ffffffff810bf4f8>] kthread+0xd8/0xf0
[    3.370414]  [<ffffffff817eba7f>] ret_from_fork+0x1f/0x40
[    3.370417]  [<ffffffff810bf420>] ? kthread_worker_fn+0x180/0x180
[    3.370420] ---[ end trace 954cdc8b7a765e7b ]---

kernel-4.8.4 crashes Xorg, and no new Xorg can be started, making the laptop unusable.

kernel-4.8.6 is usable, but boot takes much longer than 4.7.9 while it waits for timeouts.  As always, the oops taints the kernel, hampering reporting of other kernel bugs.  Here is the new kernel oops:

[   13.792070] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:26:pipe A] flip_done timed out
[   13.892498] ------------[ cut here ]------------
[   13.892528] WARNING: CPU: 1 PID: 97 at drivers/gpu/drm/drm_irq.c:1224 drm_wait_one_vblank+0x1b6/0x1c0 [drm]
[   13.892529] vblank wait timed out on crtc 0
[   13.892531] Modules linked in: i915 sdhci_pci sdhci firewire_ohci serio_raw mmc_core i2c_algo_bit firewire_core drm_kms_helper ata_generic pata_acpi drm 8021q garp stp llc mrp crc_itu_t sky2 fjes wmi video hid_logitech_hidpp hid_logitech_dj sunrpc scsi_transport_iscsi
[   13.892557] CPU: 1 PID: 97 Comm: kworker/u4:3 Not tainted 4.8.6-201.fc24.x86_64 #1
[   13.892558] Hardware name: Dell Inc. Inspiron 1525                   /0U990C, BIOS A16 10/16/2008
[   13.892564] Workqueue: events_unbound async_run_entry_fn
[   13.892567]  0000000000000286 0000000060e5c097 ffff93297526b9c8 ffffffff873e5ebd
[   13.892571]  ffff93297526ba18 0000000000000000 ffff93297526ba08 ffffffff870a0e8b
[   13.892574]  000004c800000000 ffff932933ec0000 0000000000000000 0000000000000000
[   13.892578] Call Trace:
[   13.892583]  [<ffffffff873e5ebd>] dump_stack+0x63/0x86
[   13.892587]  [<ffffffff870a0e8b>] __warn+0xcb/0xf0
[   13.892590]  [<ffffffff870a0f0f>] warn_slowpath_fmt+0x5f/0x80
[   13.892593]  [<ffffffff870e4b13>] ? finish_wait+0x53/0x70
[   13.892606]  [<ffffffffc041dc66>] drm_wait_one_vblank+0x1b6/0x1c0 [drm]
[   13.892609]  [<ffffffff870e4d70>] ? prepare_to_wait_event+0xf0/0xf0
[   13.892684]  [<ffffffffc058d192>] intel_get_load_detect_pipe+0x662/0x680 [i915]
[   13.892730]  [<ffffffffc05ca81f>] intel_tv_detect+0x13f/0x5c0 [i915]
[   13.892742]  [<ffffffffc048d04b>] drm_helper_probe_single_connector_modes+0x27b/0x520 [drm_kms_helper]
[   13.892752]  [<ffffffffc049b9ce>] drm_fb_helper_initial_config+0xae/0x420 [drm_kms_helper]
[   13.892755]  [<ffffffff870df146>] ? pick_next_task_fair+0x486/0x4c0
[   13.892800]  [<ffffffffc05a3c58>] intel_fbdev_initial_config+0x18/0x30 [i915]
[   13.892802]  [<ffffffff870c35f9>] async_run_entry_fn+0x39/0x140
[   13.892805]  [<ffffffff870baa74>] process_one_work+0x184/0x430
[   13.892807]  [<ffffffff870bad6e>] worker_thread+0x4e/0x480
[   13.892809]  [<ffffffff870bad20>] ? process_one_work+0x430/0x430
[   13.892811]  [<ffffffff870c0c08>] kthread+0xd8/0xf0
[   13.892816]  [<ffffffff8780277f>] ret_from_fork+0x1f/0x40
[   13.892818]  [<ffffffff870c0b30>] ? kthread_worker_fn+0x180/0x180
[   13.892820] ---[ end trace cd2e83ae523583d6 ]---
[   14.081063] ------------[ cut here ]------------
[   14.081090] WARNING: CPU: 0 PID: 97 at drivers/gpu/drm/drm_irq.c:1224 drm_wait_one_vblank+0x1b6/0x1c0 [drm]
[   14.081091] vblank wait timed out on crtc 0
[   14.081092] Modules linked in: i915 sdhci_pci sdhci firewire_ohci serio_raw mmc_core i2c_algo_bit firewire_core drm_kms_helper ata_generic pata_acpi drm 8021q garp stp llc mrp crc_itu_t sky2 fjes wmi video hid_logitech_hidpp hid_logitech_dj sunrpc scsi_transport_iscsi
[   14.081116] CPU: 0 PID: 97 Comm: kworker/u4:3 Tainted: G        W       4.8.6-201.fc24.x86_64 #1
[   14.081118] Hardware name: Dell Inc. Inspiron 1525                   /0U990C, BIOS A16 10/16/2008
[   14.081123] Workqueue: events_unbound async_run_entry_fn
[   14.081125]  0000000000000286 0000000060e5c097 ffff93297526b878 ffffffff873e5ebd
[   14.081130]  ffff93297526b8c8 0000000000000000 ffff93297526b8b8 ffffffff870a0e8b
[   14.081133]  000004c8870fab2c ffff932933ec0000 0000000000000000 0000000000000000
[   14.081137] Call Trace:
[   14.081142]  [<ffffffff873e5ebd>] dump_stack+0x63/0x86
[   14.081146]  [<ffffffff870a0e8b>] __warn+0xcb/0xf0
[   14.081148]  [<ffffffff870a0f0f>] warn_slowpath_fmt+0x5f/0x80
[   14.081151]  [<ffffffff870e4b13>] ? finish_wait+0x53/0x70
[   14.081164]  [<ffffffffc041dc66>] drm_wait_one_vblank+0x1b6/0x1c0 [drm]
[   14.081167]  [<ffffffff870e4d70>] ? prepare_to_wait_event+0xf0/0xf0
[   14.081231]  [<ffffffffc058682f>] intel_pre_plane_update+0x15f/0x170 [i915]
[   14.081276]  [<ffffffffc0586e9b>] intel_atomic_commit_tail+0x14b/0x1050 [i915]
[   14.081280]  [<ffffffff877ffb92>] ? mutex_lock+0x12/0x30
[   14.081296]  [<ffffffffc0496ecb>] ? drm_atomic_helper_setup_commit+0x2db/0x320 [drm_kms_helper]
[   14.081341]  [<ffffffffc058f891>] ? intel_prepare_plane_fb+0x171/0x2b0 [i915]
[   14.081387]  [<ffffffffc05881de>] intel_atomic_commit+0x43e/0x550 [i915]
[   14.081405]  [<ffffffffc04360d7>] ? drm_atomic_check_only+0x187/0x610 [drm]
[   14.081422]  [<ffffffffc0436597>] drm_atomic_commit+0x37/0x60 [drm]
[   14.081468]  [<ffffffffc058d1d3>] intel_release_load_detect_pipe+0x23/0x80 [i915]
[   14.081514]  [<ffffffffc05caa1d>] intel_tv_detect+0x33d/0x5c0 [i915]
[   14.081522]  [<ffffffffc048d04b>] drm_helper_probe_single_connector_modes+0x27b/0x520 [drm_kms_helper]
[   14.081531]  [<ffffffffc049b9ce>] drm_fb_helper_initial_config+0xae/0x420 [drm_kms_helper]
[   14.081534]  [<ffffffff870df146>] ? pick_next_task_fair+0x486/0x4c0
[   14.081579]  [<ffffffffc05a3c58>] intel_fbdev_initial_config+0x18/0x30 [i915]
[   14.081581]  [<ffffffff870c35f9>] async_run_entry_fn+0x39/0x140
[   14.081583]  [<ffffffff870baa74>] process_one_work+0x184/0x430
[   14.081585]  [<ffffffff870bad6e>] worker_thread+0x4e/0x480
[   14.081587]  [<ffffffff870bad20>] ? process_one_work+0x430/0x430
[   14.081590]  [<ffffffff870c0c08>] kthread+0xd8/0xf0
[   14.081593]  [<ffffffff8780277f>] ret_from_fork+0x1f/0x40
[   14.081595]  [<ffffffff870c0b30>] ? kthread_worker_fn+0x180/0x180
[   14.081597] ---[ end trace cd2e83ae523583d7 ]---
[   14.112573] fbcon: inteldrmfb (fb0) is primary device
[   15.013191] Console: switching to colour frame buffer device 160x50
[   15.033126] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

Created attachment 1219524 [details]
kernel oops from pressing increase brightness key

The taint is from the oops at boot time.

Still broken in 4.8.10-200

Created attachment 1229497 [details]
drm.debug=6 boot.log

Here is a boot log (all the parts concerned with drm initialization) with drm.debug=6 on kernel command line, as suggested on Fedora IRC.

Sigh, I'm losing track of bzs. Here are more of this problem.  I'm not sure how to present this to make it easier to fix the regression.

bz#1352023
bz#1394015

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)

Last usable kernel tested was 4.7.9.

*** Bug 1352023 has been marked as a duplicate of this bug. ***

*** Bug 1394015 has been marked as a duplicate of this bug. ***

Unfortunately the GM965-related Linux drivers regressed significantly in 2016 and I think there are multiple issues currently (which makes it hard to bisect as these issues influence each other). Of course it doesn't help that the hardware is quite old so Intel developers are focussing on newer hw.

Your "not tainted" trace looks very much like 
https://bugs.freedesktop.org/show_bug.cgi?id=93782

I found some other bugs about "flip_done timed out" (e.g. https://bugs.freedesktop.org/show_bug.cgi?id=96781) but the current DRM tip doesn't solve these for me (also GM965).

My guess is that this problem is unlikely to be fixed in Fedora anytime soon as it is a regression upstream. Also I assume that this will be only fixed if some technically skilled users bisect it all the way back to 4.2 and work with the intel devs (e.g. by testing patches and git trees, poking a bit at the code). Therefore I recommend that Fedora users should track the likely upstream bug report (please abstain from "me too"/"+1" unless you can also contribute other significant information).

Figured I should give an update here on my end since I haven't said much. I have been looking at this bug and while it's not my highest priority (965GM is pretty old) I would at least like to make sure that these chipsets work somewhat. The problem looks like we're trying to do a vblank wait during a portion of the modeset where we don't actually have working hardware vblank interrupts, resulting in the timeout you see there. Every time it ends up getting triggered by intel_tv_detect() which makes sense (even though you might have nothing plugged into the svideo port, it still has to attempt a modeset on the svideo port every 10 seconds to check whether or not there's supposed to be something on the other end, composite never had the fortune of having hotplug detection signals). Unfortunately this also comes with the caveat that in order to properly reproduce this bug, I need to have a 965GM machine that has either svideo or composite out.

So-- if I can manage to figure out a fix without reproducing the bug or I manage to get my hands on a machine like that this should get fixed, but no promises.

As well-- I forgot to mention that if someone managed to do me the favor of bisecting the commit that broke this, that would probably help a good bit in me fixing this :)

(In reply to Lyude from comment #16)
> So-- if I can manage to figure out a fix without reproducing the bug or I
> manage to get my hands on a machine like that this should get fixed, but no
> promises.

Ah cool. Not sure if it would help but I have an old dell laptop with svideo here (though no actual s-video cable). If it helps I could look into setting it up with a plain Fedora and provide remote access.

As for bisecting: I'm currently doing it when I have too much spare time in the evenings. So far I nailed it down (on my machine) to some change between 4.2 and 4.3.

(In reply to Felix Schwarz from comment #18)
> (In reply to Lyude from comment #16)
> > So-- if I can manage to figure out a fix without reproducing the bug or I
> > manage to get my hands on a machine like that this should get fixed, but no
> > promises.
> 
> Ah cool. Not sure if it would help but I have an old dell laptop with svideo
> here (though no actual s-video cable). If it helps I could look into setting
> it up with a plain Fedora and provide remote access.
> 
> As for bisecting: I'm currently doing it when I have too much spare time in
> the evenings. So far I nailed it down (on my machine) to some change between
> 4.2 and 4.3.

This would be perfect actually! It's going to need to have the same chipset though, 965GM. If you need help figuring out whether or not that machine has that chipset let me know, I should be able to look up the laptop model or the PCI-ID of the GPU.

As well, if you do end up setting a fedora install on it with remote access, I'd recommend you add

ks=https://lyude.net/~lyudess/ks/i386.cfg

to the kernel command line when you're booting the livecd. That'll install all the packages I need for initial setup + my ssh keys. Feel free to send me the server details over e-mail.

> As well, if you do end up setting a fedora install on it with remote access,
> I'd recommend you add
> 
> ks=https://lyude.net/~lyudess/ks/i386.cfg
> 
> to the kernel command line when you're booting the livecd. That'll install
> all the packages I need for initial setup + my ssh keys. Feel free to send
> me the server details over e-mail.

whoops, forgot to mention you'll also need to use the netboot ISO for this to work :)

Thanks for the update.  I'll look for a used laptop with a newer chipset.  Meanwhile, can I bisect the kernel using mock?  Is it a matter of making a src.tar from a commit at kernel.org, then pointing the SRPM at it and building in mock and trying the kernel?  Is there a tutorial?  Can the intel driver be built separately from the kernel (making the bisect much faster)?  Would it be the i915 kernel module?  Or would the drm modules be involved also? 

No worries if no time to explain all that, I'll make a stab at it.

(In reply to Lyude from comment #19)
> This would be perfect actually!

remote access or bisecting? Should I hurry up to provide a bisection before?

> It's going to need to have the same chipset though, 965GM.

Oh, it has that - seeing enough of these vblank warnings myself.

It's a Core2 Duo CPU T7250 (family 6 model 15) on a Dell Vostro 1500.

Feel free to contact me by email :-)

(In reply to Stuart D Gathman from comment #21)
> Meanwhile, can I bisect the kernel using mock?  Is it a matter of making a
> src.tar from a commit at kernel.org, then pointing the SRPM at it and
> building in mock and trying the kernel?

You can do that but I think that's even more time consuming than a "traditional" bisect (from a Linux git tree) because of all the overhead mock has (isolation, installing the compiler, ...).

> Can the intel
> driver be built separately from the kernel (making the bisect much faster)? 
> Would it be the i915 kernel module?  Or would the drm modules be involved
> also?

For some revisions this might work but quite often you need also to rebuild a lot of "unrelated" stuff due to API changes.

(In reply to Felix Schwarz from comment #22)
> (In reply to Lyude from comment #19)
> > This would be perfect actually!
> 
> remote access or bisecting? Should I hurry up to provide a bisection before?
> 
> > It's going to need to have the same chipset though, 965GM.
> 
> Oh, it has that - seeing enough of these vblank warnings myself.
> 
> It's a Core2 Duo CPU T7250 (family 6 model 15) on a Dell Vostro 1500.
> 
> Feel free to contact me by email :-)
> 
> (In reply to Stuart D Gathman from comment #21)
> > Meanwhile, can I bisect the kernel using mock?  Is it a matter of making a
> > src.tar from a commit at kernel.org, then pointing the SRPM at it and
> > building in mock and trying the kernel?
> 
> You can do that but I think that's even more time consuming than a
> "traditional" bisect (from a Linux git tree) because of all the overhead
> mock has (isolation, installing the compiler, ...).
It's possible but you're going to save yourself a lot of pain by just using the vanilla upstream kernel.
> 
> > Can the intel
> > driver be built separately from the kernel (making the bisect much faster)? 
> > Would it be the i915 kernel module?  Or would the drm modules be involved
> > also?
> 
> For some revisions this might work but quite often you need also to rebuild
> a lot of "unrelated" stuff due to API changes.

Well if I have remote access to the machine I've got the resources to do the bisect here myself :). Anyway, having access to a machine with this issue should be a lot more useful for debugging this then just a plain bisect.

Btw: Andreas Amann found a workaround which requires no compilation (disables S-Video output) in https://bugs.freedesktop.org/show_bug.cgi?id=93782#c40 

Still going to pursue a real solution though.

(In reply to Felix Schwarz from comment #24)
> Btw: Andreas Amann found a workaround which requires no compilation
> (disables S-Video output) in
> https://bugs.freedesktop.org/show_bug.cgi?id=93782#c40 
> 
> Still going to pursue a real solution though.

Added video=SVIDEO-1:d to kernel command line in grub.

Confirming the workaround on my Dell inspiron 1525 - now usable again with kernel-4.8.x !  I have a VGA and HDMI port.  If SVIDEO is coax, I don't have it (physically) either.  I'll see if the HDMI port still works with the workaround.

HDMI and VGA ports still work with the workaround (as a second display).  So I guess you just can't play DVDs to your old analog TV anymore.

Created attachment 1239508 [details]
kernel oops from adding external monitor with video=SVIDEO-1:d

The workaround prevents the kernel oops at boot, but it still gets this oops when plugging in an external monitor.

Just to be clear, the external monitor does work, but the oops taints the kernel.

*** Bug 1405747 has been marked as a duplicate of this bug. ***

confirming workaround on HP Compaq 6720

uname -r
   4.9.5-200.fc25.i686
lspci | grep  VGA
   00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)

kernel parameters in grub2
   ... ro rhgb quiet LANG=en_US.UTF-8 video=SVIDEO-1:d

I have the same problem, reported it here (https://bugzilla.redhat.com/show_bug.cgi?id=1409228)

but using the workaround, video=SVIDEO-1:d, does not fully solve the problem for me. I reported that here https://bugs.freedesktop.org/show_bug.cgi?id=96781#c38

X still freezes for me, when logging out either by doing startx from the console or after a suspend/resume and trying to logout.

I am on 4.9.5-200.fc25.x86_64

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-100.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Still broken on F25, but the workaround is still good for me.

Honestly, composite video monitors are so rare now, maybe the thing to do is is disable SVIDEO by default, and have a kernel command line option to enable it for those retro situations.

Just to confirm, I checked that this bug is *not* present on a newer Intel laptop.  

lspci: VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
kernel-4.10.8-100.fc24.x86_64

I presume the newer laptop does not support SVIDEO in any way (as others were having the problem with older laptops but no physical composite jack).

After upgrading kernel to
# uname -r
4.10.16-200.fc25.i686

on HP Compaq 6720s now it is possible to boot to the welcome screen after couple seconds of blinking, without using kernel parameter video=SVIDEO-1:d, but dmesg still shows several crashes and ABRT noticing about them, untainted one:

[   13.280056] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:29:pipe A] flip_done timed out
[   13.381031] ------------[ cut here ]------------
[   13.381059] WARNING: CPU: 0 PID: 94 at drivers/gpu/drm/drm_irq.c:1237 drm_wait_one_vblank+0x189/0x190 [drm]
[   13.381060] vblank wait timed out on crtc 0
[   13.381061] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops e1000e drm serio_raw ata_generic pata_acpi ptp pps_core video fjes
[   13.381083] CPU: 0 PID: 94 Comm: kworker/u4:5 Not tainted 4.10.16-200.fc25.i686 #1
[   13.381084] Hardware name: Hewlett-Packard         /30D8, BIOS 68MDU Ver. F.01 07/05/2007
[   13.381090] Workqueue: events_unbound async_run_entry_fn
[   13.381091] Call Trace:
[   13.381097]  dump_stack+0x58/0x78
[   13.381101]  __warn+0xea/0x110
[   13.381114]  ? drm_wait_one_vblank+0x189/0x190 [drm]
[   13.381117]  warn_slowpath_fmt+0x46/0x60
[   13.381131]  drm_wait_one_vblank+0x189/0x190 [drm]
[   13.381134]  ? remove_wait_queue+0x50/0x50
[   13.381207]  intel_get_load_detect_pipe+0x73a/0x790 [i915]
[   13.381253]  intel_tv_detect+0x142/0x5d0 [i915]
[   13.381269]  ? drm_get_edid+0x30/0x3e0 [drm]
[   13.381281]  drm_helper_probe_single_connector_modes+0x2a3/0x520 [drm_kms_helper]
[   13.381290]  drm_setup_crtcs+0x6a/0x9d0 [drm_kms_helper]
[   13.381293]  ? update_curr+0x161/0x210
[   13.381295]  ? dequeue_entity+0xc3/0x500
[   13.381303]  drm_fb_helper_initial_config+0x72/0x3f0 [drm_kms_helper]
[   13.381306]  ? pick_next_task_fair+0x482/0x510
[   13.381350]  intel_fbdev_initial_config+0x16/0x30 [i915]
[   13.381351]  async_run_entry_fn+0x35/0x190
[   13.381355]  process_one_work+0x14b/0x3a0
[   13.381357]  worker_thread+0x39/0x470
[   13.381359]  kthread+0xdb/0x110
[   13.381361]  ? process_one_work+0x3a0/0x3a0
[   13.381362]  ? kthread_park+0x90/0x90
[   13.381366]  ret_from_fork+0x21/0x2c
[   13.381368] ---[ end trace 010607a8608bae41 ]---

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.