Mhm, there is no more failed IB-test in there isn't it? Christian. Am 18.09.2018 um 16:09 schrieb Tom St Denis: > Disabling IOMMU in the BIOS resulted in a correct boot up... > > Here's the log. > > Tom > > On 2018-09-18 9:58 a.m., Tom St Denis wrote: >> Odd I couldn't even boot my system with the dGPU as primary after >> rebuilding the kernel. It got hung up in the IOMMU driver (loads of >> AMD-Vi IOMMU errors) which I wasn't able to capture because it >> panic'ed before loading the network stack. >> >> Bizarre. >> >> I'll keep trying. >> >> Tom >> >> On 2018-09-18 9:35 a.m., Christian König wrote: >>> Am 18.09.2018 um 15:32 schrieb Tom St Denis: >>>> On 2018-09-18 9:30 a.m., Christian König wrote: >>>>> Great, not sure if that is a good or a bad news. >>>>> >>>>> Anyway going to revert the change for now. Does anybody volunteer >>>>> to figure out why interrupts sometimes doesn't work correctly on >>>>> Raven? >>>> >>>> What does "doesn't work correctly?" My workstation is a Raven1 >>>> (Ryzen 2400G) and other than the TTM bulk move issue has been >>>> perfectly stable (through suspend/resumes too I might add). >>>> >>>> Anything I could test with my devel raven? >>> >>> The problem seems to be that on some boards IH handling doesn't work >>> as it should. >>> >>> Can you try to disable the onboard graphics and try again? >>> >>> If that still doesn't work there is a DRM_DEBUG in >>> amdgpu_ih_process(), make that a DRM_ERROR and send me the resulting >>> dmesg of loading amdgpu (but don't start any UMD). >>> >>> Thanks, >>> Christian. >>> >>>> >>>> >>>> Tom >>>> >>>>> >>>>> Christian. >>>>> >>>>> Am 18.09.2018 um 15:27 schrieb Tom St Denis: >>>>>> This commit: >>>>>> >>>>>> [root at raven linux]# git bisect good >>>>>> 9b0df0937a852d299fbe42a5939c9a8a4cc83c55 is the first bad commit >>>>>> commit 9b0df0937a852d299fbe42a5939c9a8a4cc83c55 >>>>>> Author: Christian König <christian.koenig at amd.com> >>>>>> Date:  Tue Sep 18 10:38:09 2018 +0200 >>>>>> >>>>>>    drm/amdgpu: remove fence fallback >>>>>> >>>>>>    DC doesn't seem to have a fallback path either. >>>>>> >>>>>>    So when interrupts doesn't work any more we are pretty much >>>>>> busted no >>>>>>    matter what. >>>>>> >>>>>>    Signed-off-by: Christian König <christian.koenig at amd.com> >>>>>>    Reviewed-by: Chunming Zhou <david1.zhou at amd.com> >>>>>> >>>>>> Results in this: >>>>>> >>>>>> [  24.334025] [drm] Initialized amdgpu 3.27.0 20150101 for >>>>>> 0000:07:00.0 on minor 1 >>>>>> [  24.335674] modprobe (3895) used greatest stack depth: 12600 >>>>>> bytes left >>>>>> [  26.272358] [drm:gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* >>>>>> amdgpu: IB test timed out. >>>>>> [  26.272460] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* >>>>>> amdgpu: failed testing IB on ring 9 (-110). >>>>>> [  26.407885] [drm:process_one_work] *ERROR* ib ring test failed >>>>>> (-110). >>>>>> [  28.506708] fuse init (API version 7.27) >>>>>> >>>>>> On init with my polaris/raven1 system. >>>>>> >>>>>> Cheers, >>>>>> Tom >>>>>> _______________________________________________ >>>>>> amd-gfx mailing list >>>>>> amd-gfx at lists.freedesktop.org >>>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>>>> >>>> >>> >> >
