These issues are not all necessarily related to the kernel. We need more information before we see what’s causing it—or before we can debug them and maybe file bugs if required. Can you go through the logs and find any errors? journalctl -b would be a good source. You can filter it and grep it too. This post provides more information on filtering logs: https://docs.fedoraproject.org/en-US/quick-docs/viewing-logs/
I haven’t had any kernel related breakages in quite a while now, so this may be hardware specific. In any case, you’ll have to speak to the kernel devs about the possibility of providing different varients of kernels. Maybe get in touch with them on their mailing list?
In the meantime, please boot back in to a 4.2 kernel. You may want to increase the installonly_limit in /etc/dnf/dnf.conf to a higher number to ensure that the 4.2 kernel is not removed in an update.
I already did that. Meanwhile someone on #fedora irc channel reported the exact same issue that I was facing. The only thing which save me is to put exclude=kernel* in all fedora.repo and fedora-updates.repo files. Otherwise notifications will bug me to do a update.
Actually it is related to the amdgpu driver because 4.20 is working nicely.
Yes. I can see accountmanager service fails because of timeout issue. After login gnome took an ample amount of time to show the desktop with screen completely off in between. I had to force shutdown because it wasn’t even rebooting.
I am thinking of doing that because I don’t need a latest kernel but a stable kernel unless I am running Fedora on a gaming rig. I wonder if they allow an option to choose different kernel in anaconda setup screen at the time of installation will be awesome.
Let’s see what happens.
I highly doubt that. The maintenance burden alone would be too much. Not only do they have to maintain an older kernel, they have to setup multiple kernels with anaconda in the live environment—and of course, all of this will have to be tested, so QA will have more work on their hands too.
The way to go would be to get the amd issues fixed: file your bugs, either downstream or upstream if preferable. I hear AMD is quite good when it comes to kernel contributions (at least I think I heard that somewhere). In the meantime, if you find/file bugs or find a work-around, please post here so others may also benefit from your work. Cheers!
I’m having resume issues on my thinkpad with f30 beta too. I think I’ve run into this mutter issue. Are you in workstation and gnome 3.32 too by any chance?
Theres a copr in the ticket with a fix. Ill try that later, and if it works, ask the maintainers to pull in the fix. They also report that suspending without using the lid works fine, so worth testing as a workaround too if this is the issue you are seeing.
I’m in Fedora 29. The bug has effected Fedora 27, 28 too. It was fixed in 4.20 and reappeared in 5. The worse thing is that I can fix it by adding amdgpu.dc=0 as in the previous versions. I am trying to build a kernel without hdmi cec support. Let’s see if that fixes or not.
Here is the result of my investigation which will prove that this is truely a problem with amdgpu dc in the kernel.
AMDGPU dc enabled audio routing through hdmi in 4.14x kernel iirc.
While looking at the logs carefully, I found this: kernel: snd_hda_intel 0000:00:09.2: azx_get_response timeout, switching to single_cmd mode: last cmd=0x0213b080
Now quoting from Audio-HD.txt,
BIOS reports the available codec slots wrongly, the driver gets
confused and tries to access the non-existing codec slot. This often
results in the total screw-up, and destructs the further communication
with the codec chips. The symptom appears usually as error messages
hda_intel: azx_get_response timeout, switching to polling mode:
hda_intel: azx_get_response timeout, switching to single_cmd mode:
The first line is a warning, and this is usually relatively harmless.
It means that the codec response isn’t notified via an IRQ. The
driver uses explicit polling method to read the response. It gives
very slight CPU overhead, but you’d unlikely notice it.
The second line is, however, a fatal error. If this happens, usually
it means that something is really wrong. Most likely you are
accessing a non-existing codec slot.
Secondly I issued cat /proc/asound/cards and I got the result:
0 [HDMI ]: HDA-Intel - HDA ATI HDMI
HDA ATI HDMI at 0xf0d60000 irq 39
1 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xf0d64000 irq 38
Acer: selling with a lock down amd apu(amd-v is disabled for reason idk and they haven’t provided a setting to toggle that) wasn’t enough. They have already stopped updating the bios two years ago. Wish I could flash coreboot and get the ultimate freedom from this oem bits.
Upto now I was using the upstream kernel config for my custom kernel. I will create my own config and create a kernel package with it. I can jump over to Ubuntu or mint which uses a kernel from 4.15 series which works on my laptop but I will not do that because one thing that I like about Fedora is its community. But seriously this kernel 5 is giving my lots of headaches and sleepless nights.
Open a bug report to freedesktop bugzilla notifying them of this regression.
Ask fedora kernel mailing list for the things required in a vanilla kernel that are needed to run Fedora.
Ask them if they can provide an lts kernel. I will set up LTS sig then.
Also LTS kernel is not outdated. It still receives important security updates.