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 ... , 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
Tony0945
Veteran
Veteran


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

PostPosted: Wed Aug 30, 2017 9:26 pm    Post subject: Reply with quote

Chewi wrote:
I haven't moved off this flaky 4.11.12 kernel yet but the behaviour I'm seeing is really starting to unsettle me.


I'm having no problems with 4.12.9 on Kaveri and K10
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 10:02 pm    Post subject: Reply with quote

4.12.5 and no probems since upgrading to gcc-6.4 from 6.3 here. This thing flies.
_________________
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 10:13 pm    Post subject: Reply with quote

It took about 10 attempts just to build 4.11.6 again. I'd never seen it so bad, it makes me wonder if the system had suddenly got into a worse state than usual. Out of curiosity, I booted into Fedora 26 on USB (4.11.8) and rebuilt the same kernel there from a chroot. Built first time, no problem.

So I'm back on 4.11.6 for now. I want to satisfy myself that this system is now as solid as it was before and that simply changing the kernel caused the issues to return. So far, so good. I only tried 4.12.0 (forgot to update the DC branch) so maybe the later versions are better. I'll see in a few days.
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 11:36 pm    Post subject: Reply with quote

I've tried every 4.12 kernel up to 4.12.9, and I also tried 4.13-rc6 which built itself as a generic x86_64 as the rc's have no gcc-opts patch. Same result, more or less ,with all as I've been reporting.

Currently tried the suggestions on page 20 of this thead, but no luck. Can it be my march=native, and/or the fact that gcc -7.2.0 always appends the -O2 flag no matter what I put in make.conf, or even if I do it on a simple command line
Code:
 CFLAGS="-march=native -O0 -ggdb" emerge gcc
it strips/changes it to
Code:
 * Fixing misc issues in configure files
 * Applying gcc-configure-texinfo.patch ...                                                                                                                           [ ok ]
 * Touching generated files
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0 ...
 * strip-flags: CFLAGS: changed '-march=native -O0 -ggdb' to '-march=native -ggdb -O2'
 * strip-flags: CXXFLAGS: changed '-march=native -O0 -ggdb' to '-march=native -ggdb -O2'
 * CFLAGS="-march=native -ggdb -O2"
 * CXXFLAGS="-march=native -ggdb -O2"
 * LDFLAGS="-Wl,-O1 -Wl,--as-needed"

Any advice? For me, this 7.2.0 emerge attempt has so far gone nowhere. :?

I'm almost ready to install gcc-6.4, select it in gcc-config, then see if I can install the one package gcc-7.2.0, and if so move to it with gcc-config, and recomplie the toolchain twice, then try emerge -E @system.
Anyone think that's worth a shot? or is it more a problem of march=native? Or a buggy gcc-7.1.0r1 appending -O2 into the emerge command?
_________________
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: Thu Aug 31, 2017 4:29 am    Post subject: Reply with quote

My problem is I can't seem to figure out why gcc strips out my -O0 flag and adds the -O2 flag back in replacing -O0, whether I'm tring to compile gcc-7.2.0 with gcc-6.4,or gcc-7.1.0-r1.

What do I have to do? Stop the compile right after it unpacks, and replace -O2 with -O0 on the cflags line in the /var/tmp/portage/sys-devel/gcc-7.2.0/work/build/makefile,
and then use FEATURES="keep-work" emerge gcc ? :roll: ( thought those days were long over- ahh the memories)

Or crazier yet, in /var/tmp/portage/sys-devel/gcc-7.2.0/temp/environment.

Maybe it's time to just forget 7.2 for now and be happy with 7.1.0-r1 and all the disabled Ryzen bios settings with no SMT and 3200mhz memory running at 2400mhz, which at least did get me through a nice full and smooth 458 package emerge -e @ system, even if it can't compile the new gcc-7.2.0 supposedly with some nice bug fixes.

Since this is my main box now, I can't see having prolonged downtime right now doing an RMA, at least until I'm totally confident all the week 30 and later replacement cpus are really fixed.
_________________
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
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1365

PostPosted: Thu Aug 31, 2017 4:44 am    Post subject: Reply with quote

With all the troubles that Ryzen is having, is deterring me on considering it. Considering my system my system just died on me, I ended up getting a Intel instead as at least those I haven't been hearing tons off issues. Then the part of where you have to run memory at 2400 when it it's rated for 3200 is not acceptable to me. The way I see it is if I am paying extra for memory rated to run at higher speeds, I expect it to be able to do that.
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Thu Aug 31, 2017 6:21 am    Post subject: Reply with quote

