Re: [Fedora-sparc] sparc koji
by Xose Vazquez Perez
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_com...>
--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--
8 years, 5 months
Fwd: Re: SPARC Project Maintenance
by Bryce
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)
=--=
11 years, 3 months
SPARC Project Maintenance
by Dafydd Crosby
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
11 years, 3 months