freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] FreeIPMI 0.7.4 Released


From: Al Chu
Subject: Re: [Freeipmi-devel] FreeIPMI 0.7.4 Released
Date: Mon, 05 Jan 2009 11:22:15 -0800

Hey David,

On Mon, 2009-01-05 at 19:56 +0100, david maxera - Sun Microsystems -
Prague Czech Republic wrote:
> Hi Al,
> 
> 
>  > Usually it should be obvious.  For example, running ipmi-sensors should
>  > get you sensor readings and such.  Looking at the freeipmi(7) manpage,
>  > it might be worthwhile to put a short section on "what is IPMI" and some
>  > sanity check introduction in there.  I'll put that on my TODO.
> 
> # ipmi-sensors --debug
> getpwuid_r: Error 0
> 
> 
> It looks like HAVE_FUNC_GETPWUID_R_5 is not defined, apparently 
> getpwuid_r() has only 4 parameters at Solaris. And 
> _get_home_directory(...) in tool-sdr-cache-common.c requires it. Ok, the 
> problem is clear here, I'll figure something.

Hmmm.  I already handled this for compiling on normal solaris.

#if defined(HAVE_FUNC_GETPWUID_R_5)
  if (getpwuid_r (user_id,
                  &pwd,
                  tbuf,
                  tbuf_len,
                  &(pwdptr)) != 0)
    {
      PSTDOUT_PERROR(pstate, "getpwuid_r");
      return -1;
    }

  if (!pwdptr)
    {
      /* User not found - can't figure out cache directory */
      PSTDOUT_PERROR(pstate, "getpwuid_r");
      return -1;
    }
#elif defined(HAVE_FUNC_GETPWUID_R_4)
  if (getpwuid_r (user_id,
                  &pwd,
                  tbuf,
                  tbuf_len) != 0)
    {
      PSTDOUT_PERROR(pstate, "getpwuid_r");
      return -1;
    }
#endif /* !defined(HAVE_FUNC_GETPWUID_R_4) */

I suppose it's possible the autoconf isn't detecting things properly for
opensolaris?  Are the right macros being defined/not-defined in
config/config.h??

> >> Nothing else seems to be working, or at least I haven't guessed the 
> >> correct combination of parameters. Say,
> >>  >  ipmipower -h latte2-sp -u <my_sp_user> -p <my_sp_password> --debug -s
> >> latte2-sp: =====================================================
> >> latte2-sp: IPMI 1.5 Get Channel Authentication Capabilities Request
> >> latte2-sp: =====================================================
> >> latte2-sp: RMCP Header:
> >> latte2-sp: ------------
> >> latte2-sp: [               6h] = version[ 8b]
> >> latte2-sp: [               0h] = reserved[ 8b]
> >> latte2-sp: [              FFh] = sequence_number[ 8b]
> >> latte2-sp: [               7h] = message_class.class[ 5b]
> >> latte2-sp: [               0h] = message_class.reserved[ 2b]
> >> latte2-sp: [               0h] = message_class.ack[ 1b]
> >> latte2-sp: IPMI Session Header:
> >> latte2-sp: --------------------
> >> latte2-sp: [               0h] = authentication_type[ 8b]
> >> latte2-sp: [               0h] = session_sequence_number[32b]
> >> latte2-sp: [               0h] = session_id[32b]
> >> latte2-sp: [               9h] = ipmi_msg_len[ 8b]
> >> latte2-sp: IPMI Message Header:
> >> latte2-sp: --------------------
> >> latte2-sp: [              20h] = rs_addr[ 8b]
> >> latte2-sp: [               0h] = rs_lun[ 2b]
> >> latte2-sp: [               6h] = net_fn[ 6b]
> >> latte2-sp: [              C8h] = checksum1[ 8b]
> >> latte2-sp: [              81h] = rq_addr[ 8b]
> >> latte2-sp: [               0h] = rq_lun[ 2b]
> >> latte2-sp: [              12h] = rq_seq[ 6b]
> >> latte2-sp: IPMI Command Data:
> >> latte2-sp: ------------------
> >> latte2-sp: [              38h] = cmd[ 8b]
> >> latte2-sp: [               Eh] = channel_number[ 4b]
> >> latte2-sp: [               0h] = reserved1[ 4b]
> >> latte2-sp: [               3h] = maximum_privilege_level[ 4b]
> >> latte2-sp: [               0h] = reserved2[ 4b]
> >> latte2-sp: IPMI Trailer:
> >> latte2-sp: --------------
> >> latte2-sp: [              EEh] = checksum2[ 8b]
> >>
> >>
> >> Truss reveals that sendto(...) syscall fails with Err#124 EAFNOSUPPORT - 
> >> as if some network protocol wasn't supported or what. But in ipmiping, 
> >> sendto() passes OK. What could it be?
> > 
> > This on the other hand is unexpected.  I'm not really sure why you would
> > get a EAFNOSUPPORT error.  I suppose its possible there's some subtlety
> > with opensolaris in the code that I'm not handling properly?  If you
> > could send me the --debug output and the truss output that'd be great.
> > Could you also try other tools (bmc-info, ipmi-sensors) out of band and
> > let me know if the results are the same?  
> 
> Out of band bmc-info returns  "bmc-info: invalid hostname".
> 
> Well, I now see that the problem isn't in my wrong understanding of 
> FreeIPMI, but rather in the Solaris naming functions. This is basically 
> the information I needed ;-)

If you feel you got a handle on it now, great :-)  I'd love to get
things working on opensolaris.  I'll be glad to add any patches you have
into the mainline tree.

Al

> Thanks.
> 
> David
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory





reply via email to

[Prev in Thread] Current Thread [Next in Thread]