Bug 77529

Summary:

[NVE7] NVS 510 DP-3 output doesn't work

Product:

xorg

Reporter:

sergio <sergio+it>

Component:

Driver/nouveau

Assignee:

Nouveau Project <nouveau>

Status:

RESOLVED WORKSFORME

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

sergio+it

Version:

unspecified

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
dmesg (no monitors connected)	none
dmesg (only DP1 is connected)	none
dmesg (only DP3 is connected)	none
vbios.rom (no monitors connected)	none
vbios.rom (only DP1 is connected)	none

Description sergio 2014-04-16 14:15:41 UTC

DP-3 output doesn't work on NVS 510 (Kepler, NVE7, GK107) card.

As soon as I load nouveau, third output becomes blank. All other outputs, including the fourth (last one) works fine.

xorg properly detects monitor and its modes on buggy videoout.
xrandr shows monitor as connected and enabled.
I see no errors anywhere.

I've tested only compiled debian kernels 3.10 -- 3.14

Let me know what output should I provide or how could I help to solve this bug.

Comment 1 Ilia Mirkin 2014-04-16 14:44:41 UTC

Is it some enormous monitor (resolution-wise)? If so, try a lower resolution. (A change to add support for the higher frequencies went into 3.15-rc1.)

Is this a laptop + dock? If so, which ones?

Can you check if there's a kworker taking up 100% of cpu time (of 1 cpu)?

Is the monitor actually connected via DP, or is it a DP -> HDMI (or DVI) situation?

Comment 2 sergio 2014-04-16 15:08:04 UTC

