similar to: [Bug 76732] New: Kworker using 100% CPU

https://bugs.freedesktop.org/show_bug.cgi?id=77073 Priority: medium Bug ID: 77073 Assignee: nouveau at lists.freedesktop.org Summary: [nouveaun NVE0] Attaching displayport spawns kworker taking up 100% cpu QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS:

https://bugs.freedesktop.org/show_bug.cgi?id=76483 Priority: medium Bug ID: 76483 Assignee: nouveau at lists.freedesktop.org Summary: [NV50, bisected, RFC patch] xset dpms force {on,off} does not work over DP QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS:

https://bugs.freedesktop.org/show_bug.cgi?id=82247 Priority: medium Bug ID: 82247 Assignee: nouveau at lists.freedesktop.org Summary: [NVA8] The DisplayPort screen does not light up at first try on Linux 3.16 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS:

https://bugs.freedesktop.org/show_bug.cgi?id=64858 Priority: medium Bug ID: 64858 Assignee: nouveau at lists.freedesktop.org Summary: Nouveau sees invalid EDID for eDP-1 whenever that display is turned off QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

Hi, for quite some time now I would like to switch from the proprietary driver to nouveau, using a GK107 (Quadro) in a thinkpad. Unfortunately the monitors connected to the lenovo "ultra dock" are not properly recognized when using nouveau. The laptop contains a multiplexer: so in the bios it can be selected, whether the docking station's DP/HDMI/VGA-Ports are "directly"

https://bugs.freedesktop.org/show_bug.cgi?id=34429 Summary: Failure during resume on NV50: INIT_AUXCH: rd auxch fail -121 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d

https://bugs.freedesktop.org/show_bug.cgi?id=76475 Priority: medium Bug ID: 76475 Assignee: nouveau at lists.freedesktop.org Summary: Nouveau fails to load due to unknown opcode 0x80 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: patrick.clara at

This fixes quite a number of runtime PM bugs I found that have been causing some pretty nasty issues such as: - Deadlocking on boot - Connector probing potentially not working while the GPU is in runtime suspend - i2c char dev not working while the GPU is in runtime suspend - aux char dev not working while the GPU is in runtime suspend There's definitely more parts of nouveau that need

This is a trimmed down version of https://patchwork.freedesktop.org/series/46637/ with all of the review comments addressed. The last version of this series had fixes for the i2c and DP aux busses to ensure that the GPU would be turned on whenever anything tried to access the i2c/aux busses. Unfortunately: one of the fixes apparently contained some very incorrect usage of Linux's runtime PM

I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself, qemu still eats a lot of CPU if launched like this qemu-system-x86_64 -cdrom ~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 1G -display sdl,gl=on -enable-kvm and left for few hours. top - 07:38:01 up 18:05, 2 users, load average: 2,00, 1,89, 1,83 Tasks: 224 total, 3 running, 221 sleeping, 0

https://bugs.freedesktop.org/show_bug.cgi?id=54646 Bug #: 54646 Summary: i2c failure on Quadro NVS 4200M (GF119 (NVD9)) Classification: Unclassified Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are

On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > When DP MST hubs get confused, they can occasionally stop responding for > a good bit of time up until the point where the DRM driver manages to > do the right DPCD accesses to get it to start responding again. In a > worst case scenario however, this process can take upwards of 10+ > seconds. > > Currently we use

Hi, Trying a new kernel on old [NV04] system I get tons of nouveau 0000:01:00.0: gr: intr 00000001 [NOTIFY] nsource 00000040 [ILLEGAL_MTHD] nstatus 00004000 [PROTECTION_FAULT] ch 0 [DRM] subc 3 class 004a mthd 02fc data 00000003 errors when operating on console. As I updated from 4.3 kernel, a bisect does not feel like the best start. What is that 02fc method which fbcon is probably

On Mon, Apr 20, 2015 at 11:03:43AM -0400, Martes wrote: > Tasks: 272 total, 2 running, 270 sleeping, 0 stopped, 0 zombie > %Cpu(s): 7.1 us, 18.3 sy, 0.0 ni, 73.8 id, 0.7 wa, 0.0 hi, 0.1 si, 0.0 st > KiB Mem : 32679644 total, 402520 free, 9889728 used, 22387396 buff/cache > KiB Swap: 0 total, 0 free, 0 used. 21951812 avail Mem > > PID USER

--- drivers/gpu/drm/nouveau/nouveau_bios.c | 47 ++++++++++++++----------------- 1 files changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 5eec5ed..04ac564 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -181,43 +181,42 @@ struct methods { const char

http://bugs.freedesktop.org/show_bug.cgi?id=27398 Summary: displayport: x server does not draw anything on ThinkPad T410 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo:

I have a Nvidia NVS310 installed in my Linux computer for a few years. It works well with the Nvidia driver, and not so well with the Linux nouveau driver. The Nvidia NVS310 has never worked well with Linux. In the beginning (many years ago) I decided to install Nvidia proprietary drivers, but every kernel upgrade would require an additional effort to have the driver working. That was enough