[openib-general] Announce: preview RPMs for FC-4 and RHEL-4 available

[Hal Rosenstock]

Hi Doug,

On Fri, 2005-11-18 at 08:47, Doug Ledford wrote:
> Thomas Moschny wrote:
> 
> > The patch seems to work here, thanks. The machines are up now, and at least 
> > IPoIB is working.
> 
> I should have new kernels on the site sometime today (version 
> OpenIB_3965.3) that fix this.  I only have enough quota space for one 
> set of kernel rpms, so once they are up, the others are gone.
> 
> > There seems to be a (minor?) problem with opensm -o, it aborts:
> 
> [ Snip ]
> 
> > Exiting SM
> > 
> > *** glibc detected *** double free or corruption (!prev): 0x6000000000067970 
> > ***
> > Aborted
> > 
> > Subsequent runs of opensm hang in flush_cpu_workqueue or 
> > rwsem_down_failed_common.
> 
> BTW, can you try forcing opensm to run single threaded on it's first 
> invocation and see if that fixes this?
> 
> Also, do people generally feel that opensm is stable enough to start 
> converting it to a proper system daemon?

At this point, my opinion is that it's good for small networks and more
stable larger networks (I will get you the scale in a subsequent email
if that is of interest). It still has a little ways to go before I would
say it is ready for prime time. That's just my assesment after coming
back from SC05 but there were a lot of flaky links and a lot of new
equipment as well as a lot of different equipment never before put
together on that scale. More will follow on the list. However, see
comment below...

>   By that I mean things like not 
> having it spew a bunch of informational messages to stdout when in 
> daemon mode, putting in an actual daemon option, ability to write and 
> handle a pid file, handling of putting itself in the background and 
> disassociating from the controlling tty, etc.  If so, I'll start coding 
> that up and send through a patch.  The current init.d startup script has 
> some rather ugly hackery to get around the current opensm's very daemon 
> unfriendly behavior...

I think these would all be good improvements (and some were mentioned at
SC05) so I would appreciate patches for these to move OpenSM forward as
quickly as possible.

Thanks.

-- Hal