From: Al Chu <address@hidden>
To: Anand Babu Periasamy <address@hidden>
Cc: Matt Jerdonek <address@hidden>; address@hidden
Sent: Sun, February 21, 2010 9:38:27 AM
Subject: Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
Hey A.B,
> Al, Unfortunately SMS_ATN is KCS specific. So we can't create an
> abstracted API.
There's no reason other drivers won't have "interrupt callbacks" in the
future. We can abstract it by calling the API function something like
"interrupt_callback". The only driver supported with it would be KCS in
the beginning.
Al
On Sun, 2010-02-21 at 04:29 -0800, Anand Babu Periasamy wrote:
> 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.
>
--
Albert Chu
address@hiddenComputer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory