Discuss January 2018

discuss@lists.centos.org

89 participants
70 discussions

CentOS 7 autofs flakyness
by m.roth＠5-cent.us 11 Jan '18

11 Jan '18

I have a user who couldn't get in via WinSCP to a server. Got him to log in via putty, and that was fine. But he still couldn't get in the other way. At my manager's suggestion, I restarted autofs... and everything worked. Note that his home director5y was already automounted via NFS, after he logged in via putty. We've seen other, similar oddities with NFS. Is anyone else seeing this, or have a clue? Btw, there were no errors showing in /var/log/messages, journal, I saw this in dmesg: task mount.nfs:83892 blocked for more than 120 seconds, but that was from four days ago, and my user just reported the problem yesterday, though he hadn't tried to use WinSCP in about a month. mark

2 1

1600x900 not available
by Sean Smith 11 Jan '18

11 Jan '18

My laptop is a Dell XPS-13 running CentOS 7. It has a 13" 1920x1080 screen and it's a bit difficult for my mid-40s eyesight. Fedora and Debian, on this laptop, give me the option of choosing 1600x900 which is much easier for me to read but CentOS doesn't show this resolution as available. I followed the steps I found in a post on stackexchange using xrandr, substituting 1600x900 where applicable and it worked but, once I rebooted, it went back to 1920x1080 with no 1600x900 option in settings-display. Is there a way I can add 1600x900 resolution the list of available resolutions in settings-display? Thanks, Sean

5 10

soft lockup after set multicast_router of bridge and it's port to 2
by wuzhouhui 10 Jan '18

10 Jan '18

OS: CentOS 6.5. After I set multicast_router of bridge and it's port to 2, like following: echo 2 > /sys/devices/virtual/net/eth81/bridge/multicast_router echo 2 > /sys/devices/virtual/net/bond2/brport/multicast_router Then soft lockup occured: Message from syslogd@node-0 at Jan 9 15:47:12 ... kernel:BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] And the call trace is RIP: 0010:[<ffffffffa04f3608>] [<ffffffffa04f3608>] br_multicast_flood+0x88/0x140 [bridge] RSP: 0018:ffff88013bc038f0 EFLAGS: 00000246 RAX: ffff88404f816020 RBX: ffff88013bc03940 RCX: ffff88204e40a640 RDX: ffff882002b9ce01 RSI: ffff882002b9ce80 RDI: 0000000000000000 RBP: ffffffff8100bb93 R08: 0000000000000001 R09: 00000000ff09f4a1 R10: ffff88202c884070 R11: 0000000000000000 R12: ffff88013bc03870 R13: ffff882002b9ce80 R14: ffff88013bc03860 R15: ffffffff8151b225 FS: 0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007fa11a942000 CR3: 0000000001a85000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a8d020) Stack: 880be7e100028813 ffff882002b9ce80 ffff882002b9ce80 ffffffffa04f3930 <d> 00000000880be7e1 ffff882002b9ce80 ffff882002b9ce80 ffff88200286c042 <d> ffff88202ae7c6e0 ffff882002b9ceb8 ffff88013bc03950 ffffffffa04f36d5 Call Trace: <IRQ> [<ffffffffa04f3930>] ? __br_forward+0x0/0xd0 [bridge] [<ffffffffa04f36d5>] ? br_multicast_forward+0x15/0x20 [bridge] [<ffffffffa04f4a34>] ? br_handle_frame_finish+0x144/0x2a0 [bridge] [<ffffffffa04fa938>] ? br_nf_pre_routing_finish+0x238/0x350 [bridge] [<ffffffffa04faedb>] ? br_nf_pre_routing+0x48b/0x7b0 [bridge] [<ffffffff8143ba57>] ? __kfree_skb+0x47/0xa0 [<ffffffff814734f9>] ? nf_iterate+0x69/0xb0 [<ffffffffa04f48f0>] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [<ffffffff814736b6>] ? nf_hook_slow+0x76/0x120 [<ffffffffa04f48f0>] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [<ffffffffa04f4d1c>] ? br_handle_frame+0x18c/0x250 [bridge] [<ffffffff81445709>] ? __netif_receive_skb+0x529/0x750 [<ffffffff814397da>] ? __alloc_skb+0x7a/0x180 [<ffffffff814492f8>] ? netif_receive_skb+0x58/0x60 [<ffffffff81449400>] ? napi_skb_finish+0x50/0x70 [<ffffffff8144ab79>] ? napi_gro_receive+0x39/0x50 [<ffffffffa016887f>] ? bnx2x_rx_int+0x83f/0x1630 [bnx2x] [<ffffffff810608dc>] ? perf_event_task_sched_out+0x4c/0x70 [<ffffffffa01698ae>] ? bnx2x_poll+0x23e/0x2f0 [bnx2x] [<ffffffff8144ac93>] ? net_rx_action+0x103/0x2f0 [<ffffffff8107a811>] ? __do_softirq+0xc1/0x1e0 [<ffffffff810e6b30>] ? handle_IRQ_event+0x60/0x170 [<ffffffff8100c30c>] ? call_softirq+0x1c/0x30 [<ffffffff8100fa75>] ? do_softirq+0x65/0xa0 [<ffffffff8107a6c5>] ? irq_exit+0x85/0x90 [<ffffffff8151b165>] ? do_IRQ+0x75/0xf0 [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 <EOI> [<ffffffff81016627>] ? mwait_idle+0x77/0xd0 [<ffffffff815176fa>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 [<ffffffff814f6e3a>] ? rest_init+0x7a/0x80 [<ffffffff81c25f70>] ? start_kernel+0x405/0x411 [<ffffffff81c2533a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81c25453>] ? x86_64_start_kernel+0x115/0x124 Does anyone know the reason?

