Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-09-08 Thread Carol Hebert
Hi Corey,

Roger and I believe your approach sounds great and very much appreciate
your help.

Thank you very much again,

Carol

On Thu, 2006-09-07 at 18:23 -0500, Corey Minyard wrote:
 Roger Mach wrote:
  I took a look at these patchsets and they appear to be good, with just a
  couple of minor issues.  
 Thanks for taking time to look at this.
  First, I encountered a compiler error when
  building ipmi_kcs_intf.c that I believe was already reported on the
  ipmitool-devel list earlier today by Jarrod Johnson; the extra parameter
  to ipmi_register_smi() that needs to be added to a header file.

 I'd actually prefer to just pull this file out.  It is a subset of what
 is in ipmi_si.c and it doesn't have all the fixes and new features that
 ipmi_si.c has.  Is there a problem with just removing this?
  The second issue is a simple one-line patch that fixes an off-by-one bug
  that causes the driver to not detect the BMC on any machine that has its
  BMC as the last entry in the DMI table.  This patch is not present in
  these patchsets:

 Ok, got it.  Thanks.
 
 -Corey


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer


Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-09-07 Thread Corey Minyard
Roger Mach wrote:
 I took a look at these patchsets and they appear to be good, with just a
 couple of minor issues.  
Thanks for taking time to look at this.
 First, I encountered a compiler error when
 building ipmi_kcs_intf.c that I believe was already reported on the
 ipmitool-devel list earlier today by Jarrod Johnson; the extra parameter
 to ipmi_register_smi() that needs to be added to a header file.
   
I'd actually prefer to just pull this file out.  It is a subset of what
is in ipmi_si.c and it doesn't have all the fixes and new features that
ipmi_si.c has.  Is there a problem with just removing this?
 The second issue is a simple one-line patch that fixes an off-by-one bug
 that causes the driver to not detect the BMC on any machine that has its
 BMC as the last entry in the DMI table.  This patch is not present in
 these patchsets:
   
Ok, got it.  Thanks.

