Bug 107167 - constantly firing events while screen attached to NVIDIA card is disabled
Summary: constantly firing events while screen attached to NVIDIA card is disabled
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-09 14:10 UTC by Sam Morris
Modified: 2019-12-04 09:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
output of 'udevadm monitor -p | ts' while screen is locked (163.33 KB, text/plain)
2018-07-09 14:10 UTC, Sam Morris
no flags Details
kernel log (138.06 KB, text/plain)
2018-07-09 14:13 UTC, Sam Morris
no flags Details
vbios.com (104.00 KB, application/octet-stream)
2018-07-09 16:01 UTC, Sam Morris
no flags Details
full kernel log (586.17 KB, text/plain)
2018-07-09 16:04 UTC, Sam Morris
no flags Details

Description Sam Morris 2018-07-09 14:10:10 UTC
Created attachment 140522 [details]
output of 'udevadm monitor -p | ts' while screen is locked

I've got a Lenovo P50 with hybrid graphics cards:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M2000M] (rev a2)

The internal display is connected to the Intel card. External display ports are wired to the NVIDIA card. I'm using the autobind-GPUs Xorg patch so that I don't have to run `xrandr --setprovideroutputsource` in order to make the external ports usable.

While I'm away from the system, the monitor gets blanked. While it's in this state, I see many change events from the NVIDIA device (udevadm monitor output attached). This exacerbates a memory leak in gnome-desktop that causes clients to consume several GiB of memory after I come back to the laptop, having left it idle over the weekend.
Comment 1 Sam Morris 2018-07-09 14:13:35 UTC
Created attachment 140523 [details]
kernel log

dmesg output, interest parts between 12:00 and 13:00 and 14:50 to 15:00.
Comment 2 Roy 2018-07-09 14:47:47 UTC
I suspect that more information could be useful. A good starting point would be to attach:
- Your VBIOS (obtained from /sys/kernel/debug/dri/<number>/vbios.rom while the GPU is powered on), and
- A full dmesg of a booting system.

Also: is this problem a regression from earlier kernels? If so, have you tried to pinpoint which kernel change (version, but ideally commit) led to this undesirable behaviour?

Thanks!
Comment 3 Sam Morris 2018-07-09 16:01:08 UTC
Created attachment 140524 [details]
vbios.com

I'm not sure if the card currently counts as 'powered on' given:

# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

But here's my current vbios.rom file anyway. If you need me to somehow power the card up and try again then let me know (I'm not sure how to do that - writing "ON" to the file doesn't change the output).
Comment 4 Sam Morris 2018-07-09 16:04:41 UTC
Created attachment 140527 [details]
full kernel log

Here's 'journalctl -k' which goes back to the system boot.
Comment 5 Sam Morris 2018-07-09 16:12:02 UTC
As for a working kernel version: I apologize for not mentioning that I'm using 4.17.3.

    Linux version 4.17.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0  (Debian 7.3.0-24)) #1 SMP Debian 4.17.3-1 (2018-07-02)

While I do have 4.16.16 on the system as well, I'm almost certain that I've seen this behaviour since I first started using this laptop, with much older kernels (well, at least 4.14... maybe 4.9). I remember looking into a this gnome-settings-daemon memory leak back then, but never got to the bottom of it because frankly the laptop was just not stable enough to stay up long enough to reproduce the problem!
Comment 6 Sam Morris 2018-08-28 09:59:02 UTC
I haven't seen this since installing a newer kernel from Debian (4.17.14) and rebooting. Prior to the reboot I was running 4.17.8 and did observe the problem.

I'll resolve this bug when I'm sure the problem is gone.
Comment 7 Martin Peres 2019-12-04 09:43:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/443.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.