[Top][All Lists]

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

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

From: Al Chu
Subject: Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
Date: Thu, 18 Feb 2010 14:58:53 -0800

Hi Matt,

Anand wrote the KCS driver, so he'll respond too.

Re-reading the spec again and reading your comments, I think I
understand your situation.  You're looking to read the SMS_ATN register
so that you'll know whether a receive queue, event buffer, or whatever
other thing has occurred, then you'll do something appropriate given the
situation.  This is in contrast to the relative request-reply model of
the current driver. e.g. for IPMB, I poll the recieve queue. Correct?

Based on what you said below, here's my idea of how to implement what
you're thinking.

We'll add a function like ipmi_kcs_sms_atn_callback_register(), where
you register a function that will be called if SMS_ATN is set to 1.

Add another function, something like ipmi_kcs_sms_atn_spin(), that just
spins and checks SMS_ATN once in awhile.  It'll call the callback
whenever appropriate.  This is going to be like our "sleep" or "wait"
equivalent when your app is waiting to do something.  

Within the KCS driver, check the SMS_ATN bit before any KCS read or
write operation done within the KCS driver.  If the SMS_ATN bit is 1,
call the callback.

So the net affect is an event can be generated whenever you are doing
KCS or you "sleep" w/ the spin function.  You're right, that the
downside is is that the user shouldn't use ipmi_kcs_cmd_api_ipmb() in
this situation (worst that happens is you get timeouts if you take a
message off the receive queue instead of libfreeipmi).  But I figure
this is a bit of advanced use, so they'll have to know that you
shouldn't use ipmi_kcs_cmd_api_ipmb().

Is this what you're looking for??


On Thu, 2010-02-18 at 13:24 -0800, 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
> > 
> > 
> > _______________________________________________
> > Freeipmi-devel mailing list
> > address@hidden
> > http://**
> -- 
> Albert Chu
> address@hidden
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
Albert Chu
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

reply via email to

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