6 ms·

Sparc removal

64 points by buster 11y ago

justincormack 11y ago
The linked message says it could come back as sparc64 - the Debian port was a 32 bit userspace, optionally 64 but kernel, while on new sparc machines you probably would want to use sparc64 userspace. For embedded/fpga sparc it is less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on sparc than Linux.
- dmm 11y ago
  This port only ran on 64-bit machines. Support for 32-bit sparc cpus was dropped years ago.
4ad 11y ago
Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian does not have an official SPARC64 port (it has an unofficial one).
- dmm 11y ago
  Support for 32-bit sparc was dropped years ago. This was the port for 64-bit machines even though it used a 32-bit userland.
  - deleted 11y ago
    [deleted]
justaaron 11y ago
what about openSPARC, one of the only truly open cpu designs one can load into an fpga
- nickpsecurity 11y ago
  And the Gaisler Aeroflex cores that are both open-source and fabbed onto boards they sell. People who want open hardware can get a bit closer with a 4-core SPARC board. :)
- 4ad 11y ago
  openSPARC was amazing at the time, but now the last published design is almost a decade old, and last I tried a few months ago I couldn't even download everything that was necessary to load it on an FPGA. Not to mention that the reference software you could run on that FPGA is not available any more.
DonHopkins 11y ago
CRAPS!
yrmt 11y ago
NetBSD welcomes all SPARC owners
rurban 11y ago
Very likely wrong alignment. This causes hard SIGBUS faults, and SPARC64 is one of the good platforms to catch such misaligned pointers. You cannot repro it in qemu on Intel. But I don't know what ElfW(Rel) expands to. Maybe only a 4byte word, not 8. The backtrace doesn't display the register content (THANKS gdb maintainers), and the op didn't provide the registers neither. 0xfffff8010000cda4 in elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out> https://lists.debian.org/debian-sparc/2015/07/msg00013.html https://lists.debian.org/debian-sparc/2015/07/msg00013.html
dmm 11y ago
I spent a lot of time in the past few months trying to fix enough of the issues with Debian/SPARC to keep it from having to be removed. Honestly the port isn't in terrible shape. The specific problems listed as reasons for removing it are exaggerated. GCC is not dropping 32-bit SPARC code generation and the kernel works well overall. There were a few issues causing a lot of breakage, in particular, a register corruption bug in the kernel memcpy routine and a problem with the gold linker that was corrupting string literals in certain cases. Those two bugs blocked everything depending on nettle or qt, 800+ packages. The real issue is that Debian has high expectations that take maintenance to fulfill. Particularly with the autobuilders, the machines that produce binary packages from source. When a build fails there needs to be somebody that fixes the problem. If an autobuilder crashes it can be restarted but if it's crashing every day there needs to be someone to track down the problem. If there is nobody responding to issues it's ok for a while. The people responsible for packages and the autobuilder infrastructure work around problems where they can (running old kernels) but eventually it becomes too much to ask. So I don't like this decision but it's understandable. The specific problems are exaggerated but the fundamental one isn't: nobody was doing the work to keep everything together.
- nothrabannosir 11y ago
  > The real issue is that Debian has high expectations that take maintenance to fulfill. Without meaning to diminish your insightful post and good point: as a Debian user, I have to say, this does not sound like an issue to me.
  - dmm 11y ago
    Sorry if it wasn't clear but I specifically meant the issue for the sparc port. I was not criticizing Debian in any way.
w8rbt 11y ago
OpenBSD still supports it. It's very stable too.
- dmm 11y ago
  It supports cool stuff like acting as an ldom host too. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sparc64/ldomd.8?query=ldomd http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...
  - stsp 11y ago
    Better documentation link which shows how to set it all up: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sparc64/ldomctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...
  - yellowapple 11y ago
    Huh, and here I was figuring that switching Solaris to OpenBSD on my SPARC hardware would mean not getting to tinker with logical domains anymore. I'm glad to see that my assumptions are incorrect, and that my Sun Fire T2000 will have an actual reason to be running in all its loud, jet-engine-sounding glory :)
- justin66 11y ago
  Supports some hardware that Linux never did, as well.
omginternets 11y ago
><liw> HE, we had sex in Debian for many years, yes, before I put a stop to it Could someone explain wtf this means?
- baghira 11y ago
  Probably related to the "Simple editor for X".
  - omginternets 11y ago
    Ah, that makes more sense than OSS devs getting laid ;)
    - amyjess 11y ago
      Hey, Ian Murdock did name Debian after him and his girlfriend...
      - buster 11y ago
        Whichever hand that was.. ;) (j/k i love Debian, i use it full time)
      - JupiterMoon 11y ago
        They did break up though.
        nickpsecurity 11y ago
        This whole sub-thread: DAAAAAAMN! Haha. Let it be a warning to OSS developers thinking of mixing business and pleasure. Except for the pleasure of coding. :)
  - astrodust 11y ago
    It's one of those old "jokes", like the SEX instruction: https://en.wikipedia.org/wiki/SEX_(computing) https://en.wikipedia.org/wiki/SEX_(computing)
decafbad 11y ago
What's byhand?
- detaro 11y ago
  BYHAND are uploads that are not normal packages and need manual intervention to be processed.
nickpsecurity 11y ago
What trips me out about this is that SPARC is one of the most open of the legacy ISA's. It doesn't have so much baggage like Intel. It's RISC. It's documented well even for firmware writers, unlike Intel's black boxes. The license to use the name cost $100 rather than ~$1 mil for MIPS or $1-15mil for ARM. The top, proprietary offerings scream with performance and reliability. There are also multiple open-source versions that can run on FPGA's and one which gets fabbed. And, unlike OpenRISC or RISC-V, you get a whole ecosystem of code and toolsbuilt for the architecture. Now, I understand people not buying it for desktops when they want to run browsers, flash, etc. However, it's strange for a crowd (Linux in general) that's historically about promoting openness and fighting black boxes to have so little uptake of an ISA like SPARC. Then a popular one drops it due to nobody maintaining it. A demand side of the equation like that is why few companies build or open better ISA's. The vendors think most are all talk and no wallet on the issue if it's about hardware.
- JoshTriplett 11y ago
  Having learned SPARC assembly in the past, it most certainly does have a pile of backward-compatibility baggage of its own. For instance, https://en.wikipedia.org/wiki/Delay_slot https://en.wikipedia.org/wiki/Delay_slot
  - mzs 11y ago
    It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter? For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too?
    - JoshTriplett 11y ago
      > It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter? That's not relevant for current processors; it only matters if you need to support older processors, and in any case you always use the most capable interface provided by your processor. The older interface only matters if you support processors that are well over a decade old. Current processors have to support old software; current software need not support old processors. So unless you're hacking on the guts of the Linux syscall layer... > For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too? Cyrix doesn't exist anymore, and VIA doesn't appear to have any current-generation hardware. So, unless you used to work on them and you have to avoid regressions, you can almost certainly safely ignore legacy hardware, just as you shouldn't optimize code for the Pentium 4 anymore. Especially if you're writing 64-bit code.
yellowapple 11y ago
Well darn; I guess now I can't run Debian on my Sun Fire T2000. Not that I particularly care, since I've found OpenBSD to be much better on non-x86 (particularly SPARC and PowerPC) hardware than pretty much every GNU/Linux distro I've tried (Debian included), but it's still unfortunate; diversity is nice to have in a platform, even if I'm pretty happy in BSD-land. Oh well. Perhaps if us SPARC users are lucky, more illumos distros will start supporting SPARC. Tribblix looks interesting; if I can ever get my Blade 1500 running again, I'll have to try that one out on it.

64 points by buster 11y ago

The linked message says it could come back as sparc64 - the Debian port was a 32 bit userspace, optionally 64 but kernel, while on new sparc machines you probably would want to use sparc64 userspace. For embedded/fpga sparc it is less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on sparc than Linux.

dmm 11y ago
This port only ran on 64-bit machines. Support for 32-bit sparc cpus was dropped years ago.

4ad 11y ago

Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian does not have an official SPARC64 port (it has an unofficial one).

dmm 11y ago
Support for 32-bit sparc was dropped years ago. This was the port for 64-bit machines even though it used a 32-bit userland.
- deleted 11y ago
  [deleted]

justaaron 11y ago

what about openSPARC, one of the only truly open cpu designs one can load into an fpga

nickpsecurity 11y ago
And the Gaisler Aeroflex cores that are both open-source and fabbed onto boards they sell. People who want open hardware can get a bit closer with a 4-core SPARC board. :)
4ad 11y ago
openSPARC was amazing at the time, but now the last published design is almost a decade old, and last I tried a few months ago I couldn't even download everything that was necessary to load it on an FPGA. Not to mention that the reference software you could run on that FPGA is not available any more.

DonHopkins 11y ago

CRAPS!

yrmt 11y ago

NetBSD welcomes all SPARC owners

rurban 11y ago

Very likely wrong alignment. This causes hard SIGBUS faults, and SPARC64 is one of the good platforms to catch such misaligned pointers. You cannot repro it in qemu on Intel. But I don't know what ElfW(Rel) expands to. Maybe only a 4byte word, not 8. The backtrace doesn't display the register content (THANKS gdb maintainers), and the op didn't provide the registers neither. 0xfffff8010000cda4 in elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out> https://lists.debian.org/debian-sparc/2015/07/msg00013.html https://lists.debian.org/debian-sparc/2015/07/msg00013.html

dmm 11y ago

I spent a lot of time in the past few months trying to fix enough of the issues with Debian/SPARC to keep it from having to be removed. Honestly the port isn't in terrible shape. The specific problems listed as reasons for removing it are exaggerated. GCC is not dropping 32-bit SPARC code generation and the kernel works well overall. There were a few issues causing a lot of breakage, in particular, a register corruption bug in the kernel memcpy routine and a problem with the gold linker that was corrupting string literals in certain cases. Those two bugs blocked everything depending on nettle or qt, 800+ packages. The real issue is that Debian has high expectations that take maintenance to fulfill. Particularly with the autobuilders, the machines that produce binary packages from source. When a build fails there needs to be somebody that fixes the problem. If an autobuilder crashes it can be restarted but if it's crashing every day there needs to be someone to track down the problem. If there is nobody responding to issues it's ok for a while. The people responsible for packages and the autobuilder infrastructure work around problems where they can (running old kernels) but eventually it becomes too much to ask. So I don't like this decision but it's understandable. The specific problems are exaggerated but the fundamental one isn't: nobody was doing the work to keep everything together.

