Balbir Singh writes:
> I ran into this during some testing on qemu. The current
> facility_strings[] are correct when the trap address is
> 0xf80 (hypervisor facility unavailable). When the trap
> address is 0xf60, IC (Interruption Cause) a.k.a status
> in the code is undefined for values 0 and 1
Adding fast_switch which does light weight operation to set the desired
pstate. Both global and local pstates are set to the same desired pstate.
Signed-off-by: Akshay Adiga
---
Changes from v1 :
- Removed unnecessary check for index out of bound.
drivers/cpufreq/powernv-cpufreq.c | 20
As fast_switch() may get called with interrupt disable mode, we cannot
hold a mutex to update the global_pstate_info. So currently, fast_switch()
does not update the global_pstate_info and it will end up with stale data
whenever pstate is updated through fast_switch().
As the gpstate_timer can fir
Denis Kirjanov writes:
> [ 67.700897] BUG: using smp_processor_id() in preemptible []
> code: cat/7343
> [ 67.700988] caller is .powernv_cpufreq_throttle_check+0x2c/0x710
> [ 67.700998] CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1
> [ 67.701038] Call
Thanks Viresh for taking a look at it.
I will make the mentioned changes in the next version of the patch and
will add Shilpa and Gautham to the mail chain.
Regards
Akshay Adiga
On 11/04/2016 12:11 PM, Viresh Kumar wrote:
On 04-11-16, 10:57, Akshay Adiga wrote:
As fast_switch may get called
Thanks Viresh for taking a look at it.
I will make the mentioned changes in the next version of the patch.
Regards
Akshay Adiga
On 11/04/2016 12:03 PM, Viresh Kumar wrote:
On 04-11-16, 10:57, Akshay Adiga wrote:
Adding fast_switch which does light weight operation to
set the desired pstate
On Monday, November 7, 2016, Gautham R Shenoy
wrote:
> Hi Denis,
>
> On Fri, Nov 04, 2016 at 07:08:38AM -0400, Denis Kirjanov wrote:
>
> You can provide the config option with which this bug was found in the
> change log. I suppose you had enabled CONFIG_DEBUG_PREEMPT.
>
>
that's why I put the co
Hi Denis,
On Fri, Nov 04, 2016 at 07:08:38AM -0400, Denis Kirjanov wrote:
You can provide the config option with which this bug was found in the
change log. I suppose you had enabled CONFIG_DEBUG_PREEMPT.
> [ 67.700897] BUG: using smp_processor_id() in preemptible []
> code: cat/7
Patch to add macros and constants to support the PowerISA v3.0 raw
event encoding format. Couple of new functions added to support
the new width and location of bit fields like PMCxCOMB and THRESH_CMP
within MMCR* in PowerISA v3.0.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/isa207-
Patch to update the PowerISA v3.0 raw event encoding format
information and add support for the same in Power9.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/power9-pmu.c | 134 +
1 file changed, 134 insertions(+)
diff --git a/arch/powerpc/perf
Rename the power_pmu and attribute_group variables that
support PowerISA v2.07. Add a cpu feature flag check to pick
the PowerISA v2.07 format structures to support.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/power9-pmu.c | 11 +++
1 file changed, 7 insertions(+), 4 deletio
Factor out the format field structure for PowerISA v2.07.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/isa207-common.c | 34 ++
arch/powerpc/perf/power8-pmu.c| 39 ---
arch/powerpc/perf/power9-pmu.c| 39 -
Patchset to factor out the PowerISA v2.07 PMU raw event
format encoding and add support to the PowerISA v3.0 PMU
raw event format encoding.
Madhavan Srinivasan (4):
powerpc/perf: factor out the event format field
powerpc/perf: update attribute_group data structure
powerpc/perf: PowerISA v3.0
On 04/11/16 23:07, Frederic Barrat wrote:
When I inject an EEH error, this patch causes the following WARN.
Thoughts?
mmm, hard to see a relation with that patch. I couldn't reproduce
either. Could it bear any relation with the patch you're working on
(lspci called while the capi device is unco
On 05/11/16 00:15, Uma Krishnan wrote:
Frederic/Andrew,
Just recently this issue has been reported by system test without any
of the two patches you are suspecting - this patch nor the lspci patch.
I was hoping the lspci patch from Andrew can possibly solve it.
System test CQ is SW370625. The st
On Fri, 4 Nov 2016 19:42:48 +0900
Masahiro Yamada wrote:
> nand_scan(), nand_scan_ident(), nand_scan_tail() return
> an appropriate negative value on error.
>
> Most of drivers return the value from them on error,
> but some of them return the fixed error code -ENXIO
> (and a few return -ENODEV
On Thu, Nov 3, 2016 at 8:40 AM, Brian King wrote:
> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>>> We recently encountered a bug where a few customers using ibmveth on the
>>> same LPAR hit an issue where a TCP session hung when large recei
On Sunday 06 November 2016 01:01 AM, Anton Blanchard wrote:
> Hi,
>
>> kprobe, uprobe, hw-breakpoint and xmon are the only user of
>> emulate_step.
>>
>> Kprobe / uprobe single-steps instruction if they can't emulate it, so
>> there is no problem with them. As I mention, hw-breakpoint is broken.
Hi! Here is my third regression report for Linux 4.9. It lists 17
regressions I'm aware of. 6 of them are new; 3 got fixed since
last weeks report (a fourth looks fixed as well). The console
problem ("console: don't prefer first registered [...]") got
reported to me multiple times, but the revert t
Lo! On 01.11.2016 09:18, Paul Bolle wrote:
> On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
>> As always: Are you aware of any other regressions? Then please let me
>> know (simply CC regressi...@leemhuis.info).
> Do build regressions count?
That's a good question.
> Because I was tr
20 matches
Mail list logo
