Re: [CentOS] Nvidia maximum pixel clock issue in, , kmod-nvidia-384.98

[Alexander Wiedergold]

To: CentOS mailing list <centos@centos.org>


Thema: Re: [CentOS] Nvidia maximum pixel clock issue in

kmod-nvidia-384.98

Dear All,

Start BIOS Configuration and go to Graphic Configuration change On Board 
VGA to PCI Express x16


Automatic is VGA on Board

Bis bald

Alexander


Am 09.01.2018 um 13:00 schrieb centos-requ...@centos.org:

Send CentOS mailing list submissions to
centos@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos
or, via email, send a message with subject or body 'help' to
centos-requ...@centos.org

You can reach the person managing the list at
centos-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS digest..."


Today's Topics:

1. Re: CentOS 7.4 fails to boot as Xen PV guest: resurfaces (now
   also) with centosplus kernel 693.11.6.el7 (Johnny Hughes)
2. Re: Nvidia maximum pixel clock issue in kmod-nvidia-384.98
   (Phil Perry)
3. C6 KPTI cpuinfo flag? (Robert Arkiletian)
4. Re: C6 KPTI cpuinfo flag? (isdtor)
5. Cent OS 7.3 Shared library issue (Aman Sharma)


--

Message: 1
Date: Mon, 8 Jan 2018 06:46:31 -0600
From: Johnny Hughes <joh...@centos.org>
To: centos@centos.org
Subject: Re: [CentOS] CentOS 7.4 fails to boot as Xen PV guest:
resurfaces (now also) with centosplus kernel 693.11.6.el7
Message-ID: <dda9a351-3260-647c-b4f0-5c00f6b3b...@centos.org>
Content-Type: text/plain; charset="utf-8"

On 01/08/2018 12:38 AM, Akemi Yagi wrote:

On Sun, Jan 7, 2018 at 12:07 PM, David Groep <dav...@nikhef.nl> wrote:


Dear all,

Maybe I'm the only one - so before filing it as a bug: it appears that
the latest set of kernel patches in 3.10.0-693.11.6.el7 makes issue
0013763 "CentOS 7.4 kernel (3.10.0-693*) fails to boot as Xen PV guest"
re-surface *also* with the CentOS PLUS kernel. But maybe in a
different way ...

Thanks to the (great!) quick work on making the plus kernel available
(in #14330, thanks for that!) I was able to test the following
combinations:

- 3.10.0-693.11.6.el7.centos.plus works fine on XenServer 7 HVM guests
- 3.10.0-693.11.1.el7.centos.plus works fine on XenServer 7 XenPV guests
- 3.10.0-693.11.6.el7.centos.plus crashes on boot for XS7 XenPV guests
   immediately after the boot stage where the PS/2 drivers are loaded

Crashing does not depend on the amount of VM memory or #cores/sockets.
Also, the tell-tale "mm/vmalloc.c" failure output is no longer present.
The system 'just' crashes (with the kernel log lines as below) around the
time of the i8042 controller probing.

Obviously the stock upstream 3.10.0-693.11.6.el7 crashes as well for
XS7 XenPV guests, but that was to be expected as per 0013763.
It crashes in the same way, around the time of the i8042 probes.

Can anyone (maybe bill_mcgonigle?) reproduce the issue?
Did the KPTI patches break the XenPV fixes in CentOS Plus per 13763?
Or is this a new XenPV issue?


?You may want to be watching the centos-virt mailing list. Xen-related
issues are discussed there.

This thread:

?
https://lists.centos.org/pipermail/centos-virt/2018-January/005716.html

?has a response from Johnny Hughes with a possible solution.


And specifically, this message has links to the 4.9.75 x86_64 kernel
that will boot and run as a Xen PV kernel:

https://lists.centos.org/pipermail/centos-virt/2018-January/005721.html

Also, the latest Xen Dom0 kernel 4.9.75 kernel will also boot a DomU Xen
PV.  That kernel is still in testing, and also requires the latest
linux-firmware rpms:

https://buildlogs.centos.org/centos/7/virt/x86_64/

or

https://buildlogs.centos.org/centos/6/virt/x86_64/


(And your xen version ... xen-44/, xen-46/, xen-48/)

Those kernels should be signed released to the main Xen repo sometime
this week.

And as someone has mentioned in another thread (Phil Perry), please read
Greg K-H's (the Kernel.org LTS maintainer, he is in charge of the 4.9.x
LTS tree that we use for the above kernels):

http://www.kroah.com/log/blog/2018/01/06/meltdown-status/

