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 1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Fri Sep 08, 2017 7:43 pm    Post subject: AMD Zen/Ryzen thread (part 2) Reply with quote

Split from AMD Zen/Ryzen thread --pjp

wrc1944 wrote:
Naib,
I'd sure like to know your settings that allowed you to get that far. Congrats! :) (make.conf. settings, or any bios tweaks?)

I just ran an emerge -e @ system (458 packages) after a toolchain rebuild, finished perfectly (on 7.1.0-r1) in 2 hrs and 40 min. I figured I'd clean up @system first cause I did recently update glibc and wanted to eliminate that as any possible problem.

Then once again tried gcc-7.2.0 and still got the same problem at the usual 15-20 minutes into the compile:
Code:
    -o build/rtl.o /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/rtl.c
/var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/genoutput.c: In function 'int main(int, const char**)':
/var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/genoutput.c:1039:1: internal compiler error: Segmentation fault
 }
 ^
0xb1810f crash_signal
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/toplev.c:337
0xb59727 get_ref_base_and_extent(tree_node*, long*, long*, long*, bool*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-dfa.c:571
0xbdb800 ao_ref_base(ao_ref*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-alias.c:641
0x75b948 ao_ref_from_mem
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/alias.c:298
0x75bcbc rtx_refs_may_alias_p
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/alias.c:375
0x75bf8e write_dependence_p
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/alias.c:3066
0x75c03f canon_anti_dependence(rtx_def const*, bool, rtx_def const*, machine_mode, rtx_def*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/alias.c:3090
0x112f979 check_dependence
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:1815
0x112f979 invalidate
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:1945
0x1136801 cse_insn
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:5787
0x1138b6a cse_extended_basic_block
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:6569
0x1138b6a cse_main
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:6747
0x1139376 rest_of_handle_cse
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:7567
0x1139376 execute
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/cse.c:7610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
make[3]: *** [Makefile:2597: build/genoutput.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gfortran.pod gcc.pod
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/gcc'
make[2]: *** [Makefile:4624: all-stage3-gcc] Error 2
make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build'
make[1]: *** [Makefile:22446: stage3-bubble] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build'
make: *** [Makefile:22521: bootstrap-lean] Error 2
 * ERROR: sys-devel/gcc-7.2.0::gentoo failed (compile phase):
 *   emake failed
It's obviously gcc-7.2 on Ryzen cpu and/or AM4 platforms, and/or linux//bios settings problems, as gcc-7.2.0 compiles and runs perfectly on my old AM3+ FX 8320 gigabyte system. It gives me new hope that you got 7.2 installed.



it might actually be a gcc-7.2 thing rather than ryzen. At least one confirmed regression in 7.2
https://gcc.gnu.org/ml/gcc-bugs/2017-09/msg00391.html
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Fri Sep 08, 2017 10:02 pm    Post subject: Reply with quote

wrc1944 wrote:
On the Ryzen segfault front, I was all set to RMA but now figure if we're very lucky we'll at a minimum lose power for a week or two due to the Florida hurricane ( thus no way to email with AMD or even work on my Ryzen system) , so I'll wait until I have less to worry about.

My wife's old High School chum lives in Sarasota. She said today that there is no gasoline or food in the stores and the roads are chocked with cars making it impossible to leave. Keep your head down, pal and let us know that you're OK afterward.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Thu Sep 14, 2017 10:24 am    Post subject: Reply with quote

AGESA 1.0.06b is in the works

https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update
Quote:


Motherboard vendors have begun pushing out BIOS updates for Ryzen motherboards using the AMD AGESA 1.0.0.6b revision and it's reported that it does resolve the "Performance Marginality Problem" affecting early Ryzen Linux customers.

While newer Ryzen CPUs are running great on Linux without the performance marginality problem as described by AMD, since yesterday I have begun receiving unconfirmed reports from Phoronix readers that the recent AGESA 1.0.0.6b revision does address the issue via this software update.

But unfortunately details on AGESA 1.0.0.6b are light. Most of the web pages / threads referencing AGESA 1.0.0.6b are actually inquiring about the changes to be found in this update, but few actual details on this update that has been surfacing in the past two weeks via BIOS updates.

The Performance malignity concern is PR speak for segfaults
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Thu Sep 14, 2017 10:31 am    Post subject: Reply with quote

so ...

What's been turned off or overvolted or otherwise slowed down?
_________________
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
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 455

PostPosted: Thu Sep 14, 2017 11:18 am    Post subject: Reply with quote

NeddySeagoon wrote:
so ...

What's been turned off or overvolted or otherwise slowed down?


It silently disables all cores except 1 when detects gcc running, and sets memory to 800Mhz :D Joking :D
I bet it reduces chance of segv only.

2) I enabled that ryzen k10temp v2 triple patch for gentoo-sources-4.13.2
look ok, temp is 27-33, seems too cold ?

i posted that triple patch as 1 here if anyone needs:
https://paste.pound-python.org/show/yrSldXtw8lSzzuB4ZucB/

then u can add to your conkys:
${color lightgrey}Cpu: ${hwmon 0 temp 1}°C

3) some guy wrote here https://community.amd.com/thread/215773?start=1485&tstart=0:

"4 Dual Rank Dimms on Ryzen is officially supported at 1866 MT/s. If you don't have Samsung B-Die's, then your memory compatibility will probably be a hit and miss. The only way to guarantee a B-die nowadays is to buy CL14 (not CL15, or CL16) rated DDR DIMMS rated at 3200 MT/s.

Modules Rank Clock
1 / 2 Single 2666
1 / 2 Dual 2400
3 / 4 Single 2133
3 / 4 Dual 1866
"
Is this for real ? If my bios defaults to 2400Mhz, it means my bios does it wrong ? ( i have 4 x dual rank ) Anyway i decided to test 1866 and it failed in ... 5 secs lol :D

4) I noticed my first segfault on gcc7.1 when compiling glibc 2.25-r5 ...

EDIT: corrected patch, patch -p0 < xxx.patch from /usr/src/linux

EDIT2: when compiling cpu temp max is 49, seems strange low, my nvidia 1050 on idle is 44.
_________________
Sent from Windows
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Thu Sep 14, 2017 12:06 pm    Post subject: Reply with quote

NeddySeagoon wrote:
so ...

What's been turned off or overvolted or otherwise slowed down?
Exactly...
Ill wait for the overclockers to start dissecting the new defaults.
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

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

mir3x wrote:
NeddySeagoon wrote:
so ...

What's been turned off or overvolted or otherwise slowed down?


It silently disables all cores except 1 when detects gcc running, and sets memory to 800Mhz :D Joking :D
I bet it reduces chance of segv only.

2) I enabled that ryzen k10temp v2 triple patch for gentoo-sources-4.13.2
look ok, temp is 27-33, seems too cold ?

