* [PATCH 1/3] perf_event: Add alignment-faults and emulation-faults software events
From: Anton Blanchard @ 2009-10-18 11:09 UTC (permalink / raw)
To: benh, mingo, paulus, a.p.zijlstra; +Cc: linuxppc-dev, linux-kernel
Add two more sw events that are common to many cpus.
Alignment faults: When a load or store is not aligned properly.
Emulation faults: When an instruction is emulated in software.
Both cause a very significant slowdown (100x or worse), so identifying and
fixing them is very important.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/include/linux/perf_event.h
===================================================================
--- linux.trees.git.orig/include/linux/perf_event.h 2009-10-16 11:17:17.000000000 +1100
+++ linux.trees.git/include/linux/perf_event.h 2009-10-16 11:17:29.000000000 +1100
@@ -102,6 +102,8 @@ enum perf_sw_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_MAX, /* non-ABI */
};
Index: linux.trees.git/include/linux/perf_counter.h
===================================================================
--- linux.trees.git.orig/include/linux/perf_counter.h 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/include/linux/perf_counter.h 2009-10-16 11:17:29.000000000 +1100
@@ -106,6 +106,8 @@ enum perf_sw_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_MAX, /* non-ABI */
};
Index: linux.trees.git/kernel/perf_event.c
===================================================================
--- linux.trees.git.orig/kernel/perf_event.c 2009-10-16 11:17:17.000000000 +1100
+++ linux.trees.git/kernel/perf_event.c 2009-10-16 11:17:29.000000000 +1100
@@ -4255,6 +4255,8 @@ static const struct pmu *sw_perf_event_i
case PERF_COUNT_SW_PAGE_FAULTS_MAJ:
case PERF_COUNT_SW_CONTEXT_SWITCHES:
case PERF_COUNT_SW_CPU_MIGRATIONS:
+ case PERF_COUNT_SW_ALIGNMENT_FAULTS:
+ case PERF_COUNT_SW_EMULATION_FAULTS:
if (!event->parent) {
atomic_inc(&perf_swevent_enabled[event_id]);
event->destroy = sw_perf_event_destroy;
Index: linux.trees.git/tools/perf/design.txt
===================================================================
--- linux.trees.git.orig/tools/perf/design.txt 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/tools/perf/design.txt 2009-10-16 11:17:29.000000000 +1100
@@ -137,6 +137,8 @@ enum sw_event_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
};
Counters of the type PERF_TYPE_TRACEPOINT are available when the ftrace event
Index: linux.trees.git/tools/perf/util/parse-events.c
===================================================================
--- linux.trees.git.orig/tools/perf/util/parse-events.c 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/tools/perf/util/parse-events.c 2009-10-16 11:17:29.000000000 +1100
@@ -47,6 +47,8 @@ static struct event_symbol event_symbols
{ CSW(PAGE_FAULTS_MAJ), "major-faults", "" },
{ CSW(CONTEXT_SWITCHES), "context-switches", "cs" },
{ CSW(CPU_MIGRATIONS), "cpu-migrations", "migrations" },
+ { CSW(ALIGNMENT_FAULTS), "alignment-faults", "" },
+ { CSW(EMULATION_FAULTS), "emulation-faults", "" },
};
#define __PERF_EVENT_FIELD(config, name) \
@@ -75,6 +77,8 @@ static const char *sw_event_names[] = {
"CPU-migrations",
"minor-faults",
"major-faults",
+ "alignment-faults",
+ "emulation-faults",
};
#define MAX_ALIASES 8
^ permalink raw reply
* Re: [PATCH] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Anton Blanchard @ 2009-10-18 11:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frederic Weisbecker, Ingo Molnar, linuxppc-dev, Steven Rostedt
In-Reply-To: <1255501071.2347.42.camel@pasglop>
Hi Ben,
> Breaks 6xx_defconfig:
Yuck. Since the CREATE_TRACE_POINTS stuff appears to need a non trivial number
of includes it might be best just to fold it into one of the tracepoint call
sites like this.
--
This patch adds powerpc specific tracepoints for interrupt entry and exit.
While we already have generic irq_handler_entry and irq_handler_exit
tracepoints there are cases on our virtualised powerpc machines where an
interrupt is presented to the OS, but subsequently handled by the hypervisor.
This means no OS interrupt handler is invoked.
Here is an example on a POWER6 machine with the patch below applied:
<idle>-0 [006] 3243.949840744: irq_entry: pt_regs=c0000000ce31fb10
<idle>-0 [006] 3243.949850520: irq_exit: pt_regs=c0000000ce31fb10
<idle>-0 [007] 3243.950218208: irq_entry: pt_regs=c0000000ce323b10
<idle>-0 [007] 3243.950224080: irq_exit: pt_regs=c0000000ce323b10
<idle>-0 [000] 3244.021879320: irq_entry: pt_regs=c000000000a63aa0
<idle>-0 [000] 3244.021883616: irq_handler_entry: irq=87 handler=eth0
<idle>-0 [000] 3244.021887328: irq_handler_exit: irq=87 return=handled
<idle>-0 [000] 3244.021897408: irq_exit: pt_regs=c000000000a63aa0
Here we see two phantom interrupts (no handler was invoked), followed
by a real interrupt for eth0. Without the tracepoints in this patch we
would have missed the phantom interrupts.
Since these would be the first arch specific tracepoints, I'd like to make
sure we agree on naming. The tracepoints live in events/powerpc/*, but I'm
wondering if the tracepoint name should also contain the arch name, eg
powerpc_irq_entry/powerpc_irq_exit. Thoughts?
Signed-off-by: Anton Blanchard <anton@samba.org>
--
Index: linux.trees.git/arch/powerpc/include/asm/trace.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux.trees.git/arch/powerpc/include/asm/trace.h 2009-10-17 08:45:08.000000000 +1100
@@ -0,0 +1,53 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM powerpc
+
+#if !defined(_TRACE_POWERPC_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_POWERPC_H
+
+#include <linux/tracepoint.h>
+
+struct pt_regs;
+
+TRACE_EVENT(irq_entry,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs),
+
+ TP_STRUCT__entry(
+ __field(struct pt_regs *, regs)
+ ),
+
+ TP_fast_assign(
+ __entry->regs = regs;
+ ),
+
+ TP_printk("pt_regs=%p", __entry->regs)
+);
+
+TRACE_EVENT(irq_exit,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs),
+
+ TP_STRUCT__entry(
+ __field(struct pt_regs *, regs)
+ ),
+
+ TP_fast_assign(
+ __entry->regs = regs;
+ ),
+
+ TP_printk("pt_regs=%p", __entry->regs)
+);
+
+#endif /* _TRACE_POWERPC_H */
+
+#undef TRACE_INCLUDE_PATH
+#undef TRACE_INCLUDE_FILE
+
+#define TRACE_INCLUDE_PATH asm
+#define TRACE_INCLUDE_FILE trace
+
+#include <trace/define_trace.h>
Index: linux.trees.git/arch/powerpc/kernel/irq.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/irq.c 2009-10-17 08:44:32.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/irq.c 2009-10-17 08:45:44.000000000 +1100
@@ -70,6 +70,8 @@
#include <asm/firmware.h>
#include <asm/lv1call.h>
#endif
+#define CREATE_TRACE_POINTS
+#include <asm/trace.h>
int __irq_offset_value;
static int ppc_spurious_interrupts;
@@ -325,6 +327,8 @@ void do_IRQ(struct pt_regs *regs)
struct pt_regs *old_regs = set_irq_regs(regs);
unsigned int irq;
+ trace_irq_entry(regs);
+
irq_enter();
check_stack_overflow();
@@ -348,6 +352,8 @@ void do_IRQ(struct pt_regs *regs)
timer_interrupt(regs);
}
#endif
+
+ trace_irq_exit(regs);
}
void __init init_IRQ(void)
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-18 9:38 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Adrian Hunter
In-Reply-To: <20091016153128.GA11838@loki.buserror.net>
Hi, Scott
Scott Wood wrote:
> On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote:
>> Thanks for confirmation. So the real problem is eLBC ?
>> What happens if I access other devices on eLBC (e.g. FPGA)
>> simultaneously with NAND or NOR ?
>
> AFAICT, the problem is NAND being accessed simultaneously with anything else
> on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the
> memory-like transaction until the NAND special operation has completed, it
> seems to just abort the NAND operation.
>
> eLBC can't really tell the difference whether you've got NOR or FPGA hooked
> up to a GPCM chip select, so the problem should still apply.
>
Can you please provide some code example of synchronizing GPCM and NAND ?
I may try implementing the NOR mapping driver you were talking about.
Thanks.
Felix.
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Timur Tabi @ 2009-10-17 23:17 UTC (permalink / raw)
To: Hendrik Brueckner, Scott Wood, Christian Borntraeger,
linuxppc-dev, Timur Tabi, Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20091016084924.GB4234@linux.vnet.ibm.com>
On Fri, Oct 16, 2009 at 3:49 AM, Hendrik Brueckner
<brueckner@linux.vnet.ibm.com> wrote:
> The states are handled by the hvc_iucv itself:
> If the hvc_iucv code has a connection established, terminal or console data
> are queued and sent to the peer. If the state is disconnected, terminal and
> console data is discarded internally.
So what is the plan now?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Wolfgang Denk @ 2009-10-17 19:34 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFEC00B9FB.B03AA854-ONC1257652.00644350-C1257652.00651551@transmode.se>
Dear Joakim Tjernlund,
In message <OFEC00B9FB.B03AA854-ONC1257652.00644350-C1257652.00651551@transmode.se> you wrote:
>
> > Recompile and relink it with soft-fp as well. Or ask the provider to
> > do that.
>
> That is what I am trying do/find out. The supplier claims that
> it should not be a problem and is ATM unwilling to recompile the app/libs.
> I am not convinced won't cause problems, not to mention performance degradation.
If the application is really using FP instructions a lot, then there
is a huge difference between using soft-float and MATH_EMU; I
remember test cases where soft-float was faster by factors of
500...1000.
> OK, but then you don't mix some libs/apps with soft and other
> apps/libs with hard FP?
No, we never tried that. Sounds scary to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The connection between the language in which we think/program and the
problems and solutions we can imagine is very close. For this reason
restricting language features with the intent of eliminating pro-
grammer errors is at best dangerous.
- Bjarne Stroustrup in "The C++ Programming Language"
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Joakim Tjernlund @ 2009-10-17 18:24 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091017181224.97FFBF15432@gemini.denx.de>
Wolfgang Denk <wd@denx.de> wrote on 17/10/2009 20:12:24:
>
> Dear Joakim Tjernlund,
>
> In message <OFC920E57F.DFABC29F-ONC1257652.00421E11-C1257652.
> 0043478A@transmode.se> you wrote:
> >
> > Anyone tried mixing hard and soft FP in on soft float CPU such as 83xx?
>
> Hm... most 83xx have a FPU.
Yeah, I meant 832x. These don't have a FPU
>
> > Been trying to figure out if this is a good idea or not.
> > Any combinations that will or won't work?
>
> What exactly do you mean by "mixing"? You cannot (at least not with
> any reasonable effort) mix hard and soft FP in the same application /
> linked object. And it would be pretty difficult to setup separate
> libraries for and all that stuff for both hard and soft FP binaries
> in one system.
I meant on per app or per lib basis, not within the same
app/lib.
>
> I doubt if such a setup makes sense at all.
>
> > Generally I got soft FP in all system libs but there might be
> > an binary application which will use hard FP.
>
> Recompile and relink it with soft-fp as well. Or ask the provider to
> do that.
That is what I am trying do/find out. The supplier claims that
it should not be a problem and is ATM unwilling to recompile the app/libs.
I am not convinced won't cause problems, not to mention performance degradation.
>
> > Is the MATH_EMU option in the kernel reliable(for 8xx too)?
>
> It's reliable enough to install and run standard distributions like
> Debian, Ubuntu, or Fedora, but I have to admit that we haven't stress
> tested any special FP test suites in such an environment. In everyday
> use I didn't see any real issues, though.
OK, but then you don't mix some libs/apps with soft and other
apps/libs with hard FP?
Jocke
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Wolfgang Denk @ 2009-10-17 18:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFC920E57F.DFABC29F-ONC1257652.00421E11-C1257652.0043478A@transmode.se>
Dear Joakim Tjernlund,
In message <OFC920E57F.DFABC29F-ONC1257652.00421E11-C1257652.0043478A@transmode.se> you wrote:
>
> Anyone tried mixing hard and soft FP in on soft float CPU such as 83xx?
Hm... most 83xx have a FPU.
> Been trying to figure out if this is a good idea or not.
> Any combinations that will or won't work?
What exactly do you mean by "mixing"? You cannot (at least not with
any reasonable effort) mix hard and soft FP in the same application /
linked object. And it would be pretty difficult to setup separate
libraries for and all that stuff for both hard and soft FP binaries
in one system.
I doubt if such a setup makes sense at all.
> Generally I got soft FP in all system libs but there might be
> an binary application which will use hard FP.
Recompile and relink it with soft-fp as well. Or ask the provider to
do that.
> Is the MATH_EMU option in the kernel reliable(for 8xx too)?
It's reliable enough to install and run standard distributions like
Debian, Ubuntu, or Fedora, but I have to admit that we haven't stress
tested any special FP test suites in such an environment. In everyday
use I didn't see any real issues, though.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I can have honesty, it's easier to overlook mistakes.
-- Kirk, "Space Seed", stardate 3141.9
^ permalink raw reply
* Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-17 15:42 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: fenghua.yu, gregkh, tglx, tony.luck, x86, netdev, linux-kernel,
linux-altix, yevgenyp, linuxppc-dev, mingo, paulus, hpa,
sparclinux, linux-ia64, akpm, linux-usb, davem, LW
In-Reply-To: <20091017235117U.fujita.tomonori@lab.ntt.co.jp>
>> >> --- a/lib/iommu-helper.c
>> >> +++ b/lib/iommu-helper.c
>> >> @@ -19,7 +19,7 @@ again:
>> >> =A0 =A0 =A0 index =3D (index + align_mask) & ~align_mask;
>> >>
>> >> =A0 =A0 =A0 end =3D index + nr;
>> >> - =A0 =A0 if (end >=3D size)
>> >> + =A0 =A0 if (end > size)
>> >
>> > I think that this is intentional; the last byte of the limit doesn't
>> > work.
>>
>> It looks ok to me. Without above change, find_next_zero_area cannot
>> find a 64 bits zeroed area in next sample code.
>
> I meant that we don't want to find such area for IOMMUs (IIRC, it code
> came from POWER IOMMU).
OK, I see. I think we need the comment about it.
So we cannot replace find_next_zero_area by bitmap_find_next_zero_area
and current -mmotm has the bug introduced by this patch in iommu-helper
and I also introduced the bug in bitmap_find_next_zero_area if
align_mask !=3D 0 in
bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area-fix.pat=
ch
Andrew, please drop
lib-iommu-helperc-fix-off-by-one-error-in-find_next_zero_area.patch
iommu-helper-simplify-find_next_zero_area.patch
bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area.patch
bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area-fix.pat=
ch
iommu-helper-use-bitmap-library.patch
isp1362-hcd-use-bitmap_find_next_zero_area.patch
mlx4-use-bitmap_find_next_zero_area.patch
sparc-use-bitmap_find_next_zero_area.patch
ia64-use-bitmap_find_next_zero_area.patch
genalloc-use-bitmap_find_next_zero_area.patch
I'll overhaul the patchset and retry again.
^ permalink raw reply
* Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: FUJITA Tomonori @ 2009-10-17 14:51 UTC (permalink / raw)
To: akinobu.mita
Cc: linux-usb, linux-ia64, linuxppc-dev, paulus, hpa, sparclinux, LW,
x86, linux-altix, mingo, fenghua.yu, yevgenyp, tglx, tony.luck,
netdev, gregkh, linux-kernel, fujita.tomonori, akpm, davem
In-Reply-To: <961aa3350910170743n4c9947d1ka0bd31aa1c7b9917@mail.gmail.com>
On Sat, 17 Oct 2009 23:43:56 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 2009/10/17 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>:
> > On Tue, 13 Oct 2009 18:10:17 +0900
> > Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> >> My user space testing exposed off-by-one error find_next_zero_area
> >> in iommu-helper. Some zero area cannot be found by this bug.
> >>
> >> Subject: [PATCH] Fix off-by-one error in find_next_zero_area
> >>
> >> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> >> ---
> >> =A0lib/iommu-helper.c | =A0 =A02 +-
> >> =A01 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> >> index 75dbda0..afc58bc 100644
> >> --- a/lib/iommu-helper.c
> >> +++ b/lib/iommu-helper.c
> >> @@ -19,7 +19,7 @@ again:
> >> =A0 =A0 =A0 index =3D (index + align_mask) & ~align_mask;
> >>
> >> =A0 =A0 =A0 end =3D index + nr;
> >> - =A0 =A0 if (end >=3D size)
> >> + =A0 =A0 if (end > size)
> >
> > I think that this is intentional; the last byte of the limit doesn't=
> > work.
> =
> It looks ok to me. Without above change, find_next_zero_area cannot
> find a 64 bits zeroed area in next sample code.
I meant that we don't want to find such area for IOMMUs (IIRC, it code
came from POWER IOMMU).
> unsigned long offset;
> =
> DECLARE_BITMAP(map, 64);
> =
> bitmap_clear(map, 0, 64);
> offset =3D find_next_zero_area(map, 64, 0, 64, 0);
> if (offset >=3D 64)
> printf("not found\n");
> else
> printf("found\n");
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-17 14:43 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: fenghua.yu, gregkh, tglx, tony.luck, x86, netdev, linux-kernel,
linux-altix, yevgenyp, linuxppc-dev, mingo, paulus, hpa,
sparclinux, linux-ia64, akpm, linux-usb, davem, LW
In-Reply-To: <20091017224028V.fujita.tomonori@lab.ntt.co.jp>
2009/10/17 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>:
> On Tue, 13 Oct 2009 18:10:17 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
>
>> My user space testing exposed off-by-one error find_next_zero_area
>> in iommu-helper. Some zero area cannot be found by this bug.
>>
>> Subject: [PATCH] Fix off-by-one error in find_next_zero_area
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> ---
>> =A0lib/iommu-helper.c | =A0 =A02 +-
>> =A01 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
>> index 75dbda0..afc58bc 100644
>> --- a/lib/iommu-helper.c
>> +++ b/lib/iommu-helper.c
>> @@ -19,7 +19,7 @@ again:
>> =A0 =A0 =A0 index =3D (index + align_mask) & ~align_mask;
>>
>> =A0 =A0 =A0 end =3D index + nr;
>> - =A0 =A0 if (end >=3D size)
>> + =A0 =A0 if (end > size)
>
> I think that this is intentional; the last byte of the limit doesn't
> work.
It looks ok to me. Without above change, find_next_zero_area cannot
find a 64 bits zeroed area in next sample code.
unsigned long offset;
DECLARE_BITMAP(map, 64);
bitmap_clear(map, 0, 64);
offset =3D find_next_zero_area(map, 64, 0, 64, 0);
if (offset >=3D 64)
printf("not found\n");
else
printf("found\n");
^ permalink raw reply
* Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: FUJITA Tomonori @ 2009-10-17 13:43 UTC (permalink / raw)
To: akinobu.mita
Cc: linux-usb, linux-ia64, linuxppc-dev, paulus, hpa, sparclinux, LW,
x86, linux-altix, mingo, fenghua.yu, yevgenyp, tglx, tony.luck,
netdev, gregkh, linux-kernel, fujita.tomonori, akpm, davem
In-Reply-To: <20091013091017.GA18431@localhost.localdomain>
On Tue, 13 Oct 2009 18:10:17 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:
> My user space testing exposed off-by-one error find_next_zero_area
> in iommu-helper. Some zero area cannot be found by this bug.
>
> Subject: [PATCH] Fix off-by-one error in find_next_zero_area
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> lib/iommu-helper.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> index 75dbda0..afc58bc 100644
> --- a/lib/iommu-helper.c
> +++ b/lib/iommu-helper.c
> @@ -19,7 +19,7 @@ again:
> index = (index + align_mask) & ~align_mask;
>
> end = index + nr;
> - if (end >= size)
> + if (end > size)
I think that this is intentional; the last byte of the limit doesn't
work.
^ permalink raw reply
* Mixing hard and soft floating point?
From: Joakim Tjernlund @ 2009-10-17 12:14 UTC (permalink / raw)
To: linuxppc-dev
Anyone tried mixing hard and soft FP in on soft float CPU such as 83xx?
Been trying to figure out if this is a good idea or not.
Any combinations that will or won't work?
Generally I got soft FP in all system libs but there might be
an binary application which will use hard FP.
Is the MATH_EMU option in the kernel reliable(for 8xx too)?
Jocke
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-10-17 12:01 UTC (permalink / raw)
Cc: Scott Wood, Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OF2BB5EF59.1EE0A77D-ONC1257652.003D79DC-C1257652.003EA687@LocalDomain>
Joakim Tjernlund/Transmode wrote on 17/10/2009 13:24:18:
>
> Rex Feany <RFeany@mrv.com> wrote on 16/10/2009 22:25:41:
> >
> > Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
> >
> > > Right, it is the pte table walk that is blowing up.
> > > I just noted that 2.6 lacks a tophys() call in its table walk
> > > so I removed that one(there is one more tophys call but I don't think
> > > it should be removed).
> > > Try this addon patch:
> >
> > no difference
> OK, thinking a bit more, this part should not be executed as
> copy_tofrom_user executes in kernel space.
>
> Any chance you can stick a HW breakpoint on FixupDAR?
> Perhaps there is something different with kernel
> virtual address to phys address?
> A simple topys() works in 2.4, but perhaps not in 2.6?
> this is the part of interest:
> FixupDAR: /* Entry point for dcbx workaround. */
> /* fetch instruction from memory. */
> mfspr r10, SPRN_SRR0
> andis. r11, r10, 0x8000
> tophys (r11, r10)
> beq- 139b /* Branch if user space address */
> 140: lwz r11,0(r11)
Probably better to walk the kernel page table too. Does this
make a difference(needs the tophys() patch I posted earlier):
>From 862dda30c3d3d3bedcc605e8520626408a26891c Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Sat, 17 Oct 2009 13:54:03 +0200
Subject: [PATCH] 8xx: Walk the page table for kernel addresses too.
---
arch/powerpc/kernel/head_8xx.S | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 0e91da4..edc9e9b 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -532,28 +532,27 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
* by decoding the registers used by the dcbx instruction and adding them.
* DAR is set to the calculated address and r10 also holds the EA on exit.
*/
-#define NO_SELF_MODIFYING_CODE /* define if you don't want to use self modifying code */
- nop /* A few nops to make the modified_instr: space below cache line aligned */
- nop
-139: /* fetch instruction from userspace memory */
+ /* define if you don't want to use self modifying code */
+#define NO_SELF_MODIFYING_CODE
+FixupDAR:/* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10, SPRN_SRR0
DO_8xx_CPU6(0x3780, r3)
mtspr SPRN_MD_EPN, r10
mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
- lwz r11, 0(r11) /* Get the level 1 entry */
+ cmplwi cr0, r11, 0x0800
+ blt- 3f /* Branch if user space */
+ lis r11, swapper_pg_dir@h
+ ori r11, r11, swapper_pg_dir@l
+ rlwimi r11, r11, 0, 2, 19
+3: lwz r11, 0(r11) /* Get the level 1 entry */
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r11, 0(r11) /* Get the pte */
/* concat physical page address(r11) and page offset(r10) */
rlwimi r11, r10, 0, 20, 31
- b 140f
-FixupDAR: /* Entry point for dcbx workaround. */
- /* fetch instruction from memory. */
- mfspr r10, SPRN_SRR0
- andis. r11, r10, 0x8000
- tophys (r11, r10)
- beq- 139b /* Branch if user space address */
-140: lwz r11,0(r11)
+ lwz r11,0(r11)
/* Check if it really is a dcbx instruction. */
/* dcbt and dcbtst does not generate DTLB Misses/Errors,
* no need to include them here */
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-10-17 11:24 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091016202541.GA16358@compile2.chatsunix.int.mrv.com>
Rex Feany <RFeany@mrv.com> wrote on 16/10/2009 22:25:41:
>
> Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
>
> > Right, it is the pte table walk that is blowing up.
> > I just noted that 2.6 lacks a tophys() call in its table walk
> > so I removed that one(there is one more tophys call but I don't think
> > it should be removed).
> > Try this addon patch:
>
> no difference
OK, thinking a bit more, this part should not be executed as
copy_tofrom_user executes in kernel space.
Any chance you can stick a HW breakpoint on FixupDAR?
Perhaps there is something different with kernel
virtual address to phys address?
A simple topys() works in 2.4, but perhaps not in 2.6?
this is the part of interest:
FixupDAR: /* Entry point for dcbx workaround. */
/* fetch instruction from memory. */
mfspr r10, SPRN_SRR0
andis. r11, r10, 0x8000
tophys (r11, r10)
beq- 139b /* Branch if user space address */
140: lwz r11,0(r11)
If not kernel dcbX works, you could see if user space does.
Here is a start:
#include <errno.h>
#include <sys/mman.h>
#include <stdio.h>
dcbz(void const *ptr)
{
__asm__ ("dcbz 0, %0" : : "r" (ptr) : "memory");
}
dcbf(void const *ptr)
{
__asm__ ("dcbf 0, %0" : : "r" (ptr) : "memory");
}
dcbi(void const *ptr)
{
__asm__ ("dcbi 0, %0" : : "r" (ptr) : "memory");
}
dcbst(void const *ptr)
{
__asm__ ("dcbst 0, %0" : : "r" (ptr) : "memory");
}
icbi(void const *ptr)
{
__asm__ ("icbi 0, %0" : : "r" (ptr) : "memory");
}
dcbt(void const *ptr) /* no TLB Miss */
{
__asm__ ("dcbt 0, %0" : : "r" (ptr) : "memory");
}
dcbtst(void const *ptr) /* no TLB Miss */
{
__asm__ ("dcbtst 0, %0" : : "r" (ptr) : "memory");
}
static const unsigned long const a[16*4094] ;
main()
{
volatile unsigned long b, *ptr = &a[10*4096], *mptr;
b = *ptr;
mptr = mmap(NULL, 16*4094, PROT_WRITE | PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (mptr == MAP_FAILED)
printf("mmap failed:%s\n", strerror(errno));
ptr = mptr;
#if 0
dcbst(&a[2*4096]);
b = *ptr;
dcbf(&a[6*4096]);
b = *ptr;
dcbz(&a[4*4096]);
b = *ptr;
dcbst(&a[8*4096]);
dcbst(&a[8*4096]);
#endif
*ptr = 17;
printf("dcbst(ptr)\n"); fflush(stdout);
dcbst(ptr);
*(ptr+3+1024) = 18;
printf("dcbst(ptr+3*1024)\n"); fflush(stdout);
dcbst(ptr+3*1024);
printf("dcbt(ptr+5*1024)\n"); fflush(stdout);
dcbt(ptr+5*1024);
printf("dcbz(ptr+2*1024)\n"); fflush(stdout);
dcbf(&a[6*4096]);
printf("dcbz(&a[4*4096])\n"); fflush(stdout);
dcbz(&a[4*4096]); fflush(stdout);
printf("dcbf(&a[6*4096])\n"); fflush(stdout);
dcbf(&a[6*4096]);
//dcbz(ptr+2*1024);
//dcbi(&a[6*4096]);
//icbi(&a[8*4096]);
}
^ permalink raw reply
* ppc rfi in head.s result in a reset?
From: wilbur.chan @ 2009-10-17 1:21 UTC (permalink / raw)
To: linuxppc-dev
ppc 6xx
In platform_init function of sandpoint.c , I delete the code of
getting command line from uboot, and set command_line to a fixed value
, which are like this:
sandpoint.c--> platform_init
#if 0
if (r3 && r6) {
/* copy board info structure */
memcpy( (void *)__res,(void *)(r3+KERNELBASE), sizeof(bd_t) );
/* copy command line */
*(char *)(r7+KERNELBASE) = 0;
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
#endif
strcpy(cmd_line, "xxx");
But I found that , when calling start_kernel in head.S (by rfi
instruction), the borad was reset into uboot, that is :
li r4,MSR_KERNEL
FIX_SRR1(r4,r5)
lis r3,start_kernel@h
ori r3,r3,start_kernel@l
mtspr SPRN_SRR0,r3
mtspr SPRN_SRR1,r4
SYNC
RFI //reset,why?
The RFI instruction here, caused the board reset to uboot. Can
someone give me some advice on how could this happened?
Thank you
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kim Phillips @ 2009-10-16 22:27 UTC (permalink / raw)
To: Roland Lezuo; +Cc: Scott Wood, u-boot, linuxppc-dev
In-Reply-To: <1255635643.20355.2.camel@tbfg-desktop>
On Thu, 15 Oct 2009 21:40:43 +0200
Roland Lezuo <roland.lezuo@chello.at> wrote:
> On Mon, 2009-10-12 at 11:06 -0500, Kim Phillips wrote:
> > On Wed, 9 Sep 2009 15:28:01 -0500
> > Kumar Gala <galak@kernel.crashing.org> wrote:
> > > On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
> > > > We really should have a u-boot fixup based on SVR.
> >
> > Roland, is it possible for you to test this u-boot patch?:
>
> No sorry, I have no MPC8313ERDB at hands. But the patch at least looks
> good...
ok, thanks - I went ahead and applied it anyway; it'll be tested by
the next u-boot release. I've added your reviewed-by.
Kim
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Rex Feany @ 2009-10-16 20:25 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <OFF665748B.AAF26319-ONC1257651.00296F23-C1257651.002D6BF7@transmode.se>
Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
> Right, it is the pte table walk that is blowing up.
> I just noted that 2.6 lacks a tophys() call in its table walk
> so I removed that one(there is one more tophys call but I don't think
> it should be removed).
> Try this addon patch:
no difference
take care!
/rex.
^ permalink raw reply
* c67x00 with mpc85xx
From: Jeff Angielski @ 2009-10-16 19:44 UTC (permalink / raw)
To: Linuxppc-dev, Joel Lord
We are using the Cypress USB Host (CY7C67300) with a Freescale MPC8544
and can only get it to work if we add a delay after writing to the
hardware registers through the HPI.
We tried playing with the SCY settings in the GPCM but nothing helps.
It is only when we add usecs of delay after our write() functions that
the hardware works.
The datasheets make no mention of any write-then-read requirements and
the FAEs are stumped right now.
I was just hoping somebody had some experiencing interfacing this chip
to the PowerPC and that they could offer some suggestions or ideas.
TIA,
Jeff
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Benjamin Herrenschmidt @ 2009-10-16 18:03 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, Linux Kernel Mailing List, Christian Borntraeger,
brueckner, Timur Tabi, Alan Cox
In-Reply-To: <20091016153330.GB11838@loki.buserror.net>
On Fri, 2009-10-16 at 10:33 -0500, Scott Wood wrote:
> On Fri, Oct 16, 2009 at 03:46:45PM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-10-15 at 13:57 -0500, Scott Wood wrote:
> > > I'd say the dropping approach is quite undesirable (significant
> > > potential for output loss unless the buffer is huge), unless there's
> > > simply no way to safely spin. Hopefully there are no such backends, but
> > > if there are perhaps we can have them return some special code to
> > > indicate that.
> >
> > Should never spin.
>
> Why is a hypervisor console different than a serial port in this regard?
Ah sorry, yeah, struct console can I suppose, it's the tty that
shouldn't.
> > Best is to keep a copy in the upper layer of the pending data and throttle
> > (not accept further data from tty layer) until we have managed to flush
> > out that "pending" buffer.
>
> The data isn't coming from the tty layer -- we're talking about printk. How
> do you throttle that without spinning?
>
> I agree that it shouldn't spin when handling tty I/O.
Ben.
^ permalink raw reply
* Re: Instable kernel (2.6.29 or 2.6.31) on MPC8548 with 2 GByte RAM
From: Kumar Gala @ 2009-10-16 17:50 UTC (permalink / raw)
To: willy jacobs; +Cc: Linuxppc-dev
In-Reply-To: <4AD6F5D4.7080909@nl.thalesgroup.com>
On Oct 15, 2009, at 5:13 AM, willy jacobs wrote:
> On our MPC8548 (latest die revision) based boards with 2 GByte DDR2
> RAM we see an stable kernel when
>
> CONFIG_HIGHMEM is not set
>
> In this case only the first 768 MB will be used (as reported by /
> proc/cpuinfo).
> Tested with/without the RT-patches for 2.6.29.6(-rt23) and 2.6.31.2(-
> rt13) kernels.
>
> With CONFIG_HIGHMEM=y (2048 MB reported) we see (under "heavy" load
> conditions) regulary page
> errors like this (with/without RT patches):
>
> BUG: Bad page state in process loadgen pfn:7e31d
> page:c17c23a0 flags:80000000 count:0 mapcount:-128 mapping:(null)
> index:48105
> Call Trace:
> [ef867d20] [c00072ac] show_stack+0x34/0x160 (unreliable)
> [ef867d50] [c006fcd0] bad_page+0x90/0x13c
> [ef867d70] [c0070d94] get_page_from_freelist+0x424/0x45c
> [ef867de0] [c0070ea4] __alloc_pages_nodemask+0xd8/0x48c
> [ef867e40] [c0082bf0] handle_mm_fault+0x404/0x740
> [ef867e90] [c00131bc] do_page_fault+0x150/0x460
> [ef867f40] [c001017c] handle_page_fault+0xc/0x80
>
> With the RT-patches we see already during Linux startup at lot of
> these errors (from several processes):
>
> BUG: scheduling while atomic: pam_console_app/0x00000001/802, CPU#0
> Modules linked in:
> Call Trace:
> [ef28dce0] [c00072ac] show_stack+0x34/0x160 (unreliable)
> [ef28dd10] [c002fa90] __schedule_bug+0x6c/0x80
> [ef28dd30] [c02660fc] __schedule+0x264/0x338
> [ef28dd60] [c0266400] schedule+0x1c/0x40
> [ef28dd70] [c0267898] rt_spin_lock_slowlock+0x124/0x264
> [ef28dde0] [c0079154] __lru_cache_add+0x24/0xa8
> [ef28de00] [c008ee04] page_add_new_anon_rmap+0x58/0x88
> [ef28de20] [c0086ff8] handle_mm_fault+0x5a4/0x804
> [ef28de80] [c0013590] do_page_fault+0x14c/0x49c
> [ef28df40] [c00101c4] handle_page_fault+0xc/0x80
> BUG: scheduling while atomic: pam_console_app/0x00000001/807, CPU#0
> Modules linked in:
> Call Trace:
> [ef323a30] [c00072ac] show_stack+0x34/0x160 (unreliable)
> [ef323a60] [c002fa90] __schedule_bug+0x6c/0x80
> [ef323a80] [c02660fc] __schedule+0x264/0x338
> [ef323ab0] [c0266400] schedule+0x1c/0x40
> [ef323ac0] [c0267898] rt_spin_lock_slowlock+0x124/0x264
> [ef323b30] [c0079154] __lru_cache_add+0x24/0xa8
> [ef323b50] [c008ee04] page_add_new_anon_rmap+0x58/0x88
> [ef323b70] [c0086ff8] handle_mm_fault+0x5a4/0x804
> [ef323bd0] [c0013590] do_page_fault+0x14c/0x49c
> [ef323c90] [c00101c4] handle_page_fault+0xc/0x80
> [ef323d50] [00000007] 0x7
> [ef323d80] [c0071320] generic_file_aio_read+0x2d4/0x6bc
> [ef323e00] [c00ffe98] nfs_file_read+0x124/0x178
> [ef323e30] [c009d56c] do_sync_read+0xc4/0x138
> [ef323ef0] [c009e0a4] vfs_read+0xc4/0x188
> [ef323f10] [c009e514] sys_read+0x4c/0x90
> [ef323f40] [c000fd84] ret_from_syscall+0x0/0x3c
>
> Anyone experience with MPC8548 with 2 GByte RAM (HIGHMEM)?
>
We've used MPC85xx w/2G+ for some time w/HIGHMEM and havent seen any
issues. Are you sure your DDR settings are stable?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Add a Book-3E 64-bit defconfig
From: Kumar Gala @ 2009-10-16 17:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc list, Stephen Rothwell
In-Reply-To: <1255712717-21221-1-git-send-email-galak@kernel.crashing.org>
On Oct 16, 2009, at 12:05 PM, Kumar Gala wrote:
> This defconfig's purpose at this time is to help catch compile errors
> between Book-3S and Book-3E support in ppc64. It is based on the
> ppc64_defconfig with some things disabled that we dont support on
> Book-3E right now (hugetlbfs, slices, etc.)
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/configs/ppc64e_defconfig | 2199 ++++++++++++++++++++++++
> +++++++++
> 1 files changed, 2199 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/configs/ppc64e_defconfig
Ben,
Please apply this for v2.6.32 as it should help going forward catching
compile issues.
Stephen, Michaeal,
Can we get this added to the build testing for next and to kisskb.
thanks.
- k
^ permalink raw reply
* [PATCH 5/5] powerpc: Cleanup lib/Kconfig.debug
From: Kumar Gala @ 2009-10-16 17:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1255713699-21852-5-git-send-email-galak@kernel.crashing.org>
We don't need an explicit PPC64 in the DEBUG_PREEMPT dependancies as all
PPC platforms now support TRACE_IRQFLAGS_SUPPORT.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
lib/Kconfig.debug | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 30df586..234ceb1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -392,7 +392,7 @@ config DEBUG_KMEMLEAK_TEST
config DEBUG_PREEMPT
bool "Debug preemptible kernel"
- depends on DEBUG_KERNEL && PREEMPT && (TRACE_IRQFLAGS_SUPPORT || PPC64)
+ depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
default y
help
If you say Y here then the kernel will use a debug variant of the
--
1.6.0.6
^ permalink raw reply related
* [PATCH 4/5] powerpc: clean up sound/ppc/Kconfig
From: Kumar Gala @ 2009-10-16 17:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1255713699-21852-4-git-send-email-galak@kernel.crashing.org>
We can replace PPC32 || PPC64 as a dependancy with just PPC as all
powerpc platforms (32-bit and 64-bit) define PPC now.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
sound/ppc/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/ppc/Kconfig b/sound/ppc/Kconfig
index bd2338a..0519c60 100644
--- a/sound/ppc/Kconfig
+++ b/sound/ppc/Kconfig
@@ -2,7 +2,7 @@
menuconfig SND_PPC
bool "PowerPC sound devices"
- depends on PPC64 || PPC32
+ depends on PPC
default y
help
Support for sound devices specific to PowerPC architectures.
--
1.6.0.6
^ permalink raw reply related
* [PATCH 3/5] powerpc: cleanup init/Kconfig
From: Kumar Gala @ 2009-10-16 17:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1255713699-21852-3-git-send-email-galak@kernel.crashing.org>
We dont need to depend on PPC64 explicitly as all powerpc platforms
(32-bit and 64-bit) define PPC now.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
init/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 09c5c64..f515864 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -297,7 +297,7 @@ config AUDIT
config AUDITSYSCALL
bool "Enable system-call auditing support"
- depends on AUDIT && (X86 || PPC || PPC64 || S390 || IA64 || UML || SPARC64|| SUPERH)
+ depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
default y if SECURITY_SELINUX
help
Enable low-overhead system-call auditing infrastructure that
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/5] powerpc: Limit memory hotplug support to PPC64 Book-3S machines
From: Kumar Gala @ 2009-10-16 17:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1255713699-21852-2-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
mm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 57963c6..7ca3777 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -129,7 +129,7 @@ config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on HOTPLUG && !(HIBERNATION && !S390) && ARCH_ENABLE_MEMORY_HOTPLUG
- depends on (IA64 || X86 || PPC64 || SUPERH || S390)
+ depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390)
comment "Memory hotplug is currently incompatible with Software Suspend"
depends on SPARSEMEM && HOTPLUG && HIBERNATION && !S390
--
1.6.0.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox