I am seeking technical advice to help resolve a problem with a desktop system that has become unstable, crashing with what may be a graphical display error (the system becomes unresponsive with either a blank screen or static display of current desktop). This is temporarily resolved with a hard reset.
The main system specifications are: Opensuse Leap 15; KDE 5; Graphics card: NVIDIA GeForce GTX 560 (Gigabyte GF114); Monitor: Samsung S24E650 - Native resolution: 1920x1200 Pixels (524x321 mm), 93x95 dpi; and NVIDIA driver set 390.87, i.e: nvidia-computeG04 390.87-lp150.10.2; nvidia-gfxG04-kmp-default 390.87_k4.12.14_lp150.11-lp150.10.1; nvidia-glG04 390.87-lp150.10.2; and, x11-video-nvidiaG04 390.87-lp150.10.2.
Suspecting that the NVIDIA drivers may be the cause I used yast2 to uninstall them, but this was not helpful since the only display resolution then available with the nouveau nvidia driver was, as I recall, 1600 x 900. The NVIDIA driver set was reinstalled and again provided screen resolution of 1920x1200, but the system remains prone to random freezes.
Further investigation suggest that the problem may relate to a monitor hardware detection or reporting error.
With the NVIDIA drivers UNinstalled # hwinfo --monitor yielded nul output and $ xrandr reported default 1600 x 900 only. (I regret that the brief output was not recorded.)
With the NVIDIA drivers installed # hwinfo --monitor still yielded nul output but $ xrandr reported, inter alia, DVI-I-2 connected primary 1920x1200+0+0 [snip] 518mm x 324mm.
Checking hwinfo in yast2 confirms that there is no ‘monitor’ entry in the yast2 hardware list.
When I fire up an openSUSE Tumbleweed OS installed on the same system (running the nouveau driver with 1920x1200 screen resolution) both # hwinfo --monitor and the yast2 hardware list show ‘monitor’ details in full.
Can anyone advise what may cause such a monitor hardware detection or reporting error and how I might identify and resolve it?
Thanks, always worth checking. It is very hot (40C+) everywhere in Australia today but GPU internal temp is normal (36-38C).
Thanks. Good question, but in relation to the universal DDX driver the linked article says it is for … “NVIDIA G80 (GeForce 8) GPUs and newer”. GPU is an older NVIDIA GeForce GTX 560 marketed by Gigabyte as GF114. The xf86-video-nouveau driver works fine with Tumbleweed OS installed on the same machine. Driver issues may be a factor but don’t seem to explain the corrupted hardware list.
Our NVidia “model numbers” are out of sync. My G84 is a 2007 vintage product according to Wikipedia, where your GF114 shows up as a 2011 product. GeForce 8/G80 as referred to in the Phoronix article is 2006 product according to Wikipedia.
My GT218 (GeForce 210), from 2010, closer in age to yours, also works with modesetting:
# inxi -GxxS
System: Host: p5bse Kernel: 4.12.14-lp150.12.28-default x86_64 bits: 64 compiler: gcc v: 7.3.1
Desktop: KDE 3.5.10 tk: Qt 3.3.8c wm: kwin dm: startx Distro: openSUSE Leap 15.0
Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau v: kernel bus ID: 01:00.0
chip ID: 10de:0a65
Display: server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
resolution: 1920x1440~60Hz, 1920x1080~60Hz
OpenGL: renderer: llvmpipe (LLVM 5.0 128 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0 direct render: Yes
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 2520, maximum 8192 x 8192
DVI-I-1 connected primary 1920x1440+0+1080 (normal left inverted right x axis y axis) 598mm x 336mm
2560x1440 59.95 +
1920x1440 60.00* ...
HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 673mm x 284mm
1920x1080 59.96* 60.00 60.00 50.00 59.94 59.93 24.00 23.98
1920x1080i 60.00 50.00 59.94...
VGA-1 disconnected (normal left inverted right x axis y axis)
AMD and NVidia names, model numbers and series are a vexing mess. This is a reason for asking for inxi -Gxx, which provides PCI ID numbers to help with identification.
Thanks. This is a ‘daily work’ machine, so I am loath to uninstall both NVIDIA and xf86-video-nouveau drivers, as (I think …) you suggested above, without a better understanding of the fall back position and risks, and a better understanding of the ‘monitor detection error’ issue. This is the output from inxi -Gxx
$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1600 x 1200, current 1600 x 1200, maximum 1600 x 1200
default connected primary 1600x1200+0+0 0mm x 0mm
1600x1200 77.00*
$ inxi -Gxx
Graphics: Card: NVIDIA GF114 [GeForce GTX 560]
bus-ID: 01:00.0 chip-ID: 10de:1201
Display Server: x11 (X.Org 1.19.6 )
drivers: fbdev (unloaded: modesetting,vesa)
Resolution: 1600x1200@77.00hz
OpenGL: renderer: llvmpipe (LLVM 5.0, 256 bits)
version: 3.3 Mesa 18.0.2 (compat-v: 3.0) Direct Render: Yes
# hwinfo --monitor
nul
So, this corrects the mistaken resolution report in my previous post, but 1600x1200 still unsatisfactory. Some graphical stuttering with fbdev driver, less evident with xf86-video-nouveau. Still no clue why there is no ‘monitor’ section in the hardware list.
What you seem to be calling the “fallback” position is the preferred (default) position. The driver writers over 4 years ago figured out a better technology for writing drivers (one that is not gfxchip-specific). Around 3 years ago they decided it was ready to make the default, at which time it was merged into the server (server 1.17.0), which I suppose was to ensure its availability always, unlike all other DDX drivers. The risks of using this default driver compared to xf86-video-nouveau as I see them are:
1-your problems with the non-default drivers go away.
2-you won’t like it as well and subsequently want xf86-video-nouveau reinstalled, no more work than uninstalling it, and less work than adding or removing proprietary drivers.
3-one or both of the problems you presented here remain.
4-some new problem surfaces.
5-/etc/X11/xorg.conf.d/50-monitor.conf needs a tweak to get your Samsung’s 1920x1200 properly utilized with a FOSS DDX driver.
Does your GF114 have a (working) fan?
I can’t imagine it taking more than a few minutes to determine whether it’s better or not - once you’ve ***finished eradicating ***the proprietary driver’s disruption of 15.0 as released by upstream and openSUSE (which includes eliminating /etc/X11/xorg.conf, which X automagic for FOSS usually precludes need for), and which requires working KMS. You probably have nomodeset or equivalent on your kernel cmdline as residue from proprietary driver installation, which disables KMS, and would account for 1600x1200 and FBDEV driver instead of modesetting and 1920x1200.
Here’s another NVidia older than yours auto-detecting 1920x1200 with the default modesetting DDX driver:
# inxi -GxxS
System: Host: g5eas Kernel: 4.12.14-lp150.12.28-default x86_64 bits: 64 compiler: gcc v: 7.3.1 Desktop: Trinity R14.0.5
tk: Qt 3.5.0 wm: Twin dm: startx Distro: openSUSE Leap 15.0
Graphics: Device-1: XGI Z7/Z9 vendor: Gigabyte driver: xgifb v: kernel bus ID: 0a:03.0 chip ID: 18ca:0020
Device-2: NVIDIA G98 [GeForce 8400 GS Rev. 2] driver: nouveau v: kernel bus ID: 0b:00.0 chip ID: 10de:06e4
Display: server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
resolution: 1920x1200~60Hz
OpenGL: renderer: llvmpipe (LLVM 5.0 128 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0 direct render: Yes
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
DVI-I-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
1920x1200 59.95*+
1920x1080 59.96 59.93...
VGA-1 disconnected (normal left inverted right x axis y axis)
Likely that’s another consequence of falling back to the crude fbdev driver. All residue from proprietary drivers must be eliminated for the competent FOSS DDX drivers to work as expected.
Thanks for assisting me with technical advice. Your work on this forum is appreciated.
I was not aware of the development work you describe. As must be obvious, I am unfamiliar with details and terminology around graphics processing, but have been reading. I have attempted eradicating the proprietary driver’s disruption without success. I am not sure which of the drivers are ‘proprietary’ - is this just the NVIDIA driver set or must nouveau and fbdev also be uninstalled?
Could you please outline the steps required to achieve the eradication of the proprietary driver’s disruption and then load the default driver. I cannot see this process described elsewhere, so this advice may also be useful to others.
Could you also discuss the tweeks required in /etc/X11/xorg.conf.d/50-monitor.conf (currently blank) to allow the default graphics driver to utilise 1920x1200 on the Samsung S24E650 monitor? Running hwinfo from Tumbleweed OS on the same machine provided this data, some of which may be useful:
In response to the other issues you raised: the GF114 does have a working fan (temperature=normal); there is no nomodeset or equivalent on the kernel cmdline; and, there is no /etc/X11/xorg.conf file (/etc/X11/xorg.conf.install exists).
“Proprietary” are just those created and provided by NVidia itself (or AMD, for AMD & ATI hardware), such as the four 390.87 packages in the second paragraph of your OP here.
or must nouveau and fbdev also be uninstalled?
These are FOSS drivers provided on your openSUSE installation media. Fbdev is good to keep as a fallback. Nouveau removal makes use of the FOSS DDX driver “modesetting” easier to employ. Proprietary drivers for legal reasons are not provided on any installation media or repos provided by the openSUSE project itself. Note that the capabilities of nouveau and fbdev are very different. For most people, fbdev is too basic and incapable for any respectable GUI performance. It should be regarded as temporary/rescue use only. The nouveau DDX driver capabilities fulfill the major part of what proprietary drivers provide, resulting in acceptable performance for many, maybe most, GUI users. The nouveau DDX driver is the default driver provided by an openSUSE installation media default installation for NVidia hardware. To emply the newer technology DDX driver, modesetting, in openSUSE, requires special action to be taken on the part of the openSUSE user, any of: 1-removal of xf86-video-nouveau if already installed; 2-blocking installation of xf86-video-nouveau if not already installed; 3-use of one or more config files to override normal automagic X configuration
Could you please outline the steps required to achieve the eradication of the proprietary driver’s disruption and then load the default driver. I cannot see this process described elsewhere, so this advice may also be useful to others.
Doing so in any detail is more burdensome than I choose to do. I don’t download or install proprietary software, particularly that from NVidia, so I don’t have the required information to do so. What I do know is NVidia provides instructions for removal with the drivers they provide. When those instructions are not precisely followed, proper function of FOSS software may be impeded or prevented. One thing I’ve seen reported that one should be able to discover through web search is that the NVidia driver installation process makes some sort of file substitution somewhere in /lib/ that cannot be left in place and expect nouveau or modesetting drivers to function correctly, if at all. AIUI NVidia installation incorporates module blacklisting and changes in initrds as well, so that the uninstallation process necessarily involves rebuilding initrd appropriately for each kernel required to be used with the competent FOSS drivers, and removing any blacklisting.
Could you also discuss the tweeks required in /etc/X11/xorg.conf.d/50-monitor.conf (currently blank) to allow the default graphics driver to utilise 1920x1200 on the Samsung S24E650 monitor?
If and when determination is made they are necessary is soon enough. If you are curious to see examples of xorg.conf* files that have worked with various hardware you may peruse these small portions of my own web site: http://fm.no-ip.com/Share/Linux/ and http://fm.no-ip.com/Tmp/Linux/Xorg/Cfg/OK/ .
Thank you. That is very helpful. I see I have more reading to do. Meanwhile I have one question. On the openSUSE Leap 15 system NVIDIA drivers have only ever been installed and uninstalled using yast2. I notice that the yast2 uninstallation process is quite lengthy and does seem to involve rebuilding initrd. Is it possible that this process is sufficient to revert the changes made when NVIDIA was installed?
I don’t know. I expect the answer is yes if done after little time has passed since the proprietary driver installation was performed, and no affected packages have since been updated. Whether it can succeed after a long period of time and/or many updates I won’t hazard a guess.
Thanks, mrmazda. I am grateful for your kind technical advice.
My openSUSE Leap 15 system has been running for over 12 months with regular updates and with NVIDIA drivers installed. It has been very stable until a few weeks ago. When I tried to investigate the issue I found that the hardware list ‘monitor’ section was no longer available. I then uninstalled the NVIDIA drivers and allowed the nouveau driver to load. However, while the operating system was then stable, the monitor section remained unavailable and the graphics system only allowed default resolution (1600x1200). Hence my original post.
The task of tracing and checking all possible sources of the proprietary driver’s disruption and then safely eliminating them seems both technically difficult and fraught with uncertainty, given my limited technical knowledge. I have already tried to rollback the system to the earliest available configuration with snapper, but to no avail. Preparation for a clean reinstall now seems to be the most practical option, in my case.
I understand that the loss of the hardware list ‘monitor’ section may not be related to these issues, but the question remains. I would be grateful if another user currently running openSUSE Leap 15 with NVIDIA graphics hardware and with current NVIDIA drivers loaded could check and confirm that the hardware list ‘monitor’ section is still available on their system, either in yast2 or # hwinfo --monitor output.
Thanks to all who have taken time to read this thread.
The task of tracing and checking all possible sources of the proprietary driver’s disruption and then safely eliminating them seems both technically difficult and fraught with uncertainty, given my limited technical knowledge.
The Using Nvidia drivers on openSUSE Tumbleweed section on https://news.opensuse.org/tag/nouveau/ and comments like that at https://forums.opensuse.org/showthread.php/531914-nvidia-driver-install-with-black-screen-kde?p=2871737#post2871737 suggest that the main disruption is Mesa binaries substitution. It would follow that an NVidia driver uninstallation that appears to be incomplete might be solved, in addition to unblacklisting nouveau and rebuilding initrds, by reinstalling all Mesa packages, somewhere in the vicinity of 10 packages, whose currently installed versions can be discovered thus:
I am referring to the ‘monitor’ section of the hardware list generated by selecting Hardware Information in yast or yast2, or by executing # ‘hwinfo --monitor’ in a terminal. Using the openSUSE Leap 15 system the ‘monitor’ section is omitted from the generated list in yast2 and when # ‘hwinfo --monitor’ is run in a terminal a line or two of text flashes by (unreadable) but no report is generated. I tried to pipe the output to a text file but it was blank. Using openSUSE Tumbleweed on the same machine, yast2 > Hardware Information includes a detailed ‘monitor’ section, and # hwinfo --monitor generates a similar detailed report.
Seems you have lost the handshaking with the monitor that identifies the it. You can set any needed resolution in the /etc/X11/xorg.conf.d files by entering modeline setting.
Possible reason for the lose of EDID is bad or lose cable or hardware failure on monitor
Thanks for responding, gogalthorp.
I agree, but cable (DVI) seems OK and monitor is OK. This error does not occur with 2 other linux OS installed on same machine (Tumbleweed and KDE-Neon). They both have only ever had nouveau driver loaded. Only the openSUSE Leap 15 OS has ever had NVIDIA driver set loaded but loading nouveau driver there does not resolve the issue, so perhaps the corrupted EDID has been written somewhere, preventing #hwinfo --monitor from reporting anything. Can you cast any light on this?
I have tried editing the /etc/X11/xorg.conf.d files to specify monitor settings but the default resolution (1600x1200) was still used. It is a decade since I did any ‘xorg.conf’ screens editing and I presume I am making syntax errors. Google generates lots of guides and solutions, mostly undated. As mrmazda explained above there seems to have been big changes in linux graphics systems (DM, Xserver, etc.) so it is hard for me to be sure what is relevant. https://en.opensuse.org/SDB:Configuring_graphics_cards does not discuss monitor settings. https://en.opensuse.org/SDB:Configuring_graphics_cards_and_monitor_settings is dated 2012 and I was not able to find cvt. Thanks for the link. So, seems the modeline should probably look like:
May I ask that you point me to a syntax guide for /etc/X11/xorg.conf.d files that is relevant for monitor settings in openSUSE Leap 15 - KDE? Which file name and ranking, content, etc.?
Update. This is either weird or kudos to the miracle self healing openSUSE Leap 15 OS.
When I fired up the openSUSE Leap 15 OS today with nouveau driver loaded, low and behold, correct monitor spec is recognised and full resolution is restored. System was a bit slow initially but this settled down after a few minutes. I carried out a full system shutdown and rebooted. The monitor was still there with no slow down this time.
I did nothing but fruitless fretting. My reports in this thread have been as careful and correct as I could make them. But term does not lie:
# inxi -GxxS
System: Host: [snip] Kernel: 4.12.14-lp150.12.45-default x86_64 bits: 64 gcc: 7.3.1
Console: tty 0 dm: sddm,sddm Distro: openSUSE Leap 15.0
Graphics: Card: NVIDIA GF114 [GeForce GTX 560] bus-ID: 01:00.0 chip-ID: 10de:1201
Display Server: X.Org 1.19.6 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
Resolution: 1920x1200@59.95hz
OpenGL: renderer: NVCE version: 4.3 Mesa 18.0.2 (compat-v: 3.0) Direct Render: Yes
# hwinfo --monitor
26: None 00.0: 10002 LCD Monitor
[Created at monitor.125]
Unique ID: rdCR.Pc8557+ZGR7
Parent ID: VCu0.9G1UsKVuMw1
Hardware Class: monitor
Model: "SAMSUNG S24E650"
Vendor: SAM "SAMSUNG"
Device: eisa 0x0cc2 "S24E650"
Serial ID: "HTHG800826"
Resolution: 640x480@60Hz
Resolution: 800x600@56Hz
Resolution: 800x600@60Hz
Resolution: 1024x768@60Hz
Resolution: 1280x720@60Hz
Resolution: 1280x1024@60Hz
Resolution: 1920x1200@60Hz
Size: 518x324 mm
Year of Manufacture: 2015
Week of Manufacture: 34
Detailed Timings #0:
Resolution: 1920x1200
Horizontal: 1920 1968 2000 2080 (+48 +80 +160) -hsync
Vertical: 1200 1203 1209 1235 (+3 +9 +35) +vsync
Frequencies: 154.00 MHz, 74.04 kHz, 59.95 Hz
Driver Info #0:
Max. Resolution: 1920x1200
Vert. Sync Range: 56-60 Hz
Hor. Sync Range: 30-81 kHz
Bandwidth: 154 MHz
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #24 (VGA compatible controller)
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
DVI-I-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 59.95*+
1920x1080 60.00 50.00
1680x1050 59.88
1600x900 60.00
1280x1024 60.02
1440x900 59.90
1280x800 59.91
1280x720 60.00 50.00 59.94
1024x768 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 60.00 59.94
DVI-I-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
#
Go figure? Toes and fingers crossed. And thanks, mrmazda and gogalthorp.
What you would put there would be specific to neither 15.0 nor KDE. It’s from upstream, same as any other distro for a given Xorg version, and is well enough described in the URL gogalthorp provided in comment #17. Note that URL was originally created over a decade ago, and leaves out discussion of a very significant Xorg capability, which implies absence of any other solution for bad or missing EDID.
Any modeline generated by a web page or GTF command or CVT command will differ little or none compared to one Xorg will generate all by itself given enough of a display’s specifications normally provided by EDID. You were provided that information by hwinfo --monitor. So, here’s that equivalent configuation, to put in /etc/X11/xorg.conf.d/50-monitor.conf:
A validly created modeline would be a valid insertion if you wish to go to that trouble. I’ve encountered lots of bad/missing EDID situations, but have never found necessary addition of a modeline in Xorg. I have experienced that need only in its predecessor, XFree86. Xorg knows how to do the math GTF and CVT use.
It’s very nice to see Xorg automagic is now doing its job properly for you.
