Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kernel 4.* nouveau monitor not respond question [Solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3947
Location: Dallas area

PostPosted: Sat Nov 07, 2015 12:08 pm    Post subject: kernel 4.* nouveau monitor not respond question [Solved] Reply with quote

I've been trying the new 4.* series of kernels and have a problem with the nouveau driver.

The system boots, runs fine, etc. but if I turn the monitor off with the power button,
and then turn it back on the monitor doesn't respond, until I unplug and replug the hdmi cable
then the monitor comes back to life.

This happened with both 4.1.12 and 4.3 so something seems to have changed in the nouveau driver.
Anyone have a clue what's going on?

/Rambling
It's almost as if the nouveau driver thinks it should suspend sending anything to the monitor (until un/replugging)
I don't have either hibernation or suspend built into the kernel.

Edit to add: The monitor works fine under the 3.15.9 kernel
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Fri Nov 13, 2015 10:59 am; edited 1 time in total
Back to top
View user's profile Send private message
Keruskerfuerst
Advocate
Advocate


Joined: 01 Feb 2006
Posts: 2288
Location: near Augsburg, Germany

PostPosted: Sun Nov 08, 2015 9:52 am    Post subject: Reply with quote

Hardwareinfo?
Can you try the nvidia driver?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3947
Location: Dallas area

PostPosted: Sun Nov 08, 2015 10:52 am    Post subject: Reply with quote

There's not a problem with hardware, as it runs fine under 3.15.9.
I hadn't wanted to mess with downloading and installing the nvidia drivers since I'm sure they would work fine.

The card is a nvidia gt210 (gt218, nva8) classed as nv50 by nouveau,
and that is some of the code that changed (a lot) since the late 3.x.x series

I was just curious as to whether anyone else has run into this problem.

I do have a newer nvidia on order and it should be here soon and it's in the 700 series so I expect no problems.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3947
Location: Dallas area

PostPosted: Fri Nov 13, 2015 11:03 am    Post subject: Reply with quote

Just a note to finish this thread.

I got the problem resolved.
But a little history on how.

I googled and found out that there were others having the same problem
(evidently no kernel devs ever tried turning off their monitor or they would have seen the problem)

Anyway, I tried several of the "fixes" including using a newer version of the nouveau kernel driver.
No fix.

I then did some more googling and saw that the radeon cards were having a similar problem (I use nouveau as main card)
and the fix was simple enough that I figured out where it needed to go in the nouveau code and implemented it.

The monitor now behaves properly without tons of messages and traces being generated.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Nov 15, 2015 3:11 pm    Post subject: Reply with quote

@Anon-E-moose:

code snippet or link to the reference, please


I'm currently also running nouveau on 4.3 (+4.4 nouveau changes)

and besides GPU lockups when reclocking is enabled turning off the monitor works fine - for now


I usually lock the screen via xscreensaver and then turn it off - since I've disable DPMS to prevent the monitor turning off during e.g. viewing videos, youtube, etc.


I can't believe there doesn't exist a common API or functionality for all desktop environments or X to prevent screen turning off when playing fullscreen videos

when there hasn't been any keyboard, mouse input for some time
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3947
Location: Dallas area

PostPosted: Sun Nov 15, 2015 6:47 pm    Post subject: Reply with quote

A little more about my hardware, I was running a gt210 and have upgraded to a gt730 using an lg ips monitor.
The problems were happening with both.

I would get "lots" of these types of messages
Code:
Nov 12 14:31:36 don64 kernel: [  267.297683] ------------[ cut here ]------------
Nov 12 14:31:36 don64 kernel: [  267.297696] WARNING: CPU: 1 PID: 1527 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x85/0x90 [drm_kms_helper]()
Nov 12 14:31:36 don64 kernel: [  267.297701] Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter oss_usb(O) oss_hdaudio(O) osscore(O) it87 hwmon_vid xt_mark xt_owner iptable_mangle ip_tables mxm_wmi uas serio_raw k10temp nouveau ttm drm_kms_helper syscopyarea sysfillrect sysimgblt i2c_piix4 fb_sys_fops drm r8169 mii wmi [last unloaded: soundcore]
Nov 12 14:31:36 don64 kernel: [  267.297759] CPU: 1 PID: 1527 Comm: kworker/1:1 Tainted: G           O    4.3.0-zen #4
Nov 12 14:31:36 don64 kernel: [  267.297765] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A99FX PRO R2.0, BIOS 2301 01/06/2014
Nov 12 14:31:36 don64 kernel: [  267.297795] Workqueue: events nvif_notify_work [nouveau]
Nov 12 14:31:36 don64 kernel: [  267.297800]  ffffffffa00a3f58 ffff88042c1e7d18 ffffffff8134f679 0000000000000000
Nov 12 14:31:36 don64 kernel: [  267.297809]  ffff88042c1e7d50 ffffffff8106b83c ffff880429642800 ffff88042b3a9800
Nov 12 14:31:36 don64 kernel: [  267.297817]  0000000000000003 0000000000000000 ffff88043ec53300 ffff88042c1e7d60
Nov 12 14:31:36 don64 kernel: [  267.297825] Call Trace:
Nov 12 14:31:36 don64 kernel: [  267.297837]  [<ffffffff8134f679>] dump_stack+0x4b/0x72
Nov 12 14:31:36 don64 kernel: [  267.297845]  [<ffffffff8106b83c>] warn_slowpath_common+0x7c/0xb0
Nov 12 14:31:36 don64 kernel: [  267.297851]  [<ffffffff8106b925>] warn_slowpath_null+0x15/0x20
Nov 12 14:31:36 don64 kernel: [  267.297858]  [<ffffffffa0094135>] drm_helper_choose_encoder_dpms+0x85/0x90 [drm_kms_helper]
Nov 12 14:31:36 don64 kernel: [  267.297866]  [<ffffffffa009453e>] drm_helper_connector_dpms+0x3e/0xf0 [drm_kms_helper]
Nov 12 14:31:36 don64 kernel: [  267.297896]  [<ffffffffa01729ad>] nouveau_connector_hotplug+0x4d/0xb0 [nouveau]
Nov 12 14:31:36 don64 kernel: [  267.297918]  [<ffffffffa00d18c3>] nvif_notify_work+0x13/0x80 [nouveau]
Nov 12 14:31:36 don64 kernel: [  267.297924]  [<ffffffff8107e658>] ? pwq_dec_nr_in_flight+0x48/0xa0
Nov 12 14:31:36 don64 kernel: [  267.297930]  [<ffffffff8107e7df>] process_one_work+0x12f/0x320
Nov 12 14:31:36 don64 kernel: [  267.297935]  [<ffffffff8107ea16>] worker_thread+0x46/0x440
Nov 12 14:31:36 don64 kernel: [  267.297939]  [<ffffffff8107e9d0>] ? process_one_work+0x320/0x320
Nov 12 14:31:36 don64 kernel: [  267.297944]  [<ffffffff8107e9d0>] ? process_one_work+0x320/0x320
Nov 12 14:31:36 don64 kernel: [  267.297951]  [<ffffffff81083814>] kthread+0xc4/0xe0
Nov 12 14:31:36 don64 kernel: [  267.297957]  [<ffffffff8111e09e>] ? kfree+0xde/0xf0
Nov 12 14:31:36 don64 kernel: [  267.297963]  [<ffffffff81083750>] ? kthread_create_on_node+0x170/0x170
Nov 12 14:31:36 don64 kernel: [  267.297971]  [<ffffffff815ac1ef>] ret_from_fork+0x3f/0x70
Nov 12 14:31:36 don64 kernel: [  267.297976]  [<ffffffff81083750>] ? kthread_create_on_node+0x170/0x170
Nov 12 14:31:36 don64 kernel: [  267.297981] ---[ end trace 4e5f2ee640ba6472 ]---


There would be six or so of these for every turn off of the monitor and when turning on I would get a message on the monitor
that it was going to sleep because it couldn't get a signal. It would work if the hdmi cable was disconnected and then plugged back in.
At least until the next time the monitor turned off.

This was posted on the nouveau bugzilla thread that I found, and it has the same patch that I applied and worked (for me)
I had posted the same thing in that thread once I figured it out, but this comes from one of the devs that works on nouveau,
so I expect it to make it into the kernel.

Code:
$ git log -1
commit ad38b5e72b3acb40b820954f04293a0161e33845
Author: Ben Skeggs <bskeggs at redhat.com>
Date:   Wed Nov 11 13:06:10 2015 +1000

    WIPce/gk104: attempt at better handling of LAUNCHERR

    Very rough, no idea how correct it is at this point, but it prevents
    getteximage-depth from piglit from hanging the GPU.

    Signed-off-by: Ben Skeggs <bskeggs at redhat.com>

- patched with:
$ git diff
diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 36ec8f3..d6afbb0 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -1274,6 +1274,7 @@ nouveau_connector_create(struct drm_device *dev, int
index)
                break;
        }

+       drm_modeset_lock_all(dev);
        ret = nvif_notify_init(&disp->disp, nouveau_connector_hotplug, true,
                               NV04_DISP_NTFY_CONN,
                               &(struct nvif_notify_conn_req_v0) {
@@ -1283,6 +1284,7 @@ nouveau_connector_create(struct drm_device *dev, int
index)
                               sizeof(struct nvif_notify_conn_req_v0),
                               sizeof(struct nvif_notify_conn_rep_v0),
                               &nv_connector->hpd);
+       drm_modeset_unlock_all(dev);
        if (ret)
                connector->polled = DRM_CONNECTOR_POLL_CONNECT;
        else

Ref.
"drm/radeon: Sprinkle drm_modeset_lock_all to appease locking checks"

_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Nov 15, 2015 9:15 pm    Post subject: Reply with quote

Thank you ! :)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum