Really amazing work there. Keep it up!
Bryan On Jul 30, 2012 8:14 AM, "Martin Bochnig" <mar...@martux.org> wrote: > Hi, > > > 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 > THANKS!). > > > BTW: If you visit Oracle's site, SPARC is still quite well and kicking. > > http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/t-series/sparc-t4-processor-ds-497205.pdf > > > 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 > > (U1/U2/U5/U10/U30/U60/U80/SB100/SB150/SB1000/SB1500R/SB1500S/SB2000/SB2500R/SB2500S/Tadpole > 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, > > > regards, > > Martin > > > > > > On Sun, Jul 29, 2012 at 4:51 PM, Jim Klimov <jimkli...@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@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > _______________________________________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
