Bug 101029 - notebook does not work when not booted using nomodeset AMD APU
Summary: notebook does not work when not booted using nomodeset AMD APU
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact:
URL: https://bugs.launchpad.net/ubuntu/+so...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-13 07:36 UTC by Craig
Modified: 2017-09-22 05:53 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
CurrentDMesg (76.81 KB, text/plain)
2017-05-15 13:33 UTC, Craig
no flags Details
Bootup Screenshot (6.25 MB, image/jpeg)
2017-05-17 02:44 UTC, Craig
no flags Details
Bootup Screenshot 2 (5.31 MB, image/jpeg)
2017-05-17 02:48 UTC, Craig
no flags Details
Bootup Screenshot 3 (6.70 MB, image/jpeg)
2017-05-17 02:51 UTC, Craig
no flags Details
Syslog (1.21 MB, text/plain)
2017-05-17 04:31 UTC, Craig
no flags Details
Kernel Log (874.40 KB, text/plain)
2017-05-17 04:31 UTC, Craig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Craig 2017-05-13 07:36:32 UTC
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
Comment 1 Michel Dänzer 2017-05-15 09:16:49 UTC
Please attach the dmesg output corresponding to the problem here directly.
Comment 2 Craig 2017-05-15 13:33:52 UTC
Created attachment 131361 [details]
CurrentDMesg

attached dmesg from another user with the same bug
Comment 3 Michel Dänzer 2017-05-16 02:20:54 UTC
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.
Comment 4 Craig 2017-05-17 01:30:35 UTC
(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
Comment 5 Michel Dänzer 2017-05-17 01:36:05 UTC
(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.
Comment 6 Craig 2017-05-17 02:44:16 UTC
Created attachment 131377 [details]
Bootup Screenshot
Comment 7 Craig 2017-05-17 02:45:10 UTC
(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.
Comment 8 Craig 2017-05-17 02:48:21 UTC
Created attachment 131378 [details]
Bootup Screenshot 2
Comment 9 Craig 2017-05-17 02:51:05 UTC
Created attachment 131379 [details]
Bootup Screenshot 3
Comment 10 Michel Dänzer 2017-05-17 03:19:27 UTC
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.
Comment 11 Craig 2017-05-17 04:29:47 UTC
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.
Comment 12 Craig 2017-05-17 04:31:09 UTC
Created attachment 131380 [details]
Syslog
Comment 13 Craig 2017-05-17 04:31:44 UTC
Created attachment 131381 [details]
Kernel Log
Comment 14 Michel Dänzer 2017-05-17 08:46:32 UTC
Looks like https://patchwork.freedesktop.org/patch/146519/ might help, or passing iommu=soft on the kernel command line might serve as a workaround.
Comment 15 Craig 2017-05-17 12:56:08 UTC
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
Comment 16 Craig 2017-05-17 12:58:23 UTC
(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.
Comment 17 Craig 2017-05-17 23:37:20 UTC
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.
Comment 18 Michel Dänzer 2017-05-18 02:05:33 UTC
-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?
Comment 19 Craig 2017-05-18 02:40:03 UTC
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.
Comment 20 Craig 2017-05-18 02:59:20 UTC
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
___________________________________
Comment 21 Jan Vesely 2017-05-18 17:29:19 UTC
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
Comment 22 Craig 2017-05-18 18:35:33 UTC
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.
Comment 23 Craig 2017-05-21 14:20:43 UTC
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.
Comment 24 Michel Dänzer 2017-05-22 01:12:56 UTC
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.
Comment 25 Julien Isorce 2017-05-22 10:25:18 UTC
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 ?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.