* [PATCH] powerpc: don't use kernel stack with translation off
From: Michael Neuling @ 2010-08-26 7:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, stable, Matt Evans
In f761622e59433130bc33ad086ce219feee9eb961 we changed
early_setup_secondary so it's called using the proper kernel stack
rather than the emergency one.
Unfortunately, this stack pointer can't be used when translation is off
on PHYP as this stack pointer might be outside the RMO. This results in
the following on all non zero cpus:
cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10]
pc: 000000000001c50c
lr: 000000000000821c
sp: c00000001639ff90
msr: 8000000000001000
dar: c00000001639ffa0
dsisr: 42000000
current = 0xc000000016393540
paca = 0xc000000006e00200
pid = 0, comm = swapper
The original patch was only tested on bare metal system, so it never
caught this problem.
This changes __secondary_start so that we calculate the new stack
pointer but only start using it after we've called early_setup_secondary.
With this patch, the above problem goes away.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
benh: can you pick this up for 2.6.36 as we are bust currently in Linus' tree.
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 4d6681d..c571cd3 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -575,13 +575,19 @@ __secondary_start:
/* Initialize the kernel stack. Just a repeat for iSeries. */
LOAD_REG_ADDR(r3, current_set)
sldi r28,r24,3 /* get current_set[cpu#] */
- ldx r1,r3,r28
- addi r1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD
- std r1,PACAKSAVE(r13)
+ ldx r14,r3,r28
+ addi r14,r14,THREAD_SIZE-STACK_FRAME_OVERHEAD
+ std r14,PACAKSAVE(r13)
/* Do early setup for that CPU (stab, slb, hash table pointer) */
bl .early_setup_secondary
+ /*
+ * setup the new stack pointer, but *don't* use this until
+ * translation is on.
+ */
+ mr r1, r14
+
/* Clear backchain so we get nice backtraces */
li r7,0
mtlr r7
^ permalink raw reply related
* Re: [PATCH] powerpc: Wire up direct socket system calls
From: Ian Munsie @ 2010-08-26 5:56 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Andreas Schwab, Christoph Hellwig,
Arjan van de Ven, Jesper Nilsson, linuxppc-dev
In-Reply-To: <1282798228-340-1-git-send-email-imunsie@au1.ibm.com>
Excerpts from Ian Munsie's message of Thu Aug 26 14:50:28 +1000 2010:
> This patch wires up the various socket system calls on PowerPC so that
> userspace can call them directly, rather than by going through the
> multiplexed socketcall system call.
I should have mentioned that the base is ppc/next
Also, I've included a simple library below suitable for use with
LD_PRELOAD to allow this to be tested on existing programs.
Cheers,
-Ian
#include <unistd.h>
#include <sys/syscall.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
/* PPC syscall numbers from /arch/powerpc/include/asm/unistd.h */
#define __NR_socket 326
#define __NR_bind 327
#define __NR_connect 328
#define __NR_listen 329
#define __NR_accept 330
#define __NR_getsockname 331
#define __NR_getpeername 332
#define __NR_socketpair 333
#define __NR_send 334
#define __NR_sendto 335
#define __NR_recv 336
#define __NR_recvfrom 337
#define __NR_shutdown 338
#define __NR_setsockopt 339
#define __NR_getsockopt 340
#define __NR_sendmsg 341
#define __NR_recvmsg 342
#define __NR_recvmmsg 343
#define __NR_accept4 344
#define DEBUG 0
#if DEBUG
#define DEBUGsyscall(name, ...) \
int __ret; \
__ret = syscall(__NR_##name, __VA_ARGS__); \
fprintf(stderr, "--"#name": %i", __ret); \
if (__ret == -1) { \
fprintf(stderr, ", %s (%i)", strerror(errno), errno); \
} \
fprintf(stderr, "--\n"); \
return __ret;
#else
#define DEBUGsyscall(name, ...) \
return syscall(__NR_##name, __VA_ARGS__);
#endif
int socket(int domain, int type, int protocol)
{
DEBUGsyscall(socket, domain, type, protocol);
}
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
DEBUGsyscall(bind, sockfd, addr, addrlen);
}
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
DEBUGsyscall(connect, sockfd, addr, addrlen);
}
int listen(int sockfd, int backlog)
{
DEBUGsyscall(listen, sockfd, backlog);
}
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
{
DEBUGsyscall(accept, sockfd, addr, addrlen);
}
int getsockname(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
{
DEBUGsyscall(getsockname, sockfd, addr, addrlen);
}
int getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
{
DEBUGsyscall(getpeername, sockfd, addr, addrlen);
}
int socketpair(int domain, int type, int protocol, int sv[2])
{
DEBUGsyscall(socketpair, domain, type, protocol, sv);
}
int send(int sockfd, const void *buf, size_t len, int flags)
{
DEBUGsyscall(send, sockfd, buf, len, flags);
}
int sendto(int sockfd, const void *buf, size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen)
{
DEBUGsyscall(sendto, sockfd, buf, len, flags, dest_addr, addrlen);
}
int recv(int sockfd, void *buf, size_t len, int flags)
{
DEBUGsyscall(recv, sockfd, buf, len, flags);
}
int recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen)
{
DEBUGsyscall(recvfrom, sockfd, buf, len, flags, src_addr, addrlen);
}
int shutdown(int sockfd, int how)
{
DEBUGsyscall(shutdown, sockfd, how);
}
int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen)
{
DEBUGsyscall(setsockopt, sockfd, level, optname, optval, optlen);
}
int getsockopt(int sockfd, int level, int optname, void *optval, socklen_t *optlen)
{
DEBUGsyscall(getsockopt, sockfd, level, optname, optval, optlen);
}
int sendmsg(int sockfd, const struct msghdr *msg, int flags)
{
DEBUGsyscall(sendmsg, sockfd, msg, flags);
}
int recvmsg(int sockfd, struct msghdr *msg, int flags)
{
DEBUGsyscall(recvmsg, sockfd, msg, flags);
}
/* Debian squeeze libc doesn't support recvmmsg yet, not much point intercepting it */
int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags)
{
DEBUGsyscall(accept4, sockfd, addr, addrlen, flags);
}
^ permalink raw reply
* [PATCH] powerpc: Wire up direct socket system calls
From: Ian Munsie @ 2010-08-26 4:50 UTC (permalink / raw)
To: linux-kernel
Cc: Jesper Nilsson, linuxppc-dev, Andreas Schwab, Ian Munsie,
Paul Mackerras, Andrew Morton, Arjan van de Ven,
Christoph Hellwig
From: Ian Munsie <imunsie@au1.ibm.com>
This patch wires up the various socket system calls on PowerPC so that
userspace can call them directly, rather than by going through the
multiplexed socketcall system call.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
arch/powerpc/include/asm/systbl.h | 19 +++++++++++++++++++
arch/powerpc/include/asm/unistd.h | 21 ++++++++++++++++++++-
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index 3d21266..aa0f1eb 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -329,3 +329,22 @@ COMPAT_SYS(rt_tgsigqueueinfo)
SYSCALL(fanotify_init)
COMPAT_SYS(fanotify_mark)
SYSCALL_SPU(prlimit64)
+SYSCALL_SPU(socket)
+SYSCALL_SPU(bind)
+SYSCALL_SPU(connect)
+SYSCALL_SPU(listen)
+SYSCALL_SPU(accept)
+SYSCALL_SPU(getsockname)
+SYSCALL_SPU(getpeername)
+SYSCALL_SPU(socketpair)
+SYSCALL_SPU(send)
+SYSCALL_SPU(sendto)
+COMPAT_SYS_SPU(recv)
+COMPAT_SYS_SPU(recvfrom)
+SYSCALL_SPU(shutdown)
+COMPAT_SYS_SPU(setsockopt)
+COMPAT_SYS_SPU(getsockopt)
+COMPAT_SYS_SPU(sendmsg)
+COMPAT_SYS_SPU(recvmsg)
+COMPAT_SYS_SPU(recvmmsg)
+SYSCALL_SPU(accept4)
diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index 597e6f9..6151937 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -348,10 +348,29 @@
#define __NR_fanotify_init 323
#define __NR_fanotify_mark 324
#define __NR_prlimit64 325
+#define __NR_socket 326
+#define __NR_bind 327
+#define __NR_connect 328
+#define __NR_listen 329
+#define __NR_accept 330
+#define __NR_getsockname 331
+#define __NR_getpeername 332
+#define __NR_socketpair 333
+#define __NR_send 334
+#define __NR_sendto 335
+#define __NR_recv 336
+#define __NR_recvfrom 337
+#define __NR_shutdown 338
+#define __NR_setsockopt 339
+#define __NR_getsockopt 340
+#define __NR_sendmsg 341
+#define __NR_recvmsg 342
+#define __NR_recvmmsg 343
+#define __NR_accept4 344
#ifdef __KERNEL__
-#define __NR_syscalls 326
+#define __NR_syscalls 345
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Christian Riesch @ 2010-08-25 9:40 UTC (permalink / raw)
To: john stultz
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, Richard Cochran, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <1282594125.3111.344.camel@localhost.localdomain>
On Mon, Aug 23, 2010 at 10:08 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
>> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
>> > Again, my knowledge in the networking stack is pretty limited. But it
>> > would seem that having an interface that does something to the effect =
of
>> > "adjust the timestamp clock on the hardware that generated it from thi=
s
>> > packet by Xppb" would feel like the right level of abstraction. Its
>> > closely related to SO_TIMESTAMP, option right? Would something like
>> > using the setsockopt/getsockopt interface with
>> > SO_TIMESTAMP_ADJUST/OFFSET/SET/etc be reasonable?
>>
>> The clock and its adjustment have nothing to do with a network
>> socket. The current PTP hacks floating around all add private ioctls
>> to the MAC driver. That is the *wrong* way to do it.
>
> Could you clarify on *why* that is the wrong approach?
>
> Maybe this is where some of the confusion is coming from? The subtleties
> of the more generic PTP algorithm and how the existence of PTP hardware
> clocks change things are not clear to me. My understanding of ptp and
> the networking details around it is limited, so your expertise is
> appreciated. =C2=A0Might you consider covering some of this via a
> Documentation/ptp/overview.txt file in a future version of your patch?
>
> Here's a summary of what I understand:
> So from:
> http://en.wikipedia.org/wiki/Precision_Time_Protocol#Synchronization
>
> We see the message exchange of Sync/Delay_Req/Delay_Resp, and the
> calculation of the local offset from the server (and then a frequency
> adjustment over time as offsets values are accumulated).
>
> Without the hardware clock, this all of these messages and their
> corresponding timestamps are likely created by PTPd, using clock_gettime
> and then adjtimex() to correct for the calculated offset or freq
> adjustment. No extra interfaces are necessary, and PTPd is syncing the
> system time as accurately as it can. This is how the existing ptpd
> projects on the web seem to function.
>
> Now, with PTP hardware on the system, my understanding of what you're
> trying to enable with your patches is that the PTP hardware does the
> timestamping on both incoming and outgoing messages. PTPd then reads the
> pre-timestamped messages, calculates the offset and freq correction, and
> then feeds that back into the PTP hardware via your interface. No time
> correction is done at all by PTPd.
John,
What you describe here is only one of the use cases. If the hardware
has a single network port and operates as a PTP slave, it timestamps
the PTP packets that are sent and received and subsequently uses these
timestamps and the information it received from the master in the
packets to steer its clock to align it with the master clock. In such
a case the timestamping hardware and the clock hardware work together
closely and it seems to be okay to use the same interface to control
both the timestamping and the PTP clock.
But we have to consider other use cases, e.g.,
1) Boundary clocks:
We have more than one network port. One port operates as a slave
clock, our system gets time information via this port and steers its
PTP clock to align with the master clock. The other network ports of
our system operate as master clocks and redistribute the time
information we got from the master to other clocks on these networks.
In such a case we do timestamping on each of the network ports, but we
only have a single PTP clock. Each network port's timestamping
hardware uses the same hardware clock to generate time stamps.
2) Master clock:
We have one or more network ports. Our system has a really good clock
(ovenized quartz crystal, an atomic clock, a GPS timing receiver...)
and it distributes this time on the network. In such a case we do not
steer our clock based on the (packet) timestamps we get from our
timestamping unit. Instead, we directly drive our clock hardware with
a very stable frequency that we get from the OCXO or the atomic
clock... or we use one of the ancillary features of the PTP clock that
Richard mentioned to timestamp not network packets but a 1pps signal
and use these timestamps to steer the clock. Packet time stamping is
used to distribute the time to the slaves, but it is not part of the
control loop in this case.
So in the first case we have one PTP clock but several network packet
timestamping units, whereas in the second case the packet timestamping
is done but it is not part of the control loop that steers the clock.
Of course in most hardware implementations both the PTP clock and the
timestamping unit sit on the same chip and often use the same means of
communication to the cpu, e.g., the MDIO bus, but I think we need some
logical separation here.
Christian
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Eric W. Biederman @ 2010-08-25 0:37 UTC (permalink / raw)
To: Anton Blanchard; +Cc: akpm, kexec, linux-kernel, linuxppc-dev
In-Reply-To: <20100825002258.GD28360@kryten>
Anton Blanchard <anton@samba.org> writes:
> On ppc64 the crashkernel region almost always overlaps an area of firmware.
> This works fine except when using the sysfs interface to reduce the kdump
> region. If we free the firmware area we are guaranteed to crash.
That is ppc64 bug. firmware should not be in the reserved region. Any
random kernel like thing can be put in to that region at any valid
address and the fact that shrinking the region frees your firmware means
that using that region could also stomp your firmware (which I assume
would be a bad thing).
So please fix the ppc64 reservation.
Eric
^ permalink raw reply
* Re: [PATCH] powerpc: Check end of stack canary at oops time
From: Anton Blanchard @ 2010-08-25 1:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1282699778.21145.54.camel@concordia>
Hi,
> The check for init is just because we haven't set the magic value for
> init's stack right? But we could.
Yeah, it's similar to what x86 are doing now:
commit 0e7810be30f66e9f430c4ce2cd3b14634211690f
Author: Jan Beulich <JBeulich@novell.com>
Date: Fri Nov 20 14:00:14 2009 +0000
x86: Suppress stack overrun message for init_task
init_task doesn't get its stack end location set to
STACK_END_MAGIC, and hence the message is confusing
rather than helpful in this case.
Adding it directly to init_task would be nice but I suspect we'd
either have to make assumptions about end_of_stack in our code or move the
canary into the thread_info (so we can statically allocate it via
INIT_THREAD_INFO()) or do it at runtime somewhere, hopefully early enough that
we couldn't take an oops.
Anton
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-25 1:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <1282699836.22370.566.camel@pasglop>
In message <1282699836.22370.566.camel@pasglop> you wrote:
> On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote:
> > > > Do some 32 bit processors need this?
> > > >
> > > > In 32 bit before the merge, we use to have code that did:
> > > >
> > > > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > > > #define cvt_fd without save/restore fpscr
> > > > #else
> > > > #define cvt_fd with save/restore fpscr
> > > > #end if
> > > >
> > > > Kumar; does this ring any bells?
> > >
> > > I don't see anything in the various 440 docs I have at hand that would
> > > hint at lfd/stfs adffecting FPSCR.
> >
> > The way the ifdefs are, it's the other way around. 4xx procs don't need
> > to save/restore fpscr and others do.
>
> Right, my bad. In any case, Paulus reckons it's all his mistake and we
> really never need to save/restore fpscr.
ACK :-P
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Benjamin Herrenschmidt @ 2010-08-25 1:30 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <32250.1282626925@neuling.org>
On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote:
> > > Do some 32 bit processors need this?
> > >
> > > In 32 bit before the merge, we use to have code that did:
> > >
> > > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > > #define cvt_fd without save/restore fpscr
> > > #else
> > > #define cvt_fd with save/restore fpscr
> > > #end if
> > >
> > > Kumar; does this ring any bells?
> >
> > I don't see anything in the various 440 docs I have at hand that would
> > hint at lfd/stfs adffecting FPSCR.
>
> The way the ifdefs are, it's the other way around. 4xx procs don't need
> to save/restore fpscr and others do.
Right, my bad. In any case, Paulus reckons it's all his mistake and we
really never need to save/restore fpscr.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Check end of stack canary at oops time
From: Michael Ellerman @ 2010-08-25 1:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100824231528.GC28360@kryten>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Wed, 2010-08-25 at 09:15 +1000, Anton Blanchard wrote:
> Add a check for the stack canary when we oops, similar to x86. This should make
> it clear that we overran our stack:
>
> Unable to handle kernel paging request for data at address 0x24652f63700ac689
> Faulting instruction address: 0xc000000000063d24
> Thread overran stack, or stack corrupted
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/mm/fault.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/mm/fault.c 2010-08-25 08:41:08.230086186 +1000
> +++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103 +1000
> @@ -30,6 +30,7 @@
> #include <linux/kprobes.h>
> #include <linux/kdebug.h>
> #include <linux/perf_event.h>
> +#include <linux/magic.h>
>
> #include <asm/firmware.h>
> #include <asm/page.h>
> @@ -385,6 +386,7 @@ do_sigbus:
> void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
> {
> const struct exception_table_entry *entry;
> + unsigned long *stackend;
>
> /* Are we prepared to handle this fault? */
> if ((entry = search_exception_tables(regs->nip)) != NULL) {
> @@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
> printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
> regs->nip);
>
> + stackend = end_of_stack(current);
> + if (current != &init_task && *stackend != STACK_END_MAGIC)
> + printk(KERN_ALERT "Thread overran stack, or stack corrupted\n");
The check for init is just because we haven't set the magic value for
init's stack right? But we could.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 2/2] powerpc: kdump: Override crash_free_reserved_phys_range to avoid freeing RTAS
From: Anton Blanchard @ 2010-08-25 0:23 UTC (permalink / raw)
To: benh, ebiederm, akpm; +Cc: linuxppc-dev, kexec, linux-kernel
In-Reply-To: <20100825002258.GD28360@kryten>
The crashkernel region will almost always overlap RTAS. If we free the
crashkernel region via "echo 0 > /sys/kernel/kexec_crash_size" then we will
free RTAS and the machine will crash in confusing and exciting ways.
Override crash_free_reserved_phys_range and check for overlap with RTAS.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/crash_dump.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/crash_dump.c 2010-08-24 09:24:32.219643256 +1000
+++ powerpc.git/arch/powerpc/kernel/crash_dump.c 2010-08-24 09:46:22.826868330 +1000
@@ -19,6 +19,7 @@
#include <asm/prom.h>
#include <asm/firmware.h>
#include <asm/uaccess.h>
+#include <asm/rtas.h>
#ifdef DEBUG
#include <asm/udbg.h>
@@ -141,3 +142,35 @@ ssize_t copy_oldmem_page(unsigned long p
return csize;
}
+
+#ifdef CONFIG_PPC_RTAS
+/*
+ * The crashkernel region will almost always overlap the RTAS region, so
+ * we have to be careful when shrinking the crashkernel region.
+ */
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end)
+{
+ unsigned long addr;
+ const u32 *basep, *sizep;
+ unsigned int rtas_start = 0, rtas_end = 0;
+
+ basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
+ sizep = of_get_property(rtas.dev, "rtas-size", NULL);
+
+ if (basep && sizep) {
+ rtas_start = *basep;
+ rtas_end = *basep + *sizep;
+ }
+
+ for (addr = begin; addr < end; addr += PAGE_SIZE) {
+ /* Does this page overlap with the RTAS region? */
+ if (addr <= rtas_end && ((addr + PAGE_SIZE) > rtas_start))
+ continue;
+
+ ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
+ init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+ free_page((unsigned long)__va(addr));
+ totalram_pages++;
+ }
+}
+#endif
^ permalink raw reply
* [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Anton Blanchard @ 2010-08-25 0:22 UTC (permalink / raw)
To: benh, ebiederm, akpm; +Cc: linuxppc-dev, kexec, linux-kernel
On ppc64 the crashkernel region almost always overlaps an area of firmware.
This works fine except when using the sysfs interface to reduce the kdump
region. If we free the firmware area we are guaranteed to crash.
Rename free_reserved_phys_range to crash_free_reserved_phys_range and make
it a weak function so we can override it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/kernel/kexec.c
===================================================================
--- powerpc.git.orig/kernel/kexec.c 2010-08-25 10:12:11.493863566 +1000
+++ powerpc.git/kernel/kexec.c 2010-08-25 10:12:35.907264327 +1000
@@ -1097,7 +1097,8 @@ size_t crash_get_memory_size(void)
return size;
}
-static void free_reserved_phys_range(unsigned long begin, unsigned long end)
+void __weak crash_free_reserved_phys_range(unsigned long begin,
+ unsigned long end)
{
unsigned long addr;
@@ -1133,7 +1134,7 @@ int crash_shrink_memory(unsigned long ne
start = roundup(start, PAGE_SIZE);
end = roundup(start + new_size, PAGE_SIZE);
- free_reserved_phys_range(end, crashk_res.end);
+ crash_free_reserved_phys_range(end, crashk_res.end);
if ((start == end) && (crashk_res.parent != NULL))
release_resource(&crashk_res);
Index: powerpc.git/include/linux/kexec.h
===================================================================
--- powerpc.git.orig/include/linux/kexec.h 2010-08-25 10:12:11.483862172 +1000
+++ powerpc.git/include/linux/kexec.h 2010-08-25 10:12:13.664166570 +1000
@@ -208,6 +208,7 @@ int __init parse_crashkernel(char *cmdli
unsigned long long *crash_size, unsigned long long *crash_base);
int crash_shrink_memory(unsigned long new_size);
size_t crash_get_memory_size(void);
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
#else /* !CONFIG_KEXEC */
struct pt_regs;
^ permalink raw reply
* [PATCH] powerpc: Check end of stack canary at oops time
From: Anton Blanchard @ 2010-08-24 23:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Add a check for the stack canary when we oops, similar to x86. This should make
it clear that we overran our stack:
Unable to handle kernel paging request for data at address 0x24652f63700ac689
Faulting instruction address: 0xc000000000063d24
Thread overran stack, or stack corrupted
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/mm/fault.c
===================================================================
--- powerpc.git.orig/arch/powerpc/mm/fault.c 2010-08-25 08:41:08.230086186 +1000
+++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103 +1000
@@ -30,6 +30,7 @@
#include <linux/kprobes.h>
#include <linux/kdebug.h>
#include <linux/perf_event.h>
+#include <linux/magic.h>
#include <asm/firmware.h>
#include <asm/page.h>
@@ -385,6 +386,7 @@ do_sigbus:
void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
{
const struct exception_table_entry *entry;
+ unsigned long *stackend;
/* Are we prepared to handle this fault? */
if ((entry = search_exception_tables(regs->nip)) != NULL) {
@@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
regs->nip);
+ stackend = end_of_stack(current);
+ if (current != &init_task && *stackend != STACK_END_MAGIC)
+ printk(KERN_ALERT "Thread overran stack, or stack corrupted\n");
+
die("Kernel access of bad area", regs, sig);
}
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
From: Brian King @ 2010-08-24 21:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1282627487.22370.508.camel@pasglop>
On 08/24/2010 12:24 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
>> While testing CPU DLPAR, the following problem was discovered.
>> We were DLPAR removing the first CPU, which in this case was
>> logical CPUs 0-3. CPUs 0-2 were already marked offline and
>> we were in the process of offlining CPU 3. After marking
>> the CPU inactive and offline in cpu_disable, but before the
>> cpu was completely idle (cpu_die), we ended up in __make_request
>> on CPU 3. There we looked at the topology map to see which CPU
>> to complete the I/O on and found no CPUs in the cpu_sibling_map.
>> This resulted in the block layer setting the completion cpu
>> to be NR_CPUS, which then caused an oops when we tried to
>> complete the I/O.
>>
>> Fix this by delaying clearing the sibling map of the cpu we
>> are offlining for the cpu we are offlining until cpu_die.
>
> So I'm not getting a clear mental picture of the situation, sorry about
> that.
>
> We are offlining CPU 3, and we have already marked it inactive and
> online, so how come we end up in __make_request() on it at this stage
I'm not sure about that. My thought was that until we get into cpu_die,
the cpu could still be executing code.
> and shouldn't it be the block layer that notices that it's targeting an
> offlined CPU ?
It could be easily fixed in blk_cpu_to_group as well. I'll look into
this.
> IE. I have doubts about leaving a CPU in the sibling map which isn't
> online... Wouldn't we end up "scheduling" things to it after it's
> supposed to have freed itself of everything (timers, workqueues,
> etc...) ?
I was assuming this wouldn't happen since the cpu is no longer online.
Thanks,
Brian
>
> As I said, I'm probably missing a part of the puzzle ..
>
> Ben.
>
>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>> ---
>>
>> arch/powerpc/kernel/smp.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline arch/powerpc/kernel/smp.c
>> --- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline 2010-08-09 16:49:47.000000000 -0500
>> +++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09 16:49:47.000000000 -0500
>> @@ -598,8 +598,11 @@ int __cpu_disable(void)
>> /* Update sibling maps */
>> base = cpu_first_thread_in_core(cpu);
>> for (i = 0; i < threads_per_core; i++) {
>> - cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
>> - cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
>> + if ((base + i) != cpu) {
>> + cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
>> + cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
>> + }
>> +
>> cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
>> cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
>> }
>> @@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
>>
>> void cpu_die(void)
>> {
>> + cpumask_clear_cpu(smp_processor_id(), cpu_sibling_mask(smp_processor_id()));
>> +
>> if (ppc_md.cpu_die)
>> ppc_md.cpu_die();
>> }
>> _
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Stephan Gatzka @ 2010-08-24 18:30 UTC (permalink / raw)
To: john stultz
Cc: Arnd Bergmann, netdev, Richard Cochran, linuxppc-dev,
linux-kernel, Rodolfo Giometti, devicetree-discuss,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <1282594125.3111.344.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
Hello!
> I'm curious if its possible to do the PTP hardware offset/adjustment
> calculation in a module internally to the kernel? That would allow the
> PPS interface to still be used to sync the system time, and not expose
> additional interfaces.
Just my 2 cents on this issue. PTP is very often used in embedded
systems, where the PTP timestamps will go into some dedicated hardware,
for instance an FPGA.
I'm currently working on a project where it is not necessary to adjust
the Linux system time via PTP (although it would be a nice to have), but
we only need the timestamps from the PHY to put them into our FPGA
device. So we need some kind of API to access the PTP timestamp registers.
Kind regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5136 bytes --]
^ permalink raw reply
* Re: 64-bit ppc rwsem
From: Arnd Bergmann @ 2010-08-24 12:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, paulus, linux-kernel, sparclinux, akpm, torvalds,
David Miller
In-Reply-To: <1282613477.22370.485.camel@pasglop>
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote:
> > > I've seen drivers in the past do trylocks at interrupt time ... tho
> > I
> > > agree it sucks.
> >
> > Recently there was a thread where this was declared absolutely
> > illegal.
> >
> > Maybe it was allowed, or sort-of worked before, and that's why it's
> > accounted for with IRQ disables in some implementations. I don't
> > know.
>
> Ok, I'm happy to say it's a big no-no then.
>
> Arnd, do you want to take over the moving to asm-generic and take care
> of the spinlock case as well ? I can send Linus the first patch that
> changes powerpc to use atomic_long now along with a few other things I
> have pending, then you can pickup from there. Or do you want me to
> continue pushing my patch as-is and we can look at cleaning up the
> spinlock case separately ?
I'm currently doing too many things at once, please push in your existing
patch for now, we can continue from there.
For the asm-generic patch:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB case
From: Anton Vorontsov @ 2010-08-24 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Andrew Morton
Cc: David Brownell, linuxppc-dev, linux-kernel
In-Reply-To: <1282631168.22370.517.camel@pasglop>
With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared,
so the following pops up on PowerPC:
cc1: warnings being treated as errors
In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared
inside parameter list
include/linux/of_gpio.h:74: warning: its scope is only this definition
or declaration, which is probably not what
you want
include/linux/of_gpio.h:75: warning: 'struct gpio_chip' declared
inside parameter list
make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1
This patch fixes the issue by providing the proper forward declaration.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
On Tue, Aug 24, 2010 at 04:26:08PM +1000, Benjamin Herrenschmidt wrote:
> I get that with my current stuff:
>
> cc1: warnings being treated as errors
> In file included from [..]/mpc52xx_common.c:19:
> of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list
[...]
> make[3]: *** Waiting for unfinished jobs....
That's because with GPIOCHIP=n no one declares struct gpio_chip.
It should be either of_gpio.h or gpio.h. Let's make it gpio.h, as
this feels more generic, and we already have some !GPIOLIB handling
in there.
include/linux/gpio.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 03f616b..85207d2 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -15,6 +15,12 @@
struct device;
/*
+ * Some code might rely on the declaration. Still, it is illegal
+ * to dereference it for !GPIOLIB case.
+ */
+struct gpio_chip;
+
+/*
* Some platforms don't support the GPIO programming interface.
*
* In case some driver uses it anyway (it should normally have
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
From: Arnd Bergmann @ 2010-08-24 7:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linuxppc-dev, Andreas Schwab, Arnd Bergmann, linuxppc-dev
In-Reply-To: <1282631584.22370.523.camel@pasglop>
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> > On Friday 20 August 2010, Andreas Schwab wrote:
> > > See arch/powerpc/platforms/cell/spu_callbacks.c.
> > >
> > > * 4. They are optional and we can't rely on them being
> > > * linked into the kernel. Unfortunately, the cond_syscall
> > > * helper does not work here as it does not add the necessary
> > > * opd symbols:
> >
> > Right. I should blame the person that wrote this comment.
> > If only I could remember who that was.
>
> Regardless of the outcome of that, I'm merging Andreas patch. We can
> always add SPU bindings if we feel like it later.
Sorry, I should have added a ';-)' or been clearer. The patch is good,
I wrote the comment that Andreas quoted and it's probably my own fault
that we never found a way to handle syscalls like this correctly from
the SPU.
Arnd
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-08-24 6:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a few powerpc bits & fixes for 2.6.36, some of them for some of
the new stuff that went in, along with the powerpc rwsem update to
atomic_long_t (not yet moved to asm-generic) and wiring up of some new
syscalls.
Cheers,
Ben.
The following changes since commit d1b113bb028999e82a8528e1484be8c23fb5a7d9:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git master
Anatolij Gustschin (1):
powerpc: Fix typo in uImage target
Andreas Schwab (3):
powerpc: Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
via-pmu: Add compat_pmu_ioctl
powerpc: Fix config dependency problem with MPIC_U3_HT_IRQS
Anton Blanchard (4):
powerpc/mm: Fix vsid_scrample typo
powerpc/kdump: Stop all other CPUs before running crash handlers
powerpc: Inline ppc64_runlatch_off
powerpc: Fix bogus it_blocksize in VIO iommu code
Benjamin Herrenschmidt (2):
Merge remote branch 'jwb/merge' into merge
powerpc: Make rwsem use "long" type
Dave Kleikamp (4):
powerpc/47x: Make sure mcsr is cleared before enabling machine check interrupts
powerpc/47x: Remove redundant line from cputable.c
powerpc/4xx: Index interrupt stacks by physical cpu
powerpc/47x: Add an isync before the tlbivax instruction
Denis Kirjanov (1):
powerpc: Use is_32bit_task() helper to test 32 bit binary
Grant Likely (1):
powerpc/pci: Fix checking for child bridges in PCI code.
Julia Lawall (3):
powerpc/powermac: Drop unnecessary of_node_put
powerpc/powermac: Drop unnecessary null test
powerpc/pci: Drop unnecessary null test
Matt Evans (1):
powerpc: Initialise paca->kstack before early_setup_secondary
Nathan Fontenot (1):
powerpc: Correct smt_enabled=X boot option for > 2 threads per core
Rupjyoti Sarmah (1):
powerpc/4xx: Device tree update for the 460ex DWC SATA
Signed-off-by: Darren Hart (3):
powerpc: Re-enable preemption before cpu_die()
powerpc: Silence __cpu_up() under normal operation
powerpc: Silence xics_migrate_irqs_away() during cpu offline
Sonny Rao (1):
powerpc: Export memstart_addr and kernstart_addr on ppc64
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/dts/canyonlands.dts | 8 ++++
arch/powerpc/include/asm/mmu-hash64.h | 2 +-
arch/powerpc/include/asm/reg.h | 9 ++++-
arch/powerpc/include/asm/rwsem.h | 64 +++++++++++++++++------------
arch/powerpc/include/asm/systbl.h | 3 +
arch/powerpc/include/asm/unistd.h | 5 ++-
arch/powerpc/kernel/cputable.c | 1 -
arch/powerpc/kernel/crash.c | 24 ++++++-----
arch/powerpc/kernel/head_44x.S | 4 ++
arch/powerpc/kernel/head_64.S | 6 +-
arch/powerpc/kernel/idle.c | 2 +-
arch/powerpc/kernel/irq.c | 16 ++++---
arch/powerpc/kernel/pci_of_scan.c | 2 +-
arch/powerpc/kernel/process.c | 20 ++++-----
arch/powerpc/kernel/setup_32.c | 9 ++--
arch/powerpc/kernel/setup_64.c | 63 ++++++++++++++++------------
arch/powerpc/kernel/smp.c | 4 +-
arch/powerpc/kernel/sys_ppc32.c | 8 ++++
arch/powerpc/kernel/vio.c | 3 +-
arch/powerpc/mm/init_64.c | 2 +
arch/powerpc/mm/tlb_nohash_low.S | 1 +
arch/powerpc/platforms/Kconfig | 3 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/iseries/iommu.c | 2 +-
arch/powerpc/platforms/powermac/feature.c | 3 +-
arch/powerpc/platforms/powermac/pci.c | 2 -
arch/powerpc/platforms/pseries/iommu.c | 8 ++--
arch/powerpc/platforms/pseries/smp.c | 11 +++--
arch/powerpc/platforms/pseries/xics.c | 6 ++-
drivers/macintosh/via-pmu.c | 42 +++++++++++++++++++
31 files changed, 219 insertions(+), 118 deletions(-)
^ permalink raw reply
* Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
From: Benjamin Herrenschmidt @ 2010-08-24 6:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linuxppc-dev, Andreas Schwab, Arnd Bergmann, linuxppc-dev
In-Reply-To: <201008231552.07013.arnd@arndb.de>
On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> On Friday 20 August 2010, Andreas Schwab wrote:
> > See arch/powerpc/platforms/cell/spu_callbacks.c.
> >
> > * 4. They are optional and we can't rely on them being
> > * linked into the kernel. Unfortunately, the cond_syscall
> > * helper does not work here as it does not add the necessary
> > * opd symbols:
>
> Right. I should blame the person that wrote this comment.
> If only I could remember who that was.
Regardless of the outcome of that, I'm merging Andreas patch. We can
always add SPU bindings if we feel like it later.
Cheers,
Ben.
^ permalink raw reply
* 52xx build error
From: Benjamin Herrenschmidt @ 2010-08-24 6:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
I get that with my current stuff:
cc1: warnings being treated as errors
In file included from /home/benh/linux-powerpc-test/arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: its scope is only this definition or declaration, which is probably not what you want
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:75: error: ‘struct gpio_chip’ declared inside parameter list
CC mm/bootmem.o
make[3]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-24 5:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Andreas Schwab, kvm-ppc
In-Reply-To: <DCE42647-5931-41EF-BBE8-F09FDC700143@kernel.crashing.org>
> >> Neither lfs nor stfs touch the fpscr, so remove the restore/save of =
> it
> >> around them.
> >=20
> > Do some 32 bit processors need this?=20
> >=20
> > In 32 bit before the merge, we use to have code that did:
> >=20
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > #define cvt_fd without save/restore fpscr
> > #else
> > #define cvt_fd with save/restore fpscr
> > #end if
> >=20
> > Kumar; does this ring any bells?
> >=20
> > (The addition of this predates even bitkeeper)
> >=20
> > Mikey
>
> Not really. However if the ifdef is as you say that seems wrong to
> me. We should be using CONFIG_PPC_FPU or !CONFIG_PPC_FPU. As both
> 4xx and E500 have variants w/FPUs.
It actually got changed to CONFIG_PPC_FPU, then dwg merged it with some
other versions that were around.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Kumar Gala @ 2010-08-24 5:47 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Paul Mackerras, Andreas Schwab, kvm-ppc
In-Reply-To: <27922.1282523025@neuling.org>
On Aug 22, 2010, at 7:23 PM, Michael Neuling wrote:
>> Neither lfs nor stfs touch the fpscr, so remove the restore/save of =
it
>> around them.
>=20
> Do some 32 bit processors need this?=20
>=20
> In 32 bit before the merge, we use to have code that did:
>=20
> #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> #define cvt_fd without save/restore fpscr
> #else
> #define cvt_fd with save/restore fpscr
> #end if
>=20
> Kumar; does this ring any bells?
>=20
> (The addition of this predates even bitkeeper)
>=20
> Mikey
Not really. However if the ifdef is as you say that seems wrong to me. =
We should be using CONFIG_PPC_FPU or !CONFIG_PPC_FPU. As both 4xx and =
E500 have variants w/FPUs.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Benjamin Herrenschmidt @ 2010-08-24 5:39 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <32250.1282626925@neuling.org>
> The way the ifdefs are, it's the other way around. 4xx procs don't need
> to save/restore fpscr and others do.
Hrm, oh well, 601 manual says FPSCR is unaffected too :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
From: Benjamin Herrenschmidt @ 2010-08-24 5:24 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev
In-Reply-To: <201008112034.o7BKYvEJ013392@d03av04.boulder.ibm.com>
On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
> While testing CPU DLPAR, the following problem was discovered.
> We were DLPAR removing the first CPU, which in this case was
> logical CPUs 0-3. CPUs 0-2 were already marked offline and
> we were in the process of offlining CPU 3. After marking
> the CPU inactive and offline in cpu_disable, but before the
> cpu was completely idle (cpu_die), we ended up in __make_request
> on CPU 3. There we looked at the topology map to see which CPU
> to complete the I/O on and found no CPUs in the cpu_sibling_map.
> This resulted in the block layer setting the completion cpu
> to be NR_CPUS, which then caused an oops when we tried to
> complete the I/O.
>
> Fix this by delaying clearing the sibling map of the cpu we
> are offlining for the cpu we are offlining until cpu_die.
So I'm not getting a clear mental picture of the situation, sorry about
that.
We are offlining CPU 3, and we have already marked it inactive and
online, so how come we end up in __make_request() on it at this stage
and shouldn't it be the block layer that notices that it's targeting an
offlined CPU ?
IE. I have doubts about leaving a CPU in the sibling map which isn't
online... Wouldn't we end up "scheduling" things to it after it's
supposed to have freed itself of everything (timers, workqueues,
etc...) ?
As I said, I'm probably missing a part of the puzzle ..
Ben.
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> arch/powerpc/kernel/smp.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline arch/powerpc/kernel/smp.c
> --- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline 2010-08-09 16:49:47.000000000 -0500
> +++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09 16:49:47.000000000 -0500
> @@ -598,8 +598,11 @@ int __cpu_disable(void)
> /* Update sibling maps */
> base = cpu_first_thread_in_core(cpu);
> for (i = 0; i < threads_per_core; i++) {
> - cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
> - cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
> + if ((base + i) != cpu) {
> + cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
> + cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
> + }
> +
> cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
> cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
> }
> @@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
>
> void cpu_die(void)
> {
> + cpumask_clear_cpu(smp_processor_id(), cpu_sibling_mask(smp_processor_id()));
> +
> if (ppc_md.cpu_die)
> ppc_md.cpu_die();
> }
> _
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-24 5:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <1282626718.22370.505.camel@pasglop>
> > Do some 32 bit processors need this?
> >
> > In 32 bit before the merge, we use to have code that did:
> >
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > #define cvt_fd without save/restore fpscr
> > #else
> > #define cvt_fd with save/restore fpscr
> > #end if
> >
> > Kumar; does this ring any bells?
>
> I don't see anything in the various 440 docs I have at hand that would
> hint at lfd/stfs adffecting FPSCR.
The way the ifdefs are, it's the other way around. 4xx procs don't need
to save/restore fpscr and others do.
Mikey
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox