Re: Good news on Debian Sparc port stability
James Y Knight <jyknight <at> google.com> writes:
>
> 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:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
>
> 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
>
>
>
Hi James,
I'm having a problem to install and/or use Oracle VM. Do you know how?
Because initially I had o install 2 VM's n my Sparc which in the primay
is a Solaris 11. I guess that VM would resolve my problem, but i didnt
find anything to help me install this on my Solaris. (initialy i needed
o make 2 VM's - one runing CentOS and other Windows)
BR
Kézia
Reply to: