Menu
▾
▴
ipmiutil-developers — Discussion and best-effort support of IPMI utilities.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(17) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(2) |
Feb
(4) |
Mar
(8) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
(17) |
Jul
(2) |
Aug
(5) |
Sep
(1) |
Oct
(14) |
Nov
(2) |
Dec
(3) |
| 2007 |
Jan
(11) |
Feb
(4) |
Mar
(10) |
Apr
(4) |
May
(9) |
Jun
(5) |
Jul
(11) |
Aug
(6) |
Sep
(9) |
Oct
(16) |
Nov
(8) |
Dec
(3) |
| 2008 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
|
Jun
(2) |
Jul
(2) |
Aug
(12) |
Sep
(4) |
Oct
(2) |
Nov
(6) |
Dec
(8) |
| 2009 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
(12) |
Nov
(1) |
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
(4) |
Mar
(25) |
Apr
(7) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(9) |
Sep
(8) |
Oct
(1) |
Nov
(7) |
Dec
(5) |
| 2011 |
Jan
(3) |
Feb
(15) |
Mar
(6) |
Apr
(9) |
May
(5) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(5) |
| 2012 |
Jan
(11) |
Feb
(4) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(10) |
Oct
(14) |
Nov
(1) |
Dec
(3) |
| 2013 |
Jan
(9) |
Feb
(3) |
Mar
(2) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(1) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(3) |
| 2014 |
Jan
(1) |
Feb
(14) |
Mar
(10) |
Apr
(4) |
May
(3) |
Jun
(12) |
Jul
(6) |
Aug
(12) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(3) |
| 2015 |
Jan
|
Feb
(6) |
Mar
(2) |
Apr
(4) |
May
(28) |
Jun
(5) |
Jul
(7) |
Aug
(2) |
Sep
(9) |
Oct
(3) |
Nov
(14) |
Dec
(7) |
| 2016 |
Jan
|
Feb
(2) |
Mar
(24) |
Apr
(12) |
May
(8) |
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(4) |
Nov
|
Dec
(6) |
| 2017 |
Jan
|
Feb
(3) |
Mar
(7) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andy C. <and...@gm...> - 2021-06-02 01:59:09
|
Looks good. This should go into the next version 3.1.8.
On Fri, May 21, 2021 at 10:42 AM Richard van Paasen <rvp...@t3...> wrote:
> From 0b68cae07229c90103457cd8c7e1935c3a392937 Mon Sep 17 00:00:00 2001
> From: Richard van Paasen <rvp...@t3...>
> Date: Thu, 20 May 2021 23:28:27 +0200
> Subject: [PATCH] Fix util/idiscover -i option to accept interface name,
> IP
> address and 0.0.0.0
>
> ---
> util/idiscover.c | 40 ++++++++++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/util/idiscover.c b/util/idiscover.c
> index 567cf05..e5d8d40 100644
> --- a/util/idiscover.c
> +++ b/util/idiscover.c
> @@ -283,17 +283,19 @@ static void cleanup(void)
>
> void show_usage(void)
> {
> - printf("Usage: %s [-abegix] \n",progname);
> - printf(" -a all nodes, enables broadcast ping\n");
> - printf(" -b <ip> beginning IP address (x.x.x.x), required\n");
> - printf(" -e <ip> ending IP address (x.x.x.x), default is begin
> IP\n");
> - printf(" -g use GetChanAuthCap instead of RMCP ping\n");
> - printf(" -i interface name, default is eth0\n");
> - printf(" -m get MAC addresses with a raw broadcast
> ping\n");
> - printf(" -p N specific Port (IPMI LAN port=623)\n");
> - printf(" -r N number of Repeat pings to each node
> (default=1)\n");
> - // printf(" -s specific subnet\n");
> - printf(" -x show eXtra debug messages\n");
> + printf("Usage: %s [-abeghimprx] \n",progname);
> + printf(" -a all nodes, enables broadcast ping\n");
> + printf(" -b <ip> beginning IP address (x.x.x.x),
> required\n");
> + printf(" -e <ip> ending IP address (x.x.x.x), default is
> begin IP\n");
> + printf(" -g use GetChanAuthCap instead of RMCP ping\n");
> + printf(" -h print this help text\n");
> + printf(" -i <name|ip> interface to use: name, IP address or
> 0.0.0.0\n");
> + printf(" defaults to first network interface (e.g.
> eth0)\n");
> + printf(" -m get MAC addresses with a raw broadcast
> ping\n");
> + printf(" -p <N> specific port (IPMI LAN port=623)\n");
> + printf(" -r <N> number of repeat pings to each node
> (default=1)\n");
> +// printf(" -s specific subnet\n");
> + printf(" -x show extra debug messages\n");
> }
>
> static int os_sleep(unsigned int s, unsigned int u)
> @@ -528,11 +530,17 @@ int sock_init( char *_interface, char *_startIP,
> char *_endIP)
> } else { /* valid _interface string */
> if (strchr(_interface, '.') != NULL)
> { /* assume it is an IP address*/
> - if ((rv = inet_pton(AF_INET, _interface, &_srcaddr.sin_addr))
> < 0)
> + rv = inet_pton(AF_INET, _interface, &_srcaddr.sin_addr);
> + if (rv < 0)
> + {
> printerr("inet_pton: %s\n", showlasterr());
> - if (rv == 0)
> + return(-1);
> + }
> + if (rv == 0)
> + {
> printerr("invalid interface address\n");
> - return(rv);
> + return(-1);
> + }
> }
> else
> { /* assume interface name, like eth0 */
> @@ -963,7 +971,7 @@ main(int argc, char **argv)
> #endif
> printf("%s ver %s\n", progname,progver);
>
> - while ( (c = getopt( argc, argv,"ab:ce:gi:l:mp:r:s:x?")) != EOF )
> + while ( (c = getopt( argc, argv,"ab:ce:ghi:l:mp:r:s:x?")) != EOF )
> switch(c) {
> case 'a': fBroadcastOk = 1; fping = 1;
> break; /*all (broadcast ping)*/
> @@ -996,7 +1004,7 @@ main(int argc, char **argv)
> * begin/end range. */
> break;
> case 'x': fdebug = 1; break; /* debug messages */
> - default:
> + case 'h': default:
> if (fdebug) printerr("getopt(%c) default\n",c);
> show_usage();
> rv = ERR_USAGE;
> --
> 2.14.1
>
>
> _______________________________________________
> ipmiutil-developers mailing list
> ipm...@li...
> https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers
>
|
|
From: Richard v. P. <rvp...@t3...> - 2021-05-20 21:53:21
|
Met vriendelijke groet / Kind regards, Richard van Paasen |
|
From: Doug N. <ad...@po...> - 2020-10-21 19:54:42
|
I'm trying to figure out how to interpret a line like this: 004a SDR Full 01 6f 20 a 0d snum 49 C1 P1I Bay 1 = 8005 DiscreteEvt I guess the 8005 is a bit field. Is there a standard way to interpret those bits? Thanks Doug |
|
From: Andy C. <and...@gm...> - 2020-09-07 12:39:46
|
The ipmiutil-3.1.7 update is now released and available on sourceforge and
github.
Changes:
08/31/2020 ARCress ipmiutil-3.1.7 changes (iver 3.17)
setup/* - added Win msi setup files
lib/lanplus/lanplus.c - revert WIN IPv6 changes, add os_assert routine
lib/lanplus/lanplus_crypt.c - switch assert to os_assert
lib/lanplus/lanplus_crypt_implc.c - switch assert to os_assert
util/ipmidir.h - AMD_SMB_1_STATUS_* 1< to 1<< (SF_SR#41)
util/isel.c - fix compile warning
util/ilan.c - fix compile warning
configure.ac - add --enable-doc option to allow not building
documentation
contributed by Fabrice Fontaine (ffontaine)
util/isensor.c - add SDR conflict 0xC5 handling retries with delay
contributed by albertlav
|
|
From: Eduard G. <egu...@gm...> - 2020-03-17 22:34:22
|
Thank you, Andy. On Tue, Mar 17, 2020 at 6:32 PM Andy Cress <and...@gm...> wrote: > This fix is now included in ipmiutil-3.1.6 from http://ipmiutil.sf.net > > Andy > > On Wed, Mar 4, 2020 at 11:13 PM Eduard Guzovsky <egu...@gm...> > wrote: > >> I am using ipmiutil-3.1.2-3.el7.x86_64. >> >> >> Running "ipmiutil sel -d" clears the log of all SEL records, but it does >> not clear /var/lib/ipmiutil/sel.idx file. If several new SEL records are >> added to the log after that, "ipmiutil sel -w" fails to retrieve them >> because sel.idx has a stale index of the last record retrieved from the >> log. >> >> I think, "ipmiutil sel -d" should also delete /var/lib/ipmiutil/sel.idx >> file. As a temporary workaround I added deletion of the sel.idx file to >> "/usr/share/ipmiutil/checksel" script >> >> --- a/ipmiutil/checksel >> +++ b/ipmiutil/checksel >> @@ -26,5 +26,6 @@ if [ $? -eq 0 ]; then >> $pdir/ipmiutil sel -e >$ddir/ipmisel_${today}.txt >> # Clear the IPMI SEL >> $pdir/ipmiutil sel -d >> + /bin/rm -f $ddir/sel.idx >> fi >> fi >> >> >> Thanks, >> >> >> -Ed >> >> _______________________________________________ >> ipmiutil-developers mailing list >> ipm...@li... >> https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers >> > |
|
From: Andy C. <and...@gm...> - 2020-03-17 22:32:35
|
This fix is now included in ipmiutil-3.1.6 from http://ipmiutil.sf.net Andy On Wed, Mar 4, 2020 at 11:13 PM Eduard Guzovsky <egu...@gm...> wrote: > I am using ipmiutil-3.1.2-3.el7.x86_64. > > > Running "ipmiutil sel -d" clears the log of all SEL records, but it does > not clear /var/lib/ipmiutil/sel.idx file. If several new SEL records are > added to the log after that, "ipmiutil sel -w" fails to retrieve them > because sel.idx has a stale index of the last record retrieved from the > log. > > I think, "ipmiutil sel -d" should also delete /var/lib/ipmiutil/sel.idx > file. As a temporary workaround I added deletion of the sel.idx file to > "/usr/share/ipmiutil/checksel" script > > --- a/ipmiutil/checksel > +++ b/ipmiutil/checksel > @@ -26,5 +26,6 @@ if [ $? -eq 0 ]; then > $pdir/ipmiutil sel -e >$ddir/ipmisel_${today}.txt > # Clear the IPMI SEL > $pdir/ipmiutil sel -d > + /bin/rm -f $ddir/sel.idx > fi > fi > > > Thanks, > > > -Ed > > _______________________________________________ > ipmiutil-developers mailing list > ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers > |
|
From: Andy C. <and...@gm...> - 2020-03-17 05:11:21
|
The ipmiutil-3.1.6 release is now posted on http://ipmiutil.sf.net ChangeLog: 03/15/2020 ARCress ipmiutil-3.1.6 changes (iver 3.16) util/iconfig.c - fix Fedora bug 1811462 [abrt] ipmiutil config -a util/ipmiutil.c - show version with usage (-?) if no subcommand doc/ipmiutil.spec - renamed ipmiutil.env as .env.template (contributed by mwilliams<at>illuminate.solutions) scripts/ipmiutil.env.template - renamed env as template scripts/Makefile.am - renamed env as template scripts/checksel - also rm -f $ddir/sel.idx after isel -d (contributed by eguzovsky<at>gmail.com) doc/Makefile.am - change gzip -f to gzip -nf for man pages (SF_SR#40 patch from Jeremy Puhlman) |
|
From: Eduard G. <egu...@gm...> - 2020-03-05 04:13:38
|
I am using ipmiutil-3.1.2-3.el7.x86_64.
Running "ipmiutil sel -d" clears the log of all SEL records, but it does
not clear /var/lib/ipmiutil/sel.idx file. If several new SEL records are
added to the log after that, "ipmiutil sel -w" fails to retrieve them
because sel.idx has a stale index of the last record retrieved from the log.
I think, "ipmiutil sel -d" should also delete /var/lib/ipmiutil/sel.idx
file. As a temporary workaround I added deletion of the sel.idx file to
"/usr/share/ipmiutil/checksel" script
--- a/ipmiutil/checksel
+++ b/ipmiutil/checksel
@@ -26,5 +26,6 @@ if [ $? -eq 0 ]; then
$pdir/ipmiutil sel -e >$ddir/ipmisel_${today}.txt
# Clear the IPMI SEL
$pdir/ipmiutil sel -d
+ /bin/rm -f $ddir/sel.idx
fi
fi
Thanks,
-Ed
|
|
From: Andy C. <and...@gm...> - 2019-11-25 16:55:32
|
The ipmiutil-3.1.5 release is now posted on http://ipmiutil.sf.net ChangeLog: 11/25/2019 ARCress ipmiutil-3.1.5 changes (iver 3.15) Windows EXEs built with openssl 1.0.2 util/isensor.c - workaround for Pigeon Point bad sa in SDR buildwin.cmd - detect/set MARCH=IA86 or X64 from vcvars buildmin.cmd - detect/set MARCH=IA86 or X64 for minimal buildwinARM64.cmd - new for ARM64 build (SF ticket# 38), Contributed by Hozefa Karachiwala util/ipmiutil64.mak - changed for ARM64, Contributed by Hozefa Karachiwala lib/lanplus/ipmiplus.mak - changed for ARM64, Contributed by Hozefa Karachiwala FILES/ipmiutil-3.1.5-arm64.zip - built with openssl 1.x Contributed by Hozefa Karachiwala |
|
From: Andy C. <and...@gm...> - 2019-10-16 13:18:09
|
Neeraj, Good question. The Send Message / Get Message commands are leveraged by the IPMI driver, so applications must use the method that the driver exposes. This makes it slightly different, depending on which IPMI driver is being used. Given that you are already sending and getting responses, you must already be doing this. There is an example of this in ipmiutil in util/igetevent.c (see DO_ASYNC flags). I know that the IPMI drivers & firmware that I have tested basically return the messages when they are ready, but not necessarily in the order they were sent. One option would be to include a function_id/stage_id/sequence_number within the message body so that the receiver can know how to interpret it. This would work if the destination is not just the firmware, but an application at the other end. Another option would be to make sure that additional send messages are queued in the application until the previous message gets a response. Andy On Sun, Oct 13, 2019 at 2:51 AM Neeraj Ladkani <nee...@gm...> wrote: > As I understand, we can only use Send Message without tracking support > from inband and its system software responsibility to match requests and > responses. > > Can you confirm if it's done in driver or ipmiutil? I see an issue where > the response from two separate get IPMI messages are being swapped. > > any help on how to solve this? > -- > Thanks > Neeraj > > |
|
From: Neeraj L. <nee...@gm...> - 2019-10-13 06:51:54
|
As I understand, we can only use Send Message without tracking support from inband and its system software responsibility to match requests and responses. Can you confirm if it's done in driver or ipmiutil? I see an issue where the response from two separate get IPMI messages are being swapped. any help on how to solve this? -- Thanks Neeraj |
|
From: Andy C. <and...@gm...> - 2019-10-10 01:36:23
|
> Hozefa, > > Yes, you need to create/login with a sourceforge.net user first. > At this link you should be able to click 'Create Account' > https://sourceforge.net/auth/ > > Andy > > On Wed, Oct 9, 2019 at 9:23 PM <sit...@li...> > wrote: > >> The attached message matched the ipmiutil-developers mailing list's >> content filtering rules and was prevented from being forwarded on to >> the list membership. You are receiving the only remaining copy of the >> discarded message. >> >> ---------- Forwarded message ---------- >> From: Hozefa Karachiwala <Hoz...@mi...> >> To: Andy Cress <and...@gm...> >> Cc: "ipm...@li..." < >> ipm...@li...>, YoungShin Yoon < >> You...@mi...> >> Bcc: >> Date: Thu, 10 Oct 2019 00:04:39 +0000 >> Subject: RE: [ipmiutil-developers] ipmiutil for Windows ARM64 >> >> Hi Andy, >> >> >> >> I am not able to create a patch, the create ticket is greyed out for me. >> >> Do I need to join some group? >> >> >> >> <gif> >> > >> >> Thanks >> >> -Hozefa >> >> >> >> *From:* Andy Cress <and...@gm...> >> *Sent:* Tuesday, October 8, 2019 8:14 AM >> *To:* Hozefa Karachiwala <Hoz...@mi...> >> *Cc:* ipm...@li...; YoungShin Yoon < >> You...@mi...> >> *Subject:* Re: [ipmiutil-developers] ipmiutil for Windows ARM64 >> >> >> >> That sounds great. >> >> If you can provide your changes with a patch ( >> https://sourceforge.net/p/ipmiutil/patches/ >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fipmiutil%2Fpatches%2F&data=02%7C01%7CHozefa.Karachiwala%40microsoft.com%7C0943f46aee4b451b9eb208d74c023499%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637061444687804148&sdata=bO2NwK2mTxBEWf6ekkNZsosmuxO8iBW24l4fdbKQSvs%3D&reserved=0>) >> or similar format that would be great. >> >> We can get that merged into the next release. >> >> >> >> Andy >> >> >> >> On Tue, Oct 8, 2019 at 11:08 AM Hozefa Karachiwala via >> ipmiutil-developers <ipm...@li...> wrote: >> >> Hello ipmiutil Developers, >> >> I was able to compile ipmiutil for Windows ARM64 and use it on a few >> systems we have. Would you be willing to upstream those changes? I can >> provide a PR with the changes I made. >> I compiled it with SSL 1.1 and Visual Studio 2017. >> >> Thanks >> -Hozefa >> >> _______________________________________________ >> ipmiutil-developers mailing list >> ipm...@li... >> https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fipmiutil-developers&data=02%7C01%7CHozefa.Karachiwala%40microsoft.com%7C0943f46aee4b451b9eb208d74c023499%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637061444687814144&sdata=KhMk41pdVJi8%2BS74xev6T3aWdB7OVKLy0UZZykJo%2F%2B0%3D&reserved=0> >> >> |
|
From: Andy C. <and...@gm...> - 2019-10-08 15:14:34
|
That sounds great. If you can provide your changes with a patch ( https://sourceforge.net/p/ipmiutil/patches/) or similar format that would be great. We can get that merged into the next release. Andy On Tue, Oct 8, 2019 at 11:08 AM Hozefa Karachiwala via ipmiutil-developers < ipm...@li...> wrote: > Hello ipmiutil Developers, > > I was able to compile ipmiutil for Windows ARM64 and use it on a few > systems we have. Would you be willing to upstream those changes? I can > provide a PR with the changes I made. > I compiled it with SSL 1.1 and Visual Studio 2017. > > Thanks > -Hozefa > > > > _______________________________________________ > ipmiutil-developers mailing list > ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers > |
|
From: Hozefa K. <Hoz...@mi...> - 2019-10-08 00:09:16
|
Hello ipmiutil Developers, I was able to compile ipmiutil for Windows ARM64 and use it on a few systems we have. Would you be willing to upstream those changes? I can provide a PR with the changes I made. I compiled it with SSL 1.1 and Visual Studio 2017. Thanks -Hozefa |
|
From: Andy C. <and...@gm...> - 2019-08-09 03:21:36
|
The ipmiutil-3.1.4 version has now been released which includes this fix. http://ipmiutil.sf.net On Wed, Jul 17, 2019 at 8:00 PM Andy Cress <and...@gm...> wrote: > Rob, > > Here is a hotfix version of ipmiutil which skips the GetSysInfo commands > for SuperMicro X11DPT-B > to avoid this bug with this version of SuperMicro firmware. > > http://ipmiutil.sourceforge.net/FILES/ipmiutil-314d.exe (amd64) > > Andy > > On Tue, Jul 16, 2019 at 5:48 PM Andy Cress <and...@gm...> wrote: > >> If this is SuperMicro firmware it could be another firmware failure. >> >> In fact, the previous symptom with ipmiutil fru was due to a SuperMicro >> firmware bug, causing the firmware to fail on SuperMicro X11DPT-B. I >> just realized that I didn't reply all, so I copied that email below. >> >> A firmware crash can happen on SuperMicro firmware (e.g. threshold >> exceeded and it cannot reconcile the fluctuations, or a few other bugs). >> If that happens, warm booting the firmware may be possible via 'ipmiuilt >> reset -k', but otherwise you will need to remove input power for 10 seconds >> to power up the firmware cleanly. >> >> Andy >> >> ---------- Forwarded message --------- >> From: Andy Cress <and...@gm...> >> Date: Thu, Jul 11, 2019 at 9:16 PM >> Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 >> To: Rob Scheepens <rob...@nu...> >> >> >> I see the problem. The firmware drops the session with a partially >> filled buffer when doing the get_system_info command. >> There are a few firmware vendors/versions (e.g. Sun) where this is not >> supported, and I need to add this one to set do_systeminfo = 0 and skip >> that function. >> >> devid: firmware ver 6.49, IPMI v02, vendor=10876 prod=2402. (= >> SuperMicro X11DPT-B) >> It should be supported in all IPMI v2.0, but apparently is not working in >> this case. >> I had tested this on a bunch of different SuperMicro motherboards. >> Sigh. SuperMicro isn't always consistent. Technically this is a >> firmware bug, but it could be several years before they fix it. >> >> Are there any other SuperMicro systems that see this problem? >> >> Andy >> >> On Mon, Jul 15, 2019 at 8:32 PM Abhijit Sunil Betigeri < >> abh...@nu...> wrote: >> >>> Have encountered issue where ipmiutil,.exe hangs and none of commands >>> work, this includes ipmicfg-win as well. >>> Attaching the system event log. >>> >>> >>> ipmiutil fru -x >>> >>> ipmiutil fru version 3.11 >>> >>> ipmi_open: driver type = >>> >>> ipmi_open_ia: imbdrv request error, ret=1 ccode=c0 >>> >>> ipmi_open_ms: ObjectPath: >>> Microsoft_IPMI.InstanceName="ACPI\\IPI0001\\0_0" >>> >>> ipmi_open rc = 0 type = ms >>> >>> Driver type ms, open rc = 0 >>> >>> ipmi_cmdraw_ms(cmd=1,netfn=6,lun=0,sa=20,sdata=0) RequestResponse ret=0 >>> >>> ipmi_cmdraw_ms: CompletionCode ff returned >>> >>> ipmi_cmdraw_ms: resp data(2): 00 00 >>> >>> ccode ff: Unspecified error >>> >>> ipmiutil fru, Unspecified error >>> >>> This implies to ipmi driver issue? isnt it? >>> >>> Regards, >>> >>> Abhijit >>> ------------------------------ >>> *From:* Rob Scheepens >>> *Sent:* Tuesday, July 9, 2019 11:35 PM >>> *To:* Andy Cress >>> *Cc:* ipm...@li...; Abhijit Sunil >>> Betigeri; Anupam Chakraborty; Naga Chandana >>> *Subject:* Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil >>> 3.13 >>> >>> >>> Using “ipmiutil fru -x” I get a 100% reproduction rate. The debug log of >>> one attempt is attached. All five attempts I did are the same: they stop at: >>> >>> ... >>> >>> get_sysinfo(1,2) j=2 len=15 >>> >>> ipmi_cmdraw_ms(cmd=59,netfn=6,lun=0,sa=20,sdata=4) RequestResponse ret=0 >>> >>> ipmi_cmdraw_ms: req data(4): 00 01 03 00 >>> >>> ipmi_cmdraw_ms: CompletionCode 80 returned >>> >>> ipmi_cmdraw_ms: resp data(2): 80 d0 >>> >>> ccode 80: Invalid Session Handle or Empty Buffer >>> >>> >>> >>> \Rob >>> >>> >>> >>> *From: *Andy Cress <and...@gm...> >>> *Date: *Wednesday, 10 July 2019 at 03:53 >>> *To: *Rob Scheepens <rob...@nu...> >>> *Cc: *"ipm...@li..." < >>> ipm...@li...>, Abhijit Sunil Betigeri < >>> abh...@nu...>, Anupam Chakraborty < >>> anu...@nu...>, Naga Chandana < >>> nag...@nu...> >>> *Subject: *Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil >>> 3.13 >>> >>> >>> >>> >>> >>> Sure the source is available. Here is the link for that version. >>> >>> http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.1.3.tar.gz >>> [sourceforge.net] >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sourceforge.net_projects_ipmiutil_files_ipmiutil-2D3.1.3.tar.gz&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=46h52Eb8jp-lu4UCCD6qH7HnvJnVOWctoQ20aQcztPQ&e=> >>> >>> >>> >>> >>> One other clue would be to run this command on the system where the >>> dumps occur: >>> >>> ipmiutil fru -x >>> >>> and send me the (debug) output. >>> >>> The output would show a good bit of where it fails, if it fails >>> frequently. >>> >>> >>> >>> Andy >>> >>> >>> >>> On Mon, Jul 8, 2019 at 7:04 AM Rob Scheepens <rob...@nu...> >>> wrote: >>> >>> Hi Andy, >>> >>> >>> >>> The commandline is “'"C:\Program >>> Files\sourceforge\ipmiutil\ipmiutil.exe" fru' “. Reproduction is fairly >>> reliable, see timestamps of the user dumps: >>> >>> >>> >>> 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip >>> >>> 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp >>> >>> 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp >>> >>> 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp >>> >>> 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp >>> >>> 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp >>> >>> 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp >>> >>> >>> >>> Instead of PDBs, can I get the source code somewhere and line it up in >>> WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA [we.tl] >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__we.tl_t-2DFGq9I8scLA&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=n89zN5bGfGYqXi2WHJ2X2TXmMQ2QiJashFzYCJx8lSs&e=>. >>> >>> >>> >>> >>> Iirc we recently switched from imbdrv to ipmidrv because of an issue. >>> @Abhijit: can you (dis)confirm? >>> >>> >>> >>> \Rob >>> >>> |
|
From: Andy C. <and...@gm...> - 2019-07-18 00:00:28
|
Rob, Here is a hotfix version of ipmiutil which skips the GetSysInfo commands for SuperMicro X11DPT-B to avoid this bug with this version of SuperMicro firmware. http://ipmiutil.sourceforge.net/FILES/ipmiutil-314d.exe (amd64) Andy On Tue, Jul 16, 2019 at 5:48 PM Andy Cress <and...@gm...> wrote: > If this is SuperMicro firmware it could be another firmware failure. > > In fact, the previous symptom with ipmiutil fru was due to a SuperMicro > firmware bug, causing the firmware to fail on SuperMicro X11DPT-B. I just > realized that I didn't reply all, so I copied that email below. > > A firmware crash can happen on SuperMicro firmware (e.g. threshold > exceeded and it cannot reconcile the fluctuations, or a few other bugs). > If that happens, warm booting the firmware may be possible via 'ipmiuilt > reset -k', but otherwise you will need to remove input power for 10 seconds > to power up the firmware cleanly. > > Andy > > ---------- Forwarded message --------- > From: Andy Cress <and...@gm...> > Date: Thu, Jul 11, 2019 at 9:16 PM > Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 > To: Rob Scheepens <rob...@nu...> > > > I see the problem. The firmware drops the session with a partially filled > buffer when doing the get_system_info command. > There are a few firmware vendors/versions (e.g. Sun) where this is not > supported, and I need to add this one to set do_systeminfo = 0 and skip > that function. > > devid: firmware ver 6.49, IPMI v02, vendor=10876 prod=2402. (= > SuperMicro X11DPT-B) > It should be supported in all IPMI v2.0, but apparently is not working in > this case. > I had tested this on a bunch of different SuperMicro motherboards. > Sigh. SuperMicro isn't always consistent. Technically this is a > firmware bug, but it could be several years before they fix it. > > Are there any other SuperMicro systems that see this problem? > > Andy > > On Mon, Jul 15, 2019 at 8:32 PM Abhijit Sunil Betigeri < > abh...@nu...> wrote: > >> Have encountered issue where ipmiutil,.exe hangs and none of commands >> work, this includes ipmicfg-win as well. >> Attaching the system event log. >> >> >> ipmiutil fru -x >> >> ipmiutil fru version 3.11 >> >> ipmi_open: driver type = >> >> ipmi_open_ia: imbdrv request error, ret=1 ccode=c0 >> >> ipmi_open_ms: ObjectPath: Microsoft_IPMI.InstanceName="ACPI\\IPI0001\\0_0" >> >> ipmi_open rc = 0 type = ms >> >> Driver type ms, open rc = 0 >> >> ipmi_cmdraw_ms(cmd=1,netfn=6,lun=0,sa=20,sdata=0) RequestResponse ret=0 >> >> ipmi_cmdraw_ms: CompletionCode ff returned >> >> ipmi_cmdraw_ms: resp data(2): 00 00 >> >> ccode ff: Unspecified error >> >> ipmiutil fru, Unspecified error >> >> This implies to ipmi driver issue? isnt it? >> >> Regards, >> >> Abhijit >> ------------------------------ >> *From:* Rob Scheepens >> *Sent:* Tuesday, July 9, 2019 11:35 PM >> *To:* Andy Cress >> *Cc:* ipm...@li...; Abhijit Sunil Betigeri; >> Anupam Chakraborty; Naga Chandana >> *Subject:* Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil >> 3.13 >> >> >> Using “ipmiutil fru -x” I get a 100% reproduction rate. The debug log of >> one attempt is attached. All five attempts I did are the same: they stop at: >> >> ... >> >> get_sysinfo(1,2) j=2 len=15 >> >> ipmi_cmdraw_ms(cmd=59,netfn=6,lun=0,sa=20,sdata=4) RequestResponse ret=0 >> >> ipmi_cmdraw_ms: req data(4): 00 01 03 00 >> >> ipmi_cmdraw_ms: CompletionCode 80 returned >> >> ipmi_cmdraw_ms: resp data(2): 80 d0 >> >> ccode 80: Invalid Session Handle or Empty Buffer >> >> >> >> \Rob >> >> >> >> *From: *Andy Cress <and...@gm...> >> *Date: *Wednesday, 10 July 2019 at 03:53 >> *To: *Rob Scheepens <rob...@nu...> >> *Cc: *"ipm...@li..." < >> ipm...@li...>, Abhijit Sunil Betigeri < >> abh...@nu...>, Anupam Chakraborty < >> anu...@nu...>, Naga Chandana <nag...@nu... >> > >> *Subject: *Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil >> 3.13 >> >> >> >> >> >> Sure the source is available. Here is the link for that version. >> >> http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.1.3.tar.gz >> [sourceforge.net] >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sourceforge.net_projects_ipmiutil_files_ipmiutil-2D3.1.3.tar.gz&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=46h52Eb8jp-lu4UCCD6qH7HnvJnVOWctoQ20aQcztPQ&e=> >> >> >> >> >> One other clue would be to run this command on the system where the dumps >> occur: >> >> ipmiutil fru -x >> >> and send me the (debug) output. >> >> The output would show a good bit of where it fails, if it fails >> frequently. >> >> >> >> Andy >> >> >> >> On Mon, Jul 8, 2019 at 7:04 AM Rob Scheepens <rob...@nu...> >> wrote: >> >> Hi Andy, >> >> >> >> The commandline is “'"C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe" >> fru' “. Reproduction is fairly reliable, see timestamps of the user dumps: >> >> >> >> 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip >> >> 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp >> >> 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp >> >> 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp >> >> 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp >> >> 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp >> >> 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp >> >> >> >> Instead of PDBs, can I get the source code somewhere and line it up in >> WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA [we.tl] >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__we.tl_t-2DFGq9I8scLA&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=n89zN5bGfGYqXi2WHJ2X2TXmMQ2QiJashFzYCJx8lSs&e=>. >> >> >> >> >> Iirc we recently switched from imbdrv to ipmidrv because of an issue. >> @Abhijit: can you (dis)confirm? >> >> >> >> \Rob >> >> |
|
From: Andy C. <and...@gm...> - 2019-07-16 21:48:44
|
If this is SuperMicro firmware it could be another firmware failure. In fact, the previous symptom with ipmiutil fru was due to a SuperMicro firmware bug, causing the firmware to fail on SuperMicro X11DPT-B. I just realized that I didn't reply all, so I copied that email below. A firmware crash can happen on SuperMicro firmware (e.g. threshold exceeded and it cannot reconcile the fluctuations, or a few other bugs). If that happens, warm booting the firmware may be possible via 'ipmiuilt reset -k', but otherwise you will need to remove input power for 10 seconds to power up the firmware cleanly. Andy ---------- Forwarded message --------- From: Andy Cress <and...@gm...> Date: Thu, Jul 11, 2019 at 9:16 PM Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 To: Rob Scheepens <rob...@nu...> I see the problem. The firmware drops the session with a partially filled buffer when doing the get_system_info command. There are a few firmware vendors/versions (e.g. Sun) where this is not supported, and I need to add this one to set do_systeminfo = 0 and skip that function. devid: firmware ver 6.49, IPMI v02, vendor=10876 prod=2402. (= SuperMicro X11DPT-B) It should be supported in all IPMI v2.0, but apparently is not working in this case. I had tested this on a bunch of different SuperMicro motherboards. Sigh. SuperMicro isn't always consistent. Technically this is a firmware bug, but it could be several years before they fix it. Are there any other SuperMicro systems that see this problem? Andy On Mon, Jul 15, 2019 at 8:32 PM Abhijit Sunil Betigeri < abh...@nu...> wrote: > Have encountered issue where ipmiutil,.exe hangs and none of commands > work, this includes ipmicfg-win as well. > Attaching the system event log. > > > ipmiutil fru -x > > ipmiutil fru version 3.11 > > ipmi_open: driver type = > > ipmi_open_ia: imbdrv request error, ret=1 ccode=c0 > > ipmi_open_ms: ObjectPath: Microsoft_IPMI.InstanceName="ACPI\\IPI0001\\0_0" > > ipmi_open rc = 0 type = ms > > Driver type ms, open rc = 0 > > ipmi_cmdraw_ms(cmd=1,netfn=6,lun=0,sa=20,sdata=0) RequestResponse ret=0 > > ipmi_cmdraw_ms: CompletionCode ff returned > > ipmi_cmdraw_ms: resp data(2): 00 00 > > ccode ff: Unspecified error > > ipmiutil fru, Unspecified error > > This implies to ipmi driver issue? isnt it? > > Regards, > > Abhijit > ------------------------------ > *From:* Rob Scheepens > *Sent:* Tuesday, July 9, 2019 11:35 PM > *To:* Andy Cress > *Cc:* ipm...@li...; Abhijit Sunil Betigeri; > Anupam Chakraborty; Naga Chandana > *Subject:* Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil > 3.13 > > > Using “ipmiutil fru -x” I get a 100% reproduction rate. The debug log of > one attempt is attached. All five attempts I did are the same: they stop at: > > ... > > get_sysinfo(1,2) j=2 len=15 > > ipmi_cmdraw_ms(cmd=59,netfn=6,lun=0,sa=20,sdata=4) RequestResponse ret=0 > > ipmi_cmdraw_ms: req data(4): 00 01 03 00 > > ipmi_cmdraw_ms: CompletionCode 80 returned > > ipmi_cmdraw_ms: resp data(2): 80 d0 > > ccode 80: Invalid Session Handle or Empty Buffer > > > > \Rob > > > > *From: *Andy Cress <and...@gm...> > *Date: *Wednesday, 10 July 2019 at 03:53 > *To: *Rob Scheepens <rob...@nu...> > *Cc: *"ipm...@li..." < > ipm...@li...>, Abhijit Sunil Betigeri < > abh...@nu...>, Anupam Chakraborty < > anu...@nu...>, Naga Chandana <nag...@nu...> > *Subject: *Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil > 3.13 > > > > > > Sure the source is available. Here is the link for that version. > > http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.1.3.tar.gz > [sourceforge.net] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__sourceforge.net_projects_ipmiutil_files_ipmiutil-2D3.1.3.tar.gz&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=46h52Eb8jp-lu4UCCD6qH7HnvJnVOWctoQ20aQcztPQ&e=> > > > > > One other clue would be to run this command on the system where the dumps > occur: > > ipmiutil fru -x > > and send me the (debug) output. > > The output would show a good bit of where it fails, if it fails > frequently. > > > > Andy > > > > On Mon, Jul 8, 2019 at 7:04 AM Rob Scheepens <rob...@nu...> > wrote: > > Hi Andy, > > > > The commandline is “'"C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe" > fru' “. Reproduction is fairly reliable, see timestamps of the user dumps: > > > > 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip > > 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp > > 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp > > 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp > > 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp > > 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp > > 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp > > > > Instead of PDBs, can I get the source code somewhere and line it up in > WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA [we.tl] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__we.tl_t-2DFGq9I8scLA&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=n89zN5bGfGYqXi2WHJ2X2TXmMQ2QiJashFzYCJx8lSs&e=>. > > > > > Iirc we recently switched from imbdrv to ipmidrv because of an issue. > @Abhijit: can you (dis)confirm? > > > > \Rob > > |
|
From: Rob S. <rob...@nu...> - 2019-07-10 06:35:31
|
Using “ipmiutil fru -x” I get a 100% reproduction rate. The debug log of one attempt is attached. All five attempts I did are the same: they stop at: ... get_sysinfo(1,2) j=2 len=15 ipmi_cmdraw_ms(cmd=59,netfn=6,lun=0,sa=20,sdata=4) RequestResponse ret=0 ipmi_cmdraw_ms: req data(4): 00 01 03 00 ipmi_cmdraw_ms: CompletionCode 80 returned ipmi_cmdraw_ms: resp data(2): 80 d0 ccode 80: Invalid Session Handle or Empty Buffer \Rob From: Andy Cress <and...@gm...> Date: Wednesday, 10 July 2019 at 03:53 To: Rob Scheepens <rob...@nu...> Cc: "ipm...@li..." <ipm...@li...>, Abhijit Sunil Betigeri <abh...@nu...>, Anupam Chakraborty <anu...@nu...>, Naga Chandana <nag...@nu...> Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 Sure the source is available. Here is the link for that version. http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.1.3.tar.gz [sourceforge.net]<https://urldefense.proofpoint.com/v2/url?u=http-3A__sourceforge.net_projects_ipmiutil_files_ipmiutil-2D3.1.3.tar.gz&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=46h52Eb8jp-lu4UCCD6qH7HnvJnVOWctoQ20aQcztPQ&e=> One other clue would be to run this command on the system where the dumps occur: ipmiutil fru -x and send me the (debug) output. The output would show a good bit of where it fails, if it fails frequently. Andy On Mon, Jul 8, 2019 at 7:04 AM Rob Scheepens <rob...@nu...<mailto:rob...@nu...>> wrote: Hi Andy, The commandline is “'"C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe" fru' “. Reproduction is fairly reliable, see timestamps of the user dumps: 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp Instead of PDBs, can I get the source code somewhere and line it up in WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA [we.tl]<https://urldefense.proofpoint.com/v2/url?u=https-3A__we.tl_t-2DFGq9I8scLA&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=DIsjsjlFIOJRbicayrSFqCCQVzTlqRjaQ04bd8WjicM&s=n89zN5bGfGYqXi2WHJ2X2TXmMQ2QiJashFzYCJx8lSs&e=>. Iirc we recently switched from imbdrv to ipmidrv because of an issue. @Abhijit: can you (dis)confirm? \Rob From: Andy Cress <and...@gm...<mailto:and...@gm...>> Date: Saturday, 6 July 2019 at 14:27 To: Rob Scheepens <rob...@nu...<mailto:rob...@nu...>> Cc: "ipm...@li...<mailto:ipm...@li...>" <ipm...@li...<mailto:ipm...@li...>>, Abhijit Sunil Betigeri <abh...@nu...<mailto:abh...@nu...>>, Anupam Chakraborty <anu...@nu...<mailto:anu...@nu...>>, Naga Chandana <nag...@nu...<mailto:nag...@nu...>> Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 Rob, Unfortunately, I haven't been saving the pdb files for each version. My first guess as to the cause would be the MS Wbem layer with IPMIDRV.SYS. It wouldn't be the first bug in that combination. It probably would not happen with the IMBDRV.SYS instead. However, we need to debug this further. First, can you tell me which ipmiutil function was being used when this occurred? Is it random, or is it reproducable? Andy On Fri, Jul 5, 2019 at 5:04 AM Rob Scheepens <rob...@nu...<mailto:rob...@nu...>> wrote: Hello All, Recently I encountered ipmiutil winx64 crashes on Windows Server 2019. I am yet to figure out what the trigger is, but after enabling application verifier I got the following stack: 0:000> !heap -p -a 0xd02fec0 address 000000000d02fec0 found in _DPH_HEAP_ROOT @ 1c01000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) bf67d68: d02fec0 140 - d02f000 2000 fastprox!CEnumProxyBuffer::`vftable' 00007ffc37f56cf7 ntdll!RtlDebugAllocateHeap+0x000000000000003f 00007ffc37efca9e ntdll!RtlpAllocateHeap+0x000000000009d23e 00007ffc37e5da21 ntdll!RtlpAllocateHeapInternal+0x0000000000000991 00007ffc1d98be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022 00007ffc189587c0 vfbasics!AVrfpRtlAllocateHeap+0x0000000000000130 00007ffc2787d3aa fastprox!CEnumFactoryBuffer::XEnumFactory::CreateProxy+0x000000000000007a 00007ffc36d9114f combase!CStdMarshal::CreateProxy+0x000000000000019f [onecore\com\combase\dcomrem\marshal.cxx @ 6551] 00007ffc36d93b69 combase!CStdMarshal::MakeCliIPIDEntry+0x0000000000000069 [onecore\com\combase\dcomrem\marshal.cxx @ 2840] 00007ffc36d944ea combase!CStdMarshal::UnmarshalIPID+0x000000000000007a [onecore\com\combase\dcomrem\marshal.cxx @ 2404] 00007ffc36d97500 combase!CStdMarshal::UnmarshalObjRef+0x0000000000000170 [onecore\com\combase\dcomrem\marshal.cxx @ 2272] 00007ffc36d8a7e3 combase!CoUnmarshalInterface+0x0000000000000483 [onecore\com\combase\dcomrem\coapi.cxx @ 1931] 00007ffc36deb563 combase!NdrExtInterfacePointerUnmarshall+0x00000000000001b3 [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1244] 00007ffc37553c54 rpcrt4!NdrPointerUnmarshall+0x0000000000000284 00007ffc37553cc6 rpcrt4!NdrPointerUnmarshall+0x00000000000002f6 00007ffc37558cb3 rpcrt4!NdrpClientUnMarshal+0x0000000000000433 00007ffc37511ea5 rpcrt4!NdrpClientCall2+0x0000000000000475 00007ffc36deaa87 combase!ObjectStublessClient+0x00000000000001d7 [onecore\com\combase\ndr\ndrole\amd64\stblsclt.cxx @ 368] 00007ffc36e5c7b2 combase!ObjectStubless+0x0000000000000042 [onecore\com\combase\ndr\ndrole\amd64\stubless.asm @ 176] 00007ffc27876171 fastprox!CWbemSvcWrapper::XWbemServices::CreateInstanceEnum+0x0000000000000091 0000000140061ae1 ipmiutil+0x0000000000061ae1 00000001400621b1 ipmiutil+0x00000000000621b1 000000014000b9ee ipmiutil+0x000000000000b9ee 0000000140001144 ipmiutil+0x0000000000001144 000000014006f40b ipmiutil+0x000000000006f40b 00007ffc35217974 kernel32!BaseThreadInitThunk+0x0000000000000014 00007ffc37eba271 ntdll!RtlUserThreadStart+0x0000000000000021 Image info: Loaded symbol image file: ipmiutil.exe Image path: C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe Image name: ipmiutil.exe Browse all global symbols functions data Timestamp: Thu Sep 13 09:43:24 2018 (5B9A93AC) CheckSum: 00000000 ImageSize: 00156000 Are there (private) PDB files available for this version of ipmiutil? \Rob _______________________________________________ ipmiutil-developers mailing list ipm...@li...<mailto:ipm...@li...> https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers [lists.sourceforge.net]<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ipmiutil-2Ddevelopers&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=0uA8_RO-wJLFP7eq8M8A0oBuHRUvGSaTJhQ21-gXp8o&s=25IBWbV6u_-JYOLfV01hQa-o1e_XdBnKNKqRW-_PNoM&e=> |
|
From: Andy C. <and...@gm...> - 2019-07-10 01:53:15
|
Sure the source is available. Here is the link for that version. http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.1.3.tar.gz One other clue would be to run this command on the system where the dumps occur: ipmiutil fru -x and send me the (debug) output. The output would show a good bit of where it fails, if it fails frequently. Andy On Mon, Jul 8, 2019 at 7:04 AM Rob Scheepens <rob...@nu...> wrote: > Hi Andy, > > > > The commandline is “'"C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe" > fru' “. Reproduction is fairly reliable, see timestamps of the user dumps: > > > > 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip > > 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp > > 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp > > 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp > > 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp > > 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp > > 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp > > > > Instead of PDBs, can I get the source code somewhere and line it up in > WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA. > > > > Iirc we recently switched from imbdrv to ipmidrv because of an issue. > @Abhijit: can you (dis)confirm? > > > > \Rob > > > > *From: *Andy Cress <and...@gm...> > *Date: *Saturday, 6 July 2019 at 14:27 > *To: *Rob Scheepens <rob...@nu...> > *Cc: *"ipm...@li..." < > ipm...@li...>, Abhijit Sunil Betigeri < > abh...@nu...>, Anupam Chakraborty < > anu...@nu...>, Naga Chandana <nag...@nu...> > *Subject: *Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil > 3.13 > > > > Rob, > > > > Unfortunately, I haven't been saving the pdb files for each version. > > My first guess as to the cause would be the MS Wbem layer with > IPMIDRV.SYS. It wouldn't be the first bug in that combination. > > It probably would not happen with the IMBDRV.SYS instead. > > > > However, we need to debug this further. > > First, can you tell me which ipmiutil function was being used when this > occurred? > > Is it random, or is it reproducable? > > > > Andy > > > > > > On Fri, Jul 5, 2019 at 5:04 AM Rob Scheepens <rob...@nu...> > wrote: > > Hello All, > > Recently I encountered ipmiutil winx64 crashes on Windows Server 2019. I > am yet to figure out what the trigger is, but after enabling application > verifier I got the following stack: > > 0:000> !heap -p -a 0xd02fec0 > address 000000000d02fec0 found in > _DPH_HEAP_ROOT @ 1c01000 > in busy allocation ( DPH_HEAP_BLOCK: UserAddr > UserSize - VirtAddr VirtSize) > bf67d68: d02fec0 > 140 - d02f000 2000 > fastprox!CEnumProxyBuffer::`vftable' > 00007ffc37f56cf7 ntdll!RtlDebugAllocateHeap+0x000000000000003f > 00007ffc37efca9e ntdll!RtlpAllocateHeap+0x000000000009d23e > 00007ffc37e5da21 ntdll!RtlpAllocateHeapInternal+0x0000000000000991 > 00007ffc1d98be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022 > 00007ffc189587c0 vfbasics!AVrfpRtlAllocateHeap+0x0000000000000130 > 00007ffc2787d3aa > fastprox!CEnumFactoryBuffer::XEnumFactory::CreateProxy+0x000000000000007a > 00007ffc36d9114f combase!CStdMarshal::CreateProxy+0x000000000000019f > [onecore\com\combase\dcomrem\marshal.cxx @ 6551] > 00007ffc36d93b69 > combase!CStdMarshal::MakeCliIPIDEntry+0x0000000000000069 > [onecore\com\combase\dcomrem\marshal.cxx @ 2840] > 00007ffc36d944ea combase!CStdMarshal::UnmarshalIPID+0x000000000000007a > [onecore\com\combase\dcomrem\marshal.cxx @ 2404] > 00007ffc36d97500 > combase!CStdMarshal::UnmarshalObjRef+0x0000000000000170 > [onecore\com\combase\dcomrem\marshal.cxx @ 2272] > 00007ffc36d8a7e3 combase!CoUnmarshalInterface+0x0000000000000483 > [onecore\com\combase\dcomrem\coapi.cxx @ 1931] > 00007ffc36deb563 > combase!NdrExtInterfacePointerUnmarshall+0x00000000000001b3 > [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1244] > 00007ffc37553c54 rpcrt4!NdrPointerUnmarshall+0x0000000000000284 > 00007ffc37553cc6 rpcrt4!NdrPointerUnmarshall+0x00000000000002f6 > 00007ffc37558cb3 rpcrt4!NdrpClientUnMarshal+0x0000000000000433 > 00007ffc37511ea5 rpcrt4!NdrpClientCall2+0x0000000000000475 > 00007ffc36deaa87 combase!ObjectStublessClient+0x00000000000001d7 > [onecore\com\combase\ndr\ndrole\amd64\stblsclt.cxx @ 368] > 00007ffc36e5c7b2 combase!ObjectStubless+0x0000000000000042 > [onecore\com\combase\ndr\ndrole\amd64\stubless.asm @ 176] > 00007ffc27876171 > fastprox!CWbemSvcWrapper::XWbemServices::CreateInstanceEnum+0x0000000000000091 > 0000000140061ae1 ipmiutil+0x0000000000061ae1 > 00000001400621b1 ipmiutil+0x00000000000621b1 > 000000014000b9ee ipmiutil+0x000000000000b9ee > 0000000140001144 ipmiutil+0x0000000000001144 > 000000014006f40b ipmiutil+0x000000000006f40b > 00007ffc35217974 kernel32!BaseThreadInitThunk+0x0000000000000014 > 00007ffc37eba271 ntdll!RtlUserThreadStart+0x0000000000000021 > > Image info: > > Loaded symbol image file: ipmiutil.exe > Image path: C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe > Image name: ipmiutil.exe > Browse all global symbols functions data > Timestamp: Thu Sep 13 09:43:24 2018 (5B9A93AC) > CheckSum: 00000000 > ImageSize: 00156000 > > Are there (private) PDB files available for this version of ipmiutil? > > \Rob > > _______________________________________________ > ipmiutil-developers mailing list > ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers > [lists.sourceforge.net] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ipmiutil-2Ddevelopers&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=0uA8_RO-wJLFP7eq8M8A0oBuHRUvGSaTJhQ21-gXp8o&s=25IBWbV6u_-JYOLfV01hQa-o1e_XdBnKNKqRW-_PNoM&e=> > > |
|
From: Rob S. <rob...@nu...> - 2019-07-08 11:33:03
|
Hi Andy, The commandline is “'"C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe" fru' “. Reproduction is fairly reliable, see timestamps of the user dumps: 07/05/2019 12:38 AM 24,044,684 ipmiutil.exe-dumps.zip 07/08/2019 01:55 AM 65,382,554 ipmiutil.exe.10568.dmp 07/07/2019 11:55 PM 65,374,160 ipmiutil.exe.11612.dmp 07/07/2019 10:56 PM 65,370,628 ipmiutil.exe.13348.dmp 07/08/2019 02:56 AM 65,386,532 ipmiutil.exe.14328.dmp 07/08/2019 12:55 AM 65,378,874 ipmiutil.exe.15160.dmp 07/08/2019 01:57 AM 65,408,636 ipmiutil.exe.9272.dmp Instead of PDBs, can I get the source code somewhere and line it up in WinDbg? I’ve uploaded two dumps to https://we.tl/t-FGq9I8scLA. Iirc we recently switched from imbdrv to ipmidrv because of an issue. @Abhijit: can you (dis)confirm? \Rob From: Andy Cress <and...@gm...> Date: Saturday, 6 July 2019 at 14:27 To: Rob Scheepens <rob...@nu...> Cc: "ipm...@li..." <ipm...@li...>, Abhijit Sunil Betigeri <abh...@nu...>, Anupam Chakraborty <anu...@nu...>, Naga Chandana <nag...@nu...> Subject: Re: [ipmiutil-developers] Win64: heap leak crashing ipmiutil 3.13 Rob, Unfortunately, I haven't been saving the pdb files for each version. My first guess as to the cause would be the MS Wbem layer with IPMIDRV.SYS. It wouldn't be the first bug in that combination. It probably would not happen with the IMBDRV.SYS instead. However, we need to debug this further. First, can you tell me which ipmiutil function was being used when this occurred? Is it random, or is it reproducable? Andy On Fri, Jul 5, 2019 at 5:04 AM Rob Scheepens <rob...@nu...<mailto:rob...@nu...>> wrote: Hello All, Recently I encountered ipmiutil winx64 crashes on Windows Server 2019. I am yet to figure out what the trigger is, but after enabling application verifier I got the following stack: 0:000> !heap -p -a 0xd02fec0 address 000000000d02fec0 found in _DPH_HEAP_ROOT @ 1c01000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) bf67d68: d02fec0 140 - d02f000 2000 fastprox!CEnumProxyBuffer::`vftable' 00007ffc37f56cf7 ntdll!RtlDebugAllocateHeap+0x000000000000003f 00007ffc37efca9e ntdll!RtlpAllocateHeap+0x000000000009d23e 00007ffc37e5da21 ntdll!RtlpAllocateHeapInternal+0x0000000000000991 00007ffc1d98be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022 00007ffc189587c0 vfbasics!AVrfpRtlAllocateHeap+0x0000000000000130 00007ffc2787d3aa fastprox!CEnumFactoryBuffer::XEnumFactory::CreateProxy+0x000000000000007a 00007ffc36d9114f combase!CStdMarshal::CreateProxy+0x000000000000019f [onecore\com\combase\dcomrem\marshal.cxx @ 6551] 00007ffc36d93b69 combase!CStdMarshal::MakeCliIPIDEntry+0x0000000000000069 [onecore\com\combase\dcomrem\marshal.cxx @ 2840] 00007ffc36d944ea combase!CStdMarshal::UnmarshalIPID+0x000000000000007a [onecore\com\combase\dcomrem\marshal.cxx @ 2404] 00007ffc36d97500 combase!CStdMarshal::UnmarshalObjRef+0x0000000000000170 [onecore\com\combase\dcomrem\marshal.cxx @ 2272] 00007ffc36d8a7e3 combase!CoUnmarshalInterface+0x0000000000000483 [onecore\com\combase\dcomrem\coapi.cxx @ 1931] 00007ffc36deb563 combase!NdrExtInterfacePointerUnmarshall+0x00000000000001b3 [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1244] 00007ffc37553c54 rpcrt4!NdrPointerUnmarshall+0x0000000000000284 00007ffc37553cc6 rpcrt4!NdrPointerUnmarshall+0x00000000000002f6 00007ffc37558cb3 rpcrt4!NdrpClientUnMarshal+0x0000000000000433 00007ffc37511ea5 rpcrt4!NdrpClientCall2+0x0000000000000475 00007ffc36deaa87 combase!ObjectStublessClient+0x00000000000001d7 [onecore\com\combase\ndr\ndrole\amd64\stblsclt.cxx @ 368] 00007ffc36e5c7b2 combase!ObjectStubless+0x0000000000000042 [onecore\com\combase\ndr\ndrole\amd64\stubless.asm @ 176] 00007ffc27876171 fastprox!CWbemSvcWrapper::XWbemServices::CreateInstanceEnum+0x0000000000000091 0000000140061ae1 ipmiutil+0x0000000000061ae1 00000001400621b1 ipmiutil+0x00000000000621b1 000000014000b9ee ipmiutil+0x000000000000b9ee 0000000140001144 ipmiutil+0x0000000000001144 000000014006f40b ipmiutil+0x000000000006f40b 00007ffc35217974 kernel32!BaseThreadInitThunk+0x0000000000000014 00007ffc37eba271 ntdll!RtlUserThreadStart+0x0000000000000021 Image info: Loaded symbol image file: ipmiutil.exe Image path: C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe Image name: ipmiutil.exe Browse all global symbols functions data Timestamp: Thu Sep 13 09:43:24 2018 (5B9A93AC) CheckSum: 00000000 ImageSize: 00156000 Are there (private) PDB files available for this version of ipmiutil? \Rob _______________________________________________ ipmiutil-developers mailing list ipm...@li...<mailto:ipm...@li...> https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers [lists.sourceforge.net]<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_ipmiutil-2Ddevelopers&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=0uA8_RO-wJLFP7eq8M8A0oBuHRUvGSaTJhQ21-gXp8o&s=25IBWbV6u_-JYOLfV01hQa-o1e_XdBnKNKqRW-_PNoM&e=> |
|
From: Andy C. <and...@gm...> - 2019-07-06 12:27:06
|
Rob, Unfortunately, I haven't been saving the pdb files for each version. My first guess as to the cause would be the MS Wbem layer with IPMIDRV.SYS. It wouldn't be the first bug in that combination. It probably would not happen with the IMBDRV.SYS instead. However, we need to debug this further. First, can you tell me which ipmiutil function was being used when this occurred? Is it random, or is it reproducable? Andy On Fri, Jul 5, 2019 at 5:04 AM Rob Scheepens <rob...@nu...> wrote: > Hello All, > > Recently I encountered ipmiutil winx64 crashes on Windows Server 2019. I > am yet to figure out what the trigger is, but after enabling application > verifier I got the following stack: > > 0:000> !heap -p -a 0xd02fec0 > address 000000000d02fec0 found in > _DPH_HEAP_ROOT @ 1c01000 > in busy allocation ( DPH_HEAP_BLOCK: UserAddr > UserSize - VirtAddr VirtSize) > bf67d68: d02fec0 > 140 - d02f000 2000 > fastprox!CEnumProxyBuffer::`vftable' > 00007ffc37f56cf7 ntdll!RtlDebugAllocateHeap+0x000000000000003f > 00007ffc37efca9e ntdll!RtlpAllocateHeap+0x000000000009d23e > 00007ffc37e5da21 ntdll!RtlpAllocateHeapInternal+0x0000000000000991 > 00007ffc1d98be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022 > 00007ffc189587c0 vfbasics!AVrfpRtlAllocateHeap+0x0000000000000130 > 00007ffc2787d3aa > fastprox!CEnumFactoryBuffer::XEnumFactory::CreateProxy+0x000000000000007a > 00007ffc36d9114f combase!CStdMarshal::CreateProxy+0x000000000000019f > [onecore\com\combase\dcomrem\marshal.cxx @ 6551] > 00007ffc36d93b69 > combase!CStdMarshal::MakeCliIPIDEntry+0x0000000000000069 > [onecore\com\combase\dcomrem\marshal.cxx @ 2840] > 00007ffc36d944ea combase!CStdMarshal::UnmarshalIPID+0x000000000000007a > [onecore\com\combase\dcomrem\marshal.cxx @ 2404] > 00007ffc36d97500 > combase!CStdMarshal::UnmarshalObjRef+0x0000000000000170 > [onecore\com\combase\dcomrem\marshal.cxx @ 2272] > 00007ffc36d8a7e3 combase!CoUnmarshalInterface+0x0000000000000483 > [onecore\com\combase\dcomrem\coapi.cxx @ 1931] > 00007ffc36deb563 > combase!NdrExtInterfacePointerUnmarshall+0x00000000000001b3 > [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1244] > 00007ffc37553c54 rpcrt4!NdrPointerUnmarshall+0x0000000000000284 > 00007ffc37553cc6 rpcrt4!NdrPointerUnmarshall+0x00000000000002f6 > 00007ffc37558cb3 rpcrt4!NdrpClientUnMarshal+0x0000000000000433 > 00007ffc37511ea5 rpcrt4!NdrpClientCall2+0x0000000000000475 > 00007ffc36deaa87 combase!ObjectStublessClient+0x00000000000001d7 > [onecore\com\combase\ndr\ndrole\amd64\stblsclt.cxx @ 368] > 00007ffc36e5c7b2 combase!ObjectStubless+0x0000000000000042 > [onecore\com\combase\ndr\ndrole\amd64\stubless.asm @ 176] > 00007ffc27876171 > fastprox!CWbemSvcWrapper::XWbemServices::CreateInstanceEnum+0x0000000000000091 > 0000000140061ae1 ipmiutil+0x0000000000061ae1 > 00000001400621b1 ipmiutil+0x00000000000621b1 > 000000014000b9ee ipmiutil+0x000000000000b9ee > 0000000140001144 ipmiutil+0x0000000000001144 > 000000014006f40b ipmiutil+0x000000000006f40b > 00007ffc35217974 kernel32!BaseThreadInitThunk+0x0000000000000014 > 00007ffc37eba271 ntdll!RtlUserThreadStart+0x0000000000000021 > > Image info: > > Loaded symbol image file: ipmiutil.exe > Image path: C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe > Image name: ipmiutil.exe > Browse all global symbols functions data > Timestamp: Thu Sep 13 09:43:24 2018 (5B9A93AC) > CheckSum: 00000000 > ImageSize: 00156000 > > Are there (private) PDB files available for this version of ipmiutil? > > \Rob > > _______________________________________________ > ipmiutil-developers mailing list > ipm...@li... > https://lists.sourceforge.net/lists/listinfo/ipmiutil-developers > |
|
From: Rob S. <rob...@nu...> - 2019-07-05 09:03:54
|
Hello All,
Recently I encountered ipmiutil winx64 crashes on Windows Server 2019. I am yet to figure out what the trigger is, but after enabling application verifier I got the following stack:
0:000> !heap -p -a 0xd02fec0
address 000000000d02fec0 found in
_DPH_HEAP_ROOT @ 1c01000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
bf67d68: d02fec0 140 - d02f000 2000
fastprox!CEnumProxyBuffer::`vftable'
00007ffc37f56cf7 ntdll!RtlDebugAllocateHeap+0x000000000000003f
00007ffc37efca9e ntdll!RtlpAllocateHeap+0x000000000009d23e
00007ffc37e5da21 ntdll!RtlpAllocateHeapInternal+0x0000000000000991
00007ffc1d98be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022
00007ffc189587c0 vfbasics!AVrfpRtlAllocateHeap+0x0000000000000130
00007ffc2787d3aa fastprox!CEnumFactoryBuffer::XEnumFactory::CreateProxy+0x000000000000007a
00007ffc36d9114f combase!CStdMarshal::CreateProxy+0x000000000000019f [onecore\com\combase\dcomrem\marshal.cxx @ 6551]
00007ffc36d93b69 combase!CStdMarshal::MakeCliIPIDEntry+0x0000000000000069 [onecore\com\combase\dcomrem\marshal.cxx @ 2840]
00007ffc36d944ea combase!CStdMarshal::UnmarshalIPID+0x000000000000007a [onecore\com\combase\dcomrem\marshal.cxx @ 2404]
00007ffc36d97500 combase!CStdMarshal::UnmarshalObjRef+0x0000000000000170 [onecore\com\combase\dcomrem\marshal.cxx @ 2272]
00007ffc36d8a7e3 combase!CoUnmarshalInterface+0x0000000000000483 [onecore\com\combase\dcomrem\coapi.cxx @ 1931]
00007ffc36deb563 combase!NdrExtInterfacePointerUnmarshall+0x00000000000001b3 [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1244]
00007ffc37553c54 rpcrt4!NdrPointerUnmarshall+0x0000000000000284
00007ffc37553cc6 rpcrt4!NdrPointerUnmarshall+0x00000000000002f6
00007ffc37558cb3 rpcrt4!NdrpClientUnMarshal+0x0000000000000433
00007ffc37511ea5 rpcrt4!NdrpClientCall2+0x0000000000000475
00007ffc36deaa87 combase!ObjectStublessClient+0x00000000000001d7 [onecore\com\combase\ndr\ndrole\amd64\stblsclt.cxx @ 368]
00007ffc36e5c7b2 combase!ObjectStubless+0x0000000000000042 [onecore\com\combase\ndr\ndrole\amd64\stubless.asm @ 176]
00007ffc27876171 fastprox!CWbemSvcWrapper::XWbemServices::CreateInstanceEnum+0x0000000000000091
0000000140061ae1 ipmiutil+0x0000000000061ae1
00000001400621b1 ipmiutil+0x00000000000621b1
000000014000b9ee ipmiutil+0x000000000000b9ee
0000000140001144 ipmiutil+0x0000000000001144
000000014006f40b ipmiutil+0x000000000006f40b
00007ffc35217974 kernel32!BaseThreadInitThunk+0x0000000000000014
00007ffc37eba271 ntdll!RtlUserThreadStart+0x0000000000000021
Image info:
Loaded symbol image file: ipmiutil.exe
Image path: C:\Program Files\sourceforge\ipmiutil\ipmiutil.exe
Image name: ipmiutil.exe
Browse all global symbols functions data
Timestamp: Thu Sep 13 09:43:24 2018 (5B9A93AC)
CheckSum: 00000000
ImageSize: 00156000
Are there (private) PDB files available for this version of ipmiutil?
\Rob
|
|
From: Andy C. <and...@gm...> - 2018-09-14 16:11:40
|
The ipmiutil-3.1.3 release has been posted to sourceforge. See http://ipmiutil.sf.net for binaries and documentation. Changes: 09/13/2018 ARCress ipmiutil-3.1.3 changes (iver 3.13) util/oem_hp.c - handle analog readings in HP discrete Fan sensors (SF_Feat#9) |
|
From: Chetan G. <che...@hi...> - 2018-08-04 05:17:28
|
Thanks Andy for your response. Below command resolved my issue # Enable tty1Port to IPMI-SOL COM2 esxcli system settings kernel set -s tty1Port -v com2 Once that runs, reboot ESXi and voila. The console is up Thanks, -Chetan From: Andy Cress <and...@gm...> Sent: Friday, August 03, 2018 9:35 PM To: ipmiutil-developers <ipm...@li...> Cc: Chetan Gabhane <che...@hi...> Subject: RE: Regarding IPMI SOL Activate issues Since the only change was the installing the esxi media kit image, something in that reinstall has broken the IPMI SOL configuration, probably disabling the bootloader/OS part of the serial console. There are several parts to the IPMI SOL configuration, as described in the ipmiutil UserGuide, section 4.8 (link http://ipmiutil.sourceforge.net/docs/UserGuide<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipmiutil.sourceforge.net%2Fdocs%2FUserGuide&data=01%7C01%7Cchetan.gabhane%40hitachivantara.com%7Cea3648a33e964e91da1308d5f95ad8dd%7C18791e1761594f52a8d4de814ca8284a%7C0&sdata=AfLUhHfzLaLFYzPwxosge2XveRPjLDzgoUx9eQI8JQA%3D&reserved=0>) BIOS Setup for serial console IPMI configuration for serial console (see the 'ipmiutil lan' configuration command) Bootloader serial configuration (e.g. grub if Linux) OS serial console (e.g. Linux agetty in inittab) Note that the serial Baud rate for each of these must match. The Bootloader and OS serial console settings for VMware ESXi would be questions for VMware. Andy From: Chetan Gabhane <che...@hi...<mailto:che...@hi...>> To: "ipm...@li...<mailto:ipm...@li...>" <ipm...@li...<mailto:ipm...@li...>> Cc: Bcc: Date: Fri, 3 Aug 2018 15:21:57 +0000 Subject: RE: Regarding IPMI SOL Activate hangs Hi ipmiutil dev team, Could you please help me with below issue for IPMI. Thanks! Thanks, -Chetan From: Chetan Gabhane Sent: Friday, August 03, 2018 8:32 PM To: Francis Hong <fra...@hi...<mailto:fra...@hi...>> Cc: Jose Perez <jos...@hi...<mailto:jos...@hi...>>; Utkarsh Wagh <utk...@hi...<mailto:utk...@hi...>>; Vikram Chandel <vik...@hi...<mailto:vik...@hi...>> Subject: Regarding IPMI SOL Activate hangs Hi Francis, We are trying to run sol activate command with IPMI which hangs with below message and wont display esxi console: [removed graphic] Troubleshooting we tried : 1. We tried enabling and disabling the SOL ENABLE option in BMC UI “SOL Setting” 2. We tried resetting/rebooting server 3. Tried enable/disable from BIOS 4. Checked on open forum blogs; the issue has been posted with no resolution All above option couldn’t help to get esxi console. However it was working fine before. The only change made by us is we reinstalled esxi media kit image [UCPHC_Installer_vSphere6.5U1_7388607_VUM_03292018.iso ] and enabled SSH and Shell. We reinstalled esxi image as evaluation expired for both host-64 and host-65 Before esxi instanllation sol activate was working fine. Do we need to change any other setting ? or need to use another media kit ? Please let us know if you might seen this issue any time before or workaround if you know. Adding Jose; just in case he might seen this issue. Thanks! [other grapics removed] |
|
From: Andy C. <and...@gm...> - 2018-08-03 16:04:59
|
Since the only change was the installing the esxi media kit image, something in that reinstall has broken the IPMI SOL configuration, probably disabling the bootloader/OS part of the serial console. There are several parts to the IPMI SOL configuration, as described in the ipmiutil UserGuide, section 4.8 (link http://ipmiutil.sourceforge.net/docs/UserGuide) BIOS Setup for serial console IPMI configuration for serial console (see the 'ipmiutil lan' configuration command) Bootloader serial configuration (e.g. grub if Linux) OS serial console (e.g. Linux agetty in inittab) Note that the serial Baud rate for each of these must match. The Bootloader and OS serial console settings for VMware ESXi would be questions for VMware. Andy From: Chetan Gabhane <che...@hi...> To: "ipm...@li..." < ipm...@li...> Cc: Bcc: Date: Fri, 3 Aug 2018 15:21:57 +0000 Subject: RE: Regarding IPMI SOL Activate hangs Hi ipmiutil dev team, Could you please help me with below issue for IPMI. Thanks! Thanks, *-Chetan* *From:* Chetan Gabhane *Sent:* Friday, August 03, 2018 8:32 PM *To:* Francis Hong <fra...@hi...> *Cc:* Jose Perez <jos...@hi...>; Utkarsh Wagh < utk...@hi...>; Vikram Chandel <vikram.chandel@ hitachivantara.com> *Subject:* Regarding IPMI SOL Activate hangs Hi Francis, We are trying to run sol activate command with IPMI which hangs with below message and wont display esxi console: [removed graphic] Troubleshooting we tried : 1. We tried enabling and disabling the SOL ENABLE option in BMC UI “SOL Setting” 2. We tried resetting/rebooting server 3. Tried enable/disable from BIOS 4. Checked on open forum blogs; the issue has been posted with no resolution All above option couldn’t help to get esxi console. However it was working fine before. The only change made by us is we reinstalled esxi media kit image [UCPHC_Installer_vSphere6.5U1_7388607_VUM_03292018.iso ] and enabled SSH and Shell. We reinstalled esxi image as evaluation expired for both host-64 and host-65 Before esxi instanllation sol activate was working fine. Do we need to change any other setting ? or need to use another media kit ? Please let us know if you might seen this issue any time before or workaround if you know. Adding Jose; just in case he might seen this issue. Thanks! [other grapics removed] |
33 messages has been excluded from this view by a project administrator.