I found out how the AMD 7840 maps physical address to RAM chip. One RAM chip is channel A, the other is Channel B. The LSB bit of the 64 bit address selects the Channel A/B.
Oo, very nice. I can check this with the rest of my results. Thanks a bunch!
It’s less that running them disturbs a properly working one but that it causes a marginal one to fail.
Yea, this seems fair.
I am really looking forward to lpcamm, ddr5 sodimms are running pretty close to the limit even if they are working, those traces are just too damn long.
I wish consumer CPUs/memory would get ECC by default. Doubt that’s going to happen anytime soon.
Same, especially since there aren’t a whole lot of parts missing. Unfortunately it seems like you can’t have ecc in lpcamm and you can’t have lpddr in camm (that can have ecc) so that sucks. From the 2 I personally would go with lpddr but sucks that you have to choose.
Quick update: Framework support recently asked me to reset the mainboard by pressing the center button 10 times, which I did, but the random restarts are still happening. I also tried removing the internal Wi-Fi adapter and using a USB dongle, but that didn’t help either.
Although I’ve already run memtest86+ overnight twice without any issues, I might try it again given all the recent focus on RAM testing. However, since Framework said they’d escalate this issue, I expected more concrete feedback on the logs I submitted—instead, I’ve only received more general troubleshooting steps.
At this point, I’ve exhausted most options on my end, and everything still suggests a hardware or mainboard fault. Hoping they’ll take the next step soon. I’ll keep everyone posted.
Hi, I think we have a discussion for the same issue on this post. I ran through a roughly two months process with Framework support for diagnostic, leading to a mainboard replacement.
The point is that it could be barely anything before the mainboard - so you have to test everything to come to the conclusion of a faulty mainboard.
To help, I gave a summary of the steps I went through here.
Hopping this could help you find faster what you have, and eventually shorter the support processes.
I did some more investigation. I’m a bit stumped.
In my case, either of the RAM chips alone in either memory slot works just fine, hours of memtest86+ with no problems.
But if I plug both of them in at the same time, I start seeing the memtest86+ errors reported similar to those previously reported. I had the laptop running much more stably by blacklisting some of the memory addresses, but it ended up being temporary workaround (as in, it just doesn’t work anymore, at least not with the address ranges I put in).
Another update: Framework finally sent me a replacement mainboard, and I’ve been using it for a few days with the new mainboard without any random restarts.
I just got my replacement mainboard fitted too, early days but so far so good.
@James3 posted some interesting info about the EC firmware in my thread about the same crashing issue; just cross-posting for anyone else following along: Framework 13 AMD Hard Crashing Issue - #20 by James3
Edit: still crashing with the replacement mainboard 
Edit2: not crashing with my 5600MHz now fitted 
My AMD 13 7840U seems to have developed the same issue. Random reboots which can happen any time, though much more likely during heavy loads.
During light loads it can be weeks between reboots. During heavy loads I would guess it’s typically around two or three hours on average before it reboots or locks up.
journalctl gives no indications about any issue. Memtest86+ and ectool panicinfo does not indicate that anything is wrong.
@Paul_Brown: Quite interested to hear how things turn out with the motherboard replacement. Did you do anything to directly implicate the motherboard or was it simply that you had ruled out everything else?
I quite like the laptop overall, but the fact that it can randomly decide to throw away my work is of course not welcome