From kris at FreeBSD.org Thu Sep 4 00:04:19 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Sep 4 00:04:26 2008 Subject: sun4v status In-Reply-To: References: <20080830082702.GL86609@server.vk2pj.dyndns.org> <48B90B68.80802@FreeBSD.org> <3c1674c90808301418n4fa0691fo30d61cc3e6595862@mail.gmail.com> Message-ID: <48BF2601.7000307@FreeBSD.org> Sevan / Venture37 wrote: > the system would flip out when there was even the slightest load on the disk with mpt0: queue full event messages, > tweaking the system settings with camcontrol reduced the frequency of this but resulted in dataloss when it did occur > > http://www.zulustips.com/2007/09/06/mpt0-queue-full-event-on-dell-sas-5ir.html#more-53 > _________________________________________________________________ > Win New York holidays with Kellogg?s & Live Search > http://clk.atdmt.com/UKM/go/107571440/direct/01/ > There were bugs in the interrupt handling on sun4v that were introduced at some point but I thought were fixed again. I don't remember if it was before or after this post from a year ago. Anyway there are likely to be various other issues that crop up once/if the port becomes minimally usable, so it shouldn't be seen as only needing a single bugfix. Kris From darrenr at freebsd.org Mon Sep 8 08:30:59 2008 From: darrenr at freebsd.org (Darren Reed) Date: Mon Sep 8 08:31:11 2008 Subject: the future of sun4v In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> Message-ID: <48C4DEEF.7070201@freebsd.org> 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 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 freebsd.org 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? Darren From darrenr at freebsd.org Mon Sep 8 08:30:59 2008 From: darrenr at freebsd.org (Darren Reed) Date: Mon Sep 8 08:31:21 2008 Subject: the future of sun4v In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> Message-ID: <48C4DEEF.7070201@freebsd.org> 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 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 freebsd.org 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? Darren From peterjeremy at optushome.com.au Mon Sep 8 19:55:01 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Sep 8 19:55:14 2008 Subject: the future of sun4v In-Reply-To: <48C4DEEF.7070201@freebsd.org> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> <48C4DEEF.7070201@freebsd.org> Message-ID: <20080908195457.GD15376@server.vk2pj.dyndns.org> [cc list trimmed] On 2008-Sep-08 01:14:39 -0700, Darren Reed wrote: >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? Right now it doesn't. And based on some previous threads, there is a lot of redesign to do before it can. But stability needs to come before scalability. There's no point in FreeBSD pretending it can support some arbitrary number of CPUs when it panics due to races in one of the CPU subsystems - which is my understanding of the current sun4v state. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sun4v/attachments/20080908/de5ce14c/attachment.pgp