-Corey

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer


Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-08-24 Thread Corey Minyard
 Corey for so much work on the driver over the years, Matt
 for his more recent life support work on 2.4, and Carol for trying to get
 something going here...

   
 
 Bela
 
   
 -Original Message-
 From: [EMAIL PROTECTED] on behalf of Carol
 Hebert
 Sent: Tue 2006-08-08 2:55 PM
 To: openipmi-developer@lists.sourceforge.net
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Openipmi-developer Digest, Vol 2, Issue 11
  

 Hi Corey,

 We've been looking into what we can do to help facilitate this next 2.4
 patch set and your suggestion that we send diffs from the v37 driver and
 had a couple of questions:

 First, which kernels would you want to have patch sets for?  We've only
 been working on this issue with the 2.4.21 kernel but there appear to be
 patch sets for 3 different 2.4 kernels posted for v37.  Would you need
 to have us supply diffs/patches for all 3 kernels?

 Second, would it be possible to post a pointer to Matt's dkms website on
 the 2.4 driver download page?  Although Matt has several times posted a
 pointer to this website on the mailing list, customers probably don't
 know to dig through the mail archives to find it.

 Thank you very much again for your consideration and help with this
 issue.

 Carol Hebert
 LTC System x Enablement
 IBM Corp.


   
 
 Date: Mon, 24 Jul 2006 19:18:54 -0500
 From: Corey Minyard [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel
 support
 To: Carol Hebert [EMAIL PROTECTED]
 Cc: openipmi-developer@lists.sourceforge.net,   Matt Domsch
 [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii

 I'll have to think about this. I don't really view this as a one more
 release type of thing. There's always one more thing to do. Instead, I
 view this as a support issue. Do I support 2.4, or not?

 I'm pressed for time over the near future, so it will be difficult for
 me to do this. If you could get the pieces you need working and send me
 a diff from the v37 driver, that would probably be the easiest. This
 will also require work from Matt to package things up; I don't know if
 he is able to do this.

 -Corey

 Carol Hebert wrote:
 
   
 Hi Corey,

 We have a critical situation concerning our IBM System x customers who
 are running RHEL3U6 and other 2.4 distro kernels that do not contain the
 IPMI driver speed-up fixes Matt Domsch posted for RHEL3U7 (Red Hat BZ
 #168358, #168795) and for the 2.6 kernel on SourceForge. Without Matt's
 fixes, our Flash utility takes upward of 2.5 hours to complete which is
 considered unusable for our customers due to the danger a flash of that
 time length poses to our customers' BMCs.

 I've seen your note posted with the v37 driver that it will be your last
 2.4 maintenance release but I was wondering if we might ask you to
 reconsider and post one more patch set which contains Matt's speed-up
 fixes and some of the other critical fixes which haven't yet been posted
 for 2.4 in v37? Our team is not in a position to be able to take on the
 maintenance and support role for v38 as your v37 note suggested
 someone do but would be willing to help put a patch together.

 We are hoping that the mileage Matt's speed-up patch has already put in
 on RHEL3U7 will suffice to a certain extent in proving the patch's
 correctness and stability since we have only System x boxes on which to
 test the patch.

 We, and many other vendors I suspect (speak up now!), would be very
 grateful to you if you would consider posting one more version of the
 OpenIPMI driver on SourceForge for 2.4 kernels. Please let me know what
 we can do to help make this last 2.4 patch set happen.

 Thank you very much for your consideration of this critical matter,

 Carol Hebert
 LTC System x Enablement
 IBM Corp.
   
 
 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Openipmi-developer mailing list
 Openipmi-developer@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/openipmi-developer
   
 


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Openipmi-developer mailing list
 Openipmi-developer@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/openipmi

Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-08-24 Thread Bela Lubkin
Corey Minyard wrote (in 3 messages):

 I forgot to mention that the v37 code does actually make sense.
 Everything Matt has worked on has gone to the mainstream kernel, so all
 Matt's changes should be there, either already in v37, or in future
 patches to the main kernel.

The ones I spot-checked for were not in v37, and I could not use the
future/main kernel stuff since I'm working in a fairly backwater
2.4-based environment.  My attempts to sanely bring up Matt's patches,
plus some HP patches I was trying to integrate, on the v37 base, were
not at all successful.  So I greatly appreciate your work here...

 I've spent some time today working on this.  My strategy is to go from
 the v37 driver (which is both in the 2.6 kernel and 2.4 kernel) and go
 forward from there from lkml patches that are appropriate.  I have a
 base set of patches that compile and work.

 Do we need emulator capability?  How about smb?

We are not building any of the emulation or SMBus modules; can't speak
for anyone else though.

The SMBus module implies the existence of hardware that can only be
accessed that way.  We only need this stuff to work on big server
class machines.  Am I right in guessing that IPMI-over-SMBus is going to
be found only in small embedded devices?

 I have a set of patches that should bring forward the 2.4 driver to the
 same level of features as the 2.6 driver (as close as you can get, I
 think).  I have three sets of quilt patches at:

 http://openipmi.sourceforge.net/patches-2.4.20.tar.gz
 http://openipmi.sourceforge.net/patches-2.4.21.tar.gz
 http://openipmi.sourceforge.net/patches-2.4.32.tar.gz

 These all contain the same basic things:

 * a patches directory with all the patches and a series file
 * The NMI patch
 * The v37 base patch (exactly from the sourceforge download)
 * A set of patches to add all the necessary features
 * Patches for 2.4.20 and 2.4.21 to bring them to exactly the same
   level as 2.4.32.  There are some minor necessary differences with
   ACPI (ACPI is not fully cooked in 2.4.21), but that is all.
 * The SMBus patch (untested)

 I have only done basic testing on the interface (basic messaging, no
 watchdog, power control, etc.) on the 2.4.32 and 2.4.20 kernels (there's
 no basic difference here between 2.4.20 and 2.4.21, and I ran out of
 time to test 2.4.21 except for compiling).

 My theory is to bring each kernel up to as close textually as possible
 with individual patches.  From this point onward, we can issue one patch
 and it will apply to all 2.4 kernel versions.  This should reduce the
 maintenance burden; hopefully there won't be that many patches.

That sounds like a good approach.  The whitespace changes are sort of
painful (makes this look like more change than it is), but they are
worth it to set a level baseline.

  It
 would be nicer to use the 2.6 kernel as a base version, but there are
 just too many differences.

That's what I ran into when I briefly flirted with trying to use 2.6
ongoing versions.  They don't even want to think about being compiled in
a 2.4 environment...

 So when we release this set of patches, I'll roll each up into a v37-v39
 patch for the respective kernel, and that will go onto sourceforge.

 If you have never used quilt before, you don't have to get it and learn
 it.  The tarball contains a set of patches and a file named series.
 The series file contains the list of patches in the order they should be
 applied.  So you can write a simple script (cat patches/series | while
 read i; do patch patches/$i; done) to apply the patches.

 If you are interested in this, can you make sure this has all the
 features and updates you need?  I've preserved the original git headers
 in the patches that came from 2.6 so you can review them.

For me, it will probably take about 2-3 months to really be able to
answer this.  I'm about to be out of the office for ~2 months (new baby)
plus it will take a lot of complicated QA cycles, testing with
management agents from all of our OEM partners and on various hardware.
I will look into how much QA gear I can engage before I drop out of
sight.

I'm also going to ask my contact at HP to engage with this, make sure
their changes get pulled in during this current active cycle.

Thanks,

Bela

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer


Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-08-23 Thread Corey Minyard
I forgot to mention that the v37 code does actually make sense. 
Everything Matt has worked on has gone to the mainstream kernel, so all
Matt's changes should be there, either already in v37, or in future
patches to the main kernel.

-Corey

Corey Minyard wrote:
 I'm going to be out for a little while, so I can't work on this for a
 little while.  The particular kernel version is really up to you; I can
 support any particular one, but I have no preference.

 -Corey

 Bela Lubkin wrote:
   
 Corey, Carol --

 Does a distribution in terms of patches against v37 code even make sense?
 The code base that Matt has been working from is off of OpenIPMI v35; to
 patch to that from v37 is basically to rewind a bunch of previous patches.
 It seems like it might be better to declare it a fork at v35.

 Anyway.  Carol had hinted for me to speak up:

   
 
 We, and many other vendors I suspect (speak up now!), would be very
 grateful ...
   
 
 ... and I should have done that.  I am working at one of those vendors who
 would benefit from an updated OpenIPMI-for-2.4 driver base.  I don't speak
 for VMware so I hesitate to say something like VMware would be grateful --
 subtle semantic point.

 Anyway.  We have now integrated into the upcoming VMware 2.5.4 console OS
 kernel the version of OpenIPMI found in Red Hat Enterprise Linux 3 Update 8,
 i.e. RHEL3U8.  This is very close to the last version I saw on Matt Domsch's
 FTP repository; from memory, the only differences are one or two IBM patches
 in the motherboard-table-based BMC detection, and some minor changes to the
 locking calls.

 We had previously checked in some v37-based code with added patches, supplied
 to us by HP.  We received that as pre-integrated sources so it's not easy for
 me to say exactly where the patches originated.  Relative to v37, the patches
 added support for OEM channel messages and for HP's PCI BMC.  I was not able
 to disentangle these patches and layer them onto the Domsch/RHEL3U8 35.13
 code base; nor did I have much fun trying to get Corey's PCI support stuff
 (http://lkml.org/lkml/diff/2006/3/21/429/1) integrated.  I gave up on these
 because I felt that I was just destabilizing the driver, and the 35.13 code
 gained almost as much performance as the HP PCI patch.  That is, on the HP
 PCI BMC it performed nearly as well; on any other BMC, it was miles ahead of
 the v37-based driver.

 Unfortunately, VMware ESX Server 3.0.0 did ship with the v37-based driver.
 The v35.13 code is supposed to be integrated in for an update, probably
 3.0.2.  Until then, OpenIPMI is problematic on ESX 3 except on HP PCI BMC
 systems.

 I hope to eventually converge on something 35.13-based + proper PCI interrupt
 support + OEM channel messages + whatever other goodness might be pulled out
 of the current 2.6 v39 driver.  But I'm fairly happy where I am right now,
 without integrating all that and destabilizing.

 I'd like to thank Corey for so much work on the driver over the years, Matt
 for his more recent life support work on 2.4, and Carol for trying to get
 something going here...

   
 
 Bela
 
   
 -Original Message-
 From: [EMAIL PROTECTED] on behalf of Carol
 Hebert
 Sent: Tue 2006-08-08 2:55 PM
 To: openipmi-developer@lists.sourceforge.net
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Openipmi-developer Digest, Vol 2, Issue 11
  

 Hi Corey,

 We've been looking into what we can do to help facilitate this next 2.4
 patch set and your suggestion that we send diffs from the v37 driver and
 had a couple of questions:

 First, which kernels would you want to have patch sets for?  We've only
 been working on this issue with the 2.4.21 kernel but there appear to be
 patch sets for 3 different 2.4 kernels posted for v37.  Would you need
 to have us supply diffs/patches for all 3 kernels?

 Second, would it be possible to post a pointer to Matt's dkms website on
 the 2.4 driver download page?  Although Matt has several times posted a
 pointer to this website on the mailing list, customers probably don't
 know to dig through the mail archives to find it.

 Thank you very much again for your consideration and help with this
 issue.

 Carol Hebert
 LTC System x Enablement
 IBM Corp.


   
 
 Date: Mon, 24 Jul 2006 19:18:54 -0500
 From: Corey Minyard [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel
 support
 To: Carol Hebert [EMAIL PROTECTED]
 Cc: openipmi-developer@lists.sourceforge.net,   Matt Domsch
 [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii

 I'll have to think about this. I don't really view this as a one more
 release type of thing. There's always one more thing to do. Instead, I
 view this as a support issue. Do I support 2.4, or not?

 I'm pressed for time over the near future, so it will be difficult for
 me to do this. If you could get the pieces you need working and send me
 a diff from

Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support

2006-08-23 Thread Corey Minyard
I've spent some time today working on this.  My strategy is to go from
the v37 driver (which is both in the 2.6 kernel and 2.4 kernel) and go
forward from there from lkml patches that are appropriate.  I have a
base set of patches that compile and work.

Do we need emulator capability?  How about smb?

-Corey

Bela Lubkin wrote:
 Corey, Carol --

 Does a distribution in terms of patches against v37 code even make sense?
 The code base that Matt has been working from is off of OpenIPMI v35; to
 patch to that from v37 is basically to rewind a bunch of previous patches.
 It seems like it might be better to declare it a fork at v35.

 Anyway.  Carol had hinted for me to speak up:

   
 We, and many other vendors I suspect (speak up now!), would be very
 grateful ...
   

 ... and I should have done that.  I am working at one of those vendors who
 would benefit from an updated OpenIPMI-for-2.4 driver base.  I don't speak
 for VMware so I hesitate to say something like VMware would be grateful --
 subtle semantic point.

 Anyway.  We have now integrated into the upcoming VMware 2.5.4 console OS
 kernel the version of OpenIPMI found in Red Hat Enterprise Linux 3 Update 8,
 i.e. RHEL3U8.  This is very close to the last version I saw on Matt Domsch's
 FTP repository; from memory, the only differences are one or two IBM patches
 in the motherboard-table-based BMC detection, and some minor changes to the
 locking calls.

 We had previously checked in some v37-based code with added patches, supplied
 to us by HP.  We received that as pre-integrated sources so it's not easy for
 me to say exactly where the patches originated.  Relative to v37, the patches
 added support for OEM channel messages and for HP's PCI BMC.  I was not able
 to disentangle these patches and layer them onto the Domsch/RHEL3U8 35.13
 code base; nor did I have much fun trying to get Corey's PCI support stuff
 (http://lkml.org/lkml/diff/2006/3/21/429/1) integrated.  I gave up on these
 because I felt that I was just destabilizing the driver, and the 35.13 code
 gained almost as much performance as the HP PCI patch.  That is, on the HP
 PCI BMC it performed nearly as well; on any other BMC, it was miles ahead of
 the v37-based driver.

 Unfortunately, VMware ESX Server 3.0.0 did ship with the v37-based driver.
 The v35.13 code is supposed to be integrated in for an update, probably
 3.0.2.  Until then, OpenIPMI is problematic on ESX 3 except on HP PCI BMC
 systems.

 I hope to eventually converge on something 35.13-based + proper PCI interrupt
 support + OEM channel messages + whatever other goodness might be pulled out
 of the current 2.6 v39 driver.  But I'm fairly happy where I am right now,
 without integrating all that and destabilizing.

 I'd like to thank Corey for so much work on the driver over the years, Matt
 for his more recent life support work on 2.4, and Carol for trying to get
 something going here...

   
 Bela
 

 -Original Message-
 From: [EMAIL PROTECTED] on behalf of Carol
 Hebert
 Sent: Tue 2006-08-08 2:55 PM
 To: openipmi-developer@lists.sourceforge.net
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Openipmi-developer Digest, Vol 2, Issue 11
  

 Hi Corey,

 We've been looking into what we can do to help facilitate this next 2.4
 patch set and your suggestion that we send diffs from the v37 driver and
 had a couple of questions:

 First, which kernels would you want to have patch sets for?  We've only
 been working on this issue with the 2.4.21 kernel but there appear to be
 patch sets for 3 different 2.4 kernels posted for v37.  Would you need
 to have us supply diffs/patches for all 3 kernels?

 Second, would it be possible to post a pointer to Matt's dkms website on
 the 2.4 driver download page?  Although Matt has several times posted a
 pointer to this website on the mailing list, customers probably don't
 know to dig through the mail archives to find it.

 Thank you very much again for your consideration and help with this
 issue.

 Carol Hebert
 LTC System x Enablement
 IBM Corp.


   
 Date: Mon, 24 Jul 2006 19:18:54 -0500
 From: Corey Minyard [EMAIL PROTECTED]
 Subject: Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel
  support
 To: Carol Hebert [EMAIL PROTECTED]
 Cc: openipmi-developer@lists.sourceforge.net,Matt Domsch
  [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii

 I'll have to think about this. I don't really view this as a one more
 release type of thing. There's always one more thing to do. Instead, I
 view this as a support issue. Do I support 2.4, or not?

 I'm pressed for time over the near future, so it will be difficult for
 me to do this. If you could get the pieces you need working and send me
 a diff from the v37 driver, that would probably be the easiest. This
 will also require work from Matt to package things up; I don't know if
 he is able to do this.

 -Corey

 Carol Hebert wrote:
 
 Hi Corey