You are not logged in.
[Solution]
Update to 6.4.11 or disable tpm module.
[Bug Description]
All system including sound and screen will stuck for 2-3 seconds. E.g. "Hello, world" will become "H_e_llo, w___d" and mouse cursor and screen will appear uncontinuously for seconds. (It is very annoying while playing OSU!)
This situation will appear 3 times or above in a day.
[Log]
N/A (No log relative to this issue)
[System Info]
$ neofetch
-` zayn7lie@zayn7lie
.o+` ---------------------
`ooo/ OS: Arch Linux x86_64
`+oooo: Host: ROG Flow X13 GV301RA_GV301RA 1
`+oooooo: Kernel: 6.4.2-arch1-1
-+oooooo+: Uptime: 1 day, 18 hours, 57 mins
`/:-:++oooo+: Packages: 916 (pacman)
`/++++/+++++++: Shell: bash 5.1.16
`/++++++++++++++: Resolution: 1920x1200
`/+++ooooooooooooo/` DE: Xfce 4.18
./ooosssso++osssssso+` WM: Xfwm4
.oossssso-````/ossssss+` WM Theme: Default
-osssssso. :ssssssso. Theme: Adwaita-dark [GTK2/3]
:osssssss/ osssso+++. Icons: Papirus-Dark [GTK2/3]
/ossssssss/ +ssssooo/- Terminal: xfce4-terminal
`/ossssso+/:- -:/+osssso+- Terminal Font: Fira Code 11
`+sso+:-` `.-/+oso: CPU: AMD Ryzen 7 6800HS with Radeon
`++:. `-/+/ GPU: AMD ATI Radeon 680M
.` `/ Memory: 9210MiB / 15231MiB [Misc]
I have searched for answers but previous solutions all concerning gpu, BIOS(UEFI) and upgrading kernel.
I have tried to install `xf86-video-amdgpu` and reboot, upgrading BIOS from ASUS ROG website (I even prepare dual-system including windows for upgrading), upgrading arch linux kernel but still fail to fix it.
[Updated]
Delete the log that might mislead to other issue.
Last edited by zayn7lie (2024-02-16 15:37:34)
Offline
it is suspicious because it will appear three situations:
And do the timestamps of those appearances match the occurrence of the freeze?
"Error waiting for DMUB idle: status=3" is typically linked ot output reconfigurations (resolution change, output added/removed, resume from S3/S4)
"Failed to load plugin "tumbler" just means you don't have some tumbler plugins installed. That's not relevant to anything.
Offline
it is suspicious because it will appear three situations:
And do the timestamps of those appearances match the occurrence of the freeze?
"Error waiting for DMUB idle: status=3" is typically linked ot output reconfigurations (resolution change, output added/removed, resume from S3/S4)"Failed to load plugin "tumbler" just means you don't have some tumbler plugins installed. That's not relevant to anything.
They SOMETIMES match the occurrence of the freeze.
Yes, that is the reason why I said "Thus, I suspect the real error is not shown in journalctl."
Do you have any suggestions that are able to figure out the reason like other journal, logs or so on?
Offline
Then what does the system journal actually say around the incidents?
The usual suspect would be your CPU, https://wiki.archlinux.org/title/Ryzen#Troubleshooting - try to limit the c-states, start w/ "processor.max_cstate=1", if that prevents the stalls you can try whether you get away w/ higher levels.
Offline
Then what does the system journal actually say around the incidents?
The usual suspect would be your CPU, https://wiki.archlinux.org/title/Ryzen#Troubleshooting - try to limit the c-states, start w/ "processor.max_cstate=1", if that prevents the stalls you can try whether you get away w/ higher levels.
The journal actually say nothing except the situation I have mentioned above. I just wondering whether there is other system logs I could view in addition to journalctl?
As for c-state, I will try and test this method. Thanks a lot.
Offline
Any chance you're running OOM?
Also post the journal (to be sure: unless you're in the "systemd-journal", "adm", or "wheel" group you need to sudo journalctl) and an estimated timeframe when those stalls happened.
Offline
Any chance you're running OOM?
Also post the journal (to be sure: unless you're in the "systemd-journal", "adm", or "wheel" group you need to sudo journalctl) and an estimated timeframe when those stalls happened.
Yes, that is what I actually do.
But I found another post through `dmesg`:
[ 3550.621773] traps: mscore[7111] general protection fault ip:7f74255518a6 sp:7fff4d7baaf8 error:0 in libQt5Gui.so.5.15.10[7f74254f8000+471000]I am not sure whether it matches the timestamp. Anyway, I will track it next several days.
BTW, how to transfer [ 3550.621773] to real time? I do not know how to match the time with this.
Last edited by zayn7lie (2023-07-11 06:12:21)
Offline
If you're running OOM all bets are generally off and that message is basically telling you that some Qt lib had a fault in memory trying to use ressources that aren't there. How much RAM do you have how much gets used, do you have a swap space (though having swap != free RAM and is an emergency measure that might lead to the symptoms you are seeing without having to invoke the OOM killer)
as for dmesg It's milliseconds since system boot time, see/use
dmesg -T
journalctl -kto have them converted.
Offline
If you're running OOM all bets are generally off and that message is basically telling you that some Qt lib had a fault in memory trying to use ressources that aren't there. How much RAM do you have how much gets used, do you have a swap space (though having swap != free RAM and is an emergency measure that might lead to the symptoms you are seeing without having to invoke the OOM killer)
as for dmesg It's milliseconds since system boot time, see/use
dmesg -T journalctl -kto have them converted.
The mechine's memory is 15231MiB and OOM do not occur when pause happen. I did not set swap partition when installing Arch, ram is enough for me.
OK, thanks. Then `dmesg` seems not match the timestamp.
Last edited by zayn7lie (2023-07-11 11:53:18)
Offline
post the journal […] and an estimated timeframe when those stalls happened.
There's clearly something happening.
The mechine's memory is 15231MiB and OOM do not occur when pause happen. I did not set swap partition when installing Arch, ram is enough for me.
1. no amount of RAM protects you against an OOM, a broken enough process or kernel module can suck away hundreds of gigabytes in no time.
2. did you actively monitor the RAM? How exactly? How do RAM and CPU behave during those stalls?
3. https://chrisdown.name/2018/01/02/in-de … -swap.html - you don't need a partition, a swapfile is gonna do.
Offline
seth wrote:post the journal […] and an estimated timeframe when those stalls happened.
There's clearly something happening.
The mechine's memory is 15231MiB and OOM do not occur when pause happen. I did not set swap partition when installing Arch, ram is enough for me.
1. no amount of RAM protects you against an OOM, a broken enough process or kernel module can suck away hundreds of gigabytes in no time.
2. did you actively monitor the RAM? How exactly? How do RAM and CPU behave during those stalls?
3. https://chrisdown.name/2018/01/02/in-de … -swap.html - you don't need a partition, a swapfile is gonna do.
Actually, every time when pause happen, RAM seems to be no error (it is about 7 G / 16 G according to the most recent pause), and there seems to be no error of cpu as the posts I have mentioned above.
Thanks for correcting my misunderstanding of SWAP! I have set a swapfile according to https://wiki.archlinux.org/title/Swap and I will test for next several days.
# swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 8G 0B -2Last edited by zayn7lie (2023-07-11 12:37:21)
Offline
there seems to be no error of cpu
I'm not talking about errors, but about load & temperature.
as the posts I have mentioned above.
Please be aware that you've so far just been providing vague assertions about the situation, https://bbs.archlinux.org/viewtopic.php?id=57855
As long as you want to effectively deal with this by yourself that's kinda fine, but you're forcing everyone else to poke around in darkness, based on unreliable data.
If you want a more informed comment, you'll have to provide a complete system journal covering such incident. That's not a guarantee, but also unavoidable.
Offline
there seems to be no error of cpu
I'm not talking about errors, but about load & temperature.
as the posts I have mentioned above.
Please be aware that you've so far just been providing vague assertions about the situation, https://bbs.archlinux.org/viewtopic.php?id=57855
As long as you want to effectively deal with this by yourself that's kinda fine, but you're forcing everyone else to poke around in darkness, based on unreliable data.If you want a more informed comment, you'll have to provide a complete system journal covering such incident. That's not a guarantee, but also unavoidable.
Yes, I know. I mean nothing of cpu seems to be abnormal.
Swap is not help with this problem. This time I found another thing by directly looking through /var/log/Xorg.0.log, that seems to be the only file changed when pause happen in /var/log:
[ 43541.789] (II) AMDGPU(0): EDID vendor "SHP", prod id 5464
[ 43541.789] (II) AMDGPU(0): Using hsync ranges from config file
[ 43541.789] (II) AMDGPU(0): Using vrefresh ranges from config file
[ 43541.789] (II) AMDGPU(0): Printing DDC gathered Modelines:
[ 43541.789] (II) AMDGPU(0): Modeline "1920x1200"x0.0 317.25 1920 1968 2000 2080 1200 1203 1209 1271 -hsync -vsync (152.5 kHz eP)
[ 43541.789] (II) AMDGPU(0): Modeline "1920x1200"x0.0 317.25 1920 1968 2000 2080 1200 1203 1209 2542 -hsync -vsync (152.5 kHz e)And this is the whole log while pause happening in the last time:
$ journalctl -b
Jul 12 09:09:06 zayn7lie-acl pipewire[1414]: spa.alsa: front:1: (0 missed) impossible htimestamp diff:-3009
Jul 12 09:09:16 zayn7lie-acl dbus-daemon[945]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service>
Jul 12 09:09:16 zayn7lie-acl dbus-daemon[945]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedeskto>
Jul 12 09:09:16 zayn7lie-acl sudo[74303]: pam_systemd_home(sudo:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Jul 12 09:09:19 zayn7lie-acl sudo[74303]: zayn7lie : TTY=pts/0 ; PWD=/home/zayn7lie ; USER=root ; COMMAND=/usr/bin/dmesg
Jul 12 09:09:19 zayn7lie-acl sudo[74303]: pam_unix(sudo:session): session opened for user root(uid=0) by zayn7lie(uid=1000)
Jul 12 09:09:19 zayn7lie-acl sudo[74303]: pam_unix(sudo:session): session closed for user root
Jul 12 09:09:27 zayn7lie-acl dbus-daemon[945]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service>
Jul 12 09:09:27 zayn7lie-acl dbus-daemon[945]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedeskto>
Jul 12 09:09:27 zayn7lie-acl sudo[74312]: pam_systemd_home(sudo:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Jul 12 09:09:27 zayn7lie-acl sudo[74312]: zayn7lie : TTY=pts/0 ; PWD=/home/zayn7lie ; USER=root ; COMMAND=/usr/bin/dmesg -T
Jul 12 09:09:27 zayn7lie-acl sudo[74312]: pam_unix(sudo:session): session opened for user root(uid=0) by zayn7lie(uid=1000)
Jul 12 09:09:27 zayn7lie-acl sudo[74312]: pam_unix(sudo:session): session closed for user root
Jul 12 09:09:57 zayn7lie-acl dbus-daemon[1422]: [session uid=1000 pid=1422] Activating via systemd: service name='org.freedesktop.thumbnails.Thumbnailer1' un>
Jul 12 09:09:57 zayn7lie-acl systemd[1404]: Starting Thumbnailing service...
Jul 12 09:09:57 zayn7lie-acl tumblerd[74343]: Failed to load plugin "tumbler-odf-thumbnailer.so": libgsf-1.so.114: cannot open shared object file: No such fi>
Jul 12 09:09:57 zayn7lie-acl tumblerd[74343]: Failed to load plugin "tumbler-raw-thumbnailer.so": libopenrawgnome.so.9: cannot open shared object file: No su>
Jul 12 09:09:57 zayn7lie-acl tumblerd[74343]: Failed to load plugin "tumbler-ffmpeg-thumbnailer.so": libffmpegthumbnailer.so.4: cannot open shared object fil>
Jul 12 09:09:57 zayn7lie-acl tumblerd[74343]: Failed to load plugin "tumbler-gepub-thumbnailer.so": libgepub-0.7.so.0: cannot open shared object file: No suc>
Jul 12 09:09:57 zayn7lie-acl dbus-daemon[1422]: [session uid=1000 pid=1422] Successfully activated service 'org.freedesktop.thumbnails.Thumbnailer1'
Jul 12 09:09:57 zayn7lie-acl systemd[1404]: Started Thumbnailing service.Offline
Jul 12 09:09:06 zayn7lie-acl pipewire[1414]: spa.alsa: front:1: (0 missed) impossible htimestamp diff:-3009
Is either a symptom, what means the segment starts too late - or the cause.
Offline
After testing for months, I think this issue is happening in hardware layer.
It is possibly because of fTPM with my ROG amd laptop.
Is there any good way to disable fTPM? (There is no option of this in BIOS / UEFI)
Offline
You can blacklist tpm, https://wiki.archlinux.org/title/Kernel … acklisting
Adding "module_blacklist=tpm" to the kernel parameters will prevent the module to be loaded for sure.
Offline
You can blacklist tpm, https://wiki.archlinux.org/title/Kernel … acklisting
Adding "module_blacklist=tpm" to the kernel parameters will prevent the module to be loaded for sure.
OK, thanks.
I will test for this approach recently.
Offline
The fTPM stutter bugs "should" also be mitigated by a new enough firmware (... and/or kernel for that matter), check whether there are updates for your UEFI available.
Offline
The fTPM stutter bugs "should" also be mitigated by a new enough firmware (... and/or kernel for that matter), check whether there are updates for your UEFI available.
I have checked yet, while there are still some machines would report this kind of stutter (Here is a Youtube video discussing about this problem recently: https://www.youtube.com/watch?v=0AwwAN0ysLQ).
It seems like that happens especially on ROG motherboard and laptop?
This is the tpm info:
$ modinfo tpm
name: tpm
filename: (builtin)
license: GPL
file: drivers/char/tpm/tpm
version: 2.0
description: TPM Driver
author: Leendert van Doorn (leendert@watson.ibm.com)
parm: suspend_pcr:PCR to use for dummy writes to facilitate flush on suspend. (uint)I also found a bug report which might relate to this problem: https://bugs.archlinux.org/task/77340
But it has already fixed, then it might relate to hardware instead of linux kernel.
BTW, I will test this for days and find out whether this really solve the problem.
Last edited by zayn7lie (2023-08-10 07:10:46)
Offline
Offline
> "Hello" will become "H_e_llo"
If cron jobs are running that's normal to have desktop "stutter" if the jobs hadn't been set with a "nice" value.
perhaps i don't see the full context of the original question
Offline
No it's not. Stop shitposting.
Offline
> "Hello" will become "H_e_llo"
If cron jobs are running that's normal to have desktop "stutter" if the jobs hadn't been set with a "nice" value.
perhaps i don't see the full context of the original question
I tried. For eight excruciating posts, I tried.
It is clear this new member is not here for the same reasons are are most of the rest of us.
Banned.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
The problem still exist. I have pass "module_blacklist=tpm" to kernel parameters but I don't know whether this really block tpm:
$ journalctl -k --grep=tpm
Aug 16 19:20:43 zayn7lie-acl kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=1794e657-d6a0-446c-9067-294f7198fbb0 rw loglevel=3 quiet module_blacklist=tpm
Aug 16 19:20:43 zayn7lie-acl kernel: efi: ACPI=0xb81b0000 ACPI 2.0=0xb81b0014 TPMFinalLog=0xb817b000 SMBIOS=0xb9184000 SMBIOS 3.0=0xb9183000 MEMATTR=0xac02c018 ESRT=0xac035f18 INITRD=0xaafa9b18 RNG=0xb2e5f018 TP>
Aug 16 19:20:43 zayn7lie-acl kernel: ACPI: TPM2 0x00000000B2E9F000 00004C (v04 ALASKA A M I 00000001 AMI 00000000)
Aug 16 19:20:43 zayn7lie-acl kernel: ACPI: Reserving TPM2 table memory at [mem 0xb2e9f000-0xb2e9f04b]
Aug 16 19:20:43 zayn7lie-acl kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=1794e657-d6a0-446c-9067-294f7198fbb0 rw loglevel=3 quiet module_blacklist=tpm
Aug 16 19:20:44 zayn7lie-acl systemd[1]: systemd 254.1-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +I>
Aug 16 19:20:44 zayn7lie-acl systemd[1]: TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7->Last edited by zayn7lie (2023-08-17 00:38:43)
Offline
Offline