On 02/09/2011 09:28 AM, matthew.r.chedis...@l-3com.com wrote: > I definitely believe it to be a problem on the IMPI or even BMC on the > target machine, and not an getty/init issue on the polling machine. > > When I say locked out, I mean that in the sense that any ipmitool > command results in: > > "Error in open session response message : insufficient resources for > session" You might be surprised. The BMC may be waiting for the CD signal to be dropped before releasing the resources. I'd still consider that a bug or an "undesirable feature" on the BMC. IMHO it should allow a new connection as soon as the previous one has dropped.
As far as 15 sessions, that's just what the spec allows. As Andy said, I doubt there are many boards that allow more than one, and to allow more than one you would have to have a serial port for each of them. As handy as that might be, I can't see it happening. -corey > > Also apologies to Mahesh, I feel I have usurped this thread. > > > -Matt Chedister > > -----Original Message----- > From: Andy Cress [mailto:andy.cr...@us.kontron.com] > Sent: Wednesday, February 09, 2011 10:15 AM > To: Chedister, Matthew R @ SSG - Link; mahesh.kurap...@emerson.com; > ipmitool-devel@lists.sourceforge.net > Subject: RE: [Ipmitool-devel] SoL sessions over the same > LANchannelsimultaneously. > > There can be many (15) IPMI LAN 2.0 (lanplus) sessions for normal IPMI > commands, but I have never seen an IPMI firmware implementation that > allowed more than one simultaneous SOL payload session. If an SOL > session exists, the other SOL attempts get an error. > > About opening and closing SOL sessions rapidly: > First check to make sure that you are not using getty on each session. > If so, the Linux init process will give you 'respawning too rapidly' and > disable the getty login for about 5 minutes. > If you do in fact have a pre-logged-in shell for the serial console, and > are not having the getty issue, it sounds like it could be a firmware > problem with tear-down of the SOL session. > > Andy > > -----Original Message----- > From: matthew.r.chedis...@l-3com.com > [mailto:matthew.r.chedis...@l-3com.com] > Sent: Wednesday, February 09, 2011 9:42 AM > To: mahesh.kurap...@emerson.com; ipmitool-devel@lists.sourceforge.net > Subject: Re: [Ipmitool-devel] SoL sessions over the same > LANchannelsimultaneously. > > > > -----Original Message----- > From: Chedister, Matthew R @ SSG - Link > Sent: Wednesday, February 09, 2011 9:32 AM > To: 'mahesh.kurap...@emerson.com'; ipmitool-devel@lists.sourceforge.net > Subject: RE: [Ipmitool-devel] SoL sessions over the same LAN > channelsimultaneously. > > I am curious to this limit as well. > > I have ran into trouble opening and closing SOL connections too rapidly > for a single target machine. (for the purposes of periodically running > expect scripts to obtain operating system information). I found that if > I didn't spread my SOL sessions out over 15 seconds between sessions, > the IPMI on the target machine locks me out for up to 15 minutes. > > I wonder if your 15 SOL instance max is related to what I've found about > consecutive SOL sessions. > > > -Matt Chedister > > -----Original Message----- > From: mahesh.kurap...@emerson.com [mailto:mahesh.kurap...@emerson.com] > Sent: Wednesday, February 09, 2011 9:21 AM > To: ipmitool-devel@lists.sourceforge.net > Subject: [Ipmitool-devel] SoL sessions over the same LAN > channelsimultaneously. > > Hello List, > > As per the IPMI2.0 we can have a max of 15 SoL payload instances for a > particular LAN channel. But it is not clear on whether they can be > accessed simultaneously. Can somebody help me in understanding this? > > Thanks in advance. > > Regards > Mahesh Kurapati > > ------------------------------------------------------------------------ > ------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio > XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > ------------------------------------------------------------------------ > ------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio > XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
