Author Topic: Void Linux thread  (Read 30825 times)

madscientist159

  • Raptor Staff
  • *****
  • Posts: 47
  • Karma: +11/-0
    • View Profile
Re: Void Linux thread
« Reply #15 on: December 10, 2019, 06:22:45 pm »
Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.

I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).

What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?

q66

  • Guest
Re: Void Linux thread
« Reply #16 on: December 10, 2019, 07:47:50 pm »
Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.

I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).

What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?

If you mean performance loss with 64-bit ldbl vs 128-bit IEEE754, 64-bit should be faster, because Void is compiled for POWER8 like other distros and therefore can't use POWER9 isns (other than in glibc math functions, which can be chosen at runtime). The actual difference, don't know, I haven't benchmarked it (and won't, as that would mean compiling a set of packages for that).

I kind of don't want to use the 128-bit stuff for long double type in principle, as the hard VSX requirement is there either way (gcc will not compile it without -mcpu set to at least power7) and I'd kind of like the little endian and big endian targets differ mostly in just endianness and baseline -mcpu setting.

I never liked the long double type anyway, as the guarantees you get with it are zero (it's only required to be at least as big/precise as double and that's it). So going with a 64-bit baseline that's covered well in hardware everywhere seems like the sane choice (plus musl won't be adopting 128bit IEEE754 as it would require introduction of a new subarch because musl doesn't version symbols - so that would make glibc little endian the *only* outlier).

People who want 128-bit IEEE754 floating point can easily use the __float128 type in gcc. That is a much better option as it has guaranteed properties (similarly, it works on modern x86 with at least 128-bit wide SIMD as well). People who want the IBM 128bit floating point can also use the __ibm128 type in gcc in a similar manner.

Adopting 64-bit long double in glibc is actually pretty easy right now - because it used to use it in the past (before IBM made them change the default to the silly 128-bit double-double). Therefore, all the compatibility symbols as well as redirects for when you use -mlong-double-64 are set up in glibc, and all it takes is recompiling libraries and programs that use 128-bit IBM long double. You can easily tell which do - they will be tagged like Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double in the ELF attributes. This tag is only introduced when long doubles are used in the binary and it was compiled with those set to 128-bit IBM format.

So, I just went and checked every package containing ELF files for the tag, and compiled a list. It's a relatively small number, only about 330 packages out of 8000+. The rest of them can be left alone.
« Last Edit: December 10, 2019, 07:54:54 pm by q66 »

q66

  • Guest
Re: Void Linux thread
« Reply #17 on: December 12, 2019, 12:50:00 pm »
After some experimentation, I came to the conclusion that it is currently not practical to switch, as while things will mostly work, using compat symbols ultimately means that some configurations will break; in this case, things that manually declare stuff like math symbol prototypes (which is allowed) for long double math funcs will still use the ibm128 symbols and silently have wrong results... while this is rare, it is a concern.

I searched for potential workarounds but they mostly just introduced new issues elsewhere...

I'll wait until glibc has ironed out its IEEE754 128-bit support and some other distros have switched to it (i know Fedora is planning that) and then I'll reevaluate my options (e.g. possibly see if I could get in a 64-bit ldbl ABI *without* falling back to compat symbols, which would generally solve everything, besides compatibility with ibm128 and glibc is going to need to handle that for the ieee754 transition anyway). Since transition has proved to be less of a problem than expected by itself, it should be relatively easily doable later on.

So, sticking with what I have for now.

q66

  • Guest
Re: Void Linux thread
« Reply #18 on: December 16, 2019, 03:51:14 am »
New packages batch; bringing out-of-box support for the Navi GPUs in the 5.4 kernel, further BE expansion, and other cool stuff 8)

q66

  • Guest
Re: Void Linux thread
« Reply #19 on: January 03, 2020, 11:07:10 am »
We're now complete (as in the whole repo is built and everything not buildable is properly marked as such) on ppc64le and ppc64le-musl \o/

ClassicHasClass

  • Sr. Member
  • ****
  • Posts: 471
  • Karma: +37/-0
  • Talospace Earth Orbit
    • View Profile
    • Floodgap