Thanks,
Johnny Hughes


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.centos.org/pipermail/centos/attachments/20180108/d7fcd69f/attachment-0001.sig>

--

Message: 2
Date: Mon, 8 Jan 2018 21:33:44 +
From: Phil Perry <ppe...@elrepo.org>
To: centos@centos.org
Subject: Re: [CentOS] Nvidia maximum pixel clock issue in
kmod-nvidia-384.98
Message-ID: <4a6548b4-a8e9-6622-0c93-679e6a454...@elrepo.org>
Content-Type: text/plain; charset=utf-8; format=flowed

On 08/01/18 10:22, Danny Smit wrote:

On Sat, Jan 6, 2018 at 2:27 PM, Phil Perry <ppe...@elrep

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Phil Perry]

On 08/01/18 10:22, Danny Smit wrote:

On Sat, Jan 6, 2018 at 2:27 PM, Phil Perry  wrote:


I've just built and released 384.111 to the elrepo main repository, so it
should show up on the mirrors shortly.


As expected, the 384.111 also solves the problem in my case.

Thanks for the support everyone.



Thanks for the feedback Danny - glad we got it resolved.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Danny Smit]

On Sat, Jan 6, 2018 at 2:27 PM, Phil Perry  wrote:
>
> I've just built and released 384.111 to the elrepo main repository, so it
> should show up on the mirrors shortly.

As expected, the 384.111 also solves the problem in my case.

Thanks for the support everyone.

Regards,
Danny
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Phil Perry]

On 06/01/18 12:00, Zube wrote:

On Sat Jan 06 12:27:22 PM, Danny Smit wrote:


  I normally certainly prefer the stability of the long-lived releases.
  I noticed an update was just released of the long-lived release:
  384.111.  The notes for this release say:

Fixed a regression that prevented displays connected via some
types of passive adapters (e.g. DMS-59 to VGA or DVI) from working
correctly. The regression was introduced with driver version 384.98.

  That sounds very much like my issue. I will verify next Monday if
  that solves it for me. Can I assume that new 384.111 release will
  make it into the main elrepo repository eventually?


I can confirm the 384.111 version fixes the DVI problems with the
NVS-315.

Cheers,
Zube


I've just built and released 384.111 to the elrepo main repository, so 
it should show up on the mirrors shortly.


Thanks for the confirmation it fixes the issue. I've just updated my 
local machine, which was unaffected by this issue, ran a few quick tests 
(glmark2) and can confirm 384.11 looks fine on my hardware.


Just keep in mind, this will be a package 'downgrade' from version 
387.34 in the elrepo testing repository due to the lower version number.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Zube]

On Sat Jan 06 12:27:22 PM, Danny Smit wrote:

>  I normally certainly prefer the stability of the long-lived releases.
>  I noticed an update was just released of the long-lived release:
>  384.111.  The notes for this release say:
> 
>Fixed a regression that prevented displays connected via some
>types of passive adapters (e.g. DMS-59 to VGA or DVI) from working
>correctly. The regression was introduced with driver version 384.98.
> 
>  That sounds very much like my issue. I will verify next Monday if
>  that solves it for me. Can I assume that new 384.111 release will
>  make it into the main elrepo repository eventually?

I can confirm the 384.111 version fixes the DVI problems with the
NVS-315.

Cheers,
Zube
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Danny Smit]

On Thu, Jan 4, 2018 at 9:40 PM, Phil Perry  wrote:
> Normally elrepo only releases the long term branch for Enterprise Linux, on
> the assumption EL users will welcome the implied stability over more
> frequent and potentially buggy releases.

> In this case I had built the current short lived release as a user requested
> it for compatibility with the latest CUDA. However, as it is a short term
> branch release, it will stay in the testing repository indefinitely and will
> not be promoted to the main repository. Once it's been superseded by a
> subsequent long term branch release I will likely just delete it from the
> testing repo. That said, it should be fine to use (at your own risk).
>
Thanks,

I normally certainly prefer the stability of the long-lived releases.
I noticed an update was just released of the long-lived release:
384.111.
The notes for this release say:

>  Fixed a regression that prevented displays connected via some types of 
> passive adapters (e.g. DMS-59 to VGA or DVI) from working correctly. The 
> regression was introduced with driver version 384.98.

That sounds very much like my issue. I will verify next Monday if that
solves it for me. Can I assume that new 384.111 release will make it
into the main elrepo repository eventually?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Phil Perry]

On 04/01/18 09:12, Danny Smit wrote:

