You are not logged in.
Hello,
I run archlinux32 on an AMD Geode. Until now it worked perfectly.
However, the update of glibc from 2.27 to 2.28 completely broke my system. I typically get messages like this one:
traps: bash[4529] trap invalid opcode ip:b7facd40 sp:bf9392ec error:0 in ld-2.28.so[b7fac000+1c000]
Apparently, this new version of the library uses instructions that the Geode doesn't understand. Unfortunately, I wasn't able the find the culprit one (the system was no longer usable).
Does anyone else have this problem ?
Sylvain
Offline
Yes, the toolchain is emitting SSE2 and SSE code now. Broke also on my Alix 1.E with
an AMD Geode. The only way to solve this is to bootstrap a i486 version (see my
branch on git.archlinux32.org in the 'packages' repo). Currently, this is a low-priority
project as the main i686-version suffers from lack of maintaince power already.
The i486 version is also available on http://archlinux32.andreasbaumann.cc archi486isos
and i486 repo but it contains base and base-devel only at the moment and is a little
bit behind in terms of package versions).
See also for tipps and tricks in https://bbs.archlinux32.org/viewtopic.php?id=510
Offline
Ooh, SSE2 code would have scuppered me if I were still using my Pentium 3. It could run plain old SSE but SSE2 was a bit too new for it. You could argue it was well outdated even by the time I started using it, but it still worked when I finally dumped it after finding a newer machine to use which runs 64-bit code so I'm using arch64 on that. I'm using Arch32 on my Atom-based netbook which runs SSE2 and SSSE3, so I've not noticed this build change.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Thank you for these precisions. This is sad that such processors are no longer supported, although there is probably lot of them running around (especially on Alix boards).
I had a look on
the i486 repository. Unfortunately, too many packages are missing,
so that I can't switch to a complete i486 system. (I use my alix board
as a MPD-based sound system).
So I'll stay with the 686 architecture and will no longer perform updates... In the meanwhile I was able to repair it.
Offline
What you can do, make a `pacman -Q` and post me the list. So I have something to priorize on i486.
As long things are console based and nothing uses X, things should be quite easy to build.
Offline
Thank you for your support. Basically, I "only" needs mpd, mpc and ncmpcpp.
However these 3 packages depend on lots of things (e.g. wayland, see below). I'm not sure sure it is worth the effort....
I'll try mpd-light, available on AUR. It looks much simpler.
acl alsa-lib aom argon2 attr audiofile avahi bash boost-libs bzip2 ca-certificates ca-certificates-cacert ca-certificates-mozilla ca-certificates-utils cifs-utils coreutils cracklib cryptsetup curl db dbus device-mapper e2fsprogs expat faad2 ffmpeg fftw filesystem findutils flac fontconfig freetype2 fribidi gamin gcc-libs gdbm giflib glib2 glibc gmp gnutls graphite gsm harfbuzz hicolor-icon-theme hwids iana-etc icu iptables jack json-c kbd keyutils kmod krb5 lame lcms2 ldb libao libarchive libass libasyncns libavc1394 libbluray libbsd libcap libcap-ng libcups libdaemon libdrm libedit libelf libffi libgcrypt libglvnd libgme libgpg-error libibus libice libid3tag libidn libidn2 libiec61883 libjpeg-turbo libldap libmad libmms libmnl libmodplug libmpdclient libnfs libnftnl libnghttp2 libnl libnsl libogg libomxil-bellagio libpcap libpciaccess libpng libpsl libpulse libraw1394 libsamplerate libsasl libseccomp libshout libsm libsndfile libsoxr libssh libssh2 libsystemd libtasn1 libtheora libtiff libtirpc libunistring libunwind libupnp libusb libutil-linux libva libvdpau libvorbis libvpx libwbclient libwebp libx11 libx264 libxau libxcb libxcursor libxdamage libxdmcp libxext libxfixes libxi libxml2 libxrender libxshmfence libxtst libxv libxxf86vm linux-api-headers llvm-libs lmdb lm_sensors lz4 mesa mpc mpd ncmpcpp ncurses nettle opencore-amr openjpeg2 openssl opus p11-kit pam pambase pcre pcre2 perl popt python2 readline sdl2 shadow smbclient speex speexdsp sqlite sysfsutils systemd taglib talloc tdb tevent tzdata util-linux v4l-utils vid.stab wavpack wayland x265 xcb-proto xorgproto
Offline
yeah, wayland for mpd sounds like feature creep. :-)
I definitely want to make my Alix work again with Archlinux32/486, it was running before gcc 8.2/glibc 2.28 like a charm with
window manager, VESA Xorg (ok, not geode/AMD/GPU support) without any problem. So I would love to get there again.
The sound libraries don't sound so bad.
Currently
I'm rebuilding with gcc 8.2/glibc 2.28 also the i486 version and going
through the "Python 3.7 bootstrapping hell", but
I'm confident I can soon move on to other packages than base and base-devel.
The main issue, is that I cannot put the i486 build slave yet into the buildmaster build system, it would draw away valuable
resource we need for the i686 build. I have to think about that a bit.
Offline
you could try mpg123 or some really simple command line sound players in the mean time.
Offline
I use mplayer from a terminal to play all of my audio and video these days (and my video I usually preprocess and play over a scp network share), but my reading of mpd suggests it's designed to interface with other kit - as far as I know mplayer only interfaces with remote controls using the LIRC protocol. Mpd runs over the network and lets other devices (which generally run linux under the hood by may have no user terminal facilities) to control playback on that machine.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
mplayer draws in most libraries too, like mpg123 etc.
Offline
mpd-light looks pretty good. The only missing libraries are :
audiofile ca-certificates-cacert faad2 fftw flac libgme libid3tag libmad libmms libmpdclient libnfs libogg libsamplerate libsndfile libsoxr libupnp libvorbis mpc mpd-light ncmpcpp taglib
Regarding mpd: It is my favorite music player. There is a clean separation between the audio rendering and the user interface. My favorite client is ncmpcpp, an ncurses-based client. If your audio library is well tagged, it is very easy to handle large libraries (mine has more than 10k songs). Other nice point, your smartphone can control it (e.g. stop the music when receiving a call).
Offline
Ok, I'll give the list a go on i486..
Offline
[...] Yes, the toolchain is emitting SSE2 and SSE code now. Broke also on my Alix 1.E with
an AMD Geode [...]
Hello,
The glibc update to 2.28, can break my system in a Pentium 3 (Coppermine) ...
flags: CMOV, MMX, SSE, ...
Regards,
Offline
Yes, as andreas said in his first post to the thread, the build tools are currently spitting out SSE2 code. You coppermine P3 supports the original SSE only, so you'll need to hang off updating for now, or rebuild your system from the i486 repo if it's got everything you need. SSE2 implies P4 or newer, and none of the low power options except for Atom, basically.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
The i486 repo contains only base and base-devel and everything which is needed to bootstrap some packages.
There is no X, no window manager and nothing for users there. :-)
Offline
Current status:
https://mirror.archlinux32.org/irc-logs … l#16:47:33
Short, I have check how generates illegal opcodes though I compile with -march=486
Offline
After some digging my best guess is a new security feature causing trouble on old CPUS:
http://archlinux32.andreasbaumann.cc/ir … l#20:28:05
Any information on that welcome. :-)
Offline
This is informative:
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=84148
So we must try to disable that for i486 builds.
PKGBUILD of gcc: --enable-cet=auto.
This I have to switch off and the redo the whole toolchain and the build.
Offline
Ugh. Can you see in the build logs the actual flags being passed to the final gcc compile stages to see what flags are being passed to them? Just to rule out make setting the wrong flags downstream. If this is microcode rewrites in the middle of logic flow then... stop the world I'd like to get off.
Edit: Interesting about that cet thing. You sure setting it to auto will change it? I'd have thought you'd want to start disabling features rather than setting them to autonegotiate, but I'm only really following from the exit gate at present, so give it a try, it might work. By prebuild I assume you mean the gcc configure step.
Last edited by levi (2018-09-02 19:11:57)
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
--enable-cet=auto checks if binutils supports the CET feature. I generally don't trust binutils and automatic things.
Also I don't trust glibc not to play with flags again. So easiest is to simply drop the CET-feature from the gcc
code generator. :-)
Sadly I have no build logs from the i486 virtual machine. The VM runs a little bit by hand and outside the
standard Archlinux32 buildmaster ways currently.
Actually, as I understand, the opcodes get translated to multi-byte NOPs for non-CET CPUs, but this is
something very old 32-bit CPU don't understand yet.
Offline
--enable-cet=auto came in "silently" in gcc PKGBUILD (asp
buildlog gcc just showed me that). I admit, I don't follow all the
changes
upstream that closely.
Offline
Ah, rebuild binutils then?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Worse. Rebuild everything. :-)
Offline
Well, yeah. Isn't binutils the first thing you build when building a cross compiler? Certainly the gcc build depends on it, so whenever you rebuild it you need to rebuild gcc. Only the step about installing the target linux-abi-headers can be semi-reliably skipped I suspect.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
andreas_baumann wrote:[...] Yes, the toolchain is emitting SSE2 and SSE code now. Broke also on my Alix 1.E with
an AMD Geode [...]Hello,
The glibc update to 2.28, can break my system in a Pentium 3 (Coppermine) ...
flags: CMOV, MMX, SSE, ...
Regards,
Thanks Levi ...
Ask Andreas_Baumann - Deep42thought ... Support for un pentium 3 effectively ends today ...
If it were temporary, I can safely update the other packages ...
IgnorePkg: glibc, perl, python-*
Last edited by Luffy (2018-09-03 21:43:18)
Offline