Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-03-01 Thread Matt Jerdonek 

Al,

Thanks for the clarification.  I see your point and I updated the patch to 
address it.  As with the previous patch, this compiles, but I didn't run it on 
hardware yet because my customer has not yet sent me the KCS hardware.

Thanks again,
-Matt


--- On Thu, 2/25/10, Al Chu ch...@llnl.gov wrote:

From: Al Chu ch...@llnl.gov
Subject: Re: [Freeipmi-devel] KCS Driver  SMS_ATN Register
To: Matt Jerdonek maj1...@yahoo.com
Cc: Anand Babu Periasamy a...@gnu.org.in, freeipmi-devel@gnu.org
Date: Thursday, February 25, 2010, 10:33 AM

Hi Matt,

I don't see it that way.  I could see someone programming a single
thread and only wanting to poll the SMS_ATN bit, and process events as
they occur.  Not doing any other KCS. e.g.

main()
{
   setup_kcs();

   while (1) {
      kcs_wait_for_sms()
      get_message_flags()
      process_event()
   }
}

Maybe I didn't describe it well.  The concern I have with your patch (if
I'm reading it correctly, correct me if I'm wrong) is that the only time
the SMS ATN bit is checked is in _ipmi_kcs_get_status().
_ipmi_kcs_get_status() will only be called through other KCS functions
like ipmi_kcs_read() and ipmi_kcs_write().

So in order for the SMS ATN bit to be checked, ipmi_kcs_read() and
ipmi_kcs_write() have to be called, either by your application or other
IPMI going on in the system, otherwise the SMS_ATN bit will never be
checked.  Correct?  Under your patch, in the above code snippet,
kcs_wait_for_sms() will never return, b/c no other KCS calls are going
on (unless they are other KCS IPMI going on in the system elsewhere). 

Perhaps within your patch, you assumed other IPMI going on in other
parts of the system?

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory




  

ipmi_kcs_sms_atn.patch
Description: Binary data
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-03-01 Thread Al Chu 
Hey Matt,

Looks pretty good.  A few comments:

+int
+ipmi_kcs_wait (ipmi_kcs_ctx_t ctx)
+{
+  /* Sit in loop waiting for the SMS_ATN register to be set.
+ This can also exit by invoking ipmi_kcs_wait_cancel */
+  ctx-event_exit = 0;
+  while (ctx-event_exit == 0)
+{
+  if (_ipmi_kcs_get_status (ctx)  IPMI_KCS_STATUS_REG_SMS_ATN)
+return(0);
+  sleep(1);
+}
+   
+   KCS_SET_ERRNUM(ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);
+   return (-1);
+}

A sleep of 1 second is probably too big for most people.  Perhaps we can
pass in a parameter to determine the usleep time??

Looking through the spec, I think not locking the inband sempahore is
probably safe.  Although there's a tiny part of me that says maybe we
should lock it just to be on the safe side.  A.B., what do you think?

+int
+ipmi_kcs_clear_wait (ipmi_kcs_ctx_t ctx)
+{
+  /* Allow the event thread to exit the wait loop */
+  ctx-event_exit = 1;
+}

This isn't thread safe.  Perhaps we can add back that extra semaphore
(like in your first patch) as the flag to break out of the loop?

BTW, a few commenting nits for when I integrate the patch, you don't
follow GNU coding style.  The biggest thing you're missing is a space
between a function call and the parentheses.  So for example:

 KCS_SET_ERRNUM(ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);

should be

 KCS_SET_ERRNUM (ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);

and

+  if (ctx-type == IPMI_DEVICE_KCS)
+{
+  return(ipmi_kcs_cmd_wait_event(ctx));
+}

there shouldn't be any braces with one line after the if.

 but I didn't run it on hardware yet because my customer has not yet 
 sent me the KCS hardware.

No problem.  Once we settle on a patch, we'll wait for you to test.
Once it's good to go, we can add it into FreeIPMI.

Al

On Mon, 2010-03-01 at 06:34 -0800, Matt Jerdonek wrote:
 
 Al,
 
 Thanks for the clarification.  I see your point and I updated the
 patch to address it.  As with the previous patch, this compiles, but I
 didn't run it on hardware yet because my customer has not yet sent me
 the KCS hardware.
 
 Thanks again,
 -Matt
 
 
 --- On Thu, 2/25/10, Al Chu ch...@llnl.gov wrote:
 
 From: Al Chu ch...@llnl.gov
 Subject: Re: [Freeipmi-devel] KCS Driver  SMS_ATN Register
 To: Matt Jerdonek maj1...@yahoo.com
 Cc: Anand Babu Periasamy a...@gnu.org.in,
 freeipmi-devel@gnu.org
 Date: Thursday, February 25, 2010, 10:33 AM
 
 Hi Matt,
 
 I don't see it that way.  I could see someone programming a
 single
 thread and only wanting to poll the SMS_ATN bit, and process
 events as
 they occur.  Not doing any other KCS. e.g.
 
 main()
 {
setup_kcs();
 
while (1) {
   kcs_wait_for_sms()
   get_message_flags()
   process_event()
}
 }
 
 Maybe I didn't describe it well.  The concern I have with your
 patch (if
 I'm reading it correctly, correct me if I'm wrong) is that the
 only time
 the SMS ATN bit is checked is in _ipmi_kcs_get_status().
 _ipmi_kcs_get_status() will only be called through other KCS
 functions
 like ipmi_kcs_read() and ipmi_kcs_write().
 
 So in order for the SMS ATN bit to be checked, ipmi_kcs_read()
 and
 ipmi_kcs_write() have to be called, either by your application
 or other
 IPMI going on in the system, otherwise the SMS_ATN bit will
 never be
 checked.  Correct?  Under your patch, in the above code
 snippet,
 kcs_wait_for_sms() will never return, b/c no other KCS calls
 are going
 on (unless they are other KCS IPMI going on in the system
 elsewhere). 
 
 Perhaps within your patch, you assumed other IPMI going on in
 other
 parts of the system?
 
 Al
 
 -- 
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory
 
 
 
-- 
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] KCS Driver SMS_ATN Register

2010-02-25 Thread Matt Jerdonek 
Al,

I'm not sure I understand your concern.  Using either the blocking semaphore as 
I suggested, or the blocking polling as you suggested, the application will 
have to create at least 2 threads: one to wait for events, and another to do 
everything else.  Right?

If that's the case, isn't using a semaphore a better approach in that it 
doesn't use as many processor cycles and alerts the application immediately?

Thanks,
-Matt





From: Al Chu ch...@llnl.gov
To: Matt Jerdonek maj1...@yahoo.com
Cc: Anand Babu Periasamy a...@gnu.org.in; freeipmi-devel@gnu.org
Sent: Wed, February 24, 2010 12:49:59 PM
Subject: Re: [Freeipmi-devel] KCS Driver  SMS_ATN Register

Hey Matt,

I noticed one or two minor nits, but I can fix em.  I guess I am only
perplexed by this design choice.  It seems you want to have two threads.
One thread does normal IPMI regularly, and the other thread will wait
for the SMS_ATN bit.  It appears that _ipmi_kcs_get_status() is the only
place that the SMS_ATN bit is checked, so you need to be doing some type
of other KCS in order to ever check for it?

Perhaps it'd be better to just have a function that regularly polls the
SMS_ATN bit, and if it is true, return to the user??  Perhaps something
like:

poll_sms_atn(unsigned int poll_interval, unsigned int max_iterations)
{
  while (count = max_iterations)
  {
  lock_kcs_semaphore();
  if (sms_atn bit set)
  break;
  unlock_kcs_sempahore();  
  sleep (poll_interval);
  }
  unlock_kcs_sempahore();  
}




Al

On Tue, 2010-02-23 at 08:27 -0800, Matt Jerdonek wrote:
 
 
 Please give the attached patch a look.  Since you two didn't like the
 idea of a callback, I created an API to wait for an event and a second
 API to cancel the wait.  Basically the application will be responsible
 for creating a thread which invokes the API.  The API will block the
 application's thread until an event occurs.  The application will be
 responsible for issuing a GET MESSAGE FLAGS command once the thread
 unblocks.
 
 I had to use a semaphore to block the thread, so I made some small
 changes to ipmi-semaphores.c as well.
 
 Note: this compiles, but I didn't try to run it yet.  My customer has
 not yet sent me the hardware with the KCS interface, so I don't have
 hardware to exercise the code.  
 
 Thanks again for your consideration,
 -Matt
 
 
-- 
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] KCS Driver SMS_ATN Register

2010-02-24 Thread Al Chu 
Hey Matt,

I noticed one or two minor nits, but I can fix em.  I guess I am only
perplexed by this design choice.  It seems you want to have two threads.
One thread does normal IPMI regularly, and the other thread will wait
for the SMS_ATN bit.  It appears that _ipmi_kcs_get_status() is the only
place that the SMS_ATN bit is checked, so you need to be doing some type
of other KCS in order to ever check for it?

Perhaps it'd be better to just have a function that regularly polls the
SMS_ATN bit, and if it is true, return to the user??  Perhaps something
like:

poll_sms_atn(unsigned int poll_interval, unsigned int max_iterations)
{
  while (count = max_iterations)
  {
  lock_kcs_semaphore();
  if (sms_atn bit set)
  break;
  unlock_kcs_sempahore();   
  sleep (poll_interval);
  }
  unlock_kcs_sempahore();  
}




