[OpenIndiana-discuss] OpenSolaris on SPARC

Martin Bochnig martin at martux.org
Mon Jul 30 06:13:23 UTC 2012


yes, I resumed work a few weeks ago.
X11:  problem solved(!)

And weather SPARC is dead or not, I still have 18 SPARC boxes here in my room.
Fully equipped with all existing frame buffers that ever existed
(except XVR-200, XVR-300, XVR-1000 and XVR-1200 at this time, because
I had sold them).
I also have a T1000 now with PCIe x1 to x16 Adapter. Although this box
has not even USB and only a single narrow PCEe slot, I could test the
XVR-2500 that way. And OBP detects it as boot-console, although the
T1000 was never intended to run in a non-headless configuration

On SPARC I no longer fiddle with libdevinfo, libpciaccess and Xorg
(weather libpciaccess based or old xserver 1.2), but instead I
focussed on getting Xsun to function, which Alan  Coopersmith has
thankfully opensourced 2 years ago in his spare time, just in the
first, last and probably only ever moment it was possible (BIG

BTW: If you visit Oracle's site, SPARC is still quite well and kicking.

Or which other vendor can offer a comparable CPU with up to 64 threads
running at up to 3.0GHz?
Letting alone the low power consumption per cycle.

My only problem with Illumos as code-base is, that much stuff
belonging to legacy SPARC hardware (which includes all workstations)
seems to have been dropped from Illumos.At least that was my first
impression a month ago.  And for this reason I based my initial
version of SPARC-OpenIndiana on Nevada 125 for the first demo release.

That way I intend to convince folks, that we should merge in the
missing platform specific pieces.
But one step after another.

After I had promised things in the past, this time I did not want to
make _any_ public announcement, until the SPARC-OI demo iso is ready
for download.
Now that you started such a thread, staying silent was no longer an option.
Yeas, there will be SPARC-OI.
My personal goal is and always has been, that we can offer a
functioning X-Windows.
So it shouldn't be a server-only release, limited to serial console/RSC/Alom.
And thanks to Alan's openXsun open-sourcing contribution, this dream
has *finally* come true.
The code can be found at
http://dlc.sun.com/osol/x/downloads/openXsun/openXsun.tar.bz2 and is a
stripped cut-down version. But meanwhile I added some missing
functions to build/link it sucessfully. Plus it even functions now on
my test machines
SPARCle/T1000). It only took a few days and was a child's game when
compared to what is required to modify libdevinfo/libpciaccess/Xorg to
get only a small number of frame buffers working, with  instabilities,
minute-long PCI-scanning delays, crashes and bus errors.
openXsun works now with my additions and it is a heaven's gift.

Please give me 4 weeks for the preliminary SPARC-OI release.
Everything incl. of course the src modifications will be released.
Thanks for your patience,



On Sun, Jul 29, 2012 at 4:51 PM, Jim Klimov <jimklimov at cos.ru> wrote:
> Hello all,
>   There are some discussions about whether illumos on SPARC is
> a dead-end or not (i.e. whether it is stupid to buy HW systems
> from the one vendor and not buy their software support, or if
> there is more than one vendor, or if anyone would pick up the
> open-sourced processor designs for the Niagaras and build some
> cool appliances or servers). So, just for the anecdotal sake,
> I wanted to share this weekend's experience about OpenSolaris
> on SPARC - and how it saved the day.
>   While it may seem unlikely at this moment that new SPARC
> systems would be rolled out for OI to get installed on them,
> there are many already-deployed reliable boxes which would
> run obsolete (or our new) software "until they fscking die".
>   I was asked to look at a T2000 with Sol 10u8 which did just
> that: it died during what could have been fsck - if ZFS had
> one. Apparently, the system's users did nothing formally
> invalid, they were just zfs-sending and zfs-receiving some
> datasets within the pool in order to recompress older data
> with gzip-9, then they tried to destroy the older dataset
> tree and rename the compressed copy to take its place.
> Something went wrong, the pool locked up with no IOs taking
> place (according to iostat). The "zfs" commands all hung,
> however "zpool status" and friends did not. Filesystem
> operations also went well, so running zones were properly
> stopped and the box was ultimately rebooted. It did not
> come back up.
>   Luckily, there was a Solaris installation server in
> that network, so it took a few minutes to prepare a LAN
> installation resource from a stashed SXCE snv_129_sparc
> image, and boot the T2000 from the network, into single
> user mode. OpenSolaris found nothing suspicious about
> the data pool and the rpool, imported and exported them
> without complaints. While at the rpool, we deleted the
> /etc/zfs/zpool.cache file to allow the system to boot
> its Solaris 10. It booted, but also hung at subsequent
> "zpool import -R / pool" request - in the same way:
> no iostat operations to report, and no errors in the
> logs...
>   Back to the networked boot of OpenSolaris, where we
> imported the data pool, destroyed the remaining old
> uncompressed datasets and completed the renaming of
> compressed datasets to take place of those ones,
> transparently to the zones and other consumers.
> This did unclog something, so the Solaris 10 image
> did afterwards quickly import the pool and happily
> uses it today.
>   Yesterday the old OpenSolaris SXCE for SPARC did
> save the day. I can easily imagine hitting some bugs
> in ZFS that were fixed after the last SXCE release,
> where a hypothetical "OpenIndiana for SPARC" image
> would be able to save us - even if it is not (yet)
> used as the everyday OS for the box.
> Hope this story entertains someone and helps others,
> //Jim Klimov
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

More information about the OpenIndiana-discuss mailing list