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