(In reply to comment #1)
> Is it some enormous monitor (resolution-wise)?
No.

> Is this a laptop + dock? If so, which ones?
No. It is multimonitor, 4xminiDP videocard:
http://www.nvidia.com/object/nvs-510-graphics-card.html

> Can you check if there's a kworker taking up 100% of cpu time (of 1 cpu)?
Checked, no.

> Is the monitor actually connected via DP, or is it a DP -> HDMI (or DVI)
> situation?
All four monitors are connected via Apple miniDP to VGA adapters:
http://store.apple.com/us/product/MB572Z/B/mini-displayport-to-vga-adapter

Comment 3 Ilia Mirkin 2014-04-16 20:01:40 UTC

(In reply to comment #2)
> (In reply to comment #1)
> > Is it some enormous monitor (resolution-wise)?
> No.
> 
> > Is this a laptop + dock? If so, which ones?
> No. It is multimonitor, 4xminiDP videocard:
> http://www.nvidia.com/object/nvs-510-graphics-card.html
> 
> > Can you check if there's a kworker taking up 100% of cpu time (of 1 cpu)?
> Checked, no.
> 
> > Is the monitor actually connected via DP, or is it a DP -> HDMI (or DVI)
> > situation?
> All four monitors are connected via Apple miniDP to VGA adapters:
> http://store.apple.com/us/product/MB572Z/B/mini-displayport-to-vga-adapter

Very interesting. So you have 4 identical DP->VGA adapters, each plugged into similar (identical?) monitors, and DP-3 is always the one that fails?

Can you attach a dmesg when booting with

nouveau.debug=VBIOS=trace,PDISP=trace drm.debug=0xe

That should provide a bunch of debug info, perhaps even enough to tell what's going on.

Additionally, please attach your vbios (/sys/kernel/debug/dri/0/vbios.rom).

Comment 4 sergio 2014-04-16 20:14:29 UTC

(In reply to comment #3)

> Very interesting. So you have 4 identical DP->VGA adapters, each plugged
> into similar (identical?) monitors, and DP-3 is always the one that fails?

Right. Four identical DP->VGA adapters, two pairs of identical monitors (2x LG L1710S 1280x1024, 2x DELL E156FP 1024x768)


> Can you attach...

Tomorrow.

Comment 5 sergio 2014-04-17 11:55:50 UTC

Created attachment 97506 [details]
dmesg (no monitors connected)

Comment 6 sergio 2014-04-17 11:59:08 UTC

Created attachment 97507 [details]
dmesg (only DP1 is connected)

Comment 7 sergio 2014-04-17 11:59:40 UTC

Created attachment 97508 [details]
dmesg (only DP3 is connected)

Comment 8 sergio 2014-04-17 12:00:51 UTC

Created attachment 97509 [details]
vbios.rom (no monitors connected)

Comment 9 sergio 2014-04-17 12:01:26 UTC

Created attachment 97510 [details]
vbios.rom (only DP1 is connected)

Comment 10 sergio 2014-04-17 12:06:24 UTC

vbios.rom with only DP3 connected is the same as with no monitors.

Comment 11 Ilia Mirkin 2014-04-24 20:48:22 UTC

I haven't analyzed them, but vbios.rom should _not_ be a function of what's plugged in. I sincerely hope that both of those files are the same. If they're different, perhaps it's because one is retrieved from PROM and the other from PRAMIN or something (as the VBIOS code doesn't copy it to PRAMIN if nothing's plugged in?)

Looking at the dmesg's for DP1 vs DP3, a few observations:

DP1:
[    8.484516] nouveau D[   PDISP][0000:01:00.0] supervisor 00000001
[    8.484521] nouveau D[   PDISP][0000:01:00.0] head 0: 0x00011100
[    8.484524] nouveau D[   PDISP][0000:01:00.0] head 1: 0x00000000
[    8.484528] nouveau D[   PDISP][0000:01:00.0] head 2: 0x00000000
[    8.484532] nouveau D[   PDISP][0000:01:00.0] head 3: 0x00000000
[    8.484559] nouveau T[   VBIOS][0000:01:00.0] 0x5fe1[0]: DONE
[    8.516076] nouveau D[   PDISP][0000:01:00.0] supervisor 00000002
[    8.516080] nouveau D[   PDISP][0000:01:00.0] head 0: 0x00011100
[    8.516083] nouveau D[   PDISP][0000:01:00.0] head 1: 0x00000000
[    8.516087] nouveau D[   PDISP][0000:01:00.0] head 2: 0x00000000
[    8.516090] nouveau D[   PDISP][0000:01:00.0] head 3: 0x00000000
[    8.516114] nouveau T[   VBIOS][0000:01:00.0] 0x5fe2[0]: NV_REG	R[0x80616600] &= 0xfffffffe |= 0x00000000
[    8.516118] nouveau T[   VBIOS][0000:01:00.0] 0x5fef[0]: DONE
[    8.516367] nouveau T[   VBIOS][0000:01:00.0] 0x5e15[0]: NV_REG	R[0x00ea80] &= 0xfffffffd |= 0x00000002
[    8.516371] nouveau T[   VBIOS][0000:01:00.0] 0x5e22[0]: SUB_DIRECT	0x5ff1

DP3:
[    8.487921] nouveau D[   PDISP][0000:01:00.0] supervisor 00000001
[    8.487925] nouveau D[   PDISP][0000:01:00.0] head 0: 0x00011100
[    8.487929] nouveau D[   PDISP][0000:01:00.0] head 1: 0x00000000
[    8.487933] nouveau D[   PDISP][0000:01:00.0] head 2: 0x00000000
[    8.487936] nouveau D[   PDISP][0000:01:00.0] head 3: 0x00000000
[    8.487958] nouveau T[   VBIOS][0000:01:00.0] 0x5fe1[0]: DONE
[    8.516202] nouveau D[   PDISP][0000:01:00.0] supervisor 00000002
[    8.516206] nouveau D[   PDISP][0000:01:00.0] head 0: 0x00011100
[    8.516210] nouveau D[   PDISP][0000:01:00.0] head 1: 0x00000000
[    8.516213] nouveau D[   PDISP][0000:01:00.0] head 2: 0x00000000
[    8.516217] nouveau D[   PDISP][0000:01:00.0] head 3: 0x00000000
[    8.516236] nouveau T[   VBIOS][0000:01:00.0] 0x5fe2[0]: NV_REG	R[0x80616600] &= 0xfffffffe |= 0x00000000
[    8.516240] nouveau T[   VBIOS][0000:01:00.0] 0x5fef[0]: DONE
[    8.516482] nouveau T[   VBIOS][0000:01:00.0] 0x5b66[0]: SUB_DIRECT	0x5ff1

Note that location 5b66 is executed for DP3 but 5e15 for DP1. Both sub to 5ff1, but the DP1 one also writes to 0xea80 first. Haven't looked at why they call out to different places, but can't think of a reason off-hand.

Then when training the link,

DP1:
[    8.518909] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: 2 lanes at 270000 KB/s
[    8.519095] nouveau T[   VBIOS][0000:01:00.0] 0x5d50[0]: ZM_REG	R[0x4061c00c] = 0x01000300
[    8.519098] nouveau T[   VBIOS][0000:01:00.0] 0x5d59[0]: NV_REG	R[0x4061c010] &= 0xff0fffff |= 0x00400000
[    8.519102] nouveau T[   VBIOS][0000:01:00.0] 0x5d66[0]: NV_REG	R[0x4061c014] &= 0xffffffff |= 0x00000000
[    8.519106] nouveau T[   VBIOS][0000:01:00.0] 0x5d73[0]: DONE
[    8.519116] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: training pattern 1
[    8.519481] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 00
[    8.519495] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 00
[    8.520892] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 00 00 00 00 cc cc
[    8.520894] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 38
[    8.520912] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 38
[    8.522313] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 cc cc
[    8.522315] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: training pattern 2
[    8.523317] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 cc cc
[    8.523319] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 38
[    8.523336] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 38
[    8.525043] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 88 88
[    8.525045] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 10
[    8.525063] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 10
[    8.526763] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 44 44
[    8.526765] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 08
[    8.526780] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 08
[    8.528483] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 00 00
[    8.528485] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 00
[    8.528503] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 00
[    8.530279] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 11 00 00 00 44 44
[    8.530281] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 08
[    8.530296] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 08
[    8.531999] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: status 77 00 01 00 44 44
[    8.532007] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 0 08
[    8.532025] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: config lane 1 08
[    8.533096] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f44: training pattern 0

DP3:
[    8.519010] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: 2 lanes at 270000 KB/s
[    8.519196] nouveau T[   VBIOS][0000:01:00.0] 0x5b1a[0]: ZM_REG	R[0x4061c00c] = 0x01000300
[    8.519199] nouveau T[   VBIOS][0000:01:00.0] 0x5b23[0]: NV_REG	R[0x4061c010] &= 0xff0fffff |= 0x00400000
[    8.519203] nouveau T[   VBIOS][0000:01:00.0] 0x5b30[0]: NV_REG	R[0x4061c014] &= 0xffffffff |= 0x00000000
[    8.519207] nouveau T[   VBIOS][0000:01:00.0] 0x5b3d[0]: DONE
[    8.519216] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: training pattern 1
[    8.519581] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 00
[    8.519595] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 00
[    8.520995] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.520998] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.521014] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.522419] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.522421] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.522438] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.523844] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.523846] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.523862] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.525269] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.525271] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.525287] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.526690] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.526692] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: 2 lanes at 162000 KB/s
[    8.526885] nouveau T[   VBIOS][0000:01:00.0] 0x5b3e[0]: ZM_REG	R[0x4061c00c] = 0x01000000
[    8.526888] nouveau T[   VBIOS][0000:01:00.0] 0x5b47[0]: NV_REG	R[0x4061c010] &= 0xff0fffff |= 0x00300000
[    8.526893] nouveau T[   VBIOS][0000:01:00.0] 0x5b54[0]: NV_REG	R[0x4061c014] &= 0xffffffff |= 0x00000000
[    8.526898] nouveau T[   VBIOS][0000:01:00.0] 0x5b61[0]: DONE
[    8.526908] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: training pattern 1
[    8.527283] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 00
[    8.527297] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 00
[    8.528700] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.528702] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.528719] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.530122] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.530124] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.530141] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.531548] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.531550] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.531567] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.532970] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.532972] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 0 38
[    8.532990] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: config lane 1 38
[    8.534392] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: status 00 00 00 00 cc cc
[    8.534394] nouveau D[   PDISP][0000:01:00.0] DP:0006:0f81: training pattern 0

