On Tue, 2010-06-01 at 14:45 +1000, Anton Blanchard wrote:
> Now we dynamically allocate the paca array, it takes an extra load
> whenever we want to access another cpu's paca. One place we do that a lot
> is per cpu variables. A simple example:
Can't we dedicate a GPR instead ? Or it isn't worth i
Paul Mackerras writes:
> I re-read the relevant part of the PowerPC architecture spec
> yesterday, and it seems pretty clear that the FPSCR doesn't affect the
> behaviour of lfs and stfs, and is not affected by them. So in fact 4
> out of the 7 instructions in each of those procedures are unnece
On 01.06.2010, at 10:36, Andreas Schwab wrote:
> Paul Mackerras writes:
>
>> I re-read the relevant part of the PowerPC architecture spec
>> yesterday, and it seems pretty clear that the FPSCR doesn't affect the
>> behaviour of lfs and stfs, and is not affected by them. So in fact 4
>> out of
On Mon, 2010-05-31 at 20:06 +0200, Andreas Schwab wrote:
> Alexander Graf writes:
>
> > Mind to send it over so I can take a look at it :)? Getting rid of the
> > task_struct structs lying in the stack is certainly a good idea.
>
> Still untested, because rc1 does not boot.
Ouch ! What machine
Benjamin Herrenschmidt writes:
> On Mon, 2010-05-31 at 20:06 +0200, Andreas Schwab wrote:
>> Alexander Graf writes:
>>
>> > Mind to send it over so I can take a look at it :)? Getting rid of the
>> > task_struct structs lying in the stack is certainly a good idea.
>>
>> Still untested, because
Hi Timur,
On Thu, 29 Apr 2010 20:39:02 -0500
Timur Tabi wrote:
> On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin wrote:
> > This patch series rework DIU support patches submitted
> > previously. Comments to the previos patch series have
> > been addressed, not related changes are dropped an
On Tue, 2010-06-01 at 11:36 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt writes:
>
> > On Mon, 2010-05-31 at 20:06 +0200, Andreas Schwab wrote:
> >> Alexander Graf writes:
> >>
> >> > Mind to send it over so I can take a look at it :)? Getting rid of the
> >> > task_struct structs lyin
Benjamin Herrenschmidt wrote:
> O
>
>> diff --git a/arch/powerpc/kernel/setup-common.c
>> b/arch/powerpc/kernel/setup-common.c
>> index 48f0a00..3d169bb 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -94,6 +94,10 @@ struct screen_info screen
Scott Wood wrote:
> On 05/28/2010 10:18 AM, Martyn Welch wrote:
>> The CPM early debug console hardcodes the BAT to cover the IMMR at
>> 0xf000. The IMMR (on the mpc8270 at the very least) can be set to a
>> number of locations with bootstrap configuration, which are outside the
>> hardcoded BA
Martyn Welch wrote:
> Scott Wood wrote:
>
>> On 05/28/2010 10:18 AM, Martyn Welch wrote:
>>
>>> The CPM early debug console hardcodes the BAT to cover the IMMR at
>>> 0xf000. The IMMR (on the mpc8270 at the very least) can be set to a
>>> number of locations with bootstrap configuration
On Mon, 31 May 2010 14:55:48 +0200, Wolfram Sang wrote:
> I2C-drivers can use the clientdata-pointer to point to private data. As I2C
> devices are not really unregistered, but merely detached from their driver, it
> used to be the drivers obligation to clear this pointer during remove() or a
> fai
Signed-off-by: Andreas Schwab
---
drivers/macintosh/macio_asic.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 9714780..40390ac 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintos
On 06/01/2010 08:43 AM, Martyn Welch wrote:
diff --git a/arch/powerpc/kernel/head_32.S
b/arch/powerpc/kernel/head_32.S
index e025e89..861cace 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -1194,12 +1194,13 @@ setup_disp_bat:
#endif /* CONFIG_BOOTX_TEXT */
Andreas Schwab writes:
> Benjamin Herrenschmidt writes:
>
>> On Mon, 2010-05-31 at 20:06 +0200, Andreas Schwab wrote:
>>> Alexander Graf writes:
>>>
>>> > Mind to send it over so I can take a look at it :)? Getting rid of the
>>> > task_struct structs lying in the stack is certainly a good ide
Albert Cahalan [acaha...@gmail.com] wrote:
| Sukadev Bhattiprolu writes:
|
| > Randy Dunlap [randy.dunlap at oracle.com] wrote:
| >>> base of the region allocated for stack. These architectures
| >>> must pass in the size of the stack-region in ->child_stack_size.
| >>
| >>
Fix potential initial_lfsr buffer overrun.
Writing past the end of the buffer could happen when index == ENTRIES
Signed-off-by: Denis Kirjanov
---
arch/powerpc/oprofile/op_model_cell.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/oprofile/op_model_cell.c
On Tue, Jun 1, 2010 at 3:32 PM, Sukadev Bhattiprolu
wrote:
> Albert Cahalan [acaha...@gmail.com] wrote:
> | Sukadev Bhattiprolu writes:
> | > Randy Dunlap [randy.dunlap at oracle.com] wrote:
> | >>> base of the region allocated for stack. These architectures
> | >>> must pass in the size of the s
On Tue, Jun 01, 2010 at 05:05:20PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2010-06-01 at 14:45 +1000, Anton Blanchard wrote:
> > Now we dynamically allocate the paca array, it takes an extra load
> > whenever we want to access another cpu's paca. One place we do that a lot
> > is per cpu var
* Peter Zijlstra [2010-05-31 10:33:16]:
> On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
> >
> >
> > Hrmm, my brain seems muddled but I might have another solution, let me
> > ponder this for a bit..
> >
>
> Right, so the thing I was thinking about is taking the group capacity
> int
On Wed, 2010-06-02 at 08:10 +0930, Alan Modra wrote:
> Not r12. It is used in function prologue and epilogue code. If you
> want a dedicated gpr I think you'll need to use (and lose) one of the
> non-volatile regs.
Which would probably not be a big deal...
Cheers,
Ben.
_
| Come on, seriously, you know it's ia64 and hppa that
| have issues. Maybe the nommu ports also have issues.
|
| The only portable way to specify the stack is base and offset,
| with flags or magic values for "share" and "kernel managed".
Ah, ok, we have not yet ported to IA64 and I see now wher
On Thu, May 20, 2010 at 10:49:55PM +1000, Paul Mackerras wrote:
> This extends the emulate_step() function to handle most of the load
> and store instructions implemented on current 64-bit server processors.
> The aim is to handle all the load and store instructions used in the
> kernel, so this ha
This fixes a sporadic oops at boot on G5 Power Macs. The table_end
variable has the address of the last byte of the table. Adding on
PAGE_SIZE means we flush too much, and if the page after the table
is not mapped for any reason, the kernel will oops. Instead we add
on 1 because flush_dcache_ran
On Wed, Jun 02, 2010 at 10:55:02AM +0530, K.Prasad wrote:
> On Thu, May 20, 2010 at 10:49:55PM +1000, Paul Mackerras wrote:
> > This extends the emulate_step() function to handle most of the load
> > and store instructions implemented on current 64-bit server processors.
> > The aim is to handle al
On Tue, Jun 01, 2010 at 01:41:59PM +0100, Martyn Welch wrote:
> Benjamin Herrenschmidt wrote:
> > O
> >
> >> diff --git a/arch/powerpc/kernel/setup-common.c
> >> b/arch/powerpc/kernel/setup-common.c
> >> index 48f0a00..3d169bb 100644
> >> --- a/arch/powerpc/kernel/setup-common.c
> >> +++ b/arch
25 matches
Mail list logo
