On Fri, Nov 16, 2007 at 06:21:06PM +1100, Benjamin Herrenschmidt wrote:
> This removes the old CONFIG_440A which was a pain for multiplatform
> kernel and wasn't set properly by default and replaces it with a
> CPU feature. This makes Machine Check reporting work correctly on
> my Ebony (440GP) boa
The e1000 driver stores the content of the PCI resources into
unsigned long's before ioremapping. This breaks on 32 bits
platforms that support 64 bits MMIO resources such as ppc 44x.
This fixes it by removing those temporary variables and passing
directly the result of pci_resource_start/len to i
The 32bits powerpc resource fixup code uses unsigned longs to do the
offseting of resources which overflows on platforms such as 4xx where
resources can be 64 bits.
This fixes it by using resource_size_t instead.
However, the IO stuff does rely on some 32 bits arithmetic, so we hack
by cropping t
This removes the old CONFIG_440A which was a pain for multiplatform
kernel and wasn't set properly by default and replaces it with a
CPU feature. This makes Machine Check reporting work correctly on
my Ebony (440GP) board.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Note: I'm on
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Sun, 4 Nov 2007 13:28:39 +1100
> Dave, would something like this help as an alternative to the .fixup
> change you committed recently?
I tried it, doesn't help:
kernel/built-in.o: In function `context_switch':
/home/davem/src/GIT/sparc-2.6/kernel/
On Sat, 2007-09-15 at 01:25, Josh Boyer wrote:
> On Fri, 14 Sep 2007 09:02:04 -0500
> Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote:
> >
> > > Please pull from 'for-2.6.24' branch of
> > >
> > > master.kernel.org:/pub/scm/linux/kernel/git/galak
Vaidyanathan Srinivasan writes:
> This patch fixed the problem. I am able to run and profile ebizzy on 128-way
> PPC64. However this fix is not included in 2.6.24-rc2 as well.
> I will watch for inclusion of this fix in 2.6.24.
It's upstream in Linus' tree now, so it will be in -rc3.
Paul.
___
Hi,
This sounds like a familiar problem, but could not get answers in posts
that came up in google search.
My system hangs after printing the message "Freeing unused kernel
memory". It should execute init after that, but not sure what exactly is
happening. Appreciate if some one can throw few ide
It seems, that current kernel source code contains no traces of
MAC_ADBKEYCODES and no reference to keyboard_sends_linux_keycodes any
more.
Attached patch removes them from configuration files.
Signed-off-by: Stanislav Brabec <[EMAIL PROTECTED]>
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@
Perform all error checking at the "partitonable endpoint"
of the device.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/eeh.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
Do not wait for the pci slot status before reporting an error
to the device driver. Some systems may take many seconds to
report the slot status, and this can confuse unsuspecting
device drivers.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/eeh_driver.c
If an "empty" slot is failing, make sure its a permanent failure;
else process the error normally.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/eeh.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platfo
Perform all error checking at the "partitonable endpoint"
of the device.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
version 2: I still can't get whitespace right the first time ...
arch/powerpc/platforms/pseries/eeh.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8
Alan Bennett wrote:
> While working on i2c support, I've decided to update to a new kernel.
> In the process of doing this, I'm not sure I've properly configured the
> MURAM node to my device tree (i.e. serial is broken again).
You haven't -- you copied muram/data/reg from some other tree, ra
>
>> http://patchwork.ozlabs.org/linuxppc/patch?id=14475
>
> Thanks for pointing me to this patch. I will try out and let you know if
> this fixed the problem.
Hi Anton,
This patch fixed the problem. I am able to run and profile ebizzy on 128-way
PPC64. However this fix is not included in 2.
Hello;
While working on i2c support, I've decided to update to a new kernel. In
the process of doing this, I'm not sure I've properly configured the MURAM
node to my device tree (i.e. serial is broken again). Also, does this, in
any way, change the way I offset the early debug transmit descrip
ps3: Prefix ps3-specific kernel modules with `ps3-':
- vuart.ko -> ps3-vuart.ko
- sys-manager.ko -> ps3-sys-manager.ko
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
As the patch was too big for linuxppc-dev, here's an alternative using `mv'
drivers/ps3/Makefile |4
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' p
ps3fb: video memory size cleanups:
- Limit video memory size to avoid crossing a 256 MiB boundary in IOIF space.
- Pass the actual amount of video memory used to lv1_gpu_memory_allocate().
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
FIXME Booting with `ps3fb=49M' should work now.
On (15/11/07 02:39), Andrew Morton didst pronounce:
> On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > This patch is a fix for 2.6.24.
> >
> > Ordinarily the size of a pageblock is determined at compile-time based on
> > the
> > hugepage size. On PPC64, the hugepage
On Thu, 15 Nov 2007 10:52:38 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> > Shouldn't this have been HUGETLB_PAGE_ORDER?
> >
>
> As a #define, possibly but as a static inline - definitly not.
>
> In this context, the define is not used because set_pageblock_order()
> is a no-op when CONFIG_HUG
Hi Stephen,
Stephen Rothwell wrote:
>
> On Wed, 14 Nov 2007 11:21:37 +0100 Marian Balakowicz <[EMAIL PROTECTED]>
> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +#include
>> +#include
>> +#include
>
> You still need asm/prom.h because you use of_get_flat_dt_root() and
> of_
On (15/11/07 02:32), Andrew Morton didst pronounce:
> On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > This patch is a fix for 2.6.24.
> >
> > Ordinarily the size of a pageblock is determined at compile-time based on
> > the
> > hugepage size. On PPC64, the hugepage
On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> This patch is a fix for 2.6.24.
>
> Ordinarily the size of a pageblock is determined at compile-time based on the
> hugepage size. On PPC64, the hugepage size is determined at runtime based on
> what is supported by the ma
Hi Andrew,
Here are 2 more patches for PS3 we would like to get in 2.6.24:
[1] ps3: Prefix all ps3-specific kernel modules with `ps3'
[2] ps3fb: video memory size cleanups
The first one fixes 2 PS3-specific modules having generic names.
The second one fixes a possible system lock up.
On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> This patch is a fix for 2.6.24.
>
> Ordinarily the size of a pageblock is determined at compile-time based on the
> hugepage size. On PPC64, the hugepage size is determined at runtime based on
> what is supported by the ma
On (15/11/07 14:17), Stephen Rothwell didst pronounce:
> Hi Mel,
>
> On Wed, 14 Nov 2007 18:10:45 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> >
> > libhugetlbfs test suite and boot test on iSeries is sufficient in this
> > case. However, the version I sent would break on IA-64 due to the lack of
This patch is a fix for 2.6.24.
Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that do
not support hugepages, HPAGE_SHI
Original-Nachricht
> Datum: Thu, 15 Nov 2007 08:54:32 +1100
> Von: Paul Mackerras <[EMAIL PROTECTED]>
> An: "Gerhard Pircher" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> No it's not just for
29 matches
Mail list logo
