Date: Mon, 27 Aug 2018 21:07:34 +0800 From: Meowthink <meowthink@gmail.com> To: Mitchell <mitchell@wyatt672earp.force9.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Ryzen Build Problem Message-ID: <CABnABob%2BiCFvQhxCjJ7Uj4M6h0mffNoBox0%2BpUFWR9P4GRP9ww@mail.gmail.com> In-Reply-To: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> References: <CABnABoZA4DUOFfr7JdbbBAWxak3=ge6zX0HXtu1RffQH7tSb2Q@mail.gmail.com> <CAOa8eG4UGCo3Evz7sp7w72irtP2yb=-9-KURrvCQGu6Z-1HwVA@mail.gmail.com> <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABnABob%2BiCFvQhxCjJ7Uj4M6h0mffNoBox0%2BpUFWR9P4GRP9ww>