Quote:
wrc1944

I checked 6.4, 7.1, 7.2 and it seems they all replace -O0 with -O2.
Considering u need to disable SMT, lower mem freq to get 7.1 to work, just go for RMA ( u need to do it now or later so now could be good time).
Probably not worth wasting time trying to fix that.

EDIT: anyone tried using clang ?
Ill try today with 50 X emerge mesa :D
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
Chewi
Developer
Developer


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

PostPosted: Thu Aug 31, 2017 7:22 am    Post subject: Reply with quote

gcc is always built with -O2 because toolchain.eclass enforces it.
Code:
gcc_do_filter_flags() {
        strip-flags
        replace-flags -O? -O2
        ...

I built 7.2.0 when I was still on my stable kernel and it built first time. To be honest, I don't believe any of the claims that gcc builds broken code for Ryzen, at least since 5.4.0. Suboptimal code yes, but not broken. I think people just assumed it must be gcc because it was primarily users building from source that were getting hit.

EDIT: Sorry, I did forget about the recent issue I had where Leptonica's tests were failing. That did appear to be a bug in gcc 7.1.0's optimisations. I didn't find the precise flag that was broken but it wasn't Ryzen-specific as -march=bdver4 -mno-fma4 -mno-tbm -mno-xop -mno-lwp didn't work either. It also didn't result in a segfault, just a test failure. gcc 6.3.0 and 6.4.0 were fine. The problem was fixed in 7.2.0.
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: Thu Aug 31, 2017 8:01 am    Post subject: Reply with quote

ct85711 wrote:
With all the troubles that Ryzen is having, is deterring me on considering it. Considering my system my system just died on me, I ended up getting a Intel instead as at least those I haven't been hearing tons off issues. Then the part of where you have to run memory at 2400 when it it's rated for 3200 is not acceptable to me. The way I see it is if I am paying extra for memory rated to run at higher speeds, I expect it to be able to do that.


My R7 1700 is overclocked to 3.9GHz on all cores and my memory kit is set to 3333MHz CL14 and I have had no problems at all with kernel 4.12.5 and GCC 6.4. Asrock X370 Taichi motherboard and 2x8GB Galax 3600MHz ddr4 ram kit here.

Code:
$ emerge --info
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)
=================================================================
System uname: Linux-4.12.5-gentoo-x86_64-AMD_Ryzen_7_1700_Eight-Core_Processor-with-gentoo-2.3
KiB Mem:    16433072 total,  10546060 free
KiB Swap:    2047996 total,   2047996 free
Timestamp of repository gentoo: Wed, 30 Aug 2017 19:00:01 +0000
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.28.1 p1.0) 2.28.1
app-shells/bash:          4.3_p48-r1::gentoo
dev-lang/perl:            5.24.1-r2::gentoo
dev-lang/python:          2.7.12::gentoo, 3.4.5::gentoo
dev-util/cmake:           3.7.2::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.3::gentoo
sys-apps/openrc:          0.28::gentoo
sys-apps/sandbox:         2.10-r3::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.15-r2::gentoo
sys-devel/binutils:       2.28.1::gentoo
sys-devel/gcc:            6.4.0::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:           2.23-r4::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

localrepo
    location: /usr/local/portage
    masters: gentoo

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=znver1"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo"
CXXFLAGS="-O2 -march=znver1"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.modulix.net/gentoo/"
LANG="es_ES.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j16"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="/ 7z X a52 aac acl acpi activities alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cleartype cli consolekit corefonts cracklib crypt cups cxx dbus declarative dri dropbox dts dvd dvdr emboss encode exif fam firefox flac fortran freetype gdbm gif glamor gpm gtk iconv ipv6 iso jpeg kde kipi kwallet lcms ldap libnotify lm_sensors lzma mad mng modules mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qml qt3support qt4 qt5 rar readline sdl seccomp semantic-desktop session spell ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis widgets wxwidgets x264 x265 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2 mmxext sse3 aes avx avx2 fma3 popcnt sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="es-ES es" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="es" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby22" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

_________________
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
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Thu Aug 31, 2017 8:43 am    Post subject: Reply with quote