Al

On Tue, 2010-02-23 at 08:27 -0800, Matt Jerdonek wrote:
 
 
 Please give the attached patch a look.  Since you two didn't like the
 idea of a callback, I created an API to wait for an event and a second
 API to cancel the wait.  Basically the application will be responsible
 for creating a thread which invokes the API.  The API will block the
 application's thread until an event occurs.  The application will be
 responsible for issuing a GET MESSAGE FLAGS command once the thread
 unblocks.
 
 I had to use a semaphore to block the thread, so I made some small
 changes to ipmi-semaphores.c as well.
 
 Note: this compiles, but I didn't try to run it yet.  My customer has
 not yet sent me the hardware with the KCS interface, so I don't have
 hardware to exercise the code.  
 
 Thanks again for your consideration,
 -Matt
 
 
-- 
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] KCS Driver SMS_ATN Register

2010-02-23 Thread Matt Jerdonek 


Please give the attached patch a look.  Since you two didn't like the idea of a 
callback, I created an API to wait for an event and a second API to cancel the 
wait.  Basically the application will be responsible for creating a thread 
which invokes the API.  The API will block the application's thread until an 
event occurs.  The application will be responsible for issuing a GET MESSAGE 
FLAGS command once the thread unblocks.

I had to use a semaphore to block the thread, so I made some small changes to 
ipmi-semaphores.c as well.

Note: this compiles, but I didn't try to run it yet.  My customer has not yet 
sent me the hardware with the KCS interface, so I don't have hardware to 
exercise the code.  

Thanks again for your consideration,
-Matt



  

ipmi_kcs_sms_atn.patch
Description: Binary data
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-22 Thread Al Chu 
Hey A.B.,

On Mon, 2010-02-22 at 01:16 -0800, Anand Babu Periasamy wrote:
 On Sun, Feb 21, 2010 at 8:38 AM, Al Chu ch...@llnl.gov wrote:
  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
 
 Then lets create an API and return ENOTSUP erno for system interfaces
 other than KCS (for now). It makes sense for higher level abstracted
 API to call get-message-flags in addition. This function is already
 asynchronous.  Application developers would prefer an async API over
 callback framework.

We'd probably return IPMI_ERR_DEVICE_NOT_SUPPORTED  or make a new error
code, but yeah, that's the basic idea.

Al

 --
 Anand Babu Periasamy
 GPG Key ID: 0x62E15A31
 Blog [http://*www.*unlocksmith.org]
 GlusterFS [http://*www.*gluster.org]
 GNU Operating System [http://*www.*gnu.org]
 
-- 
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] KCS Driver SMS_ATN Register

2010-02-21 Thread Matt Jerdonek 
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 ch...@llnl.gov
To: Anand Babu Periasamy a...@gnu.org.in
Cc: Matt Jerdonek maj1...@yahoo.com; freeipmi-devel@gnu.org
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 ch...@llnl.gov
  *To:* Matt Jerdonek maj1...@yahoo.com
  *Cc:* freeipmi-devel@gnu.org
  *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

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Anand Babu Periasamy 

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


Hi Matt,
If you use SMS_ATN flag, then you should also call Get Message Flags and check if 
Receive Message Available flag is set. SMS_ATN flag can also be set for other reasons 
such as watchdog pre-timeout, event message buffer full and OEM events.


My understanding was to use OBF flag for this purpose.

Check this out: Figure 9-7, KCS Interface BMC to SMS Read Transfer Flow Chart
http://download.intel.com/design/servers/ipmi/IPMI2_0E4_Markup_061209.pdf

SMS_ATN seems logical for this purpose given its name, but IPMI Spec uses OBF in its data 
flow diagram. SMS_ATN and OBF both seems to do the same job, except OBF is simple.
When should we check for SMS_ATN over OBF or should we check both always? Even OpenIPMI 
KCS driver uses OBF and not SMS_ATN flag for reading from registers.


SMS_ATN seems useful for high level polling (watch dog daemon). If all system management 
interfaces supports this flag, then it is worth exposing generic bmc_check_idle() api.


Your patches are most welcome.

--
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]


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Al Chu 
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
 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

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Matt Jerdonek 
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 ch...@llnl.gov
To: Matt Jerdonek maj1...@yahoo.com
Cc: freeipmi-devel@gnu.org
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
 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

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

2010-02-18 Thread Al Chu 
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??

Al

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 ch...@llnl.gov
 To: Matt Jerdonek maj1...@yahoo.com
 Cc: freeipmi-devel@gnu.org
 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
  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] KCS Driver SMS_ATN Register

2010-02-17 Thread Matt Jerdonek 
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
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel