9900x. Stuck on postcode 44 only during ocassional reboots

Hardware Hub Build a PC
1

Ryzen decided to welcome me with open arms…

Month ago I built a system for work.
Specs:

  • AMD’s 9900x
  • MSI x870 Tomahawk (running A3 bios… only today saw A4)
  • Kingston Fury Beast DDR5 6000 2x32GB (confirmed from AMD’s EXPO list)
  • Samsung 970 EVO Plus
  • no descrete GPU
  • beQuiet PurePower 12 PSU

Problem:
Everything works well when booted. System even seems to behave good during work (no real workload at the moment).

And then I decide to reboot. In some cases (didn’t yet figure out the precise things to trigger this) the system is stuck with post code 44 and RAM indicator led.

One thing to note is that the system isn’t shutdown, but is put to deep sleep for the perios I’m not using it.

Doesn’t seem to react to RESET. Only the 7 seconds of POWER manage to shut it down. Afterwards it works.

I tried disabling caching the training. Nothing.
I disabled EXPO, but there was a direct preset (forgot specifically where) for 6000, which set all the voltages from auto to direct values. I think it may have helped to an extent, but not really sure.

Now I decided to give XMP profile a try.

Any ideas?

2

First thing to do is to go to AMD’s webpage and download the latest chipset and graphics drivers. Code 44’s are almost always driver related.

For what it is worth, never use the drivers from a motherboard vendors support downloads when setting up a new system. Always go back to the actual manufacturer of the chip and get the latest drivers straight from them. Motherboard manufacturers are absolutely terrible at keeping their support sites up to date.

While at it, wouldn’t hurt to check if there are any newer audio, NIC, and other drivers for on board devices as well just in case. While the chipset drivers are the primary suspect and graphics the secondary for something like this, any driver that loads at boot for any device could potentially cause something like this, if it contains a bad enough bug.

So, go to Realtek for the latest ALC4080 audio drivers and 8126-CG network drivers. The Wifi card drivers would be worth updating as well, but the spec page doesn’t tell me which Wifi module it has, so you’ll have to do some investigation yourself there. Get the latest one from the hardware vendor directly and install it.

Sometimes code 44 errors are even caused by weird interactions between drivers, but since you are only using on board stuff in this build, that seems less likely, or MSI should have caught it before launch.

Back in 2016 when I first got my Nvidia Pascal Titan X, the launch drivers were great, but once the first unified drivers came out I had similar issues to this, with random Code 44’s and Code 43’s, and Nvidia didn’t fix it for almost two years :exploding_head:

All vendors have driver issues on occasion. Hopefully if that is what it is, the latest version will fix it for you, and you won’t have to wait a long time like I did.

If that is not it, it certainly does sound like a RAM issue could be the cause.

Is the exact part number of the RAM on the QVL for the motherboard? IMHO this shouldn’t be required, and can even be hard to find as RAM part numbers change so frequently, but it is one way to make sure you are using something the board maker has actually tested.

I’d go ahead and flash that latest A4 BIOS, make sure you reset BIOS to defaults and set memory to EXPO settings.

The BIOS release notes for A4 don’t specifically mention your issue (just something vague about issues with integrated graphics and hybrid graphics) but you never know. Release notes from all vendors are notoriously incomplete, and inaccurate.

After that I would boot up from a memtest USB image and test the RAM and see if it is good. Keep in mind, this will take quite a while, much longer than you’d expect, so maybe run it overnight or something.

Once you have confirmed good RAM at these settings, then - if you want to - start tweaking again, and see if that causes the issue to come back.

How many watts is that power supply? Weird stuff like this can happen with a weak PSU, but to be fair, even the smallest beQuiet PurePower 12 (550W) is probably sufficient for a system like this at stock without a discrete GPU (or other big cards installed)

Also, don’t count out something fishy going on with the SSD. If there is silent corruption and it just happens to have occurred on something related to the chipset drivers, that could also be the cause, but my bet is that it is either chipset driver, BIOS or RAM settings.

