21:28 <prahal_> hi liquidAcid:

21:28 <prahal_> I am still struggling with iommu :/

21:30 <prahal_> the page fault happens in exynos_iommu_unmap while invalidating the tlb

21:54 <liquidAcid> prahal_, hmm, i wonder if that's just something you see with armsoc

22:06 <prahal_> indeed it matters . I clued an overlap of destroy and mmap

22:08 <prahal_> but the kernel should fail gracefully even if user space is messy

22:08 <liquidAcid> doesn't destroying the bo also remove the mapping?

22:09 <prahal_> the page fault happens inthe middle of the gem destroy > free buf

22:10 <liquidAcid> ah, i think i can trigger such a case as well

22:11 <liquidAcid> at least it happened when i wrote the g2d event tests and didn't flush all events before exit

22:13 <prahal_> btw I get unmap for all 4 sysmmu related to drm (g2d , 2 xfimc, and mixer) for the same iova & size

22:48 <javier__> liquidAcid, prahal: my gfx knowledge is near to non-existent but when testing the latest exynos iommu series I also found issues on exynos5 with the armsoc ddx

22:48 <javier__> http://www.spinics.net/lists/linux-samsung-soc/msg44379.html

22:49 <javier__> I got a complete system hang on an exynos5420 with no output on the serial console when X started, this does not happen when using the fbdev ddx

22:51 <javier__> liquidAcid, prahal_: so the iommu support on exynos drm is definitely buggy or at least not robust enough

23:12 <prahal_> thanks javier__ , indeed 0x20000000 is the default (and current value) for drm in the kernel exynos_drm_iommu.h/c , size EXYNOS_DEV_ADDR_SIZE 0x40000000

23:20 <liquidAcid> just an idea, but maybe play around with the allocation flags that armsoc uses

23:20 <prahal_> liquidAcid: disabling g2d iommu looked promising

23:21 <liquidAcid> prahal_, but armsoc doesn't even use the g2d

23:22 <prahal_> it took more gnome shell starts to get a crash ... only did a serie though

23:23 <liquidAcid> prahal_, i'd say that what you're seeing is different from the issue that javier__ describes

23:24 <liquidAcid> at least you get the information about the page fault happening. if i understand javier__ correctly then for him the soc just died

23:24 <liquidAcid> *dies

23:28 <liquidAcid> also: https://github.com/mdrjr/xf86-video-armsoc/blob/r4p0/src/drmmode_exynos/drmmode_exynos.c#L145

23:32 <prahal_> about the g2d , I only disabled its iommu attached to the drm . I do not know what happens when we do invalidate the same io virtual address on all the drm syssmu

23:37 <prahal_> second test session , correlate the first one : no page fault anymore only plain instant crash when I kill -KILL gnome-shell after all my other test failed to crash

23:37 <liquidAcid> hmm, really no idea

23:38 <prahal_> will try with the drm changes

23:38 <liquidAcid> which changes?

23:39 <prahal_> the allocation flags

23:40 <prahal_> gee that was for armsoc

23:41 <liquidAcid> i wonder if armsoc doesn't do proper cleanup on exit

23:42 <liquidAcid> e.g. i don't see it disabling the crtc anywhere, might be worth to try doing that

23:43 <liquidAcid> prahal_, i still suspect that what you're getting is because mixer is still scanning out a deallocated buffer