* Re: [-next Feb 18] PowerPC boot failure (Unknowd ADD relocation :26)
From: Sachin Sant @ 2010-02-22 4:59 UTC (permalink / raw)
To: Michael Neuling; +Cc: Linux/PPC Development, linux-next, Stephen Rothwell
In-Reply-To: <4B7E118C.7060208@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Sachin Sant wrote:
> Yesterday's next failed to boot on various powerpc boxes
> with following error :
>
> NET: Registered protocol family 15
> registered taskstats version 1
> Freeing unused kernel memory: 640k freed
> doing fast boot
> scsi_mod: Unknown ADD relocation: 26
> WARNING: Error inserting scsi_mod
> (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_mod.ko):
> Invalid module format
> scsi_tgt: Unknown symbol scsi_release_buffers
> scsi_tgt: Unknown symbol scsi_host_put
> scsi_tgt: Unknown symbol __scsi_put_command
> scsi_tgt: Unknown symbol scsi_host_lookup
> scsi_tgt: Unknown symbol __scsi_get_command
> scsi_tgt: Unknown symbol scsi_init_io
> scsi_tgt: Unknown symbol __scsi_alloc_queue
>
> and many more such modules related errors.
> I have attached the boot log here.
>
> Next Feb 17th was OK. Haven't yet tried the git bisect.
> Will try that out today.
Git bisect isn't giving me reliable results. Sometimes
the machine boots fine after reverting few patches, but
the very next boot with same kernel fails.
Have attached the .config(.gz)
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: config_next_19.gz --]
[-- Type: application/x-gzip, Size: 20110 bytes --]
^ permalink raw reply
* [PATCH] powerpc: reset kernel stack on cpu online from cede state
From: Vaidyanathan Srinivasan @ 2010-02-22 8:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Anton Blanchard; +Cc: linuxppc-dev
powerpc: reset kernel stack on cpu online from cede state
Cpu hotplug (offline) without dlpar operation will place cpu
in cede state and the extended_cede_processor() function will
return when resumed.
Kernel stack pointer needs to be reset before
start_secondary() is called to continue the online operation.
Added new function start_secondary_resume() to do the above
steps.
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 9258074..567cd57 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -615,6 +615,17 @@ _GLOBAL(start_secondary_prolog)
std r3,0(r1) /* Zero the stack frame pointer */
bl .start_secondary
b .
+/*
+ * Reset stack pointer and call start_secondary
+ * to continue with online operation when woken up
+ * from cede in cpu offline.
+ */
+_GLOBAL(start_secondary_resume)
+ ld r1,PACAKSAVE(r13) /* Reload kernel stack pointer */
+ li r3,0
+ std r3,0(r1) /* Zero the stack frame pointer */
+ bl .start_secondary
+ b .
#endif
/*
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 6ea4698..9be7af4 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -146,12 +146,11 @@ static void pseries_mach_cpu_die(void)
unregister_slb_shadow(hwcpu, __pa(get_slb_shadow()));
/*
- * NOTE: Calling start_secondary() here for now to
- * start new context.
- * However, need to do it cleanly by resetting the
- * stack pointer.
+ * Call to start_secondary_resume() will not return.
+ * Kernel stack will be reset and start_secondary()
+ * will be called to continue the online operation.
*/
- start_secondary();
+ start_secondary_resume();
} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
diff --git a/arch/powerpc/platforms/pseries/offline_states.h b/arch/powerpc/platforms/pseries/offline_states.h
index 22574e0..da07256 100644
--- a/arch/powerpc/platforms/pseries/offline_states.h
+++ b/arch/powerpc/platforms/pseries/offline_states.h
@@ -14,5 +14,5 @@ extern void set_cpu_current_state(int cpu, enum cpu_state_vals state);
extern enum cpu_state_vals get_preferred_offline_state(int cpu);
extern void set_preferred_offline_state(int cpu, enum cpu_state_vals state);
extern void set_default_offline_state(int cpu);
-extern int start_secondary(void);
+extern void start_secondary_resume(void);
#endif
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
From: Anatolij Gustschin @ 2010-02-22 11:37 UTC (permalink / raw)
To: David S. Miller; +Cc: Wolfgang Denk, Detlev Zundel, netdev, linuxppc-dev
In-Reply-To: <1266418530-2727-1-git-send-email-agust@denx.de>
Hi David,
On Wed, 17 Feb 2010 15:55:27 +0100
Anatolij Gustschin <agust@denx.de> wrote:
> These patches attempt to provide support for the Freescale MPC512x
> FEC in the fs_enet driver. The first cleanup patch replaces printk
> by dev_xxx. The second and third attemt to support MPC5121 FEC
> in the FEC driver.
Could you please comment on this patch series. The patches
have been acked by Grant and I slightly reworked third patch
to address Eric's comments, so there is v3 for this patch now.
Thanks,
Anatolij
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
From: David Miller @ 2010-02-22 11:44 UTC (permalink / raw)
To: agust; +Cc: wd, dzu, netdev, linuxppc-dev
In-Reply-To: <20100222123724.67a7b862@wker>
From: Anatolij Gustschin <agust@denx.de>
Date: Mon, 22 Feb 2010 12:37:24 +0100
> Could you please comment on this patch series.
It's in the net-next-2.6 tree.
If you need to make any more changes, they need to be relative
to what went into my tree.
^ permalink raw reply
* default stack size for threads changed
From: Joakim Tjernlund @ 2010-02-22 12:20 UTC (permalink / raw)
To: linuxppc-dev
With current, 2.6.33-rc6, linux the default stack size changed from unlimited
to 8MB:
# > ulimit -s
8192
This makes NPTL allocate a 8MB stack for each thread that is created.
This breaks in our embedded system. Although this
can be fixed in our app I wonder if this is intentional?
Jocke
^ permalink raw reply
* Re: default stack size for threads changed
From: Joakim Tjernlund @ 2010-02-22 12:24 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OF21CCB5A6.CDFDB6C1-ONC12576D2.00430B25-C12576D2.0043C4BB@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2010/02/22 13:20:12:
>
> With current, 2.6.33-rc6, linux the default stack size changed from unlimited
> to 8MB:
> # > ulimit -s
> 8192
>
> This makes NPTL allocate a 8MB stack for each thread that is created.
> This breaks in our embedded system. Although this
> can be fixed in our app I wonder if this is intentional?
>
> Jocke
Forgot to mention that timer_create(2) increases the stack with 8MB too.
Jocke
^ permalink raw reply
* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: K.Prasad @ 2010-02-22 13:17 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Mahesh Salgaonkar, Will Deacon, David Gibson, linuxppc-dev,
Alan Stern, paulus, Roland McGrath
In-Reply-To: <20100221010130.GA5187@nowhere>
On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
> On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
> > +struct arch_hw_breakpoint {
> > + u8 len; /* length of the target symbol */
> > + int type;
> > + char *name; /* Contains name of the symbol to set bkpt */
> > + unsigned long address;
> > +};
>
>
>
>
> I don't think it's a good idea to integrate the name of
> the target. This is something that should be done in a higher
> level, not in an arch backend.
> We don't even need to store it anywhere as we can resolve
> back an address easily. Symbol awareness is not something
> the hardware breakpoint should care about, neither in the
> arch nor the generic level.
>
The 'name' field here is actually a legacy inherited from x86 code. It
is part of x86's arch-specific hw-breakpoint structure since:
- inspired by the kprobe implementation which accepts symbol name as
input.
- kallsyms_lookup_name() was 'unexported' and a module could not resolve
symbol names externally, so the core-infrastructure had to provide
such facilities.
- I wasn't sure about the discussions behind 'unexporting' of
kallsyms_lookup_name(), so did not venture to export them again (which
you rightfully did :-)
Having said that, I'll be glad to remove this field (along with that in
x86), provided we know that there's a way for the user to resolve symbol
names on its own i.e. routines like kallsyms_lookup_name() will remain
exported.
> Also, do you think addr/len/type is enough to abstract out
> any ppc breakpoints?
>
> This looks enough to me to express range breakpoints and
> simple breakpoints. But what about value comparison?
> (And still, there may be other trickier implementations
> I don't know in ppc).
>
The above implementation is for PPC64 architecture that supports only
'simple' breakpoints of fixed length (no range breakpoints, no value
comparison). More on that below.
> > +
> > +#include <linux/kdebug.h>
> > +#include <asm/reg.h>
> > +#include <asm/system.h>
> > +
> > +/* Total number of available HW breakpoint registers */
> > +#define HBP_NUM 1
>
>
> Looking at the G2 PowerPc implementation, DABR and DABR2 can either
> express two different watchpoints or one range watchpoint.
>
> There are also IABR and IABR2 for instruction breakpoints that
> follow the same above scheme. I'm not sure we can abstract that
> using a constant max linear number of resources.
>
>
As stated above, the patch implements breakpoints for PPC64 processors
only (http://www.power.org/resources/downloads/PowerISA_V2.06_PUBLIC.pdf),
which does not support advanced breakpoint features (which its ppc
Book-E counterpart has).
> > +static inline void hw_breakpoint_disable(void)
> > +{
> > + set_dabr(0);
> > +}
>
>
> So, this is only about data breakpoints?
>
>
Yes, newer PPC64 processors do not support IABR.
> > + /*
> > + * As a policy, the callback is invoked in a 'trigger-after-execute'
> > + * fashion
> > + */
> > + (bp->overflow_handler)(bp, 0, NULL, regs);
>
>
> Why are you calling this explicitly instead of using the perf_bp_event()
> thing? This looks like it won't work with perf as the event won't
> be recorded by perf.
>
Yes, should have invoked perf_bp_event() for perf to work well (on a
side note, it makes me wonder at the amount of 'extra' code that each
breakpoint exception would execute if it were not called through perf
sys-call...well, the costs of integrating with a generic infrastructure!)
> > +void ptrace_triggered(struct perf_event *bp, int nmi,
> > + struct perf_sample_data *data, struct pt_regs *regs)
> > +{
> > + struct perf_event_attr attr;
> > +
> > + /*
> > + * Disable the breakpoint request here since ptrace has defined a
> > + * one-shot behaviour for breakpoint exceptions in PPC64.
> > + * The SIGTRAP signal is generated automatically for us in do_dabr().
> > + * We don't have to do anything about that here
> > + */
>
>
> Oh, why does ptrace use a one-shot behaviour in ppc? Breakpoints
> only trigger once?
>
Yes, ptrace breakpoints on PPC64 are designed to trigger once and this
patch retains that behaviour. It is very convenient to use one-shot
behaviour on archs where exceptions are triggered-before-execute.
> > + if (bp) {
> > + attr = bp->attr;
> > + attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
> > +
> > + switch (data & (DABR_DATA_WRITE | DABR_DATA_READ)) {
> > + case DABR_DATA_READ:
> > + attr.bp_type = HW_BREAKPOINT_R;
> > + break;
> > + case DABR_DATA_WRITE:
> > + attr.bp_type = HW_BREAKPOINT_W;
> > + break;
> > + case (DABR_DATA_WRITE | DABR_DATA_READ):
> > + attr.bp_type = HW_BREAKPOINT_R | HW_BREAKPOINT_W;
> > + break;
> > + }
> > + ret = modify_user_hw_breakpoint(bp, &attr);
> > + if (ret)
> > + return ret;
> > + thread->ptrace_bps[0] = bp;
> > + thread->dabr = data;
> > + return 0;
> > + }
> > +
> > + /* Create a new breakpoint request if one doesn't exist already */
> > + hw_breakpoint_init(&attr);
> > + attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
> > + switch (data & (DABR_DATA_WRITE | DABR_DATA_READ)) {
> > + case DABR_DATA_READ:
> > + attr.bp_type = HW_BREAKPOINT_R;
> > + break;
> > + case DABR_DATA_WRITE:
> > + attr.bp_type = HW_BREAKPOINT_W;
> > + break;
> > + case (DABR_DATA_WRITE | DABR_DATA_READ):
> > + attr.bp_type = HW_BREAKPOINT_R | HW_BREAKPOINT_W;
> > + break;
> > + }
> > + thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
> > + ptrace_triggered, task);
> > + if (IS_ERR(bp)) {
> > + thread->ptrace_bps[0] = NULL;
> > + return PTR_ERR(bp);
> > + }
> > +
> > +#endif /* CONFIG_PPC64 */
>
>
>
> This looks fine for basic breakpoints. And this can probably be
> improved to integrate ranges.
>
> But I think we did something wrong with the generic breakpoint
> interface. We are translating the arch values to generic
> attributes. Then this all will be translated back to arch
> values.
>
> Having generic attributes is necessary for any perf event
> use from userspace. But it looks like a waste for ptrace
> that already gives us arch values. And the problem
> is the same for x86.
>
> So I think we should implement a register_ptrace_breakpoint()
> that doesn't take perf_event_attr but specific arch informations,
> so that we don't need to pass through a generic conversion, which:
>
I agree that the layers of conversion from generic to arch-specific
breakpoint constants is wasteful.
Can't the arch_bp_generic_fields() function be moved to
arch/x86/kernel/ptrace.c instead of a new interface?
> - is wasteful
> - won't be able to express 100% of any arch capabilities. We
> can certainly express most arch breakpoints features through
> the generic interface, but not all of them (given how tricky
> the data value comparison features can be)
>
> I will rework that during the next cycle.
>
> Thanks.
>
Thank you for the comments. I will re-send a new version of the patch
with the perf_bp_event() substitution.
-- K.Prasad
^ permalink raw reply
* Re: [PATCH] powerpc/mpc512x: Add gpio driver
From: Matthias Fuchs @ 2010-02-22 16:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa41002161119x6eb41203rb73b888176ce5040@mail.gmail.com>
Hi Grant,
thanks for comments. I will post an updated version soon.
On Tuesday 16 February 2010 20:19, Grant Likely wrote:
> > + =A0 =A0 =A0 return 0;
> > +}
> > +arch_initcall(mpc512x_add_gpiochips);
>=20
> Don't do this. Either make this a proper of_platform device driver,
> or call mpc512x_add_gpiochips() explicitly from the arch platform
> setup code. Otherwise, if the kernel is built for multiplatform, this
> function will get executed regardless of the platform.
In this case I prefer moving the call to the platform code.
I tested the driver on one of our 5123 boards. Shall I add it=20
to mpc5121_ads.c:mpc5121_ads_setup_arch() also? So it's at least called=20
on the reference board? I not sure if there are some LEDs or buttons
that could use it.
Matthias
^ permalink raw reply
* Re: [PATCH] powerpc/mpc512x: Add gpio driver
From: Grant Likely @ 2010-02-22 17:33 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev
In-Reply-To: <201002221705.30700.matthias.fuchs@esd-electronics.com>
On Mon, Feb 22, 2010 at 9:05 AM, Matthias Fuchs
<matthias.fuchs@esd-electronics.com> wrote:
> Hi Grant,
>
> thanks for comments. I will post an updated version soon.
>
>
> On Tuesday 16 February 2010 20:19, Grant Likely wrote:
>> > + =A0 =A0 =A0 return 0;
>> > +}
>> > +arch_initcall(mpc512x_add_gpiochips);
>>
>> Don't do this. =A0Either make this a proper of_platform device driver,
>> or call mpc512x_add_gpiochips() explicitly from the arch platform
>> setup code. =A0Otherwise, if the kernel is built for multiplatform, this
>> function will get executed regardless of the platform.
> In this case I prefer moving the call to the platform code.
> I tested the driver on one of our 5123 boards. Shall I add it
> to mpc5121_ads.c:mpc5121_ads_setup_arch() also? So it's at least called
> on the reference board? I not sure if there are some LEDs or buttons
> that could use it.
Yes, make sure all 5121 platforms call it.
Thanks,
g.
^ permalink raw reply
* [async_tx-next PATCH 2/2] fsldma: Fix cookie issues
From: Steven J. Magnani @ 2010-02-22 17:40 UTC (permalink / raw)
To: Dan Williams; +Cc: Zhang Wei, linux-kernel, Steven J. Magnani, linuxppc-dev
fsl_dma_update_completed_cookie() appears to calculate the last completed
cookie incorrectly in the corner case where DMA on cookie 1 is in progress
just following a cookie wrap.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.000000000 -0600
+++ b/drivers/dma/fsldma.c 2010-02-22 11:08:41.000000000 -0600
@@ -819,8 +819,11 @@ static void fsl_dma_update_completed_coo
desc = to_fsl_desc(chan->ld_running.prev);
if (dma_is_idle(chan))
cookie = desc->async_tx.cookie;
- else
+ else {
cookie = desc->async_tx.cookie - 1;
+ if (unlikely(cookie < DMA_MIN_COOKIE))
+ cookie = DMA_MAX_COOKIE;
+ }
chan->completed_cookie = cookie;
diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
--- a/include/linux/dmaengine.h 2010-02-22 11:18:11.000000000 -0600
+++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.000000000 -0600
@@ -31,6 +31,8 @@
* if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
*/
typedef s32 dma_cookie_t;
+#define DMA_MIN_COOKIE 1
+#define DMA_MAX_COOKIE 2147483647
#define dma_submit_error(cookie) ((cookie) < 0 ? 1 : 0)
^ permalink raw reply
* [async_tx-next PATCH 0/2] fsldma: Fix cookie issues
From: Steven J. Magnani @ 2010-02-22 17:40 UTC (permalink / raw)
To: Dan Williams; +Cc: Zhang Wei, linux-kernel, linuxppc-dev
In modeling a new DMA engine on the FSL code, I ran across what look to be
some bugs in FSL cookie handling. As I don't have FSL HW or even a PPC,
I can't verify the problem or the fix, but I did ensure that the changes
compile.
BTW thanks to all involved in creation of the FSL driver, it's a nice model
to follow.
Regards,
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply
* [async_tx-next PATCH 1/2] fsldma: Fix cookie issues
From: Steven J. Magnani @ 2010-02-22 17:40 UTC (permalink / raw)
To: Dan Williams; +Cc: Zhang Wei, linux-kernel, Steven J. Magnani, linuxppc-dev
fsl_dma_tx_submit() only sets the cookie on the first descriptor of a
transaction. It should set the cookie on all.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.000000000 -0600
+++ b/drivers/dma/fsldma.c 2010-02-22 11:24:01.000000000 -0600
@@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st
if (cookie < 0)
cookie = 1;
- desc->async_tx.cookie = cookie;
+ child->async_tx.cookie = cookie;
}
chan->common.cookie = cookie;
^ permalink raw reply
* Re: [PATCH 2/3] backlight: mark struct backlight_ops const
From: Mike Frysinger @ 2010-02-22 19:35 UTC (permalink / raw)
To: Bruno Prémont
Cc: devel, linux-fbdev, acpi4asus-user, linuxppc-dev,
Greg Kroah-Hartman, linux-kernel, linux-acpi, linux-omap,
linux-usb, Andrew Morton, dri-devel, ibm-acpi-devel
In-Reply-To: <20100221001851.673db863@neptune.home>
T24gU2F0LCBGZWIgMjAsIDIwMTAgYXQgMTg6MTgsIEJydW5vIFByw6ltb250IHdyb3RlOgo+IMKg
ZHJpdmVycy92aWRlby9iZjU0eC1scTA0M2ZiLmMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
fCDCoCDCoDIgKy0KPiDCoGRyaXZlcnMvdmlkZW8vYmZpbi10MzUwbWNxYi1mYi5jIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgfCDCoCDCoDIgKy0KCkFja2VkLWJ5OiBNaWtlIEZyeXNpbmdlciA8dmFw
aWVyQGdlbnRvby5vcmc+Ci1taWtlCg==
^ permalink raw reply
* Re: [async_tx-next PATCH 2/2] fsldma: Fix cookie issues
From: Guennadi Liakhovetski @ 2010-02-22 20:26 UTC (permalink / raw)
To: Steven J. Magnani; +Cc: Zhang Wei, Dan Williams, linux-kernel, linuxppc-dev
In-Reply-To: <1266860439-17352-1-git-send-email-steve@digidescorp.com>
On Mon, 22 Feb 2010, Steven J. Magnani wrote:
> diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> --- a/include/linux/dmaengine.h 2010-02-22 11:18:11.000000000 -0600
> +++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.000000000 -0600
> @@ -31,6 +31,8 @@
> * if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
> */
> typedef s32 dma_cookie_t;
> +#define DMA_MIN_COOKIE 1
> +#define DMA_MAX_COOKIE 2147483647
Taking into account, that dma_cookie_t is 32 bits:
+#define DMA_MAX_COOKIE ((1 << 31) - 1)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
From: Jesse Barnes @ 2010-02-23 0:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Matthew Garrett, Tony Luck, linuxppc-dev, linux-pci, Peter Haight,
Gary Hade, linux-kernel, linux-acpi, linux-am33-list,
Linus Torvalds, Ingo Molnar, Yinghai Lu, Larry Finger
In-Reply-To: <20100217201952.4013.62534.stgit@bob.kio>
On Wed, 17 Feb 2010 13:19:52 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>
> No functional change; this breaks up pci_read_bridge_bases() into separate
> pieces for the I/O, memory, and prefetchable memory windows, similar to how
> Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc.
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> ---
Applied this series, thanks Bjorn. Hopefully this one will
successfully run the linux-next gauntlet too. :)
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
From: Jesse Barnes @ 2010-02-23 1:13 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Matthew Garrett, Tony Luck, linuxppc-dev, linux-pci, Peter Haight,
Gary Hade, linux-kernel, linux-acpi, linux-am33-list,
Linus Torvalds, Ingo Molnar, Yinghai Lu, Larry Finger
In-Reply-To: <20100217201952.4013.62534.stgit@bob.kio>
On Wed, 17 Feb 2010 13:19:52 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>
> No functional change; this breaks up pci_read_bridge_bases() into separate
> pieces for the I/O, memory, and prefetchable memory windows, similar to how
> Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc.
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> ---
Had to drop these again, got:
Kernel: arch/x86/boot/bzImage is ready (#16)
MODPOST 2245 modules
ERROR: "pci_bus_resource_n" [drivers/pcmcia/yenta_socket.ko] undefined!
ERROR: "pci_bus_resource_n" [drivers/pcmcia/rsrc_nonstatic.ko] undefined!
ERROR: "pci_bus_resource_n" [drivers/pci/hotplug/shpchp.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
when building.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Anton Blanchard @ 2010-02-23 1:38 UTC (permalink / raw)
To: Balbir Singh; +Cc: mel, cl, linuxppc-dev
In-Reply-To: <661de9471002190743t5385d97hf38c544f0007879c@mail.gmail.com>
Hi Balbir,
> A reclaim distance of 10 implies a ratio of 1, that means we'll always
> do zone_reclaim() to free page cache and slab cache before moving on
> to another node?
I want to make an effort to reclaim local pagecache before ever going
off node. As an example, a completely off node stream result is almost 3x
slower than on node on my test box.
Anton
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Anton Blanchard @ 2010-02-23 1:55 UTC (permalink / raw)
To: Mel Gorman; +Cc: cl, linuxppc-dev
In-Reply-To: <20100219145523.GN30258@csn.ul.ie>
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
Hi Mel,
> You're pretty much on the button here. Only one thread at a time enters
> zone_reclaim. The others back off and try the next zone in the zonelist
> instead. I'm not sure what the original intention was but most likely it
> was to prevent too many parallel reclaimers in the same zone potentially
> dumping out way more data than necessary.
>
> > I'm not sure if there is an easy way to fix this without penalising other
> > workloads though.
> >
>
> You could experiment with waiting on the bit if the GFP flags allowi it? The
> expectation would be that the reclaim operation does not take long. Wait
> on the bit, if you are making the forward progress, recheck the
> watermarks before continueing.
Thanks to you and Christoph for some suggestions to try. Attached is a
chart showing the results of the following tests:
baseline.txt
The current ppc64 default of zone_reclaim_mode = 0. As expected we see
no change in remote node memory usage even after 10 iterations.
zone_reclaim_mode.txt
Now we set zone_reclaim_mode = 1. On each iteration we continue to improve,
but even after 10 runs of stream we have > 10% remote node memory usage.
reclaim_4096_pages.txt
Instead of reclaiming 32 pages at a time, we try for a much larger batch
of 4096. The slope is much steeper but it still takes around 6 iterations
to get almost all local node memory.
wait_on_busy_flag.txt
Here we busy wait if the ZONE_RECLAIM_LOCKED flag is set. As you suggest
we would need to check the GFP flags etc, but so far it looks the most
promising. We only get a few percent of remote node memory on the first
iteration and get all local node by the second.
Perhaps a combination of larger batch size and waiting on the busy
flag is the way to go?
Anton
[-- Attachment #2: stream_test:_percentage_off_node_memory.png --]
[-- Type: image/png, Size: 34767 bytes --]
[-- Attachment #3: reclaim_4096_pages.patch --]
[-- Type: text/x-diff, Size: 376 bytes --]
--- mm/vmscan.c~ 2010-02-21 23:47:14.000000000 -0600
+++ mm/vmscan.c 2010-02-22 03:22:01.000000000 -0600
@@ -2534,7 +2534,7 @@
.may_unmap = !!(zone_reclaim_mode & RECLAIM_SWAP),
.may_swap = 1,
.nr_to_reclaim = max_t(unsigned long, nr_pages,
- SWAP_CLUSTER_MAX),
+ 4096),
.gfp_mask = gfp_mask,
.swappiness = vm_swappiness,
.order = order,
[-- Attachment #4: wait_on_ZONE_RECLAIM_LOCKED.patch --]
[-- Type: text/x-diff, Size: 482 bytes --]
--- mm/vmscan.c~ 2010-02-21 23:47:14.000000000 -0600
+++ mm/vmscan.c 2010-02-21 23:47:31.000000000 -0600
@@ -2634,8 +2634,8 @@
if (node_state(node_id, N_CPU) && node_id != numa_node_id())
return ZONE_RECLAIM_NOSCAN;
- if (zone_test_and_set_flag(zone, ZONE_RECLAIM_LOCKED))
- return ZONE_RECLAIM_NOSCAN;
+ while (zone_test_and_set_flag(zone, ZONE_RECLAIM_LOCKED))
+ cpu_relax();
ret = __zone_reclaim(zone, gfp_mask, order);
zone_clear_flag(zone, ZONE_RECLAIM_LOCKED);
^ permalink raw reply
* Re: default stack size for threads changed
From: Michael Neuling @ 2010-02-23 1:58 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, miltonm
In-Reply-To: <OF21CCB5A6.CDFDB6C1-ONC12576D2.00430B25-C12576D2.0043C4BB@transmode.se>
In message <OF21CCB5A6.CDFDB6C1-ONC12576D2.00430B25-C12576D2.0043C4BB@transmode.se> you wrote:
>
> With current, 2.6.33-rc6, linux the default stack size changed from unlimited
> to 8MB:
> # > ulimit -s
> 8192
>
> This makes NPTL allocate a 8MB stack for each thread that is created.
> This breaks in our embedded system. Although this
> can be fixed in our app I wonder if this is intentional?
When did this change from unlimited?
It's unlikely but this might be related
803bf5ec259941936262d10ecc84511b76a20921 (post rc7). You'll also need
to grab this http://patchwork.kernel.org/patch/79365/.
Mikey
>
> Jocke
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
From: Feng Kan @ 2010-02-23 5:21 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20100220201155.27744439@opus.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
Hi Sean:
I will withdraw this patch. I had a talk with the U-Boot guys. The reason for this
patch was to support those guys that had their ECC ordering at (213) on the older
version of the kernel. Upgrading to (123) may be problematic. Since without a jtag
it would be a bit complex.
I still think this NAND_ECC_SMC define is somewhat missleading. Given that
both 1-2-3 and 2-1-3 are supported by the correction routine.
Feng
________________________________
From: Sean MacLennan [mailto:smaclennan@pikatech.com]
Sent: Sat 2/20/2010 5:11 PM
To: Feng Kan
Cc: linux-mtd@lists.infradead.org; linuxppc-dev@ozlabs.org; Feng Kan
Subject: Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
On Thu, 18 Feb 2010 15:11:18 -0800
Feng Kan <fkan@amcc.com> wrote:
> This is to lock down the ordering in the correction routine against
> the calculate routine. Otherwise, incorrect define would cause ECC
> errors.
Did you actually find a 44x PPC core that is not NAND_ECC_SMS format?
Cheers,
Sean
[-- Attachment #2: Type: text/html, Size: 2042 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
From: Sean MacLennan @ 2010-02-23 5:41 UTC (permalink / raw)
To: Feng Kan; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <2B3B2AA816369A4E87D7BE63EC9D2F260615A5F2@SDCEXCHANGE01.ad.amcc.com>
On Mon, 22 Feb 2010 21:21:53 -0800
"Feng Kan" <fkan@amcc.com> wrote:
> Hi Sean:
>
> I will withdraw this patch. I had a talk with the U-Boot guys. The
> reason for this patch was to support those guys that had their ECC
> ordering at (213) on the older version of the kernel. Upgrading to
> (123) may be problematic. Since without a jtag it would be a bit
> complex.
> I still think this NAND_ECC_SMC define is somewhat missleading. Given
> that both 1-2-3 and 2-1-3 are supported by the correction routine.
The 213 ordering is my fault. I changed it to match what u-boot did
rather than keeping the order from the old arch-ppc driver. Believe
me, I have been raked over the coals at work for this :(
I agree the NAND_ECC_SMC is misleading. The NAND_ECC_SMC *is* correct.
The confusion is that the SMC is handled later on, so you must keep the
byte order unaltered in this routine.
I wrote a simple driver that allows you to boot with the old kernel,
insmod the driver, burn new images (including a kernel with the correct
byte order!), and then reboot into the new kernel. If anybody wants
this, just ask. It will take a little work to get it working with other
NANDs since it needs to know the NAND name to get the mtd structure.
It also assumes you have a way to write to NAND in user mode. The
mtd-utils flash_eraseall and nandwrite are good enough.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-02-23 6:08 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <24165.1266577276@neuling.org>
In message <24165.1266577276@neuling.org> you wrote:
> In message <1266573672.1806.70.camel@laptop> you wrote:
> > On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > > > include/linux/sched.h | 2 +-
> > > > kernel/sched_fair.c | 61 +++++++++++++++++++++++++++++++++++++++++
++
> ++--
> > > -
> > > > 2 files changed, 58 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > index 0eef87b..42fa5c6 100644
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -849,7 +849,7 @@ enum cpu_idle_type {
> > > > #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power sa
vings */
> > > > #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
> > > resources */
> > > > #define SD_SERIALIZE 0x0400 /* Only a single load balancing
> instanc
> > > e */
> > > > -
> > > > +#define SD_ASYM_PACKING 0x0800
> > >
> > > Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
> > > or is this ok to add it generically?
> >
> > I'd think we'd want to keep that limited to architectures that actually
> > need it.
>
> OK
>
> > >
> > > > +static int update_sd_pick_busiest(struct sched_domain *sd,
> > > > + struct sd_lb_stats *sds,
> > > > + struct sched_group *sg,
> > > > + struct sg_lb_stats *sgs)
> > > > +{
> > > > + if (sgs->sum_nr_running > sgs->group_capacity)
> > > > + return 1;
> > > > +
> > > > + if (sgs->group_imb)
> > > > + return 1;
> > > > +
> > > > + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
> > > > + if (!sds->busiest)
> > > > + return 1;
> > > > +
> > > > + if (group_first_cpu(sds->busiest) < group_first_cpu(gro
up))
> > >
> > > "group" => "sg" here? (I get a compile error otherwise)
> >
> > Oh, quite ;-)
> >
> > > > +static int check_asym_packing(struct sched_domain *sd,
> > > > + struct sd_lb_stats *sds,
> > > > + int cpu, unsigned long *imbalance)
> > > > +{
> > > > + int i, cpu, busiest_cpu;
> > >
> > > Redefining cpu here. Looks like the cpu parameter is not really needed?
> >
> > Seems that way indeed, I went back and forth a few times on the actual
> > implementation of this function (which started out live as a copy of
> > check_power_save_busiest_group), its amazing there were only these two
> > compile glitches ;-)
>
> :-)
>
> Below are the cleanups + the arch specific bits. It doesn't change your
> logic at all. Obviously the PPC arch bits would need to be split into a
> separate patch.
>
> Compiles and boots against linux-next.
I have some comments on the code inline but...
So when I run this, I don't get processes pulled down to the lower
threads. A simple test case of running 1 CPU intensive process at
SCHED_OTHER on a machine with 2 way SMT system (a POWER6 but enabling
SD_ASYM_PACKING). The single processes doesn't move to lower threads as
I'd hope.
Also, are you sure you want to put this in generic code? It seem to be
quite POWER7 specific functionality, so would be logically better in
arch/powerpc. I guess some other arch *might* need it, but seems
unlikely.
> Mikey
> ---
> arch/powerpc/include/asm/cputable.h | 3 +
> arch/powerpc/kernel/process.c | 7 +++
> include/linux/sched.h | 4 +-
> include/linux/topology.h | 1
> kernel/sched_fair.c | 64 +++++++++++++++++++++++++++++++++
+--
> 5 files changed, 74 insertions(+), 5 deletions(-)
>
> Index: linux-next/arch/powerpc/include/asm/cputable.h
> ===================================================================
> --- linux-next.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-next/arch/powerpc/include/asm/cputable.h
> @@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
> #define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
> #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
> #define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
> +#define CPU_FTR_ASYM_SMT4 LONG_ASM_CONST(0x0100000000000000)
>
> #ifndef __ASSEMBLY__
>
> @@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
> CPU_FTR_MMCRA | CPU_FTR_SMT | \
> CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
> CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
> - CPU_FTR_DSCR | CPU_FTR_SAO)
> + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT4)
> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> Index: linux-next/arch/powerpc/kernel/process.c
> ===================================================================
> --- linux-next.orig/arch/powerpc/kernel/process.c
> +++ linux-next/arch/powerpc/kernel/process.c
> @@ -1265,3 +1265,10 @@ unsigned long randomize_et_dyn(unsigned
>
> return ret;
> }
> +
> +int arch_sd_asym_packing(void)
> +{
> + if (cpu_has_feature(CPU_FTR_ASYM_SMT4))
> + return SD_ASYM_PACKING;
> + return 0;
> +}
> Index: linux-next/include/linux/sched.h
> ===================================================================
> --- linux-next.orig/include/linux/sched.h
> +++ linux-next/include/linux/sched.h
> @@ -849,7 +849,7 @@ enum cpu_idle_type {
> #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
> #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
> #define SD_SERIALIZE 0x0400 /* Only a single load balancing instanc
e */
> -
> +#define SD_ASYM_PACKING 0x0800 /* Asymetric SMT packing */
> #define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling d
omain */
>
> enum powersavings_balance_level {
> @@ -881,6 +881,8 @@ static inline int sd_balance_for_package
> return SD_PREFER_SIBLING;
> }
>
> +extern int arch_sd_asym_packing(void);
> +
> /*
> * Optimise SD flags for power savings:
> * SD_BALANCE_NEWIDLE helps agressive task consolidation and power savings.
> Index: linux-next/include/linux/topology.h
> ===================================================================
> --- linux-next.orig/include/linux/topology.h
> +++ linux-next/include/linux/topology.h
> @@ -102,6 +102,7 @@ int arch_update_cpu_topology(void);
> | 1*SD_SHARE_PKG_RESOURCES \
> | 0*SD_SERIALIZE \
> | 0*SD_PREFER_SIBLING \
> + | arch_sd_asym_packing() \
> , \
> .last_balance = jiffies, \
> .balance_interval = 1, \
> Index: linux-next/kernel/sched_fair.c
> ===================================================================
> --- linux-next.orig/kernel/sched_fair.c
> +++ linux-next/kernel/sched_fair.c
> @@ -2086,6 +2086,7 @@ struct sd_lb_stats {
> struct sched_group *this; /* Local group in this sd */
> unsigned long total_load; /* Total load of all groups in sd */
> unsigned long total_pwr; /* Total power of all groups in sd */
> + unsigned long total_nr_running;
> unsigned long avg_load; /* Average load across all groups in sd */
>
> /** Statistics of this group */
> @@ -2493,6 +2494,28 @@ static inline void update_sg_lb_stats(st
> DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);
> }
>
> +static int update_sd_pick_busiest(struct sched_domain *sd,
> + struct sd_lb_stats *sds,
> + struct sched_group *sg,
> + struct sg_lb_stats *sgs)
> +{
> + if (sgs->sum_nr_running > sgs->group_capacity)
> + return 1;
> +
> + if (sgs->group_imb)
> + return 1;
> +
> + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
If we are asymetric packing...
> + if (!sds->busiest)
> + return 1;
This just seems to be a null pointer check.
>From the tracing I've done, this is always true (always NULL) at this
point so we return here.
> +
> + if (group_first_cpu(sds->busiest) < group_first_cpu(sg))
> + return 1;
I'm a bit lost as to what this is for. Any clues you could provide
would be appreciated. :-)
Is the first cpu in this domain's busiest group before the first cpu in
this group. If, so pick this as the busiest?
Should this be the other way around if we want to pack the busiest to
the first cpu? Mark it as the busiest if it's after (not before).
Is group_first_cpu guaranteed to give us the first physical cpu (ie.
thread 0 in our case) or are these virtualised at this point?
I'm not seeing this hit anyway due to the null pointer check above.
> + }
> +
> + return 0;
> +}
> +
> /**
> * update_sd_lb_stats - Update sched_group's statistics for load balancing.
> * @sd: sched_domain whose statistics are to be updated.
> @@ -2533,6 +2556,7 @@ static inline void update_sd_lb_stats(st
>
> sds->total_load += sgs.group_load;
> sds->total_pwr += group->cpu_power;
> + sds->total_nr_running += sgs.sum_nr_running;
>
> /*
> * In case the child domain prefers tasks go to siblings
> @@ -2547,9 +2571,8 @@ static inline void update_sd_lb_stats(st
> sds->this = group;
> sds->this_nr_running = sgs.sum_nr_running;
> sds->this_load_per_task = sgs.sum_weighted_load;
> - } else if (sgs.avg_load > sds->max_load &&
> - (sgs.sum_nr_running > sgs.group_capacity ||
> - sgs.group_imb)) {
> + } else if (sgs.avg_load >= sds->max_load &&
> + update_sd_pick_busiest(sd, sds, group, &sgs)) {
This is pretty clear. Moving stuff to the new function.
> sds->max_load = sgs.avg_load;
> sds->busiest = group;
> sds->busiest_nr_running = sgs.sum_nr_running;
> @@ -2562,6 +2585,38 @@ static inline void update_sd_lb_stats(st
> } while (group != sd->groups);
> }
>
> +int __weak sd_asym_packing_arch(void)
> +{
> + return 0;
> +}
> +
> +static int check_asym_packing(struct sched_domain *sd,
> + struct sd_lb_stats *sds,
> + unsigned long *imbalance)
> +{
> + int i, cpu, busiest_cpu;
> +
> + if (!(sd->flags & SD_ASYM_PACKING))
> + return 0;
> +
> + if (!sds->busiest)
> + return 0;
> +
> + i = 0;
> + busiest_cpu = group_first_cpu(sds->busiest);
> + for_each_cpu(cpu, sched_domain_span(sd)) {
> + i++;
> + if (cpu == busiest_cpu)
> + break;
> + }
> +
> + if (sds->total_nr_running > i)
> + return 0;
This seems to be the core of the packing logic.
We make sure the busiest_cpu is not past total_nr_running. If it is we
mark as imbalanced. Correct?
It seems if a non zero thread/group had a pile of processes running on
it and a lower thread had much less, this wouldn't fire, but I'm
guessing normal load balancing would kick in that case to fix the
imbalance.
Any corrections to my ramblings appreciated :-)
Thanks again,
Mikey
> +
> + *imbalance = sds->max_load;
> + return 1;
> +}
> +
> /**
> * fix_small_imbalance - Calculate the minor imbalance that exists
> * amongst the groups of a sched_domain, during
> @@ -2761,6 +2816,9 @@ find_busiest_group(struct sched_domain *
> return sds.busiest;
>
> out_balanced:
> + if (check_asym_packing(sd, &sds, imbalance))
> + return sds.busiest;
> +
> /*
> * There is no obvious imbalance. But check if we can do some balancing
> * to save power.
^ permalink raw reply
* Re: default stack size for threads changed
From: Joakim Tjernlund @ 2010-02-23 6:56 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, miltonm
In-Reply-To: <14321.1266890296@neuling.org>
Michael Neuling <mikey@neuling.org> wrote on 2010/02/23 02:58:16:
>
> In message <OF21CCB5A6.CDFDB6C1-ONC12576D2.00430B25-C12576D2.
> 0043C4BB@transmode.se> you wrote:
> >
> > With current, 2.6.33-rc6, linux the default stack size changed from unlimited
> > to 8MB:
> > # > ulimit -s
> > 8192
> >
> > This makes NPTL allocate a 8MB stack for each thread that is created.
> > This breaks in our embedded system. Although this
> > can be fixed in our app I wonder if this is intentional?
>
> When did this change from unlimited?
Sometime after 2.6.30 since that was the previous kernel we used, but I see
now that I read the wrong line. The stack size was 8MB in 2.6.30 too so
something else caused the high stack usage.
>
> It's unlikely but this might be related
> 803bf5ec259941936262d10ecc84511b76a20921 (post rc7). You'll also need
> to grab this http://patchwork.kernel.org/patch/79365/.
I see, will try. Hope fully I will see an improvement. Thanks.
>
> Mikey
>
> >
> > Jocke
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
>
>
^ permalink raw reply
* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: K.Prasad @ 2010-02-23 10:57 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Mahesh Salgaonkar, Will Deacon, David Gibson, linuxppc-dev,
Alan Stern, paulus, Roland McGrath
In-Reply-To: <20100222131746.GA3228@in.ibm.com>
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
> On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
> > On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
[snipped]
> > Also, do you think addr/len/type is enough to abstract out
> > any ppc breakpoints?
> >
> > This looks enough to me to express range breakpoints and
> > simple breakpoints. But what about value comparison?
> > (And still, there may be other trickier implementations
> > I don't know in ppc).
> >
>
> The above implementation is for PPC64 architecture that supports only
> 'simple' breakpoints of fixed length (no range breakpoints, no value
> comparison). More on that below.
>
Looks like I forgot the 'more on that below' part :-)....here are some
thoughts...
Architectures like PPC Book-E have support for a variety of
sophisticated debug features and our generic framework, in its present
form, cannot easily port itself to these processors. In order to extend
the framework for PPC Book-E, I intend the following to begin with:
- Implement support for data breakpoints through DAC registers with all
the 'bells and whistles'...support for instruction breakpoints through
IAC can come in later (without precluding its use through ptrace).
- Embed the flags/variables to store DVC, masked address mode, etc. in
'struct arch_hw_breakpoint', which will be populated by the user of
register_breakpoint interface.
Apart from the above extensions to the framework, changes in the generic
code would be required as described in an earlier LKML mail (ref:
message-id: 20091127190705.GB18408@in.ibm.com)....relevant contents
pasted below:
"I think the register_<> interfaces can become wrappers around functions
that do the following:
- arch_validate(): Validate request by invoking an arch-dependant
routine. Proceed if returned valid.
- arch-specific debugreg availability: Do something like
if (arch_hw_breakpoint_availabile())
bp = perf_event_create_kernel_counter();
perf_event_create_kernel_counter()--->arch_install_hw_breakpoint();
This way, all book-keeping related work (no. of pinned/flexible/per-cpu)
will be moved to arch-specific files (will be helpful for PPC Book-E
implementation having two types of debug registers). Every new
architecture that intends to port to the new hw-breakpoint
implementation must define their arch_validate(),
arch_hw_breakpoint_available() and an arch_install_hw_breakpoint(),
while the hw-breakpoint code will be flexible enough to extend itself to
each of these archs."
Let me know what you think of the above.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH 1/4] Add ps3_storage module alias
From: David Woodhouse @ 2010-02-23 12:47 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.1002051446280.5981@mink.sonytel.be>
On Fri, 2010-02-05 at 14:49 +0100, Geert Uytterhoeven wrote:
> On Fri, 5 Feb 2010, Josh Boyer wrote:
> > This allows the upgrade path from older kernel releases to work
> > with the Fedora mkinitrd tool.
> >
> > ---
> >
> > --- linux-2.6.22.ppc64/drivers/block/ps3disk.c~ 2007-07-25 16:06:16.000000000 +0100
> > +++ linux-2.6.22.ppc64/drivers/block/ps3disk.c 2007-07-26 08:49:44.000000000 +0100
> > @@ -628,3 +628,4 @@ MODULE_LICENSE("GPL");
> > MODULE_DESCRIPTION("PS3 Disk Storage Driver");
> > MODULE_AUTHOR("Sony Corporation");
> > MODULE_ALIAS(PS3_MODULE_ALIAS_STOR_DISK);
> > +MODULE_ALIAS("ps3_storage");
>
> NAKed-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> ps3_storage was replaced by 3 drivers: ps3disk, ps3rom, and ps3flash. These are
> automatically loaded by udev.
>
> How does mkinitrd determine the driver for the root file system on other
> systems? Does it really contain a big list of e.g. all SCSI drivers?
It pokes about in sysfs and works out the driver which is used for the
current root devices.
This hack was only needed for the upgrade -- when you were running a
kernel with the ps3_storage kernel and you first installed a kernel with
the new ps3disk driver, you needed it to find the right module.
I think we can drop it now.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
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