in kernel 4.10 and higher unable to boot without enabling nomodeset option which also removes 3D acceleration for AMD APU processors with hybrid graphics. See the following link for full detail on the bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1683184
Please attach the dmesg output corresponding to the problem here directly.
Created attachment 131361 [details] CurrentDMesg attached dmesg from another user with the same bug
Comment on attachment 131361 [details] CurrentDMesg This dmesg is with nomodeset, so it doesn't contain any information related to the problem. Please attach the dmesg output from an attempt without nomodeset.
(In reply to Michel Dänzer from comment #3) > Comment on attachment 131361 [details] > CurrentDMesg > > This dmesg is with nomodeset, so it doesn't contain any information related > to the problem. > > Please attach the dmesg output from an attempt without nomodeset. I am not sure how to get a dmesg out of it. Does Dmesg log to a file somewhere? I can't boot into the OS and output anything to text file as it just provides a "AMD-Vi: Completion-Wait loop timed out" and a bunch of disk checks that kept failing never allowing me to logon. I left it for 8-9 hours and i was still unable to do anything with the system other than a Ctrl-Alt-SysRq REISUB. Please let me know how to proceed. thanks
(In reply to Craig from comment #4) > Does Dmesg log to a file somewhere? Depending on your distro, it might be captured in /var/log/kern.log*, /var/log/dmesg*, or in the systemd journal.
Created attachment 131377 [details] Bootup Screenshot
(In reply to Craig from comment #6) > Created attachment 131377 [details] > Bootup Screenshot I am running Ubuntu 17.04. Anyways I have checked through the logs (kern.log, syslog and it appears that the last time it recorded anything in them was when I was using "nomodeset" on bootup. I have attached screenshots of what I get when I boot up without nomodeset as a parameter. Is it possible that it is not writing to disk when I bootup without "nomodeset"? There is no dmesg log in the /var/log folder. It appears that I could use journalctl -b but that only works if I am able to boot into the system or the dmesg command but also needs to be able to boot into it to run that.
Created attachment 131378 [details] Bootup Screenshot 2
Created attachment 131379 [details] Bootup Screenshot 3
Okay, I guess we need to try another trick: Boot with modprobe.blacklist=amdgpu on the kernel command line to prevent the amdgpu module from being loaded automatically. Once the system is booted up, manually run sudo modprobe amdgpu This should increase the chance of capturing the dmesg output somewhere.
ok I added the modprobe.blacklist=amdgpu to the kernel command line, wouldnt boot until I also added modprobe.blacklist=radeon. Anyways once I was in I did run sudo modprobe amdgpu and got the usual "AMD-Vi: Completion-Wait loop timed out" amongst other errors. It did log some strange things in kern.log and syslog. I also ran dmesg -k >/home/craig/DMESG.txt and it created a file with nothing in it. I will attach the kern.log and syslog... not sure if that helps, as you can see i am very new at doing this kind of thing.
Created attachment 131380 [details] Syslog
Created attachment 131381 [details] Kernel Log
Looks like https://patchwork.freedesktop.org/patch/146519/ might help, or passing iommu=soft on the kernel command line might serve as a workaround.
where do i find the amd_iommu.c in ubuntu 17.04 so that I can patch it? or is there a different method? I was considering using this syntax: patch -p[num] < patchfile patch [options] originalfile patchfile thanks very much
(In reply to Craig from comment #15) > where do i find the amd_iommu.c in ubuntu 17.04 so that I can patch it? or > is there a different method? I was considering using this syntax: patch > -p[num] < patchfile > patch [options] originalfile patchfile > thanks very much please disregard this i believe i found a solution.
I can't seem to find the amd_iommu.c file, would you be able to point me to where it is? also what would be the proper syntax to run the patch program? it seems to indicate -p or --strip but i am to sure what number to enter after it.
-p1 should work in the top level directory of a Linux kernel source tree. Have you confirmed that iommu=soft on the kernel command line works around the problem?
using iommu=soft on the kernel command line and it is now hard freezing. I will try and get the patch applied next. I can't Ctrl-Alt-Del or Ctrl-Alt-SysRq-REISUB to reboot.
ok when i type the following it is unable to find the file to patch: sudo patch -p1 < iommu-amd-flush-IOTLB-for-specific-domains-only.patch It displays the following: can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: ___________________________________ |diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c |index 98940d1..6a9a048 100644 |--- a/drivers/iommu/amd_iommu.c |+++ b/drivers/iommu/amd_iommu ___________________________________
I have the same problem on carrizo+iceland nb (reported at [0,1]). I can confirm that the linked patch applied on top of 4.10.x fixes boot, and the machine can run 3d applications (tested glxgears) on both GPUs (running 3d apps on dGPU still causes null pointer dereference when the card goes back to suspend, but that's a separate issue). it also fixes the boot hang problem on ROCK[1] [0]https://bugzilla.redhat.com/show_bug.cgi?id=1448121 [1]https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/20
in that case, when will this patch be applied permanently in a kernel versus having to use the patch? I will be attempting to apply the patch soon and verify as well on the Ubuntu side.
I can now confirm that the kernel patch fixes my problem. How can I keep in the loop as to when this is applied in the kernel? very eager to see this make its way in so that I can upgrade my kernel without having to patch and compile one on my own.
You can follow the review of the latest patch revision at https://patchwork.freedesktop.org/patch/157327/ We will resolve this bug report when the fix has landed in Linus' tree.
Does the patch mentioned in comment 24 only allow '__queue_flush' to complete faster at boot time ? Or should we expect some performance gain after boot ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/169.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.