CentOS - Jan 2018 - Nvidia maximum pixel clock issue in kmod-nvidia-384.98

On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry <pperry at elrepo.org>
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?

On 04/01/18 09:12, Danny Smit wrote:
> On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry <pperry at elrepo.org>
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).

On Thu, Jan 4, 2018 at 9:40 PM, Phil Perry <pperry at elrepo.org>
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?