Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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=lnk&kid=120709&bid=263057&dat=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
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=lnk&kid=120709&bid=263057&dat=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
On Thu, 24 Aug 2006 09:53:51 -0500 (07:53 PDT), Corey Minyard wrote: > 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) > > . . . > > 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. Corey, I took a look at these patchsets and they appear to be good, with just a couple of minor issues. 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. 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: diff -Nurp linux-2.4.21-37.EL.orig/drivers/char/ipmi/ipmi_si.c linux-2.4.21-37.EL/drivers/char/ipmi/ipmi_si.c --- linux-2.4.21-37.EL.orig/drivers/char/ipmi/ipmi_si.c 2006-07-11 09:07:40.0 -0700 +++ linux-2.4.21-37.EL/drivers/char/ipmi/ipmi_si.c2006-07-11 09:14:39.0 -0700 @@ -1668,7 +1668,7 @@ static int dmi_table(u32 base, int len, u8*buf; struct dmi_header *dm; u8*data; - int i=1; + int i=0; int status=-1; buf = ioremap(base, len); Other than these two minor issues, these patchsets look great - thanks for putting them together. -- Roger > 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=lnk&kid=120709&bid=263057&dat=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
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 > 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=lnk&kid=120709&bid=263057&dat=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
ntually 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, >>>> >>>> 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 ot
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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 PR
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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.
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
Hi, Corey: Thanks much for your reply on the kernel version. As long as you're amenable to it, I think it makes the most sense to try to come up with current support for the 2.4.21 kernel only (at least for now). Bela: Thank you very much for speaking up and for all your work in exploring all the various 2.4 OpenIPMI driver version possibilities and patches. :-) FWIW, I agree the v35.13 code is the most functional and stable starting point. From there, though, it sounds like it'll be a fairly large chunk of work to get the rest of the desired patches integrated and sufficiently tested. Do you have a feel for how much time it will take and how much of the work can be parallelized? I would be happy to volunteer to work with you on this and maybe there are some other folks in this forum who had a few cycles and the inclination to help as well (?). Thanks very much again Bela, for all your work, interest, and support. And I most heartily second your thanks to Corey and Matt for all they've done and continue to do for all of us. Carol Hebert > Date: Tue, 08 Aug 2006 22:37:37 -0500 > From: Corey Minyard <[EMAIL PROTECTED]> > Subject: Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel > support > To: Bela Lubkin <[EMAIL PROTECTED]> > Cc: openipmi-developer@lists.sourceforge.net > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > 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... > > > > > &g
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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 a
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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, > > > > We have a critical situation concerning our IBM System x customers who > > are running RHEL
Re: [Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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. > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Openipmi-developer mailing list > Openipmi-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openipmi-developer > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[Openipmi-developer] Need help with OpenIPMI 2.4 kernel support
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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
