4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

Undocking helps, and then I can dock again.

This happens at a hardened 64 bit Gentoo with i915, but I think, it is
not hardened related, or ?

-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Pavel Machek]

On Wed 2015-07-29 15:54:00, Toralf Förster wrote:
> Undocking helps, and then I can dock again.
> 
> This happens at a hardened 64 bit Gentoo with i915, but I think, it is
> not hardened related, or ?

Any chance to bisect it?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 08/02/2015 09:43 AM, Pavel Machek wrote:
> On Wed 2015-07-29 15:54:00, Toralf Förster wrote:
>> Undocking helps, and then I can dock again.
>>
>> This happens at a hardened 64 bit Gentoo with i915, but I think, it is
>> not hardened related, or ?
> 
> Any chance to bisect it?
> 

Aren't there are already pending patches in Gregs stable queue ? If now I'll see.

A quick look at the latest 4.1.3+hardened just shows that the power button at the docking station does not produce an ACPI event.
And I do get this :

Aug  3 11:40:18 t44 kernel: ------------[ cut here ]------------
Aug  3 11:40:18 t44 kernel: WARNING: CPU: 0 PID: 1233 at drivers/gpu/drm/i915/intel_display.c:1332 assert_plane.constprop.89+0x89/0xb0 [i915]()
Aug  3 11:40:18 t44 kernel: plane A assertion failure (expected on, current off)
Aug  3 11:40:18 t44 kernel: Modules linked in: nf_conntrack_ipv6 nf_defrag_ipv6 ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit ipt_REJECT nf_reject_ipv4 xt_recent xt_tcpudp xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables nfsd auth_rpcgss oid_registry lockd grace ctr ccm sunrpc af_packet bridge stp llc tun rc_dib0700_rc5 dib7000p dvb_usb_dib0700 dib3000mc dvb_usb dvb_core dib0070 dib7000m dibx000_common dib0090 rc_core hid_generic hid_cherry usbhid hid arc4 snd_hda_codec_generic rtsx_pci_sdmmc mmc_core evdev x86_pkg_temp_thermal coretemp kvm_intel kvm iwlmvm aesni_intel aes_x86_64 glue_helper lrw mac80211 gf128mul ablk_helper cryptd iwlwifi psmouse atkbd pcspkr cfg80211
Aug  3 11:40:18 t44 kernel:  rtsx_pci thermal wmi i915 fbcon bitblit cfbfillrect softcursor cfbimgblt thinkpad_acpi i2c_algo_bit font battery cfbcopyarea nvram rfkill ac tpm_tis drm_kms_helper tpm ehci_pci xhci_pci drm xhci_hcd snd_hda_intel snd_hda_controller snd_hda_codec ehci_hcd video snd_pcm intel_gtt i2c_i801 snd_timer agpgart usbcore snd_hda_core e1000e fb processor lpc_ich thermal_sys fbdev i2c_core mfd_core usb_common snd hwmon button soundcore [last unloaded: microcode]
Aug  3 11:40:18 t44 kernel: CPU: 0 PID: 1233 Comm: X Tainted: G        W       4.1.3-hardened-r2 #2
Aug  3 11:40:18 t44 kernel: Hardware name: LENOVO 20AQCTO1WW/20AQCTO1WW, BIOS GJET83WW (2.33 ) 03/09/2015
Aug  3 11:40:18 t44 kernel:  ffffffff810e3006 0000000000000000 ffffffffc0402598 ffffc90002173558
Aug  3 11:40:18 t44 kernel:  ffffffff815b2fe6 0000000000002424 ffffc900021735a8 ffffc90002173598
Aug  3 11:40:18 t44 kernel:  ffffffff8105e10a ffffffffffff4111 ffffffffc0402598 0000000000000534
Aug  3 11:40:18 t44 kernel: Call Trace:
Aug  3 11:40:18 t44 kernel:  [<ffffffff810e3006>] ? print_modules+0x76/0xe0
Aug  3 11:40:18 t44 kernel:  [<ffffffffc0402598>] ? i915_ioctls+0x8018/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffff815b2fe6>] dump_stack+0x45/0x5d
Aug  3 11:40:18 t44 kernel:  [<ffffffff8105e10a>] warn_slowpath_common+0x8a/0xd0
Aug  3 11:40:18 t44 kernel:  [<ffffffffc0402598>] ? i915_ioctls+0x8018/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc04041d8>] ? i915_ioctls+0x9c58/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffff8105e1aa>] warn_slowpath_fmt+0x5a/0x70
Aug  3 11:40:18 t44 kernel:  [<ffffffffc04041d8>] ? i915_ioctls+0x9c58/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc040f395>] ? i915_ioctls+0x14e15/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc040f398>] ? i915_ioctls+0x14e18/0x1c6e8 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc0396889>] assert_plane.constprop.89+0x89/0xb0 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc039f746>] hsw_disable_ips+0x56/0x1d0 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc039fbc5>] intel_crtc_disable_planes+0x45/0x190 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc03a0b9f>] haswell_crtc_disable+0x5f/0x440 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc03a1cf1>] __intel_set_mode+0xbb1/0xcd0 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc02c1b7e>] ? drm_atomic_get_crtc_state+0x1e/0xe0 [drm]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc03a975e>] intel_crtc_set_config+0xade/0x10c0 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc02c1b2f>] ? drm_atomic_state_free+0x2f/0x60 [drm]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc01b7dcd>] ? drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc02b0b32>] drm_mode_set_config_internal+0x82/0x130 [drm]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc01ba120>] restore_fbdev_mode+0xd0/0x100 [drm_kms_helper]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc01bc319>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x70 [drm_kms_helper]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc01bc387>] drm_fb_helper_set_par+0x27/0x60 [drm_kms_helper]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc03b903e>] intel_fbdev_set_par+0x1e/0x70 [i915]
Aug  3 11:40:18 t44 kernel:  [<ffffffffc01f0b03>] fb_set_var+0x283/0x4e0 [fb]
Aug  3 11:40:18 t44 kernel:  [<ffffffff81367374>] ? __list_add+0x24/0x50
Aug  3 11:40:18 t44 kernel:  [<ffffffff810934f2>] ? __enqueue_entity+0x72/0x80
Aug  3 11:40:18 t44 kernel:  [<ffffffffc025062e>] fbcon_blank+0x1de/0x2e0 [fbcon]
Aug  3 11:40:18 t44 kernel:  [<ffffffff813fb755>] do_unblank_screen+0xc5/0x200
Aug  3 11:40:18 t44 kernel:  [<ffffffff813ef151>] complete_change_console+0x61/0xf0
Aug  3 11:40:18 t44 kernel:  [<ffffffff813f073b>] vt_ioctl+0x155b/0x1830
Aug  3 11:40:18 t44 kernel:  [<ffffffff813e091f>] tty_ioctl+0x22f/0x1030
Aug  3 11:40:18 t44 kernel:  [<ffffffff811b1a17>] do_vfs_ioctl+0x507/0x8c0
Aug  3 11:40:18 t44 kernel:  [<ffffffff811bd892>] ? __fget_light+0x32/0x80
Aug  3 11:40:18 t44 kernel:  [<ffffffff811b1e14>] SyS_ioctl+0x44/0x80
Aug  3 11:40:18 t44 kernel:  [<ffffffff815ba519>] system_call_fastpath+0x12/0x83
Aug  3 11:40:18 t44 kernel: ---[ end trace 4c3b84e4ab3a79bf ]---