3

I can’t say for sure, but this is Linux(Fedora), and it seems to be in the interval where the OS finished shutting down and the system goes to the BIOS init process (but now I’m in doubt).

It doesn’t react to RESET. So I would assume this to not be related to OS.

By ‘code 44’ I meant (I think I need to reword the title) ‘post code 44’(on the mobo).

Yes. Even had to buy an rgb kit just to have the memory model on that list.

Yeah. I had this thought already. But want to see where XMP profile will take me.

The system is still being prepared for work (having issues making it compatible with security requirements), so that won’t be a problem.

It’s a 850w. Should be more than enough even with a gpu onboard.

I already had a problematic ssd in the past, so yeah, I understand what you’re saying.

4

Ah, yeh, that changes things.

The odd part is that I don’t see a BIOS Code 44 in the motherboard manual, so I guess it is an undocumented one, unless it is actually displaying the CPU temp, as the manual says this is what it does once fully booted instead of error codes. (look at page 63 of your manual)

So, you could actually be booting successfully, with a CPU at 44C but without display output. And that could be related to the A4 BIOS release notes having something to do with black screens and integrated graphics…

The not responding to pressing reset is weird though. I’ve never seen that before. Maybe double check if the reset switch is connected to the correct pins on the motherboard IO? It sounds like a silly thing, but it can happen to the best of us. (It’s also easy to accidentally yank those out after plugging them in when doing something else)

If the BIOS does not resolve it, just because I am curious, what kernel are you on? Could be you just need a newer kernel with more recent kernel drivers. This is a common problem for linux users when we buy latest gen hardware. The distributions just haven’t caught up with recent enough kernels to properly use our hardware yet.

Also, sometimes it is important to get more recent X11 and MESA packages. (or wayland, I suppose these days)

5

Unless it is a glitch, at which the temp sensor bugs out, I would assume that this is not a temp reading. I have been getting this code for the past two weeks.

But I do see what you mean. I also don’t see it on the manual. But I did see somewhere people speaking of 44 code. Hm, maybe it is somehow the temp…

Just now specifically checked if the reset button functions. It does.

6.13.19-200. But I did install a fresh Fedora today (although the previous installations were also Fedora 41, but with a different desktop).

I do feel that in order to capture it more precisely I would need to pay close attention to the postcodes any time I do a reboot to understand if it fails to end the Os cycle before going for a new one, or is really an os getting stuck somehow.

6

Yeah, it seems a little bit odd that it would be the same temp every single time, but during BIOS, post and boot the CPU does run at a higher power state than once fully booted, and if the boot is freezing due to not being able to start the display, maybe the CPU is remaining in that state? So the temperature range - while a little high - doesn’t seem out of question.

Is your room temperature very consistent? :sweat_smile:

Well, it was worth a check :sweat_smile:

Yep, that is a reasonable thing to do. Monitor them during power on, and see if they cycle through as expected, and then go back to 44 - OR - if they get stuck on 44 during POST.

I know you said you want to work through the RAM timing issues first, but honestly, flashing a BIOS is quick and easy. I think I’d just do that, and then commence with the RAM. At least then you know you are on the most recent configuration.

Also, just as a quick stupid thing that may or may not resolve things. Try just removing and reseating your RAM. You’d be surprised how often this actually resolves issues.

Best of luck. If I have any sudden ideas I’ll post back.

7

I can’t really tell if 44 would be a higher temp. It usually sits at 50 C. But I think I do need to pay attention to this question.

Well, I would say that its 21-22C for the past few weeks.

Yeah. I also discovered that either the iGPU or the kernel has some inconsistencies with my monitor. Just now witnessed a black screen, while the monitor indicated that there was signal, just to power off and on for it to draw the screen (I do have 3 other pcs connected to that monitor, and it never behaved like this).

