Re: [Freeipmi-devel] sun20 workaround doesn't
"Johnson, Bill" writes: > I would be interested in any thoughts or comments back. Like you're rudely abusing a GNU mailing list by advertising proprietary software? I have conman (and others). ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, Great, I'll add that into the docs. Al On Fri, 2009-06-12 at 10:32 +0100, Dave Love wrote: > Al Chu writes: > > > Hey Dave, > > > >> Ah. solpayloadsize,sun20 did establish a connexion, but I think the > >> speed may be wrong as it appears dead once connected. On the other > >> hand, after disconnecting, that seems to have taken the ILOM off the > >> air... That is with the earliest ILOM, anyway, though it's annoying it > >> looks more broken in the latest. > > > > Well, glad it got further. What motherboard is this? I can add it to > > the list of workarounds. > > solpayloadsize,sun20 got a connexion on x4100 with ILOM 1.0. I can't > see a way to make ILOM 2.0.2.5 on x4100 work. > > I think it's only the ILOM version which is relevant, though. ILOM > 2.0. behaves essentially the same on the x4200, x4200m2, and > x4500 systems I have; the MBs are certainly different physically, > between them, but I don't know what differences might be relevant. [You > can poke about on it under busybox, but I've never tried to check > exactly what's there on the different installations.] -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > Hey Dave, > >> Ah. solpayloadsize,sun20 did establish a connexion, but I think the >> speed may be wrong as it appears dead once connected. On the other >> hand, after disconnecting, that seems to have taken the ILOM off the >> air... That is with the earliest ILOM, anyway, though it's annoying it >> looks more broken in the latest. > > Well, glad it got further. What motherboard is this? I can add it to > the list of workarounds. solpayloadsize,sun20 got a connexion on x4100 with ILOM 1.0. I can't see a way to make ILOM 2.0.2.5 on x4100 work. I think it's only the ILOM version which is relevant, though. ILOM 2.0. behaves essentially the same on the x4200, x4200m2, and x4500 systems I have; the MBs are certainly different physically, between them, but I don't know what differences might be relevant. [You can poke about on it under busybox, but I've never tried to check exactly what's there on the different installations.] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, > Ah. solpayloadsize,sun20 did establish a connexion, but I think the > speed may be wrong as it appears dead once connected. On the other > hand, after disconnecting, that seems to have taken the ILOM off the > air... That is with the earliest ILOM, anyway, though it's annoying it > looks more broken in the latest. Well, glad it got further. What motherboard is this? I can add it to the list of workarounds. Al On Thu, 2009-06-11 at 17:38 +0100, Dave Love wrote: > Al Chu writes: > > > Actually, it seems the sun20 workarounds are working correctly. You are > > able to authenticate. The problem is ... > > Yes. I was only meaning to say that the SOL seems to be broken. > > >> # ipmiconsole -h ipmi101 -Wsun20 > >> [error received]: SOL unavailable > > > > This typically means the config of the remote server is invalid. We've > > authenticated all the way through but SOL isn't turned on, so we exit > > out. I will admit, I have never gotten SOL to work on my motherboard > > (w/ ipmitool either). > > Likewise. > > > The ability to configure the SOL_Conf section via > > bmc-config is broken (atleast in my firmware version). Perhaps it has > > to be configured via other Sun software or via the ILOM interface > > itself? > > I couldn't find any info. I suppose I could raise a service call, but > I don't know if that's likely to get me anywhere. The console does work > via the ssh CLI, anyhow. > > >> and for 1.0: > >> > >> # ipmiconsole -h ipmi060 -Wsun20 > >> ipmiconsole_submit_block: BMC Implementation > >> > >> and the ILOM doc seems to ignore the topic. > > > > This typically means there is an IPMI implementation issue. Have you > > tried the "solport" or the "solpayloadsize" workarounds? If either > > one/both work, we'll just have to add Sun motherboards to the > > workarounds list. > > Ah. solpayloadsize,sun20 did establish a connexion, but I think the > speed may be wrong as it appears dead once connected. On the other > hand, after disconnecting, that seems to have taken the ILOM off the > air... That is with the earliest ILOM, anyway, though it's annoying it > looks more broken in the latest. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > A. I take it you are using the hostrange feature as a "go get data > faster" mechanism. I suppose I was thinking more about the > buffer/consolidate options (-B, -C). Using them against a heterogenous > environment didn't make too much sense to me. Right. I have a script with a fragment # x2200s. Default is -W authcap. /usr/sbin/ipmi-sensors -E -h 'ipmi0[00-59]' --always-prefix -g temperature --sdr-cache-recreate -Q # x4100s /usr/sbin/ipmi-sensors -E -h 'ipmi[060-103]' --always-prefix -g temperature -W endianseq --sdr-cache-recreate -Q piped into a loop which mangles it for gmetric, though there it's not much of a problem to split the ranges, obviously. > ohhh, you mean like: > > Section nodes[0-11] > workarounds sun20 > End > Section nodes[0-12] > workarounds intel20 > End I meant more like the Windows (sorry!) .ini system, which does get used elsewhere, i.e. [section1] ... [section2] ... but I don't know that there's any particular advantage to it. ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > Actually, it seems the sun20 workarounds are working correctly. You are > able to authenticate. The problem is ... Yes. I was only meaning to say that the SOL seems to be broken. >> # ipmiconsole -h ipmi101 -Wsun20 >> [error received]: SOL unavailable > > This typically means the config of the remote server is invalid. We've > authenticated all the way through but SOL isn't turned on, so we exit > out. I will admit, I have never gotten SOL to work on my motherboard > (w/ ipmitool either). Likewise. > The ability to configure the SOL_Conf section via > bmc-config is broken (atleast in my firmware version). Perhaps it has > to be configured via other Sun software or via the ILOM interface > itself? I couldn't find any info. I suppose I could raise a service call, but I don't know if that's likely to get me anywhere. The console does work via the ssh CLI, anyhow. >> and for 1.0: >> >> # ipmiconsole -h ipmi060 -Wsun20 >> ipmiconsole_submit_block: BMC Implementation >> >> and the ILOM doc seems to ignore the topic. > > This typically means there is an IPMI implementation issue. Have you > tried the "solport" or the "solpayloadsize" workarounds? If either > one/both work, we'll just have to add Sun motherboards to the > workarounds list. Ah. solpayloadsize,sun20 did establish a connexion, but I think the speed may be wrong as it appears dead once connected. On the other hand, after disconnecting, that seems to have taken the ILOM off the air... That is with the earliest ILOM, anyway, though it's annoying it looks more broken in the latest. ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, On Wed, 2009-06-10 at 15:31 +0100, Dave Love wrote: > Al Chu writes: > > > Hehe. It's funny you mention this. I had a request/comment on this > > topic just last week. First, please take a look at my original post on > > this for what I was thinking of supporting: > > > > http://www.mail-archive.com/freeipmi-devel@gnu.org/msg00710.html > > For what it's worth, although that suggests you don't want sensor data > from heterogeneous hosts, but that's one of my application. > Specifically for out-of-band temperature data fed to ganglia, the ELOM, > ILOM, and Supermicro values can be translated to consistent names, > though I'm not currently doing that. A. I take it you are using the hostrange feature as a "go get data faster" mechanism. I suppose I was thinking more about the buffer/consolidate options (-B, -C). Using them against a heterogenous environment didn't make too much sense to me. > > The work involved is somewhat deep > > Just as well I asked, then, before trying to dive in! I could probably > help out, given instructions for part of the job, if it will partition. Thanks for the offer, but I think this is something I'll have to suffer, b/c it will take a fair amount of re-architecture, which I admit I still don't know how I'm going to do :-) > > (that I've naturally been putting > > off, but it is now higher priority b/c it came as a request from someone > > internal to my organization). As far as I can tell, it would take: > > > > A) re-work a lot of the config file parsing code to be able to take an > > additional argument. Based on other people's requests, this would be > > for all the config file options. It could be made easier if instead of > > modifying all config file options to take the additional argument, we > > made new config file options, like: > > I'd initially have thought of trying to have host-specific sections in > the file, e.g. with the common `[]' style, but I doubt it > matters from a user point of view, so it would be a question of what's > easiest to program. ohhh, you mean like: Section nodes[0-11] workarounds sun20 End Section nodes[0-12] workarounds intel20 End That's an idea too. The config-file parsing lib I have doesn't support that (yet), which is why I didn't really consider it. H. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, On Wed, 2009-06-10 at 15:19 +0100, Dave Love wrote: > Al Chu writes: > > > Hey Dave, > > > > Whew, I'm glad I have a relatively new sun board, this would have been > > tough to figure out :-) > > Good. I could have offered to let you on here. > > > Effectively, the "opensesspriv" workaround is also needed for the Sun > > boards. I've wrapped that workaround in as an automatic one for the Sun > > workaround, so it should work now. Test tar.gz is here: > > > > http:// > > ftp.zresearch.com/pub/freeipmi/qa-release/freeipmi-0.7.10.beta2.tar.gz > > > > It ends up I didn't see it before b/c the problem doesn't exist if you > > default to the "admin" privilege level. Some tools (such as bmc-info) > > don't default to that. > > > > Could you let me know if it works? Thanks. > > It seems to, though I still can't get ipmiconsole to function, which was > the original issue. It looks as if it just doesn't work with ILOM. > > In case it's useful to record the fact, for ILOM 2.0 I get: Actually, it seems the sun20 workarounds are working correctly. You are able to authenticate. The problem is ... > # ipmiconsole -h ipmi101 -Wsun20 > [error received]: SOL unavailable This typically means the config of the remote server is invalid. We've authenticated all the way through but SOL isn't turned on, so we exit out. I will admit, I have never gotten SOL to work on my motherboard (w/ ipmitool either). The ability to configure the SOL_Conf section via bmc-config is broken (atleast in my firmware version). Perhaps it has to be configured via other Sun software or via the ILOM interface itself? > and for 1.0: > > # ipmiconsole -h ipmi060 -Wsun20 > ipmiconsole_submit_block: BMC Implementation > > and the ILOM doc seems to ignore the topic. This typically means there is an IPMI implementation issue. Have you tried the "solport" or the "solpayloadsize" workarounds? If either one/both work, we'll just have to add Sun motherboards to the workarounds list. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > Hehe. It's funny you mention this. I had a request/comment on this > topic just last week. First, please take a look at my original post on > this for what I was thinking of supporting: > > http://www.mail-archive.com/freeipmi-devel@gnu.org/msg00710.html For what it's worth, although that suggests you don't want sensor data from heterogeneous hosts, but that's one of my application. Specifically for out-of-band temperature data fed to ganglia, the ELOM, ILOM, and Supermicro values can be translated to consistent names, though I'm not currently doing that. > The work involved is somewhat deep Just as well I asked, then, before trying to dive in! I could probably help out, given instructions for part of the job, if it will partition. > (that I've naturally been putting > off, but it is now higher priority b/c it came as a request from someone > internal to my organization). As far as I can tell, it would take: > > A) re-work a lot of the config file parsing code to be able to take an > additional argument. Based on other people's requests, this would be > for all the config file options. It could be made easier if instead of > modifying all config file options to take the additional argument, we > made new config file options, like: I'd initially have thought of trying to have host-specific sections in the file, e.g. with the common `[]' style, but I doubt it matters from a user point of view, so it would be a question of what's easiest to program. ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > Hey Dave, > > Whew, I'm glad I have a relatively new sun board, this would have been > tough to figure out :-) Good. I could have offered to let you on here. > Effectively, the "opensesspriv" workaround is also needed for the Sun > boards. I've wrapped that workaround in as an automatic one for the Sun > workaround, so it should work now. Test tar.gz is here: > > http://ftp.zresearch.com/pub/freeipmi/qa-release/freeipmi-0.7.10.beta2.tar.gz > > It ends up I didn't see it before b/c the problem doesn't exist if you > default to the "admin" privilege level. Some tools (such as bmc-info) > don't default to that. > > Could you let me know if it works? Thanks. It seems to, though I still can't get ipmiconsole to function, which was the original issue. It looks as if it just doesn't work with ILOM. In case it's useful to record the fact, for ILOM 2.0 I get: # ipmiconsole -h ipmi101 -Wsun20 [error received]: SOL unavailable and for 1.0: # ipmiconsole -h ipmi060 -Wsun20 ipmiconsole_submit_block: BMC Implementation and the ILOM doc seems to ignore the topic. ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, Whew, I'm glad I have a relatively new sun board, this would have been tough to figure out :-) Effectively, the "opensesspriv" workaround is also needed for the Sun boards. I've wrapped that workaround in as an automatic one for the Sun workaround, so it should work now. Test tar.gz is here: http://ftp.zresearch.com/pub/freeipmi/qa-release/freeipmi-0.7.10.beta2.tar.gz It ends up I didn't see it before b/c the problem doesn't exist if you default to the "admin" privilege level. Some tools (such as bmc-info) don't default to that. Could you let me know if it works? Thanks. Al On Tue, 2009-06-09 at 10:31 -0700, Al Chu wrote: > Hey Dave, > > > OK, appended. > > Hmmm. It seems the workaround just isn't working. It's possible I have > introduced a bug into the workaround. Let me see if I can figure it > out. > > > I didn't mean to be critical, of course. However, I find it's a real > > practical problem with our heterogeneous HPC systems, and I guess I'm > > not alone. I notice there's a TODO item addressing workarounds per > > host. Is it clear what's involved if I give it a go? > > Hehe. It's funny you mention this. I had a request/comment on this > topic just last week. First, please take a look at my original post on > this for what I was thinking of supporting: > > http:// www. mail-archive.com/freeipmi-devel@gnu.org/msg00710.html > > The work involved is somewhat deep (that I've naturally been putting > off, but it is now higher priority b/c it came as a request from someone > internal to my organization). As far as I can tell, it would take: > > A) re-work a lot of the config file parsing code to be able to take an > additional argument. Based on other people's requests, this would be > for all the config file options. It could be made easier if instead of > modifying all config file options to take the additional argument, we > made new config file options, like: > > # default for all systems > workaround intel20 > # default for some spsecific systems > workaround-hosts node[0-11] sun20 > > I haven't decided which I will do at this moment. > > B) modifying the tools to override it's defaults + the config file > defaults w/ the host specific defaults. This will require a fair amount > of re-architecture b/c host-specific defaults need to be stored/passed > around/parsed "deeper" into the hostrange code. > > Al > > On Tue, 2009-06-09 at 10:43 +0100, Dave Love wrote: > > Al Chu writes: > > > > > Hey Dave, > > > > > > It's entirely possible there is another issue for your systems I never > > > encountered before or a bug in the workaround code. If you could send > > > the --debug output, that'd be great. > > > > OK, appended. > > > > > Ipmitool also elects to "hide" > > > workarounds in its tools more often, instead of making the user put them > > > on the command line. Pros and cons of both approaches, I don't think > > > either of us is right or wrong. > > > > I didn't mean to be critical, of course. However, I find it's a real > > practical problem with our heterogeneous HPC systems, and I guess I'm > > not alone. I notice there's a TODO item addressing workarounds per > > host. Is it clear what's involved if I give it a go? > > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, > OK, appended. Hmmm. It seems the workaround just isn't working. It's possible I have introduced a bug into the workaround. Let me see if I can figure it out. > I didn't mean to be critical, of course. However, I find it's a real > practical problem with our heterogeneous HPC systems, and I guess I'm > not alone. I notice there's a TODO item addressing workarounds per > host. Is it clear what's involved if I give it a go? Hehe. It's funny you mention this. I had a request/comment on this topic just last week. First, please take a look at my original post on this for what I was thinking of supporting: http://www.mail-archive.com/freeipmi-devel@gnu.org/msg00710.html The work involved is somewhat deep (that I've naturally been putting off, but it is now higher priority b/c it came as a request from someone internal to my organization). As far as I can tell, it would take: A) re-work a lot of the config file parsing code to be able to take an additional argument. Based on other people's requests, this would be for all the config file options. It could be made easier if instead of modifying all config file options to take the additional argument, we made new config file options, like: # default for all systems workaround intel20 # default for some spsecific systems workaround-hosts node[0-11] sun20 I haven't decided which I will do at this moment. B) modifying the tools to override it's defaults + the config file defaults w/ the host specific defaults. This will require a fair amount of re-architecture b/c host-specific defaults need to be stored/passed around/parsed "deeper" into the hostrange code. Al On Tue, 2009-06-09 at 10:43 +0100, Dave Love wrote: > Al Chu writes: > > > Hey Dave, > > > > It's entirely possible there is another issue for your systems I never > > encountered before or a bug in the workaround code. If you could send > > the --debug output, that'd be great. > > OK, appended. > > > Ipmitool also elects to "hide" > > workarounds in its tools more often, instead of making the user put them > > on the command line. Pros and cons of both approaches, I don't think > > either of us is right or wrong. > > I didn't mean to be critical, of course. However, I find it's a real > practical problem with our heterogeneous HPC systems, and I guess I'm > not alone. I notice there's a TODO item addressing workarounds per > host. Is it clear what's involved if I give it a go? > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sun20 workaround doesn't
Al Chu writes: > Hey Dave, > > It's entirely possible there is another issue for your systems I never > encountered before or a bug in the workaround code. If you could send > the --debug output, that'd be great. OK, appended. > Ipmitool also elects to "hide" > workarounds in its tools more often, instead of making the user put them > on the command line. Pros and cons of both approaches, I don't think > either of us is right or wrong. I didn't mean to be critical, of course. However, I find it's a real practical problem with our heterogeneous HPC systems, and I guess I'm not alone. I notice there's a TODO item addressing workarounds per host. Is it clear what's involved if I give it a go? ipmi100: = ipmi100: IPMI 1.5 Get Channel Authentication Capabilities Request ipmi100: = ipmi100: RMCP Header: ipmi100: ipmi100: [ 6h] = version[ 8b] ipmi100: [ 0h] = reserved[ 8b] ipmi100: [ FFh] = sequence_number[ 8b] ipmi100: [ 7h] = message_class.class[ 5b] ipmi100: [ 0h] = message_class.reserved[ 2b] ipmi100: [ 0h] = message_class.ack[ 1b] ipmi100: IPMI Session Header: ipmi100: ipmi100: [ 0h] = authentication_type[ 8b] ipmi100: [ 0h] = session_sequence_number[32b] ipmi100: [ 0h] = session_id[32b] ipmi100: [ 9h] = ipmi_msg_len[ 8b] ipmi100: IPMI Message Header: ipmi100: ipmi100: [ 20h] = rs_addr[ 8b] ipmi100: [ 0h] = rs_lun[ 2b] ipmi100: [ 6h] = net_fn[ 6b] ipmi100: [ C8h] = checksum1[ 8b] ipmi100: [ 81h] = rq_addr[ 8b] ipmi100: [ 0h] = rq_lun[ 2b] ipmi100: [ 1Eh] = rq_seq[ 6b] ipmi100: IPMI Command Data: ipmi100: -- ipmi100: [ 38h] = cmd[ 8b] ipmi100: [ Eh] = channel_number[ 4b] ipmi100: [ 0h] = reserved1[ 3b] ipmi100: [ 1h] = get_ipmi_v2.0_extended_data[ 1b] ipmi100: [ 2h] = maximum_privilege_level[ 4b] ipmi100: [ 0h] = reserved2[ 4b] ipmi100: IPMI Trailer: ipmi100: -- ipmi100: [ 3Fh] = checksum2[ 8b] ipmi100: = ipmi100: IPMI 1.5 Get Channel Authentication Capabilities Response ipmi100: = ipmi100: RMCP Header: ipmi100: ipmi100: [ 6h] = version[ 8b] ipmi100: [ 0h] = reserved[ 8b] ipmi100: [ FFh] = sequence_number[ 8b] ipmi100: [ 7h] = message_class.class[ 5b] ipmi100: [ 0h] = message_class.reserved[ 2b] ipmi100: [ 0h] = message_class.ack[ 1b] ipmi100: IPMI Session Header: ipmi100: ipmi100: [ 0h] = authentication_type[ 8b] ipmi100: [ 0h] = session_sequence_number[32b] ipmi100: [ 0h] = session_id[32b] ipmi100: [ 10h] = ipmi_msg_len[ 8b] ipmi100: IPMI Message Header: ipmi100: ipmi100: [ 81h] = rq_addr[ 8b] ipmi100: [ 0h] = rq_lun[ 2b] ipmi100: [ 7h] = net_fn[ 6b] ipmi100: [ 63h] = checksum1[ 8b] ipmi100: [ 20h] = rs_addr[ 8b] ipmi100: [ 0h] = rs_lun[ 2b] ipmi100: [ 1Eh] = rq_seq[ 6b] ipmi100: IPMI Command Data: ipmi100: -- ipmi100: [ 38h] = cmd[ 8b] ipmi100: [ 0h] = comp_code[ 8b] ipmi100: [ 1h] = channel_number[ 8b] ipmi100: [ 0h] = authentication_type.none[ 1b] ipmi100: [ 1h] = authentication_type.md2[ 1b] ipmi100: [ 1h] = authentication_type.md5[ 1b] ipmi100: [ 0h] = authentication_type.reserved1[ 1b] ipmi100: [ 1h] = authentication_type.straight_password_key[ 1b] ipmi100: [ 0h] = authentication_type.oem_prop[ 1b] ipmi100: [ 0h] = authentication_type.reserved2[ 1b] ipmi100: [ 1h] = authentication_type.ipmi_v2.0_extended_capabilities_available[ 1b] ipmi100: [ 0h] = authentication_status.anonymous_login[ 1b] ipmi100: [ 0h] = authentication_status.null_username[ 1b] ipmi100: [ 1h] = authentication_status.non_null_username[ 1b] ipmi100: [ 0h] = authentication_status.user_level_authentication[ 1b] ipmi100: [ 0h] = authentication_status.per_message_authentication[ 1b] ipmi100: [ 0h] = authentication_status.k_g[ 1b] ipmi100: [ 0h] = authentication_status.reserved[ 2b] ipmi100: [ 1h] = channel_supports_ipmi_v1.5_connections[ 1b] ipmi100: [ 1h] = channel_supports_ipmi_v2.0_connections[ 1b] ipmi100: [ 0h] = reserved[ 6b]
Re: [Freeipmi-devel] sun20 workaround doesn't
Hey Dave, It's entirely possible there is another issue for your systems I never encountered before or a bug in the workaround code. If you could send the --debug output, that'd be great. As for your second question, there are a number of "checks" that I do more stringently than in ipmitool, leading to the need for workarounds in FreeIPMI than in ipmitool. Ipmitool also elects to "hide" workarounds in its tools more often, instead of making the user put them on the command line. Pros and cons of both approaches, I don't think either of us is right or wrong. Thanks, Al On Mon, 2009-06-08 at 17:43 +0100, Dave Love wrote: > I tried `bmc-info -D LAN_2_0 -W sun20' on x4100s with both ILOM 1.0 and > 2.0.2.5 (the latest as of a few months ago). It gives `password > invalid' in both cases. (With LAN, -W endianseq works with both the 1.0 > and 2.0 ILOMs, but it doesn't help with LAN_2_0.) > > Is --debug output the right thing to send? I could also send -v output > from ipmitool, which works. [Is it known how ipmitool gets away without > workarounds specified?] > > > ___ > Freeipmi-devel mailing list > Freeipmi-devel@gnu.org > http:// lists.gnu.org/mailman/listinfo/freeipmi-devel > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] sun20 workaround doesn't
I tried `bmc-info -D LAN_2_0 -W sun20' on x4100s with both ILOM 1.0 and 2.0.2.5 (the latest as of a few months ago). It gives `password invalid' in both cases. (With LAN, -W endianseq works with both the 1.0 and 2.0 ILOMs, but it doesn't help with LAN_2_0.) Is --debug output the right thing to send? I could also send -v output from ipmitool, which works. [Is it known how ipmitool gets away without workarounds specified?] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
