Anton Blanchard 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 r
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
Date: Fri Nov 20 14:00:14 2009 +
x86: Suppress stack ov
In message <1282699836.22370.566.ca...@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(CONFI
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
> > > #els
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: 0xc
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 we
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-
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: 0xc0063d24
Thread overran stack, or stack corrupted
Signed-off-b
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 an
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 i
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
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
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
> > > *
13 matches
Mail list logo