Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
AMD Zen/Ryzen thread (part 2)
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Wed Oct 11, 2017 4:50 pm    Post subject: Reply with quote

This looks really interesting. :D
https://www.phoronix.com/scan.php?page=news_item&px=AMD-GCC-More-Zen-Patches

Quote:
A few days back I initially wrote about a SUSE developer working on Zen tuning patches for GCC. That work has continued with more compiler patches coming for optimizing the GNU's compiler for Ryzen / Threadripper / EPYC processors.

Jan Hubicka of SUSE has continued posting more patches for tuning Zen for GCC and underlying code improvements for GCC in dealing with CPU-specific optimizations.

Among the work includes simplifying some code, avoiding 512-bit memcpy/memset for AVX-128 optimal targets, disabling Bulldozer dispatch scheduling, and better managing around CPU specific optimizations.


simplifying some code
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00272.html

avoiding 512-bit memcpy/memset for AVX-128 optimal targets:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00427.html

disabling Bulldozer dispatch scheduling:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00428.html

better managing around CPU specific optimizations:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00624.html
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5982

PostPosted: Thu Oct 12, 2017 12:40 pm    Post subject: Reply with quote

wrc1944 wrote:
I am currently arranging a pre-paid FedEx return label to return your CPU back to AMD free of charge - It will be emailed to you shortly.
Please print the label and attach it to the return package and arrange pick up or drop off through your local FedEx service centre. As soon as I receive your confirmation that your CPU is in transit, I will have the replacement part shipped out immediately.

The good part: the pre-paid cost is nice, it should be "normality" that they do that, but someone earlier report it wasn't (in France, it's not only natural, but our laws impose that, customers are protect by law against faulty per design product for 2 years, and the protection include shipping costs).

What is less good is that if you trust what they say, you have sent them confirmation of the return product Oct.6 and so they should have process Oct.6 to send you the replacement.
However this would contradict this:
Quote:
upon arrival at the AMD Returns Center, and must pass this inspection
before your warranty claim can be approved

If they need to check your cpu is ok before sending a new one, this cannot be before they have it in hands :)

I'm pointing the weak logic there, i would myself find it also "all ok, i'm happy" if i were in your case too, because even they will in real wait for my cpu to pass their tests and a few more delays, i would find it really good that they sent me pre-paid return label.
Even without french law forcing them, if you consider it: you have brought the product including its shipping costs already, if they ask you to pay shipping costs for replacement, it's like forcing you to pay 2x times shipping costs, which might have change its value in your eyes and might even let you not brought it at first.
It's a case when you are just happy that "the normality" is use, when in real, you have nothing to be happy about, as you didn't get any reward to excuse the troubles.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Thu Oct 12, 2017 2:26 pm    Post subject: Reply with quote

krinn,
Thanks for the comments. :)
I agree, they should have either shipped out an RMA, or at least replied they received my shipping confirmation email so I wouldn't sit around wondering if they even got it. Anyway, I'm reasonably happy, and will chalk it up to weekend delays and/or maybe they are having problems with maintaining enough RMA stock and are actually testing the RMA replacement cpus before they send them out, which is fine with me. I'd really hate to get an RMA chip that itself needed to be RMA'd.

However, I just got an update , which seems to say they actually tested my 1707SUT chip I sent them, and that they are going to send me a replacement, but doesn't say precisely when it will be shipped, as they say: "when your replacement product is ready to ship." Leaves one wondering if they mean only the time to package it up and drop it off at FedEx, or that they currently don't actually have any non-segfaulting post UA 1725 chips available at that RMA service center. Anyway, at least I now know I should getting a fully functional chip, and apparently won't be paying any shipping charges. :D
Oct. 12:
Quote:
This is an automatically generated email please do not reply

Product Serial# Result
______________________________________________________________

YD1700BBAEBOX 9GU4895N70046 TEST/INSPECTION PASSED

Next Steps

You will receive an Email notification when your replacement product is
ready to ship.

Best regards,

AMD Global Customer Care.

_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5982

PostPosted: Thu Oct 12, 2017 3:14 pm    Post subject: Reply with quote

