| I've recently acquired a Sparc T3-1, and installed Debian Unstable's Sparc port on it, as a guest in a Oracle VM Server for Sparc ("ldm") VM. I ran into a few issues, that I've cataloged in a story below. But it has a happy ending! Kernel sunvdc module ==================== Installation wasn't 100% straightforward, as the "sunvdc" virtual disk driver, at least as used in kernel 3.16.7-ckt9-3, which was what was in the d-i image I downloaded from http://d-i.debian.org/daily-images/sparc/ at the time, seems to be basically 100% broken. As soon as the installer got to the partitioner, the whole VM would hang. I see that there have been a lot of commits to that driver from Oracle people in the last few months, so I hope they're working on fixing it. Dunno. I also never tried installing on "bare metal", which I'm led to believe from random forum posts does work out of the box, since I wanted to keep solaris (and didn't realize, going in, how hard I was making things for myself...) So long story short on that, I ended up doing an NFS root install instead, since the sunvnet network driver worked fine. It would be real nice if debian-installer had the ability to install to NFS readily available; I had to go extract the nfs modules manually from the normal kernel package, and then run debootstrap manually. (But -- I'm sure happy that debian's initramfs has builtin support for NFS root!) klibc-utils =========== Next problem I found is that the klibc-utils' ipconfig program gets a Bus Error when trying to get itself an DHCP address. I believe that DHCP client is only ever used in the initramfs, and only if you want to do an NFS root; the other dhcp daemons, e.g. as found in debian-installer, had worked fine. So, I told it to use a static IP instead, which worked. (I'm sure the bug is just an obvious misaligned memory access; I can look into that later). GLibc ===== After that, everything seemed to be going fine, except that programs like GCC would randomly segfault and give parse errors. This has been reported before, e.g. http://thread.gmane.org/gmane.linux.ports.sparc/16835, from 2 years ago. Things were stable enough to use interactively, if you're willing to keep retrying a build until it works, but not stable enough to use for any autobuild system. After a getting a hint from Aurelien that disabling optimized memcpy routines in glibc (eglibc 2.19-1, on Wed, 04 Jun 2014 20:32:06 +0200) had improved, but did not fix, the problem, I started looking into that.... ...And found that recompiling glibc, disabling the sparcv9 optimizations (that is: eliminating debian/patches/sparc/local-sparcv9-target.diff), *appears* to have completely fixed the stability issue! To try to verify that, I ran a loop building and rebuilding 'clang' (with full "ninja" parallelism) overnight, and it's had zero crashes in all 14 builds of clang that it got through. Prior to fixing glibc, at least one of the ~2300 build steps (gcc/as/ld) was sure to crash unreproducibly. It'd be great if someone wants to try to figure out exactly /which/ of the asm routines in the various sysdeps/**/sparc32/sparcv9 are broken, to narrow down the problem better, too. I highly suspect there's just something wrong in one or more of the hand-written asm files, but it's certainly possible there's some wider problem that the sparcv9 optimizations of glibc (but nothing else I've seen so far), just happens to expose. GCC ==== Oh, and I'll mention one more bug I ran into, which is not sparc-specific, but does affect building some C++11 software on Sparc: The workaround for that is usually to just compile at an optimization level greater than -O0, as the problematic construct typically only occurs in inline templates forwarding their arguments onto another function, which all just disappear at high opt levels. Conclusion ========== It seems like the one change to glibc is probably a good-enough fix to get the Sparc port back to a position of stability. And I hope this can help avoid Sparc needing to be deleted from Debian... It seems to really *not* be in as bad a shape as one might be led to believe. E.g. I'm not sure what "lack of proper kernel support" means (from Joerg's https://lists.debian.org/debian-devel/2015/04/msg00284.html). The kernel appears to be working fine. I ran into some bugs, but besides the one glibc issue, none really seem fatal to the health of the port in Debian. James |