Ryzen 9900x. Having issues with reboot operation

Ask Fedora
1

Although I understand that this is a far shot, but I’m trying to find similarities to my case. Since I’m running Linux, Fedora in particular, being the only system (for now I’m omitting testing it on Windows), I decided to ask maybe this is common/familiar to AMD’s latest CPU lineup.

And if I don’t get any new information, I will reach out to MSI’s and AMD’s supports. And re-assembling the PC (maybe I somehow screwed up with power cables or something).

The short description would be - 6 out of 10 times my system fails to reboot, getting stuck somewhere on the initial codes (the postcode shows 44, which seems not to be a documented code, and the RAM indicator led is glowing orange). Pressing RESET does seem to give a proper RESET reaction - the postcode goes to 00, and (from what my eye has caught) a few quick codes before getting stuck on 44. Only the long POWER press solves the issue.

One thing to note is that I mostly don’t shut down the PC - it’s a work bench, so it goes to deep sleep. But I can’t prove this to be strictly related to deep sleep since I have seen it appear on regular reboots.

And now the long description.

System specs:

  • Ryzen 9900x (no overclock)
  • MSI x870 Tomahawk (I had it on the bios, with which the board shipped, the A3, and today I flashed to A4 and did a reset to defaults)
  • Kingston Fury Beast DDR5 2x32 (from AMD’s EXPO ram list, forgot the sn)
  • m2 Samsung 970 evo plus
  • Arctic AiO
  • 850w beQuiet PSU
  • No discrete GPU

The system does seem to work absolutely fine, although I haven’t done a real stress test (the one, pushing to thermalthrottle temps). It’s main use is for Java development.

Things I tried so far:

  1. Switching to different RAM profiles. There was a somehow unique profile in the BIOS settings, named “Kingston Fury DDR 5”, which directly set the voltages. For now, I didn’t try only the standard 4400.
  2. Turned off Ram Training cache.
  3. Switched the ram sticks places.

Side notes:

  1. Although this maybe just was caught by chance, but the first time I noticed this behavior when I was trying to turn off the RGB using openRGB (which didn’t work at first, so I needed to sudo rmmod spd5118 by people’s advice). I did read that it caused problems for some people, so yeah, not crossing this out. But this was basically day 2 of me building the system (and actually doing a reboot), so can’t really bind this to be the cause.
  2. I have electric tape on the ramsticks all over the RGB. Maybe that somehow introduced heat…
2

I don’t have any technical information for you but I myself have a 9950x with a x870e carbon wifi from msi. From what I gather the x870 in general has been having some bugs pop up across manufacturers, MSI is no exception. Code 44 use to be oem post memory initialization which any memory training/initializing can take several minutes. If you made changes in the bios pertaining to the memory as you’ve said, this could have triggered the initialization. I also run Fedora 41 and the only issue I run into is an occasional 40gb usb disconnect which a reboot solves. I have dual boot with windows 10 I think for my sim rig and I can tell you, Windows brings a lot of the issues out. I can’t reboot from windows otherwise it will either throw a code with no boot forcing a full power down to boot successfully again. For this reason I fully power down and power back up after the fans stop spinning and has worked well for me. Fedora has been great for me with the exception of a small but consistent micro stutter in gaming, otherwise I wouldn’t need windows at all. My system is a work/game machine as well but I do fully power down when not using it.

Have you waited a few minutes while in code 44 to see if it is indeed memory initialization and will boot? Also ensure your memory is installed in the proper slots, usually A2 and B2 but double check for your board. There is also the possibility that enabling Memory Context Restore in your bios could help improve your boots.

I would suggest looking through the msi forums below and see if you can find anyone in a similar situation. I have not registered there myself as of yet but they seem to be a good group of people and quick to help others out. You may get more direct detailed information there and of course advice as to the best bios version for your setup. Sorry I couldn’t offer more direct help.

https://forum-en.msi.com/index.php?forums/gaming-motherboards-meg-mpg-mag.122/
https://forum-en.msi.com/index.php?forums/msi-amd-boards.24/

1 Like
3

If there is a fastboot option in bios make sure it’s disabled.

4

Yeah. I also thought that its memory training. But for that I usually see code 15.

Other than that, I tried waiting for something like 5 minutes (I think). Does not seem it wants to go from that point.

Ah, so it “Linux” in some way, and not just a hardware/bios related problem.

Well. This is strange to be honest.

Yeah, this one I already witnessed. Any change, even a “disable boot from CD-ROM” causes memory training.

I did run two times already in a situation, where my wifi doesn’t boot up. And there only a power off helps. Guess x870 still need some polish.

I do wonder if b650 has those problems.

Yes, that one I also checked.

This is somehow different from memory caching? If not, I have tried both ways.

Thanks. I will. But since this is a fresh build, and a build running on Linux, I decided to go from spot, which has more checkpoints (cpu + fedora). Will give MSI forums a “Hello” :slight_smile:

You gave a good portion of info to work with. I thank you for that!

5

Although I have used MSI’s mobo’s for quite a few years, this one has a strange bios layout. Will try to see if there is (there should be, I think) such an option.

Thanks.

6

Yes memory training is for sure code 15. 44 is post memory initialization which occurs after the memory has been initialized and it would appear your not proceeding past that point. So something within your setup or the current 870 chipset gremlins are getting you. It seems like the bios updates are in a fix an issue, create an issue stage. More of the good old we pay to be the beta testers.. lol