-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 08/03/2015 11:53 AM, Toralf Förster wrote:
> A quick look at the latest 4.1.3+hardened just shows that the power button at the docking station does not produce an ACPI event.
This is fixed between 4.1.3 and 4.1.4 - would be helpful to know the commit id for the following bisecting of the blackmonitor issue (still an issue in 4.1.4 and 4.2-rc5)

-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 08/02/2015 09:43 AM, Pavel Machek wrote:
> Any chance to bisect it?
Did it.

FWIW: the mentioned commit was introduced between 3.18 and 3.19.
But my system (hardened 64 bit Gentoo) did not suffer from it till version 4.0.8.
The hardened kernel 4.1.x was the first where the bug was visible at my docked environment  too.



commit e7d6f7d708290da1b7c92f533444b042c79412e0
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Dec 8 13:23:37 2014 +1000

    drm/i915: resume MST after reading back hw state

    Otherwise the MST resume paths can hit DPMS paths
    which hit state checker paths, which hit WARN_ON,
    because the state checker is inconsistent with the
    hw.

    This fixes a bunch of WARN_ON's on resume after
    undocking.

    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1e9c136..f990ab4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -706,11 +706,12 @@ static int i915_drm_resume(struct drm_device *dev)
                        dev_priv->display.hpd_irq_setup(dev);
                spin_unlock_irq(&dev_priv->irq_lock);

