When I rebooted my computer into Fedora this morning, it’s not talking to my right monitor. I don’t think it’s a hardware issue, because the BIOS sees both monitors, but when it boots, the monitor says it’s not getting a signal. When I go into settings to look at the display(s), the OS thinks that it only has one monitor. Any ideas?
[Afternoon update]
Apparently it was due to a kernel update. I backed up to the previous kernel and it seems to be working now.
[November 4th update]
Well, I’ve updated kernels several times, and this weekend I upgraded from Fedora 40 to Fedora 41. The problem persists. The OS is clearly having trouble seeing the second monitor. Do I need to replace the video card? How should I diagnose this?
[Bumped]
[Veterans’ Day update]
Well, I got no response from the Fedora Forum. This is what I get when I ixni:
inxi -Fzx
System:
Kernel: 6.11.6-300.fc41.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 2.43.1-2.fc41
Console: pty pts/0 Distro: Fedora Linux 41 (Workstation Edition)
Machine:
Type: Desktop Mobo: Micro-Star model: X570-A PRO (MS-7C37) v: 3.0
serial: UEFI: American Megatrends LLC. v: H.K0 date: 04/27/2023
CPU:
Info: 6-core model: AMD Ryzen 5 3600 bits: 64 type: MT MCP arch: Zen 2
rev: 0 cache: L1: 384 KiB L2: 3 MiB L3: 32 MiB
Speed (MHz): avg: 3596 min/max: 550/4208 boost: enabled cores: 1: 3596
2: 3596 3: 3596 4: 3596 5: 3596 6: 3596 7: 3596 8: 3596 9: 3596 10: 3596
11: 3596 12: 3596 bogomips: 86403
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Caicos [Radeon HD 6450/7450/8450
/ R5 230 OEM] vendor: XFX Pine driver: radeon v: kernel arch: TeraScale-2
bus-ID: 2e:00.0 temp: 62.0 C
Display: unspecified server: X.Org v: 24.1.4 with: Xwayland v: 24.1.4
driver: X: loaded: radeon unloaded: fbdev,modesetting,vesa dri: r600
gpu: radeon resolution: 1920×1080~60Hz
API: OpenGL v: 4.5 vendor: mesa v: 24.2.6 glx-v: 1.4 direct-render: yes
renderer: AMD CAICOS (DRM 2.50.0 / 6.11.6-300.fc41.x86_64 LLVM 19.1.0)
API: EGL Message: EGL data requires eglinfo. Check –recommends.
Audio:
Device-1: C-Media CMI8738/CMI8768 PCI Audio driver: snd_cmipci v: kernel
bus-ID: 2a:00.0
Device-2: Advanced Micro Devices [AMD/ATI] Caicos HDMI Audio [Radeon HD
6450 / 7450/8450/8490 OEM R5 230/235/235X OEM] vendor: XFX Pine
driver: snd_hda_intel v: kernel bus-ID: 2e:00.1
Device-3: Advanced Micro Devices [AMD] Starship/Matisse HD Audio
vendor: Micro-Star MSI X570-A PRO driver: snd_hda_intel v: kernel
bus-ID: 30:00.4
API: ALSA v: k6.11.6-300.fc41.x86_64 status: kernel-api
Server-1: PipeWire v: 1.2.6 status: off
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Micro-Star MSI X570-A PRO driver: r8169 v: kernel port: d000
bus-ID: 27:00.0
IF: enp39s0 state: up speed: 100 Mbps duplex: full mac:
Drives:
Local Storage: total: 2.05 TiB used: 1.08 TiB (52.5%)
ID-1: /dev/nvme0n1 vendor: Patriot model: Viper M.2 VPN100
size: 238.47 GiB temp: 27.9 C
ID-2: /dev/sda vendor: Western Digital model: WD20EZAZ-00L9GB0
size: 1.82 TiB temp: 31 C
Partition:
ID-1: / size: 231.3 GiB used: 38.79 GiB (16.8%) fs: btrfs
dev: /dev/nvme0n1p3
ID-2: /boot size: 973.4 MiB used: 515.7 MiB (53.0%) fs: ext4
dev: /dev/nvme0n1p2
ID-3: /boot/efi size: 598.8 MiB used: 19.3 MiB (3.2%) fs: vfat
dev: /dev/nvme0n1p1
ID-4: /home size: 1.79 TiB used: 1.04 TiB (58.0%) fs: ext4 dev: /dev/sda1
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
System Temperatures: cpu: 52.2 C mobo: N/A gpu: radeon temp: 62.0 C
Fan Speeds (rpm): N/A
Info:
Memory: total: 32 GiB available: 31.26 GiB used: 21.5 GiB (68.8%)
Processes: 479 Uptime: 5h 22m Init: systemd target: graphical (5)
Packages: 16 note: see –rpm Compilers: gcc: 14.2.1 Shell: Bash v: 5.2.32
inxi: 3.3.36
I’ve seen some people say that they solved the problem by upgrading Nvidia drivers, but would that work for a Radeon? Or should I upgrade Radeon drivers? Which one?
This is the sort of thing that happens after an update, either a library change or a new kernel module. Does the problem persist when booting to an earlier kernel?
No, it cleared up when I went to the previous kernel. If I have to reboot, I’ll do it manually with that kernel until there’s another kernel update (they occur quite often), and hopefully the next one will fix the issue.
About the slow boot, I’d be worried about a hardware issue, possibly bad sectors in the EFI partition. You might want to boot into a diagnostic thumb drive like parted magic. There may be some free alternatives, or even a separate fedora drive with SU enabled utilities. Then you could do a deep dive into the health of all the partitions. After that, Boot Repair might have some ideas.
Makes sense.
A lot depends how he’s getting into the bios. If it’s direct via a keyboard press (ESC, F2, etc.), it MIGHT, but just might, be independent of a boot drive. I say might because these days all sorts of weird things happen on power up that seems to be different for different computers. Gone are the days of the good old white boxes, where the motherboard just talks to the keyboard and the monitor if you push the bios key. If he gets into the bios via the grub menu, then a boot issue is definitely in play.
Unrelated old man rant…
Ubuntu finally removed LDAP protocol support for CUPS based printer drivers. Along with the replacement of inetd with systemd all my favorite Linux hacks are slowly but surely disappearing.
Is it better? Or just different?
Pixy over at Ace posted this fun issue with WD SSDs:
https://hothardware.com/news/windows-11-24h2-wd-ssd-bsod
Now that’s BSOD, but who knows what it does to Linux.
Rolls eyes.
Point taken. It could be that Fedora has no ability (as yet) to take advantage of an NVMe cache and so disables or never enables the feature and has to go to non-volatile reads until enough of the O/S is running to use main memory as a disk cache? Be interesting to research the topic.
Do I need to replace the video card? How should I diagnose this?
I’d start with the Fedora Forums. If you don’t see a logical match there for your problem already, post a query. Does sounds like a display driver issue to me. Hopefully they didn’t drop support for your video card.
Maybe it’s something you can fix with an insmod or a kernel recompile if you are up for that. Good Luck.
Simply for comparison purposes: I’m one version behind vis-a-vis Long Term Support (LTS) using Ubuntu 22.04 LTS under a VM. I’ve been running now for over two years largely without issue. I did experience one problem with an Ubuntu “upgrade” at one point about a year ago that hosed my display but it got fixed with an corresponding update to the Guest Host utilities under my VM. Nothing weird since. I typically stage upgrades by taking a snapshot of the working O/S before doing them. That way I can always roll back anything that breaks. Sounds like you have done similar. Absolutely key when working with Fedora I’d say…
After doing a Brave search, this seems to happen to somebody with just about every Fedora release, but I don’t see anything specific about 41. As David suggests, Fedora forums might be helpful, but also check if there are forums related to your video card. What card is it? Nvidia always seems to have a love/hate relationship with Linux, I’m afraid. In Ubuntu, there’s a mechanism to report a bug directly to Canonical, and I’ve had good luck on their responses in several cases. Does Red Hat have a similar function?
However, you could wait for just one more release, because Douglas Adams assured us that 42 is the answer to life, the universe and everything.
I don’t think it’s a 41 problem. It was happening with the last few kernels of 40 as well. I was hoping that 41 would fix finally fix it, but it didn’t. I’ve posted at Fedora Forum, but not gotten a response yet.
Just out of curiosity, have you tried a different screen resolution to see if that affects the situation?
Also I remember way back when you switched to using X11 over Wayland. Is that still the case?
I don’t know how to change the screen resolution of a screen that doesn’t exist.
Change it on the one that does and see what happens with the other.
It just stays black.
What about the Wayland vs X11 question?
FWIW I typed this into ChatGPT:
Do you have any solutions to dual display fails to work under Fedora Core 40 using ATI/Radeon Graphics Card?
It came up with a few things to try, nothing specific to FC40 however.
You might want to walk through a few steps and see what you can find out.
“I’ve seen some people say that they solved the problem by upgrading Nvidia drivers, but would that work for a Radeon? Or should I upgrade Radeon drivers? Which one?”
Only install/upgrade/use the drivers for the type of card you have. Nvidia drivers won’t do anything if you have a Radeon GPU and vice versa.
Is the video part of built in AMD CPU circuitry, or is it on a separate Radeon card? Nvidia drivers shouldn’t do anything for you, but updated Radeon drivers might. Found this site that possibly could help:
https://linux-hardware.org/index.php?id=pci:1002-aa98-1043-aa98
Switching between Xorg and Wayland is probably worth a try, but you’ve probably tried that already. You might also play around with booting into a live USB version of another Linux flavor (e.g. Manjaro, Ubuntu 24.04, etc.) and see if they work. Then you can check which drivers they use with what you have. I used that trick to diagnose some faulty audio problems with Ubuntu 22.04 that were fixed in 24.04 for an Intel Celeron built in audio on an el cheapo laptop.
Finally, if you are using a separate Radeon card, if you can switch to another card that supports dual monitors might tell you if it’s a high level issue (e.g. Wayland) or a hardware driver in problem.
It’s a card. I guess I could borrow one from her computer. But I know that the card works during POST, because I see both screens. It just disappears when it boots.
Also:
Radeon HD 6450/7450/8450/ R5 230 OEM
Even the newest iteration of that (R5 230) is probably 10+ years old and the last official RHEL drivers on AMD’s site are from 2015. I know “upgrade” isn’t going to be what you want to hear but it might be worth considering.
Googling the issue I see people have been having problems since 2016 with Fedora kernel updates causing this problem with AMD cars. One person on a recent thread said adding acpi_osi=linux made him stop having problem. That’s something you add to your bootloader, IIRC. Have you tried this? (Also: someone in a thread mentioned having the same problem on a Radeon 7900XTX so maybe the age of your card isn’t the issue either, after all.)
You may have mentioned this at some point, I don’t remember. Is there something keeping you on Fedora? You do seem to have a (relatively) large number of problems.
When the monitor fails to wake up, what happens if you unplug it and plug it back in? (Don’t just turn it off with the power button. I tried that when I was having a similar problem, only with Windows, and it didn’t make a difference for some reason, only unplugging the cable did. But the root cause was different).
The monitor works fine during POST. It just disappears after boot. I’ll try that bootloader modification.
It was a cheap card I installed when I got the second monitor. Maybe it would be best to just replace it.
Time is money…
Does your monitor have a button that cycles through all the input ports? If so, try it when the monitor won’t wake up. If not, go into the monitor’s settings and manually switch through all of the inputs and see if it comes back when you get back go the one that’s plugged in. Not sure what, if anything, that will tell us, but it might give you a workaround, at least.
Again, the monitor is not asleep. It just loses signal after boot.
I saw this in a couple of forum threads–try this and see if anything interesting pops up (I don’t know what to look for, but below the command I’ll paste in the last suspend and resume operations on my Linux PC).
journalctl | grep -i ‘suspend\|resume’
Nov 11 22:52:27 rick-MN56 systemd-logind[907]: The system will suspend now!
Nov 11 22:52:27 rick-MN56 ModemManager[1050]: [sleep-monitor-systemd] system is about to suspend
Nov 11 22:52:28 rick-MN56 systemd[1]: Starting systemd-suspend.service – System Suspend…
Nov 11 22:52:28 rick-MN56 systemd-sleep[406534]: Performing sleep operation ‘suspend’…
Nov 11 22:52:28 rick-MN56 kernel: PM: suspend entry (deep)
Nov 12 06:50:10 rick-MN56 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 12 06:50:10 rick-MN56 kernel: ACPI: PM: Low-level resume complete
Nov 12 06:50:10 rick-MN56 kernel: amdgpu 0000:e5:00.0: amdgpu: SMU is resumed successfully!
Nov 12 06:50:10 rick-MN56 kernel: PM: suspend exit
Nov 12 06:50:10 rick-MN56 systemd-sleep[406534]: System returned from sleep operation ‘suspend’.
Nov 12 06:50:10 rick-MN56 bluetoothd[874]: Controller resume with wake event 0x0
Nov 12 06:50:10 rick-MN56 systemd[1]: systemd-suspend.service: Deactivated successfully.
Nov 12 06:50:10 rick-MN56 systemd[1]: Finished systemd-suspend.service – System Suspend.
Nov 12 06:50:10 rick-MN56 systemd[1]: Reached target suspend.target – Suspend.
Nov 12 06:50:10 rick-MN56 systemd-logind[907]: Operation ‘suspend’ finished.
Nov 12 06:50:10 rick-MN56 systemd[1]: Stopped target suspend.target – Suspend.
Another thing: try out what Espionage724 said in the last post in this thread:
https://discussion.fedoraproject.org/t/monitor-wont-wake-from-suspend-amd-gpu-thinkpad/127324/6
I don’t think it’s a suspend issue. The OS doesn’t see the monitor. When I go to Display settings, it’s not there.
After years of reading Rand’s posts on computer problems, I think I found the solution. There is one common issue.
“When I rebooted my computer into Fedora this morning,”
Have you tried not turning your computer off? Simple fix.
After years of reading Rand’s posts on computer problems, I think I found the solution. There is one common issue.
“When I rebooted my computer into Fedora this morning,”
IMHO this is the common issue…
Fedora == Forever Beta or Mostly Alpha… I have no patience for it.
As a friend of mine who has long since retired from the olden days of VAX/VMS likes to say: “When you allow children to program, expect your software to throw tantrums…”