[Bug 94676] New: Possible kernel regression for gen3 and earlier in i915.ko

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94676

            Bug ID: 94676
           Summary: Possible kernel regression for gen3 and earlier in
                    i915.ko
           Product: DRI
           Version: unspecified
          Hardware: x86 (IA32)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: vivek at collabora.co.uk
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 122505
  --> https://bugs.freedesktop.org/attachment.cgi?id=122505&action=edit
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: 

https://01.org/linuxgraphics/forum/graphics-installer-discussions/intel-graphics-1.4.0-32bit-ubuntu-15.10-login-screen-corruption

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160323/daab8ffa/attachment.html>