Date: Mon, 27 Aug 2018 23:30:25 +0200 From: Stefan Blachmann <sblachmann@gmail.com> To: Meowthink <meowthink@gmail.com> Cc: Mitchell <mitchell@wyatt672earp.force9.co.uk>, freebsd-hackers@freebsd.org Subject: Re: Ryzen Build Problem Message-ID: <CACc-My2%2B%2BVEWrbrAZBiavOC3L2L5Q3ARWBFaxNkX7mx8FZbatA@mail.gmail.com> In-Reply-To: <CABnABob%2BiCFvQhxCjJ7Uj4M6h0mffNoBox0%2BpUFWR9P4GRP9ww@mail.gmail.com> References: <CABnABoZA4DUOFfr7JdbbBAWxak3=ge6zX0HXtu1RffQH7tSb2Q@mail.gmail.com> <CAOa8eG4UGCo3Evz7sp7w72irtP2yb=-9-KURrvCQGu6Z-1HwVA@mail.gmail.com> <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> <CABnABob%2BiCFvQhxCjJ7Uj4M6h0mffNoBox0%2BpUFWR9P4GRP9ww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It is remarkable that AMD's list only contains "brands" like Crucial and the like, but not a single first-party-manufacturer. Why? Because the first-party-manufacturers do not sell bad memories, for simple reputation reasons. The question where all these masses of B-grade selection chips remain, which the memory manufacturers reject for use under their own brand, is an old taboo in the industry. My personal impression is that these are dumped via these third party memory module manufacturers. The typical gamer/overclocker customer unaware of this will readily explain away problems on her non-ECC systems equipped with memory chips rejected by the original manufacturer as "the usual Windows crashes". The consumers will even happily take the fancy "coolers" on the modules as "sign of quality and worthiness", whose actual function is to hide the crap inside. Thus my personal advice: Do not use memory modules from third-party-manufacturers. The time and data you lose does not justify the savings when buying stuff from B-grade-stuff remarketers. Only buy first-party-memory modules, i.e. Samsung, Hynix, Micron etc. (If you really insist on using third-party-modules, take Kingston, who have a comparatively small history of using unreliable chips compared to other "brands".) On 8/27/18, Meowthink <meowthink@gmail.com> wrote: > Hi frank, > > On 8/27/18, Mitchell <mitchell@wyatt672earp.force9.co.uk> wrote: >> >> Hi Meowthink: >> >> I'm planning a Home Build, and I came across an issue which might apply >> to your design. >> >> Some AMD CPUs are designed for Over-Clocking automatically. But when I >> investigated Memory Compatibility I saw that some Memory wasn't. > > Many Intel CPUs are turbo boost enabled, also. I think It's safe to > trust these designs. They'll communicate to memory at a steady clock > rate, which will provide by SPD chips on DIMMs. > > Ryzens are known to have compatible issues with memories. An easier > way is to choose a module which is in the qualified list, "QVL". > >> >> The "AMD Ryzen 5 2400G" looks like it can Over-Clock itself when it >> feels safe to do so. >> >> But the "Crucial 16GB DDR4-2400 EUDIMM CL17" seems to be classified as >> Server Memory, which could mean it's designed for a single speed. I >> couldn't find more details about Crucial Memory Over-Clocking. >> >> The Crucial Web Pages do feature a Help Facility which might enable you >> to check further if you input all your system details. >> > > That's a mistake months ago. What I'd care about is ECC. > I knew Ryzens (1x00) are ECC enabled. Then I was mistaken checking out > mobo's specification as Asrock didn't mention Raven Ridges (2x00G) at > that time. I thought my build with 2400G will got ECC, but sadly not. > Now Asrock say these on their website: > > - AMD Ryzen series CPUs (Raven Ridge) support DDR4 > 3200+(OC)/2933(OC)/2667/2400/2133 non-ECC, un-buffered memory* > > *For Ryzen Series CPUs (Raven Ridge), ECC is only supported with PRO CPUs. > > In the end I got my system run, but without ECC enabled. > >> I'm no expert here. This will be my first Home Build attempt and I >> haven't even started yet. You probably need a 2nd and 3rd opinion on >> this topic. I'm just hoping my contribution will prompt further comments >> from FreeBSD people with more know-how than I've got. >> >> Yours truly: Frank Mitchell >> > > You are welcome. > > Cheers, > meowthink > >> On 27/08/18 09:13, Phil Norman wrote: >>> Hi. >>> >>> I have a similar setup: Ryzen 3 and Fatal1ty X370 mini-ITX. I had some >>> trouble with instability, although my problems weren't panics, but >>> rather >>> two issues. One was random lockups (with no evidence left in logs), but >>> I >>> *think* this was down to an inadequately cooled graphics card. >>> >>> The other problem I had was with USB. I got quite a spam of log messages >>> about the USB reinitialisation. However, eventually I figured out that >>> the >>> problem didn't occur if I booted the system from a completely >>> powered-down >>> state. That is, use the physical switch on the PSU to cut power >>> entirely, >>> re-enable, then boot from that state. Since then I've had 67 days of >>> uninterrupted uptime, with no USB issues at all. >>> >>> It sounds like your problem is different, but trying a boot-from-cold >>> might >>> be worthwhile, just in case ASRock have a consistent problem in this >>> regard. >>> >>> Cheers, >>> Phil >>> >>> On 26 August 2018 at 13:20, Meowthink <meowthink@gmail.com> wrote: >>> >>>> Hello all, >>>> >>>> Recently I tried to build up a Ryzen system and run FreeBSD on it. >>>> CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (0x810f10) >>>> Mobo: Asrock Fatal1ty AB350 Gaming-ITX/ac ( with up-to-date BIOS with >>>> PinnaclePI-AM4_1.0.0.4, microcode 0x810100b ) >>>> Mem: 2x Crucial 16GB DDR4-2400 EUDIMM CL17 ( ECC Unregistered but ECC >>>> actually won't work :( ) >>>> >>>> But the system is unstable - it can't last few days even is nearly >>>> idle. System panics even at midnight. It almost panic while or after I >>>> built something large. Surprisly I didn't encourage a user program >>>> fault, bad binaries built etc., panics only. >>>> >>>> Then I tried lots of BIOS settings e.g. SMT, C6 idle current, >>>> underclock RAM, but none seems effect. >>>> It could pass memtest86 V7.5 without error, or various benchmarks >>>> under Windows. thus I think the problem is not in the hardware but >>>> software. >>>> >>>> In the mean time, I realized that the rate of irqs from xhci0 are too >>>> high - it's about 1998/s. I found [1] and tried to MFC r331665. It >>>> didn't fix the problem though, but disabling that bluetooth module >>>> stops the irq storm, after all. >>>> >>>> Then the system lasts much longer before panic. It eventually can >>>> compile ports tree, build the world, scrub the zpool, all done without >>>> annoying reboots. >>>> Then I assume this is [2] related? So I also tried cpuctl, bounding >>>> all processes to 2-7. >>>> But the problem is still there, only the chance become very low. It >>>> still panics occasionally, idling a week or stressing few hours - >>>> Stress seems to rise the chance of panic, but differently by types. >>>> Things like llvm will always build, but gcc will cause a panic per few >>>> passes. >>>> >>>> The system was 11.2 but then moved on to stable/11 (r337906 >>>> currently). I've got last 10 coredumps saved but my kernel isn't >>>> compile as debug. So I'll put some backtrace from core.txt.? in the >>>> end. >>>> >>>> Indeed I want to eliminate this problem. Could someone guide me how to >>>> figure out the problem? What should I try next? >>>> >>>> Best regards, >>>> Meowthink >>>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACc-My2%2B%2BVEWrbrAZBiavOC3L2L5Q3ARWBFaxNkX7mx8FZbatA>