New Dell T5810 with above card. Put Centos 7 on it (after finding the "use a basic video driver" selection under "Troubleshooting"). Got TDE v.newest installed just fine (after reading all steps in the directions - sad considering I'd done this before ...).
But how do I adjust the video? The stuff in RandR only seems to want to give me 1024x768 which seems ... skimpy ... on a pair of P2416Ds which are 2560x1440 each (I've not connected the 2nd display yet).
What am I missing? Do I need to ditch the Nouveau stuff and go for some sort of proprietary driver? I'm not opposed to either direction, but I really have to have better than 1995's idea of hi-res. :-)
Or is there a tool I'm missing?
-- Peter Laws, BS, MRCP / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology plaws@ou.edu
Peter Laws composed on 2017-07-21 14:29 (UTC-0500):
New Dell T5810 with above card. Put Centos 7 on it (after finding the "use a basic video driver" selection under "Troubleshooting"). Got TDE v.newest installed just fine (after reading all steps in the directions - sad considering I'd done this before ...).
But how do I adjust the video? The stuff in RandR only seems to want to give me 1024x768 which seems ... skimpy ... on a pair of P2416Ds which are 2560x1440 each (I've not connected the 2nd display yet).
What am I missing? Do I need to ditch the Nouveau stuff and go for some sort of proprietary driver? I'm not opposed to either direction, but I really have to have better than 1995's idea of hi-res. :-)
Or is there a tool I'm missing?
Sometimes "troubleshooting" instructions say to include nomodeset on the kernel cmdline. You do not want to do that if you want an acceptable FOSS Xorg driver to function. Nomodeset can work with the proprietary NVidia driver, but it blocks use of modeset and nouveau Xorg drivers.
I couldn't find whatever doc you read that in, but "use a basic video driver" suggests what it says, which in Xorg means either FBDEV or VESA, crude generic drivers, with which highest video mode available is typically 1024x768. Whatever you did to cause use of either of those needs to be undone if that's what did happen. To find out which driver is being used, inspect /var/log/Xorg.0.log for a large number of sequential lines beginning around two screens down from the top of the file. Look for:
fbdev(0) vesa(0) modeset(0) nouveau(0)
With that Quadro, I'm guessing modeset is most likely to be the best of the FOSS bunch. The modeset driver is integral to the Xorg server, so typically the easiest way to have it used is to not have the nouveau driver installed. If neither modeset nor nouveau produce acceptable results, the proprietary NVidia driver is called for.
Share Xorg.0.log via pastebin if the above isn't enough help.
Peter Laws composed on 2017-07-21 14:29 (UTC-0500):
Sometimes "troubleshooting" instructions say to include nomodeset on the kernel cmdline. You do not want to do that if you want an acceptable FOSS Xorg driver to function. Nomodeset can work with the proprietary NVidia driver, but it blocks use of modeset and nouveau Xorg drivers.
The "Troubleshooting" menu item lets you select "basic graphics mode". After a day of futzing, this was the only way to get to the installation screen. Using the regular install selection yielded disk accesses (when I was trying with a DVD) and a black screen.
I couldn't find whatever doc you read that in, but "use a basic video driver"
My assumption was that this would get me through the installation and not set it forever and ever.
happen. To find out which driver is being used, inspect /var/log/Xorg.0.log for a large number of sequential lines beginning around two screens down from the top of the file. Look for:
fbdev(0) vesa(0) modeset(0) nouveau(0)
I've never been good at deciphering Xorg.0.log files, but ...
[ 1638.443] (==) Matched nouveau as autoconfigured driver 0 [ 1638.443] (==) Matched modesetting as autoconfigured driver 1 [ 1638.443] (==) Matched fbdev as autoconfigured driver 2 [ 1638.443] (==) Matched vesa as autoconfigured driver 3
Who do I tell which one is being used and then how do I manipulate it?
Share Xorg.0.log via pastebin if the above isn't enough help.
Oh, good idea. Hang on ...
OK, see if this works: https://pastebin.com/bhnUCYSD
On Fri, 21 Jul 2017 15:46:18 -0500 Peter Laws plaws@ou.edu wrote:
Peter Laws composed on 2017-07-21 14:29 (UTC-0500):
[ 1638.443] (==) Matched nouveau as autoconfigured driver 0 [ 1638.443] (==) Matched modesetting as autoconfigured driver 1 [ 1638.443] (==) Matched fbdev as autoconfigured driver 2 [ 1638.443] (==) Matched vesa as autoconfigured driver 3
Who do I tell which one is being used and then how do I manipulate it?
Share Xorg.0.log via pastebin if the above isn't enough help.
Oh, good idea. Hang on ...
OK, see if this works: https://pastebin.com/bhnUCYSD
You've got lines with "FBDEV(0)" scattered all over the file, so I'd assume that's what it's decided to use.
I would go with the nVidia proprietary driver. Nouveau is something of a crapshoot, since it was reverse-engineered without the manufacturer's support, and your distro may not be shipping the most current version.
E. Liddell
Peter Laws composed on 2017-07-21 15:46 (UTC-0500):
I couldn't find whatever doc you read that in, but "use a basic video driver"
My assumption was that this would get me through the installation and not set it forever and ever.
I would make the same assumption, but that's not what happened to you. :-(
happen. To find out which driver is being used, inspect /var/log/Xorg.0.log for a large number of sequential lines beginning around two screens down from the top of the file. Look for:
fbdev(0) vesa(0) modeset(0) nouveau(0)
I've never been good at deciphering Xorg.0.log files, but ..
You misinterpreted or missed the "large number of sequential lines" part:
[1638.579] (II) FBDEV(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [1638.579] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32 [1638.579] (==) FBDEV(0): RGB weight 888 [1638.579] (==) FBDEV(0): Default visual is TrueColor [1638.579] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) [1638.579] (II) FBDEV(0): hardware: EFI VGA (video memory: 3072kB) [1638.579] (II) FBDEV(0): checking modes against framebuffer device... [1638.579] (II) FBDEV(0): checking modes against monitor... [1638.579] (--) FBDEV(0): Virtual size is 1024x768 (pitch 1024) [1638.579] (**) FBDEV(0): Built-in mode "current": 78.7 MHz, 59.9 kHz...
[ 1638.443] (==) Matched nouveau as autoconfigured driver 0 [ 1638.443] (==) Matched modesetting as autoconfigured driver 1 [ 1638.443] (==) Matched fbdev as autoconfigured driver 2 [ 1638.443] (==) Matched vesa as autoconfigured driver 3
Who do I tell which one is being used and then how do I manipulate it?
FBDEV is being used. Why is the question I can't answer easily because I don't use CentOS. OK, from your pastebin, here's why:
[1638.435] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-514.26.2.el7.x86_64 root=/dev/mapper/cl_ip--10--197--15--52-root ro crashkernel=auto rd.md.uuid=84a77eb4:612c546f:bbfacc72:2944e155 rd.lvm.lv=cl_ip-10-197-15-52/root rd.md.uuid=00e7a463:b7860ba3:0d667429:7d96fa74 rd.lvm.lv=cl_ip-10-197-15-52/swap nomodeset rhgb quiet LANG
Your bootloader needs to have a less limiting selection made, or created, one that at the very least lacks
nomodeset
which blocks use of modeset and nouveau drivers. rhgb and quiet prevent you from seeing possibly helpful messages as init proceeds. They are typically not needed by people who like to know how init is progressing. I'm not familiar with "crashkernel". Likely that's only for a rescue stanza, not normally needed.
Share Xorg.0.log via pastebin if the above isn't enough help.
Oh, good idea. Hang on ...
OK, see if this works: https://pastebin.com/bhnUCYSD--
"The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
On Fri, Jul 21, 2017 at 4:22 PM, Felix Miata mrmazda@earthlink.net wrote:
Your bootloader needs to have a less limiting selection made, or created, one that at the very least lacks
nomodesetwhich blocks use of modeset and nouveau drivers. rhgb and quiet prevent you from seeing possibly helpful messages as init proceeds. They are typically not needed by people who like to know how init is progressing. I'm not familiar with "crashkernel". Likely that's only for a rescue stanza, not normally needed.
(Damn gmail used to have Quote Selected Text and they pulled it a couple weeks ago so now I have to do it manually - grumble. Not paying my Google bill this month)
Pulling nomodeset gets me lots of stuff that looks exciting in Xorg.0.log but leaves me with a black display after spitting out the now-displayed boot messages (which go by far too quickly to read - maybe I'll video with my phone).
Assuming that nomodeset really is what I want and that now I need to get the card configured for some mode I can see, how would I do that?
I'm also seeing that tdm.log has unhappiness in it, namely:
(==) Using system config directory "/usr/share/X11/xorg.conf.d" nvc0_screen_create:762 - Error allocating PGRAPH context for M2MF: -16 EGL_MESA_drm_image required. Jul 21 16:53:18 tdm[1812] error: X server startup timeout, terminating (II) Server terminated successfully (0). Closing log file. Jul 21 16:54:13 tdm[1812] error: X server for display :0 can't be started, session disabled
The line with the PGRAPH thing turned up a bug against Puppy linux at https://bugs.launchpad.net/linuxmint/+bug/1675811 that seems similar ... ick.
I really regret dumping the Ubuntu 14.04LTS image that was pre-installed on this system because while not configured for TDE, it was driving the card/display correctly. :-)
This sequence worked:
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh http://www.elrepo.org/elrepo-release-7. ... noarch.rpm yum install nvidia-detect.x86_64 yum install kmod-nvidia reboot
2560x1440 is nice. Now to hook up the other display.
Gentlemen (and ladies), thanks as always!!
Peter
-- Peter Laws, BS, MRCP / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology plaws@ou.edu
Peter Laws composed on 2017-07-21 17:06 (UTC-0500):
Pulling nomodeset gets me lots of stuff that looks exciting in Xorg.0.log but leaves me with a black display after spitting out the now-displayed boot messages (which go by far too quickly to read - maybe I'll video with my phone).
Assuming that nomodeset really is what I want and that now I need to get the card configured for some mode I can see, how would I do that?
Assuming you are still stuck using the FBDEV driver, that can't happen. I really don't think you have a TDE problem. The (EE) lines in Xorg.0.log seem to say you have a CentOS/Xorg problem to solve. Once Xorg.0.log shows you are using NVIDIA(0), NOUVEAU(0) or MODESET(0), TDM/TDE should start working as expected.
Your kernel in CentOS is actually older than 3.13 in 14.04LTS. Could it be that the older CentOS 3.10 kernel and/or the CentOS nouveau and/or modeset drivers do not support your M2000, maybe unless you install the proprietary NVidia driver? Release announcement date for the M2000 isn't very different from kernel 3.11 release.
I'm also seeing that tdm.log has unhappiness in it, namely:
(==) Using system config directory "/usr/share/X11/xorg.conf.d" nvc0_screen_create:762 - Error allocating PGRAPH context for M2MF: -16 EGL_MESA_drm_image required....
Is Mesa even installed?.
I really regret dumping the Ubuntu 14.04LTS image that was pre-installed on this system because while not configured for TDE, it was driving the card/display correctly. :-)
You need nomodeset gone from the default bootloader stanza for either the nouveau or the modeset driver to work. To do that, assuming your installed bootloader is grub2, that string needs to be removed from the GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub, after which /boot/grub/grub.cfg needs to be regenerated using grub-mkconfig.
However, that may need to wait until it can be determined why you get a black screen when it is not used. When you reach the black screen after booting, can you reach any of the vttys using Ctrl-Alt-Fn? If yes, then it can be removed now.
If your 14.04 was using the proprietary NVidia driver, then it's probably what you want with CentOS too.
If you pastebin dmesg output and/or 'journalctl -b' output maybe someone can spot the obstacle.
-
E. Liddell -
Felix Miata -
Peter Laws