Making progress (fewer video issues)but still video problems.
On 2022-02-17 23:41, mark neidorff wrote:
Hello again,
I wish to apologize for starting to receive your help back in November, and then disappearing for months. The reason for disappearing was medical issues (not COVID or COVID related) which I will just have to deal with.
Moving forward, I found that there are problems with the NVidia drivers and for me, trying more with the NVidia card is not worth it. Fortunately, there is an Intel video chip i915 on the motherboard, so I decided to use that instead of the NVidia card. I removed the NVidia video drivers and the nouveau drivers through yast. But, I still have problems.
Symptoms: Cold boot screens: 1. Grub screen--looks and works fine 2. Next screen says "Loading" and works fine. 3. Third screen is the expected grey color. 3 visual green progress bars scroll across the center of the screen---*BUT!!!! PROBLEM???* 3 visual green "artifact" bars appear at the top left side of the screen after a couple of seconds. (this is my first indication that all is not right) 4. Then the login screen appears, and I can login.
My graphical desktop appears....but after a while, the cooling fans on the video card and the power supply spin loudly at what I assume to be maximum speed and the computer is frozen. Holding the power button (or probably pulling the plug, which I did not try)is the only thing that will shut the system down.
Next, I logged in as root and ran # lsmod | grep nouveau and I found that the nouveau module is still loading...and I'm wondering if that is the problem?
You have to blacklist it, not uninstall it. Create a suitable file under /etc/modprobe.d/, with this line: blacklist nouveau -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 2022-02-17 16:41, mark neidorff wrote:
4. Then the login screen appears, and I can login.
My graphical desktop appears....but after a while, the cooling fans on the video card and the power supply spin loudly at what I assume to be maximum speed and the computer is frozen. Holding the power button (or probably pulling the plug, which I did not try)is the only thing that will shut the system down.
If you're not using the NVidia card, why leave it in your system? Removing it should take care of the problem with the nouveau driver still being loaded; if not, then you can blacklist the driver as Carlos suggested.
mark neidorff composed on 2022-02-17 17:41 (UTC-0500):
If the problem is not nouveau, what should I run to get more diagnostic information? Needless to say, my goal is a stable, graphical KDE environment.
It used to be with a Dell desktop that if a discrete graphics card was installed on a model that includes motherboard IGP or CPU IGP, that connecting a display to the IGP output would result in a BIOS message reporting that you are not allowed to do that, and must connect your display(s) to the discrete card's output(s) instead. I've not seen a Dell BIOS anywhere near as new as yours so as to know what to suggest you might need or want to do there. Motherboards for self-built PC's provide a lot more options re graphics setup. You might want to poke in yours for a suitable change to make. Ideally you have two ways to go: 1-Remove the discrete card 2-configure use of the discrete card to the exclusion of the IGP Another option would be to utilize the concept of "offloading", where the IGP and GPU share the job. That's more complicated and something I've never done. Whether anyone with such experience reads this list I have no idea, but I know there is at least one person routinely on the openSUSE forums who does, so you might want to do a search or inquire there. https://forums.opensuse.org/forumdisplay.php/668-Install-Boot-Login For option 1, it should be simple. Remove the discrete card, and let automagic do its thing without interference. NAICT, you have a 400 series Intel chipset PC, which supports Comet Lake (10th gen) and Rocket Lake (11th gen) Intel processors. At some point we may need to know the specific CPU model you have installed to be sure of how to proceed, as with Rocket Lake there could be an added problem if you ever connect more than one display at a time. All the bugs aren't out of Rocket Lake support yet. For option 2, you may need to blacklist i915 and/or i965, and/or change a BIOS option, to prevent interference from the IGP in using either of the two ostensibly competent FOSS display drivers for GeForce. If the GeForce cannot be made to work properly with the FOSS drivers, a bug report would be in order, as it should just work automagically. Installing *nouveau* may be necessary to enable that, as well as purging any residue from any prior attempt to install proprietary NVidia drivers that you might have made. To be complete, there's also the proprietary NVidia driver option, which I never use, so won't comment further about. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2/17/22 19:55, Felix Miata wrote:
mark neidorff composed on 2022-02-17 17:41 (UTC-0500):
If the problem is not nouveau, what should I run to get more diagnostic information? Needless to say, my goal is a stable, graphical KDE environment. It used to be with a Dell desktop that if a discrete graphics card was installed on a model that includes motherboard IGP or CPU IGP, that connecting a display to the IGP output would result in a BIOS message reporting that you are not allowed to do that, and must connect your display(s) to the discrete card's output(s) instead. I've not seen a Dell BIOS anywhere near as new as yours so as to know what to suggest you might need or want to do there. Motherboards for self-built PC's provide a lot more options re graphics setup. You might want to poke in yours for a suitable change to make.
Ideally you have two ways to go:
1-Remove the discrete card 2-configure use of the discrete card to the exclusion of the IGP
Another option would be to utilize the concept of "offloading", where the IGP and GPU share the job. That's more complicated and something I've never done. Whether anyone with such experience reads this list I have no idea, but I know there is at least one person routinely on the openSUSE forums who does, so you might want to do a search or inquire there. https://forums.opensuse.org/forumdisplay.php/668-Install-Boot-Login
For option 1, it should be simple. Remove the discrete card, and let automagic do its thing without interference.
NAICT, you have a 400 series Intel chipset PC, which supports Comet Lake (10th gen) and Rocket Lake (11th gen) Intel processors. At some point we may need to know the specific CPU model you have installed to be sure of how to proceed, as with Rocket Lake there could be an added problem if you ever connect more than one display at a time. All the bugs aren't out of Rocket Lake support yet.
For option 2, you may need to blacklist i915 and/or i965, and/or change a BIOS option, to prevent interference from the IGP in using either of the two ostensibly competent FOSS display drivers for GeForce. If the GeForce cannot be made to work properly with the FOSS drivers, a bug report would be in order, as it should just work automagically. Installing *nouveau* may be necessary to enable that, as well as purging any residue from any prior attempt to install proprietary NVidia drivers that you might have made.
To be complete, there's also the proprietary NVidia driver option, which I never use, so won't comment further about.
Mark, I've looked back on all the posts about this problem over the last two months, and I think a reset is in order because at this point we are really guessing and it isn't sufficiently clear (at least to me) what you have/have not done and why - especially given all of what you've switched around and dearth of results you've reported back. To start with, the RTX 2060 *is* supported by the nvidia driver and has been since early 2019. According to Phoronix, it works quite well. It uses the 470 version driver; following are all the associated packages. I didn't find any issues with this driver and your card. Installing this driver will blacklist nouveau. IIRC you won't have W$ on this machine, so in the bios disable Fast Boot and also Secure Boot, when you enable the discrete card (if for some reason you cannot disable Secure Boot, then after installing the driver but before rebooting with it, run as root #mokutil --disable-validation). Also install icewm; at the login screen choose it rather than KDE (just in case you have a KDE problem). If after doing all this and rebooting, X still fails, post what you did back here along with an attached copy of the file /var/log/Xorg.0.log. nvidia-computerG05 nvidia-fgxG05-kmp-default nvidia-glG05 x11-video-nvidiaG05 kernel-default-extra kernel-firmware-all (which should install kernel-firmware-nvidia; if it does not, include it) Next, nouveau: First, I'm confused. In Dec you posted here that you had nouveau working fine, but just not starting automatically. Now you report artifacts, raging fans, and lockup. What changed? In any event, this may be the problem (from Phoronix): "the Nouveau kernel driver is bound to running at the boot clock frequencies that are generally very low - just a fraction of their base - due to not being able to properly handle power management (PMU access limitations) with the graphics cards due to the signed firmware restrictions." (The shorthand for this issue is "reclocking".) This issue dates from early 2019, the nvidia gen just before yours. The Arch Linux page on nouveau, power management section, provides (rather complex) workarounds to manually manage pstates, fan speeds, or udev rules - while warning of the risk of overheating the video card, video corruption, or hanging the system, all of which sounds similar to the symptoms you report now. While this issue was still reported elsewhere just last year, I could find no update on the driver which solves the problem - I think the driver comes from freedesktop.org, maybe take an additional look there. But from what I've read, nvidia still has to do some things before this issue can be addressed by the nouveau dev's, if at all. If you want to try this again anyway (I don't advise this), the packages needed are as follows. Note that there are actually 2 nouveau drivers, the kernel driver which starts at boot and an X driver (xf86-video-nouveau). Before using it, you must be sure that there is no modesetting in the grub2 boot command line (if there is, remove that text with YaST Boot Loader which will regenerate the initrd) and also verify that there is no nouveau blacklisting in /etc/modprobe.d/. If you try this route and it fails, you can again post the logfile back here as an attachment. Mesa Mesa-dri-nouveau kernel-default-extra libdrm-nouveau2 xf86-video-nouveau Finally, re the integrated graphics with your Rocket Lake chip. Two weeks ago you stated that you "searched and found that there are no approved drivers for the Intel video chipset in Leap 15.3." Not correct. I think you were confused by a known problem in the openSUSE software search tool, i.e., 15.3 packages are not being included in the search directory. You also were probably looking at the xf86-video-intel package, which provides a DRI/3D driver for X (analogous to the X driver above for nouveau), not the same animal as the main Intel i915 kernel driver. (IOW, xf86* is actually in 15.3 although not shown by the search tool.) Also like with nouveau, both drivers are required. That said, as I wrote two weeks ago but you did not reply to, due to Rocket Lake being newer (March 2021) than stock 15.3 (Feb 2021), there is a very strong possibility that you need updated Intel kernel firmware. You can find it here: https://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_15.... Just install the kernel-firmware-all package to pull in the newest firmwares, including for the i915 ("kernel-firmware-i915" package). And again, you need xf86-video-intel installed as well. This doesn't mean that there may not be other Rocket Lake issues. You *may* need a newer kernel - or maybe not. But for sure, the i915 driver will not work if it does not have the necessary firmware for your device. So IMO the firmware should be your starting point. Install that, restart into the bios, point to the IGP, and boot. If X fails, post back X log as attachment. And btw, don't do blanket uninstalls based on package name unless you really know what you're doing - that can break your system. Good luck. --dg 15.3/Plasma
DennisG composed on 2022-02-20 14:10 (UTC-0500):
On 2/17/22 19:55, Felix Miata wrote:
mark neidorff composed on 2022-02-17 17:41 (UTC-0500):
If the problem is not nouveau, what should I run to get more diagnostic information? Needless to say, my goal is a stable, graphical KDE environment. It used to be with a Dell desktop that if a discrete graphics card was installed on a model that includes motherboard IGP or CPU IGP, that connecting a display to the IGP output would result in a BIOS message reporting that you are not allowed to do that, and must connect your display(s) to the discrete card's output(s) instead. I've not seen a Dell BIOS anywhere near as new as yours so as to know what to suggest you might need or want to do there. Motherboards for self-built PC's provide a lot more options re graphics setup. You might want to poke in yours for a suitable change to make.
Ideally you have two ways to go:
1-Remove the discrete card 2-configure use of the discrete card to the exclusion of the IGP
Another option would be to utilize the concept of "offloading", where the IGP and GPU share the job. That's more complicated and something I've never done. Whether anyone with such experience reads this list I have no idea, but I know there is at least one person routinely on the openSUSE forums who does, so you might want to do a search or inquire there. https://forums.opensuse.org/forumdisplay.php/668-Install-Boot-Login
For option 1, it should be simple. Remove the discrete card, and let automagic do its thing without interference.
NAICT, you have a 400 series Intel chipset PC, which supports Comet Lake (10th gen) and Rocket Lake (11th gen) Intel processors. At some point we may need to know the specific CPU model you have installed to be sure of how to proceed, as with Rocket Lake there could be an added problem if you ever connect more than one display at a time. All the bugs aren't out of Rocket Lake support yet.
For option 2, you may need to blacklist i915 and/or i965, and/or change a BIOS option, to prevent interference from the IGP in using either of the two ostensibly competent FOSS display drivers for GeForce. If the GeForce cannot be made to work properly with the FOSS drivers, a bug report would be in order, as it should just work automagically. Installing *nouveau* may be necessary to enable that, as well as purging any residue from any prior attempt to install proprietary NVidia drivers that you might have made.
To be complete, there's also the proprietary NVidia driver option, which I never use, so won't comment further about.
If you want to try this again anyway (I don't advise this), the packages needed are as follows. Note that there are actually 2 nouveau drivers, the kernel driver which starts at boot and an X driver (xf86-video-nouveau).
xf86-video-nouveau provides an /optional/ /old technology/ display driver. For best results from FOSS on NVidia GPUs, it is not usually required.
Before using it, you must be sure that there is no modesetting in the grub2 boot command line (if there is, remove that
Modesetting is the name of a driver. It is nomodeset, along with i915.modeset=0, amdgpu.modeset=0, radeon.modeset=0, and nouveau.modeset=0 that will disable KMS, which disables all optimal FOSS display drivers.
Finally, re the integrated graphics with your Rocket Lake chip. ...You also were probably looking at the xf86-video-intel package, which provides a DRI/3D driver for X (analogous to the X driver above for nouveau), not the same animal as the main Intel i915 kernel driver. (IOW, xf86* is actually in 15.3 although not shown by the search tool.) Also like with nouveau, both drivers are required.
Only the i915 kernel module (driver) is required for Rocket Lake. No DDX driver is required for either Intel or NVidia GPUs: # rpm -qa | egrep 'xf86-v|firmware|intel' | sort intel-media-driver-20.3.0-1.41.x86_64 intel-vaapi-driver-2.4.1-1.62.x86_64 kernel-firmware-i915-20210208-2.4.noarch kernel-firmware-intel-20210208-2.4.noarch libdrm_intel1-2.4.104-1.12.x86_64 ucode-intel-20210525-7.1.x86_64 xf86-video-fbdev-0.5.0-4.31.x86_64 xf86-video-vesa-2.4.0-3.31.x86_64 # lsmod | grep i9 i915 2625536 4 i2c_algo_bit 16384 1 i915 drm_kms_helper 262144 1 i915 cec 65536 2 drm_kms_helper,i915 drm 614400 4 drm_kms_helper,i915 video 53248 1 i915 # inxi -SCy System: Host: ab560 Kernel: 5.3.18-150300.59.49-default x86_64 bits: 64 Desktop: Trinity R14.0.11 Distro: openSUSE Leap 15.3 CPU: Info: 6-core model: 11th Gen Intel Core i5-11400 bits: 64 type: MT MCP cache: L2: 3 MiB Speed (MHz): avg: 801 min/max: 800/4400 cores: 1: 802 2: 801 3: 801 4: 803 5: 801 6: 801 7: 800 8: 801 9: 802 10: 800 11: 801 12: 800 # inxi -Gayz Graphics: Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK /driver: i915/ v: kernel bus-ID: 00:02.0 chip-ID: 8086:4c8b class-ID: 0300 /Display/: x11 server: X.Org 1.20.3 /driver/: /loaded/: modesetting/ unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1 Screen-1: 0 s-res: 2560x1440 s-dpi: 120 s-size: 541x304mm (21.3x12.0") s-diag: 621mm (24.4") Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27") OpenGL: renderer: /Mesa Intel Graphics/ (RKL GT1) v: 4.6 Mesa 20.2.4 direct render: Yes # Note absence of "intel" with regard to any running driver. The newer FOSS technology modesetting DIX driver is the preferred FOSS driver for all GPUs it supports, except for newer AMD GPUs that are supported by the DDX display driver provided by xf86-video-amdgpu. This support includes NVidia GPUs. <https://forums.opensuse.org/showthread.php/562680-AMD-Intel-amp-NVidia-X-graphics-driver-primer-third-edition> The nouveau DDX display driver is old technology, and reverse-engineered. The intel DDX display driver is also old technology. It hasn't had an official release in over 7 years. It's in maintenance mode, because for ancient Intel IGPs it's the only KMS-supporting display driver, and because in some configurations it may work better than the modesetting DIX.
That said, as I wrote two weeks ago but you did not reply to, due to Rocket Lake being newer (March 2021) than stock 15.3 (Feb 2021), there is a very strong possibility that you need updated Intel kernel firmware
I didn't for my Rocket Lake. He doesn't on account of any Rocket Lake hardware. I suppose Dell could have slipped in something else that needs newer firmware. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2/20/22 15:57, Felix Miata wrote:
DennisG composed on 2022-02-20 14:10 (UTC-0500):
On 2/17/22 19:55, Felix Miata wrote:
mark neidorff composed on 2022-02-17 17:41 (UTC-0500):
If the problem is not nouveau, what should I run to get more diagnostic information? Needless to say, my goal is a stable, graphical KDE environment. It used to be with a Dell desktop that if a discrete graphics card was installed on a model that includes motherboard IGP or CPU IGP, that connecting a display to the IGP output would result in a BIOS message reporting that you are not allowed to do that, and must connect your display(s) to the discrete card's output(s) instead. I've not seen a Dell BIOS anywhere near as new as yours so as to know what to suggest you might need or want to do there. Motherboards for self-built PC's provide a lot more options re graphics setup. You might want to poke in yours for a suitable change to make.
Ideally you have two ways to go:
1-Remove the discrete card 2-configure use of the discrete card to the exclusion of the IGP
Another option would be to utilize the concept of "offloading", where the IGP and GPU share the job. That's more complicated and something I've never done. Whether anyone with such experience reads this list I have no idea, but I know there is at least one person routinely on the openSUSE forums who does, so you might want to do a search or inquire there. https://forums.opensuse.org/forumdisplay.php/668-Install-Boot-Login
For option 1, it should be simple. Remove the discrete card, and let automagic do its thing without interference.
NAICT, you have a 400 series Intel chipset PC, which supports Comet Lake (10th gen) and Rocket Lake (11th gen) Intel processors. At some point we may need to know the specific CPU model you have installed to be sure of how to proceed, as with Rocket Lake there could be an added problem if you ever connect more than one display at a time. All the bugs aren't out of Rocket Lake support yet.
For option 2, you may need to blacklist i915 and/or i965, and/or change a BIOS option, to prevent interference from the IGP in using either of the two ostensibly competent FOSS display drivers for GeForce. If the GeForce cannot be made to work properly with the FOSS drivers, a bug report would be in order, as it should just work automagically. Installing *nouveau* may be necessary to enable that, as well as purging any residue from any prior attempt to install proprietary NVidia drivers that you might have made.
To be complete, there's also the proprietary NVidia driver option, which I never use, so won't comment further about. If you want to try this again anyway (I don't advise this), the packages needed are as follows. Note that there are actually 2 nouveau drivers, the kernel driver which starts at boot and an X driver (xf86-video-nouveau). xf86-video-nouveau provides an /optional/ /old technology/ display driver. For best results from FOSS on NVidia GPUs, it is not usually required.
Ah, that explains why I didn't find it required by anything, although it is installed by default. Does this mean that the current (kernel) nouveau has resolved the power management issues that it had, and so that can be ruled out for causing OP's racing issue? And is it no longer required to import the mok certificate?
Before using it, you must be sure that there is no modesetting in the grub2 boot command line (if there is, remove that Modesetting is the name of a driver. It is nomodeset, along with i915.modeset=0, amdgpu.modeset=0, radeon.modeset=0, and nouveau.modeset=0 that will disable KMS, which disables all optimal FOSS display drivers.
Yes, thx. Given that distros use different syntax here, I just used an abbreviated "modesetting" to keep in simple, lest there was something left over from previous attempts.
Finally, re the integrated graphics with your Rocket Lake chip. ...You also were probably looking at the xf86-video-intel package, which provides a DRI/3D driver for X (analogous to the X driver above for nouveau), not the same animal as the main Intel i915 kernel driver. (IOW, xf86* is actually in 15.3 although not shown by the search tool.) Also like with nouveau, both drivers are required. Only the i915 kernel module (driver) is required for Rocket Lake. No DDX driver is required for either Intel or NVidia GPUs: # rpm -qa | egrep 'xf86-v|firmware|intel' | sort intel-media-driver-20.3.0-1.41.x86_64 intel-vaapi-driver-2.4.1-1.62.x86_64 kernel-firmware-i915-20210208-2.4.noarch kernel-firmware-intel-20210208-2.4.noarch libdrm_intel1-2.4.104-1.12.x86_64 ucode-intel-20210525-7.1.x86_64 xf86-video-fbdev-0.5.0-4.31.x86_64 xf86-video-vesa-2.4.0-3.31.x86_64
Noted. I think I was thrown off by xf86 nvidia and intel packages being included in 15.3 and TW.
# lsmod | grep i9 i915 2625536 4 i2c_algo_bit 16384 1 i915 drm_kms_helper 262144 1 i915 cec 65536 2 drm_kms_helper,i915 drm 614400 4 drm_kms_helper,i915 video 53248 1 i915 # inxi -SCy System: Host: ab560 Kernel: 5.3.18-150300.59.49-default x86_64 bits: 64 Desktop: Trinity R14.0.11 Distro: openSUSE Leap 15.3 CPU: Info: 6-core model: 11th Gen Intel Core i5-11400 bits: 64 type: MT MCP cache: L2: 3 MiB Speed (MHz): avg: 801 min/max: 800/4400 cores: 1: 802 2: 801 3: 801 4: 803 5: 801 6: 801 7: 800 8: 801 9: 802 10: 800 11: 801 12: 800 # inxi -Gayz Graphics: Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK /driver: i915/ v: kernel bus-ID: 00:02.0 chip-ID: 8086:4c8b class-ID: 0300 /Display/: x11 server: X.Org 1.20.3 /driver/: /loaded/: modesetting/ unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1 Screen-1: 0 s-res: 2560x1440 s-dpi: 120 s-size: 541x304mm (21.3x12.0") s-diag: 621mm (24.4") Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27") OpenGL: renderer: /Mesa Intel Graphics/ (RKL GT1) v: 4.6 Mesa 20.2.4 direct render: Yes #
Note absence of "intel" with regard to any running driver. The newer FOSS technology modesetting DIX driver is the preferred FOSS driver for all GPUs it supports, except for newer AMD GPUs that are supported by the DDX display driver provided by xf86-video-amdgpu. This support includes NVidia GPUs.
The nouveau DDX display driver is old technology, and reverse-engineered. The intel DDX display driver is also old technology. It hasn't had an official release in over 7 years. It's in maintenance mode, because for ancient Intel IGPs it's the only KMS-supporting display driver, and because in some configurations it may work better than the modesetting DIX.
Again, thx for the update. Clearly I need that primer. :)
That said, as I wrote two weeks ago but you did not reply to, due to Rocket Lake being newer (March 2021) than stock 15.3 (Feb 2021), there is a very strong possibility that you need updated Intel kernel firmware I didn't for my Rocket Lake. He doesn't on account of any Rocket Lake hardware. I suppose Dell could have slipped in something else that needs newer firmware.
I'll take your word. Although it seems curious why there is a firmware update given that Xe-LP is the latest architecture. Maybe due to processor differences across the Rocket Lake series (although I would expect the same for OP's i7 as your i5). In any event, thanks Felix for taking the time with the needed corrections/clarifications. Re the OP's problem: His nvidia card has had good driver support from nvidia for 3 years, but he claims it does not work. He has reported both good, and very bad, results with nouveau. One post showed that the i915 had been loaded, but it apparently didn't work, either. At this point, then? A newer kernel, as previously advised? Or go back to square one, test each of the alternatives again verifying steps, and take a look at the X log each time (as probably should have been suggested before)? Or, if nouveau and i915 are viable alternatives, maybe just another fresh install to test each??? OP has been to this movie 3 times over the last 2 months. --dg 15.3/Plasma
participants (5)
-
Carlos E. R. -
Darryl Gregorash -
DennisG -
Felix Miata -
mark neidorff