Zdenek,
I have updated the patch according to the Jim's changes. Nothing else to
do here.
Dmitry
28.05.2013 13:48, Zdenek Styblik пишет:
> Dmitry,
>
> I've committed your changes. However, I'm wondering about single/dual
> bridging functionality. Does fixing of ID#3611226 ``bridging code
> cleanup for PICMG platforms'' by Jim Mank imply it will work
> auto-magically now, or is there some work left to be done to make it
> work?
>
> Thanks for clarification,
> Z.
>
> --
> Zdenek Styblik
> email: zdenek.styb...@gmail.com
> jabber: zdenek.styb...@gmail.com
>
>
> On Tue, May 28, 2013 at 6:44 AM, Dmitry Bazhenov <dim...@pigeonpoint.com>
> wrote:
>> Agreed.
>>
>> 28.05.2013 10:41, Zdenek Styblik пишет:
>>
>>> On Tue, May 28, 2013 at 6:39 AM, Dmitry Bazhenov <dim...@pigeonpoint.com>
>>> wrote:
>>>>
>>>> Hello, Zdenek,
>>>>
>>>> There's a typo (and it's mine originally):
>>>>
>>>> enable_intf_serial=yes
>>>>
>>>> Needed:
>>>>
>>>> xenable_intf_serial=yes
>>>>
>>>> Regards,
>>>> Dmitry
>>>>
>>>
>>> Oh, I see Dmitry. However, the changes I've made seem to be required
>>> anyway, otherwise it gets borked. Please, check again.
>>>
>>> Thanks,
>>> Z.
>>>
>>>> 28.05.2013 10:35, Zdenek Styblik пишет:
>>>>
>>>>> On Fri, May 24, 2013 at 9:24 AM, Dmitry Bazhenov
>>>>> <dim...@pigeonpoint.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Zdenek,
>>>>>>
>>>>>> Here it is.
>>>>>>
>>>>>> Regards,
>>>>>> Dmitry
>>>>>>
>>>>>
>>>>> @@ -195,6 +196,23 @@
>>>>>
>>>>> ORIG_CPPFLAGS=$CPPFLAGS
>>>>>
>>>>> +dnl enable serial interface
>>>>> +AC_ARG_ENABLE([intf-serial],
>>>>> + [AC_HELP_STRING([--enable-intf-serial],
>>>>> + [enable direct Serial Basic/Terminal mode
>>>>> interface [default=yes]])],
>>>>> + [xenable_intf_serial=$enableval], [xenable_intf_serial=yes])
>>>>> +if test "x$enable_intf_serial" = "xstatic" || test
>>>>> "x$enable_intf_serial" = "xplugin"; then
>>>>> + enable_intf_serial=yes
>>>>> +fi
>>>>> +if test "x$xenable_intf_serial" = "xyes"; then
>>>>> + AC_DEFINE(IPMI_INTF_SERIAL, [1], [Define to 1 to enable serial
>>>>> interface.])
>>>>> + AC_SUBST(INTF_SERIAL, [serial])
>>>>> + AC_SUBST(INTF_SERIAL_LIB, [libintf_serial.la])
>>>>> + IPMITOOL_INTF_LIB="$IPMITOOL_INTF_LIB serial/libintf_serial.la"
>>>>> +else
>>>>> + xenable_intf_serial=no
>>>>> +fi
>>>>> +
>>>>> dnl look for OpenIPMI header files
>>>>> AC_ARG_WITH([kerneldir],
>>>>> [AC_HELP_STRING([--with-kerneldir=DIR],
>>>>> @@ -583,7 +601,8 @@
>>>>>
>>>>> Agreed?
>>>>>
>>>>> Z.
>>>>>
>>>>>
>>>>>> 24.05.2013 13:14, Dmitry Bazhenov пишет:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello, Zdenek,
>>>>>>>
>>>>>>>
>>>>>>> I'll provide the updated patch in a minute with your comments
>>>>>>> addressed.
>>>>>>> I'll add the double check you're talking about and remove the assert
>>>>>>> since they are redundant.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Dmitry
>>>>>>>
>>>>>>> 22.05.2013 14:55, Zdenek Styblik пишет:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 21, 2013 at 4:18 PM, Dmitry Bazhenov
>>>>>>>> <dim...@pigeonpoint.com> wrote:
>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would like not to place excessive check there in order not to
>>>>>>>>> overload the
>>>>>>>>> code. The surrounding context pretty much ensures that the
>>>>>>>>> conversion
>>>>>>>>> goes
>>>>>>>>> smoothly without errors.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Dmitry,
>>>>>>>>
>>>>>>>> I still disagree, because there is no reason why not to double check
>>>>>>>> it. I guess I'm paranoid like that. However, this was a suggestion
>>>>>>>> not
>>>>>>>> condition. If you say it's sufficient, then it's sufficient.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Is there some extra documentation necessary/required (and
>>>>>>>>>> available)
>>>>>>>>>> so this can be used/implemented/supported by other parties? But I
>>>>>>>>>> pretty much guessed this is just shoveling IPMI packets over serial
>>>>>>>>>> line, am I correct?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You are correct. It's just a way to interact with IPM Controllers. I
>>>>>>>>> don't
>>>>>>>>> think that anything more than the help string is required here.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Alright.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Good. Can you acknowledge that the patch will be submitted into the
>>>>>>>>> mainline?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know what exactly you meant by this question. If I'm the one
>>>>>>>> doing the commit, then yes. I have no problem to commit this into
>>>>>>>> ipmitool.
>>>>>>>>
>>>>>>>> Ok, I have one more question. serial_read_line() and
>>>>>>>> serial_write_line() have assert(str). Is this on purpose? Why? Are
>>>>>>>> you
>>>>>>>> aware it's going to crash the program? I'm not in favour of doing
>>>>>>>> such
>>>>>>>> thing. Since both functions return int, couldn't it be possible to do
>>>>>>>> without assert()?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Z.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> No more comments below.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Dmitry
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Z.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Dmitry
>>>>>>>>>>>
>>>>>>>>>>> 20.05.2013 19:32, Zdenek Styblik пишет:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, May 20, 2013 at 3:07 PM, Dmitry Bazhenov
>>>>>>>>>>>> <dim...@pigeonpoint.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Zdenek,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree with the first fragment changes (probably, it is worth
>>>>>>>>>>>>> making
>>>>>>>>>>>>> "rv"
>>>>>>>>>>>>> an unsigned long).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dmitry,
>>>>>>>>>>>>
>>>>>>>>>>>> it was just a quick modification to show what I meant.
>>>>>>>>>>>>
>>>>>>>>>>>>> As for the second fragment, I suggest we remove any check at
>>>>>>>>>>>>> all.
>>>>>>>>>>>>> The
>>>>>>>>>>>>> surrounding context ensures that the converted string is a
>>>>>>>>>>>>> 2-digit
>>>>>>>>>>>>> hexadecimal (see the isxdigit(ch) check upper to the fragment).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Uh. I'd be rather safe than sorry. My $0.02 USD.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Z.
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>
>>>>>>>>>>>>> 20.05.2013 18:50, Zdenek Styblik пишет:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, May 20, 2013 at 2:17 PM, Dmitry Bazhenov
>>>>>>>>>>>>>> <dim...@pigeonpoint.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello, Zdenek,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've addressed your comments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I see. Well, this sucks. Two solutions come to my mind. The
>>>>>>>>>>>>>>>> first is
>>>>>>>>>>>>>>>> to extend str2*() calls which, I admit, is going to be a bit
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>> The second is to check 'errno', endptr and '#include
>>>>>>>>>>>>>>>> <limits.h>'. In
>>>>>>>>>>>>>>>> other words, do what str2*() calls do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added checks of endptr and errno after the strtol() calls.
>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>> of these two calls these checks look sufficient to me. Please,
>>>>>>>>>>>>>>> review.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dmitry,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> please, see changes I've made/I propose. Lines which don't
>>>>>>>>>>>>>> being/aren't prefixed with '+' got either changed or added.
>>>>>>>>>>>>>> Also, some
>>>>>>>>>>>>>> parts of the code are missing, but since you have written it,
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> shouldn't be a problem.
>>>>>>>>>>>>>> If you have any questions regarding changes I've made, please,
>>>>>>>>>>>>>> ask.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +static int
>>>>>>>>>>>>>> +recv_response(struct ipmi_intf * intf, unsigned char *data,
>>>>>>>>>>>>>> int
>>>>>>>>>>>>>> len)
>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>> + char hex_rs[IPMI_SERIAL_MAX_RESPONSE * 3];
>>>>>>>>>>>>>> int i, j, resp_len = 0;
>>>>>>>>>>>>>> /* This shouldn't matter since rv isn't used
>>>>>>>>>>>>>> further
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> code, is it? */
>>>>>>>>>>>>>> long int rv = 0;
>>>>>>>>>>>>>> unsigned long int hex_tmp = 0;
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>> + if (strncmp(p, "ERR ", 4) == 0) {
>>>>>>>>>>>>>> + serial_write_line(intf, "\r\r\r\r");
>>>>>>>>>>>>>> + sleep(1);
>>>>>>>>>>>>>> + serial_flush(intf);
>>>>>>>>>>>>>> errno = 0;
>>>>>>>>>>>>>> rv = strtol(p + 4, &p, 16);
>>>>>>>>>>>>>> + if ((rv && rv < 0x100 && *p == '\0')
>>>>>>>>>>>>>> + || (rv == 0 && !errno)) {
>>>>>>>>>>>>>> + /* The message didn't get it through. The upper
>>>>>>>>>>>>>> + level will have to re-send */
>>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>>> + } else {
>>>>>>>>>>>>>> + lprintf(LOG_ERR, "Serial response is invalid");
>>>>>>>>>>>>>> + return -1;
>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>> + /* parse the response */
>>>>>>>>>>>>>> + i = 0;
>>>>>>>>>>>>>> + j = 0;
>>>>>>>>>>>>>> + while (*p) {
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>> + if (j == 2) {
>>>>>>>>>>>>>> + /* parse the hex number */
>>>>>>>>>>>>>> + str_hex[j] = 0;
>>>>>>>>>>>>>> errno = 0;
>>>>>>>>>>>>>> hex_tmp = strtoul(str_hex, &pp, 16);
>>>>>>>>>>>>>> /* I'm not 100% sure about "|| *pp != '\0'
>>>>>>>>>>>>>> "
>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>> Please, test it! */
>>>>>>>>>>>>>> if (errno != 0 || hex_tmp > UCHAR_MAX ||
>>>>>>>>>>>>>> *pp
>>>>>>>>>>>>>> != '\0')
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> /* TODO - Handle this error */
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> data[i++] = hex_tmp;
>>>>>>>>>>>>>> + if (pp == str_hex || *pp != 0) {
>>>>>>>>>>>>>> + break;
>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>> + j = 0;
>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Z.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 20.05.2013 10:46, Zdenek Styblik пишет:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 20, 2013 at 6:31 AM, Dmitry Bazhenov
>>>>>>>>>>>>>>>> <dim...@pigeonpoint.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Great. However, please fix the following lines:
>>>>>>>>>>>>>>>>>> + rate = atol(p + 1);
>>>>>>>>>>>>>>>>>> + rate = atol(p + 1);
>>>>>>>>>>>>>>>>>> + rv = strtol(p + 4, &p, 16);
>>>>>>>>>>>>>>>>>> + data[i++] = (unsigned char)
>>>>>>>>>>>>>>>>>> strtol(str_hex,
>>>>>>>>>>>>>>>>>> &pp,
>>>>>>>>>>>>>>>>>> 16);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have changed atol() calls to str2uint().
>>>>>>>>>>>>>>>>> Unfortunately, ipmitool/helper.h does not provide
>>>>>>>>>>>>>>>>> appropriate
>>>>>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> replace
>>>>>>>>>>>>>>>>> strtol(). In the code strtol() is called with radix=16 that
>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> input
>>>>>>>>>>>>>>>>> is read in hexadecimal form only. I think it is best to
>>>>>>>>>>>>>>>>> leave
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> strtol()
>>>>>>>>>>>>>>>>> calls there as they are.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I see. Well, this sucks. Two solutions come to my mind. The
>>>>>>>>>>>>>>>> first is
>>>>>>>>>>>>>>>> to extend str2*() calls which, I admit, is going to be a bit
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>> The second is to check 'errno', endptr and '#include
>>>>>>>>>>>>>>>> <limits.h>'. In
>>>>>>>>>>>>>>>> other words, do what str2*() calls do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm also wondering whether /dev/tty or /dev/ttyS couldn't
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> implied
>>>>>>>>>>>>>>>>>> and whether extending 'struct ipmi_intf' is really
>>>>>>>>>>>>>>>>>> necessary. But
>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>> just a silly question, I guess.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I couldn't find a better solution to provide a device string
>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>> drivers.
>>>>>>>>>>>>>>>>> The implying /dev/tty(s, USB) strings in the command-line is
>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>> think through how to make it without affecting those users
>>>>>>>>>>>>>>>>> who get
>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> specify the full device names.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, you're right. Serial dev can have <whatever> name. I
>>>>>>>>>>>>>>>> guess
>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>> fine as it's.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> These two functions both return a pointer to the static
>>>>>>>>>>>>>>>>> data.
>>>>>>>>>>>>>>>>> Hence,
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> #ifdef guard is unnecessary.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hmm :-S Ok. To be honest, I'm disappointed, because this
>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>> possible memory leak which "can't" be fixed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Z.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll provide the updated patch for serial drivers and
>>>>>>>>>>>>>>>>> separate
>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> bug soon.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No more comments below.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Z.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please, review.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 26.04.2013 16:08, Dmitry Bazhenov пишет:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hello, all,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I would like to submit a patch which adds Serial Basic
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> Terminal
>>>>>>>>>>>>>>>>>>>> mode
>>>>>>>>>>>>>>>>>>>> interface drivers which utilize a direct serial
>>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> interact with IPMC.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Both the patches implement single and double bridging.
>>>>>>>>>>>>>>>>>>>> However,
>>>>>>>>>>>>>>>>>>>> bridging
>>>>>>>>>>>>>>>>>>>> is temporarily broken for PICMG systems due to the known
>>>>>>>>>>>>>>>>>>>> bridging
>>>>>>>>>>>>>>>>>>>> issues. I'm going to update the patch as soon as these
>>>>>>>>>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> resolved.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AlienVault Unified Security Management (USM) platform
>>>>>>>>>>>>>>>>>>> delivers
>>>>>>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>>>>>> security visibility with the essential security
>>>>>>>>>>>>>>>>>>> capabilities.
>>>>>>>>>>>>>>>>>>> Easily
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> efficiently configure, manage, and operate all of your
>>>>>>>>>>>>>>>>>>> security
>>>>>>>>>>>>>>>>>>> controls
>>>>>>>>>>>>>>>>>>> from a single console and one unified framework. Download
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> free
>>>>>>>>>>>>>>>>>>> trial.
>>>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/alienvault_d2d
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Ipmitool-devel mailing list
>>>>>>>>>>>>>>>>>>> Ipmitool-devel@lists.sourceforge.net
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
