White lines and screen block after installing either firmware-linux-nonfree or firmware-amd-graphics - Sempron 2600+ and Radeon HD 3450
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
White lines and screen block after installing either firmware-linux-nonfree or firmware-amd-graphics - Sempron 2600+ and Radeon HD 3450
Using Sempron 2600+ and Radeon HD 3450, I installed the OS from a USB and on startup got the message "Radeon kernel modesetting for R600 or later requires firmware installed". The OS is Debian 11 i386 with the default desktop environment and LXQT. The start screen where the services get started and finished got blocked when it came to the Simple Desktop Display Manager. After pressing CTRL+ALT+F2, I got to a bash prompt, entered a root username and password. Then in the sources list, I added the non-free and contrib keywords. I did apt update, and installed
Code:
sudo apt install firmware-linux-nonfree
After that, I rebooted and the screen got blocked showing white lines, like in the image below.
ALT+CTRL+F2 and holding SHIFT are unresponsive. Trying to boot from the USB again shows black screen.
With a previous installation of the same Debian 32 bit version, I installed Mate instead of LXQT and logged successfully. But, the resolution was low and pixelated and I couldn't find the graphics card in the settings. There I installed
Code:
sudo apt install firmware-amd-graphics
and after a reboot, the same white lines block appeared.
Using amd64 from a USB, the white lines appear immediately before it arrives at the install menu, after the motherboard logo.
I tried antiX Linux, 32 and 64 bit and the white lines appear too. But, antiX has a live version with the ISO and the install menu has options to start with different parameters. I selected one of the modes, either video safe mode with the keyword
Code:
xorg=safe
or another boot mode with the keyword
Code:
failsafe
It logged me and I can use the OS, but the resolution is pixelated again. Both 32 and 64 bit worked. I can't find the graphics card in the settings again.
On antiX I got this using inxi. The driver for the graphics is N/A, but as I installed graphics drivers on Debian, the screen got blocked.
Only the last URL, directly to a .jpg, is viewable here. Imgur pages that host images are blocked due to scripts. Images can be attached here directly, if they're limited to a reasonable size, or uploaded to a pastebin that doesn't require disabling scripts.
Including radeon.agpmode=-1 on Grub's linu line might help, but from what I see on that white lines image, I think that Radeon is ready for the recycle bin. I've seen more than a few instances in various help forums to indicate a disappointing rate of failures among old Radeons. I've had several turn to toast for me, most recently a 9850 AGP, before that PCIe X300, X600 & X850. My HD3570 is still OK (along with several older and several newer), using only free firmware:
I tried including radeon.agpmode=-1 with antiX Linux's boot screen, but it still returns the screen with white lines. I tried installing Windows XP, and after copying the files to proceed with the installation, it showed a blocked screen with red lines starting at the top instead of the white ones starting at the bottom. I did Ctrl+Alt+Del, it rebooted, and then the installation proceeded. I installed Windows XP, the OS works.
Yes, there might be something wrong with the Radeon GPU.
It seems that only AntiX and Linux MX have a boot menu with a lot of options, that this PC can reach when Linux is 64-bit. I created a live USB with Rufus and Linus MX 21.1 64-bit, and booting with the usual parameters shows a stuck scrambled screen with the text that appeared during the booting process.
But, using parameters as nomodeset or radeon.modeset=0 starts the OS successfully, however, the resolution is low at 720x480 and it can't be increased. It seems that the graphic drivers in Linux are causing the screen to get stuck, I tried with Debian 11, Ubuntu 21.10, Ubuntu Server 20.04, Arch Linux, Linux Mint, EndeavourOS, and other distros. Booting EndeavourOS with a few of its options resulted in a stuck screen, but with eos64fb it returns a message:
Quote:
[KMS] drm report modesetting isn't supported
I started MX with radeon.modeset=0 added to the booting parameters line, and after loading, I installed it on an SSD. Then, booting from the SSD works and it shows low resolutions, it seems that the radeon.modeset=0 was set in the booting configuration.
With inxi -Fxxxrz, it shows that fbdev, modesetting, radeon are unloaded.
using parameters as nomodeset or radeon.modeset=0 starts the OS successfully, however, the resolution is low at 720x480 and it can't be increased.
Those are primarily troubleshooting parameters. They disable KMS, usually allowing a low resolution and lethargic boot that permits reconfiguration. Without KMS, the important kernel device and X display drivers can't load, so X falls back on crude drivers that usually won't support widescreen modes or modes higher than 1280x1024, often lower.
Unless there's something particularly different about the AGP RV620 devices from the PCIe RV620 devices, I still have to think you have a failing RV620. Mine still works well across all installed distros, among them, the five following:
Your graphics card seems to be broken.
You can try two things:
Clean its contacts.
1. step: Remove patina with an erazer.
2. step: Clean contacts with tissue paper and isopropyl alcohol (propan-2-ol). Example: Left side shows contacts with patina, right side shows cleaned contacts: https://www.sackpfeyffer-zu-linden.d...igt_300dpi.jpg
Replace thermal grease between GPU and its cooler with new one.
This old Sempron 3000+ motherboard has VIA Unichrome graphics, which is why I have a Radeon card in it. It has bad RAM, so colors are erratic, but the modes are as they should be. Notice this and my others are all running an AMD/ATI Mesa OpenGL renderer, while yours is llvm-based. That means all available Mesa modules have not been installed. Here are mine:
Code:
# dpkg -l \*mesa\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========================-============-============-===========================================================
ii glx-alternative-mesa 1.2.1 amd64 allows the selection of MESA as GLX provider
ii libegl-mesa0:amd64 21.3.8-1 amd64 free implementation of the EGL API -- Mesa vendor library
ii libegl1-mesa:amd64 21.3.8-1 amd64 transitional dummy package
ii libgl1-mesa-dri:amd64 21.3.8-1 amd64 free implementation of the OpenGL API -- DRI modules
ii libgl1-mesa-glx:amd64 21.3.8-1 amd64 transitional dummy package
ii libglapi-mesa:amd64 21.3.8-1 amd64 free implementation of the GL API -- shared library
ii libgles2-mesa:amd64 21.3.8-1 amd64 transitional dummy package
ii libglu1-mesa:amd64 9.0.2-1 amd64 Mesa OpenGL utility library (GLU)
ii libglw1-mesa:amd64 8.0.0-1.1+b1 amd64 GL widget library for Athena and Motif -- runtime
ii libglx-mesa0:amd64 21.3.8-1 amd64 free implementation of the OpenGL API -- GLX vendor library
ii libosmesa6:amd64 21.3.8-1 amd64 Mesa Off-screen rendering extension
un libwayland-egl1-mesa <none> <none> (no description available)
ii mesa-utils 8.4.0-1+b2 amd64 Miscellaneous Mesa GL utilities
ii mesa-utils-extra 8.4.0-1+b2 amd64 Miscellaneous Mesa utilies (opengles, egl)
ii mesa-va-drivers:amd64 21.3.8-1 amd64 Mesa VA-API video acceleration drivers
ii mesa-vdpau-drivers:amd64 21.3.8-1 amd64 Mesa VDPAU video acceleration drivers
un mesa-vulkan-drivers <none> <none> (no description available)
un mesag3 <none> <none> (no description available)
un xlibmesa3 <none> <none> (no description available)
Possibly adding the missing ones to yours would be helpful in some way, though I still think you need to find another GPU.
I tried to install Windows 7 from DVD or USB but there was a black screen. The accepted answer from Tuesday, September 7, 2010, 6:26 AM suggests turning off features in the BIOS: https://social.technet.microsoft.com...w7itproinstall
I turned off multiple things regarding the Advanced Options and Chipset, Peripherals, and Cell Menu. Windows 7 still showed a black screen, but I booted Linux MX 64-bit from a USB without the nomodeset parameters, and it worked. The option that allows the boot to proceed was setting in the BIOS -> Advanced Chipset Features -> AGP Timing Control -> AGP Aperture Size to a different value than the Load Optimized Default of 128MB. I set it to 64MB, but it also works with 256MB. I installed Linux MX from the installer on the Live USB desktop. Booting from the SSD also shows a bigger resolution.
Perhaps the GPU is defective indeed or it needs cleaning.
Yes, there is a short screen corruption after boot, and on the previous startup, there was a corruption that lasted 1-2 seconds when loading the desktop and the menus, but that one didn't appear the last time I booted it.
You have a Radeon HD 3450 AGP. There is one great issue with AGP graphics cards & Linux: If "AGP fast writes" is enabled in BIOS AGP graphics card doesn't correctly work in most cases with Linux. Disabling "AGP fast writes" in BIOS may avoid crashes, black screens, scrambled screens etc. and gives a chance that AGP graphics card will correctly work.
NAICT, this is a purely cosmetic thing. https://www.kernel.org/doc/Documenta...ot-options.txt has some kernel command line options you might try if the corruption is sufficiently bothersome. iommu=noagp would be one I'd try if my 3470 was AGP instead of PCIe. iomem=relaxed & amdgpu.dc=0 are other stabs. If these options or experimenting with other options or others' comments here produce no fruit, you could try asking AMD developers on their mailing list or on IRC.
AGP Fast Write is set to Disabled by Load Optimized Defaults. I set the AGP Aperature Size to 128MB, but booting from the SSD, after the Welcome to Grub! message the screen gets scrambled and stuck. Setting it to 256MB and then using the above commands there is still a short corruption at the desktop GUI load. But, with or without the commands, the corruption gets cleared quickly and the PC is usable.
I sent an email to the AMD developers on their mailing list.
I tried with Nvidia FX5200 AGP8X. It has 128MB memory, and setting the memory in BIOS -> Advanced Chipset Features -> AGP Timing Control -> AGP Aperture Size to 256MB, the screen on loading gets stuck and every time it shows the same pattern of random pixelated colors, probably because it requires more memory than the GPU has. Setting the AGP Aperature Size to 128MB or 64MB, the PC loads up to the Login screen on MX Linux. Clicking on Login, the screen gets stuck and becomes pixelated again.
With the Radeon HD 3450 AGP the PC is usable after setting the Aperature Size to something other than 128MB.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
