the future of sun4v

Darren Reed darrenr at
Mon Sep 8 08:30:59 UTC 2008

Marius Strobl wrote:
> On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote:
> > Peter Jeremy wrote:
> > >[Replies re-directed to freebsd-sun4v]
> > >
> > >On 2008-Aug-21 14:42:55 -0700, Kip Macy <kmacy at> wrote:
> > >>I believe that there is a general expectation by freebsd users and
> > >>developers that unsupported code should not be in CVS. Although sun4v
> > >>is a very interesting platform for developers doing SMP work, I simply
> > >>do not have the time or energy to maintain it. If someone else would
> > >>like to step up and try his hand I would be supportive of his efforts.
> > >>In the likely event that no one steps forward by the time that 7.1 is
> > >>released I will ask that it be moved to the Attic.
> > >
> > >Since there are no other current SPARC CPUs that FreeBSD can run on
> > >(the US-II has been obsolete for about 6 years and FreeBSD won't run
> > >on any more recent sun4u chips), that will also remove the
> > >justification for maintaining a SPARC64 port.
> > >
> > >I don't have the knowledge or available time to maintain the sun4v
> > >port by myself but would be happy to be part of a team doing so.  One
> > >impediment I have is that I don't have a T-1 or T-2 system that I can
> > >dedicate to FreeBSD.  I could work on FreeBSD in a guest domain - but
> > >since FreeBSD doesn't support either the virtual disk or virtual
> > >network, actually getting FreeBSD running there presents somewhat of a
> > >challenge.
> > >
> > 
> > There are two t1000 systems in the cluster that are 
> > available for people to work on.  Rink Springer has also expressed 
> > interest in this.
> > 
> > Perhaps Kip can explain some more about what things he looked at, but 
> > the most serious bugs might be in pmap or perhaps trap handling. 
> > Operationally, things like buildworld -jN die quickly with random 
> > signals, kernel traps, etc.
> > 
> > Kris
> > 
> > P.S. It looks like marius has made progress on US III but sun4u is still 
> > an architectural dead end.
> Well, let's see what architecture the upcoming Rock CPUs are;
> judging their feature list they appear to be a continuation of
> the Fujitsu sun4u line rather than a successor of UST1/2 :)

That's inaccurate. Rock is meant to be very compatible with
sun4v, although I don't know if uname will say "sun4v" or
something else...but you will need a bug-free sun4v operating
system to run them (which is to say that various bugs in the
solaris sun4v support needed to get fixed rather than left...)

The critical issue for freebsd (and any operating system for
that matter) on rock is how well does the kernel scale to a
system with that many concurrent threads?


More information about the freebsd-stable mailing list