On 26/11/2014 04:31, Michael Ellerman wrote:
> OK. You say "LPAR", by which you mean "under phyp" I think. I haven't seen
> this
> under KVM, and it looks like KVM doesn't implement "set-indicator" so that
> would explain that.
Yes LPAR implies phyp, and KVM don't implement "set-indicator" so thi
On Tue, 2014-25-11 at 10:08:48 UTC, Anshuman Khandual wrote:
> This patch enables support for hardware instruction breakpoints
> on POWER8 with the help of a new register CIABR (Completed
> Instruction Address Breakpoint Register). With this patch, single
> hardware instruction breakpoint can be ad
Hi Michael,
thanks for your reply! some general thought:
This change was introduced mid 2013 but we don't have a single user relying
on this code change yet, right?
Disabling might_sleep() for functions that clearly state that they may sleep to
get some special case running feels wrong to me.
>
On 11/26/2014 09:14 AM, Michael Ellerman wrote:
> On Thu, 2014-20-11 at 04:14:36 UTC, Mahesh Salgaonkar wrote:
>> From: Mahesh Salgaonkar
>>
>> The current HMI event structure is an ABI and carries a version field to
>> accommodate future changes without affecting/rearranging current structure
>>
Hello.
My Freescale TWR-MPC5125 board instantly reboots if I touch
any physical address on the LocalPlus Bus (LPB) for the first time
when Linux has already booted.
This effect is reproduced by using /dev/mem or loading a kernel module
which works with any peripherals on LPB.
It took me some ti
On Tue, 25 Nov 2014 21:11:58 -0600
, Nathan Fontenot
wrote:
> On 11/25/2014 05:07 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-11-24 at 22:33 +, Grant Likely wrote:
> >> The OF_RECONFIG notifier callback uses a different structure depending
> >> on whether it is a node change or a prope
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > What's the path you are trying to debug?
>
> Well, we had a problem where we held a spin_lock and called
> copy_(from|to)_user(). We experienced very random deadlocks that took some guy
> almost a week to debug. The simple migh
Add support for the Artesyn MVME2500 Single Board Computer.
The MVME2500 is a 6U form factor VME64 computer with:
- A single Freescale QorIQ P2010 CPU
- 1 GB of DDR3 onboard memory
- Three Gigabit Ethernets
- Five 16550 compatible UARTS
- One USB 2.0 port,
Hmm you sent same mail to me off-list, and I replied there.
Now there's a copy on list - I'm just going to assume
it's exactly identical, pasting my response here as well.
If there are more questions I missed, let me know.
On Wed, Nov 26, 2014 at 09:23:31AM +0100, David Hildenbrand wrote:
> Sorry
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > What's the path you are trying to debug?
> >
> > Well, we had a problem where we held a spin_lock and called
> > copy_(from|to)_user(). We experienced very
Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
>>> What's the path you are trying to debug?
>>
>> Well, we had a problem where we held a spin_lock and called
>> copy_(from|to)_user(). We experienced very random deadlocks that
> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > > What's the path you are trying to debug?
> > >
> > > Well, we had a problem where we held a spin_lock and called
> > > copy_(from|to)_user(). We expe
On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> >>> What's the path you are trying to debug?
> >>
> >> Well, we had a problem where we held a spin_loc
On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
> > On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > > > What's the path you are trying to debug?
> > > >
> > > > Well, we had a prob
> > This is what happened on our side (very recent kernel):
> >
> > spin_lock(&lock)
> > copy_to_user(...)
> > spin_unlock(&lock)
>
> That's a deadlock even without copy_to_user - it's
> enough for the thread to be preempted and another one
> to try taking the lock.
>
>
> > 1. s390 locks/unlock
Am 26.11.2014 um 16:37 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
>> Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
>>> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> What's the path you are trying to debug?
>>>
Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
>>> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
>> What's the path you are tryi
On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
> > > This is what happened on our side (very recent kernel):
> > >
> > > spin_lock(&lock)
> > > copy_to_user(...)
> > > spin_unlock(&lock)
> >
> > That's a deadlock even without copy_to_user - it's
> > enough for the thread to be
Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
This is what happened on our side (very recent kernel):
spin_lock(&lock)
copy_to_user(...)
spin_unlock(&lock)
>>>
>>> That's a deadlock even without copy_
On Wed, Nov 26, 2014 at 05:07:13PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
> >>> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at
On Wed, Nov 26, 2014 at 05:30:35PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
> This is what happened on our side (very recent kernel):
>
> spin_lock(&lock)
> cop
Am 26.11.2014 um 17:32 schrieb Michael S. Tsirkin:
[...]
This is what happened on our side (very recent kernel):
spin_lock(&lock)
copy_to_user(...)
spin_unlock(&lock)
>>>
>>> That's a deadlock even without copy_to_user - it's
>>> enough for the thread to be preempted and an
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > But this one was > giving users in field false positives.
>
> So lets try to fix those, ok? If we cant, then tough luck.
Sure.
I think the simplest way might be to make spinlock disable
premption when CONFIG_DEBUG_ATOMIC_S
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > But this one was > giving users in field false positives.
> >
> > So lets try to fix those, ok? If we cant, then tough luck.
>
> Sure.
> I think the s
I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.
Fixes: 18ad51dd342a ("powerpc: Add VDSO version of getcpu")
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/vdso32/getcpu.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
On Wed, 2014-11-26 at 15:17 +0100, Alessio Igor Bogani wrote:
> + board_soc: soc: soc@ffe0 {
There's no need for two labels on the same node.
> + ranges = <0x0 0 0xffe0 0x10>;
> +
> + i2c@3000 {
> + hwmon@4c {
> +
On Wed, 2014-11-26 at 15:56 +0530, Mahesh Jagannath Salgaonkar wrote:
> On 11/26/2014 09:14 AM, Michael Ellerman wrote:
> > On Thu, 2014-20-11 at 04:14:36 UTC, Mahesh Salgaonkar wrote:
> >> From: Mahesh Salgaonkar
> >>
> >> The current HMI event structure is an ABI and carries a version field to
>
On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote:
> I used some 64 bit instructions when adding the 32 bit getcpu VDSO
> function. Fix it.
Ouch. The symptom is a SIGILL I presume?
Could we catch this by forcing -m32 in the CFLAGS for vdso32 ?
cheers
On Thu, Nov 27, 2014 at 09:38:17AM +1100, Michael Ellerman wrote:
> On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote:
> > I used some 64 bit instructions when adding the 32 bit getcpu VDSO
> > function. Fix it.
>
> Ouch. The symptom is a SIGILL I presume?
>
> Could we catch this by forcin
On Wed, Nov 26, 2014 at 05:23:18PM -0600, Segher Boessenkool wrote:
> GCC has added -many to the assembler flags for over ten years now, so
> no that will not work. You can use -mppc or similar with the assembler
> if you invoke it correctly (use $(CC) -print-prog-name=as to figure
s/correctly/d
On Mon, 2014-11-17 at 18:42 +0100, Greg Kurz wrote:
> The first argument to vphn_unpack_associativity() is a const long *, but the
> parsing code expects __be64 values actually. This is inconsistent. We should
> either pass a const __be64 * or change vphn_unpack_associativity() so that
> it fixes e
On Mon, 2014-11-17 at 15:51 -0600, Nathan Fontenot wrote:
>
> For PowerVM systems, this patch creates the /sys/kernel/dlpar file that rtas
> hotplug events can be written to by drmgr and passed to the common entry
> point.
> There is no chance of updating how we receive hotplug requests on PowerV
>
> @@ -37,8 +38,7 @@
>
> /*
> * Pass requested state in r3:
> - * 0 - nap
> - * 1 - sleep
> + * r3 - PNV_THREAD_NAP/SLEEP/WINKLE
> *
> * To check IRQ_HAPPENED in r4
> * 0 - don't check
> @@ -123,12 +123,62 @@ power7_enter_nap_mode:
> li r4,KVM_HWTHREAD_IN_NAP
>
On Mon, Oct 20, 2014 at 07:59:00PM +0530, Aneesh Kumar K.V wrote:
> Minor cleanup
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/kvm/book3s_hv_rm_mmu.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rm_mm
On Tue, 2014-11-25 at 16:47 +0530, Shreyas B. Prabhu wrote:
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S
> b/arch/powerpc/kernel/cpu_setup_power.S
> index 4673353..66874aa 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -55,6 +55,8 @
Hi Greg,
So Nathan is working on a patch series to cleanup and improve our
"DLPAR" infrastructure which is basically our hotplug mechanism when
running under the PowerVM (aka pHyp) and KVM hypervisors.
I'll let Nathan give you a bit more details/background and answer
subsequent question you might
Hello Mike,
Could you please apply this patch?
This patch has been acked for a while.
Thanks,
Yuantian
> -Original Message-
> From: Linuxppc-dev
> [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On
> Behalf Of Scott Wood
> Sent: Friday, November 07, 2014 12:08 PM
> To
On Thu, 2014-11-27 at 09:38 +1100, Michael Ellerman wrote:
> On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote:
> > I used some 64 bit instructions when adding the 32 bit getcpu VDSO
> > function. Fix it.
>
> Ouch. The symptom is a SIGILL I presume?
Nope, you don't get a SIGILL when execut
Hi Linus,
Here are five fixes for you to pull please.
I think these are all rc6 material, but I'm still learning so let me know if
you disagree :)
They're all CC'ed to stable except the "Fix PE state format" one which went in
this release.
cheers
The following changes since commit d7ce4377494
Hi Ben,
On Thursday 27 November 2014 06:07 AM, Benjamin Herrenschmidt wrote:
>
>>
>> @@ -37,8 +38,7 @@
>>
>> /*
>> * Pass requested state in r3:
>> - * 0 - nap
>> - * 1 - sleep
>> + * r3 - PNV_THREAD_NAP/SLEEP/WINKLE
>> *
>> * To check IRQ_HAPPENED in r4
>> * 0 - don't check
>> @
Hi Ben,
On Thursday 27 November 2014 07:25 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-11-25 at 16:47 +0530, Shreyas B. Prabhu wrote:
>
>> diff --git a/arch/powerpc/kernel/cpu_setup_power.S
>> b/arch/powerpc/kernel/cpu_setup_power.S
>> index 4673353..66874aa 100644
>> --- a/arch/powerpc/ker
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > But this one was > giving users in field false positives.
> >
> > So lets try to fix those, ok? If we cant, then tough luck.
>
> Sure.
> I think the s
On Thu, Nov 27, 2014 at 08:09:19AM +0100, Heiko Carstens wrote:
> On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > > But this one was > giving users in field false positives.
> > >
> > > So lets try
43 matches
Mail list logo
