leming has quit [Read error: Connection reset by peer]
leming has joined #linux-exynos
leming has quit [Read error: Connection reset by peer]
leming has joined #linux-exynos
dlan has quit [Ping timeout: 256 seconds]
dlan has joined #linux-exynos
liquidAcid has joined #linux-exynos
prahal_ has joined #linux-exynos
liquidAcid has quit [Quit: Leaving]
pekka30 has joined #linux-exynos
zombah has joined #linux-exynos
afaerber__ has quit [Ping timeout: 244 seconds]
liquidAcid has joined #linux-exynos
afaerber__ has joined #linux-exynos
liquidAcid has quit [Quit: Leaving]
liquidAcid has joined #linux-exynos
afaerber__ is now known as afaerber
leming has quit [Quit: ZNC - http://znc.in]
<prahal_> hi liquidAcid:
<prahal_> I am still struggling with iommu :/
<prahal_> the page fault happens in exynos_iommu_unmap while invalidating the tlb
leming has joined #linux-exynos
<liquidAcid> prahal_, hmm, i wonder if that's just something you see with armsoc
<prahal_> indeed it matters . I clued an overlap of destroy and mmap
<prahal_> but the kernel should fail gracefully even if user space is messy
<liquidAcid> doesn't destroying the bo also remove the mapping?
<prahal_> the page fault happens inthe middle of the gem destroy > free buf
<liquidAcid> ah, i think i can trigger such a case as well
<liquidAcid> at least it happened when i wrote the g2d event tests and didn't flush all events before exit
<prahal_> btw I get unmap for all 4 sysmmu related to drm (g2d , 2 xfimc, and mixer) for the same iova & size
<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
<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
<javier__> liquidAcid, prahal_: so the iommu support on exynos drm is definitely buggy or at least not robust enough
<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
<liquidAcid> just an idea, but maybe play around with the allocation flags that armsoc uses
<prahal_> liquidAcid: disabling g2d iommu looked promising
<liquidAcid> prahal_, but armsoc doesn't even use the g2d
<prahal_> it took more gnome shell starts to get a crash ... only did a serie though
<liquidAcid> prahal_, i'd say that what you're seeing is different from the issue that javier__ describes
<liquidAcid> at least you get the information about the page fault happening. if i understand javier__ correctly then for him the soc just died
<liquidAcid> *dies
<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
<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
<liquidAcid> hmm, really no idea
<prahal_> will try with the drm changes
<liquidAcid> which changes?
<prahal_> the allocation flags
<prahal_> gee that was for armsoc
<liquidAcid> i wonder if armsoc doesn't do proper cleanup on exit
<liquidAcid> e.g. i don't see it disabling the crtc anywhere, might be worth to try doing that
<liquidAcid> prahal_, i still suspect that what you're getting is because mixer is still scanning out a deallocated buffer
liquidAcid has quit [Quit: Leaving]