was an internal symbol of the device system code
which was never meant for external use and has now gone away, and
thus the kernel fails to compile on pSeries.
The new version uses bus_find_device() on the vio bus (vio_bus_type).
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
Greg, do you want to send
Kamalesh Babulal writes:
> >>> NIP: 4570 LR: 0fc42dc0 CTR:
> >>> REGS: c0077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> >>> MSR: 80001000 CR: 28022422 XER:
> >>> DAR: c0077b6bfce0, DSISR: 0a00
Kamalesh Babulal writes:
> I tried reproducing the problem and was successful with following trace
> in which the pc is at 0x4570 as the above one
What did you do to trigger it?
> c0004544 :
> c0004544: 71 8a 40 00 andi. r10,r12,16384
> c0004548: 7c 2a
Andrew Morton writes:
> On Fri, 18 Jan 2008 14:06:00 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > Hi Andrew,
> >
> > Following oops was seen while running kernbench on one of test machine
> > (power4+ box). I tried reproducing the oops but was unsuccessful.
> > I will try to
Andrew Morton writes:
On Fri, 18 Jan 2008 14:06:00 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
Hi Andrew,
Following oops was seen while running kernbench on one of test machine
(power4+ box). I tried reproducing the oops but was unsuccessful.
I will try to reproduce the oops
Kamalesh Babulal writes:
I tried reproducing the problem and was successful with following trace
in which the pc is at 0x4570 as the above one
What did you do to trigger it?
c0004544 unrecov_slb:
c0004544: 71 8a 40 00 andi. r10,r12,16384
c0004548:
Kamalesh Babulal writes:
NIP: 4570 LR: 0fc42dc0 CTR:
REGS: c0077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
MSR: 80001000 ME CR: 28022422 XER:
DAR: c0077b6bfce0, DSISR: 0a00
Actually, how much RAM
Mathieu Desnoyers writes:
> Sorry for self-reply, but I thought, in the past, of a way to make this
> possible.
>
> It would imply the creation of a new vsyscall : vgetschedperiod
>
> It would read a counter that would increment each time the thread is
> scheduled out (or in). It would be a per
Mathieu Desnoyers writes:
Sorry for self-reply, but I thought, in the past, of a way to make this
possible.
It would imply the creation of a new vsyscall : vgetschedperiod
It would read a counter that would increment each time the thread is
scheduled out (or in). It would be a per thread
Harvey Harrison writes:
> Use a central is_kprobe_fault() inline in kprobes.h to remove all
> of the arch-dependant, practically identical implementations in
> avr32, ia64, powerpc, s390, sparc64, and x86.
I don't like the name "is_kprobe_fault" since the function actually
handles the fault -
Harvey Harrison writes:
Use a central is_kprobe_fault() inline in kprobes.h to remove all
of the arch-dependant, practically identical implementations in
avr32, ia64, powerpc, s390, sparc64, and x86.
I don't like the name is_kprobe_fault since the function actually
handles the fault - i.e. it
Andrew Morton writes:
> Maybe, but we can usually work around it pretty comfortably.
>
> If smu_set_fan() is only ever called by a kernel thread then we can simply
> flip it over to using wait_for_completion_interruptible().
>
> If smu_set_fan() is also called from user processes then things
Andrew Morton writes:
Maybe, but we can usually work around it pretty comfortably.
If smu_set_fan() is only ever called by a kernel thread then we can simply
flip it over to using wait_for_completion_interruptible().
If smu_set_fan() is also called from user processes then things aren't
Greg KH writes:
> Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
> devices that are mmaped, that makes a bit more sense.
>
> But I'd like to see what ioctl is wanted here first.
I believe the ioctl would be to set whether the mapping goes to I/O or
memory space, and whether
Greg KH writes:
Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
devices that are mmaped, that makes a bit more sense.
But I'd like to see what ioctl is wanted here first.
I believe the ioctl would be to set whether the mapping goes to I/O or
memory space, and whether
Dave Jones writes:
> drivers/macintosh/via-pmu.c: In function 'register_pmu_pm_ops':
> drivers/macintosh/via-pmu.c:2481: error: implicit declaration of function
> 'pm_set_ops'
What tree is this against? I don't see any occurrences of pmu_pm_ops
in either 2.6.23 or Linus' current tree, or in my
Dave Jones writes:
drivers/macintosh/via-pmu.c: In function 'register_pmu_pm_ops':
drivers/macintosh/via-pmu.c:2481: error: implicit declaration of function
'pm_set_ops'
What tree is this against? I don't see any occurrences of pmu_pm_ops
in either 2.6.23 or Linus' current tree, or in my
Christoph Hellwig writes:
> As Arnd said reusing an old system call slot seems rather dangerous,
> I'd rather avoid it.
Sure. I don't mind allocating a new syscall for this.
> But I wonder whether we really need a new
> syscall. Using 4k pages should basically be a pre-process flag
> (which
Christoph Hellwig writes:
As Arnd said reusing an old system call slot seems rather dangerous,
I'd rather avoid it.
Sure. I don't mind allocating a new syscall for this.
But I wonder whether we really need a new
syscall. Using 4k pages should basically be a pre-process flag
(which it
used it.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 232c298..0f5b968 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -340,6 +340,14 @@ config PPC_64K_PAGES
while on hardware with such s
used it.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 232c298..0f5b968 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -340,6 +340,14 @@ config PPC_64K_PAGES
while on hardware with such support
Christoph Lameter writes:
> On Wed, 28 Nov 2007, Paul Mackerras wrote:
>
> > Did you try both 32-bit (CONFIG_64BIT=n) and 64-bit (CONFIG_64BIT=y)
> > configurations? The paca only exists in 64-bit kernels.
>
> I build both and there is no dependency on 32bit or 64 bit i
Christoph Lameter writes:
> On Tue, 27 Nov 2007, Kumar Gala wrote:
>
> > > Index: linux-2.6/include/asm-powerpc/percpu.h
> > > ===
> > > --- linux-2.6.orig/include/asm-powerpc/percpu.h 2007-11-24
> > > 10:27:31.088350556 -0800
> >
Johannes Berg writes:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I see it on my G4 powerbook. However, a compute-bound task runs just
as
Johannes Berg writes:
Contrary to what I claimed later in the thread, my 64-bit powerpc box
(quad-core G5) doesn't suffer from this problem.
Does anybody have any idea? I don't even know how to debug it further.
I see it on my G4 powerbook. However, a compute-bound task runs just
as fast
Christoph Lameter writes:
On Tue, 27 Nov 2007, Kumar Gala wrote:
Index: linux-2.6/include/asm-powerpc/percpu.h
===
--- linux-2.6.orig/include/asm-powerpc/percpu.h 2007-11-24
10:27:31.088350556 -0800
+++
Christoph Lameter writes:
On Wed, 28 Nov 2007, Paul Mackerras wrote:
Did you try both 32-bit (CONFIG_64BIT=n) and 64-bit (CONFIG_64BIT=y)
configurations? The paca only exists in 64-bit kernels.
I build both and there is no dependency on 32bit or 64 bit in
include/asm-powerpc/percpu.h
H. Peter Anvin writes:
> There was, at some point, discussion about using the gcc TLS mechanism,
> which should permit even better code to be generated. Unfortunately, it
> would require gcc to be able to reference %gs instead of %fs (and vice
> versa for i386), which I don't think is
David Miller writes:
> As a result I've found that perfmon2 is quite nice and allows
> incredibly useful and powerful tools to be written. The syscalls
> aren't that bad and really I see not reason to block it's inclusion.
>
> I rescind all of my earlier objections, let's merge this soon :-)
David Miller writes:
As a result I've found that perfmon2 is quite nice and allows
incredibly useful and powerful tools to be written. The syscalls
aren't that bad and really I see not reason to block it's inclusion.
I rescind all of my earlier objections, let's merge this soon :-)
H. Peter Anvin writes:
There was, at some point, discussion about using the gcc TLS mechanism,
which should permit even better code to be generated. Unfortunately, it
would require gcc to be able to reference %gs instead of %fs (and vice
versa for i386), which I don't think is available
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.
-
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.
-
To
dean gaudet writes:
> actually multiplexing is the main feature i am in need of. there are an
> insufficient number of counters (even on k8 with 4 counters) to do
> complete stall accounting or to get a general overview of L1d/L1i/L2 cache
> hit rates, average miss latency, time spent in
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 12:11:10 +1100
>
> > The third (hard to extend cleanly) is a good point, and is a valid
> > criticism of the current set of perfmon2 system calls, I think.
> > However,
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 10:12:22 +1100
>
> > *I* never had a problem with a few extra system calls. I don't
> > understand why you (apparently) do.
>
> We're stuck with them forever, they are har
Andi Kleen writes:
> > This only works when counting (not sampling) and only for self-monitoring.
>
> It works for global monitoring too.
How would you provide access to the counters of another process?
Through an extension to ptrace perhaps?
Paul.
-
To unsubscribe from this list: send the
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 08:50:22 +1100
>
> > I'd prefer to have a transaction() system call like I suggested to
> > Nick rather than overloading read() like this.
>
> So much for getting rid of the
David Miller writes:
> > You're suggesting that the behaviour of a read() should depend on what
> > was in the buffer before the read? Gack! Surely you have better
> > taste than that?
>
> Absolutely that's what I mean, it's atomic and gives you exactly what
> you need.
>
> I see nothing
Nick Piggin writes:
> What I really mean is a readv-like syscall, but one that also
> vectorises the file offset. Maybe this is useful enough as a generic
> syscall that also helps Paul's example...
I've sometimes thought it would be useful to have a "transaction"
system call that is like a
David Miller writes:
> The same way we handle some of the multicast "getsockopt()"
> calls. The parameters passed in are both inputs and outputs.
For a read??!!!
> For the above example:
>
> struct pmd_info {
> int *pmd_numbers;
> u64 *pmd_values;
>
Christoph Hellwig writes:
> int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
>
> This is basically a read(2) (or for other syscalls a write) on something
> else than the file descriptor provided to the system call.
No it's not basically a read(). It's more like a request/reply
interface,
David Miller writes:
> This is my impression too, all of the things being done with
> a slew of system calls would be better served by real special
> files and appropriate fops.
Special files and fops really only work well if you can coerce the
interface into one where data flows predominantly
Christoph Hellwig writes:
> Mine for example. The whole userspace interface is just on crack,
> and the code is full of complexities aswell.
Could you give some _technical_ details of what you don't like?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Christoph Hellwig writes:
Mine for example. The whole userspace interface is just on crack,
and the code is full of complexities aswell.
Could you give some _technical_ details of what you don't like?
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
David Miller writes:
This is my impression too, all of the things being done with
a slew of system calls would be better served by real special
files and appropriate fops.
Special files and fops really only work well if you can coerce the
interface into one where data flows predominantly one
Christoph Hellwig writes:
int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
This is basically a read(2) (or for other syscalls a write) on something
else than the file descriptor provided to the system call.
No it's not basically a read(). It's more like a request/reply
interface,
David Miller writes:
The same way we handle some of the multicast getsockopt()
calls. The parameters passed in are both inputs and outputs.
For a read??!!!
For the above example:
struct pmd_info {
int *pmd_numbers;
u64 *pmd_values;
int
David Miller writes:
You're suggesting that the behaviour of a read() should depend on what
was in the buffer before the read? Gack! Surely you have better
taste than that?
Absolutely that's what I mean, it's atomic and gives you exactly what
you need.
I see nothing wrong or gross
Nick Piggin writes:
What I really mean is a readv-like syscall, but one that also
vectorises the file offset. Maybe this is useful enough as a generic
syscall that also helps Paul's example...
I've sometimes thought it would be useful to have a transaction
system call that is like a write +
David Miller writes:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 15 Nov 2007 08:50:22 +1100
I'd prefer to have a transaction() system call like I suggested to
Nick rather than overloading read() like this.
So much for getting rid of the extra system calls...
*I* never had
Andi Kleen writes:
This only works when counting (not sampling) and only for self-monitoring.
It works for global monitoring too.
How would you provide access to the counters of another process?
Through an extension to ptrace perhaps?
Paul.
-
To unsubscribe from this list: send the line
David Miller writes:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 15 Nov 2007 10:12:22 +1100
*I* never had a problem with a few extra system calls. I don't
understand why you (apparently) do.
We're stuck with them forever, they are hard to version and extend
cleanly.
Those
David Miller writes:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 15 Nov 2007 12:11:10 +1100
The third (hard to extend cleanly) is a good point, and is a valid
criticism of the current set of perfmon2 system calls, I think.
However, the goal of being able to extend the interface
dean gaudet writes:
actually multiplexing is the main feature i am in need of. there are an
insufficient number of counters (even on k8 with 4 counters) to do
complete stall accounting or to get a general overview of L1d/L1i/L2 cache
hit rates, average miss latency, time spent in various
Andrew Morton writes:
> I was hoping that after the round of release-and-review which Stephane,
> Andi and I did about twelve months ago that we were on track to merge the
> perfmon codebase as-offered. But now it turns out that the sentiment is
> that the code simply has too many
Andrew Morton writes:
I was hoping that after the round of release-and-review which Stephane,
Andi and I did about twelve months ago that we were on track to merge the
perfmon codebase as-offered. But now it turns out that the sentiment is
that the code simply has too many bells-and-whistles
David Miller writes:
> On x86 only. We could use force_successful_syscall_return()
> to make sure the condition codes get set correctly on
> other platforms.
>
> But even in that case we'd still be broken when the return
> value is exactly -1 and that's what the application is going
> to
David Miller writes:
On x86 only. We could use force_successful_syscall_return()
to make sure the condition codes get set correctly on
other platforms.
But even in that case we'd still be broken when the return
value is exactly -1 and that's what the application is going
to compare
Andrew Morton writes:
> Yup. But userspace will already have a fit if either the start or end time
> advanced into the glibc-thought-that-was-an-error range.
Not nearly as much of a fit. The effect on x86 is that values between
-4095 and -1 are reported as -1, so the end-start difference will
David Miller writes:
> I can't see where x86 is doing this though, so perhaps for x86
> glibc does make the negative value check. But I doubt it is
> checking the range 0x8000-0x, otherwise mmap() would
> be busted.
At least for the INTERNAL_SYSCALL macro in glibc, the error check
Andrew Morton writes:
> "the latter" is what my protopatch does isn't it? It wraps at 0x7fff.
> It appears that glibc treats all of 0x8000-0x as an error.
Not on powerpc. On powerpc the error indication is carried separately
in a condition register bit. So a
Andrew Morton writes:
> Given all this stuff, the return value from sys_times() doesn't seem a
> particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from copy_to_user
and always return the number of clock ticks. We should call
Andrew Morton writes:
Yup. But userspace will already have a fit if either the start or end time
advanced into the glibc-thought-that-was-an-error range.
Not nearly as much of a fit. The effect on x86 is that values between
-4095 and -1 are reported as -1, so the end-start difference will be
Andrew Morton writes:
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from copy_to_user
and always return the number of clock ticks. We should call
Andrew Morton writes:
the latter is what my protopatch does isn't it? It wraps at 0x7fff.
It appears that glibc treats all of 0x8000-0x as an error.
Not on powerpc. On powerpc the error indication is carried separately
in a condition register bit. So a
David Miller writes:
I can't see where x86 is doing this though, so perhaps for x86
glibc does make the negative value check. But I doubt it is
checking the range 0x8000-0x, otherwise mmap() would
be busted.
At least for the INTERNAL_SYSCALL macro in glibc, the error check is:
account_process_tick().
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
account_process_tick now takes the task_struct * as an argument.
Tested both with and without CONFIG_VIRT_CPU_ACCOUNTING.
arch/powerpc/kernel/process.c |2 +-
arch/powerpc/kernel/time.c| 25 +
Balbir Singh writes:
> So, scaled accounting will not be available if
> CONFIG_VIRT_CPU_ACCOUNTING is defined? Am I reading this correctly
No, what makes you think that? If VIRT_CPU_ACCOUNTING=y it is the
responsibility of the arch's account_process_tick to update the scaled
stats. And the
Ingo Molnar writes:
> hm, i've removed it for now because it doesnt even build due toj:
*blush*
New patch coming. Sending it to Linus via the scheduler tree sounds
fine to me.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Ingo Molnar writes:
hm, i've removed it for now because it doesnt even build due toj:
*blush*
New patch coming. Sending it to Linus via the scheduler tree sounds
fine to me.
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Balbir Singh writes:
So, scaled accounting will not be available if
CONFIG_VIRT_CPU_ACCOUNTING is defined? Am I reading this correctly
No, what makes you think that? If VIRT_CPU_ACCOUNTING=y it is the
responsibility of the arch's account_process_tick to update the scaled
stats. And the
account_process_tick().
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
account_process_tick now takes the task_struct * as an argument.
Tested both with and without CONFIG_VIRT_CPU_ACCOUNTING.
arch/powerpc/kernel/process.c |2 +-
arch/powerpc/kernel/time.c| 25 +
arch
Linus Torvalds writes:
> and wouldn't it be nice if we just changed it to
>
> #include
>
> and got rid of one totally unnecessary stupid arch difference?
Looks fine to me. I'll do a patch for powerpc & ppc.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe
Linus Torvalds writes:
and wouldn't it be nice if we just changed it to
#include asm/i8253.h
and got rid of one totally unnecessary stupid arch difference?
Looks fine to me. I'll do a patch for powerpc ppc.
Paul.
-
To unsubscribe from this list: send the line unsubscribe
Jan Kara writes:
> I've just found out that operations like constant_test_bit() take pointer
> of different types on different architectures. In particular, x86_64,
> blackfin and frv take void * while i386, s390 and m68k take unsigned long
> *. Is this intended difference? Wouldn't using void
account_process_tick().
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
I don't know who maintains kernel/timer.c, but I assume it's one of
Ingo, Peter Z. or Thomas.
In fact the arch bits here don't need to go in at the same time as the
changes to include/linux/sched.h and kernel/timer.c, but co
account_process_tick().
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
I don't know who maintains kernel/timer.c, but I assume it's one of
Ingo, Peter Z. or Thomas.
In fact the arch bits here don't need to go in at the same time as the
changes to include/linux/sched.h and kernel/timer.c, but could go
Jan Kara writes:
I've just found out that operations like constant_test_bit() take pointer
of different types on different architectures. In particular, x86_64,
blackfin and frv take void * while i386, s390 and m68k take unsigned long
*. Is this intended difference? Wouldn't using void *
Linus Torvalds writes:
> Nobody should *ever* walk the list to find the length. Does anybody really
> do that? Yes, we pass the thing down, but do people *need* it?
Yes, I need it for devices that use the macintosh DBDMA
(descriptor-based DMA) hardware. The DBDMA hardware reads an array of
Linus Torvalds writes:
Nobody should *ever* walk the list to find the length. Does anybody really
do that? Yes, we pass the thing down, but do people *need* it?
Yes, I need it for devices that use the macintosh DBDMA
(descriptor-based DMA) hardware. The DBDMA hardware reads an array of
Kamalesh Babulal writes:
> The kernel build fails on the power box
>
> INSTALL vdso64.so
>
> INSTALL vdso32.so
>
> BOOTCC arch/powerpc/boot/inflate.o
>
> arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory
This problem is fixed by
Kamalesh Babulal writes:
The kernel build fails on the power box
INSTALL vdso64.so
INSTALL vdso32.so
BOOTCC arch/powerpc/boot/inflate.o
arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory
This problem is fixed by
Andrew Morton writes:
> On Sat, 13 Oct 2007 10:14:22 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > The functions virt_to_bus and bus_to_virt are begin defined between ifdef
> > CONFIG_PPC32
> > but when i compile allyesconfig with ppc64 box,i get this error. This patch
> > removes the
Andrew Morton writes:
On Sat, 13 Oct 2007 10:14:22 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
The functions virt_to_bus and bus_to_virt are begin defined between ifdef
CONFIG_PPC32
but when i compile allyesconfig with ppc64 box,i get this error. This patch
removes the
ifdef.
Olof Johansson writes:
> Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
> 4K text on a ppc64_defconfig. The main reason seems to be that prepping
> the arguments to the conditional trap instructions is more work than
> just doing a compare and branch.
It might be more
Kumar Gala writes:
> > ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
> > conjunction with a function called elf_core_copy_task_xfpregs().
>
> agreed, I think the function name should change as well.
Maybe. Let's do one step at a time...
Paul.
-
To unsubscribe from this
Kumar Gala writes:
> > #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
> > there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
> to the x86 specific name?
How is "extended floating point registers" x86-specific?
Kumar Gala writes:
#define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
there's are no change in behaviour.
Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
to the x86 specific name?
How is extended floating point registers x86-specific?
Kumar Gala writes:
ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
conjunction with a function called elf_core_copy_task_xfpregs().
agreed, I think the function name should change as well.
Maybe. Let's do one step at a time...
Paul.
-
To unsubscribe from this list:
Olof Johansson writes:
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than
just doing a compare and branch.
It might be more
Olof Johansson writes:
> Don't allow cpu hotplug on systems lacking XICS interrupt controller,
> since current code is hardcoded for it.
...
> + for (np = NULL; (np = of_find_node_by_name(np,
> +"interrupt-controller"));) {
Looks like
Linus Torvalds writes:
> On Wed, 10 Oct 2007, Thomas Gleixner wrote:
> >
> > Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
>
> Well, the ppc oops seems to be a ppc bug regardless.
Sure. And Milton and Olof have figured out what the problem is and
proposed patches to fix it.
Linus Torvalds writes:
On Wed, 10 Oct 2007, Thomas Gleixner wrote:
Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
Well, the ppc oops seems to be a ppc bug regardless.
Sure. And Milton and Olof have figured out what the problem is and
proposed patches to fix it.
However, I'm
Olof Johansson writes:
Don't allow cpu hotplug on systems lacking XICS interrupt controller,
since current code is hardcoded for it.
...
+ for (np = NULL; (np = of_find_node_by_name(np,
+interrupt-controller));) {
Looks like
Linus Torvalds writes:
> Well, since others definitely don't see this, including me, and I can do
> things like 62MB exec arrays:
>
> [EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
> 1 883304 63000962
That wouldn't actually do an exec, assuming you're using
Linus Torvalds writes:
Well, since others definitely don't see this, including me, and I can do
things like 62MB exec arrays:
[EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
1 883304 63000962
That wouldn't actually do an exec, assuming you're using bash,
Joachim Fenkes writes:
> Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> and struct of_platform_driver, respectively. Match the external ibmebus
> interface and drivers using it.
>
> Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
> ---
>
Joachim Fenkes writes:
Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
and struct of_platform_driver, respectively. Match the external ibmebus
interface and drivers using it.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
Mathieu Desnoyers writes:
> Make sure that at least cmpxchg64_local is available on all architectures to
> use
> for unsigned long long values.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
-
To unsubscribe fr
301 - 400 of 1180 matches
Mail list logo
