1. Forum
  2. Usenet
  3. LINUX.GENTOO.USER

  • [gentoo-user] Build for Athlon and Ryzen architectures

    From ralfconn@21:1/5 to All on Tue Aug 20 19:30:01 2024
    Hello,

    my 8-year old gentoo HTPC is giving clear signals that the motherboard
    is about to die so I ordered new components.

    The dying box is an AMD FX-6530 built with -march=native. The new box
    will be Ryzen 7 5800X.

    I'd like to rebuild the dying boxwith some more generic -march option so
    that I'll be able to boot into the new box and then rebuild it with more optimized -march.

    If I understand well the GCC man page the safest option for the dying
    system rebuild would be -march=x86_64 (and maybe -mtune=generic?). Is
    this right?

    thanks,

    raffaele

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Schwartz@21:1/5 to ralfconn on Tue Aug 20 19:40:01 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------1MluIrXWKqy20zZGvP0YP5vr
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 8/20/24 1:23 PM, ralfconn wrote:
    Hello,

    my 8-year old gentoo HTPC is giving clear signals that the motherboard
    is about to die so I ordered new components.

    The dying box is an AMD FX-6530 built with -march=native. The new box
    will be Ryzen 7 5800X.

    I'd like to rebuild the dying boxwith some more generic -march option so
    that I'll be able to boot into the new box and then rebuild it with more optimized -march.

    If I understand well the GCC man page the safest option for the dying
    system rebuild would be -march=x86_64 (and maybe -mtune=generic?). Is
    this right?


    The other safe option is to run `ld.so --help` and check for this:

    Subdirectories of glibc-hwcaps directories, in priority order:
    x86-64-v4
    x86-64-v3 (supported, searched)
    x86-64-v2 (supported, searched)



    Your new CPU should support -march=x86-64-v3 but perhaps the old one
    doesn't.

    If you plan to recompile all packages with -march=native immediately
    after you swap anyway, then it doesn't really matter, just use "x86-64"
    for maximum compatibility.


    --
    Eli Schwartz


    --------------1MluIrXWKqy20zZGvP0YP5vr--

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZsTUlwUDAAAAAAAKCRCEp9ErcA0vV9cS AP4x3bV7rvqs9ot+pGV8WXxsZVV5fOvJpNRj1FpriooV/AD+I4kiWG+8JiwMCq0redH54dpfDZGY rC5YsRqzzSB5JA4=
    =N7Jv
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Victor Ivanov@21:1/5 to gentoo-user at lists.gentoo.org on Tue Aug 20 20:57:11 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
    On 20/08/2024 18:38, Eli Schwartz wrote:
    Your new CPU should support -march=x86-64-v3 but perhaps the old one
    doesn't.

    If you plan to recompile all packages with -march=native immediately
    after you swap anyway, then it doesn't really matter, just use "x86-64"
    for maximum compatibility.

    Agreed with this recommendation. Last year I migrated from a dying Intel
    6th gen to a Ryzen 7000 series and went with, IIRC, the most generic -march=x86-64 without -mtune.

    To save some compile time and electricity I only recompiled @system.
    After migrating the drive to the new system I updated -march accordingly
    and recompiled @system again (just in case, perhaps unnecessarily)
    before ultimately running a full "--emptytree @world" recompile with
    some exceptions from @system. If recompile time and/or energy is not a
    factor, it's probably safer to go with @world in both cases and not bother.

    Somebody also suggested then to install "gentoo-kernel-bin" before the

    migration in case there's any compatibility changes and your current
    kernel doesn't boot on the new system.

    Ironically, in my case I did have issues with a black screen with my
    kernel, but the gentoo-kernel-bin panic'd straight away. Turns out my
    issue was graphics related and adding "nomodeset" got the screen going
    and I resolved the problem shortly after. So YMMV, but probably doesn't
    hurt to have it as a back up.

    Good luck!

    - Victor

    -----BEGIN PGP SIGNATURE-----
    Version: ProtonMail

    wnUEARYIACcFAmbE9RoJEMuXJJI+vh0uFiEE59g+WZi8eZ7/aQNqy5ckkj6+ HS4AAMhlAP9FhVBA6B2P4hF0hzf2/jNF4NI5JS7ZRPXZq+B75f0IUwD9HK+I h/cmoCmIpOXPqYUq6fr69ZTNbSJHjnESzC1tnwQ=
    =u4Nv
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ralfconn@21:1/5 to All on Wed Aug 21 06:50:01 2024
    Il 20/08/24 22:42, Dale ha scritto:
    If you are in no hurry for the new system to be available once built,
    I'd consider this way.  Leave current system as is.  If you start compiling, it could die while compiling depending on what the problem
    is.  I'd assemble the new system, test from some boot media, make sure memory, CPU and all that works.  In other words, not dead out of the
    box.  Then install the hard drive OS from the old system.  Boot the boot media, mount and chroot into the old install.  Make the needed changes
    As mentioned in another post I tried a similar route in the past (not
    chroot but directly boot from the old install) and it did not work. At
    the time I assumed the instruction sets were different between the
    Athlon and the Ryzen and gave up, reinstalling the new rig from stage 3.
    I'm not so convinced that was the problem, but this subject is far too
    complex given the time I can invest on it.
    in make.conf, don't forget CPU flags if set, and start a emerge -e
    world.  One advantage of compiling on newer rig, it is faster than the
    old rig.  Another advantage, you only need to do it once.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ralfconn@21:1/5 to All on Wed Aug 21 06:40:02 2024
    Il 20/08/24 19:38, Eli Schwartz ha scritto:
    On 8/20/24 1:23 PM, ralfconn wrote:
    my 8-year old gentoo HTPC is giving clear signals that the motherboard
    is about to die so I ordered new components.

    The dying box is an AMD FX-6530 built with -march=native. The new box
    will be Ryzen 7 5800X.
    The other safe option is to run `ld.so --help` and check for this:

    Subdirectories of glibc-hwcaps directories, in priority order:
        x86-64-v4
        x86-64-v3 (supported, searched)
        x86-64-v2 (supported, searched)


    Your new CPU should support -march=x86-64-v3 but perhaps the old one doesn't.

    If you plan to recompile all packages with -march=native immediately
    after you swap anyway, then it doesn't really matter, just use "x86-64"
    for maximum compatibility.

    The command on the old rig outputs:

      x86-64-v4
      x86-64-v3
      x86-64-v2 (supported, searched)

    while on another box with a Ryzen 9 5900x it output the same as your
    example (-v3 and -v2 supported).

    I did not know about this 'Microarchitecture level' definition [1],
    thanks. I'd expect the -v3 to be a superset of the -v2, instead when in
    the past I tried to boot a Ryzen 9 from a system built with
    -march=native for an FX 8530 it did not work (I don't remember if it was
    a kernel panic or if it stopped already at GRUB, I think the latter), so
    I had to reinstall from stage 3.

    raffaele

    [1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Schwartz@21:1/5 to ralfconn on Wed Aug 21 07:30:01 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hGajCg1AcGR8NpJFDfm6l07X
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 8/21/24 12:34 AM, ralfconn wrote:
    I did not know about this 'Microarchitecture level' definition [1],
    thanks. I'd expect the -v3 to be a superset of the -v2, instead when in
    the past I tried to boot a Ryzen 9 from a system built with
    -march=native for an FX 8530 it did not work (I don't remember if it was
    a kernel panic or if it stopped already at GRUB, I think the latter), so
    I had to reinstall from stage 3.

    raffaele

    [1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels


    Yup, that is the great advantage of these microarchitecture "common
    levels". Unlike -march=native which just toggles every single tiny
    option your current CPU supports, these are strictly defined supersets
    designed to work with, basically, "any CPU produced after a certain
    date". It makes it much easier to deliver common optimizations to a mere
    3 distinct configurations. Also it makes it much easier to rapidly tell
    which group your current CPU supports.



    Gentoo's official binhost uses these too. Well, the binhost provides a
    regular generic -march=x86-64 set of binary packages, plus a set that
    targets the -march=x86-64-v3 seriesdsfe. No "v2" or "v4" packages there,
    I'm afraid. :)


    --
    Eli Schwartz


    --------------hGajCg1AcGR8NpJFDfm6l07X--

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZsV6YwUDAAAAAAAKCRCEp9ErcA0vV/LL AQDF0uEkT967GjzbLnodn0Dhl8X29+vx7H0lp3BBE12zwQEAiouV4kvLsrgQ3dpr9TnoFPKQiAXL NVNIEzbY1X4oVwY=
    =4ond
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)