nothrabannosir 11y ago
> The real issue is that Debian has high expectations that take maintenance to fulfill. Without meaning to diminish your insightful post and good point: as a Debian user, I have to say, this does not sound like an issue to me.
- dmm 11y ago
  Sorry if it wasn't clear but I specifically meant the issue for the sparc port. I was not criticizing Debian in any way.

w8rbt 11y ago

OpenBSD still supports it. It's very stable too.

dmm 11y ago
It supports cool stuff like acting as an ldom host too. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sparc64/ldomd.8?query=ldomd http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...
- stsp 11y ago
  Better documentation link which shows how to set it all up: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sparc64/ldomctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...
- yellowapple 11y ago
  Huh, and here I was figuring that switching Solaris to OpenBSD on my SPARC hardware would mean not getting to tinker with logical domains anymore. I'm glad to see that my assumptions are incorrect, and that my Sun Fire T2000 will have an actual reason to be running in all its loud, jet-engine-sounding glory :)
justin66 11y ago
Supports some hardware that Linux never did, as well.

omginternets 11y ago

><liw> HE, we had sex in Debian for many years, yes, before I put a stop to it Could someone explain wtf this means?

baghira 11y ago
Probably related to the "Simple editor for X".
- omginternets 11y ago
  Ah, that makes more sense than OSS devs getting laid ;)
  - amyjess 11y ago
    Hey, Ian Murdock did name Debian after him and his girlfriend...
    - buster 11y ago
      Whichever hand that was.. ;) (j/k i love Debian, i use it full time)
    - JupiterMoon 11y ago
      They did break up though.
      - nickpsecurity 11y ago
        This whole sub-thread: DAAAAAAMN! Haha. Let it be a warning to OSS developers thinking of mixing business and pleasure. Except for the pleasure of coding. :)
- astrodust 11y ago
  It's one of those old "jokes", like the SEX instruction: https://en.wikipedia.org/wiki/SEX_(computing) https://en.wikipedia.org/wiki/SEX_(computing)

decafbad 11y ago

What's byhand?

detaro 11y ago
BYHAND are uploads that are not normal packages and need manual intervention to be processed.

nickpsecurity 11y ago

What trips me out about this is that SPARC is one of the most open of the legacy ISA's. It doesn't have so much baggage like Intel. It's RISC. It's documented well even for firmware writers, unlike Intel's black boxes. The license to use the name cost $100 rather than ~$1 mil for MIPS or $1-15mil for ARM. The top, proprietary offerings scream with performance and reliability. There are also multiple open-source versions that can run on FPGA's and one which gets fabbed. And, unlike OpenRISC or RISC-V, you get a whole ecosystem of code and toolsbuilt for the architecture. Now, I understand people not buying it for desktops when they want to run browsers, flash, etc. However, it's strange for a crowd (Linux in general) that's historically about promoting openness and fighting black boxes to have so little uptake of an ISA like SPARC. Then a popular one drops it due to nobody maintaining it. A demand side of the equation like that is why few companies build or open better ISA's. The vendors think most are all talk and no wallet on the issue if it's about hardware.

JoshTriplett 11y ago
Having learned SPARC assembly in the past, it most certainly does have a pile of backward-compatibility baggage of its own. For instance, https://en.wikipedia.org/wiki/Delay_slot https://en.wikipedia.org/wiki/Delay_slot
- mzs 11y ago
  It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter? For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too?
  - JoshTriplett 11y ago
    > It's really not all that bad, there's also the cache coloring and memory ordering stuff, but it's well documented at least. There is a lot more historical baroque stuff about x86, like int 80, syscall, or sysenter? That's not relevant for current processors; it only matters if you need to support older processors, and in any case you always use the most capable interface provided by your processor. The older interface only matters if you support processors that are well over a decade old. Current processors have to support old software; current software need not support old processors. So unless you're hacking on the guts of the Linux syscall layer... > For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too? Cyrix doesn't exist anymore, and VIA doesn't appear to have any current-generation hardware. So, unless you used to work on them and you have to avoid regressions, you can almost certainly safely ignore legacy hardware, just as you shouldn't optimize code for the Pentium 4 anymore. Especially if you're writing 64-bit code.

yellowapple 11y ago

Well darn; I guess now I can't run Debian on my Sun Fire T2000. Not that I particularly care, since I've found OpenBSD to be much better on non-x86 (particularly SPARC and PowerPC) hardware than pretty much every GNU/Linux distro I've tried (Debian included), but it's still unfortunate; diversity is nice to have in a platform, even if I'm pretty happy in BSD-land. Oh well. Perhaps if us SPARC users are lucky, more illumos distros will start supporting SPARC. Tribblix looks interesting; if I can ever get my Blade 1500 running again, I'll have to try that one out on it.