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

Goto page Previous  1, 2, 3 ... 19, 20, 21, 22  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
wrc1944
Advocate
Advocate


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

PostPosted: Sun Aug 27, 2017 6:04 pm    Post subject: Reply with quote

On my backup AM3+ FX 8320 box, I compiled gcc-7.2.0 and moved to it from 7.1 when it appeared in my @world updates, and am running it normally.

However, on the two Gentoo systems on my Ryzen/AM4 box, I can't compile gcc-7.2.0 ( get Internal compiler error, MCE errors, and segfaults even with ASLR and Opcache disabled, and SMT disabled or not). No thermal issues. Also failed to compile kernel 4.12.9 until I disabled ASLR. It's curious that previously I had not run into these problems, but they have started to appear in the last 2-3 weeks, including an occasional random freeze and/or lockup, even when idle.

After reading a myriad of long detailed threads on the subject (including on the week of the Ryzen cpu manufacture and RMA's) It's become obvious I'm now suffering from the same problems. From what some Ryzen owners are saying, the AMD RMA process is quite involved in that they make you file a ticket and go through various AMD ordered testing and detailed time consuming questioning and otherwise "proving" to them you actually have a problem.

Then you have to hope you are RMA'd a cpu from at least week 25 of manufacture, which according to all those getting that far, may or may not work. Some have even done multiple RMA's and still not resolved the problems, along with weeks of downtime on the specific box.

Not the ideal situation, to say the least. I was going to RMA, but for now guess I'll just see if I can get along with the bios tweaks, and wait until AMD issues a real fix and/or a new stepping, hopefully in a few months, and RMA then, (if still possible). To be fair, there are reports of some RMA chips not having the problems, but it seems pretty random.

This seems to be more of a problem for us Gentoo users, or anyone who needs to do a lot of compiling. BTW, anyone have any thoughts/experience on the LLC settings in the bios to help in this (mentioned as a possible aid in reducing problems.

Bottom line: In my opinion AMD needs to be doing Ryzen RMA's for anyone having a week 30 2017 or earlier chip, no questions asked, and immediate shipment. Or even expand that to any week chip manufactured and sold BEFORE they announce a definitive and guaranteed resolution, with a detailed explanation as to the real cause of the problem.

Come on, AMD. We bought these chips and paid in good faith expecting that they actually worked well for the intended purpose. For users doing heavy compiling, this is not working out. Constant segfaults, freezes, and random ICE's render Ryzen problematic for Gentoo users.
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
fcl
n00b
n00b


Joined: 31 Dec 2016
Posts: 67

PostPosted: Sun Aug 27, 2017 7:02 pm    Post subject: Reply with quote

Disabling OPCache helped some on my Ryzen 1600 but I still had occasional segfaults. Running memory at default 2133 helped a bit further. Upgrading to gcc-7.2 got rid of almost all segfaults. It's still not 100% stable so I'm buying a new chip. I made a deal with a vendor and they're willing to make sure that they send a CPU that's manifactured after week 25. I can't be bothered to RMA the current CPU so I'm selling it to my buddy (he doesn't use Linux much and ~never compiles stuff such as mesa/gcc).

A bit bothersome.. but I do like the performance of Ryzen so that's that. :?
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Sun Aug 27, 2017 7:20 pm    Post subject: Reply with quote

For idle freezes in kernel:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

It seems im quite lucky that gcc7.1 is flawless for me :D ( just chrome doesnt like gcc7 ...)
I tested gcc7.2 with aslr disabled but it changes nothing for me. Maybe there is some option in gcc to stop agreesive memory usage ?

EDIT: ill try gcc 7.2 wihtout -pipe
_________________
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: 3092
Location: Gainesville, Florida

PostPosted: Sun Aug 27, 2017 7:38 pm    Post subject: Reply with quote

fcl,
Interesting about your gcc-7.2.0 experience. So far, I can't get 7.2 to compile on both Ryzen systems. I was thinking maybe it wasn't possible yet to compile 7.2 on Ryzen systems yet, but your comment gives me new hope. :)

Guess I'll try temporarily dropping my GSkill 3200 Flare memory down to 2133 along with disabled ALSR, SMT, and OPcache and maybe even setting -j1 or j-2 in make.conf and see if I can get 7.2 on the Ryzen systems. I also read that with ASLR disabled, enabling SMT actually was better than disabled. Who knows without trying it yourself.

From what I read on a huge 240 page thread last night, even week 25 chips are still basically a crap shoot. All those comments by people really testing out these chips didn't give me much confidence about week 25. One guy said they sent him a week 30, but I think I'll hold off for at least 2 more months, unless AMD issues an announcement all is fixed in post week (whatever ) chips.

BTW, for several kernel versions now I have set:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

That was before my problem started to really show up big time. I need more info on the LLC options, and also read about disabling C states might help. The quest continues. :roll:

If anyone else has gcc-7.2.0 running on their Ryzen system, please post and offer some tips.
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
Chewi
Developer
Developer


Joined: 01 Sep 2003
Posts: 856
Location: Edinburgh, Scotland

PostPosted: Sun Aug 27, 2017 7:55 pm    Post subject: Reply with quote

mir3x wrote:
For idle freezes in kernel:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

I'm hoping this won't be necessary from 4.12 onwards. There's a fix in there that looks like a very likely candidate but I haven't verified this yet.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Sun Aug 27, 2017 7:57 pm    Post subject: Reply with quote

wrc1944,

AMD won't announce a fix. That's the same as announcing that some Ryzen CPUs are faulty.
That would be met with demands for a recall.
It won't happen, look how hard Intel resisted a recall of the Pentiums with the FDIV bug.

If you want to go down the RMA path, may as well get started.
_________________
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
Naib
Watchman
Watchman


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

PostPosted: Sun Aug 27, 2017 8:22 pm    Post subject: Reply with quote

wrc1944 wrote:
fcl,
Interesting about your gcc-7.2.0 experience. So far, I can't get 7.2 to compile on both Ryzen systems. I was thinking maybe it wasn't possible yet to compile 7.2 on Ryzen systems yet, but your comment gives me new hope. :)

Guess I'll try temporarily dropping my GSkill 3200 Flare memory down to 2133 along with disabled ALSR, SMT, and OPcache and maybe even setting -j1 or j-2 in make.conf and see if I can get 7.2 on the Ryzen systems. I also read that with ASLR disabled, enabling SMT actually was better than disabled. Who knows without trying it yourself.

From what I read on a huge 240 page thread last night, even week 25 chips are still basically a crap shoot. All those comments by people really testing out these chips didn't give me much confidence about week 25. One guy said they sent him a week 30, but I think I'll hold off for at least 2 more months, unless AMD issues an announcement all is fixed in post week (whatever ) chips.

BTW, for several kernel versions now I have set:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

That was before my problem started to really show up big time. I need more info on the LLC options, and also read about disabling C states might help. The quest continues. :roll:

If anyone else has gcc-7.2.0 running on their Ryzen system, please post and offer some tips.
thats odd... gcc-7.2 compiles fine here oO

Code:
gcc -v && emerge gcc -va
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 7.2.0 p1.1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (Gentoo 7.2.0 p1.1)

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   *] sys-devel/gcc-7.2.0:7.2.0::gentoo  USE="cxx fortran (multilib) nls nptl openmp pch sanitize ssp vtv (-altivec) (-awt) -cilk -debug -doc (-fixed-point) (-gcj) -go -graphite (-hardened) (-jit) (-libssp) -mpx -objc -objc++ -objc-gc (-pie) -regression-test -vanilla" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No]



did you go 7.1 -> 7.2 or were you on 6.x -> 7.2 ?
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
thumper
Guru
Guru


Joined: 06 Dec 2002
Posts: 506
Location: Venice FL

PostPosted: Sun Aug 27, 2017 9:15 pm    Post subject: Reply with quote

Chewi wrote:
mir3x wrote:
I tried gcc 6.4 and 7.2 and im getting internal compilers errors there.
( I dont get any when using 7.1 ) ...

Interesting, I ran into an issue that was broken with 7.1 but worked with 7.2. What a mess! Just to add to the fun, after finding issues with 4.12, I updated to the latest 4.11 and have started seeing segfaults there too. This is starting to get very annoying.

I also hear from Phoronix that newer chip revisions don't have these problems. If they don't find a way around these issues soon, they could be looking at mass replacements.


My system had seemed to run fine without any issues for some time, and segfaults are now showing up randomly on bigger build runs, my observations are similar to yours, I was wondering if the recent change in the stack guard pages had any thing to do with it, then I realized I'm grasping at straws and starting to worry there may really be a problem with the CPU.

George
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sun Aug 27, 2017 9:22 pm    Post subject: Reply with quote

thumper wrote:
Chewi wrote:
mir3x wrote:
I tried gcc 6.4 and 7.2 and im getting internal compilers errors there.
( I dont get any when using 7.1 ) ...