wrc1944 wrote:
and are actually testing the RMA replacement cpus before they send them out, which is fine with me.

hihi i don't think anyone has anytime to do that: they produce fixed cpu and can safely assume the fixed product is ok (it should have pass their own tests already, which would be resume to test a random unit every X units produce)
I think the tests they are speaking off, are not on the new cpu, but on your "old" one. While they don't really need to actually test that what you describe is true (they are totally aware of it, and they are producing fixed cpu because of that), their tests is to check if you from your side didn't do anything stupid.
It's not because they are aware your cpu is buggy, that they will replace it if you have done silly things with it : run it at 1000000ghz, sending them a false cpu (a copy), crush it with an hammer...

So unlike what you think, you might get a fixed new cpu that need rma

For the time it should take now that your cpu has been validate, they already gave you the answer
Quote:
Once you have received this notification email and your processor(s)
pass the VM inspection, it usually takes approximately 2 business days
for your replacement part to ship. You will receive your
replacement(s) approximately 3-5 business days from the ship date from
the AMD Returns Center, depending upon your location.


Put a big cross in your calendar at Oct. 19, and start getting mad each day when you get up :D
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Thu Oct 12, 2017 4:51 pm    Post subject: Reply with quote

Yeah- I agree that what the AMD emails were referring to was the testing of my 1707SUT cpu I sent them.

Over the last few weeks I was reading on the (currently 119 page) amd.community.com Ryzen segfault thread as well as several in depth reddit.com ryzen threads, and there was discussion and a belief that AMD was indeed testing the cpus they sent out as RMA replacements on indentical mobos/systems to insure they would actually solve the problems.

That's the reason I mentioned it, and it was also postulated that was one reason for some long delays, but of course we wouldn't know that was true, or not, unless an AMD representative actually confirmed it. Not to mention there are a few reports of post week 25 RMA's still having segfault and other issues, but again those might be caused by other problems, and not the cpu, per se.

Guess I won't know until I get the RMA replacement and do my own testing, but I'm pretty optimistic and think AMD would make serious efforts to be sure they didn't send a faulty cpu out to an RMA customer.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental


Last edited by wrc1944 on Fri Oct 13, 2017 3:53 pm; edited 1 time in total
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 344

PostPosted: Thu Oct 12, 2017 5:25 pm    Post subject: Reply with quote

wrc1944 wrote:

Guess I won't know until I get the RMA replacement and do my own testing, but I'm pretty optimistic and think AMD would make serious efforts to be sure they didn't send a faulty cpu out to an RMA customer.


They are not testing lately, some users reported earlier that there was even thermal paste on cpu, but in last month seems everyone got not tested.
Let's hope u get new CPU before weekend.

Amd has just big mess: they sent to me lately:
Code:
AMD RMA# 2000241259 15-Day Reminder
This is a courtesy notice from AMD Global Customer Care with regards to
Warranty Request RMA# 2000241259. for your AMD retail packaged
 Processor(s) in a Box.


    Product         Serial#         Result
    ______________________________________________________________

    YD170XBCAEWOF  9R64481N70184      RETURN NOT RECEIVED


    Your warranty replacement processor was sent to you as part of the AMD
    Advanced Warranty Fulfillment service which is offered as a privilege
    to our warranty service, if we do not receive the original processor
    within the next 15 business days, we may not be able to continue to
    extend this privilege to you in the future.


Funny fact: when I opened new BOX - I see only black "WTF Box is empty I think" ( Box is black inside, on bottom I found another small black box with cpu a while later)

I noticed new CPU temperature is very stable, on idle it stays 29, sometimes might change to 30 or 31, with old one it was changing randomly temperature like 2 times per second from 25 to 35. Also similiar behaviour was with voltages shown in bios. Seems old one had ADHD :D
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Mon Oct 16, 2017 10:02 pm    Post subject: Reply with quote

My 1700 RMA update. I shipped my cpu on Oct.6,and AMD Service Center in Miami actually received my package Oct. 9, and I got email confirming on Oct.11.
Then, received an email on Oct. 12 saying test/inspection passed, and to expect an email saying the replacement is ready to ship.

