| Message ID | 20171026031317.15969-1-sam@mendozajonas.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | discover/platform-powerpc: Increase IPMI timeout | expand |
On Thu, 2017-10-26 at 14:13 +1100, Samuel Mendoza-Jonas wrote: > On OpenBMC platforms IPMI requests can take over five seconds to > complete. OpenBMC does inform OPAL in BT init that it may take up to > ten seconds to respond to any requests, so update our timeout value to > accommodate this extra delay. > > On other platforms this will won't change anything (AMI- and SMC- based > BMCs for example respond in under a second), but on OpenBMC platforms > such as Witherspoon this will delay Petitboot significantly while we > wait for the response. This is not ideal but we need to wait in order to > receive important information such as a safe mode request. > Reviewed-by: Cyril Bur <cyrilbur@gmail.com> > Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> > --- > discover/platform-powerpc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/discover/platform-powerpc.c b/discover/platform-powerpc.c > index 02d9a20..ed5733e 100644 > --- a/discover/platform-powerpc.c > +++ b/discover/platform-powerpc.c > @@ -25,7 +25,7 @@ > static const char *partition = "common"; > static const char *sysparams_dir = "/sys/firmware/opal/sysparams/"; > static const char *devtree_dir = "/proc/device-tree/"; > -static const int ipmi_timeout = 5000; /* milliseconds. */ > +static const int ipmi_timeout = 10000; /* milliseconds. */ > > struct param { > char *name;
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > On OpenBMC platforms IPMI requests can take over five seconds to > complete. OpenBMC does inform OPAL in BT init that it may take up to > ten seconds to respond to any requests, so update our timeout value to > accommodate this extra delay. Arguably, OpenBMC should fix their code to respond in a sane timeframe. Not arguably actually, they should do that full stop. do we have a bug open on that for them? > On other platforms this will won't change anything (AMI- and SMC- based > BMCs for example respond in under a second), but on OpenBMC platforms > such as Witherspoon this will delay Petitboot significantly while we > wait for the response. This is not ideal but we need to wait in order to > receive important information such as a safe mode request. Hrm... should we/do we expose this in any way to userspace? Also wondering if we should log somewhere how long all of these things took... if it's >5 seconds now, that's... as long as it takes to boot to petitboot from starting the kernel.
On Thu, 2017-10-26 at 19:15 -0700, Stewart Smith wrote: > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > > On OpenBMC platforms IPMI requests can take over five seconds to > > complete. OpenBMC does inform OPAL in BT init that it may take up to > > ten seconds to respond to any requests, so update our timeout value to > > accommodate this extra delay. > > Arguably, OpenBMC should fix their code to respond in a sane timeframe. > > Not arguably actually, they should do that full stop. do we have a bug > open on that for them? Absolutely. I was tempted to really press on OpenBMC to just fix it, but as it stands we have systems that are incapable of entering safe mode among other things, so here we are. I've opened an issue to work out what on earth is happening here: https://github.com/openbmc/openbmc/issues/2519 > > > On other platforms this will won't change anything (AMI- and SMC- based > > BMCs for example respond in under a second), but on OpenBMC platforms > > such as Witherspoon this will delay Petitboot significantly while we > > wait for the response. This is not ideal but we need to wait in order to > > receive important information such as a safe mode request. > > Hrm... should we/do we expose this in any way to userspace? This is a good idea. > > Also wondering if we should log somewhere how long all of these things > took... if it's >5 seconds now, that's... as long as it takes to boot to > petitboot from starting the kernel. > Agreed, I'll add some logging at the minimum to say "wondering why Petitboot look 30 seconds to come up? See https://github.com/openbmc/open bmc/issues/2519". It's probably a good idea to make these IPMI calls asynchronous anyway, it was just never an issue before :) Sam
diff --git a/discover/platform-powerpc.c b/discover/platform-powerpc.c index 02d9a20..ed5733e 100644 --- a/discover/platform-powerpc.c +++ b/discover/platform-powerpc.c @@ -25,7 +25,7 @@ static const char *partition = "common"; static const char *sysparams_dir = "/sys/firmware/opal/sysparams/"; static const char *devtree_dir = "/proc/device-tree/"; -static const int ipmi_timeout = 5000; /* milliseconds. */ +static const int ipmi_timeout = 10000; /* milliseconds. */ struct param { char *name;
On OpenBMC platforms IPMI requests can take over five seconds to complete. OpenBMC does inform OPAL in BT init that it may take up to ten seconds to respond to any requests, so update our timeout value to accommodate this extra delay. On other platforms this will won't change anything (AMI- and SMC- based BMCs for example respond in under a second), but on OpenBMC platforms such as Witherspoon this will delay Petitboot significantly while we wait for the response. This is not ideal but we need to wait in order to receive important information such as a safe mode request. Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> --- discover/platform-powerpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)