On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry  wrote:

On 03/01/18 20:14, Zube wrote:


I can confirm that this happens with the driver downloaded from NVIDIA.
I had to fall back to the .90 driver to get it to work for all my
NVS 315s (with dual DVI) running on 7.4 / 6.9.


Thanks. For reference, I did the same test. With the driver downloaded
from NVIDIA the issues also occurs in my case.


I couldn't find any reports upstream at nvidia so am unsure if they are
aware of the issue.


Where do you look for this at nvidia, in the community forums? Or is
there another publicly available bug tracking system? (which I was
unable to find)



I would start by posting in the forums as you did (below). I'm not aware 
of an official bug tracker either.



There is an updated version 387.34 short-lived branch driver available in
the elrepo testing repository that you could test to see whether the issue
has been fixed in this latest release (only available for el7 currently).


Surprisingly, I couldn't reproduce the issue anymore. Therefore at
first sight it seems to be fixed in the 387.34 driver.



Excellent. Hopefully sounds like the issue may already have been fixed.


I posted a question at nvidia anyway:
https://devtalk.nvidia.com/default/topic/1028268/linux/nvidia-maximum-pixel-clock-issue-in-kmod-nvidia-384-98/
(although I'm not sure it is the right place, still having some issues
finding my way at nvidia.com, other suggestions or directions are
welcome of course)



Yes, I would have posted to the same place.


Will short-lived drivers ever make it into the official elrepo
repository? Or will only the long-lived drivers be included in the
official repository?


Normally elrepo only releases the long term branch for Enterprise Linux, 
on the assumption EL users will welcome the implied stability over more 
frequent and potentially buggy releases.


In this case I had built the current short lived release as a user 
requested it for compatibility with the latest CUDA. However, as it is a 
short term branch release, it will stay in the testing repository 
indefinitely and will not be promoted to the main repository. Once it's 
been superseded by a subsequent long term branch release I will likely 
just delete it from the testing repo. That said, it should be fine to 
use (at your own risk).



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Danny Smit]

On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry  wrote:
> On 03/01/18 20:14, Zube wrote:
>>
>> I can confirm that this happens with the driver downloaded from NVIDIA.
>> I had to fall back to the .90 driver to get it to work for all my
>> NVS 315s (with dual DVI) running on 7.4 / 6.9.

Thanks. For reference, I did the same test. With the driver downloaded
from NVIDIA the issues also occurs in my case.

> I couldn't find any reports upstream at nvidia so am unsure if they are
> aware of the issue.

Where do you look for this at nvidia, in the community forums? Or is
there another publicly available bug tracking system? (which I was
unable to find)

> There is an updated version 387.34 short-lived branch driver available in
> the elrepo testing repository that you could test to see whether the issue
> has been fixed in this latest release (only available for el7 currently).

Surprisingly, I couldn't reproduce the issue anymore. Therefore at
first sight it seems to be fixed in the 387.34 driver.

I posted a question at nvidia anyway:
https://devtalk.nvidia.com/default/topic/1028268/linux/nvidia-maximum-pixel-clock-issue-in-kmod-nvidia-384-98/
(although I'm not sure it is the right place, still having some issues
finding my way at nvidia.com, other suggestions or directions are
welcome of course)

Will short-lived drivers ever make it into the official elrepo
repository? Or will only the long-lived drivers be included in the
official repository?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Walter H.]

On Thu, January 4, 2018 05:22, Phil Perry wrote:

> I couldn't find any reports upstream at nvidia so am unsure if they are
> aware of the issue. For reference, my GK208 [GeForce GT 730] in my test
> system is unaffected by the issue and is working fine with the 384.98
> driver over DVI.

keep in mind that an nVIDIA GeForce is a consumer graphics device and the
NVS xxx series device is a business product similar to the nVIDIA Quadro
...
(with Windows they have different video drivers ...)

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Phil Perry]

On 03/01/18 20:14, Zube wrote:

On Wed Jan 03 07:43:04 PM, Phil Perry wrote:


On CentOS 7 I'm running into an issue with the latest nvidia driver
from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64
This driver version seem to introduce issue in detecting video modes
when a monitor is connected using DVI. As soon as the machine attempts
to start X, nothing happens and the monitor goes into sleep mode
reporting that it has 'no signal'.