-               intel_dp_mst_resume(dev);
                drm_modeset_lock_all(dev);
                intel_modeset_setup_hw_state(dev, true);
                drm_modeset_unlock_all(dev);

+               intel_dp_mst_resume(dev);
+
                /*
                 * ... but also need to make sure that hotplug processing
                 * doesn't cause havoc. Like in the driver load code we don't


-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 08/04/2015 02:29 PM, Toralf Förster wrote:
> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>> Any chance to bisect it?
> Did it.
> 
> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> But my system (hardened 64 bit Gentoo) did not suffer from it till version 4.0.8.
> The hardened kernel 4.1.x was the first where the bug was visible at my docked environment  too.
> 
> 
> 
> commit e7d6f7d708290da1b7c92f533444b042c79412e0
> Author: Dave Airlie <airlied@redhat.com>
> Date:   Mon Dec 8 13:23:37 2014 +1000
> 


FWIW the issue happens only if the system is docked.

Plugging in the VGA connector in parallel to the already plugged in DVI-D conenctor after wakeup from s2ram helps as a work around.
In this case then the external monitor shows again the KDE desktop.

After few seconds I can then plug off the VGA connector from the docking station and can continue with my work.


-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 08/04/2015 02:29 PM, Toralf Förster wrote:
> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>> Any chance to bisect it?
> Did it.
> 
> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> But my system (hardened 64 bit Gentoo) did not suffer from it till version 4.0.8.
> The hardened kernel 4.1.x was the first where the bug was visible at my docked environment  too.
> 
> 
> 
> commit e7d6f7d708290da1b7c92f533444b042c79412e0
> Author: Dave Airlie <airlied@redhat.com>
> Date:   Mon Dec 8 13:23:37 2014 +1000
> 
>     drm/i915: resume MST after reading back hw state
> 
>     Otherwise the MST resume paths can hit DPMS paths
>     which hit state checker paths, which hit WARN_ON,
>     because the state checker is inconsistent with the
>     hw.
> 
>     This fixes a bunch of WARN_ON's on resume after
>     undocking.
> 
>     Signed-off-by: Dave Airlie <airlied@redhat.com>
>     Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Cc: stable@vger.kernel.org
>     Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 

Is there anything else what I can do ?

Current kernels up to 4.2.3 and 4.3-rc3 (not hardened) shows this issue here at my system.


-- 
Toralf, pgp key: 872AE508 0076E94E

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Pavel Machek]

On Sun 2015-10-04 18:30:14, Toralf Förster wrote:
> On 08/04/2015 02:29 PM, Toralf Förster wrote:
> > On 08/02/2015 09:43 AM, Pavel Machek wrote:
> >> Any chance to bisect it?
> > Did it.
> > 
> > FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> > But my system (hardened 64 bit Gentoo) did not suffer from it till version 4.0.8.
> > The hardened kernel 4.1.x was the first where the bug was visible at my docked environment  too.
> > 
> > 
> > 
> > commit e7d6f7d708290da1b7c92f533444b042c79412e0
> > Author: Dave Airlie <airlied@redhat.com>
> > Date:   Mon Dec 8 13:23:37 2014 +1000
> > 
> >     drm/i915: resume MST after reading back hw state
> > 
> >     Otherwise the MST resume paths can hit DPMS paths
> >     which hit state checker paths, which hit WARN_ON,
> >     because the state checker is inconsistent with the
> >     hw.
> > 
> >     This fixes a bunch of WARN_ON's on resume after
> >     undocking.
> > 
> >     Signed-off-by: Dave Airlie <airlied@redhat.com>
> >     Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> >     Cc: stable@vger.kernel.org
> >     Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > 
> 
> Is there anything else what I can do ?
> 
> Current kernels up to 4.2.3 and 4.3-rc3 (not hardened) shows this issue here at my system.

Yes. Now you ask Dave Airlie <airlied@redhat.com> to fix it. If that
does not work, you ask him to fix it, in less polite words. If that
does not work, you verify that reverting
e7d6f7d708290da1b7c92f533444b042c79412e0 fixes it for you, then ask
Daniel Vetter and Jani Nikula to revert it. If they fail to do that,
you go all the way up to Linus.

Good luck ;-), 
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Toralf Förster]

On 10/29/2015 10:49 PM, Pavel Machek wrote:
> On Sun 2015-10-04 18:30:14, Toralf Förster wrote:
>> On 08/04/2015 02:29 PM, Toralf Förster wrote:
>>> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>>>> Any chance to bisect it?
>>> Did it.
>>>
>>> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
>>> But my system (hardened 64 bit Gentoo) did not suffer from it till version 4.0.8.
>>> The hardened kernel 4.1.x was the first where the bug was visible at my docked environment  too.
>>>
>>>
>>>
>>> commit e7d6f7d708290da1b7c92f533444b042c79412e0
>>> Author: Dave Airlie <airlied@redhat.com>
>>> Date:   Mon Dec 8 13:23:37 2014 +1000
>>>
>>>     drm/i915: resume MST after reading back hw state
>>>
>>>     Otherwise the MST resume paths can hit DPMS paths
>>>     which hit state checker paths, which hit WARN_ON,
>>>     because the state checker is inconsistent with the
>>>     hw.
>>>
>>>     This fixes a bunch of WARN_ON's on resume after
>>>     undocking.
>>>
>>>     Signed-off-by: Dave Airlie <airlied@redhat.com>
>>>     Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>     Cc: stable@vger.kernel.org
>>>     Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>>
>>
>> Is there anything else what I can do ?
>>
>> Current kernels up to 4.2.3 and 4.3-rc3 (not hardened) shows this issue here at my system.
> 
> Yes. Now you ask Dave Airlie <airlied@redhat.com> to fix it. If that

Dear Dave,

please fix it.

Here's a work around which works for me since kernel 4.1.x :

diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index ab64d68..3aeead2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -740,6 +740,8 @@ static int i915_drm_resume(struct drm_device *dev)
        if (dev_priv->display.hpd_irq_setup)
                dev_priv->display.hpd_irq_setup(dev);
        spin_unlock_irq(&dev_priv->irq_lock);
+
+       intel_dp_mst_resume(dev);

        drm_modeset_lock_all(dev);
        intel_display_resume(dev);


> does not work, you ask him to fix it, in less polite words. If that
> does not work, you verify that reverting
> e7d6f7d708290da1b7c92f533444b042c79412e0 fixes it for you, then ask
> Daniel Vetter and Jani Nikula to revert it. If they fail to do that,
> you go all the way up to Linus.
> 
> Good luck ;-), 
> 									Pavel
> 


-- 
Toralf, pgp key: C4EACDDE 0076E94E

4.0 -> 4.1 regression : after resume from s2ram both internal and external display of a docked ThinkPad ate black

[Pavel Machek]

> >>> commit e7d6f7d708290da1b7c92f533444b042c79412e0
> >>> Author: Dave Airlie <airlied@redhat.com>
> >>> Date:   Mon Dec 8 13:23:37 2014 +1000
> >>>
> >>>     drm/i915: resume MST after reading back hw state
....
> >> Is there anything else what I can do ?
> >>
> >> Current kernels up to 4.2.3 and 4.3-rc3 (not hardened) shows this issue here at my system.
> > 
> > Yes. Now you ask Dave Airlie <airlied@redhat.com> to fix it. If that
> 
> Dear Dave,
> 
> please fix it.
> 
> Here's a work around which works for me since kernel 4.1.x :

Dave. You broke it. You fix it. Don't make me less polite?

Daniel? Jani? Can you apply the patch below, or comment whats wrong
with that?

This is a regression, so it should not require much thinking.

									Pavel

> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index ab64d68..3aeead2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -740,6 +740,8 @@ static int i915_drm_resume(struct drm_device *dev)
>         if (dev_priv->display.hpd_irq_setup)
>                 dev_priv->display.hpd_irq_setup(dev);
>         spin_unlock_irq(&dev_priv->irq_lock);
> +
> +       intel_dp_mst_resume(dev);
> 
>         drm_modeset_lock_all(dev);
>         intel_display_resume(dev);
> 
> 
> > does not work, you ask him to fix it, in less polite words. If that
> > does not work, you verify that reverting
> > e7d6f7d708290da1b7c92f533444b042c79412e0 fixes it for you, then ask
> > Daniel Vetter and Jani Nikula to revert it. If they fail to do that,
> > you go all the way up to Linus.
> > 
> > Good luck ;-), 
> > 									Pavel
> > 
> 
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html