Interesting, I ran into an issue that was broken with 7.1 but worked with 7.2. What a mess! Just to add to the fun, after finding issues with 4.12, I updated to the latest 4.11 and have started seeing segfaults there too. This is starting to get very annoying.

I also hear from Phoronix that newer chip revisions don't have these problems. If they don't find a way around these issues soon, they could be looking at mass replacements.


My system had seemed to run fine without any issues for some time, and segfaults are now showing up randomly on bigger build runs, my observations are similar to yours, I was wondering if the recent change in the stack guard pages had any thing to do with it, then I realized I'm grasping at straws and starting to worry there may really be a problem with the CPU.

George
Im in a similar boat to you (but have not had any segfaults...) its high load linux users that are aggravating something yet I am not seeing it ... every stresstest I see I go and try because I am concerned I have an issue because this seems more of a fundamental thing than a batch thing.

every report and post gets me nervous to a point where I might just by a 2nd gen ryzen7 to replace this 1st gen ryzen5 once a new stepping is released (then sell this chip)
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Chewi
Developer
Developer


Joined: 01 Sep 2003
Posts: 856
Location: Edinburgh, Scotland

PostPosted: Sun Aug 27, 2017 9:26 pm    Post subject: Reply with quote

There does seem to be a common theme here, most of us had managed to work around the issues for a while and they've only just started coming back. I haven't done a full world update since mid-June. It's only since updating the kernel or possibly GCC that I've started seeing issues again. I'd need to go back to 4.11.6 to fully convince myself but it looks as though the problematic change is something that was introduced in 4.12 and backported to 4.11. Incidentally the fix I mentioned above is one such change.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


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

PostPosted: Sun Aug 27, 2017 11:31 pm    Post subject: Reply with quote

I just tried to compile gcc-7.2.0 yet again, with ASRL, OPcache disabled, and with SMT (enabled or disabled) doesn't solve it. Got a segfault again, but the last error was one I hadn't seen before:
Code:
make: *** [Makefile:22521: bootstrap-lean] Error 2

Here's the relevant two parts of the output that might offer clues for those with more knowledge than I have:
Code:
ap_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=ctype_members.lo -g -march=native -O2 -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp -D_GNU_SOURCE -c ctype_members.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o ctype_members.o
In file included from /var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.h:2013:0,
                 from /var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/locale:41,
                 from /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/libstdc++-v3/src/c++11/locale-inst.cc:38,
                 from /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/libstdc++-v3/src/c++11/wlocale-inst.cc:35:
