Hi,

tested with the newly released rc6, same issue.

Many thanks !
Christian

I have the same issue with a 2700U in a Dell Inspiron 7375. All of the 4.20 RC versions that I have tried show the same problem. The system is able to boot with a 4.19 kernel.

The issue is still present in kernel 4.20.0-rc6-next-20181213.

Can you boot the system without amdgpu loaded (e.g., append modprobe.blacklist=amdgpu)?  Or is this a general platform problem?

Can you boot the system without amdgpu loaded (e.g., append modprobe.blacklist=amdgpu)

-> Doing this, i am able to boot my system.

To clarify, the system can boot with the amdgpu module, but it will lock up when LightDM/X starts. Booting with the amdgpu module blacklisted works.

Yes, same here. The system boots until GDM wants to start, then it freezes with the mentioned amdgpu error. Disabling amdgpu let the system start up completely including gdm.

Can you bisect?

020aa2ec15fc4a5ffdfcab7dc0db648a137abc41 lets me log in before the system freezes.

770af5859d6903049b7f39ed4f4e6612b63fd82d locks up before LightDM can start.

I'll do a bit more testing.

Ignore that previous comment. I'm getting some strange results here and may have marked a commit with an intermittent crash as "good" while bisecting.

"bc537a9cc47eec7f4e32b8164c494ddc35dca8ac is the first bad commit"

Well, that's kind of useless. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=bc537a9cc47eec7f4e32b8164c494ddc35dca8ac

Any suggestions on how to get a better idea of where the break was?

Make sure you've tested a commit plenty before declaring it "good".

FYI, as a workaround, you can use the kernel opt:

 iommu=pt

..at least, on 4.20 rc7, which is the only one I've tried that on, but it should work with others.

I can confirm that the iommu=pt workaround works, also iommu=soft works to get gdm started and use the laptop. Sadly i have no idea what impact those workarounds have when it comes to performance of the gpu/cpu or battery lifetime ?

(In reply to chris from comment #14)
> I can confirm that the iommu=pt workaround works, also iommu=soft works to
> get gdm started and use the laptop. Sadly i have no idea what impact those
> workarounds have when it comes to performance of the gpu/cpu or battery
> lifetime ?

Sadly i had a freeze during desktop usage shortly after boot using iommu=pt.
The driver situation for raven ridge is really sad atm :( .

I've tested a next-20181221 kernel with IOMMU_DEFAULT_PASSTHROUGH set, and I'm able to get the system to start properly. Still seeing some system lockups, when playing games, but it's better than crashing on the login screen.

Hi,

the laptop is still freezing when trying to start with kernel 4.20 (release version) using latest amdgpu firmware from kernel firmware git.

Using iommu=soft still solves that issue.

I also tested with a kernel daily build from 26.12 which should include the latest drm changes, and it also shows the same issue.

Is there anything we can provide to help finding the root cause ?

Many thanks !
Christian

*** Bug 109200 has been marked as a duplicate of this bug. ***

Created attachment 142928 [details]
full kernel log

Seeing same issue with Dell 5575 (AMD 2500u, Vega mobile) on 4.20 Release.  iommu=soft seems to allow boot.

Kernel Log: https://gist.github.com/ikidd/692dea4c63cc7656247071322d066405

With iommu=soft I still occasionally experience frozen screen with following logs:

Jan 02 16:11:18 lzThinkpad gnome-shell[1647]: Failed to flip: Cannot allocate memory
Jan 02 16:11:18 lzThinkpad kernel: amdgpu 0000:05:00.0: 00000000a2e0b642 pin failed
Jan 02 16:11:18 lzThinkpad kernel: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -12

I would like to add that on my Lenovo E585 iommu=pt works reliably; even for hours and doing games/webvideos. But a few minutes in wayland produce a frozen screen (without iommu=pt is does not even start).

Can anyone else try and bisect?

No problem here with amdgpu and iommu enabled, running kernel 4.20.0 on Dell Latitude 5495 (2700U). So BIOS issue maybe?

iommu=pt is however still needed for kfd (bug 107898).

Created attachment 142974 [details]
journalctl -b of lockup from bisected commit

E585 owner here.  Please let me know if I can provide any additional information that would be helpful.  Thanks in advance for your help.

This problem was very consistently reproduced during the bisect.  I've attached a journalctl -b from the first bad commit.  I was able to bisect the problem to...


284dec4317c8e76f45d3ce922f673c80331812f1 is the first bad commit
commit 284dec4317c8e76f45d3ce922f673c80331812f1
Author: Christian König <christian.koenig@amd.com>
Date:   Wed Aug 22 16:44:56 2018 +0200

    drm/amdgpu: enable GTT PD/PT for raven v3

    Should work on Vega10 as well, but with an obvious performance hit.

    Older APUs can be enabled as well, but will probably be more work.

    v2: fix error checking
    v3: use more general check

    Signed-off-by: Christian König <christian.koenig@amd.com>
    Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Hi,

many thanks for that bisect.
I googled the commit and found the following in addition which seems to be the same issue ?

https://bugzilla.kernel.org/show_bug.cgi?id=201727

Hope that helps.

Many thanks !
Christian

Still the same issue with kernel 5.0-rc1. Any plan on when to tackle that issue ?

Should be fixed with this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c1eba86339c8517814863bc7dd21e2661a84e77

I'm able to boot when building from that commit (1c1eba8) and looks like it will land in 4.20.4.

Thanks!

Very nice. Just tried 5.0-rc2 and booting works fine now without the iommu workaround !

-- 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/633.