However, I got no such email, but today (Oct 16, Mon.), my RMA arrived, and was a full retail 1700 package, including another nice Wraith cooler. A pleasant surprise. :D

So my total downtime wound up being 10 days, which included 2 weekends (non-business days), so I guess you could say that's only a six business-day turn-around. All in all, I consider this great service. The new 1700 details are:
Code:
YD1700BBM88AE

UA 1733SUS

9GY8049U70255
Diffused in USA
Made in China
Now the fun begins. For the time-being I think I'll keep C-state disabled as I've been seeing week 172x and 173x processors are still showing freezes without it disabled. First, need to get both my Gentoo installs up-to-date with the kde, kernel, and assorted other updates, and then maybe run some preliminary tests and see how it shakes out.

For anyone considering doing an RMA, my experience was great, and I'm convinced doing the testing beforehand and then detailing it for AMD support when you send in the RMA request makes a big difference.

BTW, anyone know if a Wraith cooler will fit on a Gigabyte GA-990FXA-UD3 ver.4 AM3+ motherboard running an 8320FX?

UPDATE: Just did an emerge -uDN @world which had 343 packages, including glibc, mesa, the new qt (includes the huge qtwebengine package) & all the big kde updates, plus lots of other major packages prone to segfaults, and the new RMA week 33 1700 chewed thru them at 44C. or less, no problems.

Plus, and most importantly, my main test which was gcc-7.2.0 that always had a segfault on my UA 1707 chip. This time compiled perfectly in record time, which I think in my case confirms the 1707 chip was the cause of the segfaults. :D

This was with defaults on the AGESA 1.0.0.6b BIOS which includes SMT (16 threads) & Opcache enabled, and as I mentioned I disabled C-states for the initial testing. Next round I'll enable XMP profile and fool with RAM settings. I'm happy to confirm that in my case AMD has certainly stood by its product, and its customer- I'm completely satisfied.

UPDATE 2: just updated my other Gentoo install on this box after updating to gcc-7.2.0 first. Entire 343 package @world update compiled perfectly with 7.2.0. Again the new week 33 1700 processor performed flawlessly. :D
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental
Back to top
View user's profile Send private message
mattcode
n00b
n00b


Joined: 06 Oct 2017
Posts: 3

PostPosted: Tue Oct 24, 2017 8:33 am    Post subject: Reply with quote

Shipped my CPU on the 18th of October and it was received by AMD on the 19th. It's now the 24th and I haven't heard anything at all back from AMD.

[hr]

wrc1944 wrote:
For anyone considering doing an RMA, my experience was great, and I'm convinced doing the testing beforehand and then detailing it for AMD support when you send in the RMA request makes a big difference.

What kind of testing did you detail for AMD support? I just told them I was dealing with segfaults when compiling anything and they accepted it without asking any more questions.

edit Spoke too soon. Got an email today saying that my CPU had been received by AMD, and then less than a minute later an email saying that my CPU had passed inspection (must've been a quick inspection :roll:).
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Wed Oct 25, 2017 7:23 pm    Post subject: Reply with quote

@mattcode,
I posted a summary of it at bottom of page 5. Sounds like from your experience if you just say "segfaults" and mention the week and the actual serial number of the Ryzen cpu they are now foregoing all the questions and testing they were previously requiring.

My 1733SUS is still performing perfectly, and I've enabled XMP and boosted the ram back up to 2933 from 2400 ( on my 16GB G.Skill 3200 FlareX). There are still questions and reports on at least some of the the ASrock x370 gaming K4 boards having a 2933 maximum.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5982

PostPosted: Tue Oct 31, 2017 8:06 am    Post subject: Reply with quote

Pointing Chiitoo's entry https://forums.gentoo.org/viewtopic-p-8136170.html#8136170
As it's worth reading because of the bugreport link in it for amd ryzen freezing issue. (actually it would had help more to stick this thread a few in hardware/kernel for ryzen users to not miss it)
Back to top
View user's profile Send private message
Chiitoo
Moderator
Moderator


Joined: 28 Feb 2010
Posts: 1404
Location: Here and Away Again

PostPosted: Tue Oct 31, 2017 10:05 am    Post subject: Reply with quote

Indeed, I joined in on the Ryzen fun, but got a 1700 from week 22 according to them numbers, so it's going back (I had previously contacted my supplier, and they said they have some post 25-weeklies, but that I should probably mention while ordering that it should be one of those, which I did, so someone at packaging didn't read or care, and the customer support wanted me to test it anyblue (the RMA process for me will be with my supplier, not directly with AMD)).

