Al Viro writes:
ppc SMP is supported only for 6xx/POWER3/POWER4 - i.e. ones that have
PPC_STD_MMU. Dependency fixed.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Acked-by: Paul Mackerras [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Kumar Gala writes:
> So after all of this its not clear to me if its acceptable to kill
> all users of in the kernel and to move code that
> exists in to for arch's that need it.
doesn't describe any part of the user/kernel ABI, so
we should be OK to kill it. I would say we should
Kumar Gala writes:
So after all of this its not clear to me if its acceptable to kill
all users of asm/segment.h in the kernel and to move code that
exists in asm/segment.h to asm/uaccess.h for arch's that need it.
asm/segment.h doesn't describe any part of the user/kernel ABI, so
we
the pointers to start doing the
devices on the bus under the bridge, and when we reach the end of a
bus's devices, we use the bus->self pointer to go back up to the next
higher bus and continue doing its devices.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -urN linux-2.6/dr
the pointers to start doing the
devices on the bus under the bridge, and when we reach the end of a
bus's devices, we use the bus-self pointer to go back up to the next
higher bus and continue doing its devices.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff -urN linux-2.6/drivers/pci
tephen Rothwell <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
arch/ppc64/kernel/LparData.c| 79
arch/ppc64/kernel/Makefile |5 ++
arch/ppc64/kernel/head.S|6 ++
arch/ppc64/kernel/lparma
Kumar Gala writes:
> Made a dummy include like it is in ppc64 and removed any
> users if it in arch/ppc.
Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
too, for that matter) entirely?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Kumar Gala writes:
Made asm/segment.h a dummy include like it is in ppc64 and removed any
users if it in arch/ppc.
Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
too, for that matter) entirely?
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Rothwell [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
arch/ppc64/kernel/LparData.c| 79
arch/ppc64/kernel/Makefile |5 ++
arch/ppc64/kernel/head.S|6 ++
arch/ppc64/kernel/lparmap.c | 31
Arjan van de Ven writes:
> is there a way to avoid the recursion somehow? Recursion is "not fun"
> stack usage wise, esp if you have really deep hierarchies
Yes, since we have pointers up the tree as well as down, it should in
fact be easy. I'll hack something up.
Paul.
-
To unsubscribe
Arjan van de Ven writes:
is there a way to avoid the recursion somehow? Recursion is not fun
stack usage wise, esp if you have really deep hierarchies
Yes, since we have pointers up the tree as well as down, it should in
fact be easy. I'll hack something up.
Paul.
-
To unsubscribe from
was originally written by Linas Vepstas
and moved to drivers/pci/bus.c (and slightly modified) by me.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -urN linux-2.6/drivers/pci/bus.c test-pseries/drivers/pci/bus.c
--- linux-2.6/drivers/pci/bus.c 2005-08-03 10:51:36.0 +1000
++
was originally written by Linas Vepstas
and moved to drivers/pci/bus.c (and slightly modified) by me.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff -urN linux-2.6/drivers/pci/bus.c test-pseries/drivers/pci/bus.c
--- linux-2.6/drivers/pci/bus.c 2005-08-03 10:51:36.0 +1000
+++ test
Hmamouche, Youssef writes:
> This patch adds two checks for NULL pointers.
OK, but get the whitespace right please - use tabs not spaces for
indentation, and put a space between "if" and "(". See
Documentation/CodingStyle.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe
Hmamouche, Youssef writes:
This patch adds two checks for NULL pointers.
OK, but get the whitespace right please - use tabs not spaces for
indentation, and put a space between if and (. See
Documentation/CodingStyle.
Paul.
-
To unsubscribe from this list: send the line unsubscribe
kexec on ppc64 and should be safe to go in
2.6.13. -- paulus]
Signed-off-by: Haren Myneni <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -Naurp 2613-rc4-git4.orig/arch/ppc64/kernel/machine_kexec.c
2613-rc4-git4/arch/ppc64/kernel/machine_kexec.c
--- 2
w state of those CPU(s).
[This is a simple, very low risk, obvious fix for an obvious bug, and
should go into 2.6.13. -- paulus]
Signed-off-by: Haren Myneni <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
--- linux-2.6.13-rc4-git4/arch/ppc64/xmon/xmo
powerbook once again.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -urN linux-2.6/drivers/pcmcia/yenta_socket.c
pmac-2.6/drivers/pcmcia/yenta_socket.c
--- linux-2.6/drivers/pcmcia/yenta_socket.c 2005-07-31 17:38:35.0
+1000
+++ pmac-2.6/drivers/pcmcia/yenta_socket.c
again.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff -urN linux-2.6/drivers/pcmcia/yenta_socket.c
pmac-2.6/drivers/pcmcia/yenta_socket.c
--- linux-2.6/drivers/pcmcia/yenta_socket.c 2005-07-31 17:38:35.0
+1000
+++ pmac-2.6/drivers/pcmcia/yenta_socket.c 2005-08-02 21:32
(s).
[This is a simple, very low risk, obvious fix for an obvious bug, and
should go into 2.6.13. -- paulus]
Signed-off-by: Haren Myneni [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
--- linux-2.6.13-rc4-git4/arch/ppc64/xmon/xmon.c.orig 2005-08-01
22:31:09.0
kexec on ppc64 and should be safe to go in
2.6.13. -- paulus]
Signed-off-by: Haren Myneni [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff -Naurp 2613-rc4-git4.orig/arch/ppc64/kernel/machine_kexec.c
2613-rc4-git4/arch/ppc64/kernel/machine_kexec.c
--- 2613-rc4-git4.orig
Anton Blanchard writes:
> Dont include asm-generic/topology.h unconditionally, we end up
> overriding all the ppc64 specific functions when NUMA is on.
>
> Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
It looks like th
Anton Blanchard writes:
Dont include asm-generic/topology.h unconditionally, we end up
overriding all the ppc64 specific functions when NUMA is on.
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
Acked-by: Paul Mackerras [EMAIL PROTECTED]
It looks like this should go into 2.6.13
patch handles those
cases.
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -urN linux-2.6/arch/ppc64/mm/numa.c g5-ppc64/arch/ppc64/mm/numa.c
--- linux-2.6/arch/ppc64/mm/numa.c 2005-06-24 13:38:52.0 +1000
+++ g5-p
handles those
cases.
Signed-off-by: Mike Kravetz [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff -urN linux-2.6/arch/ppc64/mm/numa.c g5-ppc64/arch/ppc64/mm/numa.c
--- linux-2.6/arch/ppc64/mm/numa.c 2005-06-24 13:38:52.0 +1000
+++ g5-ppc64/arch/ppc64/mm/numa.c
Andrew Morton writes:
> Matt Porter <[EMAIL PROTECTED]> wrote:
> >
> > +static u64 dma_mask = 0xULL;
>
> I'm sure you're totally uninterested in this, but the above will probably
> generate warnings on (say) ppc64, where u64 is implemented as unsigned
> long.
>
> I usually chuck a
Andrew Morton writes:
Matt Porter [EMAIL PROTECTED] wrote:
+static u64 dma_mask = 0xULL;
I'm sure you're totally uninterested in this, but the above will probably
generate warnings on (say) ppc64, where u64 is implemented as unsigned
long.
I usually chuck a simple `-1' in
Christoph Hellwig writes:
> On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote:
> > On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote:
> > > additional benefit is cleaning up the ifdef mess in ppc_htab.c
> > >
> > >
> > > Signed-off-by: Christoph Hellwig <[EMAIL
Christoph Hellwig writes:
On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote:
On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote:
additional benefit is cleaning up the ifdef mess in ppc_htab.c
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
I wrote:
> The only fast path that needs atomic_dec_if_positive is down_trylock.
> You can use atomic_dec for down_trylock instead; the only downside to
> that is that if somebody was holding the semaphore but nobody was
> waiting, the holder will take the slow path when it does the up.
Better
Benjamin LaHaise writes:
> There are at least two users who need asynchronous semaphore/mutex
> operations: aio_write (which needs to acquire i_sem), and nfs.
What do you mean by asynchronous semaphore/mutex operations? Are you
talking about a down operation that will acquire the semaphore
Trond Myklebust writes:
> The PPC implementation would be hard to port to x86, since it relies on
> the load-linked/store-conditional stuff to provide a fast primitive for
> atomic_dec_if_positive().
The only fast path that needs atomic_dec_if_positive is down_trylock.
You can use atomic_dec for
Trond Myklebust writes:
The PPC implementation would be hard to port to x86, since it relies on
the load-linked/store-conditional stuff to provide a fast primitive for
atomic_dec_if_positive().
The only fast path that needs atomic_dec_if_positive is down_trylock.
You can use atomic_dec for
Benjamin LaHaise writes:
There are at least two users who need asynchronous semaphore/mutex
operations: aio_write (which needs to acquire i_sem), and nfs.
What do you mean by asynchronous semaphore/mutex operations? Are you
talking about a down operation that will acquire the semaphore if
I wrote:
The only fast path that needs atomic_dec_if_positive is down_trylock.
You can use atomic_dec for down_trylock instead; the only downside to
that is that if somebody was holding the semaphore but nobody was
waiting, the holder will take the slow path when it does the up.
Better
Trond Myklebust writes:
> It started from a desire to extend the existing implementations to
> support new features such as asynchronous notification. Currently that
> sort of thing is impossible unless your developer-super-powers include
> the ability to herd 24 different subsystem maintainers
Benjamin LaHaise writes:
> Please review the following series of patches for unifying the
> semaphore implementation across all architectures (not posted as
> they're about 350K), as they have only been tested on x86-64. The
> code generated is functionally identical to the earlier i386
>
Benjamin LaHaise writes:
Please review the following series of patches for unifying the
semaphore implementation across all architectures (not posted as
they're about 350K), as they have only been tested on x86-64. The
code generated is functionally identical to the earlier i386
Trond Myklebust writes:
It started from a desire to extend the existing implementations to
support new features such as asynchronous notification. Currently that
sort of thing is impossible unless your developer-super-powers include
the ability to herd 24 different subsystem maintainers into
Andrew Morton writes:
> > The other reason,
> > of course, is to be able to see if a patch I'm about to send conflicts
> > with something you have already taken, and rebase it if necessary.
>
>
>
> How's this?
Nice; but in fact I meant that I want to be able to see if a patch of
mine
Andrew Morton writes:
> The problem with those is letting other people get access to it. I guess
> that could be fixed with a bit of scripting and rsyncing.
Yes.
> (I don't do that for -mm because -mm basically doesn't work for 99% of the
> time. Takes 4-5 hours to out a release out assuming
Linus,
> That "individual patches" is one of the keywords, btw. One thing that BK
> has been extremely good at, and that a lot of people have come to like
> even when they didn't use BK, is how we've been maintaining a much finer-
> granularity view of changes. That isn't going to go away.
Andrew Morton writes:
The problem with those is letting other people get access to it. I guess
that could be fixed with a bit of scripting and rsyncing.
Yes.
(I don't do that for -mm because -mm basically doesn't work for 99% of the
time. Takes 4-5 hours to out a release out assuming that
Andrew Morton writes:
The other reason,
of course, is to be able to see if a patch I'm about to send conflicts
with something you have already taken, and rebase it if necessary.
hack, hack
How's this?
Nice; but in fact I meant that I want to be able to see if a patch of
mine
Andrew Morton writes:
> Marty Ridgeway <[EMAIL PROTECTED]> wrote:
> >
> > The April release of LTP is now on SourceForge.
> >
> > LTP-20050405
>
> It seems to have an x86ism in it which causes the compile to fail on ppc64:
Looks to me like gcc is objecting to our (ppc64's) _syscall2
Andrew Morton writes:
Marty Ridgeway [EMAIL PROTECTED] wrote:
The April release of LTP is now on SourceForge.
LTP-20050405
It seems to have an x86ism in it which causes the compile to fail on ppc64:
Looks to me like gcc is objecting to our (ppc64's) _syscall2
definition; Alan Modra
Christoph Hellwig writes:
> - the magic CONFIG_COMPAT changes for SHM handles should only be done when
>a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can
>run 32bit code and drm shouldn't behave differently just because we can
>run 32bit code.
Yes it should -
Christoph Hellwig writes:
> E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
> in for running i386 apps. But I don't want dri to hand out 32bit handles
> everywhere just because of that, because I most certainly won't be running
> i386 OpenGL apps.
The handle for a
Christoph Hellwig writes:
> It's documented where the other filesystem entry points are documented.
Which is?
$ grep -r compat_ioctl Documentation
Documentation/filesystems/Locking: long (*compat_ioctl) (struct file *,
unsigned int, unsigned long);
Christoph Hellwig writes:
> Please make it a module option so it doesn't regress everyone for your
> specific needs.
Sorry, I don't follow you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Dave Airlie writes:
> Paulus these look like your patches care to update them with the "new"
> method of doing stuff..
What are we going to do about the DRM CVS? Change it to the new way
and break everyone running 2.6.10 or earlier, or leave it at the old
way that will work for people with
Christoph Hellwig writes:
> Those DRI callers aren't in mainline but introduced in bk-drm.patch,
> looks like the DRI folks need beating with a big stick..
Settle down Christoph, the compat_ioctl method is less than 3 months
old, has only been in one official 2.6.x release, and isn't documented
modules to use the inline flush_icache_range.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc64/kernel/ppc_ksyms.c
test/arch/ppc64/kernel/ppc_ksyms.c
--- linux-2.5/arch/ppc64/kernel/ppc_ksyms.c 2005-03-07 10:46:38.0
+1100
+++ test/arch/ppc64/
Christoph Hellwig writes:
Those DRI callers aren't in mainline but introduced in bk-drm.patch,
looks like the DRI folks need beating with a big stick..
Settle down Christoph, the compat_ioctl method is less than 3 months
old, has only been in one official 2.6.x release, and isn't documented
at
Dave Airlie writes:
Paulus these look like your patches care to update them with the new
method of doing stuff..
What are we going to do about the DRM CVS? Change it to the new way
and break everyone running 2.6.10 or earlier, or leave it at the old
way that will work for people with distro
Christoph Hellwig writes:
Please make it a module option so it doesn't regress everyone for your
specific needs.
Sorry, I don't follow you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Christoph Hellwig writes:
It's documented where the other filesystem entry points are documented.
Which is?
$ grep -r compat_ioctl Documentation
Documentation/filesystems/Locking: long (*compat_ioctl) (struct file *,
unsigned int, unsigned long);
Christoph Hellwig writes:
E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
in for running i386 apps. But I don't want dri to hand out 32bit handles
everywhere just because of that, because I most certainly won't be running
i386 OpenGL apps.
The handle for a _DRM_SHM
Christoph Hellwig writes:
- the magic CONFIG_COMPAT changes for SHM handles should only be done when
a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can
run 32bit code and drm shouldn't behave differently just because we can
run 32bit code.
Yes it should - we
after emulating the instruction.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/kernel/traps.c pmac-2.5/arch/ppc/kernel/traps.c
--- linux-2.5/arch/ppc/kernel/traps.c 2005-03-29 16:24:53.0 +1000
+++ pmac-2.5/arch/ppc/kernel/traps.c2005-03-31
if the altivec unit is in java mode.)
This patch checks explicitly if we are in user mode and prints a
useful message if not.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/kernel/traps.c pmac-2.5/arch/ppc/kernel/traps.c
--- linux-2.5/arch/ppc/kernel/traps.c 2
it reads the timebase from one CPU and
transfers the value to the other CPU. (Hotplug CPU is needed for
sleep (aka suspend to RAM) to work.)
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/platforms/pmac_smp.c
pmac-2.5/arch/ppc/platforms/pmac_smp.c
--- linux-2.
The code that went into arch/ppc/kernel/signal.c recently to handle
process freezing seems to contain a dubious assumption: that a process
that calls do_signal when PF_FREEZE is set will have entered the
kernel because of a system call. This patch removes that assumption.
Signed-off-by: Paul
The code that went into arch/ppc/kernel/signal.c recently to handle
process freezing seems to contain a dubious assumption: that a process
that calls do_signal when PF_FREEZE is set will have entered the
kernel because of a system call. This patch removes that assumption.
Signed-off-by: Paul
it reads the timebase from one CPU and
transfers the value to the other CPU. (Hotplug CPU is needed for
sleep (aka suspend to RAM) to work.)
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/arch/ppc/platforms/pmac_smp.c
pmac-2.5/arch/ppc/platforms/pmac_smp.c
--- linux-2.5/arch/ppc
after emulating the instruction.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/arch/ppc/kernel/traps.c pmac-2.5/arch/ppc/kernel/traps.c
--- linux-2.5/arch/ppc/kernel/traps.c 2005-03-29 16:24:53.0 +1000
+++ pmac-2.5/arch/ppc/kernel/traps.c2005-03-31 08:37
if the altivec unit is in java mode.)
This patch checks explicitly if we are in user mode and prints a
useful message if not.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/arch/ppc/kernel/traps.c pmac-2.5/arch/ppc/kernel/traps.c
--- linux-2.5/arch/ppc/kernel/traps.c 2005-03-29
. The number of casts in
prom_init.c is reduced substantially by this patch.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/syslib/prom_init.c
pmac-2.5/arch/ppc/syslib/prom_init.c
--- linux-2.5/arch/ppc/syslib/prom_init.c 2005-01-29 09:58:49.0
Since we have some syscalls with 6 arguments, it's useful to have a
definition of _syscall6 in asm-ppc/unistd.h. This patch adds a
suitable definition.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/include/asm-ppc/unistd.h pmac-2.5/include/asm-ppc/unistd.h
--- lin
Since we have some syscalls with 6 arguments, it's useful to have a
definition of _syscall6 in asm-ppc/unistd.h. This patch adds a
suitable definition.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/include/asm-ppc/unistd.h pmac-2.5/include/asm-ppc/unistd.h
--- linux-2.5
. The number of casts in
prom_init.c is reduced substantially by this patch.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/arch/ppc/syslib/prom_init.c
pmac-2.5/arch/ppc/syslib/prom_init.c
--- linux-2.5/arch/ppc/syslib/prom_init.c 2005-01-29 09:58:49.0
+1100
This patch shuts up some more incorrect gcc warnings.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/xmon/xmon.c testpmac/arch/ppc/xmon/xmon.c
--- linux-2.5/arch/ppc/xmon/xmon.c 2004-10-21 07:17:18.0 +1000
+++ testpmac/arch/ppc/xmon/xmon.c
This patch shuts up a couple of gcc "variable may be used
uninitialized" warnings. The warnings are invalid - the code is such
that the variables are in fact initialized before being used - but gcc
isn't smart enough to see that. This patch eliminates the warnings.
Signed-off-by: Paul
CONFIG_OPROFILE=m doesn't work on ppc64 if these aren't exported...
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
--- linux-2.6.11/arch/ppc64/kernel/pmc.c.orig 2005-03-31 20:31:07.0
+0100
+++ linux-2.6.11/arch/ppc64/
CONFIG_OPROFILE=m doesn't work on ppc64 if these aren't exported...
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
--- linux-2.6.11/arch/ppc64/kernel/pmc.c.orig 2005-03-31 20:31:07.0
+0100
+++ linux-2.6.11/arch/ppc64/kernel/pmc.c
This patch shuts up a couple of gcc variable may be used
uninitialized warnings. The warnings are invalid - the code is such
that the variables are in fact initialized before being used - but gcc
isn't smart enough to see that. This patch eliminates the warnings.
Signed-off-by: Paul Mackerras
This patch shuts up some more incorrect gcc warnings.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/arch/ppc/xmon/xmon.c testpmac/arch/ppc/xmon/xmon.c
--- linux-2.5/arch/ppc/xmon/xmon.c 2004-10-21 07:17:18.0 +1000
+++ testpmac/arch/ppc/xmon/xmon.c 2005-04
Antonio Vargas writes:
> Don't know exactly about power5, but G5 processor is described on IBM
> docs as doing automatic whole-page prefetch read-ahead when detecting
> linear accesses.
Sure, but linked lists would rarely be laid out linearly in memory.
Paul.
-
To unsubscribe from this list:
Serge E. Hallyn writes:
> While investigating the inordinate performance impact one of my patches
> seemed to be having, we tracked it down to two hlist_for_each_entry
> loops, and finally to the prefetch instruction in the loop.
I would be interested to know what results you get if you leave
Serge E. Hallyn writes:
While investigating the inordinate performance impact one of my patches
seemed to be having, we tracked it down to two hlist_for_each_entry
loops, and finally to the prefetch instruction in the loop.
I would be interested to know what results you get if you leave the
Antonio Vargas writes:
Don't know exactly about power5, but G5 processor is described on IBM
docs as doing automatic whole-page prefetch read-ahead when detecting
linear accesses.
Sure, but linked lists would rarely be laid out linearly in memory.
Paul.
-
To unsubscribe from this list: send
Luck, Tony writes:
> Can we legislate that "end==0" isn't possible.
I think this is only likely to be a problem on 32-bit platforms with
hardware support for separate user and kernel address spaces. m68k
and sparc32 come to mind, though I might be mistaken.
Paul.
-
To unsubscribe from this
Luck, Tony writes:
Can we legislate that end==0 isn't possible.
I think this is only likely to be a problem on 32-bit platforms with
hardware support for separate user and kernel address spaces. m68k
and sparc32 come to mind, though I might be mistaken.
Paul.
-
To unsubscribe from this list:
Mikael Pettersson writes:
> Compiling 2.6.12-rc1-mm1 for ppc64 fails with:
>
> arch/ppc64/kernel/prom.c:1691: error: syntax error before
> 'prom_reconfig_notifier'
Currently prom.c is in a mess because Linus applied the last 2 of 8
patches from Nathan Lynch but not the first 6. :-P
Paul.
-
Mikael Pettersson writes:
Compiling 2.6.12-rc1-mm1 for ppc64 fails with:
arch/ppc64/kernel/prom.c:1691: error: syntax error before
'prom_reconfig_notifier'
Currently prom.c is in a mess because Linus applied the last 2 of 8
patches from Nathan Lynch but not the first 6. :-P
Paul.
-
To
Randy.Dunlap writes:
> diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl
> linux-2611-bk3-pv/include/asm-ppc/pgtable.h
> linux-2611-bk3-pfn/include/asm-ppc/pgtable.h
> --- linux-2611-bk3-pv/include/asm-ppc/pgtable.h 2005-03-07
> 11:02:18.0 -0800
> +++
Randy.Dunlap writes:
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl
linux-2611-bk3-pv/include/asm-ppc/pgtable.h
linux-2611-bk3-pfn/include/asm-ppc/pgtable.h
--- linux-2611-bk3-pv/include/asm-ppc/pgtable.h 2005-03-07
11:02:18.0 -0800
+++
Nguyen, Tom L writes:
> We decided to implement PCI Express error handling based on the PCI
> Express specification in a platform independent manner. This allows any
> platform that implements PCI Express AER per the PCI SIG specification
> can take advantage of the advanced features, much like
Nguyen, Tom L writes:
> Is EEH a PCI-SIG specification? Is EEH specs available in public?
No and no (not yet anyway).
> It seems that a PCI-PCI bridge per slot is hardware implementation
> specific. The fact that the PCI-PCI Bridge can isolate the slot is
> hardware feature specific.
Well,
Andrew Morton writes:
> I guess if the bss has zero length then we can skip the zeroing of the end
> of the page at the end of bss, as long as we're dead sure that we didn't
> accidentally instantiate a single page on behalf of that zero-length bss.
There is another thing I noticed about the bss
Alan Cox writes:
> On Iau, 2005-03-17 at 09:34, Paul Mackerras wrote:
> > This code needs real physical addresses, which are not the same things
> > as bus addresses.
>
> Not always. The code needs platform specific goodies. We've only never
> been burned so far b
Use the pSeries_reconfig notifier list to handle newly added pci
device nodes.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
arch/ppc64/kernel/pci_dn.c | 22 ++
arch/ppc64/kernel/prom.c | 14 ---
Use the pSeries_reconfig notifier list to fix up a device node which
is about to be added.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
arch/ppc64/kernel/prom.c | 40 ---
1 files changed, 31 inse
p.c | 183 +++-
arch/ppc64/kernel/setup.c | 12 --
arch/ppc64/kernel/smp.c | 13 --
include/asm-ppc64/machdep.h |1
4 files changed, 78 insertions(+), 131 deletions(-)
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras &
Use the pSeries_reconfig notifier chain for tearing down the iommu
table when a device node is removed.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
arch/ppc64/kernel/pSeries_iommu.c| 25 +++
arch/
, possibly looping forever if the length was
zero. This patch changes the behaviour to terminate the scan when a
corrupted partition is found.
Signed-off-by: Utz Bacher <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc64/kernel/nvram.c tes
allow 'xmon' or 'xmon=early' to enter xmon very early during boot.
allow 'xmon=on' to just enable it, or 'xmon=off' to disable it.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc64/kernel/setup.c test/arch/
During boot, pSeries_request_regions() should only request I/O ports for
legacy ISA in the case that ISA exists on the system. Add a check for
this. This patch was suggested by Anton.
Signed-off-by: John Rose <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
di
]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
arch/ppc64/kernel/pSeries_smp.c | 126
1 files changed, 126 insertions(+)
Index: linux-2.6.11-bk10/arch/ppc64/kernel/pSeries_smp.c
===
--- linux-2.6.1
. Patches to migrate code to the notifier api follow in this
series.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
arch/ppc64/kernel/Makefile |2
arch/ppc64/kernel/pSeries_reconfig.c | 446 +++
arch/ppc
801 - 900 of 1180 matches
Mail list logo