Re: Void Linux thread
« Reply #20 on: January 04, 2020, 06:28:13 pm »
Excellent!!

q66

  • Guest
Re: Void Linux thread
« Reply #21 on: January 15, 2020, 02:08:50 am »
The repos are now complete on big endian/32 bit targets as well. Final coverage as usual at https://repo.voidlinux-ppc.org/stats.html. Currently at ~100k packages, amounting to just under 450GB total.
« Last Edit: January 15, 2020, 02:18:57 am by q66 »

xilinder

  • Jr. Member
  • **
  • Posts: 82
  • Karma: +9/-0
    • View Profile
Re: Void Linux thread
« Reply #22 on: January 18, 2020, 10:08:04 am »
I installed Void Linux as a base system only and added 'mc''links' and 'gpm'.
I'm not getting a mouse. How do I start it?
Talos II 2x8, 32GB RAM, onboard Microsemi RAID,  AMD WX7100, J.Micron SATA/PATA PCIe adapter. Debian with Mate.

q66

  • Guest
Re: Void Linux thread
« Reply #23 on: January 18, 2020, 10:12:10 am »
presumably you need to enable the appropriate service...

something like


ln -s /etc/sv/gpm /var/service/

xilinder

  • Jr. Member
  • **
  • Posts: 82
  • Karma: +9/-0
    • View Profile
Re: Void Linux thread
« Reply #24 on: January 18, 2020, 10:47:17 am »
Yup! That did it. Thanks
Talos II 2x8, 32GB RAM, onboard Microsemi RAID,  AMD WX7100, J.Micron SATA/PATA PCIe adapter. Debian with Mate.

q66

  • Guest
Re: Void Linux thread
« Reply #25 on: April 11, 2020, 11:34:24 am »
Fresh installation/live media now available: https://voidlinux-ppc.org/news/2020/04/new-images.html

q66

  • Guest
Re: Void Linux thread
« Reply #26 on: May 01, 2020, 09:19:02 pm »
Latest packages now fix Navi GPUs on kernel 5.6 (5.5 and 5.4 had it working all along). Once again we're the first to have it, but necessary patch was submitted upstream as well and in the meantime made it into drm-next, and will trickle down to other distros later.

Hasturtium

  • Full Member
  • ***
  • Posts: 155
  • Karma: +10/-0
    • View Profile
Re: Void Linux thread
« Reply #27 on: July 23, 2022, 05:57:07 pm »
Hey, I know this is an old thread but thought this would be a valuable place to post. I just setup my Blackbird and installed the most current ISO of Void, but I can’t get networking to work. lspci dutifully lists all three Ethernet controllers, but Void’s network manager does not seem to enumerate any of them. I’m unfortunately new to Void and not used to running any traps on it, and would appreciate any pointers!

MPC7500

  • Hero Member
  • *****
  • Posts: 592
  • Karma: +41/-1
    • View Profile
    • Twitter
Re: Void Linux thread
« Reply #28 on: July 24, 2022, 07:14:04 am »
You have to set the correct time / date.

Hasturtium

  • Full Member
  • ***
  • Posts: 155
  • Karma: +10/-0
    • View Profile
Re: Void Linux thread
« Reply #29 on: July 24, 2022, 02:39:49 pm »
You have to set the correct time / date.

I’ve been trying, but whether I use date within the skiroot shell to set the date or within Void itself, it doesn’t seem to stick. Forgive me, I’m new to this - can you show me how?

edit: to clarify, date appears to update correctly, but hwclock remains firmly convinced that it is June 8th, and nothing I’ve been able to do disabuses it of the notion. I’ve tried syncing the system time to the hardware clock so they’re at least both wrong to the same extent, but networking still doesn’t work

edit the second: I skipped connecting to the BMC initially, which is where I’m supposed to initially set the date. D’oh. I’ll take care of that this week and pray until then.
« Last Edit: July 24, 2022, 07:23:41 pm by Hasturtium »