On 2018-09-18 10:13 a.m., Christian König wrote: > Mhm, there is no more failed IB-test in there isn't it? oh sorry I thought you wanted to test HEAD~ ... Attached is a log from the tip of drm-next Tom > > 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 >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: amdgpu_ih_process2.log.gz Type: application/gzip Size: 21165 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180918/02fa726f/attachment-0001.gz>
