Bug 89247 - [NVE7] short display freeze on xrandr --query
Summary: [NVE7] short display freeze on xrandr --query
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-20 22:45 UTC by exi+freedesktop
Modified: 2015-06-29 15:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output containing nouveau (310.61 KB, text/plain)
2015-05-05 19:57 UTC, exi+freedesktop
no flags Details
dmesg of boot with video=DP-1:d (73.50 KB, text/plain)
2015-05-05 20:43 UTC, exi+freedesktop
no flags Details
dmesg with verbose nouveau (38.88 KB, application/octet-stream)
2015-05-05 21:48 UTC, exi+freedesktop
no flags Details
strace of xrandr with timing info (36.05 KB, text/plain)
2015-05-05 22:12 UTC, exi+freedesktop
no flags Details
Flame graph of xrandr -q perf events (88.76 KB, image/svg+xml)
2015-05-06 08:23 UTC, exi+freedesktop
no flags Details
Flame graph of xrandr -q perf events more samples, debug kernel (262.15 KB, image/svg+xml)
2015-05-06 09:35 UTC, exi+freedesktop
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description exi+freedesktop 2015-02-20 22:45:05 UTC
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

xf86-video-nouveau 1.0.11-3

This might possibly be an nouveau bug but as xrandr is triggering this behavior, I'm going to report a bug here first.
Comment 1 exi+freedesktop 2015-05-05 19:50:36 UTC
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:
extra/xf86-video-nouveau 1.0.11-3
and
extra/xorg-xrandr 1.4.3-1
Comment 2 Ilia Mirkin 2015-05-05 19:53:35 UTC
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.
Comment 3 exi+freedesktop 2015-05-05 19:57:54 UTC
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
Comment 4 Ilia Mirkin 2015-05-05 20:01:53 UTC
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?
Comment 5 exi+freedesktop 2015-05-05 20:06:24 UTC
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.
Comment 6 exi+freedesktop 2015-05-05 20:07:38 UTC
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.
Comment 7 Tobias Klausmann 2015-05-05 20:08:04 UTC
> 
> 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" ?
Comment 8 exi+freedesktop 2015-05-05 20:12:25 UTC
└> 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  
   1680x1050     59.95  
   1400x1050     59.98  
   1280x1024     59.89  
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   720x400       59.55  
   640x400       59.95  
   640x350       59.77  
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)
Comment 9 exi+freedesktop 2015-05-05 20:13:43 UTC
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.
Comment 10 Ilia Mirkin 2015-05-05 20:15:54 UTC
What if you just disable DP-1 on boot, so something like:

video=DP-1:d
Comment 11 Tobias Klausmann 2015-05-05 20:19:43 UTC
(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?
Comment 12 exi+freedesktop 2015-05-05 20:30:45 UTC
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  
   1400x1050     59.98  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
VGA2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Comment 13 exi+freedesktop 2015-05-05 20:43:44 UTC
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.
Comment 14 Tobias Klausmann 2015-05-05 21:09:32 UTC
(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.
Comment 15 exi+freedesktop 2015-05-05 21:11:38 UTC
I made a small video documenting what is happening when i change the display configuration:

http://dump.wthack.de/nouveau.webm

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.
Comment 16 exi+freedesktop 2015-05-05 21:30:13 UTC
Tobias Klausmann:
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.
Comment 17 Ilia Mirkin 2015-05-05 21:38:00 UTC
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.
Comment 18 Tobias Klausmann 2015-05-05 21:47:52 UTC
(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...
Comment 19 exi+freedesktop 2015-05-05 21:48:07 UTC
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:
http://dump.wthack.de/dmesg-nouveau-debug
Comment 20 exi+freedesktop 2015-05-05 22:05:59 UTC
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
Comment 21 exi+freedesktop 2015-05-05 22:12:33 UTC
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.
Comment 22 exi+freedesktop 2015-05-06 07:07:59 UTC
I just booted ubuntu 14.10 desktop from an USB stick to rule out any misconfiguration on my archlinux.

Ubuntu comes with
nouveau 1.1.2
xrandr 1.4.1
Xorg 1.16.0

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.
Comment 23 exi+freedesktop 2015-05-06 08:23:53 UTC
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.
Comment 24 exi+freedesktop 2015-05-06 09:35:25 UTC
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'
Comment 25 exi+freedesktop 2015-05-11 10:57:47 UTC
Any updates on this? Is there any debug information i can provide?
Maybe add perf event counters inside nouveau to trace the hickup better?
Comment 26 exi+freedesktop 2015-06-29 15:50:07 UTC
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.


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.