From owner-freebsd-hackers@freebsd.org Mon Aug 27 13:07:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 942AB108902C for ; Mon, 27 Aug 2018 13:07:36 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 266918F5C1 for ; Mon, 27 Aug 2018 13:07:36 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id r69-v6so26484229oie.3 for ; Mon, 27 Aug 2018 06:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ws0UqhetKzfSmN5rtD+NVka32AFswU7HhgYBp5rkrHE=; b=IBek+LNFV24M+naKu+ZgA8Mn58uXex/hSu3p1phKCv2dQlRFyUIeUh3vxRgtgou4X6 IBC4Z8nXmAQyFrTOGKte/FHmchDIK22nYKUIanRSs9pBEyvUfz+SlJcc9Eo/h148XxBa r/wKgbo81+4cZ8KOhwXnSVs8mbTzIhppyKqzCttVsrsmmcDbWzqmLPy+rbiS98pkMg3/ nsG9MntQMn9L3mNS3KL1k6t1Cc0LL2eeBJA/QRzcQxgpbPSK8Iv2UBsyns3ONZAKPro9 Hc7a6VpPURw2UmxvRd2xovbvdvil+piDSQYuUnbkkYjqi5aY+UYN/mNcQH/42lfkd5eA tqlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ws0UqhetKzfSmN5rtD+NVka32AFswU7HhgYBp5rkrHE=; b=A+tW6BpD2avRGJMUtm6heCqWxUGenJPmfLQaXqtAMbJGqsgcVgpRjbX560WJycEFFA BKmQQv7L64zKdYHzwV2GjDRKYMZw510c2dU3KKyd9OnQjeJZoICEiwarybCQQbgfszXM A8jR0a7Se/NRTzxijLDL5fKH1HJsrTBToIPZcztL2Gx0/epJt27bVfo3v1Q6oof6NmEJ NeboCbtHanFwVidEkdaTLfVFT2tDw/ht1ZCdlHbxG2EGzMHwDR/7zPPBreIQfvQ0hpJi WR3arZL8OdzWBeHaa4hgSB4NI4CHlGY/MrTBhMn1rgiJp6pIxRyLb40jniVaAyAeXJLh nElg== X-Gm-Message-State: APzg51DckIeB9QSNLX6v9f7dKXvovcRkKytOZ1umMY0SK1QcxLe/0xBr AEtXVHGBhd6Q1EcZHkgh7be1Ku8Fr4Le/2Na8pk= X-Google-Smtp-Source: ANB0VdbJJJY5ioczeLx/9IRbfBdFjrElwz94DFVzYQhJsMXwQKwJSyDFSFGNSQ/VlRcT1qGonXFmmG/6OekK0Zj7sVs= X-Received: by 2002:aca:e510:: with SMTP id c16-v6mr13201223oih.44.1535375255088; Mon, 27 Aug 2018 06:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a54:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 06:07:34 -0700 (PDT) In-Reply-To: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> References: <32e008cf-93d3-944d-9b11-e56f1bb425ef@wyatt672earp.force9.co.uk> From: Meowthink Date: Mon, 27 Aug 2018 21:07:34 +0800 Message-ID: Subject: Re: Ryzen Build Problem To: Mitchell Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 13:07:36 -0000 Hi frank, On 8/27/18, Mitchell 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 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" >