summaryrefslogtreecommitdiffstats
path: root/core/timebase.c
diff options
context:
space:
mode:
authorStewart Smith <stewart@linux.ibm.com>2018-10-30 00:34:23 -0500
committerStewart Smith <stewart@linux.ibm.com>2018-10-31 15:15:51 +1100
commitd10862e40cd8ef36fe49b298f3c615ac73dd3c4e (patch)
tree69991e1919815e5a7092915223b5809dc926f470 /core/timebase.c
parent8d58ee17ea20d43db5bb47b1533bc5faf396b46a (diff)
downloadblackbird-skiboot-d10862e40cd8ef36fe49b298f3c615ac73dd3c4e.tar.gz
blackbird-skiboot-d10862e40cd8ef36fe49b298f3c615ac73dd3c4e.zip
Run pollers in time_wait() when not booting
This only bit us hard with hiomap in one scenario. Our OPAL API has been OPAL_POLL_EVENTS may be needed to make forward progress on ongoing operations, and the internal to skiboot API has been that time_wait() of a suitable time will run pollers (on at least one CPU) to help ensure forward progress can be made. In a perfect world, interrupts are used but they may a) be disabled, or b) the thing we're doing can't use interrupts because computers are generally terrible. Back in 3db397ea5892a (circa 2015), we changed skiboot so that we'd run pollers only on the boot CPU, and not if we held any locks. This was to reduce the chance of programming code that could deadlock, as well as to ensure that we didn't just thrash all the cachelines for running pollers all over a large system during boot, or hard spin on the same locks on all secondary CPUs. The problem arises if the OS we're booting makes an OPAL call early on, with interrupts disabled, that requires a poller to run to make forward progress. An example of this would be OPAL_WRITE_NVRAM early in Linux boot (where Linux sets up the partitions it wants) - something that occurs iff we've had to reformat NVRAM this boot (i.e. first boot or corrupted NVRAM). The hiomap implementation should arguably *not* rely on synchronous IPMI messages, but this is a future improvement (as was for mbox before it). The mbox-flash code solved this problem by spinning on check_timers(). More generically though, the approach of running the pollers when no longer booting means we behave more in line with what the API is meant to be, rather than have this odd case of "time_wait() for a condition that could also be tripped by an interrupt works fine unless the OS is up and running but hasn't set interrupts up yet". Fixes: 529bdca0bc546a7ae3ecbd2c3134b7260072d8b0 Fixes: 3db397ea5892a8b348cf412739996731884561b3 Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Diffstat (limited to 'core/timebase.c')
-rw-r--r--core/timebase.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/core/timebase.c b/core/timebase.c
index 24e72959..0ae11d25 100644
--- a/core/timebase.c
+++ b/core/timebase.c
@@ -1,4 +1,3 @@
-
/* Copyright 2013-2014 IBM Corp.
*
* Licensed under the Apache License, Version 2.0 (the "License");
@@ -19,6 +18,7 @@
#include <opal.h>
#include <cpu.h>
#include <chip.h>
+#include <debug_descriptor.h>
unsigned long tb_hz = 512000000;
@@ -57,7 +57,7 @@ void time_wait(unsigned long duration)
return;
}
- if (c != boot_cpu)
+ if (c != boot_cpu && opal_booting())
time_wait_nopoll(duration);
else
time_wait_poll(duration);
OpenPOWER on IntegriCloud