i posted that triple patch as 1 here if anyone needs:
https://paste.pound-python.org/show/yrSldXtw8lSzzuB4ZucB/

then u can add to your conkys:
${color lightgrey}Cpu: ${hwmon 0 temp 1}°C

3) some guy wrote here https://community.amd.com/thread/215773?start=1485&tstart=0:

"4 Dual Rank Dimms on Ryzen is officially supported at 1866 MT/s. If you don't have Samsung B-Die's, then your memory compatibility will probably be a hit and miss. The only way to guarantee a B-die nowadays is to buy CL14 (not CL15, or CL16) rated DDR DIMMS rated at 3200 MT/s.

Modules Rank Clock
1 / 2 Single 2666
1 / 2 Dual 2400
3 / 4 Single 2133
3 / 4 Dual 1866
"
Is this for real ? If my bios defaults to 2400Mhz, it means my bios does it wrong ? ( i have 4 x dual rank ) Anyway i decided to test 1866 and it failed in ... 5 secs lol :D

4) I noticed my first segfault on gcc7.1 when compiling glibc 2.25-r5 ...

EDIT: corrected patch, patch -p0 < xxx.patch from /usr/src/linux

EDIT2: when compiling cpu temp max is 49, seems strange low, my nvidia 1050 on idle is 44.


Technically speaking yes... the "official" ram clock speed depending on how you populate it was stated pre-release. I remember having an argument along these lines on IRC about a month ago.
Everything over this is overclocked.

This is the major weakness in the Ryzen setup... the entire fabric of the CPU is soo dependent on high speed RAM yet the RAM interface cannot handle the higher rates and thus need overclocking
I really would not be surprised if the changes in 1.0.0.6b is around memory ... be it increasing the voltage, slowing something down. I would have like a change in the uCode but I doubt it for this.
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Thu Sep 14, 2017 2:42 pm    Post subject: Reply with quote

Naib wrote:
https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update

