View previous topic :: View next topic |
Author |
Message |
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Thu Oct 12, 2017 12:40 pm Post subject: |
|
|
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 |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Thu Oct 12, 2017 2:26 pm Post subject: |
|
|
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.
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 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11 |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Thu Oct 12, 2017 3:14 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Thu Oct 12, 2017 4:51 pm Post subject: |
|
|
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 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11
Last edited by wrc1944 on Fri Oct 13, 2017 3:53 pm; edited 1 time in total |
|
Back to top |
|
|
mir3x Guru
Joined: 02 Jun 2012 Posts: 455
|
Posted: Thu Oct 12, 2017 5:25 pm Post subject: |
|
|
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 _________________ Sent from Windows |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Mon Oct 16, 2017 10:02 pm Post subject: |
|
|
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.
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.
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. _________________ Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11 |
|
Back to top |
|
|
mattcode n00b
Joined: 06 Oct 2017 Posts: 4
|
Posted: Tue Oct 24, 2017 8:33 am Post subject: |
|
|
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 ). |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Wed Oct 25, 2017 7:23 pm Post subject: |
|
|
@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 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11 |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Tue Oct 31, 2017 8:06 am Post subject: |
|
|
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 |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2551 Location: Here and Away Again
|
Posted: Tue Oct 31, 2017 10:05 am Post subject: |
|
|
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 _________________ Kindest of regardses. |
|
Back to top |
|
|
stephan-t Tux's lil' helper
Joined: 12 May 2014 Posts: 122
|
Posted: Wed Nov 01, 2017 5:17 pm Post subject: |
|
|
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 |
|
|
Gordex n00b
Joined: 10 Jul 2008 Posts: 26
|
Posted: Sat Nov 18, 2017 4:37 pm Post subject: |
|
|
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 |
|
|
truekaiser l33t
Joined: 05 Mar 2004 Posts: 801
|
Posted: Sun Nov 19, 2017 4:54 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mir3x Guru
Joined: 02 Jun 2012 Posts: 455
|
Posted: Sun Nov 19, 2017 8:25 pm Post subject: |
|
|
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. _________________ Sent from Windows |
|
Back to top |
|
|
Saundersx Apprentice
Joined: 11 Apr 2005 Posts: 290
|
Posted: Tue Nov 21, 2017 8:03 pm Post subject: |
|
|
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 |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Wed Nov 22, 2017 12:15 am Post subject: |
|
|
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 |
|
|
Saundersx Apprentice
Joined: 11 Apr 2005 Posts: 290
|
Posted: Wed Nov 22, 2017 2:43 am Post subject: |
|
|
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 |
|
|
salmander n00b
Joined: 19 Oct 2015 Posts: 10
|
Posted: Wed Nov 22, 2017 6:48 pm Post subject: |
|
|
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 |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54096 Location: 56N 3W
|
Posted: Wed Nov 22, 2017 7:43 pm Post subject: |
|
|
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 |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Thu Nov 23, 2017 3:21 am Post subject: |
|
|
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 |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Thu Nov 23, 2017 10:39 am Post subject: |
|
|
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 |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Fri Nov 24, 2017 3:34 am Post subject: |
|
|
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.
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 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11
Last edited by wrc1944 on Fri Nov 24, 2017 7:07 pm; edited 7 times in total |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3432 Location: Gainesville, Florida
|
Posted: Fri Nov 24, 2017 5:16 am Post subject: |
|
|
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). _________________ Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11
Last edited by wrc1944 on Fri Nov 24, 2017 5:34 am; edited 1 time in total |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Fri Nov 24, 2017 5:26 am Post subject: |
|
|
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 |
|
|
|
|
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
|
|