In kexec_prepare_cpus cpu, the primary CPU IPIs the secondary CPUs to
kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1. The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the primary IPIing one
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
This optimises the path so that we only remove PTEs that are valid.
It also uses the read 4 PTEs at onc
This adds plpar_pte_read_4_raw() which can be used read 4 PTEs from
PHYP at a time, while in real mode.
It also creates a new hcall9 which can be used in real mode. It's the
same as plpar_hcall9 but minus the tracing hcall statistics which may
require variables outside the RMO.
Signed-off-by: Mi
(2010/05/11 12:43), Marcelo Tosatti wrote:
On Tue, May 04, 2010 at 10:08:21PM +0900, Takuya Yoshikawa wrote:
+How to Get
+
+Before calling this, you have to set the slot member of kvm_user_dirty_log
+to indicate the target memory slot.
+
+struct kvm_user_dirty_log {
+ __u32 slot;
+ _
On Mon, 2010-05-10 at 15:53 -0500, Brian King wrote:
> Adds support for suspend/resume for VIO devices. This is needed for
> support for HMC initiated hibernation.
Your previous version of that patch is already in powerpc-next. Please
make a new patch against it.
Cheers,
Ben.
> Signed-off-by: Br
On Tue, May 04, 2010 at 10:08:21PM +0900, Takuya Yoshikawa wrote:
> Now that dirty bitmaps are accessible from user space, we export the
> addresses of these to achieve zero-copy dirty log check:
>
> KVM_GET_USER_DIRTY_LOG_ADDR
>
> We also need an API for triggering dirty bitmap switch to take
On Tue, May 04, 2010 at 10:07:02PM +0900, Takuya Yoshikawa wrote:
> We move dirty bitmaps to user space.
>
> - Allocation and destruction: we use do_mmap() and do_munmap().
>The new bitmap space is twice longer than the original one and we
>use the additional space for double buffering: t
Author: Milton Miller
On large machines we are running out of room below 256MB. In some cases we
only need to ensure the allocation is in the first segment, which may be
256MB or 1TB.
Add slb0_limit and use it to specify the upper limit for the irqstack and
emergency stacks.
On a large ppc64 bo
On Tue, 2010-05-11 at 12:23 +1000, Anton Blanchard wrote:
> With sparse irqs we have to check if we have a descriptor before dereferencing
> it.
>
> Signed-off-by: Anton Blanchard
> ---
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 6f4613d..5182439 100644
> -
On Tue, 2010-05-11 at 12:25 +1000, Anton Blanchard wrote:
> We wrap the crash_shutdown_handles[] calls with longjmp/setjmp, so if any
> of them fault we can recover. The problem is we add a hook to the debugger
> fault handler hook which calls longjmp unconditionally.
>
> This first part of kdump
On Tue, 2010-05-11 at 12:27 +1000, Anton Blanchard wrote:
> I saw this in a kdump kernel:
>
> IOMMU table initialized, virtual merging enabled
> Interrupt 155954 (real) is invalid, disabling it.
> Interrupt 155953 (real) is invalid, disabling it.
>
> ie we took some spurious interrupts.
OK, but
I saw this in a kdump kernel:
IOMMU table initialized, virtual merging enabled
Interrupt 155954 (real) is invalid, disabling it.
Interrupt 155953 (real) is invalid, disabling it.
ie we took some spurious interrupts. default_machine_crash_shutdown tries
to disable all interrupt sources but uses c
We wrap the crash_shutdown_handles[] calls with longjmp/setjmp, so if any
of them fault we can recover. The problem is we add a hook to the debugger
fault handler hook which calls longjmp unconditionally.
This first part of kdump is run before we marshall the other CPUs, so there
is a very good c
With sparse irqs we have to check if we have a descriptor before dereferencing
it.
Signed-off-by: Anton Blanchard
---
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 6f4613d..5182439 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -375,
If we take an EEH early enough, we oops:
Call Trace:
[c00010483770] [c0013ee4] .show_stack+0xd8/0x218 (unreliable)
[c00010483850] [c0658940] .dump_stack+0x28/0x3c
[c000104838d0] [c0057a68] .eeh_dn_check_failure+0x2b8/0x304
[c00010483990] [c00259c8]
Hi Ben, we ran into an issue where it looks like we're not
properly ignoring a pci device with a non-good status property
when we walk the device tree and create our device nodes.
However, the EEH init code does look for the property and
disables EEH on these devices. This leaves us in an
incon
On 05/10/2010 09:37 AM, Brian King wrote:
>
>>> }
>>> #else /* CONFIG_PPC_PSERIES */
>>> static int rtas_ibm_suspend_me(struct rtas_args *args)
>>> {
>>> return -ENOSYS;
>>> }
>>> +
>>> +int rtas_suspend_cpu(struct rtas_suspend_me_data *data)
>>> +{
>>> + return -ENOSYS;
>>> +}
>>> +
>>
Adds support for suspend/resume for VIO devices. This is needed for
support for HMC initiated hibernation.
Signed-off-by: Brian King
---
arch/powerpc/kernel/vio.c |1 +
1 file changed, 1 insertion(+)
diff -puN arch/powerpc/kernel/vio.c~powerpc_vio_bus_pm arch/powerpc/kernel/vio.c
--- linu
Partition hibernation will use some of the same code as is
currently used for Live Partition Migration. This function
further abstracts this code such that code outside of rtas.c
can utilize it. It also changes the error field in the suspend
me data structure to be an atomic type, since it is set
Enables support for HMC initiated partition hibernation. This is
a firmware assisted hibernation, since the firmware handles writing
the memory out to disk, along with other partition information,
so we just mimic suspend to ram.
Signed-off-by: Brian King
---
arch/powerpc/Kconfig
On Mon, May 10, 2010 at 6:25 PM, Greg KH wrote:
> On Mon, May 10, 2010 at 12:04:30AM +0200, Grant Likely wrote:
>> Greg, I can either pick this up and push it out to Linus tomorrow, or
>> let you do it. Whichever you prefer. Let me know so I don't cause
>> conflicts in your tree.
>
> I have 2 ot
Fix legacy PCI-E interrupt mapping for PCI-E slot 0 of
P2020DS evaluation board. The patch is based on P2020DS
device tree from Freescale BSP for this board.
Signed-off-by: Felix Radensky
---
arch/powerpc/boot/dts/p2020ds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
dif
On Mon, May 10, 2010 at 12:04:30AM +0200, Grant Likely wrote:
> On Wed, May 5, 2010 at 12:18 AM, Anatolij Gustschin wrote:
> > Commit 6acc6833510db8f72b5ef343296d97480555fda9
> > introduced NULL pointer dereference and kernel crash
> > on ppc32 machines while booting. Fix this bug now.
> >
> > Rep
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski
---
drivers/hwmon/tmp421.c | 42 ++
1
On 05/10/2010 01:48 AM, Michael Ellerman wrote:
> On Fri, 2010-05-07 at 13:58 -0500, Brian King wrote:
>> diff -puN /dev/null arch/powerpc/platforms/pseries/suspend.c
>> --- /dev/null2009-12-15 17:58:07.0 -0600
>> +++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/suspend.c
On Sun, 2010-05-09 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2010-05-09 at 08:59 +0200, Sam Ravnborg wrote:
> > >From ff056c080d2b0b93bac07ad71125fee701919f5e Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg
> > Date: Sun, 9 May 2010 08:52:31 +0200
> > Subject: [PATCH] powerpc: fix us
On 05/09/2010 09:35 PM, Michael Ellerman wrote:
> On Fri, 2010-05-07 at 13:58 -0500, Brian King wrote:
>> Adds support for suspend/resume for VIO devices. This is needed for
>> support for HMC initiated hibernation.
>>
>> Signed-off-by: Brian King
>> ---
>>
>> arch/powerpc/kernel/vio.c | 24 +++
get.org get.opt switch.opt
slots[7].len=32768 278379 66398 64024
slots[8].len=32768 181246 270 160
slots[7].len=32768 263961 64673 64494
slots[8].len=32768 181655 265 160
slots[7].len=32768 263736 64701 64610
slots[8].len=32768 182785 267 160
slots[7].len=32768 260925 65360 65042
slots[8].len=
(2010/05/06 22:38), Arnd Bergmann wrote:
On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
Date:
Yesterday 04:59:24
That's why the bitmaps are defined as little endian u64 aligned, even on
big endian 32-bit systems. Little endian bitmaps are wordsize agnostic,
and u64 alignment ensures we can
Yes, I'm just using in kernel space: qemu has its own endian related helpers.
So if you allow us to place this macro in asm-generic/bitops/* it will help us.
No problem at all then. Thanks for the explanation.
Acked-by: Arnd Bergmann
Thanks you both. I will add your Acked-by from now on!
On 05/04/2010 03:56 PM, Takuya Yoshikawa wrote:
[Performance test]
We measured the tsc needed to the ioctl()s for getting dirty logs in
kernel.
Test environment
AMD Phenom(tm) 9850 Quad-Core Processor with 8GB memory
1. GUI test (running Ubuntu guest in graphical mode)
sudo qemu-syste
On Monday 10 May 2010, Takuya Yoshikawa wrote:
> (2010/05/06 22:38), Arnd Bergmann wrote:
> > On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
> >> There was a suggestion to propose set_le_bit_user() kind of macros.
> >> But what I thought was these have a constraint you two explained and
> >> se
On 05/10/2010 02:46 PM, Takuya Yoshikawa wrote:
(2010/05/06 22:38), Arnd Bergmann wrote:
On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
Date:
Yesterday 04:59:24
That's why the bitmaps are defined as little endian u64 aligned,
even on
big endian 32-bit systems. Little endian bitmaps are wor
On Mon, May 10, 2010 at 02:55:03PM +1000, Michael Neuling wrote:
>
>
> In message <4be78e06.6080...@ozlabs.org> you wrote:
> >
> > ppc64's fs2dt used to use a fixed-size array into which the device tree
> > was parsed. There was no bounds checking, so with a large device tree other
> > heap dat
34 matches
Mail list logo
