Comment # 6
on bug 109135
from rmuncrief@humanavance.com
(In reply to iive from comment #5) > (In reply to rmuncrief from comment #2) > [...] > > Here's the grub line I use for all testing: > > GRUB_CMDLINE_LINUX_DEFAULT="quiet > > resume=UUID=b4f71480-8fe3-43c2-99c9-fc3f5687545b libata.atapi_passthru16=0 > > rd.modules-load=vfio-pci amd_iommu=on iommu=pt amdgpu.modeset=1 > [...] > > Would you try with "iommu=soft", aka disable the hardware one? > Maybe try tuning it off entirely. Thank you for looking into this bug. I tried all combinations of amd_iommu/iommu "soft" and "off", on kernels 4.19.13, 4.20.0, and linux-mainline from last night. And I tried them all with the BIOS iommu enabled and disabled, and also leaving and removing iommu=pt. In all cases the boot failed in the same way, with a black screen and complete lockup so that even ssh from another terminal would not work. And unfortunately none of them generated any type of boot log that I could find. In fact if you delete all the /var/log/Xorg.* log files, and then try booting with the bad kernels, not even an empty Xorg.*.old log file is generated. The only log that appears after I finally change back to 4.18.20 is the single Xorg.0.log from its boot. And of course there's nothing at all in journalctl. In any case I'm an embedded systems designer, but only have a cursory knowledge of low level Linux kernel development. However I'm willing to invest whatever time is necessary to help find this bug. I bought an expensive R9 390 three years ago and have only been able to fully utilize it for about six months off and on. By the way, I'd have no problem sticking with the 4.18 kernel as everything works great with it, and I've heard that same sentiment from others. It really seems that for whatever reasons there were systemic errors introduced after it, and they will take a substantial amount of time to fix. Our only concern is that 4.18 will soon lose support. So given the unprecedented number of problems with all later kernels it may be wise to move it to LTS, and give developers more time to work on the plethora of problems they're dealing with now.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