Yeah, Bloot Made in china means good quality now ( i got expensive camera made in japan and it died in few weeks ...) ... world is ending for US :D
Is there any option to see that production week without removing cooler ? ( i have serial number on box, mb i could find it via that serial ?)

Edit: bloot maybe give link to your kernel config ?
_________________
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: Thu Aug 31, 2017 12:15 pm    Post subject: Reply with quote

mir3x wrote:
Yeah, Bloot Made in china means good quality now ( i got expensive camera made in japan and it died in few weeks ...) ... world is ending for US :D
Is there any option to see that production week without removing cooler ? ( i have serial number on box, mb i could find it via that serial ?)

Edit: bloot maybe give link to your kernel config ?


Sure no problem! There're tons of options I sure won't need, I should make it cleaner one of these days.

https://pastebin.com/raw/b0fVLdvG
_________________
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
wrc1944
Advocate
Advocate


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

PostPosted: Thu Aug 31, 2017 1:37 pm    Post subject: Reply with quote

Thanks much to all for the informative replies!
If my eclass understanding wasn't so limited, I would have realized how gcc was replacing the -O0 flag. :oops: I still don't get how others are somehow compiling gcc with -O0. Edit the eclass file?

I saw in Bloot's emerge --info he uses CFLAGS="-O2 -march=znver1" with gcc-6.4 to compile 7.2, so I tried that with a 4.12.9 kernel (and added the LDFLAGS line which I forgot about on this relatively new gentoo install. Same segfault happens.

I forgot to consider all my kernel configs were all built with "native" cpu opts enabled, so could that be a factor in my failures? However, I did build that 4.13-rc6 which was a generic 64 kernel, and the same thing happens. I just can't understand why some can get gcc-7.2.0 installed, and nothing works for me? I'm obviously missing something, :? Do I need to compile a 4.12..x kernel without the "native" gcc detedted opts set?

EDIT: OK- just saw Bloot's 4.12.5 kernel config and he has zen opts selected. Would that really make a difference? I have a 4.12.5 kernel still on this system- might try recompiling it with this config file. I'll examine it in detail and see what jumps out at me. Thanks Bloot! :) Hmmm. Just noticed you are amd64, and I'm ~amd64.

@Bloot,
Please let us know what your bios settings regarding SMT, ASLR, OPcache, SOC, and C6 states are.

One other thought: Anyone now successfully using gcc-7.2 have IOMMU enabled in the bios?

One final thought, grasping at straws here: Since gcc 7.1.0-r1 and 7.2.0 are keyworded, might they require glibc-2.26, which is also keyworded? ( I know about going back to my glibc-2.25-r4 would be a nightmare, if not impossible)

I'm about ready to try an emerge -e @world with my current gcc-7.1.0-r1 ( which did compile @system perfectly), and be done with trying to get 7.2.0 installed. (of course unless someone points out where I'm going wrong) :roll:
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.25-r9, gcc-7.2.0- kernel-4.13.11 gentoo USE=experimental
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Thu Aug 31, 2017 4:11 pm    Post subject: Reply with quote

I just copied and added only ethernet driver to bloot config.
Im compiling mesa 50 times, for now it passed 3 times. On second terminal gcc7.2 is recompiling itself. Looks ok for now.

I have IOMMU enabled in bios, everything is default except i added virtualization support.

ASLR is disabled in kernel, also stack protector, KSM too, enabled profiling(that rcu option that prevents idle freezes is not enabled)
If it wont fail ill write in 4-5hours, and i post all changed kernel configs.

EDIT: nvm, it failed.
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
fcl
n00b
n00b


Joined: 31 Dec 2016
Posts: 67

PostPosted: Thu Aug 31, 2017 5:24 pm    Post subject: Reply with quote

FYI if it's compiling segfaults because of the CPU, they won't go away completely. Just RMA the chip and be done with it. There's no way you should have to disable ASLR, lower memory speeds etc. just to have a stable system.
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: Thu Aug 31, 2017 8:02 pm    Post subject: Reply with quote

wrc1944 wrote:
Thanks much to all for the informative replies!
If my eclass understanding wasn't so limited, I would have realized how gcc was replacing the -O0 flag. :oops: I still don't get how others are somehow compiling gcc with -O0. Edit the eclass file?

