iommu page fault causes blank screen under Manjaro 20.04?
#1
Hello, I used the emmc installer image to put Manjaro 20.04 on my PBP and was happily setting it up as a system I'd use for many months. I was running out of things to change when the screen started to go blank during use. The PBP runs for about an hour longer until it won't respond to SSH any more. I searched dmesg and journalctl for errors and warnings or things to do with the display, but didn't find anything that looked like a problem to me. This installation is using Gnome, mesa-git, Panfrost, and is using GDM to get Wayland sessions. The problem may have started after switching to GDM and Wayland.

Once this had happened a few times, I realized closing the lid would put something in the journal to show where it happened. Here is the results of 'journalctl -r --no-hostname'. You can see just before I closed the lid, rk_iommu said quite a bit, including page faults And before that Tracker was core dumping, which is all over the journal so doesn't appear to be causing the the blank screen. Does anyone have ideas on tracking the problem down?

Code:
Apr 10 16:44:11 systemd-logind[835]: Lid closed.
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: mmu_dte_addr: 0x00000000ec804000 dte@0x00000000ec80401c: 0xae156001 valid: 1 pte@0x0000000>
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: iova = 0x0000000001cf6000: dte_index: 0x7 pte_index: 0xf6 page_offset: 0x0
Apr 10 16:44:02 kernel: rk_iommu ff8f3f00.iommu: Page fault at 0x0000000001cf6000 of type read
Apr 10 16:42:57 systemd[1219]: Failed to start Tracker metadata extractor.
Apr 10 16:42:57 systemd[1219]: tracker-extract.service: Failed with result 'signal'.
Apr 10 16:42:57 systemd[1219]: tracker-extract.service: Start request repeated too quickly.
Apr 10 16:42:57 dbus-daemon[1360]: [session uid=1000 pid=1360] Activating via systemd: service name='org.freedesktop.Tracker1.Miner.Extract>
Apr 10 16:42:56 kernel: audit: type=1334 audit(1586551376.228:23789): prog-id=6769 op=UNLOAD
Apr 10 16:42:56 kernel: audit: type=1334 audit(1586551376.228:23788): prog-id=6770 op=UNLOAD
Apr 10 16:42:56 audit: AUDIT1334 prog-id=6769 op=UNLOAD
Apr 10 16:42:56 audit: AUDIT1334 prog-id=6770 op=UNLOAD
Apr 10 16:42:56 kernel: audit: type=1131 audit(1586551375.988:23787): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit>
Apr 10 16:42:55 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-coredump@3370-244834-0>
Apr 10 16:42:55 systemd[1]: systemd-coredump@3370-244834-0.service: Succeeded.
Apr 10 16:42:55 systemd-coredump[244835]: Process 244805 (tracker-extract) of user 1000 dumped core
#2
I've found lots of instances on the web of people having tracker using a tremendous amount of CPU and memory. Can you try disabling tracker to see if that is the problem. Or perhaps also ask this in the Manjaro arm forum.... . I believe tracker and tracker-miner packages are installed with GNOME. I am running the KDE Plasma version of 20.04, and don't have tracker running, nor am I seeing the problem you are having.
#3
(04-11-2020, 02:18 PM)belfastraven Wrote: I've found lots of instances on the web of people having tracker using a tremendous amount of CPU and memory. Can you try disabling tracker to see if that is the problem. Or perhaps also ask this in the Manjaro arm forum.... . I believe tracker and tracker-miner packages are installed with GNOME. I am running the KDE Plasma version of 20.04, and don't have tracker running, nor am I seeing the problem you are having.

I can try disabling tracker, but I had been watching resource use, it never got too close to max and the PBP didn't appear to be grinding to a halt. The other info I have now is that it only happens under Wayland. Describing the problem clearly for the post made me think more systematically and realize that the change to GDM+Wayland was around the time the problem started and I hadn't tried Xorg again. Since I posted I have been using GNOME on Xorg without problem. Enough uptime has passed that I'm sure the problem would have occurred in a Wayland session. So unless tracker or other programs are acting differently in the two sessions, it seems related to Wayland so I can now poke around in that direction (without fear of the screen going blank in the middle of something!)
#4
The 2020-04-17 stable update from Manjaro appeared to solve this. The kernel, Wayland, and mesa-git were all updated among more than 90 other packages so I don't know what was going on or what fixed it.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Attempting to install Void Linux, boots into a black screen 9a3eedi 1 1,191 09-28-2024, 09:23 AM
Last Post: throwawayforvoid
  [Pinebook Pro/Mobian/XFCE4] can fix touch or screen in greeter not both SynthGal 0 401 05-31-2024, 09:42 AM
Last Post: SynthGal
  Manjaro Sway Theme Broken Eighty8 1 796 03-08-2024, 08:41 AM
Last Post: tophneal
Question Manjaro with Full Disk Encryption and GRUB dumetrulo 1 2,316 02-02-2024, 02:45 AM
Last Post: frankkinney
  Manjaro network problem late 2023 acruhl 1 824 01-19-2024, 11:32 PM
Last Post: Kevin Kofler
  Help installing Manjaro on eMMC of Pinebook Pro pine4546464 4 3,220 12-13-2023, 07:22 PM
Last Post: trillobite
  Need Help Recovering Manjaro /boot Contents on Pinebook Pro calinb 6 3,511 12-11-2023, 03:47 AM
Last Post: calinb
  Manjaro 20.04 not loading from SD (with Manjaro on eMMC) zaius 1 881 12-07-2023, 03:11 PM
Last Post: wdt
  Manjaro ARM: enabling external monitors & fixing Broadcom WiFi after updating trifleneurotic 2 1,635 11-14-2023, 10:57 AM
Last Post: trifleneurotic
  Manjaro [ARM Stable Update] 2021-07-23 issues Bocanila 1 2,398 08-21-2023, 09:10 PM
Last Post: vanessadonald

Forum Jump:


Users browsing this thread: 1 Guest(s)