It is interesting because it occurs with several monitors, but only
when they are connected through DVI. When using VGA it works like a
charm.
Also it did work without problems with the previous driver version
(kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup.

In this case the issue occurs with an Nvidia NVS 315. I don't know if
other nvidia cards are affected.


I can confirm that this happens with the driver downloaded from NVIDIA.
I had to fall back to the .90 driver to get it to work for all my
NVS 315s (with dual DVI) running on 7.4 / 6.9.



Thank you for the confirmation. I found a similar report on debian also 
relating to NVS315 with the 384.98 driver so I'm guessing this is 
hardware specific:


https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1570324.html

I couldn't find any reports upstream at nvidia so am unsure if they are 
aware of the issue. For reference, my GK208 [GeForce GT 730] in my test 
system is unaffected by the issue and is working fine with the 384.98 
driver over DVI.


There is an updated version 387.34 short-lived branch driver available 
in the elrepo testing repository that you could test to see whether the 
issue has been fixed in this latest release (only available for el7 
currently).


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Zube]

On Wed Jan 03 07:43:04 PM, Phil Perry wrote:

> > On CentOS 7 I'm running into an issue with the latest nvidia driver
> > from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64
> > This driver version seem to introduce issue in detecting video modes
> > when a monitor is connected using DVI. As soon as the machine attempts
> > to start X, nothing happens and the monitor goes into sleep mode
> > reporting that it has 'no signal'.
> > 
> > It is interesting because it occurs with several monitors, but only
> > when they are connected through DVI. When using VGA it works like a
> > charm.
> > Also it did work without problems with the previous driver version
> > (kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup.
> > 
> > In this case the issue occurs with an Nvidia NVS 315. I don't know if
> > other nvidia cards are affected.

I can confirm that this happens with the driver downloaded from NVIDIA.
I had to fall back to the .90 driver to get it to work for all my
NVS 315s (with dual DVI) running on 7.4 / 6.9.

Cheers,
Zube
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Phil Perry]

On 03/01/18 15:45, Danny Smit wrote:

Hi everyone,

On CentOS 7 I'm running into an issue with the latest nvidia driver
from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64
This driver version seem to introduce issue in detecting video modes
when a monitor is connected using DVI. As soon as the machine attempts
to start X, nothing happens and the monitor goes into sleep mode
reporting that it has 'no signal'.

