freeipmi-devel
[Top][All Lists]
Advanced

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

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


From: Matt Jerdonek
Subject: Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
Date: Sun, 21 Feb 2010 10:51:30 -0800 (PST)

Before I started looking at the KCS interface, the same customer had me start writing a serial interface for FreeIPMI for some different hardware.  That project has been abandoned; however, I wanted to point out that the serial interface sent an attention character that had the same functionality as the SMS_ATN.  So, I think it's in the best interest to create an abstract API.

Since you two appear open to this, please give me a few days to talk to my co-workers and develop a patch for this.  You two can then review it and tell me if you think I'm in the right direction.

Thanks again for all your comments,
-Matt


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@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



reply via email to

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