I mainly tested by building 'sys-devel/gcc-7.2.0', and since I knew I'd be sending it back, I didn't go for a full system re-build. The segmentation faults were fewer than I expected, but they were there. Sometimes it took several builds before they showed up, sometimes they would show up a few times in a row.

Initial thoughts were something along the lines of “wait, shouldn't I be seeing 16 penguins, instead of 12... oh yeah, I have a limit of 12 in the kernel!”, and that the single-core performance could be better, but I'm not going to complain about that as the multicore/thread goodness is quite a bit more important to me. :]

The parts I got:

- Ryzen 7 1700
- ASUS PRIME X370-A
- G.Skill 16GB (2 x 8GB) Flare X (for AMD), DDR4 3200 MHz, CL14, 1.35V
_________________
Kind Regards,
~ The Noob Unlimited ~

Sore wa sore, kore wa kore.
Back to top
View user's profile Send private message
stephan-t
Tux's lil' helper
Tux's lil' helper


Joined: 12 May 2014
Posts: 118

PostPosted: Wed Nov 01, 2017 5:17 pm    Post subject: Reply with quote

Necessary upgrade the latest tested stable GCC (from portage tree) to 6.x or 7.x???
I don't think not seat with amd64 anymore, the Ryzen based system require the newest packages just like new (Mesa, GCC, kernel, glibc)
What think about it?
Back to top
View user's profile Send private message
Gordex
n00b
n00b


Joined: 10 Jul 2008
Posts: 26

PostPosted: Sat Nov 18, 2017 4:37 pm    Post subject: Reply with quote

running a week 33 SUS Ryzen 1700 on an Asrock Taichi with GSkill Flare X 3200 1.35v cl 14 rock stable here for a while but did encounter once https://bugzilla.kernel.org/show_bug.cgi?id=196683 as well. Since running with the mentioned rcu configs everything seems fine. Not one segfault so far, so quite happy. Ran Gentoo on Phenom X2 720BE before so it's quite an upgrade :)
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 744

PostPosted: Sun Nov 19, 2017 4:54 pm    Post subject: Reply with quote

My 1700x seems to be affected by this bug too. I'd find the system either locked up or to have restarted on its own after letting it sit idle say overnight because i couldn't be bothered to shut it down. That and i had tabs open and didn't want to close them :p.
That being said i don't want to go through the hassle of being down a system as well as hoping what ever test they use at amd shows it has a problem. Also since we are so close to the release of the 12nm refresh(jan-feb) I'll just wait and get that.
_________________
"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
—Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 344

PostPosted: Sun Nov 19, 2017 8:25 pm    Post subject: Reply with quote

truekaiser wrote:
My 1700x seems to be affected by this bug too. I'd find the system either locked up or to have restarted on its own after letting it sit idle say overnight because i couldn't be bothered to shut it down. That and i had tabs open and didn't want to close them :p.
That being said i don't want to go through the hassle of being down a system as well as hoping what ever test they use at amd shows it has a problem. Also since we are so close to the release of the 12nm refresh(jan-feb) I'll just wait and get that.


gcc failure doesnt lock/restart linux. It kernel bug.
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
Saundersx
Apprentice
Apprentice


Joined: 11 Apr 2005
Posts: 219

PostPosted: Tue Nov 21, 2017 8:03 pm    Post subject: Reply with quote

