sparc December 2012

sparc@lists.fedoraproject.org

2 participants
3 discussions

Re: [Fedora-sparc] sparc koji
by Xose Vazquez Perez 09 Oct '15

09 Oct '15

Rafal Maszkowski wrote: > I mirror the Oracle OEL (on this new machine). I have asked people > propagating this distribution about OEL on Sparc but got no answer. > Weird - they want to have their own RHEL and they produce Sparc machines > but cannot (do not want?) connect these two things together.[...] <http://www.pcworld.com/article/212564/ellison_oracle_enterprise_linux_comin…> --cut-- Ellison: Oracle Enterprise Linux Coming to Sparc By James Niccolai, IDG News Dec 6, 2010 9:00 pm Oracle will port its Enterprise Linux distribution to Sun's Sparc processor, a move that could help it compete better against IBM and Hewlett-Packard in the high-end server business. CEO Larry Ellison made the disclosure in response to a question about Oracle's Linux strategy at the company's Sparc systems launch last Thursday. "We think Sparc will become clearly the best chip for running Oracle software. At that point we'd be nuts not to move Oracle Enterprise Linux there. We're a ways away, but I think that's definitely going to happen," Ellison said. It's likely to happen in "the T4, T5 timeframe," he said, referring to the next two versions of Sun's Sparc processor. Oracle just released the Sparc T3 in September and the T4 isn't expected for a year or so. Customers who buy Oracle's x86 servers today can run both Solaris and Oracle Enterprise Linux, but for Oracle's Sparc systems, Solaris is the only supported OS. "Some customers have run Linux on Sparc, but it's mostly in the high-performance computing market and it's not a supported environment," said IDC analyst Jean Bozman. That puts Oracle at odds with IBM and HP, whose customers can run both Unix and Linux on those companies' high-end servers. "You have both HP and IBM ... being able to offer their customers Linux and their proprietary Unix on the same hardware, and that gives them additional opportunities for customers running virtual environments," said Nathan Brookwood, principal analyst at Insight64. IBM customers, for example, can take a single Power7 system and run Linux, AIX and IBM's System i software under a common hypervisor. "In the world of virtualized data centers, being able to run all your major OS environments on your major hardware platform gives end users a little bit more flexibility," Brookwood said. Linux was Oracle's preferred OS before it acquired Sun. Ellison now calls Solaris "the leading OS on the planet," but he knows some customers want a choice. He wants that choice to be among Oracle products, however, not among different vendors. "We want [customers] thinking, 'Should I go with Sparc or should I go with x86? Should I run it on Solaris or should I run it on Linux?' End of discussion," Ellison said. "We don't want them thinking, 'Should I move from Sparc to Power or Solaris to AIX.' We want to give them choice within our own family of products." Ellison also introduced a new category of support, called Gold Standard Services, for customers who are willing to run their Oracle systems with exactly the configuration Oracle suggests. Oracle will test each new software upgrade and big fix against the Gold configurations in its labs, Ellison said. That should allow it to guarantee higher levels of uptime for customers, he suggested. The first "gold configurations" will be for the big integrated systems Oracle has announced recently -- the Exadata Database Machine, the Exalogic Elastic Cloud and the Sparc Supercluster. It expects to include partner products too. "We're going to have IBM, Dell and Cisco join in and create those Gold Standard configurations," Ellison said. He didn't give any pricing information and Oracle didn't respond to a request for more details. --end--

1 1

Fwd: Re: SPARC Project Maintenance
by Bryce 07 Dec '12

07 Dec '12

