Bug 89247

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

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  
   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)

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:

video=DP-1:d

(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  
   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)

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:

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.

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.

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:
http://dump.wthack.de/dmesg-nouveau-debug

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
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.

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.

-- 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/171.