Just to derail this thread a little. Would any of you recommend getting a ryzen 1800X in the current state of everything? I have an AMD8350 and I see the 1800X is on sale at newegg. But I also read (perhaps here or elsewhere) that if you ask newegg to not send you one of the known messed up chips that in true form they "can't do that". I would be a little more then angry to get some expensive silicon in the mail only to turn around and mail the goddamn right back out to AMD itself (as apparently newegg will not take it back).
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11449

PostPosted: Wed Nov 22, 2017 12:15 am    Post subject: Reply with quote

If your vendor cannot sort out chips with a known defect, and refuses to take returns on the issue, then they should not be your vendor. I cannot comment on whether Newegg acts as you describe, but if you are correct, I would not buy any Ryzen parts from them until this issue is long past. Find someone who will ship a good Ryzen, or forgo Ryzen entirely.
Back to top
View user's profile Send private message
Saundersx
Apprentice
Apprentice


Joined: 11 Apr 2005
Posts: 219

PostPosted: Wed Nov 22, 2017 2:43 am    Post subject: Reply with quote

Hu wrote:
If your vendor cannot sort out chips with a known defect, and refuses to take returns on the issue, then they should not be your vendor. I cannot comment on whether Newegg acts as you describe, but if you are correct, I would not buy any Ryzen parts from them until this issue is long past. Find someone who will ship a good Ryzen, or forgo Ryzen entirely.


https://forums.gentoo.org/viewtopic-p-8126552-highlight-newegg.html#8126552

Turns out it was this very thread, and yeah I agree.
Back to top
View user's profile Send private message
salmander
n00b
n00b


Joined: 19 Oct 2015
Posts: 4

PostPosted: Wed Nov 22, 2017 6:48 pm    Post subject: Reply with quote

Hu wrote:
If your vendor cannot sort out chips with a known defect, and refuses to take returns on the issue, then they should not be your vendor. I cannot comment on whether Newegg acts as you describe, but if you are correct, I would not buy any Ryzen parts from them until this issue is long past. Find someone who will ship a good Ryzen, or forgo Ryzen entirely.


Until now no vendor can do it because there is no official statement from amd about the week of processors is the issue.
Should I be wrong help me. I read so much because you do not know what to believe.

The Note in the Gentoo Ryzen Wiki is in my opinion wrong. Note
"....This problem should only affect the very few early Ryzen patches that were produced."

I had a very early 1700X with segfault bug i sent them back. After price drop i brought a 1800X last week and guess what.. also with segfault and it was a 25+ Processor.
I tested the ryzen kill script under ubuntu and gentoo with mesa.

So i don't believe that the week is a indicator. The Processor is now RMA and i'm waiting.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39319
Location: 56N 3W

PostPosted: Wed Nov 22, 2017 7:43 pm    Post subject: Reply with quote

salmander,

I don't think AMD know when the cutoff beteem good and bad is.
If they did, they would not screen RMA replacement processors to make sure that they are OK.

From the lack of a microcode fix, I suspect that the problem is either marginal silicon behaviour or a marginal packaging issue.
That is, it can't be fixed in the microcode.
Silicon is hard and expensive to fix, so AMD will avoid that if they can. Roll it in with the die shrink early in the new year.
The packaging can be modified though. AMD may have tweaked the packaging several times and each time the yield improved, so there may not be an identifiable cut over.

AMD admit there is a problem and accept RMAs. That's probably as good as it will get.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11449

PostPosted: Thu Nov 23, 2017 3:21 am    Post subject: Reply with quote

