upgraded to Debian Trixie now. still same issue.
I would legit pay good money for a fix to this. how do i place a bounty on a bug?
Linux 6.17, i tried the parameters to ignore ppc and tpc. No change in behavior.
i think i have ruled out rapl being the culprit. here is my rapl info when the problem is occurring.
this time it occurred at only 70C. far below the limits i7 4800MQ, this is certainly not a thermal issue.
intel-rapl
enabled: 1
Zone 0
name: package-0
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 220613382310
Constraint 0
name: long_term
power_limit_uw: 1696000000
time_window_us: 8187281408
max_power_uw: 47000000
Constraint 1
name: short_term
power_limit_uw: 1696000000
time_window_us: 8187281408
max_power_uw: 0
Zone 0:0
name: core
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 164541139015
Constraint 0
name: long_term
power_limit_uw: 1696000000
time_window_us: 8187281408
Zone 0:1
name: dram
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 207689198844
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 8187281408
UPDATE:
after finagling the /sys/class interface for rapl, i was able to load the system for little over 20 minutes without the unwanted behavior!
these are the rapl values i achieved for this.
intel-rapl
enabled: 1
Zone 0
name: package-0
enabled: 1
max_energy_range_uj: 262143328850
energy_uj: 37380215585
Constraint 0
name: long_term
power_limit_uw: 1696000000
time_window_us: 976
max_power_uw: 47000000
Constraint 1
name: short_term
power_limit_uw: 1696000000
time_window_us: 976
max_power_uw: 0
Zone 0:0
name: core
enabled: 0
max_energy_range_uj: 262143328850
energy_uj: 23413882931
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 976
Zone 0:1
name: dram
enabled: 0
max_energy_range_uj: 262143328850
energy_uj: 7817666998
Constraint 0
name: long_term
power_limit_uw: 0
time_window_us: 976
ill have to do some more testing later. as my University responsibilities need tending to.
1 Like
UPDATE: my earlier observation was a fluke. the issue happened within 10 minutes this time
I FIXED IT:
Turns out, you need the rapl nonsense i figured out the other day
AND
you need the kernel parameter âdis_ucode_ldrâ
been stressing the system for hours now. no issue!
Maybe mainline should have a quirk for this hardware?
1 Like
false alarm. it broke again today.
darn, really thought i had it that time.
somebody please help
All these years and you still have this problemâŚ
Change your distribution or see how Windows behaves on this hardware.
I also have another old laptop thatâs not very good at maintaining the set clock speed. I can force it to run at maximum speed, but it also tends to slow down for a second or two while performing tasks. Windows doesnât have this problem.
But I havenât had time to investigate this because itâs an antique machine.
1 Like
This laptop never worked with windows. The install cd always just puts a garbled mess of colors on the screen.
i guess i can try ubuntu whenever i can save up to buy another ssd for it. i am not willing to nuke my debian install.
i dont understand how i went a week without the problem showing, and now it does. ive changed nothing.
A fellow student at my university stated that this issue might be consistent with a failed battery, even on AC power.
I lack the electrical engineering knowledge to know if this avenue is worth investigating further. Replacement batteries for this laptop are not cheap.
This is the first Iâve ever heard ofâŚ
It doesnât matter if the battery is weak; you can remove it and leave the AC alone.
Either the cause is somewhere in the kernelâs specific configuration, or the BIOS is taking control and forcing certain behavior.
Install/run another OS and youâll have your answer.
Windows*/ReactOS/Linux*/*BSD/âŚ
1 Like
i am hesitant to declare victory yet. remains to be seen if this is in fact a solution, or just another false positive. but so far, these commands appear to at least make a dramatic improvement to the situation.
wrmsr --all 0x1FC 0x400000
wrmsr --all 0x610 0xffffff
wrmsr --all 0x638 0x001083e7
wrmsr --all 0x640 0x0
echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "3" > /sys/class/drm/card0/device/pp_power_profile_mode
UPDATE: this is an improvement, but the throttling still does happen. just takes longer to do so. :<
update: i believe i have narrowed down the culprit to msr register 0x19a.
I set it to 0, and everything is fine. But something mysterious writes a non-zero value to it, and causes the throttle.
Any ideas what kernel tricks i could do to remove whatever module/driver is writing to msr 0x19a?
Gonna remove the intel cpufreq and rapl drivers, hopefully reverting to the acpi frequency driver might stop these unwanted writes.
i beleive i have pinpointed the bug!
The bios sometimes writes garbage data to msr 0x19a and/or msr 0x199 when the system is under slight or heavy load. I have just a few more test cases i want to try before i confidently confirm this being the core issue.
Using a bash script, to write 0x5000 to msr 0x199 and 0x0 to msr 0x19a every second, completley negates the issue!
Question now: what is a more effective method for this as opposed to a shoddy bash script?
Is there some kernel-level trick i could do to more effeciently check for and correct garbage data in these registers?
Perhaps a dkms module could be made?
I know a systemd service would do the job, but im trying to find an approach with the least system impact as possible.
im open to ideas: whats the most performant/lightweight way to constsntly check msrâs for garbage data and overwrite when needed?
The first thing you do where it works and you donât have to touch it anymore is perfect
1 Like