I know. But I have been doing glob knows what for the past week, trying to make the system compliant for the company’s security validation tool… which involved already 3 different Fedora installations… so I’m simply out of spirit.

Yeah. That also came to my mind(forgot to mention it). No result.

Thank you for your efforts.

8

this actually sounds a lot like the issue I have been having with my own build that I put together recently. I am using the Ryzen 9900X + Asus ProArt B650 + Ubuntu 24.04

when I try to “restart” or “reboot” the system, the OS shuts down but the devices never power down and the system never boots back up

its basically exactly as described in these pages ubuntu sudo reboot does not restart the server at DuckDuckGo

I have been trying the Grub linux kernel options as described here boot - How to fix a computer that won't restart? - Ask Ubuntu

but so far no luck with anything

good luck

1 Like
9

Interesting. And how periodically you have this?

10

Nope. This is most definitely a “somehow” code. Caught it today (I very rarely reboot my system…).

I pressed RESET. The postcode goes for a second to 00, then it would seem to one of the initial codes (my eye can spot the value changing maybe 2-3 times) and then 44 (and I watched the system show the temp value as 50 before the reboot).

Verified this behavior couple of times.

Flashed the A4 (which had a a-alpha in the version, raising more concerns). Wanted to wipe the BIOS settings, but the bios flash beat me to it…

Will see where this will lead me.

I did see that the CPU was released in aug 24, so it has been more somewhere to a half a year now. Which I hoped would be enough to fix such small problems (unless this isn’t common).

My next thoughts are to ask Fedora folk if this is somehow common. If not, write to MSI support (I don’t know if AMD support will be of help).

If not. Maybe I somehow screwed up building the system (a loose cable or a hair in the cpu socket…).

On the other hand. I today finally started my working environment on 9900x. Bear God, this is a delight! 10 seconds of init instead of 60+ (and for compiling and stuff).

11

Hello @Draaksward,

Thank you for your initial share about your issue with your machine. In fact I had this issue going on also for me until I figured out what the solution is.

We have a couple of things in common - see my build :

AMD R9 9900X
MSI X870 Tomahok WiFi
Fury Beast 2x64G
2x 2TB SN850X
ThermalTake GT 850W

I run Fedora 42 and openSuSE on this machine, both are working smoothly.

Here are my thoughts :
This is a relatively new MSI board, so bugs both in hardware and software (bios) are expected.

I got code 44 displayed on the board with the memory led lit also when I rebooted my machine. According to the board manual this code indicates a problem to initialize the memory at startup. The MSI board using AMD’s bios gives a lot of flexibility to play with almost any aspect starting with voltages, timing, frequencies, thermals and many other things - this is one of the reasons why I bought this specific one.

Eariler to this happening, I changed the timing of the memory from the standard (auto) to tight, so squeeze a bit more performance out of it (was running on EXPO1 which is officially supported by Fury (K.)). To be precise I have no idea what exactly this means in terms of frequencies, voltages and timings, but it certainly changed the behavior of the memory and there was a bit perceived increase of performance without any effect of reliability - tested with memtest.

In general it seems that if a memory is tested with the board (QVL), and it is advertised to work with specific overclocking timing (in this case EXPO1) that can be read easily by the board, it will be stable - running and initializing and handling edge cases like heat. But let us not forget that stability also means that you will be able to init correctly each time repeatedly.

The nice thing about MSI giving most of AMD’s bios reference features is that you can do what I did easily, but none of MSI nor AMD nor Kingston can guarantee you if you deviate from the “spec”. They gave us flexibility as much as possible. In addition to that there is always tolerances in manufacturing the CPUs, memory and all the parts, and these can change overtime.

Resetting that feature of “effecient” timing for the memory solved the stucking at the boot.

You mentioned response to RESET - do you mean reset on the motherboard button or the button on the case ? for example in that case when I was stuck I had no access to the back and had to use the case button which is not a reset buttn - it is a power button and needs to be pressed at least 7 seconds to cutoff the power.