salmander wrote:
Hu wrote:
If your vendor cannot sort out chips with a known defect, and refuses to take returns on the issue, then they should not be your vendor. I cannot comment on whether Newegg acts as you describe, but if you are correct, I would not buy any Ryzen parts from them until this issue is long past. Find someone who will ship a good Ryzen, or forgo Ryzen entirely.
Until now no vendor can do it because there is no official statement from amd about the week of processors is the issue.
Should I be wrong help me. I read so much because you do not know what to believe.
I accept that it may be infeasible for the vendor to pre-screen the CPU for correctness, but I maintain that if they cannot screen (whether due to lack of manpower, lack of motivation, or unavailability of an adequate testing procedure) and they refuse to deal with returns, and the customer expects that "bad" Ryzen CPUs will need to be returned (rather than relegated to some low-stress task where the fault has no practical ill effect), then buying from them is setting the customer up for a hassle and the customer should avoid purchasing suspect hardware from that vendor. If there are no vendors who can either commit to prescreening or commit to a smooth return process, then that may mean not purchasing any Ryzen CPUs until either this blows over or the customer develops a tolerance for dealing with the RMA process. It's all a matter of personal preference, balancing the customer's desire for Ryzen performance at the Ryzen price-point versus the customer's tolerance for hardware that has a very reasonable chance of the first round not being suitable for its intended purpose.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5982

PostPosted: Thu Nov 23, 2017 10:39 am    Post subject: Reply with quote

I agree with Hu: if your vendor cannot handle to look if the cpu is fine or not, then don't buy from that vendor.
Why do people accept things from computer vendor they will never accept from another vendor?
"Is that ford mustang a fixed version model or a bad one with the engine bug that blow away after a month? And do you have it in red?"
"Sorry sir, i cannot tell you about the model version, but i have some in red yes"
"Ah, ok, i'll pick you one in red then".

While it is just stupid because at best you have a 50% chance to get a buggy model. In real, if the vendor is aware his model is a buggy one, it wouldn't tell you: it's only when vendor is 100% sure its model is not a buggy one that he will claim it proudly.
So for any customer, a vendor unable to answer should be taken as : incompetent and you are rolling a dice or competent and lier.

It's even worst for ryzen case, because the vendor would also tell you "if you have any problem with the car, you have to sent it back to Ford, we won't do it for you".
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Fri Nov 24, 2017 3:34 am    Post subject: Reply with quote

Tony0945 et al,
Sorry to drag up this topic again. (just want to be sure I don'r screw it up like last time) I needed to order a R5 1600/Asrock-B50 package (couldn't resist Black Friday deals!) for a new Ryzen build replacing my old Gigabyte AM3+/8320FX cpu system, which I had in June just replaced with a Ryzen R7 1700 which resulted in nightmate problems caused by the fact I didn't rebuild the AM3+ system first with CFLAGS="-march=k8 -mtune=generic -O2 -pipe" as Tony0945 suggested in the first post on the first zen part 1 thread. That was my big mistake, as well-documented on the Zen part 1 thread (pages 11-14 or so, IIRC).