I love that AMD shill making light of this and saying AMD doesn't care if we go away for good. Coupled with their secrecy about the problem, I'm just trying to decide whether to buy a Kabylake or wait for the next generation of Intel. I had just bought an AMD Wraith Silent removed from a Bulldozer. Well, it can act as a backup for my K8 builds, provided it fits. It's a huge monster. Costs less than twenty bucks anyway. That may seem inconsistent with thinking of an 1800X, but I don't mind spending money if I get value from it. I hate wasting money buying parts I won't need.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20054

PostPosted: Thu Sep 14, 2017 3:32 pm    Post subject: Reply with quote

Tony0945 wrote:
Naib wrote:
https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update

I love that AMD shill making light of this and saying AMD doesn't care if we go away for good. Coupled with their secrecy about the problem, I'm just trying to decide whether to buy a Kabylake or wait for the next generation of Intel. I had just bought an AMD Wraith Silent removed from a Bulldozer. Well, it can act as a backup for my K8 builds, provided it fits. It's a huge monster. Costs less than twenty bucks anyway. That may seem inconsistent with thinking of an 1800X, but I don't mind spending money if I get value from it. I hate wasting money buying parts I won't need.
Which shill said what? I didn't see anything like that in the link.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Thu Sep 14, 2017 4:46 pm    Post subject: Reply with quote

pjp wrote:
Which shill said what? I didn't see anything like that in the link.


eydee on page 3

And then on the AMD forum, I see there isn't a problem anymore. https://community.amd.com/thread/220261

Quite different from what I read here. I trust the people here.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20054

PostPosted: Thu Sep 14, 2017 5:18 pm    Post subject: Reply with quote

Tony0945 wrote:
pjp wrote:
Which shill said what? I didn't see anything like that in the link.


eydee on page 3

And then on the AMD forum, I see there isn't a problem anymore. https://community.amd.com/thread/220261

Quite different from what I read here. I trust the people here.
Thanks. I now understand your previous comment.

Unfortunately, the shill is somewhat correct, even if AMD genuinely disagrees. As others have mentioned here, bugs aren't unusual even in chips. I don't know if the Ryzen issues are still considered "within the realm of reasonable," though I believe I read something to that effect earlier in this thread. I don't want the headaches, so I rarely if ever use a new design of anything. But when I'm ready, I'll buy AMD (assuming they're still around). Intel is just too proud of their products for the budget I allocate.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Thu Sep 14, 2017 7:58 pm    Post subject: Reply with quote

While agree that Intel is a little too prideful of their work; I am hoping the new competition that AMD is now doing will help drive the prices back down. For a long time, Intel didn't have any big competition, so I've felt that they have started slacking off on improving. Hopefully, AMD keeps the heat on and not falter after they finally release a chip that has an actual improvement.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20054

PostPosted: Fri Sep 15, 2017 4:31 am    Post subject: Reply with quote

Yes, hopefully. I may have to chloroform my inner Ebenezer when EPYC is available (although I just noticed that it may not do as well vs. Xeon as Ryzen is compared to the ix line).
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Fri Sep 15, 2017 8:18 am    Post subject: Reply with quote

so anyone able to test with a replacement cpu or you're still in rma process?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Fri Sep 15, 2017 9:12 am    Post subject: Reply with quote

pjp wrote:
Yes, hopefully. I may have to chloroform my inner Ebenezer when EPYC is available ...

Yes. I was quite willing to pay $500 for 1800X but $1,000 is a bridge too far.

Still thinking of buying a 1300 for $129 with a $100 mobo. Then if it doesn't work, I can recycle the DDR4 memory and I've only lost $229. The RMA process sounds like dentistry without anesthetic.
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 455

PostPosted: Sun Sep 17, 2017 8:37 pm    Post subject: Reply with quote

Guys, what are your compile mesa times, it really bothers me:

eg. thats mesa:
This is when i got ryzen 7 1700X ( qlop -gt mesa)

Code:
mesa: Wed Jul 19 21:37:43 2017: 152 seconds
mesa: Thu Jul 20 18:16:47 2017: 113 seconds
mesa: Thu Jul 20 18:26:17 2017: 110 seconds
mesa: Fri Jul 21 19:48:13 2017: 110 seconds
mesa: Fri Jul 21 20:18:45 2017: 117 seconds

(I think it could be gcc 5.4 with a bit older mesa, i uninstalled gcc 5.4 and 4.9 and i cannot compile them now with gcc6.3, 6.4 or 7.1 or clang,
so maybe just gcc 5.4 was much faster)