Maybe I worded it wrong but no I don’t think linux has anything to do with it, with the very slight exception of being newer hardware as a possibility. What I was saying was when I do boot into windows is when I start seeing all the bugs others talk about. Most commonly not being able to boot windows without throwing a random error code and requiring a full power cycle to actually boot into windows. I have never had the issue with linux so that would lead me to think it is a possible driver/bios/hardware issue. Fedora has been rock solid for me, every update so far. Like I said, if I could figure out the micro stutter, I wouldn’t have one complaint. Well realistically some but they are all user fixable.

Yes Memory context restore is different from memory caching. Memory context restore preserves memory settings during shutdown and memory caching stores frequently accessed data in faster storage areas for faster access. Memory context restore is a separate setting in the bios, under the main overclocking tab in expert or advanced view if I recall correctly, if not under the advanced memory section.

For sure, makes sense to be thorough. My build is fairly fresh to me yet as well. Again linux is my main setup and has no issues compared to windows, so it makes me feel there is a driver/hardware issue going on.

7

You know, the more I look at it, the more thoughts arise in my head about me either putting the CPU upside down, or something close to that.

Or maybe this is a reminder to me to never buy a 200-300USD mobo. I usually go for MSI’s closest to top gaming board (I wanted to buy a Godlike for my home 13900K, but its eATX was a bit too much for my case).

Today I finally moved my work to this PC, and moved my Roccat mouse’s BT connection to it. Aaaand I got stutters. Once in a few minutes the cursor freezes (and zero of that with the wired Razer mouse I had hooked up while I was configuring… and I am using it right now). And this is not an antenna nor mouse issue (this mouse works flawlessly).

UPD: and after me writing this, letting the system go down to sleep for a few hours, returning, working for an hour with the wired mouse, and deciding to again switch to the Roccat mouse… worked for a few hours without any problems. This is simply not stable…

I do think that it may be a Gnome issue (somehow).

But I occasionally boot my system with “No WiFi”.

My overall thoughts are to try to do a rebuild when I’ll have time (maybe I screwed up somehow… after somewhere to 20 years of being a PC DIY guy).

I am trying to figure out an answer to such a question - is x870 a relatively NEW chipset (although google says September 20th, 2024).

Or this is a x870 versus Linux thing? I know that “you can go and try it on windows to see”, but my issues don’t seem to be constant, nor do I see a follow up to OS doing something, from where a system fails to initialize memory (or does it?).

So there are bugs? I haven’t invested time into this question yet.

Thank you. I will look into that.

8

I’d add reboot=pci to GRUB/bootloader. For me that makes reboots happen cold (mobo full power-off) and I like that it makes the reboot thorough.

reboot=efi might also do something different (pci works better for me even on UEFI).

How to add boot flags posted below: Ryzen 9900x. Having issues with reboot operation - #10 by leigh123linux

1 Like
9

As a person, who has never touched bootloader, may I ask you how to do this properly?

I have googled the “Fedora bootloader config” and by that page tried looking at the config and found a

sudo cat /boot/grub2/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
10

Try

sudo grubby --update-kernel=ALL --args='reboot=pci'

To remove

sudo grubby --update-kernel=ALL --remove-args='reboot=pci'
2 Likes
11

wow, is it the shortcut for editing kernel parametres and updating grub?

12

Not sure if it worked, but the reboot didn’t trigger. Giving an idea that the reboot part didn’t occur at all.

On the other note, I finally lost my nerve to wait till saturday to disassemble the PC…

And I think it may have been a problem with me building it. When I was installing the AiO (Arctic Freezer III) I had issues with screwing in the block (a not so good design), where one screw would catch the thread, and the order didn’t. At first I managed to screw in just one screw, making the block push the cpu at an angle (which is REALLY bad). And there was my fear that I caused damage.

But the thing was - my idle was 50C. I did google it, and people said it is normal.

Now, after re-assembling it(and looking very carefully at the socket for bent pins) and screwing the block just by feel, my idle is 39C. Which is a big “HUH”.

I also rechecked the power connectors, but those seem fine.

One thing, which also happened, is the full reset of the BIOS - the mobo re-identified (don’t know how common is this) the cpu. I mean the whole several minutes of waiting at the first start (giving me the idea that maybe I applied too much force for the cpu block and now its ded). I didn’t even touch the ram, so I assume it is running at stock 4400(or what was it).

I did a test reboot just now (after several hours of the system in deep sleep). And it didn’t get stuck. The problem is that there was never a 100% success rate of triggering the issue. So only time will tell.

The bootloader parts seems to be working. Just now I checked and saw the system fully go down and start over. Really like this approach.

Second reboot went well.

But I still can’t figure out whats going on with my mouse. The cursor just freezes for a few seconds all of a sudden. This does not affect the Corsair K100 Air, connected by BT - the moment I see the cursor freezing I see if the keyboard is fine, and it is (by pressing the Win key I both verify the BT being functional, and the UI responsive).

In parallel to that I have the wired mouse connected (wait. Can there be some case, in which Fedora/Gnome is going crazy if there are two mice connected at the same time? Although the wired one is resting near the monitor, waiting for me to unplug it).