<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Possible kernel regression for gen3 and earlier in i915.ko"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94676">94676</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Possible kernel regression for gen3 and earlier in i915.ko
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86 (IA32)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vivek@collabora.co.uk
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=122505" name="attach_122505" title="dmesg output from a 4.3.5 (4.3 bpo kernel from debian backports) booting on a gen3 based laptop">attachment 122505</a> <a href="attachment.cgi?id=122505&action=edit" title="dmesg output from a 4.3.5 (4.3 bpo kernel from debian backports) booting on a gen3 based laptop">[details]</a></span>
dmesg output from a 4.3.5 (4.3 bpo kernel from debian backports) booting on a
gen3 based laptop
When booting an old laptop with a gen3 (I think) GPU on a 4.3.5 kernel:
Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics
Controller [8086:27a2] (rev 03)
There were lots of warnings in dmesg and the graphics output was corrupted
as described here:
<a href="https://01.org/linuxgraphics/forum/graphics-installer-discussions/intel-graphics-1.4.0-32bit-ubuntu-15.10-login-screen-corruption">https://01.org/linuxgraphics/forum/graphics-installer-discussions/intel-graphics-1.4.0-32bit-ubuntu-15.10-login-screen-corruption</a>
The original test was with the 01.org backported driver but the user
was kind enough to provide me with access to the machine in question
so I was able to try out a 4.3.5 kernel on it, same behaviour.
So far there appear to be two problems - the first is in intel_sanitize_crtc:
/* We need to sanitize the plane -> pipe mapping first because this will
* disable the crtc (and hence change the state) if it is wrong. Note
* that gen4+ has a fixed plane -> pipe mapping. */
if (INTEL_INFO(dev)->gen < 4 && !intel_check_plane_mapping(crtc)) {
This section used to call intel_crtc_disable_planes() in 4.2.x and do some
other
cleanup besides, but now calls intel_crtc_disable_noatomic() which in turn
uses the recorded plane_mask - but this has not yet been set, so nothing
gets disabled, then later when intel_disable_pipe() is called
assert_planes_disabled() blows a gasket:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 81 at
/build/linux-5EEdAm/linux-4.3.5/drivers/gpu/drm/i915/intel_display.c:1389
assert_planes_disabled+0x108/0x140 [i915]()
plane B assertion failure, should be off on pipe B but is still active
Modules linked in: psmouse ata_piix(+) libata scsi_mod sdhci_pci tg3 sdhci ptp
pps_core mmc_core libphy firewire_ohci firewire_core crc_itu_t ehci_pci(+) fan
thermal wmi i915(+) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
sysimgblt fb_sys_fops uhci_hcd video ehci_hcd button drm usbcore usb_common
CPU: 1 PID: 81 Comm: systemd-udevd Not tainted 4.3.0-0.bpo.1-686 #1 Debian
4.3.5-1~bpo8+1
Hardware name: Hewlett-Packard HP Compaq nc6320 (RH374ET#ABU)/30AA, BIOS 68YDU
Ver. F.0D 04/17/2007
00000000 49d9f2cb f5cb1a24 c12999b5 f5cb1a34 c10578e1 f8397e04 f5cb1a54
00000051 f8397b3c 0000056d f8327438 00000009 0000056d f8327438 f5ec0000
00000042 00000001 f5cb1a40 c105794e 00000009 f5cb1a34 f8397e04 f5cb1a54
Call Trace:
[<c12999b5>] ? dump_stack+0x3e/0x59
[<c10578e1>] ? warn_slowpath_common+0x91/0xc0
[<f8327438>] ? assert_planes_disabled+0x108/0x140 [i915]
[<f8327438>] ? assert_planes_disabled+0x108/0x140 [i915]
[<c105794e>] ? warn_slowpath_fmt+0x3e/0x60
[<f8327438>] ? assert_planes_disabled+0x108/0x140 [i915]
[<f8331424>] ? intel_disable_pipe+0x44/0x290 [i915]
[<f832a8f3>] ? assert_vblank_disabled+0x13/0x70 [i915]
[<f8334ad8>] ? i9xx_crtc_disable+0x68/0x3d0 [i915]
having just looked at the 4.4 branch in stable, I think this may have
been fixed by 634b3a4a476e96816d5d6cd5bb9f8900a53f56ba.
--------------------------------------------------------------------------
Next up is drm_atomic_commit(), called from intel_get_load_detect_pipe()
and a bunch of other places: This one seems to fail because one of the CRTCs
doesn't have a mode blob (and isn't enabled, I think), but
drm_atomic_check_only tries to check its state anyway.
I think this is because intel_modeset_readout_hw_state() skips calling
drm_atomic_set_mode_for_crtc() on it as its crtc->base.state->active
is false, so no mode_blob is set. I guess drm_atomic_check_only should
likewise know enough to leave it alone? I'll confess to be being a bit
lost here.
I still have [remote] access to the machine in question if
anything needs testing.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>