Later it was always about 240-270 for gcc7.1 and newest mesa.
Somethign like that:
Code:
mesa: Mon Aug 28 10:35:00 2017: 270 seconds
mesa: Mon Aug 28 10:39:36 2017: 262 seconds
mesa: Mon Aug 28 10:44:04 2017: 262 seconds
mesa: Mon Aug 28 10:48:33 2017: 266 seconds


but few days I changed to kernel 4.13 and now it compile time went down 40 secs for mesa without any reason ? (still gcc7.1):
Code:
mesa: Tue Sep 12 22:19:57 2017: 211 seconds
mesa: Wed Sep 13 00:55:36 2017: 213 seconds
mesa: Sun Sep 17 22:16:14 2017: 210 seconds

(I used config from 4.12, changed nothing, just oldconfig, I noticed that option RCU_NO_CB disappeared)

Also i have something strange in log with glibc:
Code:
glibc: Mon Sep 11 22:42:42 2017: 245 seconds
glibc: Tue Sep 12 20:13:00 2017: 5363 seconds   (???)
glibc: Wed Sep 13 10:56:08 2017: 435 seconds


Idk how it possible that glibc was compiling 5363 seconds... I dont recall any hardcore stressing cpu.

I checked kwin, coreutils, binutils,libreoffice, chromium compile times - they look all normal.

EIDT: i figured why gibc was so long, it was with lto, graphite and O3, but i noticed that my kdevelop started crashing when i press enter :D, so i reverted everything,
_________________
Sent from Windows
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Sun Sep 17, 2017 9:12 pm    Post subject: Reply with quote

Code:

     Fri Jun  2 14:34:21 2017 >>> media-libs/mesa-17.1.1
       merge time: 5 minutes and 55 seconds.

     Sun Jun 11 13:33:31 2017 >>> media-libs/mesa-17.1.2
       merge time: 5 minutes and 42 seconds.

     Wed Jun 21 18:35:52 2017 >>> media-libs/mesa-17.1.3
       merge time: 5 minutes and 55 seconds.

     Mon Jul  3 19:05:59 2017 >>> media-libs/mesa-17.1.4
       merge time: 5 minutes and 41 seconds.

     Mon Jul 17 19:08:17 2017 >>> media-libs/mesa-17.1.5
       merge time: 5 minutes and 16 seconds.

     Thu Aug 10 19:19:26 2017 >>> media-libs/mesa-17.2.0_rc3
       merge time: 5 minutes and 22 seconds.

     Sat Aug 12 17:36:07 2017 >>> media-libs/mesa-17.2.0_rc3
       merge time: 5 minutes and 35 seconds.

     Sat Aug 12 17:41:45 2017 >>> media-libs/mesa-17.2.0_rc3
       merge time: 5 minutes and 33 seconds.

     Sun Aug 13 12:25:49 2017 >>> media-libs/mesa-17.2.0_rc4
       merge time: 5 minutes and 29 seconds.

     Fri Aug 25 17:26:38 2017 >>> media-libs/mesa-17.2.0_rc5
       merge time: 5 minutes and 21 seconds.

     Wed Aug 30 04:53:40 2017 >>> media-libs/mesa-17.2.0_rc5
       merge time: 5 minutes and 28 seconds.

     Tue Sep  5 21:07:27 2017 >>> media-libs/mesa-17.2.0
       merge time: 38 minutes and 1 second.

     Sun Sep 10 14:10:50 2017 >>> media-libs/mesa-17.2.0
       merge time: 4 minutes and 57 seconds.

     Sun Sep 17 22:08:56 2017 >>> media-libs/mesa-17.2.0
       merge time: 4 minutes and 46 seconds.


Code:

     Fri Aug 18 15:00:27 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 6 minutes and 33 seconds.

     Mon Aug 28 13:29:23 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 6 minutes and 7 seconds.

     Tue Aug 29 18:58:27 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 6 minutes and 26 seconds.

     Tue Aug 29 20:37:46 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 6 minutes and 3 seconds.

     Wed Aug 30 03:44:56 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 23 seconds.

     Wed Aug 30 21:51:08 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 30 seconds.

     Wed Aug 30 23:06:19 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 27 seconds.

     Thu Aug 31 20:43:47 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 21 seconds.

     Fri Sep  1 17:47:56 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 21 seconds.

     Mon Sep  4 21:15:15 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 17 seconds.

     Mon Sep  4 22:26:51 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 22 seconds.

     Wed Sep  6 23:27:53 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 20 seconds.

     Thu Sep  7 00:01:16 2017 >>> sys-libs/glibc-2.25-r4
       merge time: 5 minutes and 25 seconds.

     Tue Sep 12 22:40:58 2017 >>> sys-libs/glibc-2.25-r5
       merge time: 4 minutes and 58 seconds.



