Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register

[Anand Babu Periasamy]

Matt Jerdonek wrote:
> Al & Anand,
>
> Thanks for the quick response.  I'm planning on using libfreeipmi to 
> create a custom application that, among other things, will have to read 
> event flags from the local event log and query sensors on local and 
> remote BMCs.
>
> I looked at the spec, and I think I have a slightly different 
> understanding (I'm not saying I'm right -- I may be misunderstanding the 
> spec).  I don't think SMS_ATN and OBF can be used interchangeably.  
> Here's my understanding:
> 1) If the SMS_ATN bit is set the local BMC requires some attention.
> 2) A GET MESSAGE FLAGS command should be sent to query the BMC.
> 3) If bit 0 is set in the response, that indicates a receive message is 
> available.  From looking at the ipmi_kcs_cmd_api_ipmb code, it appears 
> as if that code polls the local BMC with GET MESSAGE cmds instead of 
> using this bit to indicate when the response from the remote BMC is 
> ready.  While polling may not be ideal, it's certainly ok for my 
> application.
> 4) If bit 1 is set in the response, that indicates an event is available.
> 5) I'll ignore the pre-watchdog timeout and OEM bits for now ...
>
> I don't understand how libfreeipmi notifies the application that an 
> event is available without monitoring the SMS_ATN bit.  I think I want 
> to create a patch that does the following:
> 1) Creates a callback from libfreeapi to the application when an event 
> occurs.
> 2) Monitors the SMS_ATN bit.
> 3) If set, invokes the callback.
>
> The application would be responsible for issuing the GET MESSAGE FLAGS 
> command and handling the response.  One downside of this approach is 
> that it prevents you from ever making ipmi_kcs_cmd_api_ipmb 
> event-driven.  What do you two think?
>
> Thanks,
> -Matt
> ------------------------------------------------------------------------
> *From:* Al Chu <address@hidden>
> *To:* Matt Jerdonek <address@hidden>
> *Cc:* address@hidden
> *Sent:* Thu, February 18, 2010 10:58:06 AM
> *Subject:* Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
>
> Hi Matt,
>
> Definitely open to patches.  Looking over the IPMI spec, I agree w/
> A.B., it seems to be more useful for a higher level monitoring, w/ the
> Get Message Flags and similar commands.  I can think of several patch
> ideas:
>
> 1) add a KCS driver flag for checking for SMS_ATN in addition to OBF (or
> instead of??).  Flags may be propogated up into higher level APIs too.
>
> 2) an additional function that checks for SMS_ATN in addition/or instead
> of OBF that users can call instead.
>
> It would be useful to understand your use case too.  Are you using the
> KCS driver and IPMI bridging commands to bridge from one BMC to another
> BMC?
>
> Thanks,
>
> Al
>
> On Wed, 2010-02-17 at 18:51 -0800, Matt Jerdonek wrote:
>  > Hello,
>  >
>  > The KCS driver appears to not use the SMS_ATN register.  This register
>  > is useful for BMC-to-BMC communication to know when the remote BMC has
>  > responded.  Are there any plans to monitor this register in future
>  > releases?  If not, are the maintainers open to including a patch?
>  >
>  > Thanks,
>  > -Matt

I have attached a patch to give you an idea. I did not even compile it yet.
If ipmi_kcs_read_sms_atn() returns 1, then you should call ipmi_cmd_get_message_flags() 
function and check what type of event occurred.

nt ipmi_kcs_read_sms_atn (ipmi_kcs_ctx_t ctx);
int ipmi_cmd_get_message_flags (ipmi_ctx_t ctx, fiid_obj_t obj_cmd_rs);
Use this "tmpl_cmd_get_message_flags_rs" to parse the message contents.

All IPMI commands have request (write) and response (read) transaction model. So FreeIPMI 
drivers doesn't have to  wait for interrupts. All responses are triggered by its own 
requests. Driver internally uses OBF to poll for response immediately after request 
command. Polling is very short lived.

OBF is appropriate only when you send a command request. For general polling of hardware 
triggered events, one should use SMS_ATN register. Instead of creating a callback model, 
it is better to expose ipmi_kcs_read_sms_atn () function directly. It works like an 
asynchronous function. Let the application retain the control and decide how to thread or 
poll using this function.

Al, Unfortunately SMS_ATN is KCS specific. So we can't create an abstracted API.

--
Anand Babu Periasamy
Blog [http://www.unlocksmith.org]
Twitter [http://twitter.com/unlocksmith]
Gluster Storage Platform [http://www.gluster.org]
GNU/Linux Operating System [http://www.gnu.org]

Index: libfreeipmi/include/freeipmi/driver/ipmi-kcs-driver.h
===================================================================
RCS file: 
/sources/freeipmi/freeipmi/libfreeipmi/include/freeipmi/driver/ipmi-kcs-driver.h,v
retrieving revision 1.18
diff -r1.18 ipmi-kcs-driver.h
66a67
> int ipmi_kcs_read_sms_atn (ipmi_kcs_ctx_t ctx);
Index: libfreeipmi/src/driver/ipmi-kcs-driver.c
===================================================================
RCS file: /sources/freeipmi/freeipmi/libfreeipmi/src/driver/ipmi-kcs-driver.c,v
retrieving revision 1.40
diff -r1.40 ipmi-kcs-driver.c
578a579,596
>  * The SMS_ATN flag is used to indicate that the BMC requires attention from 
> system software. 
>  * This could either be because a message was received into the Receive 
> Message Queue and ready
>  * for delivery to system software, the Event Message Buffer is full (if the 
> Event Message Buffer
>  * is configured to generate an interrupt to system management software), a 
> watchdog pre-timeout
>  * occurred, or because of an OEM event. You should always call "Get Message 
> Flags" command whenever
>  * SMS_ATN remains set after normal processing and check the type of pending 
> message.
>  */
> 
> int
> ipmi_kcs_read_sms_atn (ipmi_kcs_ctx_t ctx)
> {
>   assert (ctx);
>   assert (ctx->magic == IPMI_KCS_CTX_MAGIC);
> 
>   return (_ipmi_kcs_get_status (ctx) & IPMI_KCS_STATUS_REG_SMS_ATN);
> }
> 
> /*