/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.tcc: In member function '_InIter std::money_get<_CharT, _InIter>::_M_extract(std::money_get<_CharT, _InIter>::iter_type, std::money_get<_CharT, _InIter>::iter_type, std::ios_base&, std::ios_base::iostate&, std::string&) const [with bool _Intl = true; _CharT = wchar_t; _InIter = std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >]':
/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.tcc:136:7: internal compiler error: Segmentation fault[
       money_get<_CharT, _InIter>::
       ^~~~~~~~~~~~~~~~~~~~~~~~~~
0xb1810f crash_signal
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/toplev.c:337
0xb5a4d0 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:653
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
0xbde337 ao_ref_base(ao_ref*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-alias.c:1171
0xbde337 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-alias.c:1417
0xbe00b3 stmt_may_clobber_ref_p_1(gimple*, ao_ref*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-alias.c:2302
0xbe019a stmt_may_clobber_ref_p(gimple*, tree_node*)
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-alias.c:2316
0xc5af07 compute_avail
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-pre.c:3947
0xc5e499 execute
        /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/gcc/tree-ssa-pre.c:5095
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[6]: *** [Makefile:558: wlocale-inst.lo] Error 1
make[6]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11'
Making all in filesystem
make[6]: Entering directory '/var/tmp/portage/sys-devel/gcc-7.2.0/

SKIPPED BUNCH OF LINES

r/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -I/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-thread-c++0x.lo -g -march=native -O2 -pipe -mno-fma4 -mno-tbm -mno-xop -mno-lwp -D_GNU_SOURCE -std=gnu++11 -c /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc -o compatibility-thread-c++0x.o >/dev/null 2>&1
make[6]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src'
make[5]: *** [Makefile:641: all-recursive] Error 1
make[5]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src'
make[4]: *** [Makefile:510: all-recursive] Error 1
make[4]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3'
make[3]: *** [Makefile:417: all] Error 2
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3'
make[2]: *** [Makefile:14393: all-stage2-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.2.0/work/build'
make[1]: *** [Makefile:22306: stage2-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



EDIT: Naib, , I was on gcc-7.1.0 (happily, I might add) and 7.2 showed up in @world updates.

Grasping at straws here, but anyone tried compiling 7.2 with a 4.13-rc kernel?
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


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

PostPosted: Mon Aug 28, 2017 2:42 am    Post subject: Reply with quote

For anyone wishing a source of info generated by Ryzen users, here's that actively ongoing " gcc segmentation faults on Ryzen / Linux" 248 page thead from amd:

https://community.amd.com/thread/215773?start=15&tstart=0

Some Gentoo users there too, plus lots of detailed testing results/discussions by lots of very seriously dedicated AMD users. I'm learning some good stuff.
This thread should yield some really good info soon because a lot of users who already RMA'd will be updating us with their new testing results.

User udamanfunks is kindly archiving info in a nice spreadsheet: https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


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

PostPosted: Mon Aug 28, 2017 4:13 pm    Post subject: Reply with quote

I'm really disgusted with this situation and AMD's lack of explanation. Then I saw this picture: http://www.phoronix.com/image-viewer.php?id=amd-tr-1950x&image=amd_tr1950x_1_lrg Made in China. All my good AMD's were fabbed in Dresden. Some people are reported AMD as cooperative in RMA, others are complaining they have to jump through hoops. Then besides the seg fault problem there is the random freeze problem. I'm really glad I was too busy yesterday to finalize my order at Newegg. Today I decided to buy a Kabylake instead, then I found that I have to start a search for a suitable heat sink all over again. Maybe I'll just wait for coffeeelake. Maybe I'll just stick with the old Athlon II. It's slow but it doesn't crash when I build and it doesn't freeze randomly. AMD hasn't been worth spit since they hired that CEO who destroyed Motorola Semiconductor. Maybe if they hadn't fired Jim Keller, Zen would actually work.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4445

PostPosted: Mon Aug 28, 2017 5:12 pm    Post subject: Reply with quote

I'm really glad I resisted the temptation to buy one of these at launch, but then again after the hardware issues of first-gen FX and Phenom chips I was pretty much expecting a trainwreck here too. I could wait for a Ryzen 2 but at this point I'd rather abandon x86 entirely, it's becoming a choice between malice or incompetence.
_________________
*.ebuild // /etc/service/*
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


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

PostPosted: Mon Aug 28, 2017 7:39 pm    Post subject: Reply with quote

Ant P. wrote:
I'm really glad I resisted the temptation to buy one of these at launch, but then again after the hardware issues of first-gen FX and Phenom chips I was pretty much expecting a trainwreck here too. I could wait for a Ryzen 2 but at this point I'd rather abandon x86 entirely, it's becoming a choice between malice or incompetence.


I had no problems with my Newcastle and Manchester chips, nor the Phenom II or Athlon II. The old 32bit K6-3+ is still running 32bit and not that slow without X11. Even NT runs decently on it, albeit not as fast an XP on the Phenom II. XP only uses two of the six cores, showing how brain dead Micro$oft is (recognixes six cores, never uses more than two). I think because Windoze is so damn slow that Ryzen doesn't get worked hard and thus doesn't crash, AMD could really care less about the problems. As for freezing, on Windoze how can you tell? BTW, see a pattern there? When Keller and the old Alpha gang were designing the chips they were powerful and good. When new management got cheaper engineers they got what they paid for.

If you abandon x86 where can you go? Arm is interesting but so slow you need distcc to build.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4445

PostPosted: Mon Aug 28, 2017 8:20 pm    Post subject: Reply with quote

Tony0945 wrote:
XP only uses two of the six cores, showing how brain dead Micro$oft is (recognixes six cores, never uses more than two).

It's Windows XP, it comes from an era where SMP meant a captive audience with deep pockets. Those other cores can be enabled for the low low price of several hundred dollars, which gets you a slightly different product key that allows the "OS is expensive version" registry key to be set without it deliberately bricking itself. (Completely real thing - regedit.exe will pop up a big scary error if you try to flip that bit!)
_________________
*.ebuild // /etc/service/*
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


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

PostPosted: Mon Aug 28, 2017 10:36 pm    Post subject: Reply with quote

After realizing I foolishly forgot to disable 'Cool 'n Quite, I did so but again gcc-7.2.0 failed to compile, same segfault after about 15 minutes, but saw less warnings before that happened.

I then decided to try a toolchain rebuild:
Code:
emerge -1 gcc binutils libtool glibc linux-headers portage

My Ryzen system (memory dropped to 2400, with disabled Cool 'n Quite, Opcache and ASRL) smoothly completed all six packages, including gcc-7.1.0-r1 in just under 30 minutes. Thermals never went above 42-44C.
(Actually, during all the previous 7.2 failures temps have never gotten over 45C.)

Very perplexing, but makes me think since gcc-7.1.0-r1 and glibc presented no problem, my system should be capable of compiling 7.2.0, unless the problem actually is a buggy 7.2.0, or I need a specific kernel and/or bios option or setting enabled or altered. I read on another thread that raising SOC to 1.2v fixed their segfault problem, but my bios doesn't let me change it (unless I'm just missing the technique to do so)

@fci,
Since you've gotten gcc-7.2.0 installed and are using it, can you think of any kernel/bios options you needed that seemed like others might be missing?

Any info is greatly appreciated.
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental


Last edited by wrc1944 on Wed Aug 30, 2017 6:40 pm; edited 1 time in total
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Tue Aug 29, 2017 2:12 pm    Post subject: Reply with quote

Quote:
I read on another thread that raising SOC to 1.2v fixed their segfault problem

Its VDDR SOC Voltage ? - for me its 0.925 default, doesn't look safe setting to 1.2.

meanwhile i tested 7.2
:if removing '-pipe' changes something - probably not, but when i disabled it i got very fast errors, so maybe enabling it reduces chance
:i compiled gcc7.2 with -O1 and used it but it still crashes.

Now i'm testing both LLC option set to 'high' ( was auto, there is also 'extreme' option but i didnt enabled it)
_________________
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: 3092
Location: Gainesville, Florida

PostPosted: Tue Aug 29, 2017 7:36 pm    Post subject: Reply with quote

mir3x,
I reviewed some general info on overclocking ryzen cpus, not that I plan on overclocking, but just in hopes of a slight tweak or two to help address the segfault issue preventing the emerge of gcc-7.2.0. Seems like the SOC default on my ASrock 370 k4 was set at 1.1, and the max on it and other boards is said to be 1.3 (unless you're on liquid nitrogen coolers), so I figured 1.2 was OK to try. Since it still didn't allow me to emerge 7.2 and I had the same segfault, guess I'll revert to auto. I noticed no increase in tmps at 1.2.

I'm still thinking it's a bug in gcc-7.2.0, but then again fcl upgraded to 7.2.0, so it's apparently possible on some Ryzen systems.
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Tue Aug 29, 2017 7:50 pm    Post subject: Reply with quote

wrc1944 wrote:
mir3x,
I reviewed some general info on overclocking ryzen cpus, not that I plan on overclocking, but just in hopes of a slight tweak or two to help address the segfault issue preventing the emerge of gcc-7.2.0. Seems like the SOC default on my ASrock 370 k4 was set at 1.1, and the max on it and other boards is said to be 1.3 (unless you're on liquid nitrogen coolers), so I figured 1.2 was OK to try. Since it still didn't allow me to emerge 7.2 and I had the same segfault, guess I'll revert to auto. I noticed no increase in tmps at 1.2.

I'm still thinking it's a bug in gcc-7.2.0, but then again fcl upgraded to 7.2.0, so it's apparently possible on some Ryzen systems.


I am thinking there is something up with gcc-7.2 as well... while gcc-7.2 compiled for me and a few emerge @world were fine... I decided to fix an ongoing issue with kicad... wxGTK would keep segfaulting... it wasn't a segfaul in dmesg but a compiler segfault

Quote:
internal compiler error: Segmentation fault


kicking off an emerge -e @system and a few other packages were popping up... I am just completing my 2nd emerge libtool glibc binutils gcc and then ill see if it was a funny with the complete toolchain. If it again occurs ill switch back to 7.1
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Wed Aug 30, 2017 9:10 am    Post subject: Reply with quote

Well a double build of the toolchain with 7.2 followed by an emerge -e @system completed fine
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


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

PostPosted: Wed Aug 30, 2017 10:11 am    Post subject: Reply with quote

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.
_________________
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.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental


Last edited by wrc1944 on Wed Aug 30, 2017 6:38 pm; edited 1 time in total
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Wed Aug 30, 2017 10:48 am    Post subject: Reply with quote

If u really want to check 7.2 then u can try that way ( i noticed that often seg fault doens't happen with -ggdb on my personal project,
it really hard to find bug then, its not ryzen specific)
compile gcc with -ggdb -O0
revert to -O2
rebuild your toolchain
test it

but its not worth time wasting.

I got 7.2, first thing i did was emerge -e system ... it failed in 374/375 package (at cmake )
then i tried emerge mesa and it failed instantly, so i reverted to 7.1.

( I wont be suprised if gcc7.2 would work perfectly with -ggdb and -O0 but it would be 20-40% performance loss, or maybe not so big ?
In most project half time is spent on automake ... my personal project with 300 files on automake compiles in more than minute, in cmake with ninja less than 10 secs ...)
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
Bloot
Tux's lil' helper
Tux's lil' helper


Joined: 10 Mar 2006
Posts: 90
Location: Barcelona

PostPosted: Wed Aug 30, 2017 1:02 pm    Post subject: Reply with quote

GCC 7.2 compiled just fine here, using GCC 6.4. My chip is a week 07 Made in China.
_________________
Portage 2.3.6 (python 3.4.5-final-0, default/linux/amd64/13.0/desktop/plasma, gcc-6.4.0, glibc-2.23-r4, 4.12.5-gentoo x86_64)
Back to top
View user's profile Send private message
Chewi
Developer
Developer


Joined: 01 Sep 2003
Posts: 856
Location: Edinburgh, Scotland

PostPosted: Wed Aug 30, 2017 7:53 pm    Post subject: Reply with quote

I haven't moved off this flaky 4.11.12 kernel yet but the behaviour I'm seeing is really starting to unsettle me. Java dies a lot. Tabs in Vivaldi occasionally die. Just now, I had git die on me, leaving it in an odd state. Trying to recover from this state made it even worse. The files mentioned here have nothing to do with what I was working on and the rename looks crazy.

Code:
$ git status                                     
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

   renamed:    media-gfx/meshlab/files/1.3.2/02_cstddef.patch -> media-gfx/meshlab/files/1.3.2/02]cstddef.patch

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

   deleted:    media-gfx/meshlab/files/1.3.2/02]cstddef.patch

Untracked files:
  (use "git add <file>..." to include in what will be committed)

   media-gfx/meshlab/files/1.3.2/02_cstddef.patch
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... 19, 20, 21, 22  Next
Page 20 of 22

 
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