I suggest you start with a cleared bios setting and set your memory to its advertised speed with the recognized profiles in the bios, then if that does not work, you can tweak it to more relaxed timing and check if any work.

I also want to mention that I turned of PBO, all setting to auto, and that works like a charm given the fact that I have a water cooling (Arctic freezer 3 pro) - I tested my systems thermals and stability using OCCT on both Fedora and openSuSE.

12

Yep, I also thought it was the RAM profile. So I changed it to Standard. And, having the nature of this problem not 100% of times, at first I thought I solved it.

My best guess was that the CPU needed some additional pressure from the AiO block, so I reinstalled the cpu and tightened the screws (at my own risk). That gave me hope for some time…

But no. This is not the cpu sitting bad, nor is it EXPO. Resetting to bios defaults also did little.

The only real thing that helped was
sudo grubby --update-kernel=ALL --args='reboot=pci'

suggested at Fedora’s forums. Shuts down the system on reboot.

But I had to move to Ubuntu due to stupi…work reasons, and didn’t address the issue much (my only reboots are for updates).

Ubuntu unrolled quite a few updates past these two weeks, so I had to reboot a few times. I’m getting the impression that postcode 44 is now a constant.

Ah, case with no Reset button?
Well, I have one. And you can press it all day long. You see the reaction (postcodes start to run), but always end up on 44.

So the only thing that works is holding the Power button.

Yeah, I passed the clear bios quite a few times. No game.

Same. I did not configure anything. This is basically a stock behavior.

13

https://www.msi.com/Motherboard/MAG-X870-TOMAHAWK-WIFI/support#bios

Looks like they have a bunch of new BIOS releases including one July 18th.

1 Like
14

I’ll wait till it will settle down. But thanks, I haven’t looked at that page for a while.

15

as per this thread Ubuntu 16.04 Hanging on reboot

I set this;

# /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="reboot=warm,cold,bios,smp,triple,kbd,acpi,efi,pci,force"

after several reboots, the issue has mostly gone away.

1 Like
16

Could be the case, but I really don’t want to see what happens when trying to apply an 8 year old fix to a system, which is installed on a fully encrypted drive with work data.

17

I don’t have a solution, but I just joined this form to say I have been experiencing the exact same issue with my PC. Besides this issue, everything has been working flawlessly, I built the system the same week AMD launched the 9950X. Shutdowns, startups from cold boot, suspend—all work perfect. Reboot often gets stuck at BIOS code 44, and normally only after the system has been running for a while.

I’m running a 9950X, ASrock x870e Nova, 64G T-Create DDR5, and a 7900XTX. OS is EndeavourOS (Arch).

18

Regurgitating AI search results. Check your cpu socket for bent pins. If no bent pins, reseat your cpu. Pay attention to your air cooler or water block’s mounting pressure. Rearrange the order of your memory sticks but use the same memory slots. If it still throws hangs on postcode 44. Try small adjustment to the ram voltages. If you still throw freeze or hang on post code 44… It will most likely be your cpu… The long shot, try a different ram kit. But most likely your cpu has issues.

19

I do like that chatGPT cached all the forum advice you usually hear from people :wink:

Socket checked.
CPU (visually) checked.
CPU stress test checked.
Mounting pressure checked.
Ram checked.

Didn’t play with ram voltages, but the memory is QVL. And did reproduce the behavior on stock profile.

The wording is a bit different. You don’t freeze. You “end up” with code 44, specifically on reboots. Pressing ‘reset’ works - you can see the postocode screen going through the usual routine. But! It ends up at 44.

Yes, and this is not a “my specific unit” cpu “has issues”. This is AMD cpu line has common issues.

20

Hi, any updates to this? Having this issue with my x870 Tomahawk on bios version 7E51v1A69 (latest). Using standard profile with TEAMGROUP T-Create Expert CL30 RAM. I also have an AMD 9900X.