When querying my displays with xrandr --query, my display shortly freezes for ~1 second and unfreezes when xrandr finished it's query.
This is very annoying because changing my screen resolution/attaching a new display forces a number of applications to query xrandr for the new display dimensions which leads to a near 15 second sluggish/spontaneous freezing/unfreezing of my screen.
I am running arch Linux with:
X.Org X Server 1.17.1
Release Date: 2015-02-10
xrandr program version 1.4.3
Server reports RandR version 1.4
Linux bugbox 3.19.0-1-ARCH #1 SMP PREEMPT Mon Feb 9 07:08:20 CET 2015 x86_64 GNU/Linux
This might possibly be an nouveau bug but as xrandr is triggering this behavior, I'm going to report a bug here first.
Moving this bug over to Driver/nouveau because it disappears on my machine when i switch the driver over to the integrated Intel gpu.
Also the problem persists with arch package:
I assume you have a pre-G80 GPU? I think it ends up doing a modeset or something crazy like that every time you run xrandr -q.
Created attachment 115553 [details]
dmesg output containing nouveau
I don't know whether this contains the information to answer this question, but I attached all dmesg lines containing nouveau from my journal
It does... you have a fairly new card, so it's not the issue I was thinking about.
nouveau 0000:01:00.0: DP-1: EDID block 0 invalid.
nouveau E[ DRM] DDC responded, but no EDID for DP-1
These lines don't fill me with confidence... Is it an actual monitor connected over DP, or is it the internal panel?
And then PDISP hangs, which is even worse. Someone recently bisected that issue to a commit that came into kernel 3.15 iirc -- does downgrading to 3.14 solve these issues for you?
The card should be an nvidia quadro K1000.
This problem happens every time I connect an external display.
I switch displays daily, it happens on MiniDP as well as VGA ports.
I am not sure I can downgrade because I am using Arch Linux which makes it kind of hard to downgrade anything, but I could try an report back if it worked.
Compiling a recent kernel myself and helping debugging would be much easier for me though.
By the way, the systemd journal lets me access the dmesg messages from old boots, I could attach the dmesg output from a different display via VGA if that would help.
> nouveau 0000:01:00.0: DP-1: EDID block 0 invalid.
> nouveau E[ DRM] DDC responded, but no EDID for DP-1
> These lines don't fill me with confidence... Is it an actual monitor
> connected over DP, or is it the internal panel?
as this seems to be an optimus notebook i guess this is a fake output...
exi, can you post the output of "xrandr --query" ?
└> xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1920x1080 60.02*+ 50.03
VGA-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
Ah, I forgot to mention:
I usually disable the Intel GPU in the BIOS and force it to use the nvidia gpu because the Intel one is unable to drive external displays.
What if you just disable DP-1 on boot, so something like:
(In reply to exi+freedesktop from comment #9)
> Ah, I forgot to mention:
> I usually disable the Intel GPU in the BIOS and force it to use the nvidia
> gpu because the Intel one is unable to drive external displays.
sounds odd letting the dedicated card drive all the outputs.
you checked the outputs with "xrandr --listproviders" i guess? intel really drivers 0 of them?
I just switched to Optimus mode in the bios.
When I boot Linux, the Intel driver takes over immediately.
In this mode, no external displays are recognized for both VGA and DP ports.
In 'Intel only' mode, Windows is unable to recognize any external displays too, so i think it is hard wired.
In 'Nvidia only' mode, all external ports are working, except for the bug described in this ticket.
└> xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x8f cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:Intel
Provider 1: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
└> xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
LVDS2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1920x1080 60.02*+ 50.03
800x600 60.32 56.25
VGA2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Created attachment 115557 [details]
dmesg of boot with video=DP-1:d
Ilia Mirkin: I just booted with video=DP-1:d on the kernel line, no difference.
xrandr -q still takes 0.3 seconds every time it is called leading to massive freezing when attaching an external display.
The dmesg is attached.
(In reply to exi+freedesktop from comment #13)
> xrandr -q still takes 0.3 seconds every time it is called leading to massive
> freezing when attaching an external display.
> The dmesg is attached.
Maybe try to disable all unused outputs (at least DP-2/3), i think you cant for the intel outputs in "nvidia mode", but listing them wont hurt either.
I made a small video documenting what is happening when i change the display configuration:
As you can see it takes around 45 seconds for the machine to be usable again.
I will try disabling the additional port right away.
I disabled DP-2/3 via video=DP-2:d video=DP-3:d and ignored both outputs in the xorg.conf.
The "frozen" time decreased from 45 seconds to 20 seconds, which is at least an improvement, thank you. The xrandr -q time decreased from 0.3 to 0.17 seconds as well.
But waiting 20 seconds for each configuration change is still really bad and causes me a lot of headaches when having to give presentations.
I'm willing to invest some time to debug this further. If I can help please just tell me what I need to do. Compiling custom kernels/modules with experimental patches would definitely be possible.
Just for the record, that is *not* expected to happen -- xrandr -q always returns ~instantly for me. I was aware that it did some funny business on pre-G80 gpu's, but those are 10 years old by now.
Can you try booting with nouveau.debug=debug drm.debug=0xe hopefully that'll provide some info as to where the time is going.
(In reply to Ilia Mirkin from comment #17)
> Just for the record, that is *not* expected to happen -- xrandr -q always
> returns ~instantly for me.
For me as well and i have and nve7 as well
> Can you try booting with nouveau.debug=debug drm.debug=0xe hopefully that'll
> provide some info as to where the time is going.
as an addition: maybe "perf top" can visually aid here, as it really must be stuck in some cycle inside the nouveau kernel module...
Created attachment 115564 [details]
dmesg with verbose nouveau
I attached a compressed dmesg log for the verbose settings, plugging and unplugging an external VGA display.
The plaintext log is too big to upload to this bugtracker but you can view it here:
Running xrandr -q in a loop shows the following symbols high in 'perf top':
62,34% [kernel] [k] ioread32
13,75% [kernel] [k] native_read_tsc
12,56% [kernel] [k] delay_tsc
while nouveau is far down here:
0,61% nouveau_drv.so [.] 0x0000000000007ab0
Created attachment 115567 [details]
strace of xrandr with timing info
I don't know if this helps but here is an 'strace -f -r -C -- xrandr -q' output, showing the slow syscall.
I just booted ubuntu 14.10 desktop from an USB stick to rule out any misconfiguration on my archlinux.
Ubuntu comes with
The problem is even worse here, xrandr -q consistently takes about 0.4 seconds.
I also switched to Windows to rule out any hardware defects.
Display switching under Windows 8 is instant.
Created attachment 115584 [details]
Flame graph of xrandr -q perf events
I captured a 'perf record -F 1000 -a -g'
Attached is a flame graph of where the time is spent.
Created attachment 115585 [details]
Flame graph of xrandr -q perf events more samples, debug kernel
I recompiled my kernel with debug symbols and did a perf record with higher sampling rate.
Flame graph of 'perf record -F 12600 -ag -- xrandr -q'
Any updates on this? Is there any debug information i can provide?
Maybe add perf event counters inside nouveau to trace the hickup better?
I just tested the latest linux-4.1 branch from git://anongit.freedesktop.org/nouveau/linux-2.6 and this issue still persists for me with this kernel and nouveau driver.