Anyway, my current situation is that when I put my old AM3+ mobo with the 8320FX cpu (replacing a Phenom II 1090T amdfam10 ~amd64 system in my other Box) , it booted up fine with my multi-boot linux sata-1 drive with sda1 holding a Mint grub2 install (as the grub2 master boot loader for my Gentoo on sda8, along with several other Linux distros, and an sdb1 disk with win10 Home, and sdc1 disk with Win 10 Pro insider fast ring pre-release system.

Of course as expected, all functioned well for 4+ months or so now. This is a secondary little home office system, and I didn't think much about it as it was working fine, and gentoo ~amd64 is current and updated, in perfect order. I'm now ready to replace the AM3+ with some new Ryzen 1600 hardware.

However, when I just looked at the /etc/make.conf file I realized I had forgot to update it when I replaced the AM3 1090t board with the AM3+ 8320FX board, and for all these months the Gentoo world updates and new kernels have been going along built with:
Code:
 
CFLAGS="-march=amdfam10 -O2 -fomit-frame-pointer -pipe -ftree-vectorize -fipa-icf"
CXXFLAGS="${CFLAGS}"

CHOST="x86_64-pc-linux-gnu"
ACCEPT_KEYWORDS="~amd64"

USE="mmx sse sse2 sse3 mmxext 3dnowext 3dnow 3dnowprefetch sse4a -ipv6 semantic-desktop gnome icu nspluginwrapper -gnome -qt3support -qt4"

CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a"


I'm thinking that since this "new" AM3+ "bulldozer" type system has been rebuilding updates using -march=amdfam10 flags all along I should be almost ready to go for a successful reboot on Ryzen, but perhaps also add the -mno-fma4 -mno-tbm -mno-xop -mno-lwp flags and remove a few other of the flags such as 3dnowext 3dnow 3dnowprefetch.

However, I also just realized I have been building Gentoo kernels on this box since I installed the AM3+ mobo with "native" enabled in the kernel config instead of amdfam10 (k10), but still with "-march=amdfam10" in make.conf.

I'm not sure if the "native" gcc opts in the kernel config would detect the "bulldozer" system, and thus override and not allow the -march=amdfam10 flags in make.conf to take effect or not. As I understand it, the idea is only a bulldozer flag built system is the one that prevents a Gentoo system from booting on Ryzen AM4 hardware.

So my plan would be while the drives in this box are still using the AM3+ mobo is to build a new kernel with "k10" instead of native, and with video, ethernet, usb 3.0, 3.1, etc., and sound support for the new AM4 board, and adjust my make.conf flags to something like:

Code:
CFLAGS="-march=amdfam10 -mtune=generic -O2 -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
ACCEPT_KEYWORDS="~amd64"

USE="mmx sse sse2 sse3 sse4a -ipv6 semantic-desktop gnome icu nspluginwrapper -gnome -qt3support -qt4"

CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a"


And then do emerge -e @ system && emerge -e @world, and then I should be able to replace the AM3+ hardware with the Ryzen system board, and Gentoo grub2 should boot OK from my master Mint grub2, as usual. Then after reboot to Ryzen adjust flags again and rebuild @world with Ryzen opts.

Or, Thumper suggested recompiling some or all of their system to an apparent common denominator like ( -mtune=generic -march=x86-64 ), which makes sense to me. I'm just worried about being sure there are no "bulldozer" family conlficting flags in the rebuild before I swap I the ryzen hardware.

Anything stand out as wrong in this scenario? Except maybe Newegg is still shipping pre week 25 stock, in which case I'll immediately and hopefully be able to return it for a refund. :roll:

Update: After some more thought, I think my setting for the first rebuild before moving to Ryzen AM4 board be best set at:
Code:
 CFLAGS="-march=x86-64 -mtune=generic -O2 -fomit-frame-pointer -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp"

_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental


Last edited by wrc1944 on Fri Nov 24, 2017 7:07 pm; edited 7 times in total
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3105
Location: Gainesville, Florida

PostPosted: Fri Nov 24, 2017 5:16 am    Post subject: Reply with quote

Gordex wrote:
Quote:
running a week 33 SUS Ryzen 1700 on an Asrock Taichi with GSkill Flare X 3200 1.35v cl 14 rock stable here for a while but did encounter once https://bugzilla.kernel.org/show_bug.cgi?id=196683 as well. Since running with the mentioned rcu configs everything seems fine. Not one segfault so far, so quite happy.

I have an RMA UA 1733SUS on the AsRock x370 Gaming K4 (which is pretty much the same as a Taichi, with the rcu configs and disabled C-state, and can confirm it's rock solid. Looks like those 1733SUS are pretty reliable. :) Mine was out of Miami AMD support. Hope I don't have to RMA my new R5 1600 build (vendor is Newegg- surely they are shipping post week 25 by now. Should know in a few days). :roll:
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r3, gcc-7.2.0- kernel-4.14.5 gentoo USE=experimental


Last edited by wrc1944 on Fri Nov 24, 2017 5:34 am; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11449

PostPosted: Fri Nov 24, 2017 5:26 am    Post subject: Reply with quote

To be fair to the vendor, I wouldn't assume incompetence if they can't do this. It could be as simple as that their fulfillment process doesn't support passing the customer's instructions from the point of order all the way to the person who will pull the chip from storage and ship it. It could also be that they have made a business decision that they don't want to go to the extra trouble of passing that request and respecting it in fulfillment. However, regardless of why they cannot / will not handle that type of filtering request, if they don't handle it, then the customer risks getting a bad product and shouldering the burden of correcting it. Hence, if you strongly prefer not to deal with getting a bad CPU, you shouldn't use a non-filtering vendor.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 6 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum