[Top][All Lists]
[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