You are not logged in.
Hello, I would like to help to try to understand what is happening, if you need more information let me know so I don't understand much about logs, my notebook is extremely slow when it is charging via the USB-C port (the only one available) and I have the following errors in my "dmesg":
[ 18.934408] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20240322/psargs-330)
[ 18.934481] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS02._PLD due to previous error (AE_NOT_FOUND) (20240322/psparse-529)
[ 18.938923] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.UBTC.RUCC], AE_NOT_FOUND (20240322/psargs-330)
[ 18.939013] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS02._PLD due to previous error (AE_NOT_FOUND) (20240322/psparse-529)
[ 24.088033] ucsi_acpi USBC000:00: failed to reset PPM!
[ 24.088057] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
My laptop is a Galaxy Book3 i5 1335U.
Last edited by Ilton Pfleger (2024-09-08 14:57:58)
Offline
First and foremost, quantify and identify "slow".
Compare the conditions w/ a cheap-O CPU benchmark:
time echo "scale=5000; a(1)*4" | bc -l
(Do not post the result, we all know that number - only the computation time matters)
Then see and check the status for https://wiki.archlinux.org/title/CPU_frequency_scaling
Also make sure w/ "top" that there's no rogue process when plugging the charger and check "dmesg"/"sudo journalctl -b" for kernel messages, maybe from a device going nuts.
Also if you're using anything like TLP: disable that, if the problem goes away, check its config to make sure you've not accidentally reversed the setup to go into performance mode on battery and power saving mode on external supply.
Offline
Heyy, thanks for the reply.
Regarding how slow the system animations crash and take a few seconds to open a simple console.
Output from time echo "scale=5000; a(1)*4" | bc -l:
"real 1m54.641s
user 1m53.072s
sys 0m0.007s"
Here is the output of dmesg but the only strange thing I found were the bugs with ACPI itself: https://pastebin.com/e0aJ9xqA
For the top there doesn't seem to be any abused process, the only significant thing connected is gnome-shell wayland but it seems normal to me.
Regarding the CPU governors, now that you said there is something strange here, even changing the governors it seems that the frequency at which the CPU is running remains intact, always close at minimum (400000)
Yes I use TLP, but uninstalling it doesn't solve the problem.
**One extra piece of information that I forgot to mention is that charging is extremely slow when compared to Windows.
Last edited by Ilton Pfleger (2024-09-08 14:36:51)
Offline
**One extra piece of information that I forgot to mention is that charging is extremely slow when compared to Windows.
https://bbs.archlinux.org/viewtopic.php?id=297580
Also 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Output from time echo "scale=5000; a(1)*4" | bc -l:
Please use [code][/code] tags. Edit your post in this regard.
Is that on battery or the charger and what is the result in the other condition?
even changing the governors it seems that the frequency at
Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Post the values you query for governor and frequencies wrt the conditions you tested (if the CPU isn't doing anything, it'll of course not step up)
Offline
Sorry, this is the first time I'm using the forum.
acpi_osi=! acpi_osi="Windows 2022"
This solves the charging, but does not affect performance, I already tested it before, I just commented in case it has any relation
The test was made plugged on the charger, on battery give me this results:
real 0m35.099s
user 0m34.980s
sys 0m0.003s
On Charger:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
400000
400000
400000
400000
400000
400000
400001
400000
400000
400000
400000
400000
On Battery:
**same governor
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
1128171
400000
865833
986846
560217
400000
400000
400000
651841
400000
400000
400000
Last edited by Ilton Pfleger (2024-09-08 14:56:27)
Offline
Did you read up on the fast-start problem?
What are scaling_m{ax,in}_freq in either configuration? Can you raise either and does that have any impact?
Offline
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
1300000
900000
900000
1300000
1300000
1300000
900000
900000
900000
900000
900000
900000
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
400000
400000
400000
400000
400000
400000
400000
400000
400000
400000
400000
400000
sudo echo 900000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
real 0m37.084s
user 0m36.981s
sys 0m0.008s
Yes, this seems to solve the problem, do you have any idea who could be forcing the clock to the minimum frequency on the charger?
Offline
The scaling_governor - the more interesting question is why it behaves differently on battery and AC.
https://superuser.com/questions/1420298 … at-0-4-ghz
Does the same thing not happenon windows?
Does it make a difference whether you boot w/ the charger plugged or plug it later on?
Also, once more
Did you read up on the fast-start problem?
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
This isn't somehow optional, you cannot reliably run one OS while another one is hibernating.
Offline
I'm not dual booting with Windows, it's a pure Arch installation, no, it doesn't make a difference in the order of the factors, after I changed the minimum frequency to maximum once the problem disappeared even with reboots, I have no idea what it is but everything indicates that it is resolved. Thank you very much for your attention, I've been having this problem for a few weeks now.
Offline
I though because you were making that point wrt the charging speed.
Can you try the cpu frequencies w/ some live distro (can be grml or even the install iso) to rule out some local service/setting?
Offline
This also stopped after messing with the CPU clock, this doesn't make any sense, I thought they were somehow linked to the ACPI errors that appear in dmesg (they are still there) I still think so in fact. This morning I reinstalled arch to check and everything is still fine. (It wasn't an arch problem because I already reinstalled arch several times). The only valid hypothesis that I could think of is that there could be some remnant of Windows that was left on it and by touching the clock it was erased. Well, for now I can't test it on this thing you mentioned, I'll leave the thread open for now, if the problem comes back I'll update you, I'm also curious to understand. If she doesn't come back in three weeks, I'll close her down.
Offline
I thought they were somehow linked to the ACPI errors
No, such errors are incredibly common and just let you know that every board vendor implements ACPI by poking around until windows boots.
But
only valid hypothesis that I could think of is that there could be some remnant of Windows
the entire problem w/ windows "fast-start" is that it only hibernates the system and leaves the HW in an undefined state.
If you "shut down" windows and then installed arch, you were basically installing it onto a system that was still running windows.
iow "random things can happen"
Messing around enough might have cleared that and ultimately most (all?) scaling drivers will delegate the decisions to the hardware.
So
I'll leave the thread open for now … If she doesn't come back in three weeks, I'll close her down.
is indeed the best bet.
You could try to reset the CMOS (UEFI feature or shut down and take out the battery for an hour or so), but if you're unlucky, this will just re-cause the problem
Offline