Which seems like a failure of some sort. The DP3 one falls back to 2x 162MHz lanes, which also fails.

However it is still able to get the mode list from DP3. But I think that's done via a side-channel.

Comment 12 sergio 2014-04-24 23:11:13 UTC

(In reply to comment #11)

> If they're different, perhaps it's because one is retrieved from PROM and the
> other from PRAMIN or something (as the VBIOS code doesn't copy it to PRAMIN
> if nothing's plugged in?)

You're right:

without monitors:
[    6.701295] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x0e73d0a2
[    6.701366] nouveau  [  DEVICE][0000:01:00.0] Chipset: GK107 (NVE7)
[    6.701429] nouveau  [  DEVICE][0000:01:00.0] Family : NVE0
[    6.704392] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[    6.704462] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    6.704526] nouveau  [   VBIOS][0000:01:00.0] checking PROM for image...
[    6.816794] nouveau  [   VBIOS][0000:01:00.0] ... checksum invalid
[    6.816857] nouveau  [   VBIOS][0000:01:00.0] checking ACPI for image...
[    6.816919] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    6.816981] nouveau  [   VBIOS][0000:01:00.0] checking PCIROM for image...
[    6.817051] nouveau 0000:01:00.0: Invalid ROM contents
[    6.818327] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[    6.818392] nouveau  [   VBIOS][0000:01:00.0] using image from PCIROM
[    6.818642] nouveau  [   VBIOS][0000:01:00.0] BIT signature found
[    6.818706] nouveau  [   VBIOS][0000:01:00.0] version 80.07.43.00.0d
[    6.818770] nouveau D[   VBIOS][0000:01:00.0] created