I saw in Bloot's emerge --info he uses CFLAGS="-O2 -march=znver1" with gcc-6.4 to compile 7.2, so I tried that with a 4.12.9 kernel (and added the LDFLAGS line which I forgot about on this relatively new gentoo install. Same segfault happens.

I forgot to consider all my kernel configs were all built with "native" cpu opts enabled, so could that be a factor in my failures? However, I did build that 4.13-rc6 which was a generic 64 kernel, and the same thing happens. I just can't understand why some can get gcc-7.2.0 installed, and nothing works for me? I'm obviously missing something, :? Do I need to compile a 4.12..x kernel without the "native" gcc detedted opts set?

EDIT: OK- just saw Bloot's 4.12.5 kernel config and he has zen opts selected. Would that really make a difference? I have a 4.12.5 kernel still on this system- might try recompiling it with this config file. I'll examine it in detail and see what jumps out at me. Thanks Bloot! :) Hmmm. Just noticed you are amd64, and I'm ~amd64.

@Bloot,
Please let us know what your bios settings regarding SMT, ASLR, OPcache, SOC, and C6 states are.

One other thought: Anyone now successfully using gcc-7.2 have IOMMU enabled in the bios?

One final thought, grasping at straws here: Since gcc 7.1.0-r1 and 7.2.0 are keyworded, might they require glibc-2.26, which is also keyworded? ( I know about going back to my glibc-2.25-r4 would be a nightmare, if not impossible)

I'm about ready to try an emerge -e @world with my current gcc-7.1.0-r1 ( which did compile @system perfectly), and be done with trying to get 7.2.0 installed. (of course unless someone points out where I'm going wrong) :roll:


Took some screenshots from my bios settings hope this helps http://imgur.com/a/LOTNc

GCC-7.1.0-r1 and GCC-7.2.0 succesful simultaneous compiling http://imgur.com/a/GeZCm
_________________
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
wrc1944
Advocate
Advocate


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

PostPosted: Thu Aug 31, 2017 10:51 pm    Post subject: Reply with quote

@Bloot,
Thanks very much for posting the bios shots! I see you have SMT, C6, and Cool 'n Quite enabled, and Opcache, global C state control and IOMMU on auto, and the SOC at 0.96875.
Pretty much all else seems at auto. I'll re-enable the items I disabled, and see what happens. IIRC, the IOMMU was disabled by default. My ASrock 370 k4 gaming board is pretty similar to yours in the bios settings. Are you using the 3.00 bios version?

fcl wrote:
Quote:
FYI if it's compiling segfaults because of the CPU, they won't go away completely. Just RMA the chip and be done with it.
I surely agree, but I'm still wondering if that's the case how does it manage to compile gcc-7.1.0-r1 or 6.4.0 normally, plus do an emerge -e @system or @world which run to completion without problems? It's only gcc-7.2.0 that segfaults. :?

You're right, I'd RMA in a second, but unfortunately I can't currently have any downtime on this main box right now.

mir3x wrote:
Quote:
On second terminal gcc7.2 is recompiling itself.
So, you already had 7.2 installed. I looked at Bloot's config file, and his board uses the same ethernet and sensors as mine (added my video card options), so maybe I'll try that if adjusting my bios to be more in line with his fails.
Just saw your EDIT: nvm, it failed. Too bad. I had high hopes it would finish well.
On another point, I have IOMMU enabled in my kernels, so maybe that's a conflict if it's disabled in the bios? I'm not really sure on this.

Quote:
# Processor type and features
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y

# Clock Source drivers
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y

Generic IOMMU Pagetable Support
#
CONFIG_IOMMU_IOVA=y
CONFIG_OF_IOMMU=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=y
CONFIG_DMAR_TABLE=y

However, under # Runtime Testing I have this:
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set

_________________
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 Sep 03, 2017 7:46 pm    Post subject: Reply with quote

I've thrown in the towel now and submitted the RMA form. I'll let you know how that goes.

I had several freezes, a runaway memory leak, and a spontaneous reboot in the past few days, though the leak and at least one of the freezes are almost certainly due to the DC kernel. I could stop using that for now but at least if I get a replacement CPU, I can be more confident about what the real cause is.

What knocked my confidence more than anything was a weird error I got while compiling a kernel. I got an error about a missing symbol called syq_set_thread_area. Searching around revealed nothing but I did find one called sys_set_thread_area and starting the build again actually worked. This, along with the earlier corruption I saw with git, is very worrying. Segfaults are annoying but silent data corruption could lead to some very severe problems.