It is interesting because it occurs with several monitors, but only
when they are connected through DVI. When using VGA it works like a
charm.
Also it did work without problems with the previous driver version
(kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup.

In this case the issue occurs with an Nvidia NVS 315. I don't know if
other nvidia cards are affected.

The following information from Xorg.0.log seems of interest:

 [   130.447] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
 [   130.447] (--) NVIDIA(0): CRT-0
 [   130.447] (--) NVIDIA(0): CRT-1
 [   130.447] (--) NVIDIA(0): DFP-0 (boot)
 [   130.447] (--) NVIDIA(0): DFP-1
 [   130.447] (--) NVIDIA(0): DFP-2
 [   130.447] (--) NVIDIA(0): DFP-3
 [   130.448] (II) NVIDIA(0): NVIDIA GPU NVS 315 (GF119) at PCI:1:0:0 
(GPU-0)
 [   130.448] (--) NVIDIA(0): Memory: 1048576 kBytes
 [   130.448] (--) NVIDIA(0): VideoBIOS: 75.19.88.00.0b
 [   130.448] (II) NVIDIA(0): Detected PCI Express Link width: 16X
 [   130.462] (--) NVIDIA(GPU-0): CRT-0: disconnected
 [   130.462] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
 [   130.462] (--) NVIDIA(GPU-0):
 [   130.467] (--) NVIDIA(GPU-0): CRT-1: disconnected
 [   130.467] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
 [   130.467] (--) NVIDIA(GPU-0):
 [   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): connected
 [   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): Internal TMDS
 [   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): 0.0 MHz
maximum pixel clock
 [   130.488] (--) NVIDIA(GPU-0):
 [   130.493] (--) NVIDIA(GPU-0): DFP-1: disconnected
 [   130.493] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS
 [   130.493] (--) NVIDIA(GPU-0): DFP-1: 0.0 MHz maximum pixel clock
 [   130.493] (--) NVIDIA(GPU-0):
 [   130.493] (--) NVIDIA(GPU-0): DFP-2: disconnected
 [   130.493] (--) NVIDIA(GPU-0): DFP-2: Internal DisplayPort
 [   130.493] (--) NVIDIA(GPU-0): DFP-2: 480.0 MHz maximum pixel clock
 [   130.493] (--) NVIDIA(GPU-0):
 [   130.493] (--) NVIDIA(GPU-0): DFP-3: disconnected
 [   130.493] (--) NVIDIA(GPU-0): DFP-3: Internal DisplayPort
 [   130.493] (--) NVIDIA(GPU-0): DFP-3: 480.0 MHz maximum pixel clock
 [   130.493] (--) NVIDIA(GPU-0):
 [   130.493] (EE) NVIDIA(GPU-0): Unable to add conservative
default mode "nvidia-auto-select".
 [   130.493] (EE) NVIDIA(GPU-0): Unable to add
"nvidia-auto-select" mode to ModePool.
 [   130.493] (==) NVIDIA(0):
 [   130.493] (==) NVIDIA(0): No modes were requested; the default
mode "nvidia-auto-select"
 [   130.493] (==) NVIDIA(0): will be used as the requested mode.
 [   130.493] (==) NVIDIA(0):
 [   130.493] (WW) NVIDIA(0): No valid modes for
"DFP-0:nvidia-auto-select"; removing.
 [   130.493] (WW) NVIDIA(0):
 [   130.493] (WW) NVIDIA(0): Unable to validate any modes; falling
back to the default mode
 [   130.493] (WW) NVIDIA(0): "nvidia-auto-select".
 [   130.493] (WW) NVIDIA(0):
 [   130.493] (WW) NVIDIA(0): No valid modes for
"DFP-0:nvidia-auto-select"; removing.
 [   130.493] (EE) NVIDIA(0): Unable to use default mode
"nvidia-auto-select".
 [   130.493] (EE) NVIDIA(0): Failing initialization of X screen 0


The log shows "0.0 MHz maximum pixel clock" for the DVI connections.
When enabling ModeDebug in the xorg.conf it shows that all of the
resolutions are rejected because of incorrect maximum pixel clock:

 [  1354.589] (II) NVIDIA(GPU-0):
 [  1354.589] (II) NVIDIA(GPU-0): --- Building ModePool for Philips
240S4 (DFP-0) ---
 [  1354.589] (WW) NVIDIA(GPU-0):   Validating Mode "1920x1200_60":
 [  1354.589] (WW) NVIDIA(GPU-0): Mode Source: EDID
 [  1354.589] (WW) NVIDIA(GPU-0): 1920 x 1200 @ 60 Hz
 [  1354.589] (WW) NVIDIA(GPU-0):   Pixel Clock  : 154.00 MHz
 [  1354.589] (WW) NVIDIA(GPU-0):   HRes, HSyncStart : 1920, 1968
 [  1354.589] (WW) NVIDIA(GPU-0):   HSyncEnd, HTotal : 2000, 2080
 [  1354.589] (WW) NVIDIA(GPU-0):   VRes, VSyncStart : 1200, 1203
 [  1354.589] (WW) NVIDIA(GPU-0):   VSyncEnd, VTotal : 1209, 1235
 [  1354.589] (WW) NVIDIA(GPU-0):   Sync Polarity: +H -V
 [  1354.589] (WW) NVIDIA(GPU-0): Mode is rejected: PixelClock
(154.0 MHz) too high for
 [  1354.589] (WW) NVIDIA(GPU-0): Display Device (Max: 0.0 MHz).
 [  1354.589] (WW) NVIDIA(GPU-0): Mode "1920x1200_60" is 

[CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98

[Danny Smit]

Hi everyone,

On CentOS 7 I'm running into an issue with the latest nvidia driver
from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64
This driver version seem to introduce issue in detecting video modes
when a monitor is connected using DVI. As soon as the machine attempts
to start X, nothing happens and the monitor goes into sleep mode
reporting that it has 'no signal'.

It is interesting because it occurs with several monitors, but only
when they are connected through DVI. When using VGA it works like a
charm.
Also it did work without problems with the previous driver version
(kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup.

In this case the issue occurs with an Nvidia NVS 315. I don't know if
other nvidia cards are affected.

The following information from Xorg.0.log seems of interest:

[   130.447] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
[   130.447] (--) NVIDIA(0): CRT-0
[   130.447] (--) NVIDIA(0): CRT-1
[   130.447] (--) NVIDIA(0): DFP-0 (boot)
[   130.447] (--) NVIDIA(0): DFP-1
[   130.447] (--) NVIDIA(0): DFP-2
[   130.447] (--) NVIDIA(0): DFP-3
[   130.448] (II) NVIDIA(0): NVIDIA GPU NVS 315 (GF119) at PCI:1:0:0 (GPU-0)
[   130.448] (--) NVIDIA(0): Memory: 1048576 kBytes
[   130.448] (--) NVIDIA(0): VideoBIOS: 75.19.88.00.0b
[   130.448] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[   130.462] (--) NVIDIA(GPU-0): CRT-0: disconnected
[   130.462] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[   130.462] (--) NVIDIA(GPU-0):
[   130.467] (--) NVIDIA(GPU-0): CRT-1: disconnected
[   130.467] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[   130.467] (--) NVIDIA(GPU-0):
[   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): connected
[   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): Internal TMDS
[   130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): 0.0 MHz
maximum pixel clock
[   130.488] (--) NVIDIA(GPU-0):
[   130.493] (--) NVIDIA(GPU-0): DFP-1: disconnected
[   130.493] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS
[   130.493] (--) NVIDIA(GPU-0): DFP-1: 0.0 MHz maximum pixel clock
[   130.493] (--) NVIDIA(GPU-0):
[   130.493] (--) NVIDIA(GPU-0): DFP-2: disconnected
[   130.493] (--) NVIDIA(GPU-0): DFP-2: Internal DisplayPort
[   130.493] (--) NVIDIA(GPU-0): DFP-2: 480.0 MHz maximum pixel clock
[   130.493] (--) NVIDIA(GPU-0):
[   130.493] (--) NVIDIA(GPU-0): DFP-3: disconnected
[   130.493] (--) NVIDIA(GPU-0): DFP-3: Internal DisplayPort
[   130.493] (--) NVIDIA(GPU-0): DFP-3: 480.0 MHz maximum pixel clock
[   130.493] (--) NVIDIA(GPU-0):
[   130.493] (EE) NVIDIA(GPU-0): Unable to add conservative
default mode "nvidia-auto-select".
[   130.493] (EE) NVIDIA(GPU-0): Unable to add
"nvidia-auto-select" mode to ModePool.
[   130.493] (==) NVIDIA(0):
[   130.493] (==) NVIDIA(0): No modes were requested; the default
mode "nvidia-auto-select"
[   130.493] (==) NVIDIA(0): will be used as the requested mode.
[   130.493] (==) NVIDIA(0):
[   130.493] (WW) NVIDIA(0): No valid modes for
"DFP-0:nvidia-auto-select"; removing.
[   130.493] (WW) NVIDIA(0):
[   130.493] (WW) NVIDIA(0): Unable to validate any modes; falling
back to the default mode
[   130.493] (WW) NVIDIA(0): "nvidia-auto-select".
[   130.493] (WW) NVIDIA(0):
[   130.493] (WW) NVIDIA(0): No valid modes for
"DFP-0:nvidia-auto-select"; removing.
[   130.493] (EE) NVIDIA(0): Unable to use default mode
"nvidia-auto-select".
[   130.493] (EE) NVIDIA(0): Failing initialization of X screen 0


The log shows "0.0 MHz maximum pixel clock" for the DVI connections.
When enabling ModeDebug in the xorg.conf it shows that all of the
resolutions are rejected because of incorrect maximum pixel clock:

[  1354.589] (II) NVIDIA(GPU-0):
[  1354.589] (II) NVIDIA(GPU-0): --- Building ModePool for Philips
240S4 (DFP-0) ---
[  1354.589] (WW) NVIDIA(GPU-0):   Validating Mode "1920x1200_60":
[  1354.589] (WW) NVIDIA(GPU-0): Mode Source: EDID
[  1354.589] (WW) NVIDIA(GPU-0): 1920 x 1200 @ 60 Hz
[  1354.589] (WW) NVIDIA(GPU-0):   Pixel Clock  : 154.00 MHz
[  1354.589] (WW) NVIDIA(GPU-0):   HRes, HSyncStart : 1920, 1968
[  1354.589] (WW) NVIDIA(GPU-0):   HSyncEnd, HTotal : 2000, 2080
[  1354.589] (WW) NVIDIA(GPU-0):   VRes, VSyncStart : 1200, 1203
[  1354.589] (WW) NVIDIA(GPU-0):   VSyncEnd, VTotal : 1209, 1235
[  1354.589] (WW) NVIDIA(GPU-0):   Sync Polarity: +H -V
[  1354.589] (WW) NVIDIA(GPU-0): Mode is rejected: PixelClock
(154.0 MHz) too high for
[  1354.589] (WW) NVIDIA(GPU-0): Display Device (Max: 0.0 MHz).
[  1354.589] (WW) NVIDIA(GPU-0): Mode "1920x1200_60" is invalid.


Note that with the previous driver (version 384.90), a valid value was
detected for the