Welp no change. I’m guessing the motherboard firmware already contained the latest microcode. Oh well, was worth a try, thank you.

This sounds like my best shot, thank you.

I’ve installed the amd-ucode package. It already adds microcode to the HOOKS array in /etc/mkinitcpio.conf and runs mkinitcpio -P but I’ve moved microcode before autodetect so it bundles code for all CPUs not just for the current one (to have it ready when I swap) and re-ran mkinitcpio -P. Also had to re-run grub-mkconfig -o /boot/grub/grub.cfg.

I’ve seen the message “Early uncompressed CPIO image generation successful” pass by, and lsinitcpio --early /boot/initramfs-6.12-x86_64.img|grep micro shows kernel/x86/microcode/AuthenticAMD.bin, there’s a /boot/amd-ucode.img, and an initrd parameter for it in grub.cfg. I’ve also confirmed that /usr/lib/firmware/amd-ucode/README lists an update for that new CPU (and for the current one, speaking of which).

Now from what I understand all I have to do is reboot and the early stage will apply the update?

Any idea what it looks like when it applies the microcode? Will it appear in dmesg after boot or is it something that happens too early in the boot process?

BIOS is up to date, CPU model explicitly listed as supported, memtest ran fine, not using XMP profiles.

All hardware is the same, I’m trying to upgrade from a Ryzen 3100 so everything should be compatible. Both old and new CPU have a 65W TDP.

I’m on Manjaro, everything is up to date, kernel is 6.12.17.

Memory runs at 2133 MHz, same as for the other CPU. I usually don’t tweak BIOS much if at all from the default settings, just change the boot drive and stuff like “don’t show full logo at startup”.

I’ve add some voltage readings in the post and answered some other posts here.

Everything is up to date as far as I can tell, I did Windows too.

memtest ran fine for a couple of hours, CPU stress test hang up partway through though, while CPU temp was around 75C.

RAM is indeed at 2133 MHz and the cooling is great, got a tower cooler (Scythe Kotetsu mark II), idle temps are in the low 30’s C, stress temp was 76C.

Motherboard is a Gigabyte B450 Aorus M. It’s fully updated and support for this particular CPU is explicitly listed in a past revision of the mobo firmware.

Manual doesn’t list any specific CPU settings but their website says stepping A0, and that’s what the defaults were setting. Also I got “core speed: 400 MHz”, “multiplier: x 4.0 (14-36)”.

even some normal batch cpus might sometimes require a bit more (or less) juice or a system tweak

What does that involve? I wouldn’t know where to begin changing voltages or other parameters. I suspect I shouldn’t just faff about in the BIOS and hope for the best. :/

Manjaro has no purpose, it’s half-assed at being arch and it’s half-assed at being stable.

My experience with Manjaro and Fedora, OpenSUSE etc. contradicts yours. Manjaro has the best balance between stability and rolling out of the box I’ve seen.

“Out of the box” is key here. You can tweak any distro into doing anything you want, given enough time and effort. Manjaro achieves a good balance without the user having to do anything. I remind you that I’ve tested this with non-experienced users and they have no problem using it without any admin skills (or any admin access).

Debian testing is a rolling.

It is not.

AUR isn’t a problem in Manjaro because of lack of support, it’s a problem because packages there are made with Arch and 99.999% of its derivatives in mind, aka latest packages not one week old still-broken packages.

And yet I’ve managed to install dozens of AUR packages just fine. How do you explain that?

Matter of fact, I’ve never run into an AUR package I couldn’t install on Manjaro. What package is giving you trouble?

Manjaro literally accidentally DDoSes the AUR every now and then because again they’re incompetent.

You’re being confused.

AUR had very little bandwidth to begin with and could not cope with the rise in popularity of Arch-based distros. That’s a problem that needs to be solved by the AUR repo first and foremost. Manjaro did what they could when the problem became apparent and has added caching wherever it could. Both Manjaro and Arch devs have worked together to improve this.

If Wayland is so fragile as to only work with KDE, and is not responsible for anything, how long until it’s relegated to a KDE internal subsystem?

It actually is because of Wayland design. In their quest for “security” they’ve made it impossible for automation and accesibility tools to do their job.

It’s a glaring omission in Wayland going forward, for zero gain. Most of the touted Wayland security advantages are hogwash.

I believe that rclone already has Proton Drive support.

We don’t know yet, the first frame has been rendering for the last two weeks.

Ok but it’s not called Kdeland.

Or try using any form of desktop automation… which is a show-stopper and it doesn’t look like Wayland plans to do anything about it any time soon.

There is no other Arch-based distro that strives to achieve a “rolling-stable” release.

Alternatives like Fedora have already been mentioned by other comments.

Debian testing is not a rolling release. Its package update strategy is focused on becoming the next stable so the frequency ebbs and flows around stable’s release cycle.

manjaro since it manages to be less stable than Arch specifically because of their update policy

This is false. Their delayed updates mitigate issues in latest packages. Plasma 6 was released late but it was a lot more usable, for example.

I mean why even be on Arch if you can’t use the AUR and have the latest packages?

Anybody who wants Arch should use Arch. Manjaro is not Arch.

Some of us don’t want the latest packages the instant they release, we’re fine with having them a week or a month late if it means extra stability.

There’s nothing magical about what Manjaro is doing, it stands to reason that if you delay packages even a little some bugs will be fixed.

Also you can use AUR on Manjaro perfectly fine, I myself have over 100 AUR packages installed. But AUR is not supported even by Arch so it’s impossible to offer any guarantees for it.

There’s also Flatpak and some people may prefer that since it’s more reliable.

Manjaro has been specifically designed to have fresh packages (sourced from Arch) but to be user friendly, long term stable, and provide as many features as possible out of the box.

It requires some compromises in order to achieve this, in particular it wants you to stick to its curated package repo and a LTS kernel and use it’s helper apps (package/kernel/driver manager) and update periodically. It won’t remain stable if you tinker with it.

You’ll get packages slower than Arch (depending on complexity, Plasma 6 took about two months, typically it’s about two weeks) but faster than Debian stable.

I’m running it as my main driver for gaming and work for about 5 years now and it’s been exactly what I wanted, a balanced mix of rolling and stable distro.

I’ve also given it to family members who are not computer savvy and it’s been basically zero maintenance on my part.

If it has one downside is that you really have to leave it alone to do its thing. In that regard it takes a special category of user to enjoy it — you have to either be an experienced user who knows to leave it alone or a very basic user who doesn’t know how to mess with it. The kind of enthusiastic Linux user who wants to tinker will make it fall apart and hate it, and they’d be happier on Arch or some of the other distros mentioned here.

Why do you assume they haven’t warned Mozilla in advance?

Also, Mozilla was fully aware that what they were doing is in breach of GDPR. I find it extremely hard to believe that the makers of Firefox are not fully familiarized with it by now.

Last but not least Mozilla is doing this for financial gain. It’s selling pur data to advertisers. Why should we excuse it? It’s a very hostile act.

If Mozilla has hit rock bottom and has been reduced to selling our data to survive then that’s that. We’ll find another way and another FOSS browser. Accepting it is not an option.

So what, are we giving Mozilla a free pass to do anything now? Is the new bar “not quite as shitty as Google”?

Exactly.

The reason most companies decide to contribute to FOSS is because it’s a lot more efficient to fix bugs and add/influence features upstream than to do it at your end of the code independently of everybody else.

Try using an addon like Basic Automatic Tabs Unloader, it will kill tabs completely a while after they’ve been closed. You can set the grace period as low as you want.

The Firefox native tab unloader is extremely permissive and only kills tabs when the whole system starts running low on RAM.