any particular reason you are using gcc-5.x ? it doesn't support ryzen and you have to be very, very careful with the flags you set
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 455

PostPosted: Mon Sep 18, 2017 5:42 am    Post subject: Reply with quote

Naib wrote:

any particular reason you are using gcc-5.x ? it doesn't support ryzen and you have to be very, very careful with the flags you set


It was just new install from stage3 and I think there was 5.4 default.

Now I think I switched to 6.3 the same day and i used those flags:
-march=znver1 -O2 -pipe -mtune=broadwell -mprefer-avx128 ( Im sure I used them, i coped them from phoronix forums, so it had to be 6.3)

Later i always used only CFLAGS="-march=znver1 -O2 -pipe"
I tested that gentoo lto from github showed on phoronix for one day, but next day I reverted/reemerged everything.

Anyway its odd, especially yesterday I noticed mesa is 40secs faster now. No idea where it came from. ( no bios updates. I can think only about kernel 4.13.2)

EDIT: Naib u have that also:
Quote:
Tue Sep 5 21:07:27 2017 >>> media-libs/mesa-17.2.0
merge time: 38 minutes and 1 second.

but maybe u were doing 10 parallel mesa compilations ?
_________________
Sent from Windows
Back to top
View user's profile Send private message
vaxbrat
l33t
l33t


Joined: 05 Oct 2005
Posts: 731
Location: DC Burbs

PostPosted: Tue Sep 19, 2017 1:46 am    Post subject: Things I noticed doing a fresh 1700x install Reply with quote

I started over here and then saw this thread when it updated yesterday.

https://forums.gentoo.org/viewtopic-t-1069208-highlight-.html

I used a thumbdrive with the the July livedvd and pulled a stage 3, starting the process last Saturday after doing a burn in with memtest of Corsair 2x16 2666 DDR4 memory. As others have noted, the stage3 uses gcc-5.4.0, so I didn't know I would be getting into trouble with the segfaulting after pulling over a make.conf from one of my other boxes with CFLAGS set to -march=native. The other problem was the make.conf came from one of my FX-8350 systems so I had 3dnow and 3dnowext in the USE flags as well.

When I booted kernel 4.12.5 I saw problems with rx-480 gpu I had in there where the amdgpu module was unable to load its firmware. I went unstable to get 4.13.1 and had it manage to load the firmware. Then as it was building out enough to get an xorg-server implemented, I started to see the random segfaults (especially in mesa) but other pigs like chromium, firefox, libreoffice and the various webkits seemed to build fine. I'm using btrfs with a 1tb samsung ssd and began to notice emerge taking a woefully long time to get through filesystem intensive stuff like unpacking and install phases. Running top in another tab showed the emerge command buzzing 100% cpu when this was going on.

I went unstable to get gcc 6.4.0, set the CFLAGS to -march=znver1 and then rebuilt the kernels, python, portage, glibc and redid the mesa and x11 pieces. Booting 4.12.5 now shows the amdgpu successfully loading firmware, and now emerge is flying along again without having things slow to a crawl during unpack and install. I'm in the middle of doing an emerge -e system and have my fingers crossed that xorg-server won't go belly up when working with the amdgpu driver like it was doing before. I'm at just under 200 packages into a 1100 package emerge of system so far and have yet to see a segfault problem.
Back to top
View user's profile Send private message
vaxbrat
l33t
l33t


Joined: 05 Oct 2005
Posts: 731
Location: DC Burbs

PostPosted: Tue Sep 19, 2017 6:19 am    Post subject: emerge mesa timing Reply with quote

So far I'm about halfway through an 1100 package emerge -e system and have only run into one segfault problem with one of the gstreamers (base I think) where I had to throttle back to -j4 to get it to emerge. I interrupted to do an emerge of mesa 7.2.0 with time so you can compare. This is an ASUS Fatal1ty Gaming K4 mobo with 2x16 Corsair Vengeance 2666 memory and a 1 TB Samsung SSD on a Sata port running btrfs as the root fs.

Code:
real    6m55.775s
user    39m28.629s
sys     18m10.595s


One thing I noticed with the BIOS is that it defaulted to 2400 for the memory until I manually forced it. The before and after memtest runs I did confirm that the 2666 setting I put in did "take".

Short of pulling the cooler off of the cpu chip, is there any way to tell what week number your cpu was baked?

Code:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 1
model name      : AMD Ryzen 7 1700X Eight-Core Processor
stepping        : 1
microcode       : 0x800111c
cpu MHz         : 2200.000
cache size      : 512 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse
 sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
 aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core
 perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt
sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flus
hbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca
bugs            : fxsave_leak sysret_ss_attrs null_seg
bogomips        : 6787.53
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 455

PostPosted: Tue Sep 19, 2017 7:36 am    Post subject: Reply with quote

Rather there is no chance to tell that without removing fan.
I removed my fan 10 mins ago to check serial number ... and then i noticed thats on box also:D. Removing fan is fun.
(serial is needed for rma, amd sends some rma form after contact).

Just set everything on auto. If u encounter seg fault, recompile again, if it passed or segfaulted on another line then its faulty ...
Some ppl reported that also some cpu were faulty with 27th week.

There is also some script kill_ryzen on github to check.

Overall if it fails dont try tuning bios/kernel. Just prepare to contact Amd. There is user bloot kernel config some pages back, it segfaulted very rarely for me.
_________________
Sent from Windows
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Tue Sep 19, 2017 8:11 am    Post subject: Reply with quote

mir3x wrote:
Naib wrote:

any particular reason you are using gcc-5.x ? it doesn't support ryzen and you have to be very, very careful with the flags you set


It was just new install from stage3 and I think there was 5.4 default.

Now I think I switched to 6.3 the same day and i used those flags:
-march=znver1 -O2 -pipe -mtune=broadwell -mprefer-avx128 ( Im sure I used them, i coped them from phoronix forums, so it had to be 6.3)

Later i always used only CFLAGS="-march=znver1 -O2 -pipe"
I tested that gentoo lto from github showed on phoronix for one day, but next day I reverted/reemerged everything.

Anyway its odd, especially yesterday I noticed mesa is 40secs faster now. No idea where it came from. ( no bios updates. I can think only about kernel 4.13.2)


eww don't rely on Phoronix for the flags..

A few of us keep the gentoo wiki updated with respect to relevant infomation

https://wiki.gentoo.org/wiki/Ryzen

with GCC-5.x you need to be careful about what CFLAGS you use due to GCC not being aware of the zen core.
GCC-6.x has znver but is not optimized for zen
GCC-7.1 is <3
GCC-7.2 is causing some issues and there have been some confirmed (generic regressions )

mir3x wrote:

EDIT: Naib u have that also:
Quote:
Tue Sep 5 21:07:27 2017 >>> media-libs/mesa-17.2.0
merge time: 38 minutes and 1 second.

but maybe u were doing 10 parallel mesa compilations ?

Something like that. there are a number of users who are experiencing segfaults and I am very,very nervous that I have a faulty chip. I went for a Ryzen5 so early batch issues could be weed out the obvious issues... So far every RMA seem to be Ryzen7 so maybe AMD were being overly aggressive with increasing yield early on by pushing out chips that were "marginal" in their words
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
AlienPenguin
n00b
n00b


Joined: 08 Sep 2004
Posts: 12
Location: Pisa, Italy

PostPosted: Tue Sep 19, 2017 8:28 am    Post subject: mesa compile times Reply with quote

Hi all,

these are my mesa compilation times with gcc 4.93 (first 2) and gcc 5.4 (last) with an old i7-2600k with a samsung-evo ssd

Code:

mesa-13.0.5: Tue Mar 14 14:08:40 2017: 184 seconds
mesa-13.0.5: Tue Apr  4 09:32:49 2017: 174 seconds
mesa-17.0.6: Wed Jun  7 16:21:27 2017: 182 seconds


is there something i am missing?
i expected much better timing from the new ryzen chips...
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Tue Sep 19, 2017 10:08 am    Post subject: Reply with quote

AlienPenguin,

These are elapsed seconds. It all depends on what else was going on and your MAKEOPTS.
Post
Code:
emerge --info mesa
from both systems.
_________________
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
AlienPenguin
n00b
n00b


Joined: 08 Sep 2004
Posts: 12
Location: Pisa, Italy

PostPosted: Tue Sep 19, 2017 10:25 am    Post subject: Reply with quote

NeddySeagoon,
i do not have any ryzen system (was considering it for an upgrade though :P ) i was referring to the timings posted by other people in previous posts.

that is why i asked fro some clarifications :)
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 1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 1 of 10

 
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