On Tue, 2014-06-10 at 15:20 +0200, Christian Zigotzky wrote:
> Hi All,
>
> Could you help me to remove the changes of the PCI code, please? Or
> which patches shall I remove to get the old PCI code?
Hi Christian,
Thanks for doing the bisect. It wasn't clear why that change was causing your
issu
On 06/17/2014 08:23 AM, Geert Uytterhoeven wrote:
On Tue, Jun 17, 2014 at 5:16 PM, Geert Uytterhoeven
wrote:
[...]
+ /scratch/kisskb/src/sound/soc/fsl/fsl_dma.c: error: invalid use of undefined
type 'struct ccsr_ssi': => 926:34, 927:34
powerpc/mpc85xx_defconfig
Being fixed:
:
OF stdout device is: /vdevice/vty@3000
Preparing to boot Linux version 3.16.0-rc1-next-20140617+ (root@shui)
(gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #5 SMP Tue Jun
17 05:16:21 EDT 2014
Detected machine type: 0101
Max number of cores passed to firmware: 256 (NR_CPUS
On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
> On 16 June 2014 12:46, Russell King - ARM Linux
> wrote:
> > On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
> >> @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host
> >> *host, struct mmc_ios *ios)
>
On Thu, Jun 5, 2014 at 11:38 PM, Masami Hiramatsu
wrote:
> Ping?
>
> I guess this should go to 3.16 branch, shouldn't it?
>
> (2014/05/30 12:18), Masami Hiramatsu wrote:
>> On ia64 and ppc64, the function pointer does not point the
>> entry address of the function, but the address of function
>> d
>
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit
> > declaration of function 'atomic_add'
> > [-Werror=implicit-function-declaration]: => 176:2
> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit
> > declaration of function 'atomic_add
Hi Sam,
On Tue, Jun 17, 2014 at 11:29 PM, Sam Ravnborg wrote:
>> > + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit
>> > declaration of function 'atomic_add'
>> > [-Werror=implicit-function-declaration]: => 176:2
>> > + /scratch/kisskb/src/include/asm-generic/atomic
On 17.06.14 22:36, mihai.cara...@freescale.com wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 11:05 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v3] KVM: PPC: e50
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 17, 2014 11:05 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
> condition o
On Tue, 2014-06-17 at 15:02 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, June 17, 2014 10:48 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 17, 2014 10:48 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
> condition o
On Tue, 2014-06-17 at 14:42 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > > -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
> > > +static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
> > last_vcpu_on_cpu);
> >
> > Hmm, I didn't know you could express types like that. Is this
> > -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
> > +static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
> last_vcpu_on_cpu);
>
> Hmm, I didn't know you could express types like that. Is this special
> syntax that only works for typeof?
Yes, AFAIK.
> No space after *
Ch
On Tue, Jun 17, 2014 at 10:31:09PM +0800, Jeff Liu wrote:
> From: Jie Liu
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Signed-off-by: Jie Liu
> ---
> arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
> arch/powerpc/platforms/powernv/opal-elog.c | 4 ++--
> 2 files changed, 3 inserti
On Tue, 2014-06-17 at 22:09 +0300, Mihai Caraman wrote:
> On vcpu schedule, the condition checked for tlb pollution is too loose.
> The tlb entries of a vcpu become polluted (vs stale) only when a different
> vcpu within the same logical partition runs in-between. Optimize the tlb
> invalidation co
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping last_vcpu_on_cpu per logical partition id.
With
On Tue, 2014-06-17 at 14:04 -0500, Caraman Mihai Claudiu-B02008 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, June 17, 2014 6:36 PM
> > To: Caraman Mihai Claudiu-B02008
> > Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 17, 2014 6:36 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v2] KVM: PPC: e500mc: Enhance tlb invalidation
> condition on
On 12.06.14 10:16, Anton Blanchard wrote:
Both kvmppc_hv_entry_trampoline and kvmppc_entry_trampoline are
assembly functions that are exported to modules and also require
a valid r2.
As such we need to use _GLOBAL_TOC so we provide a global entry
point that establishes the TOC (r2).
Signed-off
On 12.06.14 10:16, Anton Blanchard wrote:
To establish addressability quickly, ABIv2 requires the target
address of the function being called to be in r12.
Signed-off-by: Anton Blanchard
Thanks, applied to kvm-ppc-queue.
Alex
---
Index: b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
The commit 71ec7c55ed91 introduced the magic symbol ".TOC." for ELFv2 ABI.
This symbol is built manually and has no CRC value computed. A zero value
is put in the CRC section to avoid modpost complaining about a missing CRC.
Unfortunately, this breaks the kernel module loading when the kernel is
re
This patch hooks into the ras EPOW interrupt handler so that we can
communicate hotplug rtas events to a PowerKVM guest from qemu.
The ras epow interrupt wil lnow check for hotplgu rtas events and
invoke the common handling routine accordingly.
---
arch/powerpc/include/asm/rtas.h | 1 +
This patch updates the cpu hotplug handling code so that we can perform
cpu hotplug using the new rtas hotplug event interface while still
maintaining the ability to use the probe/release sysfs interface
for adding and removing cpus.
At a later point we could deprecate the use of the probe/release
This patch moves the cpu hotplug handling code from pseries/dlpar.c
to pseries/hotplug-cpu.c. Additionally it factors out the work to
add/remove a single cpu into its own routine.
---
arch/powerpc/platforms/pseries/dlpar.c | 182 -
arch/powerpc/platforms/pseries/hotp
In order to support hotplug of memory, cpu and pci devices in the PowerVM
and the PowerKVM environments we will need to provide a single entry
point. To do this requires updating the way in which we handle hotplug
requests in the PowerVM environment. The idea is to have all of the hotplug
in the ke
In order to support device hotplug (cpu, memory, and pci) in both the
PowerVM and the PowerKVM environments the handling of hotplug events
will need to be updated. This patch set adresses this by creating a
common entry point for handling hotplug events in the kernel that
can be used in both PowerV
On Tue, 2014-06-17 at 12:02 +0300, Mihai Caraman wrote:
> On vcpu schedule, the condition checked for tlb pollution is too loose.
> The tlb entries of a vcpu become polluted (vs stale) only when a different
> vcpu within the same logical partition runs in-between. Optimize the tlb
> invalidation co
On Thu, 2014-06-12 at 19:04 +0200, Alexander Graf wrote:
> On 06/12/2014 04:00 PM, Mihai Caraman wrote:
> > @@ -140,12 +142,24 @@ static void kvmppc_core_vcpu_load_e500mc(struct
> > kvm_vcpu *vcpu, int cpu)
> > mtspr(SPRN_GDEAR, vcpu->arch.shared->dar);
> > mtspr(SPRN_GESR, vcpu->arch.shar
On Tue, Jun 17, 2014 at 5:16 PM, Geert Uytterhoeven
wrote:
> 85 regressions:
> + /scratch/kisskb/src/arch/mips/net/bpf_jit.c: error: 'BPF_S_ALU_ADD_K'
> undeclared (first use in this function): => 930:8
[]
> + /scratch/kisskb/src/arch/mips/net/bpf_jit.c: error: 'BPF_S_STX'
> undecla
From: Jie Liu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Jie Liu
---
arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
arch/powerpc/platforms/powernv/opal-elog.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dum
On 17.06.14 13:13, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 04:38 PM, Alexander Graf wrote:
On 17.06.14 13:07, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for so
In machine_check_e500 exception handler is a wrong indication
in case of MCSR_BUS_WBERR - so print "Write" instead of "Read".
Signed-off-by: Wladislav Wiebe
---
arch/powerpc/kernel/traps.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arc
> Before the patch, I believe tty_reopen() would return -EIO because
> the TTY_CLOSING flag is set. After the patch, tty_open() blocks
> on tty_lock() before calling tty_reopen(). AFAICT, this is independent
> of O_NONBLOCK.
That would be a bug then. Returning -EIO is fine (if unfriendly). The
O_N
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, June 17, 2014 12:09 PM
> To: Wood Scott-B07421
> Cc: Caraman Mihai Claudiu-B02008; kvm-...@vger.kernel.org;
> k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] KVM: PPC: e500mc: Rela
On 06/17/2014 07:03 AM, David Laight wrote:
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete the function that
sends the pending data. I
On Tuesday 17 June 2014 11:03:50 David Laight wrote:
> From: Peter Hurley
> ...
> > > I don't understand the second half of the changelog, it doesn't seem
> > > to fit here: there deadlock that we are trying to avoid here happens
> > > when the *same* tty needs the lock to complete the function tha
On Tuesday 17 June 2014 04:38 PM, Alexander Graf wrote:
>
> On 17.06.14 13:07, Madhavan Srinivasan wrote:
>> On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
>>> On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is th
On 17.06.14 13:20, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 03:13 PM, Alexander Graf wrote:
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200,
On Tuesday 17 June 2014 03:13 PM, Alexander Graf wrote:
>
> On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
>> On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
>>> On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
> Also, wh
On 17.06.14 13:07, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
>
> On 14.06.14 23:08, Madhavan Srinivasan wrote:
>> This patch adds kernel side support for software breakpoint.
>> Design is that, by using an illegal instruction, we trap to hypervisor
>> via Emulation Assistance interrupt, where we check
From: Peter Hurley
...
> > I don't understand the second half of the changelog, it doesn't seem
> > to fit here: there deadlock that we are trying to avoid here happens
> > when the *same* tty needs the lock to complete the function that
> > sends the pending data. I don't think we do still do that
On 06/17/2014 04:00 AM, Arnd Bergmann wrote:
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
However,
On Tuesday 17 June 2014 03:02 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
>> On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
>>> On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that a
-next-20140617+ (root@shui)
(gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #5 SMP Tue Jun 17
05:16:21 EDT 2014
Detected machine type: 0101
Max number of cores passed to firmware: 256 (NR_CPUS = 1024)
Calling ibm,client-architecture-support... done
command line: BOOT_IMAGE=/vmlinux
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually is
defined as i
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
> On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
> >> Also, why don't we use twi always or something else that actually is
> >> defined as illegal instruction? I would like to see
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually is
defined as illegal instruction? I would like to see this shared with
book3s_32 PR.
twi will be directed to the guest on
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
>
> Also, why don't we use twi always or something else that actually is
> defined as illegal instruction? I would like to see this shared with
> book3s_32 PR.
twi will be directed to the guest on HV no ? We want a real illegal
because th
On 13.06.14 21:42, Scott Wood wrote:
On Fri, 2014-06-13 at 16:55 +0200, Alexander Graf wrote:
On 13.06.14 16:43, mihai.cara...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, June 12, 2014 8:05 PM
To: Caraman Mihai Claudiu-B02008
Cc:
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition taking into account the logical partition id.
With the
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host or Gu
On 2014-06-17 16:23:58 Tue, Paul Mackerras wrote:
> On Wed, Jun 11, 2014 at 02:18:21PM +0530, Mahesh J Salgaonkar wrote:
> > From: Mahesh Salgaonkar
> >
> > Currently we forward MCEs to guest which have been recovered by guest.
> > And for unhandled errors we do not deliver the MCE to guest. It l
From: Arnd Bergmann
> On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
> > tty_wait_until_sent_from_close() drops the tty lock while waiting
> > for the tty driver to finish sending previously accepted data (ie.,
> > data remaining in its write buffer and transmit fifo).
> >
> > However, droppin
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
> tty_wait_until_sent_from_close() drops the tty lock while waiting
> for the tty driver to finish sending previously accepted data (ie.,
> data remaining in its write buffer and transmit fifo).
>
> However, dropping the tty lock is a hold-over f
Simon, I missed "kexec" string in subject, so please ignore this
version. I would resend it with adding "kexec" in subject.
Thanks
Wei
On 06/17/2014 02:01 PM, Yang,Wei wrote:
Hi Simon,
How about this patch?
Thanks
Wei
On 06/12/2014 01:16 PM, wei.y...@windriver.com wrote:
From: Yang Wei
The
From: Yang Wei
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the length
of directory name,
57 matches
Mail list logo
