Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
notebook does not work when not booted using nomodeset AMD APU
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.
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.
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.
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.
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
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.
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.
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]
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.
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 ?
This issue hasn't had any activity since 2019-11-19. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.