1 1

Re: [CentOS] Nvidia maximum pixel clock issue in, , kmod-nvidia-384.98
by Alexander Wiedergold 10 Jan '18

10 Jan '18

To: CentOS mailing list <centos(a)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-request(a)centos.org: > Send CentOS mailing list submissions to > centos(a)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-request(a)centos.org > > You can reach the person managing the list at > centos-owner(a)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 <johnny(a)centos.org> > To: centos(a)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-5c00f6b3bfd5(a)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 <davidg(a)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 > > >

1 0

Audio Output Timer Utility
by Chris Olson 09 Jan '18

09 Jan '18

We have several CentOS 6.x systems that are incorporated into suites of special test equipment. One of the requirements for these systems is that they be kept up to date and they are kept up to date using yum once per week or more frequently, as needed. All of our CentOS 6.x systems have at least 2TB system disks and were installed with essentially everything that was available on the DVD at the time of initial setup. One of our programs is currently in Beta Test which includes both command line and GUI operator inputs and responses. The functional testing requires operator inputs or responses within certain time frames. This timing has usually been implemented with a stopwatch that is operated by a test director. Other timing options would beneficial for complex testing scenarios One of our test directors suggested that we use a digital count- down timer with audio outputs to prompt test operators for their inputs or responses at appropriate times. We have not found such a utility on our CentOS 6 distribution. If there is one available, we would appreciate any information that can be provided. Thanks.

2 2

FreeIPA - client/replica errors
by lejeczek 09 Jan '18

09 Jan '18

hi, free IPA everyone? I wanted to ask if you maybe seen below errors. I'm trying regular: $ ipa-client-install --principal=admin --password="ccnR.Biotec13#diradm" --enable-dns-updates and it fails: ... Valid From: 2018-01-09 16:51:35 Valid Until: 2038-01-09 16:51:35 Enrolled in IPA realm PRIVATE.CCNR.CEB.PRIVATE.CAM.AC.UK Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Failed to obtain host TGT: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638936): Preauthentication failed Installation failed. Rolling back changes. Unconfigured automount client failed: Command 'ipa-client-automount --uninstall --debug' returned non-zero exit status 1 Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted Client uninstall complete. The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information It's not time sync problem, server & client candidate are in sync. Simple install, server installed okey but client fails as above. Does your IPA VERSION: 4.5.0, API_VERSION: 2.228 install okey, with no problems? many thanks, L.

1 0

CentOS-announce Digest, Vol 155, Issue 2
by centos-announce-request＠centos.org 09 Jan '18

09 Jan '18

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2018:0061 Important CentOS 6 thunderbird Security Update (Johnny Hughes) 2. CESA-2018:0061 Important CentOS 7 thunderbird Security Update (Johnny Hughes) 3. CEBA-2018:0042 CentOS 7 dracut BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Jan 2018 16:07:45 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2018:0061 Important CentOS 6 thunderbird Security Update Message-ID: <20180108160745.GA32803(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2018:0061 Important Upstream details at : https://access.redhat.com/errata/RHSA-2018:0061 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: e6695d9d57c40de231c342187c2a90e7857e2b03127cc36ebf2196a9ae2ee05a thunderbird-52.5.2-1.el6.centos.i686.rpm x86_64: a8c1d4fb627a99bfc5bb43318628979992594546ba7d3836d34cf65ad921002f thunderbird-52.5.2-1.el6.centos.x86_64.rpm Source: 99ce9c2112832a7cc18198d9e405dad9f3d53d94928b592c2ab100da3ae64df3 thunderbird-52.5.2-1.el6.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Mon, 8 Jan 2018 16:19:25 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2018:0061 Important CentOS 7 thunderbird Security Update Message-ID: <20180108161925.GA40072(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2018:0061 Important Upstream details at : https://access.redhat.com/errata/RHSA-2018:0061 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 9c5cb918ab52c65f08316d00b8bda0818037c4dd317c8e9c1caf36c121345a14 thunderbird-52.5.2-1.el7.centos.x86_64.rpm Source: fcffd379f539a936adf9c5f141a506445b3623854f82d8b51ec250e167bca898 thunderbird-52.5.2-1.el7.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Mon, 8 Jan 2018 16:20:53 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2018:0042 CentOS 7 dracut BugFix Update Message-ID: <20180108162053.GA40202(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2018:0042 Upstream details at : https://access.redhat.com/errata/RHBA-2018:0042 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: c6017d90619a761a97b6e48d8f82bf961b8b580bc1ae53beef03355aada3e4da dracut-033-502.el7_4.1.x86_64.rpm c488f669a93c3fb7c329a9223fe4315321d73cd3e424ab0902b77c4069aacfcd dracut-caps-033-502.el7_4.1.x86_64.rpm ae13cf4499925fcac5fe6c45ac507b9ff53bf33870bc1de395800e570555a75f dracut-config-generic-033-502.el7_4.1.x86_64.rpm e38520716f7d774300f3e71e9ad2f3e58abe9302590fcd4016a2a0ebb702b09e dracut-config-rescue-033-502.el7_4.1.x86_64.rpm 3415bec446875991ce2aaddcb01aa5b145dff30c6f153d0d151e7227e292bc04 dracut-fips-033-502.el7_4.1.x86_64.rpm bb8bb68b3a7031e084a7107c0b137649c1590b6bee3c93e446e93f44322cd69d dracut-fips-aesni-033-502.el7_4.1.x86_64.rpm 05da89cae2a294c13794d43f97e9a7642452ce4b92d92b1b9de5f67a4a8dd844 dracut-network-033-502.el7_4.1.x86_64.rpm 568dac68a18f0a6af37485eb04c77da6a12692f22ad42a19cc12ae4f3e69ad97 dracut-tools-033-502.el7_4.1.x86_64.rpm Source: c49fb5836bb119608a6ec9bf43fc344421810eb95bcfea6a8d7719ea74a59c0b dracut-033-502.el7_4.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 155, Issue 2 ***********************************************

1 0

Cent OS 7.3 Shared library issue
by Aman Sharma 09 Jan '18

09 Jan '18

Hi Guys, I am using my native library to run but during runtime, its picking the default library i.e. /usr/lib/libssl. Due to this, my application crashes. But after adding the Soft link for my native library, its working fine. Can anybody Please let me know why its not working without adding softlink in cent os 7.3. -- Thanks Aman Cell: +91 9990296404 | Email ID : amansh.sharma5(a)gmail.com

1 0

C6 KPTI cpuinfo flag?
by Robert Arkiletian 09 Jan '18

09 Jan '18

Noticed C6 had a kernel update on Friday. 2.6.32-696.18.7.el6.x86_64 What is the flag in /proc/cpuinfo that indicates the KPTI patch for Meltdown CVE-2017-5754 for C6? Some distros are using "kaiser" some like Fedora are using "pti". Also noticed some (like Fedora) are displaying "cpu_insecure" under the bugs: heading of cpuinfo.

2 1

Nvidia maximum pixel clock issue in kmod-nvidia-384.98
by Danny Smit 08 Jan '18

08 Jan '18

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 'maximum pixel clock': [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): connected [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): Internal TMDS [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): 165.0 MHz maximum pixel clock Since it did work with version 384.90 and stopped working with version 384.98, it looks like a regression in the nvidia driver. What is the best way to report the issue and get an update in elrepo? Kind regards, Danny Smit

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss January 2018