with DP-1:
[    6.654377] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x0e73d0a2
[    6.654447] nouveau  [  DEVICE][0000:01:00.0] Chipset: GK107 (NVE7)
[    6.654510] nouveau  [  DEVICE][0000:01:00.0] Family : NVE0
[    6.657545] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[    6.657624] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    6.657688] nouveau  [   VBIOS][0000:01:00.0] checking PROM for image...
[    6.769576] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[    6.769640] nouveau  [   VBIOS][0000:01:00.0] using image from PROM
[    6.769894] nouveau  [   VBIOS][0000:01:00.0] BIT signature found
[    6.769957] nouveau  [   VBIOS][0000:01:00.0] version 80.07.43.00.0d
[    6.770019] nouveau D[   VBIOS][0000:01:00.0] created



with DP-3: (Is this the begin of the problem?)
[    6.659517] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x0e73d0a2
[    6.659587] nouveau  [  DEVICE][0000:01:00.0] Chipset: GK107 (NVE7)
[    6.659650] nouveau  [  DEVICE][0000:01:00.0] Family : NVE0
[    6.662670] nouveau  [   VBIOS][0000:01:00.0] checking PRAMIN for image...
[    6.662741] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    6.662804] nouveau  [   VBIOS][0000:01:00.0] checking PROM for image...
[    6.775445] nouveau  [   VBIOS][0000:01:00.0] ... checksum invalid
[    6.775510] nouveau  [   VBIOS][0000:01:00.0] checking ACPI for image...
[    6.775574] nouveau  [   VBIOS][0000:01:00.0] ... signature not found
[    6.775637] nouveau  [   VBIOS][0000:01:00.0] checking PCIROM for image...
[    6.775709] nouveau 0000:01:00.0: Invalid ROM contents
[    6.777182] nouveau  [   VBIOS][0000:01:00.0] ... appears to be valid
[    6.777248] nouveau  [   VBIOS][0000:01:00.0] using image from PCIROM
[    6.777498] nouveau  [   VBIOS][0000:01:00.0] BIT signature found
[    6.777562] nouveau  [   VBIOS][0000:01:00.0] version 80.07.43.00.0d
[    6.777626] nouveau D[   VBIOS][0000:01:00.0] created

Comment 13 Ilia Mirkin 2014-04-25 00:09:21 UTC

PCIROM is almost always bad. You want to use PROM. There's a bug on Kepler chips for reading from PROM where it sometimes fails. It should be fixed by

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=18acc6d84eba960804f38a21842c02f3981c1c18

Try either 3.15-rc2 or just apply that commit to your kernel. You may also be able to boot with

nouveau.config=NvBios=PROM

however you'd still end up with a potentially corrupt vbios.

Comment 14 Samuel Pitoiset 2015-06-03 13:28:35 UTC

Can you reproduce this issue with a more recent kernel?
If you no longer have the problem, this issue should be closed.

Comment 15 Samuel Pitoiset 2015-06-14 12:04:19 UTC

Feel free to re-open the issue if the bug still occurs.

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.