Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
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 wrote: From: Al Chu Subject: Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register To: "Matt Jerdonek" Cc: "Anand Babu Periasamy" , 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
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 To: Matt Jerdonek Cc: Anand Babu Periasamy ; 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
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
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 To: Anand Babu Periasamy Cc: Matt Jerdonek ; 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 > > *To:* Matt Jerdonek > > *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
Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
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 To: Matt Jerdonek 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
[Freeipmi-devel] KCS Driver & SMS_ATN Register
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