on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
Colin King <colin.k...@canonical.com> writes:
> From: Colin Ian King <colin.k...@canonical.com>
>
> Trivial fix to spelling mistake in hmi_error_types text
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Reviewed-by: Stewart Smith <stew...@li
Colin King writes:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in hmi_error_types text
>
> Signed-off-by: Colin Ian King
Reviewed-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
that one).
The idea behind that is that you can answer "where did all my CPUs go?"
by looking at the device tree rather than having to know the platform
specific way of how guards are stored.
--
Stewart Smith
OPAL Architect, IBM.
quot;where did all my CPUs go?"
by looking at the device tree rather than having to know the platform
specific way of how guards are stored.
--
Stewart Smith
OPAL Architect, IBM.
head to stable? It means that for single threaded
workloads, if you guard out a CPU core you'll not get WoF, which means
that performance goes down when you wouldn't expect it to. Right?
--
Stewart Smith
OPAL Architect, IBM.
d
workloads, if you guard out a CPU core you'll not get WoF, which means
that performance goes down when you wouldn't expect it to. Right?
--
Stewart Smith
OPAL Architect, IBM.
any(policy->cpus, set_pstate, _data, 1);
> + smp_call_function_any(policy->cpus, set_pstate, _data, 0);
> }
Should this have:
Fixes: eaa2c3aeef83f
and CC stable v4.7+ ?
--
Stewart Smith
OPAL Architect, IBM.
r(struct timer_list *t)
> spin_unlock(>gpstate_lock);
>
> /* Timer may get migrated to a different cpu on cpu hot unplug */
> - smp_call_function_any(policy->cpus, set_pstate, _data, 1);
> + smp_call_function_any(policy->cpus, set_pstate, _data, 0);
> }
Should this have:
Fixes: eaa2c3aeef83f
and CC stable v4.7+ ?
--
Stewart Smith
OPAL Architect, IBM.
;
> Fixes : 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle
> states via stop API.")
This should CC stable ?
We'll need this to enable stop11 in firmware and not break things, right?
--
Stewart Smith
OPAL Architect, IBM.
t;powerpc/powernv/idle: Restore SPRs for deep idle
> states via stop API.")
This should CC stable ?
We'll need this to enable stop11 in firmware and not break things, right?
--
Stewart Smith
OPAL Architect, IBM.
generic sensors API?
>>
>
> Disabling/Enabling sensor groups is not supported in the current generic
> sensors
> API. And also we dont export all type of sensors in HWMON as not all of them
> are
> environment sensors (like performance).
Are there barriers to adding such concepts to the generic sensors API?
--
Stewart Smith
OPAL Architect, IBM.
c
> sensors
> API. And also we dont export all type of sensors in HWMON as not all of them
> are
> environment sensors (like performance).
Are there barriers to adding such concepts to the generic sensors API?
--
Stewart Smith
OPAL Architect, IBM.
Anju T Sudhakar <a...@linux.vnet.ibm.com> writes:
> On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote:
>> Michael Ellerman <m...@ellerman.id.au> writes:
>>> Anju T Sudhakar <a...@linux.vnet.ibm.com> writes:
>>>
>>>> Add a
Anju T Sudhakar writes:
> On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote:
>> Michael Ellerman writes:
>>> Anju T Sudhakar writes:
>>>
>>>> Add a kernel command line parameter option to disable In-Memory Collection
>>>> (IMC)
ight thing and nothing special in
kernel. i.e. not to merge this.
--
Stewart Smith
OPAL Architect, IBM.
ch/823249/
would fix the firmware implementation where the counters were already
running before the INIT/START calls, which are likely the cause of the
problems that this patch is trying to work around.
I propose we have the firmware do the right thing and nothing special in
kernel. i.e. not to me
already have two ways of exposing sensors
to Linux: the OPAL_SENSOR API and the IMC API.
Why this method and not use the existing ones?
--
Stewart Smith
OPAL Architect, IBM.
ensors
to Linux: the OPAL_SENSOR API and the IMC API.
Why this method and not use the existing ones?
--
Stewart Smith
OPAL Architect, IBM.
th "memory-region" properties.
A more future-proof fix is likely possible, although more invasive and this
simple fix is perfectly suitable in the meantime while a more future-proof
fix is developed.
Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com>
---
drivers/of/of_res
th "memory-region" properties.
A more future-proof fix is likely possible, although more invasive and this
simple fix is perfectly suitable in the meantime while a more future-proof
fix is developed.
Signed-off-by: Stewart Smith
---
drivers/of/of_reserved_mem.c | 2 +-
1 file change
Rob Herring <r...@kernel.org> writes:
> On Thu, Sep 14, 2017 at 5:24 AM, Stewart Smith
> <stew...@linux.vnet.ibm.com> wrote:
>> There are two types of memory reservations firmware can ask the kernel
>> to make in the device tree: static and dynamic.
>> S
Rob Herring writes:
> On Thu, Sep 14, 2017 at 5:24 AM, Stewart Smith
> wrote:
>> There are two types of memory reservations firmware can ask the kernel
>> to make in the device tree: static and dynamic.
>> See Documentation/devicetree/bindings/reserved-memory/reserved
to do
(although I have not checked every real world device tree on the planet
for this condition)
Fixes: 3f0c8206644836e4f10a6b9fc47cda6a9a372f9b
Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com>
---
NOTE: I've done only fairly limited testing of this on POWER, I
certainly haven't tested
to do
(although I have not checked every real world device tree on the planet
for this condition)
Fixes: 3f0c8206644836e4f10a6b9fc47cda6a9a372f9b
Signed-off-by: Stewart Smith
---
NOTE: I've done only fairly limited testing of this on POWER, I
certainly haven't tested on ARM or *anything* with dynamic
thing, you *could* go
and set a differnt powercap 180 times concurrently and we should do the
right thing in skiboot... but then you're sitting in skiboot rather than
sitting in linux being able to go run some other task on the thread.
--
Stewart Smith
OPAL Architect, IBM.
set a differnt powercap 180 times concurrently and we should do the
right thing in skiboot... but then you're sitting in skiboot rather than
sitting in linux being able to go run some other task on the thread.
--
Stewart Smith
OPAL Architect, IBM.
IBM Verse is a web UI around Lotus Domino mail servers (much like
the Lotus Notes client talks to Domino servers).
For various reasons, it is not at all suitable for kernel development,
all of which have been raised (repeatedly) internally.
Signed-off-by: Stewart Smith <s
IBM Verse is a web UI around Lotus Domino mail servers (much like
the Lotus Notes client talks to Domino servers).
For various reasons, it is not at all suitable for kernel development,
all of which have been raised (repeatedly) internally.
Signed-off-by: Stewart Smith
---
Documentation
n, we'd have no way to detect that and we'd fail silently by
overwriting memory.
--
Stewart Smith
OPAL Architect, IBM.
t that and we'd fail silently by
overwriting memory.
--
Stewart Smith
OPAL Architect, IBM.
if the class
exists but init is a no-op, then OPAL_IMC_COUNTERS_INIT should return
OPAL_SUCCESS and just do nothing. This future proofs everything, and the
API is that one *must* call _INIT before start.
--
Stewart Smith
OPAL Architect, IBM.
L_IMC_COUNTERS_INIT should return
OPAL_SUCCESS and just do nothing. This future proofs everything, and the
API is that one *must* call _INIT before start.
--
Stewart Smith
OPAL Architect, IBM.
; + * "/reserved-memory" node.
> + */
> + for (dn = of_find_node_by_name(rm_node, "ibm,homer-image"); dn;
> + dn = of_find_node_by_name(dn, "ibm,homer-image")) {
> +
> + /* Get the chip id to which the above homer region belongs to */
> + if (of_property_read_u32(dn, "ibm,chip-id", _id))
> + goto err;
So, I was thinking on this (and should probably comment on the firmware
side as well).
I'd prefer an OPAL interface where instead of looking up where
ibm,homer-image is, we provide the kernel with a base address and then
have offsets into it.
That way, we don't tie the kernel code to counters that are only in the
HOMER region.
--
Stewart Smith
OPAL Architect, IBM.
,homer-image"); dn;
> + dn = of_find_node_by_name(dn, "ibm,homer-image")) {
> +
> + /* Get the chip id to which the above homer region belongs to */
> + if (of_property_read_u32(dn, "ibm,chip-id", _id))
> + goto err;
So, I was thinking on this (and should probably comment on the firmware
side as well).
I'd prefer an OPAL interface where instead of looking up where
ibm,homer-image is, we provide the kernel with a base address and then
have offsets into it.
That way, we don't tie the kernel code to counters that are only in the
HOMER region.
--
Stewart Smith
OPAL Architect, IBM.
on
boot.
We may hot plug/unplug CPUs, but we're not doing that from a hardware
level, what CPUs you get in the DT on PowerNV on boot is all you're
getting.
--
Stewart Smith
OPAL Architect, IBM.
g CPUs, but we're not doing that from a hardware
level, what CPUs you get in the DT on PowerNV on boot is all you're
getting.
--
Stewart Smith
OPAL Architect, IBM.
ompatible node under the
top level ibm,opal-in-memory-counters node? (i'm not convinced that
having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
ibm,imc-counters-thread as I see in the dts is correct though, as
they're all accessed exactly the same way?)
--
Stewart Smith
OPAL Architect, IBM.
ibm,opal-in-memory-counters node? (i'm not convinced that
having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
ibm,imc-counters-thread as I see in the dts is correct though, as
they're all accessed exactly the same way?)
--
Stewart Smith
OPAL Architect, IBM.
+#include
> +
> +#define IMC_MAX_CHIPS32
> +#define IMC_MAX_PMUS 32
> +#define IMC_MAX_PMU_NAME_LEN 256
Why do we need a max length? We get the actual lengths from the device
tree, so we know at each point in time what the length of any new string
should be, right?
Otherwise you appear to be, in the general case, using 10x the memory
than you could.
--
Stewart Smith
OPAL Architect, IBM.
256
Why do we need a max length? We get the actual lengths from the device
tree, so we know at each point in time what the length of any new string
should be, right?
Otherwise you appear to be, in the general case, using 10x the memory
than you could.
--
Stewart Smith
OPAL Architect, IBM.
uot;);
> + if (!rm_node)
> + goto err;
> +
> + for_each_child_of_node(rm_node, child) {
> + if (of_property_read_string_index(child, "name", 0,
> + _name))
> + continue;
> +
(child, "name", 0,
> + _name))
> + continue;
> + if (strncmp("ibm,homer-image", node_name,
> + strlen("ibm,homer-image")))
> + continue;
A better way to do this would be to reference the memory region, like
what's shown in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
just reference the phandle of the memory region.
seeing as these are per chip, why not just have something linking
together chip-id and the IMC layout node?
--
Stewart Smith
OPAL Architect, IBM.
end up missing some code, what about this instead:
Remove OPAL regex in powerpc to avoid false match
Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com>
---
MAINTAINERS |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 39
hat about this instead:
Remove OPAL regex in powerpc to avoid false match
Signed-off-by: Stewart Smith
---
MAINTAINERS |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3960e7f..25ed25a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7393,18
special and set it
to DEFAULT_PSSCR_MASK in that case? That deals with old skiboot, new
kernel, and sets a pretty small special case that's easy to track into
the future as something we should watch out for.
Additionally, if we make skiboot set sane values in ~DEFAULT_PSSCR_MASK
for valid fields in PSSCR on boot/(also kexec?), then
we should end up in a situation where everything works with everything
(even if you don't get the best power saving). Specifically, new
skiboot, old kernel... but it looks like there's nothing currently
missing there
Should this patch also have Fixes: 3005c597ba4 and CC to stable?
--
Stewart Smith
OPAL Architect, IBM.
; }
> }
>
>
>
> Is this approach ok ?
What if we just treat the 0xF state from firmware as special and set it
to DEFAULT_PSSCR_MASK in that case? That deals with old skiboot, new
kernel, and sets a pretty small special case that's easy to track into
the future as something we should watch out for.
Additionally, if we make skiboot set sane values in ~DEFAULT_PSSCR_MASK
for valid fields in PSSCR on boot/(also kexec?), then
we should end up in a situation where everything works with everything
(even if you don't get the best power saving). Specifically, new
skiboot, old kernel... but it looks like there's nothing currently
missing there
Should this patch also have Fixes: 3005c597ba4 and CC to stable?
--
Stewart Smith
OPAL Architect, IBM.
nged, 26 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/powerpc/opal/hotplug-aperture.txt
Forgive me for being absent on the whole discussion here, but is this an
OPAL specific binding? If so, shouldn't the docs also appear in the
skiboot tree?
--
Stewart Smith
OPAL Architect, IBM.
ocumentation/devicetree/bindings/powerpc/opal/hotplug-aperture.txt
Forgive me for being absent on the whole discussion here, but is this an
OPAL specific binding? If so, shouldn't the docs also appear in the
skiboot tree?
--
Stewart Smith
OPAL Architect, IBM.
gt; not
> require an additional step of signing it, since the running kernel already
> trusts it.
- using current view of the hardware, flattened into a new dtb.
This should already be trusted, as it's what we're running now (boot +
runtime changes)
--
Stewart Smith
OPAL Architect, IBM.
e an additional step of signing it, since the running kernel already
> trusts it.
- using current view of the hardware, flattened into a new dtb.
This should already be trusted, as it's what we're running now (boot +
runtime changes)
--
Stewart Smith
OPAL Architect, IBM.
Ard Biesheuvel <ard.biesheu...@linaro.org> writes:
> On 13 July 2016 at 09:36, Russell King - ARM Linux
> <li...@armlinux.org.uk> wrote:
>> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>>> Russell King - ARM Linux <li...@armlinux.org.uk> w
Ard Biesheuvel writes:
> On 13 July 2016 at 09:36, Russell King - ARM Linux
> wrote:
>> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>>> Russell King - ARM Linux writes:
>>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
>
Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
>> >
Russell King - ARM Linux writes:
> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>> Russell King - ARM Linux writes:
>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
>> >> I'm not an expert on DTB, so I can't provide an example of
er. Our bootloader is a
linux kernel and initramfs with a UI (petitboot) - this means we never
have to write a device driver twice: write a kernel one and you're done
(for booting from the device and using it in your OS).
--
Stewart Smith
OPAL Architect, IBM.
el and initramfs with a UI (petitboot) - this means we never
have to write a device driver twice: write a kernel one and you're done
(for booting from the device and using it in your OS).
--
Stewart Smith
OPAL Architect, IBM.
So, I assume that this license is compatible with the GPLv2?
https://people.gnome.org/~markmc/openssl-and-the-gpl.html has an
explanation and points to:
https://www.openssl.org/docs/faq.html#LEGAL2
which makes it anything but clearer.
it appears the answer is "probably not, unless you have an explicit
exemption in your license"
--
Stewart Smith
OPAL Architect, IBM.
ps://people.gnome.org/~markmc/openssl-and-the-gpl.html has an
explanation and points to:
https://www.openssl.org/docs/faq.html#LEGAL2
which makes it anything but clearer.
it appears the answer is "probably not, unless you have an explicit
exemption in your license"
--
Stewart Smith
OPAL Architect, IBM.
an attack
vector? Is *every* command line option safe?
> In general, tampering with the hardware inventory of a machine opens up
> a security hole, and one must be very cautious which modifications are
> allowed. You're giving this power to an (unsigned, hence untrusted)
> userspace application; Eric argues that only the kernel should have
> this power.
In the case of petitboot on OpenPOWER, this (will) be a signed and
trusted kernel and userspace and verified by a previous bit of firmware.
--
Stewart Smith
OPAL Architect, IBM.
uses the same console that
>> petitboot was configured to use (i.e., set the /chosen/linux,stdout-path
>> property). It also modifies the device tree to allow the kernel to inherit
>> Petitboot's Openfirmware framebuffer.
>
> Can some of this be done with the help of kernel command line options for
> second kernel?
how would this be any more secure?
Passing in an address for a framebuffer via command line option means
you could scribble over any bit of memory, which is the same kind of
damage you could do by modifying the device tree.
--
Stewart Smith
OPAL Architect, IBM.
being
interacted with in order to set up /chosen/linux,stdout-path correctly.
This specific option could be passed as a kernel command line to the
next kernel, yes. However, isn't the kernel command line also an attack
vector? Is *every* command line option safe?
> In general, tampering with the hardware inventory of a machine opens up
> a security hole, and one must be very cautious which modifications are
> allowed. You're giving this power to an (unsigned, hence untrusted)
> userspace application; Eric argues that only the kernel should have
> this power.
In the case of petitboot on OpenPOWER, this (will) be a signed and
trusted kernel and userspace and verified by a previous bit of firmware.
--
Stewart Smith
OPAL Architect, IBM.
configured to use (i.e., set the /chosen/linux,stdout-path
>> property). It also modifies the device tree to allow the kernel to inherit
>> Petitboot's Openfirmware framebuffer.
>
> Can some of this be done with the help of kernel command line options for
> second kernel?
how would this be any more secure?
Passing in an address for a framebuffer via command line option means
you could scribble over any bit of memory, which is the same kind of
damage you could do by modifying the device tree.
--
Stewart Smith
OPAL Architect, IBM.
th a
dumb idea and a bug?
otherwise (including if above change is made)
Acked-by: Stewart Smith <stew...@linux.vnet.ibm.com>
--
Stewart Smith
OPAL Architect, IBM.
ise (including if above change is made)
Acked-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
mware. :)
It is. PAPR says we format NVRAM when it's corrupted. This is also true
for NVRAM for PowerNV (not just pseries guest).
--
Stewart Smith
OPAL Architect, IBM.
VRAM when it's corrupted. This is also true
for NVRAM for PowerNV (not just pseries guest).
--
Stewart Smith
OPAL Architect, IBM.
here we're all
about OPAL.
With a slight change to the commit message,
Acked-by: Stewart Smith <stew...@linux.vnet.ibm.com>
--
Stewart Smith
OPAL Architect, IBM.
a slight change to the commit message,
Acked-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
herit in
hardware or software that this is computed from?
> +/* Interval after which the timer is queued to bring down global pstate */
> +#define GPSTATE_TIMER_INTERVAL 2000
in ms?
--
Stewart Smith
OPAL Architect, IBM.
computed from?
> +/* Interval after which the timer is queued to bring down global pstate */
> +#define GPSTATE_TIMER_INTERVAL 2000
in ms?
--
Stewart Smith
OPAL Architect, IBM.
additional consoles
> to start properly.
>
> Signed-off-by: Samuel Mendoza-Jonas <s...@mendozajonas.com>
> Cc: <sta...@vger.kernel.org> # 4.1.x-
Tested on 4.4.6 - seemed to stop (some of) the problems I was having
when using it as a kernel for the bootloader on a FSP bas
to start properly.
>
> Signed-off-by: Samuel Mendoza-Jonas
> Cc: # 4.1.x-
Tested on 4.4.6 - seemed to stop (some of) the problems I was having
when using it as a kernel for the bootloader on a FSP based POWER8
system.
Tested-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
undation hat on, I'll say that it's a
work-in-progress getting all this documentation in order.
The questions of if it's a sensible hypervisor to partition interface
and if it's a sensible userspace API are open for debate :)
Would we implement this way of communicating between a KVM guest and the
host linux system? If not, then it's probably not a generally good
idea. That being said, it seems to be what already exists in PowerVM
--
Stewart Smith
OPAL Architect, IBM.
umentation in order.
The questions of if it's a sensible hypervisor to partition interface
and if it's a sensible userspace API are open for debate :)
Would we implement this way of communicating between a KVM guest and the
host linux system? If not, then it's probably not a generally good
idea. That being said, it seems to be what already exists in PowerVM
--
Stewart Smith
OPAL Architect, IBM.
en this on some machines, at
least in the lab.
--
Stewart Smith
OPAL Architect, IBM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y should CC stable@ as we have seen this on some machines, at
least in the lab.
--
Stewart Smith
OPAL Architect, IBM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
linux.conf.au 2016 in Geelong will have a kernel miniconf. The format is
part talks, part unconference.
The miniconf will be all day Monday.
Like previous years, a mixture of organised talks and impromptu
discussion and sessions can provide a good mix.
CFP open until Jan 20th. Unconference
linux.conf.au 2016 in Geelong will have a kernel miniconf. The format is
part talks, part unconference.
The miniconf will be all day Monday.
Like previous years, a mixture of organised talks and impromptu
discussion and sessions can provide a good mix.
CFP open until Jan 20th. Unconference
Daniel Axtens writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
> > Could you explain why it's useful, and what it's useful for. Moreover,
> > it's POWER8 feature, right?
>
> I'm not sure whether you're asking about the script or
Daniel Axtens writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
> > Could you explain why it's useful, and what it's useful for. Moreover,
> > it's POWER8 feature, right?
>
> I'm not sure whether you're asking
David Gibson writes:
>> > opal/powernv:
>> > https://github.com/open-power/skiboot/commit/9ee56b5
>>
>> Very interesting. Is there a way to have a firmware with the fix ?
>
> From Laurent's analysis of the crash, I don't think this will be
> relevant either, but I'm not sure. It would be very
David Gibson writes:
>> > opal/powernv:
>> > https://github.com/open-power/skiboot/commit/9ee56b5
>>
>> Very interesting. Is there a way to have a firmware with the fix ?
>
> From Laurent's analysis of the crash, I don't think this will be
> relevant either, but I'm not sure.
Shilpasri G Bhat writes:
> Modify the OCC reset/load/active event message to make it clearer for
> the user to understand the event and effect of the event.
>
> Suggested-by: Stewart Smith
> Signed-off-by: Shilpasri G Bhat
Acked-by: Stewart Smith
--
To unsubscribe from
Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com> writes:
> Modify the OCC reset/load/active event message to make it clearer for
> the user to understand the event and effect of the event.
>
> Suggested-by: Stewart Smith <stew...@linux.vnet.ibm.com>
> Signed-off-by:
Shilpasri G Bhat writes:
>> Also, do we export this information via sysfs somewhere? It would seem
>> to want to go along with other cpufreq/cpu info there.
>
> No we don't export the throttling status of the cpu via sysfs. Since the
> throttling state is common across the chip, the per_cpu
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
Also, do we export this information via sysfs somewhere? It would seem
to want to go along with other cpufreq/cpu info there.
No we don't export the throttling status of the cpu via sysfs. Since the
throttling state is common across the
Shilpasri G Bhat writes:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index d0c18c9..a634199 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include /*
Shilpasri G Bhat writes:
> Add OPAL_MSG_OCC message definition to opal_message_type to receive
> OCC events like reset, load and throttled. Host performance can be
> affected when OCC is reset or OCC throttles the max Pstate.
> We can register to opal_message_notifier to receive OPAL_MSG_OCC type
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index d0c18c9..a634199 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -33,6 +33,7 @@
#include
patch fixes this issue by setting opal_rtc_ops.read/set_alarm
> callback pointers only when tpo is supported.
>
> Acked-by: Michael Neuling
> Acked-by: Neelesh Gupta
> Signed-off-by: Vaibhav Jain
Acked-by: Stewart Smith
FWIW I'm updating OPAL docs with this. The TPO calls aren't
by setting opal_rtc_ops.read/set_alarm
callback pointers only when tpo is supported.
Acked-by: Michael Neuling mi...@neuling.org
Acked-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Vaibhav Jain vaib...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
FWIW I'm
Madhavan Srinivasan writes:
> Nest Counters can be configured via PORE Engine and OPAL
> provides an interface call to it. PORE Engine also does the
> work of moving the counter data to memory.
Do you have the associated skiboot patch that implements this firmware
call? I haven't seen it on
Madhavan Srinivasan ma...@linux.vnet.ibm.com writes:
Nest Counters can be configured via PORE Engine and OPAL
provides an interface call to it. PORE Engine also does the
work of moving the counter data to memory.
Do you have the associated skiboot patch that implements this firmware
call? I
hotplug vs. set_cpus_allowed_ptr()")
> Signed-off-by: Michael Ellerman
> Signed-off-by: Anton Blanchard
By building a gcov enabled skiboot, which makes OPAL_START_CPU a whole
bunch slower (because gcov), I could really *really* reliably reproduce
this. With this patch, I cannot.
Michael Ellerman writes:
> Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
> output confirms
Michael Ellerman m...@ellerman.id.au writes:
Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
kernel BUG at kernel/smpboot.c:134! issue during boot:
BUG_ON(td-cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output
By building a gcov enabled skiboot, which makes OPAL_START_CPU a whole
bunch slower (because gcov), I could really *really* reliably reproduce
this. With this patch, I cannot.
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
1 - 100 of 188 matches
Mail list logo