On Wed, 2008-04-23 at 14:40 +1000, Benjamin Herrenschmidt wrote:
> > Hmm. Bad news. I got a crash in console_callback() again where
> > apparently r28 had a bogus value. That, however, doesn't make sense, so
> > maybe that register value was calculated from another register.
>
> Possibly. How har
Michael Ellerman schrieb:
On Tue, 2008-04-22 at 12:23 -0500, Scott Wood wrote:
On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote:
I wonder if the IRQ number should match the vector of the datasheet ...
giving :
No. The numbers in /proc/interrupts are virtual IRQ numbers, which are
Hi all,
Linus' kernel today produces these warnings for an allyesconfig build:
(it was actually a linux-next build, but the commit is in Linus' tree)
In file included from arch/powerpc/kernel/stacktrace.c:16:
include/asm/asm-offsets.h:113:1: warning: "CLONE_VM" redefined
In file included from arc
Kamalesh Babulal writes:
> After applying the patch above and the patch posted on
> http://lkml.org/lkml/2008/4/8/42
> the bug had the following information,
Thanks. The patch below, against Linus' current git tree, fixes one
bug that might be the cause of the problem, and also attempts to
detec
Hi Anton,
On Tuesday 22 April 2008 21:41, Anton Vorontsov wrote:
> Hi all,
>
> Here is purposed bindings draft for the new drivers that I would like to
> send for this or next merge window, depending on results of this RFC. ;-)
> (The new bindings needs to be in-tree or at least Acked before I co
On Wed, 2008-04-23 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
> > I wanted to ask if there are any known workarounds atm that would
> > allow me to use my X11 for now?
>
> X is doing a mmap of /dev/mem instead of /dev/fb ?
>
> You
This patch fixes the following build error:
<-- snip -->
...
CC [M] drivers/char/xilinx_hwicap/xilinx_hwicap.o
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xilinx_hwicap.c:806:
error: hwicap_of_match causes a section type conflict
/home/bunk/linux/kernel-2.6/git/
After commit 585468e5d5962660867c269e26f0a4b89a599473
([POWERPC] i2c: Fix build breakage introduced by OF helpers)
drivers/of/of_i2c.c needs a MODULE_LICENSE.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/of/of_i2c.c |3 +++
1 file changed, 3 insertions(+)
946ca8103416a313577b
From: Michel Dänzer <[EMAIL PROTECTED]>
Date: Wed, 23 Apr 2008 11:32:07 +0200
> On Wed, 2008-04-23 at 08:21 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote:
> > > I wanted to ask if there are any known workarounds atm that would
> > > allow me t
On Wed, 2008-04-23 at 11:32 +0200, Michel Dänzer wrote:
> > X is doing a mmap of /dev/mem instead of /dev/fb ?
> >
> > You can normally map the fb mapping /dev/fb and then map the
> registers
> > using /dev/fb at an offset beyond the framebuffer (fix->smem_len).
> >
> > If X is using /dev/mem in
On Wed, 2008-04-23 at 02:57 -0700, David Miller wrote:
> > It's up to the driver, and again, the current radeon driver doesn't
> use
> > radeonfb at all anymore...
>
> The only portable thing is for X to use the PCI sysfs mmap() stuff,
> which current Xorg servers using libpciaccess do.
>
> I kn
On Mon, 21 Apr 2008 14:12:48 +0200, Stefan Roese wrote:
> On Monday 21 April 2008, Laurent Pinchart wrote:
> > > > > Is there any chance they will got to 2.6.26?
> > > >
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks a
David Woodhouse wrote:
Ok. I'll submit a new patch as soon as we agree on a compatible name.
Did we?
IIRC, The latest agreement was that we don't need the "compatible" and
will match on node name.
Ok. Is there a current patch I should be merging?
Looks like it was decided to rev
Hi Laurent,
On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> Hi Jean,
>
> On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > Jean Delvare wrote:
> > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > under the impression that the powerpc folks are t
Adrian Bunk schrieb:
> After commit 585468e5d5962660867c269e26f0a4b89a599473
> ([POWERPC] i2c: Fix build breakage introduced by OF helpers)
> drivers/of/of_i2c.c needs a MODULE_LICENSE.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Jochen Friedrich <[EMAIL PROTECTED]>
Thanks,
Joc
On Wednesday 23 April 2008, Jean Delvare wrote:
> > > The patches are required for long awaited I2C support on various
> > > PowerPC boards. As the ppc architecture support is going away in
> > > 2.6.27, it would be nice to have them applied in 2.6.26.
> >
> > Yes, please.
>
> I know that many peop
Hi Stefan,
> Please don't get we wrong, I didn't want to put additional pressure on you
> here. I just wanted to express that I'm waiting for these patches to arrive
> upstream quite some time now too.
and unfortunately, the longer we wait the more drivers are ported to new-style
and the bigger
Hi Jean,
On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> Hi Laurent,
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
> > > > I'm not sure. I didn't have the time to loo
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers writes:
> > Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> > > This is a no-no for those archs that still use -traditional.
> > > > I dunno if this is a problem for you at the moment and the
> > > > right fix is any
Hi All,
Is there a Xilinx GPIO driver draft that uses CONFIG_OF somewhere?
Thanks in advance,
Johann Baudy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > I still don't know exactly what happened there... I think I saw some
> > "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> > listed below, which I thought they
On Apr 21, 2008, at 7:15 PM, Paul Mackerras wrote:
Kumar Gala writes:
Once again I want to go through it carefully and understand how it
all
works, and in particular understand things like the way it ensures
that the base address for the kmap region is aligned to a 4M
boundary
so all the
The fixmap code from x86 allows us to have compile time virtual addresses
that we change the physical addresses of at run time.
This is useful for applications like kmap_atomic, PCI config that is done
via direct memory map, kexec/kdump.
We got ride of CONFIG_HIGHMEM_START as we can now determine
Hi Stephen,
The next-20080423 kernel panics at various points on x86_64 and ppc machines
I have listed the call trace of ppc machine followed by the trace of x86_64
on ppc box
---
kernel BUG at arch/powerpc/lib/locks.c:36!
Oops: Exception in kernel mode, sig: 5 [#43]
SMP NR_CPUS=128
On 4/23/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Laurent,
>
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
>
> > > > I'm not sure. I didn't have the time to look at
Hi Johann,
Not to my knowledge yet. We have it on our list to do.
Thanks,
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Johann Baudy
Sent: Wednesday, April 23, 2008 6:48 AM
To: linuxppc-dev@ozlabs.org
Subject: Xilinx GPIO driver / CONFIG_OF
Hi A
Hi Jean,
> Jochen, I'm a bit confused by the dependencies that exist - or not -
> between these 7 patches you sent at once. I thought they had to be
> applied in sequence but it seems not? And some of them should
> apparently go through me i2c tree but others (e.g. [7/7]) not?
[1/7] and [2/7] are
On 4/23/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Jean,
>
>
> > Jochen, I'm a bit confused by the dependencies that exist - or not -
> > between these 7 patches you sent at once. I thought they had to be
> > applied in sequence but it seems not? And some of them should
> > apparently
On Wednesday 23 April 2008 14:47, Jean Delvare wrote:
> On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> > On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > > I still don't know exactly what happened there... I think I saw some
> > > "OpenFirmware i2c" patches go upstream yeste
On Wed, Apr 23, 2008 at 11:15:35AM +0200, Laurent Pinchart wrote:
> Hi Anton,
>
> On Tuesday 22 April 2008 21:41, Anton Vorontsov wrote:
> > Hi all,
> >
> > Here is purposed bindings draft for the new drivers that I would like to
> > send for this or next merge window, depending on results of thi
On Wed, Apr 23, 2008 at 05:59:38PM +1000, Stephen Rothwell wrote:
> This is from commit fd3e0bbc6052ca9747a5332b382584ece83aab6d ("[POWERPC]
> Stacktrace support for lockdep"). We don't include asm-offsets.h in any
> other C file in the powerpc build.
I think the include can be safely removed.
On Wed, Apr 23, 2008 at 7:21 AM, John Linn <[EMAIL PROTECTED]> wrote:
> Hi Johann,
>
> Not to my knowledge yet. We have it on our list to do.
>
> Thanks,
> John
I've got a partial driver but it's not updated to the new GPIO
infrastructure. I'll try to post what I have today.
Cheers,
g.
--
Pegasos2 has no current-speed property in
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] As a result,
console=ttyS0,115200 is
still required unless the patch below is used.
What is the correct way to restore console detection on pegasos2?
Index: linux-2.6.25-pegasos/arch/powerpc/platfor
The two u16 fields lock_token and paca_index in struct paca_struct are
accessed as one u32 field via type punning. Change this into one u32
field paca_id, and add a paca_get_index() function to access only the
low 16 bits of this.
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
---
arch/po
This is a reworked patch to fix the SPU data storage. Currently, the
SPU escape sequences and program counter data is being added directly
into the kernel buffer without holding the buffer_mutex lock. This
patch changes how the data is stored. A new function,
oprofile_add_value, is added into
Perfect :)
Many thanks,
Johann Baudy
On Wed, Apr 23, 2008 at 2:33 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 23, 2008 at 7:21 AM, John Linn <[EMAIL PROTECTED]> wrote:
> > Hi Johann,
> >
> > Not to my knowledge yet. We have it on our list to do.
> >
> > Thanks,
> > John
>
You can see the mapping between virq and hwirq numbers by turning on
CONFIG_VIRQ_DEBUG and looking in /sys/kernel/debug/powerpc/virq_mapping
(after mounting debugfs).
Ooh, nice! Are there plans to move this into some "real" sysfs
nodes?
Segher
___
data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
Which doesn't seem to actually do anything?
It's not a no-op, because hwirq is signed. It probably should be
unsigned, like most things.
You'll have to draw me a picture.
In C, signed division is round-towards-zero, while unsigned division
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
The functions can be found respectively in:
//---[ vi lib/bitmap.c +807 ]---
//---[ vi arch/powerpc/sysdev/mpic_ms
A similar problem in arch/powerpc/sysdev/mpic_u3msi.c:
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
The functions can be found respectively in:
//---[ vi l
Hi Wolfram,
> Hello,
>
> I finally could get the work started with I2C on a MPC8260-based
> platform. I applied Jochen's series on top of 2.6.25 and it seems I
> could get the i2c-cpm and the rtc-rs5c372 driver working (except that it
> doesn't autoload as a module, but I think this is my fault s
The two u16 fields lock_token and paca_index in struct paca_struct are
accessed as one u32 field via type punning. Change this into one u32
field paca_id, and add a paca_get_index() function to access only the
low 16 bits of this.
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
---
arch/p
A similar problem in arch/powerpc/sysdev/mpic_u3msi.c,
sorry for the dup, fixed header.
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
The functions can be f
mpc83xx_spi->irq is unsigned, so the test fails
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index be15a62..033fd51 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -454,12 +454,12 @@ static int __init
Use (31-THREAD_SHIFT) to get to thread_info from stack pointer. This makes
the code a bit easier to read and more robust if we ever change THREAD_SHIFT.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/misc_32.S |6 +++---
arch/powerpc/mm/hash_low_32.S |4 ++--
2 fil
* Removed TI_EXECDOMAIN define as its not used anywhere
* Use STACK_INT_FRAME_SIZE to allow common define of INT_FRAME_SIZE
* Define TI_CPU on both ppc32 & ppc64 (removes an ifdef).
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/asm-offsets.c | 11 ++-
1 files cha
On Apr 23, 2008, at 3:19 PM, Roel Kluin wrote:
mpc83xx_spi->irq is unsigned, so the test fails
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
you should copy the linux-spi list on such patches.
- k
---
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index be15a62..033fd5
mpc83xx_spi->irq is unsigned, so the test fails
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index be15a62..033fd51 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -454,12 +454,12 @@ static int __init
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Roel Kluin
> Sent: den 23 april 2008 22:55
> To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; lkml
> Subject: [PATCH 1/2] spi_mpc83xx: test below 0
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
list_for_each_entry(entry, &pdev->msi_list, list) {
hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
- if (hwirq < 0) {
+
Segher Boessenkool wrote:
>> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
>> return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
>
>> list_for_each_entry(entry, &pdev->msi_list, list) {
>> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
>> -if
also please add my signoff to
[PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
signed, but hwirq is unsigned. A failed allocation remains unnoticed.
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff
Add Timur TAbi as the maintainer for the Freescale QE library, the Freescale
QE UART device driver, the Freescale SOC sound drivers, and the Crystal
Semiconductor CS4270 device driver.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
This patch is for 2.6.26.
MAINTAINERS | 25 +++
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
to receive the following updates:
arch/powerpc/kernel/cpu_setup_6xx.S |8
arch/ppc/8260_io/fcc_enet.c | 19
arch/ppc/8xx_io/enet.c| 2
Here are four patches posted for you to pick up directly:
[POWERPC v7] 85xx: Add support for relocatble kernel (and booting at
non-zero)
[POWERPC v2] Port fixmap from x86 and use for kmap_atomic
[POWERPC] Cleanup asm-offset.c
[POWERPC] Clean up access to thread_info in assembly
- k
__
Again thanks to Segher and Joe Perches
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
signed, but hwirq is unsigned. A failed allocation remains unnoticed.
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sy
On Thu, 2008-04-24 at 00:25 +0200, Roel Kluin wrote:
> Segher Boessenkool wrote:
> >> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
> >> return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
> >
> >> list_for_each_entry(entry, &pdev->msi_list, list) {
> >>
On Thu, 2008-04-24 at 09:36 +1000, Michael Ellerman wrote:
>
> I think the real bug is that we're using irq_hw_number_t to represent
> something which isn't. At the end of the day we have to stash the
> hwirq
> into the MSI message data, which is a u32.
>
> I guess we could imagine a driver that
On Wed, 2008-04-23 at 16:32 +0200, Christoph Hellwig wrote:
> On Wed, Apr 23, 2008 at 05:59:38PM +1000, Stephen Rothwell wrote:
> > This is from commit fd3e0bbc6052ca9747a5332b382584ece83aab6d ("[POWERPC]
> > Stacktrace support for lockdep"). We don't include asm-offsets.h in any
> > other C file
On Wed, 2008-04-23 at 07:49 -0500, Kumar Gala wrote:
> its left over from the x86 port. I'll get rid of
> __FIXADDR_BOOT_SIZE,
> FIXADDR_BOOT_START, and __FIXADDR_TOP.
>
> If we want the early ioremap support in the future we can add back
> __FIXADDR_BOOT_SIZE and FIXADDR_BOOT_START.
Our ea
As BenH said the other day, it is an "accident" that prom_init.o is linked
with the rest of the kernel. The truth is a little more subtle, prom_init
isn't truly bootloader, it does fiddle with kernel data in a few places.
What we can do is discourage people from adding new code that accesses
data
Replace two open-coded occurences of the of_get_next_parent() logic.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
The function touched by the first chunk still needs the tmp variable.
arch/powerpc/platforms/cell/axon_msi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions
Ben-san,
I'm sorry to have kept you waiting for my response.
I just finished reviewing your patch. Your patch works well on
Celleb, and I found I also should do the same thing for Celleb as you
pointed. I will send a new patch which includes your fix.
Benjamin Herrenschmidt <[EMAIL PROTECTED]
Ben-san,
I'm sorry to have kept you waiting for my response.
I just finished reviewing your patch. Your patch works well on
Celleb, and I found I also should do the same thing for Celleb as you
pointed. I will send a new patch which includes your fix.
Benjamin Herrenschmidt <[EMAIL PROTECTED]
On Thu, 2008-04-24 at 12:07 +0900, Ishizaki Kou wrote:
>
> I'm sorry to have kept you waiting for my response.
>
> I just finished reviewing your patch. Your patch works well on
> Celleb, and I found I also should do the same thing for Celleb as you
> pointed. I will send a new patch which inc
* Removed get_msr(), get_srr0(), and get_srr1() - not used anywhere
* Use STACK_FRAME_OVERHEAD instead of magic number
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/misc_64.S | 20
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/
On Thu, 2008-04-24 at 12:08 +1000, Michael Ellerman wrote:
> As BenH said the other day, it is an "accident" that prom_init.o is linked
> with the rest of the kernel. The truth is a little more subtle, prom_init
> isn't truly bootloader, it does fiddle with kernel data in a few places.
>
> What w
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
As sfr points out this works because __secondary_hold_spinloop is being set
already, but iSeries isn't looking a
This patch adds the required functionality to fill in all pacas at runtime.
With NR_CPUS=1024
textdata bss dec hex filename
137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
121 1179744 524288 1704153 1a00d9 arch/powerpc/kernel/paca.o :After
Also remove un
On Thu, 2008-04-24 at 13:43 +1000, Tony Breeds wrote:
> This patch adds the required functionality to fill in all pacas at runtime.
>
> With NR_CPUS=1024
> textdata bss dec hex filename
> 137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
> 121 1179744 524288
Because the udbg_console has CON_ENABLED set, it's possible that when we
register it with the console code the index won't be set. This leads to
slightly confusing boot messages like:
[0.00] console [udbg-1] enabled
We could remove CON_ENABLED, but we don't want to do that, we always
want
The udbg console should be safe to call basically at any time after boot.
It does not need any per-cpu resources or for the cpu to be online, as
long as there is a udbg_putc routine hooked up it should work. So mark it
as CON_ANYTIME.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/p
On pseries LPAR we can call the udbg routines, and the udbg console very
early. So mark the udbg console as safe to call early in boot, and register
the udbg console as soon as the udbg routines are hooked up.
This allows platforms/pseries code to use printk() and pr_debug() rather
than needing to
In pseries/lpar.c, fix some printf specifier mismatches, and add
a newline to one printk.
In pseries/rtasd.c add "rtasd" to some messages to make it clear
where they're coming from.
In pseries/scanlog.c remove the hand-rolled runtime debugging support
in there. This file has been largely unchange
Add a DEBUG config setting which turns on all (most) of the debugging
under platforms/pseries.
To have this take effect we need to remove all the #undef DEBUG's, in
various files. We leave the #undef DEBUG in platforms/pseries/lpar.c,
as this enables debugging printks from the low-level hash table
Posting this to get any review and suggestions on the functionality of the
patch.
Questions/issues:
* what to do about the stack_ovf check in entry_32.S
* do we really have any constraints on ppc32 (beyond being in lowmem) on
the locations of the stacks [see irqstack_early_init()]
- k
diff --git
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> After applying the patch above and the patch posted on
>> http://lkml.org/lkml/2008/4/8/42
>> the bug had the following information,
>
> Thanks. The patch below, against Linus' current git tree, fixes one
> bug that might be the cause of the
Paul, I finally got around to testing your changeset on sparc64, it
breaks things:
commit d9024df02ffe74d723d97d552f86de3b34beb8cc
Author: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sat Apr 12 15:20:59 2008 +1000
[LMB] Restructure allocation loops to avoid unsigned underflow
...
Specif
Roland McGrath writes:
> > This should be _TLF_RESTORE_SIGMASK (leading '_'), I think.
>
> Indeed so. Here's a replacement patch.
Thanks. That can't go in until some generic changes have gone in
first, right? So are you going to push the lot in one go via Andrew,
or should I wait until the ge
Roland McGrath writes:
> Indeed so. Here's a replacement patch.
Oh, and could you please also fix the occurrence of
TIF_RESTORE_SIGMASK in arch/ppc/kernel/entry.S when this stuff goes
in?
Thanks,
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs
On Wed, 2008-04-23 at 23:24 -0700, David Miller wrote:
> Paul, I finally got around to testing your changeset on sparc64, it
> breaks things:
>
> commit d9024df02ffe74d723d97d552f86de3b34beb8cc
> Author: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Sat Apr 12 15:20:59 2008 +1000
>
> [LMB] Res
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Thu, 24 Apr 2008 16:35:33 +1000
> Sounds like we need a test suite :)
Maybe :-) Anyways, here is the bug fix I plan to push to
Linus with my sparc64 NUMA changes, unless someone has an
objection:
[LMB]: Fix lmb allocation regression.
Changeset d
David Miller writes:
> Specifically, you removed the aligning of the size argument given to
> lmb_add_region() in the lmb allocators, and that is critical when
> allocating many small chunks, we run out of LMB slots otherwise
> and allocations start failing.
Sorry. It's still there in lmb_alloc_
83 matches
Mail list logo