Gigabyte put out a new BIOS the other day but that hasn't helped.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11304

PostPosted: Sun Sep 03, 2017 9:04 pm    Post subject: Reply with quote

Regarding syq_ vs sys_, that looks like a bit flip. s is 73; q is 71, so an inappropriate clear of bit 1 (value 2) would account for the change. This bit flip could be caused by a CPU problem or by bad RAM. Normally, I would blame bad RAM, but since this is a thread about an entire line of CPUs with erratic results, a CPU problem seems plausible in context.
Back to top
View user's profile Send private message
Chewi
Developer
Developer


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

PostPosted: Sun Sep 03, 2017 9:13 pm    Post subject: Reply with quote

Hu wrote:
Regarding syq_ vs sys_, that looks like a bit flip. s is 73; q is 71, so an inappropriate clear of bit 1 (value 2) would account for the change. This bit flip could be caused by a CPU problem or by bad RAM. Normally, I would blame bad RAM, but since this is a thread about an entire line of CPUs with erratic results, a CPU problem seems plausible in context.

Yeah, I have encountered bad RAM in the past and first noticed it when doing diffs across the gcc source tree and seeing random junk creep in occasionally. I'll do a RAM test when I get the replacement CPU. Even if the RAM is faulty, I wouldn't trust a RAM test when I know the CPU is also faulty.
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Wed Sep 06, 2017 9:53 pm    Post subject: Reply with quote

wrc1944 wrote:

On another point, I have IOMMU enabled in my kernels, so maybe that's a conflict if it's disabled in the bios? I'm not really sure on this.

Rather no, if u disabled in kernel then in dmesg it will write it's not enabled ( i tested it), if it enabled then dmesg | grep iommu will return a lot of lines.
dmesg | grep IOMMU - will show generate extra message if it not enabled.

Strange thing - if i set memory to 2.66 ( i've read on kingston site that it will work without changing any dram voltage), then i cannot disable iommu
( i can but computer shutdowns and start many times and then starts again with iommu enabled)

I've set in bios memory interleave -> from auto -> to none and used my antiryzen kernel config and gcc7.2 compiled very fine few times.
(it should be in the same section as iommu in bios ->amd cbs )
It usually failed in 90% cases with memory interleave set to auto( with bloot config it worked mostly ok).
I was testing then with iommu disabled, but now im testing with enabled, its seems it changes nothing for me.
Compiling mesa 50 times with gcc7.2 failed at some point time but with some strange error about general protection trapx in libc2.2.5.
Ill test more soon.

NVM. that memory interleaving set to none causes compile times about 8-15% longer, i tested how changing ram timings affects and i set from 15-15-15-35 to 20-20-20-45 and change in that case was minimal 0-2% only.
_________________
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: Thu Sep 07, 2017 10:51 pm    Post subject: Reply with quote

I submitted the RMA form too, tried the kill-ryzen script and it failed soon with a segfault error. And recently I've been getting segmentation faults on kde plasma too...

Code:
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fcdb85ad7c0 (LWP 2133))]

Thread 11 (Thread 0x7fcccffff700 (LWP 2454)):
#0  0x00007fcdb2565e6f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fcdb36eb3da in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#2  0x00007fcdb65eda8d in ?? () from /usr/lib64/libQt5Quick.so.5
#3  0x00007fcdb65ee35d in ?? () from /usr/lib64/libQt5Quick.so.5
#4  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 10 (Thread 0x7fcce9386700 (LWP 2443)):
#0  0x00007fcdb2565e6f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fcdb36eb3da in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#2  0x00007fcdb65eda8d in ?? () from /usr/lib64/libQt5Quick.so.5
#3  0x00007fcdb65ee35d in ?? () from /usr/lib64/libQt5Quick.so.5
#4  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 9 (Thread 0x7fccec063700 (LWP 2344)):
#0  0x00007fcdb2f8d567 in ioctl () from /lib64/libc.so.6
#1  0x00007fcd0b5daedc in ?? () from /usr/lib64/libnvidia-glcore.so.384.69
#2  0x00007fcd0b5dbeb7 in ?? () from /usr/lib64/libnvidia-glcore.so.384.69
#3  0x00007fcd0b5dc853 in ?? () from /usr/lib64/libnvidia-glcore.so.384.69
#4  0x00007fcd94e78392 in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0
#5  0x00007fcd0b2df6f0 in ?? () from /usr/lib64/libnvidia-glcore.so.384.69
#6  0x00007fcd0b204f8e in ?? () from /usr/lib64/libnvidia-glcore.so.384.69
#7  0x00007fcd94e6eeae in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0
#8  0x00007fcdb876534a in ?? () from /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#9  0x00007fcdb3bdaf1d in QOpenGLContext::swapBuffers(QSurface*) () from /usr/lib64/libQt5Gui.so.5
#10 0x00007fcdb65e9a94 in ?? () from /usr/lib64/libQt5Quick.so.5
#11 0x00007fcdb65ee224 in ?? () from /usr/lib64/libQt5Quick.so.5
#12 0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#13 0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#14 0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7fcd02140700 (LWP 2327)):
#0  0x00007fcdb2565e6f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fcdb36eb3da in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#2  0x00007fcdb65eda8d in ?? () from /usr/lib64/libQt5Quick.so.5
#3  0x00007fcdb65ee35d in ?? () from /usr/lib64/libQt5Quick.so.5
#4  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7fcd03915700 (LWP 2323)):
#0  0x00007fcdb2f8be5d in poll () from /lib64/libc.so.6
#1  0x00007fcdae9592de in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fcdae9593ec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fcdb38c7b1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4  0x00007fcdb387ad7a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb36e6b8b in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007fcdb6581ce6 in ?? () from /usr/lib64/libQt5Quick.so.5
#7  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7fcd95a2d700 (LWP 2314)):
#0  0x00007fcdb2565e6f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fcdb7fe7ac4 in ?? () from /usr/lib64/libQt5Script.so.5
#2  0x00007fcdb7fe7b09 in ?? () from /usr/lib64/libQt5Script.so.5
#3  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#4  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7fcd979b1700 (LWP 2313)):
#0  0x00007fcdb2f8be5d in poll () from /lib64/libc.so.6
#1  0x00007fcdae9592de in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fcdae9593ec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fcdb38c7b1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4  0x00007fcdb387ad7a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb36e6b8b in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007fcdb5c04685 in ?? () from /usr/lib64/libQt5Qml.so.5
#7  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fcd9d9b2700 (LWP 2225)):
#0  0x00007fcdb2f87f9d in read () from /lib64/libc.so.6
#1  0x00007fcdae99b9c0 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fcdae958db6 in g_main_context_check () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fcdae959284 in ?? () from /usr/lib64/libglib-2.0.so.0
#4  0x00007fcdae9593ec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#5  0x00007fcdb38c7b1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6  0x00007fcdb387ad7a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#7  0x00007fcdb36e6b8b in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#8  0x00007fcdb5c04685 in ?? () from /usr/lib64/libQt5Qml.so.5
#9  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#10 0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7fcd9f3f7700 (LWP 2180)):
#0  0x00007fcdb2f8be5d in poll () from /lib64/libc.so.6
#1  0x00007fcdae9592de in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fcdae9593ec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fcdb38c7b1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4  0x00007fcdb387ad7a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb36e6b8b in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007fcdb86c42a5 in ?? () from /usr/lib64/libQt5DBus.so.5
#7  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fcda508e700 (LWP 2143)):
#0  0x00007fcdb2f8be5d in poll () from /lib64/libc.so.6
#1  0x00007fcdb6f3e83f in ?? () from /usr/lib64/libxcb.so.1
#2  0x00007fcdb6f40579 in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007fcda6fe89d9 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007fcdb36ead9b in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007fcdb2560364 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fcdb2f94ccd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fcdb85ad7c0 (LWP 2133)):
[KCrash Handler]
#6  0x00007fcdb5afd66a in QV4::BuiltinFunction::call(QV4::Managed const*, QV4::CallData*) () from /usr/lib64/libQt5Qml.so.5
#7  0x00007fcdb5b65f2e in QV4::Runtime::callProperty(QV4::ExecutionEngine*, int, QV4::CallData*) () from /usr/lib64/libQt5Qml.so.5
#8  0x00007fcd94b414a7 in ?? ()
#9  0x00007fcd969b2520 in ?? ()
#10 0x00007fcdb5b0e4da in QV4::Object::internalGet(QV4::String*, bool*) const () from /usr/lib64/libQt5Qml.so.5
#11 0x00007fcdb5adbf16 in QV4::ExecutionContext::getPropertyAndBase(QV4::String*, QV4::Value*) () from /usr/lib64/libQt5Qml.so.5
#12 0x00007fcdb5b659a8 in QV4::Runtime::callActivationProperty(QV4::ExecutionEngine*, int, QV4::CallData*) () from /usr/lib64/libQt5Qml.so.5
#13 0x00007fcd94b462e5 in ?? ()
#14 0x00000000026f74a0 in ?? ()
#15 0x00007fcd969b2470 in ?? ()
#16 0x00007fcd969b2468 in ?? ()
#17 0x00007fcdb5b0e544 in QV4::Object::internalGet(QV4::String*, bool*) const () from /usr/lib64/libQt5Qml.so.5
#18 0x00007fcdb5bf43f4 in QV4::QmlContextWrapper::get(QV4::Managed const*, QV4::String*, bool*) () from /usr/lib64/libQt5Qml.so.5
#19 0x00007fcdb5b65f2e in QV4::Runtime::callProperty(QV4::ExecutionEngine*, int, QV4::CallData*) () from /usr/lib64/libQt5Qml.so.5
#20 0x00007fcd94b03dc2 in ?? ()
#21 0x00007ffceb2a9ef8 in ?? ()
#22 0x0000000003496ee0 in ?? ()
#23 0x0003200000000000 in ?? ()
#24 0x00000000034d3de0 in ?? ()
#25 0x0000000000000000 in ?? ()


Hope it's solved on newest cpu batches.
_________________
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
wrc1944
Advocate
Advocate


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

PostPosted: Fri Sep 08, 2017 5:29 am    Post subject: Reply with quote

Here's something interesting: http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-k10temp-Patch
Comments:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/975047-there-s-now-a-patch-adding-ryzen-amd-zen-temperature-support-on-linux

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.
_________________
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
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Fri Sep 08, 2017 6:44 am    Post subject: Reply with quote

I applied that temp patch to 4.12.7-gentoo ( half of patches i had to add manually, but probably i screwed something)
k10temp shows me only -20 temp (minus 20).

Does Ryzen BOX version has 3 years warranty ?

bloot - cmon, not every segfault is caused by Ryzen, especially those by Plasma and Qt.
Probably u wont see any Ryzen related segfault outside gcc.
I just ditched gcc7.2 and everything is ok.
We can wait 2.5 years and mb we get then Ryzens 11 :D ( I mean RMA then and mb ryzen 7 will not be longer in production ... )

I have no idea which week is my ryzen but I noticed my ram was made in 21 week, cpu was from the same shop so probably something similar.
( that information was in bios)

EDIT: if anyone needs more segfaulting kernel config (I've read that for RMA they request many screenshots) - I posted it here
https://paste.pound-python.org/show/btM3q8LnLKK6Bve357zd/

(it has realtek ethernet, so if u use intel u would need to add)
_________________
Installation aborted to prevent system self-destruction
Back to top
View user's profile Send private message
Chewi
Developer
Developer


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

PostPosted: Fri Sep 08, 2017 7:02 am    Post subject: Reply with quote

mir3x wrote:
bloot - cmon, not every segfault is caused by Ryzen, especially those by Plasma and Qt.
Probably u wont see any Ryzen related segfault outside gcc.

That's not true at all, I've seen git, Java, and even Portage itself segfault and they definitely weren't caused by anything else. gcc gets called over and over so you're just more likely to see it there.

My RMA is progressing. Sent details about my system and pictures of my case. They've ruled out thermal issues and now they want to start tweaking BIOS settings. I wish they'd just acknowledge that these are known to be faulty but it's better than nothing.
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 343

PostPosted: Fri Sep 08, 2017 7:06 am    Post subject: Reply with quote

Chewi wrote
Quote:
My RMA is progressing. Sent details about my system and pictures of my case. They've ruled out thermal issues and now they want to start tweaking BIOS settings. I wish they'd just acknowledge that these are known to be faulty but it's better than nothing.


From what I've read on that wrc posted link not everyone had to some crazy tests every 0.05, just tell them thats waste of your time and send them 3 samples.
EDIT: or maybe pretend to be angry customer, I've read that if u r waiting on phone, there is program listening u, and if u start swearing, u will be first in queue :D
_________________
Installation aborted to prevent system self-destruction
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 ... , 20, 21, 22  Next
Page 21 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