On 03/12/12 21:33, Dafydd Crosby wrote: > On Mon, Dec 3, 2012 at 2:17 PM, Bryce <bryce(a)zeniv.linux.org.uk > <mailto:bryce@zeniv.linux.org.uk>> wrote: > > On 03/12/12 20:20, Dafydd Crosby wrote: > > Hello, > > I've been told on the IRC channel that the SPARC project is > looking > > for a maintainer. I've got a SunBlade 2500 and experience > building and > > maintaining RPM's, so if someone could let me know what needs to get > > done, I'd be happy to do it. > > > > -Dafydd Crosby > > > Atm I'm loking into the fc18 build environment that would be used to > bootstrap the whole fc18 build,.. there is a chunk of broken > madness in > the binutils ld.so which I'm bisecting atm, I might have that fixed or > at least properly identified if I dunno what the answer to it is by > tomorrow. Thers also something a bit odd going on with gcc which stops > c++ being recompiled. glibc has a unprotected header (memcopy.h) that > you need to fit a #ifndef _MEMCOPY_H, #define _MEMCOPY_H, #endif > around. > Then to get past a few other items you need to compile gcc > statically,.. > > Later on, kernelwise there is a pita where an asumption is made that > adressing is by 42bits when in actual fact it should be 48 leading to > spurious kernel hangs,.. loads and loads of other 'close but not > right' > problems,.. I'm working through them but it's gonna be at least a > week, > possibly two, before I have a buildroot environment ready to bootstrap > everything. (simplistic overview) > > Not to mention the pile of catch 22 chicken egg shared lib > broblems. Joy. > > I also need to extricate a reasonably speced sparc into the community > ring from the lab. (endless paperwork and trying to convince folk to > authorise) as the sparcs that are currently used are looking somewhat > long in the tooth compared to. There is a ton of other administrative > paperpushing going on in the background that would make European > beurocrats blush. It's unfortunately just been slow getting it > moving 8( > > On the plus side I do have a static 2.7.2 gcc c compiler compiled up > though I'm using that to attack the ld.so problem I mentioned above. > > > Phil > =--= > > > Awesome! My machine's not exactly high-power, but I can throw it on > Koji at least to get the ball rolling. > (slight correction to the above,.. not 42bit... 41 bits) might need more time that I envisaged, glibc has a bit of work to be done to it when you compare it to whats in the fc18 repo for Intel architecture. Once I've enough to get a 1/2way sane environment going I'll punt that over to the tools folk to sift through and try and fix it up a bit better since glibc isn't my development niche. (html table follows) x86_64 glibc (2.16-26.fc18) sparc glibc-2.16-26.1.fc18 ISO... ISO99... Total number of tests : 1776 Number of failed tests : 4 ( <1%) Number of skipped tests : 0 ( 0%) ISO11... Total number of tests : 1840 Number of failed tests : 4 ( <1%) Number of skipped tests : 0 ( 0%) POSIX... XPG3... Total number of tests : 4418 Number of failed tests : 281 ( 6%) Number of skipped tests : 158 ( 3%) XPG4... Total number of tests : 4463 Number of failed tests : 189 ( 4%) Number of skipped tests : 86 ( 1%) UNIX98... Total number of tests : 4696 Number of failed tests : 58 ( 1%) Number of skipped tests : 37 ( <1%) XOPEN2K... Total number of tests : 6168 Number of failed tests : 24 ( <1%) Number of skipped tests : 11 ( <1%) XOPEN2K8... Total number of tests : 5499 Number of failed tests : 19 ( <1%) Number of skipped tests : 4 ( <1%) POSIX2008... Total number of tests : 5692 Number of failed tests : 14 ( <1%) Number of skipped tests : 2 ( <1%) DEBUG: ISO... DEBUG: ISO99... DEBUG: Total number of tests : 1776 DEBUG: Number of failed tests : 4 ( <1%) DEBUG: Number of skipped tests : 0 ( 0%) DEBUG: ISO11... DEBUG: Total number of tests : 22 DEBUG: Number of failed tests : 22 (100%) DEBUG: Number of skipped tests : 22 (100%) DEBUG: POSIX... DEBUG: Total number of tests : 2696 DEBUG: Number of failed tests : 3 ( <1%) DEBUG: Number of skipped tests : 0 ( 0%) DEBUG: XPG3... DEBUG: Total number of tests : 4418 DEBUG: Number of failed tests : 281 ( 6%) DEBUG: Number of skipped tests : 158 ( 3%) DEBUG: XPG4... DEBUG: Total number of tests : 4463 DEBUG: Number of failed tests : 189 ( 4%) DEBUG: Number of skipped tests : 86 ( 1%) DEBUG: UNIX98... DEBUG: Total number of tests : 4696 DEBUG: Number of failed tests : 59 ( 1%) DEBUG: Number of skipped tests : 37 ( <1%) DEBUG: XOPEN2K... DEBUG: Total number of tests : 6168 DEBUG: Number of failed tests : 25 ( <1%) DEBUG: Number of skipped tests : 11 ( <1%) DEBUG: XOPEN2K8... DEBUG: Total number of tests : 5499 DEBUG: Number of failed tests : 20 ( <1%) DEBUG: Number of skipped tests : 4 ( <1%) POSIX2008... DEBUG: Total number of tests : 5692 DEBUG: Number of failed tests : 17 ( <1%) DEBUG: Number of skipped tests : 2 ( <1%) 2 Extra tests 1000's of tests not run? why? Not entirely sure whats going on here... sparc is running POSIX tests but the Intel side didn't? One extra failure One extra failure One extra failure Three extra failures as for elfutils,.. the testsuite for 'elflint' fails spectacularly, fortunately I haven't come across anything that wants to use it in any anger so I've removed it from the sparc build until someone with far more ELF knowledge, (which would basically be anyone else), can figure out what it's issues are. I'm really hoping the errors it's spewing out are just alarmist and not deathly serious. The processor specific flag bit might well be down to me using a sparc T4. Oh well,.. <mock-chroot>[root@localhost tests]# make check-TESTS TESTS="run-elflint-self.sh" section [ 5] '.dynsym': symbol 45: st_value out of bounds section [36] '.symtab': symbol 128: st_value out of bounds *** failure in ../src/addr2line section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/elflint section [ 5] '.dynsym': symbol 195: st_value out of bounds section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format section [38] '.symtab': symbol 474: st_value out of bounds *** failure in ../src/ld section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/readelf section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/strip loadable segment [7] flags do not match GNU_RELRO [1] flags section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format section [38] '.symtab': symbol 310: st_value out of bounds *** failure in ../libelf/libelf.so section [35] '.gnu.attributes' has wrong flags: expected none, is section [35] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [35] '.gnu.attributes': unrecognized attribute format *** failure in ../libdw/libdw.so FAIL: run-elflint-self.sh Ugh,... when I get all the rpms for the minimal buildroot done (~130 pkgs though they in turn need dependant packages so more like 600) I'll turn those over to Dennis and co. to see about importing them into a koji instance somewhere and then start the long slog of hand cranking the remaining rpms through the system. though I'll bet the farm on a lot of them not compiling happily at all for sparc. Certainly there is a pile of hurt to work through for stuff like rpm/filesystem. The real fun will start when we move onto Fc18's anaconda/silo, that is a whole new pit of snakes though I've a lot of the kinks already worked out. Suffice to say thers a lot of work,... not hard per se,.. just a lot of grunt work. Phil (desperately in need of sleep) =--=

1 0

SPARC Project Maintenance
by Dafydd Crosby 03 Dec '12

03 Dec '12

Hello, I've been told on the IRC channel that the SPARC project is looking for a maintainer. I've got a SunBlade 2500 and experience building and maintaining RPM's, so if someone could let me know what needs to get done, I'd be happy to do it. -Dafydd Crosby

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sparc December 2012