* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Kevin Diggs @ 2008-08-27 9:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200808261329.22699.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 26 August 2008, Kevin Diggs wrote:
>
>>Arnd Bergmann wrote:
>>
>>>On Monday 25 August 2008, Kevin Diggs wrote:
>
>
>>>Most people list their email address here as well
>>>
>>
>>For reasons I'd rather not go into, my email address is not likely
>>to remain valid for much longer.
>
>
> Maybe you should get a freemail account somewhere then.
> It's better if people have a way to Cc the author of
> a file when they make changes to it.
>
That won't really help either.
>
>>>drop the _t here, or make explicit what is meant by it.
>>>
>>
>>Now that I look at it the _t is supposed to be at the end. It is
>>meant to indicate that this is a structure tag or type. I'll
>>remove it.
>
>
> Ok, thanks for the explanation. I now saw that you also
> use '_v' for variables (I guess). These should probably
> go the same way.
>
Actually the _v means global variable. I would prefer to keep it.
>
>>>>+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
>>>>+
>>>>+static unsigned int override_min_core = 0;
>>>>+static unsigned int override_max_core = 0;
>>>>+static unsigned int minmaxmode = 0;
>>>>+
>>>>+static unsigned int cf750gx_v_min_core = 0;
>>>>+static unsigned int cf750gx_v_max_core = 0;
>>>>+static int cf750gx_v_idle_pll_off = 0;
>>>>+static int cf750gx_v_min_max_mode = 0;
>>>>+static unsigned long cf750gx_v_state_bits = 0;
>>>
>>>
>>>Is 0 a meaningful value for these? If it just means 'uninitialized',
>>>then better don't initialize them in the first place, for clarity.
>>>
>>
>>The first 3 are module parameters. For the first 2, 0 means
>>that they were not set. minmaxmode is a boolean. 0 is the
>>default of disabled.
>
>
> Then at least for the first two, the common coding style would
> be to leave out the '= 0'. For minmaxmode, the most expressive
> way would be to define an enum, like
>
> enum {
> MODE_NORMAL,
> MODE_MINMAX,
> };
>
> int minmaxmode = MODE_NORMAL;
>
Since this is a boolean parameter I don't know? What if I change the
name to enable_minmax. And actually use the "bool" module parameter
type?
>
>>..._min_max_mode is a boolean to hold the state of
>>minmaxmode. Seems to be only used to print the current
>>value.
>
>
> this looks like a duplicate then. why would you need both?
> It seems really confusing to have both a cpufreq attribute
> and a module attribute with the same name, writing to
> different variables.
>
I probably don't need both? I kinda treat the variables tied to module
parameters as read only.
>
> Are there even SMP boards based on a 750? I thought only 74xx
> and 603/604 were SMP capable.
>
Not that I have heard of. I thought it was lacking some hardware that
was needed to do SMP? Can the 603 do SMP?
>
>>>>+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
>>>>+ action, void *data)
>>>>+{
>>>>+struct cf750gx_t_call_data *cd;
>>>>+unsigned int idle_pll;
>>>>+unsigned int pll_off_cmd;
>>>>+unsigned int new_pll;
>>>
>>>
>>>The whitespace appears damaged here.
>>>
>>
>>Just a coding style thing. I put declarations (or definitions -
>>I get the two confused?) on the same indent as the block they are
>>in. Is this a 15 yard illegal procedure penalty?
>
>
> I've never seen that style before. Better do what everyone
> else does here, e.g. using 'indent -kr -i8'.
>
Ok, I'll fix this.
>
>>>>+ dprintk(__FILE__">%s()-%d: Modifying PLL: 0x%x\n", __func__, __LINE__,
>>>>+ new_pll);
>>>
>>>
>>>Please go through all your dprintk and see if you really really need all of them.
>>>Usually they are useful while you are doing the initial code, but only get in the
>>>way as soon as it starts working.
>>>
>>
>>This from a code readability standpoint? Or an efficiency one?
>>I think the cpufreq stuff has a debug configure option that
>>disables compilation of these unless enabled.
>
>
> It's more about readability.
>
I removed a few. Let me know if I should whack some more (and which ones).
>
>>>>+ result = pllif_register_pll_switch_cb(&cf750gx_v_pll_switch_nb);
>>>>+
>>>>+ cf750gx_v_pll_lock_nb.notifier_call = cf750gx_pll_lock_cb;
>>>>+ cf750gx_v_pll_lock_nb.next =
>>>>+ (struct notifier_block *)&cf750gx_v_lock_call_data;
>>>
>>>
>>>These casts look wrong, cf750gx_v_lock_call_data is not a notifier_block.
>>>What are you trying to do here?
>>>
>>
>>Just a little sneaky. I should document in the kernel doc though.
>
>
> No, better avoid such hacks instead of documenting them. I think I
> now understand what you do there, and if I got it right, you should
> just pass two arguments to pllif_register_pll_switch_cb.
>
I'll fix this.
>
>>>>+static int cf750gx_cpu_exit(struct cpufreq_policy *policy)
>>>>+{
>>>>+ dprintk("%s()\n", __func__);
>>>>+
>>>>+ /*
>>>>+ * Wait for any active requests to ripple through before exiting
>>>>+ */
>>>>+ wait_for_completion(&cf750gx_v_exit_completion);
>>>
>>>
>>>This "wait for anything" use of wait_for_completion looks wrong,
>>>because once any other function has done the 'complete', you won't
>>>wait here any more.
>>>
>>>What exactly are you trying to accomplish with this?
>>>
>>
>>Originall I had something like:
>>
>> while(some_bit_is_still_set)
>> sleep
>>
>>I think you suggested I use a completion because it is in
>>fact simpler than a sleep. Now that I think about it also seems
>>intuitive to give the system a hint as to when something will
>>be done. 'complete' just means there is no timer pending (unless,
>>of course, I screwed up the code).
>
>
> The completion would certainly be better than the sleep here, but
> I think you shouldn't need that in the first place. AFAICT, you
> have three different kinds of events that you need to protect
> against, when some other code can call into your module:
>
> 1. timer function,
> 2. cpufreq notifier, and
> 3. sysfs attribute.
>
> In each case, the problem is a race between two threads that you
> need to close. In case of the timer, you need to call del_timer_sync
> because the timers already have this method builtin. For the other
> two, you already unregister the interfaces, which ought to be enough.
>
The choice I made here was to wait for the timer to fire rather than
to delete it. I think it is easier to just wait for it than to delete
it and try to get things back in order. Though since this is in a
module exit routine it probably does not matter. Also I would have to
check whether there was an analogous HRTimer call and call the right
one.
>
> Arnd <><
>
^ permalink raw reply
* Re: [PATCH][for 2.6.27] fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()
From: Jeff Garzik @ 2008-08-27 9:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, hs, davem, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0808252019030.20949@blarg.am.freescale.net>
Kumar Gala wrote:
> From: Heiko Schocher <hs@denx.de>
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Updated to apply cleanly to top of linus's tree.
>
> - k
>
> arch/powerpc/include/asm/cpm2.h | 5 +++++
> drivers/net/fs_enet/fs_enet-main.c | 8 ++++++++
> drivers/net/fs_enet/mac-scc.c | 8 +++++++-
> 3 files changed, 20 insertions(+), 1 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Don't call dev_mc_add() before device is registered
From: Jeff Garzik @ 2008-08-27 9:56 UTC (permalink / raw)
To: benh; +Cc: netdev, Sebastian Siewior, linuxppc-dev list
In-Reply-To: <1219008563.28339.15.camel@pasglop>
Benjamin Herrenschmidt wrote:
> We must not call dev_mc_add() from within our HW configure which happens
> before we initialize and register the netdev. Do it in open() instead.
>
> Thanks to Sebastian Siewior for tracking it down.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This fixes an uninitialized spinlock warning (and possibly more).
>
> Please apply.
applied
^ permalink raw reply
* [PATCH] cpm1: Fix race condition in CPM1 GPIO library.
From: Jochen Friedrich @ 2008-08-27 10:32 UTC (permalink / raw)
To: linuxppc-dev list
The CPM1 GPIO library code uses the non thread-safe clrbits32/setbits32
macros. This patch protects them with a spinlock.
Based on the CPM2 patch from Laurent Pinchart <laurentp@cse-semaphore.com>,
commit 639d64456e20cbfc866b18dc03cf9f9babc9c7cd.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/cpm1.c | 74 +++++++++++++++++++++++++++++++-------------
1 files changed, 52 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 4a04823..490473c 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -546,15 +546,11 @@ static int cpm1_gpio16_get(struct gpio_chip *gc, unsigned int gpio)
return !!(in_be16(&iop->dat) & pin_mask);
}
-static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
+static void __cpm1_gpio16_set(struct of_mm_gpio_chip *mm_gc, u16 pin_mask,
+ int value)
{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
struct cpm_ioport16 __iomem *iop = mm_gc->regs;
- unsigned long flags;
- u16 pin_mask = 1 << (15 - gpio);
-
- spin_lock_irqsave(&cpm1_gc->lock, flags);
if (value)
cpm1_gc->cpdata |= pin_mask;
@@ -562,6 +558,18 @@ static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
cpm1_gc->cpdata &= ~pin_mask;
out_be16(&iop->dat, cpm1_gc->cpdata);
+}
+
+static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ unsigned long flags;
+ u16 pin_mask = 1 << (15 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ __cpm1_gpio16_set(mm_gc, pin_mask, value);
spin_unlock_irqrestore(&cpm1_gc->lock, flags);
}
@@ -569,14 +577,17 @@ static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
struct cpm_ioport16 __iomem *iop = mm_gc->regs;
- u16 pin_mask;
+ unsigned long flags;
+ u16 pin_mask = 1 << (15 - gpio);
- pin_mask = 1 << (15 - gpio);
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
setbits16(&iop->dir, pin_mask);
+ __cpm1_gpio16_set(mm_gc, pin_mask, val);
- cpm1_gpio16_set(gc, gpio, val);
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
return 0;
}
@@ -584,13 +595,17 @@ static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
static int cpm1_gpio16_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
struct cpm_ioport16 __iomem *iop = mm_gc->regs;
- u16 pin_mask;
+ unsigned long flags;
+ u16 pin_mask = 1 << (15 - gpio);
- pin_mask = 1 << (15 - gpio);
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
clrbits16(&iop->dir, pin_mask);
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+
return 0;
}
@@ -655,15 +670,11 @@ static int cpm1_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
return !!(in_be32(&iop->dat) & pin_mask);
}
-static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+static void __cpm1_gpio32_set(struct of_mm_gpio_chip *mm_gc, u32 pin_mask,
+ int value)
{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
struct cpm_ioport32b __iomem *iop = mm_gc->regs;
- unsigned long flags;
- u32 pin_mask = 1 << (31 - gpio);
-
- spin_lock_irqsave(&cpm1_gc->lock, flags);
if (value)
cpm1_gc->cpdata |= pin_mask;
@@ -671,6 +682,18 @@ static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
cpm1_gc->cpdata &= ~pin_mask;
out_be32(&iop->dat, cpm1_gc->cpdata);
+}
+
+static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ __cpm1_gpio32_set(mm_gc, pin_mask, value);
spin_unlock_irqrestore(&cpm1_gc->lock, flags);
}
@@ -678,14 +701,17 @@ static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
static int cpm1_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
struct cpm_ioport32b __iomem *iop = mm_gc->regs;
- u32 pin_mask;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
- pin_mask = 1 << (31 - gpio);
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
setbits32(&iop->dir, pin_mask);
+ __cpm1_gpio32_set(mm_gc, pin_mask, val);
- cpm1_gpio32_set(gc, gpio, val);
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
return 0;
}
@@ -693,13 +719,17 @@ static int cpm1_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
static int cpm1_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
struct cpm_ioport32b __iomem *iop = mm_gc->regs;
- u32 pin_mask;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
- pin_mask = 1 << (31 - gpio);
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
clrbits32(&iop->dir, pin_mask);
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+
return 0;
}
--
1.5.6.3
^ permalink raw reply related
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: Kamalesh Babulal @ 2008-08-27 11:12 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Stephen Rothwell, LKML, linuxppc-dev, linux-next, mingo
In-Reply-To: <48B46610.1010809@linux.intel.com>
Arjan van de Ven wrote:
> Kamalesh Babulal wrote:
>> Hi Stephen,
>>
>> Badness warning is seen, while booting up the next-20080825/26 kernels on
>> the powerpc boxes
>>
>
> this is fixed in the patch I sent to Ingo earlier today
> (attached again for reference)
>
>
> ------------------------------------------------------------------------
>
> From eafa461d187448998b1f66c9134e66b125db9531 Mon Sep 17 00:00:00 2001
> From: Arjan van de Ven <arjan@linux.intel.com>
> Date: Tue, 26 Aug 2008 09:01:06 -0700
> Subject: [PATCH] debug: add notifier chain debugging
>
> during some development we suspected a case where we left something
> in a notifier chain that was from a module that was unloaded already...
> and that sort of thing is rather hard to track down.
>
> This patch adds a very simple sanity check (which isn't all that
> expensive) to make sure the notifier we're about to call is
> actually from either the kernel itself of from a still-loaded
> module, avoiding a hard-to-chase-down crash.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
> Acked-by: Tony Luck <tony.luck@intel.com>
> ---
> include/linux/kernel.h | 3 +++
> kernel/extable.c | 16 ++++++++++++++++
> kernel/notifier.c | 6 ++++++
> lib/vsprintf.c | 2 +-
> 4 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 2651f80..4e1366b 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -187,6 +187,9 @@ extern unsigned long long memparse(char *ptr, char **retptr);
> extern int core_kernel_text(unsigned long addr);
> extern int __kernel_text_address(unsigned long addr);
> extern int kernel_text_address(unsigned long addr);
> +extern int func_ptr_is_kernel_text(void *ptr);
> +extern void *dereference_function_descriptor(void *ptr);
> +
> struct pid;
> extern struct pid *session_of_pgrp(struct pid *pgrp);
>
> diff --git a/kernel/extable.c b/kernel/extable.c
> index a26cb2e..adf0cc9 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -66,3 +66,19 @@ int kernel_text_address(unsigned long addr)
> return 1;
> return module_text_address(addr) != NULL;
> }
> +
> +/*
> + * On some architectures (PPC64, IA64) function pointers
> + * are actually only tokens to some data that then holds the
> + * real function address. As a result, to find if a function
> + * pointer is part of the kernel text, we need to do some
> + * special dereferencing first.
> + */
> +int func_ptr_is_kernel_text(void *ptr)
> +{
> + unsigned long addr;
> + addr = (unsigned long) dereference_function_descriptor(ptr);
> + if (core_kernel_text(addr))
> + return 1;
> + return module_text_address(addr) != NULL;
> +}
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 823be11..522277c 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -82,6 +82,12 @@ static int __kprobes notifier_call_chain(struct notifier_block **nl,
>
> while (nb && nr_to_call) {
> next_nb = rcu_dereference(nb->next);
> + if (!func_ptr_is_kernel_text(nb->notifier_call)) {
> + WARN(1, "Invalid notifier called!");
> + nb = next_nb;
> + continue;
> + }
> +
> ret = nb->notifier_call(nb, val, v);
>
> if (nr_calls)
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index d8d1d11..f5e5ffb 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -513,7 +513,7 @@ static char *string(char *buf, char *end, char *s, int field_width, int precisio
> return buf;
> }
>
> -static inline void *dereference_function_descriptor(void *ptr)
> +void *dereference_function_descriptor(void *ptr)
> {
> #if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
> void *p;
Thanks for reference of the patch, After replacing the patch with the latest
one above on the powerpc, the warning still remains
Badness at kernel/notifier.c:86
NIP: c000000000081470 LR: c000000000081494 CTR: c00000000005a2d0
REGS: c0000021ce0bfaf0 TRAP: 0700 Not tainted (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24008042 XER: 00000005
TASK = c0000015de080000[1] 'swapper' THREAD: c0000021ce0bc000 CPU: 0
GPR00: c000000000081494 c0000021ce0bfd70 c00000000081e940 c000000000749c38
GPR04: 0000000000000003 0000000000000001 ffffffffffffffff c0000021ce0bfe90
GPR08: ffffffffffffffff ffffffffffffffff c0000000004fd9f0 c0000000004fd9f0
GPR12: 0000000024000042 c00000000089c300 0000000002307ef0 c0000000006332a0
GPR16: c000000000631f28 c000000000633388 00000000018bf8b0 0000000002700000
GPR20: c00000000070b07c c000000000707ef0 c000000000708160 c000000000631c58
GPR24: 0000000000000003 0000000000000001 c0000021ce0bfe90 0000000000000000
GPR28: ffffffffffffffff c000000000749c20 c0000000007bf338 c000000000749c38
NIP [c000000000081470] .notifier_call_chain+0x70/0x140
LR [c000000000081494] .notifier_call_chain+0x94/0x140
Call Trace:
[c0000021ce0bfd70] [c000000000081494] .notifier_call_chain+0x94/0x140 (unreliable)
[c0000021ce0bfe20] [c0000000004fe3fc] .cpu_up+0x10c/0x200
[c0000021ce0bfee0] [c0000000006cdcc0] .kernel_init+0x1b0/0x440
[c0000021ce0bff90] [c0000000000299cc] .kernel_thread+0x4c/0x68
Instruction dump:
e8630000 2fa30000 419e00f0 2fa60000 419e00e8 2e270000 7c7f1b78 3b600000
48000028 60000000 60000000 60000000 <0fe00000> 2fbd0000 2f3c0000 7fbfeb78
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Arnd Bergmann @ 2008-08-27 11:34 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <48B51A31.8090909@hypersurf.com>
On Wednesday 27 August 2008, Kevin Diggs wrote:
> Arnd Bergmann wrote:
> > Ok, thanks for the explanation. I now saw that you also
> > use '_v' for variables (I guess). These should probably
> > go the same way.
> >
> Actually the _v means global variable. I would prefer to keep it.
The reasoning on Linux is that you can tell from the declaration
whether something is global or automatic. In fact, functions should
be so short that you can always see all automatic declarations
when you look at some code.
If you use nonstandard variable naming, people will never stop
asking you about that, so it's easier to just to the same as
everyone else.
> >
> > Then at least for the first two, the common coding style would
> > be to leave out the '= 0'. For minmaxmode, the most expressive
> > way would be to define an enum, like
> >
> > enum {
> > MODE_NORMAL,
> > MODE_MINMAX,
> > };
> >
> > int minmaxmode = MODE_NORMAL;
> >
> Since this is a boolean parameter I don't know? What if I change the
> name to enable_minmax. And actually use the "bool" module parameter
> type?
Module parameter names should be short, so just "minmax" would
be a good name, but better put the module_param() line right
after that. If it's a bool type, I would just leave out the
initialization.
> >>..._min_max_mode is a boolean to hold the state of
> >>minmaxmode. Seems to be only used to print the current
> >>value.
> >
> >
> > this looks like a duplicate then. why would you need both?
> > It seems really confusing to have both a cpufreq attribute
> > and a module attribute with the same name, writing to
> > different variables.
> >
> I probably don't need both? I kinda treat the variables tied to module
> parameters as read only.
But you have marked as read/write in the module_param line.
I would prefer to just have the module parameter and have
a tool to modify that one.
If a module parameter only makes sense as read-only, you
should mark it as 0444 instead of 0644, but this one looks
like it can be writable.
> > Are there even SMP boards based on a 750? I thought only 74xx
> > and 603/604 were SMP capable.
> >
> Not that I have heard of. I thought it was lacking some hardware that
> was needed to do SMP? Can the 603 do SMP?
No, I was wrong about the 603. The machine I was thinking of is actually
604e.
> > The completion would certainly be better than the sleep here, but
> > I think you shouldn't need that in the first place. AFAICT, you
> > have three different kinds of events that you need to protect
> > against, when some other code can call into your module:
> >
> > 1. timer function,
> > 2. cpufreq notifier, and
> > 3. sysfs attribute.
> >
> > In each case, the problem is a race between two threads that you
> > need to close. In case of the timer, you need to call del_timer_sync
> > because the timers already have this method builtin. For the other
> > two, you already unregister the interfaces, which ought to be enough.
> >
> The choice I made here was to wait for the timer to fire rather than
> to delete it. I think it is easier to just wait for it than to delete
> it and try to get things back in order. Though since this is in a
> module exit routine it probably does not matter. Also I would have to
> check whether there was an analogous HRTimer call and call the right
> one.
I think the module_exit() function should leave the frequency in a
well-defined state, so the easiest way to get there is probably
to delete the timer, and then manually set the frequency.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Geert Uytterhoeven @ 2008-08-27 11:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Kevin Diggs, linux-kernel
In-Reply-To: <200808271334.16712.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 883 bytes --]
On Wed, 27 Aug 2008, Arnd Bergmann wrote:
> On Wednesday 27 August 2008, Kevin Diggs wrote:
> > Arnd Bergmann wrote:
> > > Are there even SMP boards based on a 750? I thought only 74xx
> > > and 603/604 were SMP capable.
> > >
> > Not that I have heard of. I thought it was lacking some hardware that
> > was needed to do SMP? Can the 603 do SMP?
>
> No, I was wrong about the 603. The machine I was thinking of is actually
> 604e.
The BeBox had a dual 603.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Chris Skepper @ 2008-08-27 13:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <48B43C42.5040407@freescale.com>
On Tue, 26 Aug 2008, Scott Wood wrote:
>>> It's usually easiest to just trust that that part of the code works (in
>>> my experience, that's rarely where a hang actually occurs when bringing
>>> up a new board), and resume tracing after the MMU is on and you've
>>> inserted a caching-inhibited BAT entry.
>>
>> Where can I find out how to do that? Since I have this board working with
>> the old ARCH=ppc, can I copy anything from there?
>
> See setup_cpm_bat in arch/powerpc/kernel/head_32.S.
>
>> Also, where would be a good place in the code to resume tracing?
>
> As soon as you can set up a BAT -- though first, I would try just enabling
> the CPM debug console and see if you get anything from that.
Thanks very much for your help so far. I tried enabling the console and
didn't get anything output. So I resumed tracing and discovered it gets
much further, as far as udbg_init_cpm and udbg_putc_cpm in cpm_common.c
However, it never gets that first 'X' printed because it appears to hang
when it gets to this bit:
out_8(txbuf, c);
out_be32(&cpm_udbg_txdesc[0], 0xa0000001);
I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
Is that likely to be correct for SMC1? (I tried looking in the MPC8272
reference manual, but couldn't find it.)
Is it likely the port isn't set up properly? udbg_early_init and
udbg_init_cpm get called before it probes the machine so there's been no
chance to do cpm2_set_pin or anything.
Cheers,
Chris.
^ permalink raw reply
* [PATCH 04/59] CRED: Wrap task credential accesses in the PowerPC arch
From: David Howells @ 2008-08-27 13:46 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-security-module, Paul Mackerras, Serge Hallyn
In-Reply-To: <20080827134541.19980.61042.stgit@warthog.procyon.org.uk>
Wrap access to task credentials so that they can be separated more easily from
the task_struct during the introduction of COW creds.
Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
sense to use RCU directly rather than a convenient wrapper; these will be
addressed by later patches.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/platforms/cell/spufs/inode.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 565b7a2..8660986 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -339,7 +339,7 @@ bad_area_nosemaphore:
&& printk_ratelimit())
printk(KERN_CRIT "kernel tried to execute NX-protected"
" page (%lx) - exploit attempt? (uid: %d)\n",
- address, current->uid);
+ address, current_uid());
return SIGSEGV;
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 690ca7b..60bd5ed 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -95,8 +95,8 @@ spufs_new_inode(struct super_block *sb, int mode)
goto out;
inode->i_mode = mode;
- inode->i_uid = current->fsuid;
- inode->i_gid = current->fsgid;
+ inode->i_uid = current_fsuid();
+ inode->i_gid = current_fsgid();
inode->i_blocks = 0;
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
out:
^ permalink raw reply related
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: Arjan van de Ven @ 2008-08-27 13:48 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: Stephen Rothwell, LKML, linuxppc-dev, linux-next, mingo
In-Reply-To: <48B53695.3020703@linux.vnet.ibm.com>
Kamalesh Babulal wrote:
>
> Thanks for reference of the patch, After replacing the patch with the latest
> one above on the powerpc, the warning still remains
>
> Badness at kernel/notifier.c:86
sadly you have something going on that doesn't list the modules loaded etc...
is this during boot or way later?
(because if it's the later, you might be hitting a legitimate bug ;-)
> NIP: c000000000081470 LR: c000000000081494 CTR: c00000000005a2d0
> REGS: c0000021ce0bfaf0 TRAP: 0700 Not tainted (2.6.27-rc4-next-20080826-autotest)
> MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24008042 XER: 00000005
> TASK = c0000015de080000[1] 'swapper' THREAD: c0000021ce0bc000 CPU: 0
> GPR00: c000000000081494 c0000021ce0bfd70 c00000000081e940 c000000000749c38
> GPR04: 0000000000000003 0000000000000001 ffffffffffffffff c0000021ce0bfe90
> GPR08: ffffffffffffffff ffffffffffffffff c0000000004fd9f0 c0000000004fd9f0
> GPR12: 0000000024000042 c00000000089c300 0000000002307ef0 c0000000006332a0
> GPR16: c000000000631f28 c000000000633388 00000000018bf8b0 0000000002700000
> GPR20: c00000000070b07c c000000000707ef0 c000000000708160 c000000000631c58
> GPR24: 0000000000000003 0000000000000001 c0000021ce0bfe90 0000000000000000
> GPR28: ffffffffffffffff c000000000749c20 c0000000007bf338 c000000000749c38
> NIP [c000000000081470] .notifier_call_chain+0x70/0x140
> LR [c000000000081494] .notifier_call_chain+0x94/0x140
> Call Trace:
> [c0000021ce0bfd70] [c000000000081494] .notifier_call_chain+0x94/0x140 (unreliable)
> [c0000021ce0bfe20] [c0000000004fe3fc] .cpu_up+0x10c/0x200
> [c0000021ce0bfee0] [c0000000006cdcc0] .kernel_init+0x1b0/0x440
> [c0000021ce0bff90] [c0000000000299cc] .kernel_thread+0x4c/0x68
> Instruction dump:
> e8630000 2fa30000 419e00f0 2fa60000 419e00e8 2e270000 7c7f1b78 3b600000
> 48000028 60000000 60000000 60000000 <0fe00000> 2fbd0000 2f3c0000 7fbfeb78
>
>
^ permalink raw reply
* Re: gdb problems with threads on mpc512x
From: Daniele Bosi @ 2008-08-27 13:58 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20080825182053.B804B248CA@gemini.denx.de>
[-- Attachment #1: Type: text/html, Size: 5240 bytes --]
^ permalink raw reply
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: Stephen Rothwell @ 2008-08-27 14:33 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: LKML, Kamalesh Babulal, linuxppc-dev, linux-next, mingo
In-Reply-To: <48B55B16.7060804@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
Hi Arjan,
On Wed, 27 Aug 2008 06:48:06 -0700 Arjan van de Ven <arjan@linux.intel.com> wrote:
>
> Kamalesh Babulal wrote:
> >
> > Thanks for reference of the patch, After replacing the patch with the latest
> > one above on the powerpc, the warning still remains
> >
> > Badness at kernel/notifier.c:86
>
> sadly you have something going on that doesn't list the modules loaded etc...
>
> is this during boot or way later?
> (because if it's the later, you might be hitting a legitimate bug ;-)
The original reported trace was during setup_system which is very early in
the boot.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: Stephen Rothwell @ 2008-08-27 14:38 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: LKML, Kamalesh Babulal, linuxppc-dev, linux-next, mingo
In-Reply-To: <20080828003308.400038e0.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi Arjan,
On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The original reported trace was during setup_system which is very early in
> the boot.
But, of course, that version didn't have the necessary extra dereference
of the function address ...
And the later debug patch did not check the address at register time,
only at notify time.
The later trace also looks to be early in the boot.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata
From: Alan Stern @ 2008-08-27 14:36 UTC (permalink / raw)
To: Vitaly Bordug
Cc: Stefan Roese, linuxppc-dev@ozlabs.org, linux-usb, Mark Miesfeld
In-Reply-To: <20080827022351.67e8a9b2@vitb-lp>
On Wed, 27 Aug 2008, Vitaly Bordug wrote:
> A published errata for ppc440epx states, that when running Linux with both
> EHCI and OHCI modules loaded, the EHCI module experiences a fatal error
> when a high-speed device is connected to the USB2.0, and functions normally
> if OHCI module is not loaded.
>
> Quote from original descriprion:
>
> The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In USB
> 2.0 Host controllers, each EHCI controller has one or more companion
> controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
> contain one or more ports. For each port, only one of the controllers is
> connected at any one time. In the 440EPx, there is only one OHCI companion controller,
> and only one USB 2.0 Host port.
> All ports on an USB 2.0 controller default to the companion controller. If
> you load only an ohci driver, it will have control of the ports and any
> deviceplugged in will operate, although high speed devices will be forced to
> operate at full speed. When an ehci driver is loaded, it explicitly takes control
> of the ports. If there is a device connected, and / or every time there is a
> new device connected, the ehci driver determines if the device is high speed or
> not. If it is high speed, the driver retains control of the port. If it
> is not, the driver explicitly gives the companion controller control of the
> port.
This doesn't explain why the fatal error occurs.
> The is a software workaround that uses
> Initial version of the software workaround was posted to linux-usb-devel:
>
> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
>
> and later available from amcc.com:
> http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
>
> The patch below is generally based on the latter, but reworked to
> powerpc/of_device USB drivers, and uses a few devicetree inquiries to get
> rid of all the hardcoded defines and CONFIG_* stuff, in favor to
> defining specific quirk. The latter required to add more accurate
> description into compatible field of USB node for 'sequioia' board.
I have some doubts about parts of this patch.
> --- a/drivers/usb/host/ehci-ppc-of.c
> +++ b/drivers/usb/host/ehci-ppc-of.c
> @@ -107,16 +107,17 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
> {
> struct device_node *dn = op->node;
> struct usb_hcd *hcd;
> - struct ehci_hcd *ehci;
> + struct ehci_hcd *ehci = NULL;
> struct resource res;
> int irq;
> int rv;
>
> + struct device_node *np;
> +
> if (usb_disabled())
> return -ENODEV;
>
> dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
> -
> rv = of_address_to_resource(dn, 0, &res);
> if (rv)
> return rv;
> @@ -125,6 +126,7 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
> if (!hcd)
> return -ENOMEM;
>
> +
Is there any reason for these apparently gratuitous whitespace changes?
> hcd->rsrc_start = res.start;
> hcd->rsrc_len = res.end - res.start + 1;
>
> @@ -172,6 +174,21 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
> rv ? "NOT ": "");
> }
>
> + np = of_find_compatible_node(NULL, NULL, "ibm,usb-ohci-440epx");
> + if (np != NULL) {
> + /* claim we really affected by usb23 erratum */
> + ehci->has_amcc_usb23 = 1;
> + if (!of_address_to_resource(np, 0, &res))
> + ehci->ohci_hcctrl_reg = ioremap(res.start +
> + OHCI_HCCTRL_OFFSET, OHCI_HCCTRL_LEN);
> + else
> + pr_debug(__FILE__ ": no ohci offset in fdt\n");
> + if (!ehci->ohci_hcctrl_reg) {
> + pr_debug(__FILE__ ": ioremap for ohci hcctrl failed\n");
> + return -ENOMEM;
This is a memory leak.
> --- a/drivers/usb/host/ehci.h
> +++ b/drivers/usb/host/ehci.h
> @@ -809,6 +819,20 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd *ehci, const __hc32 *x)
> le32_to_cpup((__force __le32 *)x);
> }
>
> +static inline void set_ohci_hcfs(struct ehci_hcd *ehci, int operational)
> +{
> + u32 hc_control;
> +
> + hc_control = (readl_be(ehci->ohci_hcctrl_reg) & ~OHCI_CTRL_HCFS);
> + if (operational)
> + hc_control |= OHCI_USB_OPER;
> + else
> + hc_control |= OHCI_USB_SUSPEND;
> +
> + writel_be(hc_control, ehci->ohci_hcctrl_reg);
> + (void) readl_be(ehci->ohci_hcctrl_reg);
> +}
> +
This should be protected by a preprocessor test so that the code
doesn't get compiled on architectures that don't need it.
> --- a/drivers/usb/host/ohci-ppc-of.c
> +++ b/drivers/usb/host/ohci-ppc-of.c
> @@ -148,6 +148,31 @@ ohci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
> if (rv == 0)
> return 0;
>
> + /* by now, 440epx is known to show usb_23 erratum */
> + np = of_find_compatible_node(NULL, NULL, "ibm,usb-ehci-440epx");
> +
> + /* Work around - At this point ohci_run has executed, the
> + * controller is running, everything, the root ports, etc., is
> + * set up. If the ehci driver is loaded, put the ohci core in
> + * the suspended state. The ehci driver will bring it out of
> + * suspended state when / if a non-high speed USB device is
> + * attached to the USB Host port. If the ehci driver is not
> + * loaded, do nothing. request_mem_region is used to test if
> + * the ehci driver is loaded.
> + */
> + if (np != NULL) {
> + ohci->flags |= OHCI_QUIRK_AMCC_USB23;
> + if (!of_address_to_resource(np, 0, &res))
> + if (!request_mem_region(res.start, 0x4, hcd_name)) {
> + writel_be((readl_be(&ohci->regs->control) |
> + OHCI_USB_SUSPEND), &ohci->regs->control);
> + (void) readl_be(&ohci->regs->control);
Wrong indentation level.
> + } else {
> + release_mem_region(res.start, 0x4);
> + }
> + else
> + pr_debug(__FILE__ ": cannot get ehci offset from fdt\n");
Wrong indentation amount.
> + }
> iounmap(hcd->regs);
> err_ioremap:
> irq_dispose_mapping(irq);
I doubt this will interact properly with usbcore and the rest of
ohci-hcd. They do not expect the root hub to be suspended unless they
know about it.
Alan Stern
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Scott Wood @ 2008-08-27 15:01 UTC (permalink / raw)
To: Chris Skepper; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0808271413001.14220@chara.vm.bytemark.co.uk>
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> Is it likely the port isn't set up properly? udbg_early_init and
> udbg_init_cpm get called before it probes the machine so there's been no
> chance to do cpm2_set_pin or anything.
For the early console to work, the pins must have been set up properly by
firmware.
-Scott
^ permalink raw reply
* [TTY] driver sriel tty on ppc board
From: Sébastien Chrétien @ 2008-08-27 15:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Hello,
I am trying to code a tty serial driver (UART link). The initialization is :
(model LDD 3)
static int __init tiny_tty_init(void)
{
int i, retval;
printk("Initialization of ttyS -> \n");
tiny_tty_driver=alloc_tty_driver(NB_TTY);
if(!tiny_tty_driver)
return -ENOMEM;
/*Initialize the tty driver*/
tiny_tty_driver->owner =THIS_MODULE;
tiny_tty_driver->driver_name = "ttyS";
tiny_tty_driver->name = "ttyS";
tiny_tty_driver->major = TTY_MAJOR;
tiny_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
tiny_tty_driver->subtype = SERIAL_TYPE_NORMAL;
tiny_tty_driver->flags = TTY_DRIVER_REAL_RAW;
tiny_tty_driver->init_termios = tty_std_termios;
tiny_tty_driver->init_termios.c_cflag = B9600 | CS8 | CREAD
|HUPCL|CLOCAL;
tty_set_operations(tiny_tty_driver, &serial_ops);
/*register the tty driver*/
retval=tty_register_driver(tiny_tty_driver);
if(retval)
{
printk(KERN_ERR "Failed to register tiny tty driver");
put_tty_driver(tiny_tty_driver);
return retval;
}
for(i=0; i< NB_TTY; ++i)
tty_register_device(tiny_tty_driver,i,NULL);
printk("<-Initialization of ttyS \n");
return retval;
}
module_init(tiny_tty_init);
but I have a kernel panic :
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Kernel panic - not syncing: Couldn't register /dev/tty0 driver
Can someone help me to trace the failure ?
Thanks
[-- Attachment #2: Type: text/html, Size: 2348 bytes --]
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Scott Wood @ 2008-08-27 15:01 UTC (permalink / raw)
To: Chris Skepper; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0808271413001.14220@chara.vm.bytemark.co.uk>
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
> Is that likely to be correct for SMC1? (I tried looking in the MPC8272
> reference manual, but couldn't find it.)
The value depends on how the port was set up by firmware (or by the
bootwrapper). It should be set to wherever the descriptor is, and there
should only be one descriptor that loops back on itself.
-Scott
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Brad Boyer @ 2008-08-27 16:08 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Kevin Diggs, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.64.0808271339230.22151@vixen.sonytel.be>
On Wed, Aug 27, 2008 at 01:40:10PM +0200, Geert Uytterhoeven wrote:
> On Wed, 27 Aug 2008, Arnd Bergmann wrote:
> > On Wednesday 27 August 2008, Kevin Diggs wrote:
> > > Arnd Bergmann wrote:
> > > > Are there even SMP boards based on a 750? I thought only 74xx
> > > > and 603/604 were SMP capable.
> > > >
> > > Not that I have heard of. I thought it was lacking some hardware that
> > > was needed to do SMP? Can the 603 do SMP?
> >
> > No, I was wrong about the 603. The machine I was thinking of is actually
> > 604e.
>
> The BeBox had a dual 603.
I remember going to a talk by some of the Be engineers, and I think they
said that the 603 had terrible SMP performance. My understanding was that
Motorola recommended the 604 for SMP configurations but the 603 was much
cheaper and mostly worked. The 750 is much more like the 603 than the 604.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Geert Uytterhoeven @ 2008-08-27 16:18 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev, Kevin Diggs, Arnd Bergmann
In-Reply-To: <20080827160859.GA2009@cynthia.pants.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1470 bytes --]
On Wed, 27 Aug 2008, Brad Boyer wrote:
> On Wed, Aug 27, 2008 at 01:40:10PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 27 Aug 2008, Arnd Bergmann wrote:
> > > On Wednesday 27 August 2008, Kevin Diggs wrote:
> > > > Arnd Bergmann wrote:
> > > > > Are there even SMP boards based on a 750? I thought only 74xx
> > > > > and 603/604 were SMP capable.
> > > > >
> > > > Not that I have heard of. I thought it was lacking some hardware that
> > > > was needed to do SMP? Can the 603 do SMP?
> > >
> > > No, I was wrong about the 603. The machine I was thinking of is actually
> > > 604e.
> >
> > The BeBox had a dual 603.
>
> I remember going to a talk by some of the Be engineers, and I think they
> said that the 603 had terrible SMP performance. My understanding was that
> Motorola recommended the 604 for SMP configurations but the 603 was much
> cheaper and mostly worked. The 750 is much more like the 603 than the 604.
Yes, the 603 was not designed for SMP boxes. But that didn't mean nobody had
the courage to (mis)use them that way ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: Kamalesh Babulal @ 2008-08-27 17:52 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Stephen Rothwell, LKML, linuxppc-dev, linux-next, mingo
In-Reply-To: <48B55B16.7060804@linux.intel.com>
Arjan van de Ven wrote:
> Kamalesh Babulal wrote:
>> Thanks for reference of the patch, After replacing the patch with the latest
>> one above on the powerpc, the warning still remains
>>
>> Badness at kernel/notifier.c:86
>
> sadly you have something going on that doesn't list the modules loaded etc...
>
> is this during boot or way later?
> (because if it's the later, you might be hitting a legitimate bug ;-)
>
>> NIP: c000000000081470 LR: c000000000081494 CTR: c00000000005a2d0
>> REGS: c0000021ce0bfaf0 TRAP: 0700 Not tainted (2.6.27-rc4-next-20080826-autotest)
>> MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24008042 XER: 00000005
>> TASK = c0000015de080000[1] 'swapper' THREAD: c0000021ce0bc000 CPU: 0
>> GPR00: c000000000081494 c0000021ce0bfd70 c00000000081e940 c000000000749c38
>> GPR04: 0000000000000003 0000000000000001 ffffffffffffffff c0000021ce0bfe90
>> GPR08: ffffffffffffffff ffffffffffffffff c0000000004fd9f0 c0000000004fd9f0
>> GPR12: 0000000024000042 c00000000089c300 0000000002307ef0 c0000000006332a0
>> GPR16: c000000000631f28 c000000000633388 00000000018bf8b0 0000000002700000
>> GPR20: c00000000070b07c c000000000707ef0 c000000000708160 c000000000631c58
>> GPR24: 0000000000000003 0000000000000001 c0000021ce0bfe90 0000000000000000
>> GPR28: ffffffffffffffff c000000000749c20 c0000000007bf338 c000000000749c38
>> NIP [c000000000081470] .notifier_call_chain+0x70/0x140
>> LR [c000000000081494] .notifier_call_chain+0x94/0x140
>> Call Trace:
>> [c0000021ce0bfd70] [c000000000081494] .notifier_call_chain+0x94/0x140 (unreliable)
>> [c0000021ce0bfe20] [c0000000004fe3fc] .cpu_up+0x10c/0x200
>> [c0000021ce0bfee0] [c0000000006cdcc0] .kernel_init+0x1b0/0x440
>> [c0000021ce0bff90] [c0000000000299cc] .kernel_thread+0x4c/0x68
>> Instruction dump:
>> e8630000 2fa30000 419e00f0 2fa60000 419e00e8 2e270000 7c7f1b78 3b600000
>> 48000028 60000000 60000000 60000000 <0fe00000> 2fbd0000 2f3c0000 7fbfeb78
>>
This is during the bootup
Welcome to yaboot version 1.3.12
Enter "help" to get some basic usage information
boot: autotest
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02700000, size: 846 Kbytes
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda6 console=hvc0 IDENT=1219851195
memory layout at init:
alloc_bottom : 00000000027d4000
alloc_top : 0000000008000000
alloc_top_hi : 0000000100000000
rmo_top : 0000000008000000
ram_top : 0000000100000000
Looking for displays
instantiating rtas at 0x00000000076a1000 ... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x00000000028d5000 -> 0x00000000028d637a
Device tree struct 0x00000000028d7000 -> 0x00000000028df000
Calling quiesce ...
returning from prom_init
Using pSeries machine description
Found initrd at 0xc000000002700000:0xc0000000027d3800
console [udbg0] enabled
Partition configured for 4 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #1 SMP Wed Aug 27 11:25:24 EDT 2008
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0x100000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Linux version 2.6.27-rc4-next-20080826-autotest (root@gekko-lp1.ltc.austin.ibm.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Wed Aug 27 11:25:24 EDT 2008
[boot]0012 Setup Arch
PCI host bridge /pci@800000020000002 ranges:
IO 0x000003fe00600000..0x000003fe006fffff -> 0x0000000000000000
MEM 0x0000040100000000..0x000004017fffffff -> 0x0000000080000000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0x00000000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00100000
[boot]0015 Setup Done
Built 1 zonelists in Node order, mobility grouping on. Total pages: 1034240
Policy zone: DMA
Kernel command line: root=/dev/sda6 console=hvc0 IDENT=1219851195
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
clocksource: timebase mult[10cd746] shift[22] registered
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 0
Memory: 4101404k/4194304k available (7536k kernel code, 92900k reserved, 1108k data, 604k bss, 300k init)
SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=16
Calibrating delay loop... 475.13 BogoMIPS (lpj=950272)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
------------[ cut here ]------------
Badness at kernel/notifier.c:86
NIP: c00000000050228c LR: c000000000502274 CTR: c000000000054ffc
REGS: c0000000fe06bb10 TRAP: 0700 Not tainted (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 44000082 XER: 00000004
TASK = c0000000fe060000[1] 'swapper' THREAD: c0000000fe068000 CPU: 0
GPR00: c000000000502274 c0000000fe06bd90 c000000000873748 c000000000791220
GPR04: 0000000000000003 0000000000000001 ffffffffffffffff c0000000fe06beb0
GPR08: c0000000005075cc c00000000077e0c8 c0000000005075cc c0000000fe068000
GPR12: c0000000008f8300 c0000000008f8300 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000230000 0000000000000000 00000000000d3800 4000000001c00000
GPR24: 0000000000000003 0000000000000001 c0000000fe06beb0 0000000000000000
GPR28: ffffffffffffffff c000000000791208 c00000000080bdc0 c000000000791220
NIP [c00000000050228c] .notifier_call_chain+0x8c/0x138
LR [c000000000502274] .notifier_call_chain+0x74/0x138
Call Trace:
[c0000000fe06bd90] [c000000000502274] .notifier_call_chain+0x74/0x138 (unreliable)
[c0000000fe06be40] [c000000000507ea0] .cpu_up+0xec/0x204
[c0000000fe06bf00] [c000000000711c58] .kernel_init+0x158/0x384
[c0000000fe06bf90] [c0000000000269a4] .kernel_thread+0x4c/0x68
Instruction dump:
7d2b0038 2c0b0000 418200a4 e87f0000 ebbf0008 4bb6eaf1 60000000 7f04c378
7f25cb78 2fa30000 7fe3fb78 409e0010 <0fe00000> 7fbfeb78 48000050 e93f0000
------------[ cut here ]------------
Badness at kernel/notifier.c:86
.
.
.
<snip Badness at kernel/notifier.c:86 9 times>
.
.
.
------------[ cut here ]------------
Badness at kernel/notifier.c:86
NIP: c00000000050228c LR: c000000000502274 CTR: 80000000001af404
REGS: c0000000fe06bb10 TRAP: 0700 Tainted: G W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 42000022 XER: 00000004
TASK = c0000000fe060000[1] 'swapper' THREAD: c0000000fe068000 CPU: 0
GPR00: c000000000502274 c0000000fe06bd90 c000000000873748 c000000000791220
GPR04: 0000000000000002 0000000000000001 ffffffffffffffff 0000000000000000
GPR08: c0000000005075cc c00000000077e0c8 c0000000005075cc c0000000fe068000
GPR12: 0000000000004000 c0000000008f8300 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000230000 <1>Unable to handle kernel paging request for data at address 0xffffffffffffffe8
Faulting instruction address: 0xc000000000077fa0
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000077fa0 LR: c000000000077f84 CTR: c000000000066110
REGS: c00000000fff7af0 TRAP: 0300 Tainted: G W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28000044 XER: 00000000
DAR: ffffffffffffffe8, DSISR: 0000000040010000
TASK = c0000000fe061160[0] 'swapper' THREAD: c0000000fe080000 CPU: 1
GPR00: c000000000077f84 c00000000fff7d70 c000000000873748 c0000000009b0b70
GPR04: 0000000000000018 0000000000000002 0000000000000000 c000000000759088
GPR08: c00000000088a380 0000000000000000 0000000000000056 c00000000088a380
GPR12: 0000000048000044 c0000000008f8500 0000000000000000 000000000796a428
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
GPR24: 0000000000000001 c0000000009b0c18 c0000000009b0b70 0000000000000000
GPR28: 0000000000000001 c00000000088a188 c00000000080c168 ffffffffffffffc0
NIP [c000000000077fa0] .run_hrtimer_pending+0x4c/0x1c0
LR [c000000000077f84] .run_hrtimer_pending+0x30/0x1c0
Call Trace:
[c00000000fff7d70] [c000000000077f84] .run_hrtimer_pending+0x30/0x1c0 (unreliable)
[c00000000fff7e20] [c00000000006614c] .run_timer_softirq+0x3c/0x288
[c00000000fff7ef0] [c00000000005f9b4] .__do_softirq+0xac/0x16c
[c00000000fff7f90] [c0000000000267e8] .call_do_softirq+0x14/0x24
[c0000000fe0839b0] [c00000000000cd58] .do_softirq+0x94/0x104
[c0000000fe083a50] [c00000000005fb84] .irq_exit+0x70/0xcc
[c0000000fe083ad0] [c00000000002352c] .timer_interrupt+0xe0/0x10c
[c0000000fe083b60] [c000000000003700] decrementer_common+0x100/0x180
--- Exception: 901 at .raw_local_irq_restore+0x3c/0x40
LR = .cpu_idle+0x12c/0x200
[c0000000fe083e50] [c000000000012fa8] .cpu_idle+0x120/0x200 (unreliable)
[c0000000fe083ed0] [c000000000509e34] .start_secondary+0x364/0x3a0
[c0000000fe083f90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
fbe1fff8 3b3a00a8 f8010010 f821ff51 48487a05 60000000 eb7a00a8 7fbbc800
419e012c 3bfbffc0 38a00002 38c00000 <e89f0028> 7fe3fb78 ebbf0020 4bfff925
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[c00000000fff7810] [c0000000000114b0] .show_stack+0x6c/0x194 (unreliable)
[c00000000fff78c0] [c000000000058994] .panic+0x74/0x1cc
[c00000000fff7950] [c000000000024a84] .die+0x248/0x28c
[c00000000fff7a00] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff7a80] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .run_hrtimer_pending+0x4c/0x1c0
LR = .run_hrtimer_pending+0x30/0x1c0
[c00000000fff7e20] [c00000000006614c] .run_timer_softirq+0x3c/0x288
[c00000000fff7ef0] [c00000000005f9b4] .__do_softirq+0xac/0x16c
[c00000000fff7f90] [c0000000000267e8] .call_do_softirq+0x14/0x24
[c0000000fe0839b0] [c00000000000cd58] .do_softirq+0x94/0x104
[c0000000fe083a50] [c00000000005fb84] .irq_exit+0x70/0xcc
[c0000000fe083ad0] [c00000000002352c] .timer_interrupt+0xe0/0x10c
[c0000000fe083b60] [c000000000003700] decrementer_common+0x100/0x180
--- Exception: 901 at .raw_local_irq_restore+0x3c/0x40
LR = .cpu_idle+0x12c/0x200
[c0000000fe083e50] [c000000000012fa8] .cpu_idle+0x120/0x200 (unreliable)
[c0000000fe083ed0] [c000000000509e34] .start_secondary+0x364/0x3a0
[c0000000fe083f90] [c000000000008364] .start_secondary_prolog+0xc/0x10
------------[ cut here ]------------
Badness at kernel/smp.c:290
NIP: c00000000008595c LR: c000000000085b3c CTR: 0000000000000000
REGS: c00000000fff7410 TRAP: 0700 Tainted: G D W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000021032 <ME,IR,DR> CR: 22000024 XER: 00000000
TASK = c0000000fe061160[0] 'swapper' THREAD: c0000000fe080000 CPU: 1
f2e10] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff2e90] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .kmem_cache_alloc+0x44/0xdc
LR = .smp_call_function_single+0xbc/0x118
[c00000000fff3180] [c000000000085960] .smp_call_function_mask+0x60/0x208 (unreliable)
[c00000000fff3220] [c00000000008587c] .smp_call_function_single+0xbc/0x118
[c00000000fff3310] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff3440] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff34c0] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff3540] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff35d0] [c000000000024a84] .die+0x248/0x28c
[c00000000fff3680] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff3700] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .kmem_cache_alloc+0x44/0xdc
LR = .smp_call_function_single+0xbc/0x118
[c00000000fff39f0] [c000000000085960] .smp_call_function_mask+0x60/0x208 (unreliable)
[c00000000fff3a90] [c00000000008587c] .smp_call_function_single+0xbc/0x118
[c00000000fff3b80] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff3cb0] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff3d30] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff3db0] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff3e40] [c000000000024a84] .die+0x248/0x28c
[c00000000fff3ef0] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff3f70] [c000000000005218] handle_page_fault+0x3c/0x5c
------------[ cut here ]------------
Badness at kernel/smp.c:290
NIP: c00000000008595c LR: c000000000085b3c CTR: 0000000000000000
REGS: c00000000fff2820 TRAP: 0700 Tainted: G D W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000021032 <ME,IR,DR> CR: 22000024 XER: 00000000
TASK = c0000000fe061160[0] 'swapper' THREAD: c0000000fe080000 CPU: 1
GPR00: 0000000000000001 c00000000fff2aa0 c000000000873748 0000000000000003
GPR04: 0000000000000000 c000000000828930 0000000000000000 0000000000000000
GPR08: c00000000fff4260 0000000000000000 0000000000000001 0000000000000001
GPR12: 0000000022000082 c0000000008f8500 0000000000000000 000000000796a428
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
GPR24: 0000000000000001 000000000000000b 0000000000000000 c000000000828930
GPR28: 0000000000000000 c0000000006626b0 c00000000080d0e8 0000000000000000
NIP [c00000000008595c] .smp_call_function_mask+0x5c/0x208
LR [c000000000085b3c] .smp_call_function+0x34/0x48
Call Trace:
[c00000000fff2aa0] [c000000000059cdc] .try_acquire_console_sem+0x1c/0x5c (unreliable)
[c00000000fff2bd0] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff2c50] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff2cd0] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff2d60] [c000000000024a84] .die+0x248/0x28c
[c00000000fff2e10] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff2e90] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .kmem_cache_alloc+0x44/0xdc
LR = .smp_call_function_single+0xbc/0x118
[c00000000fff3180] [c000000000085960] .smp_call_function_mask+0x60/0x208 (unreliable)
[c00000000fff3220] [c00000000008587c] .smp_call_function_single+0xbc/0x118
[c00000000fff3310] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff3440] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff34c0] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff3540] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff35d0] [c000000000024a84] .die+0x248/0x28c
[c00000000fff3680] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff3700] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .kmem_cache_alloc+0x44/0xdc
LR = .smp_call_function_single+0xbc/0x118
[c00000000fff39f0] [c000000000085960] .smp_call_function_mask+0x60/0x208 (unreliable)
[c00000000fff3a90] [c00000000008587c] .smp_call_function_single+0xbc/0x118
[c00000000fff3b80] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff3cb0] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff3d30] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff3db0] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff3e40] [c000000000024a84] .die+0x248/0x28c
[c00000000fff3ef0] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff3f70] [c000000000005218] handle_page_fault+0x3c/0x5c
Instruction dump:
7cfc3b78 f821fed1 60000000 60000000 e8010000 f8610160 f8810168 f82100e8
f80100e0 880d01da 21200000 7c090114 <0b000000> a14d000a e93e8040 38a100c0
------------[ cut here ]------------
Badness at kernel/smp.c:216
NIP: c00000000008580c LR: c000000000085a0c CTR: 0000000000000000
REGS: c00000000fff2730 TRAP: 0700 Tainted: G D W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000021032 <ME,IR,DR> CR: 42000028 XER: 00000000
TASK = c0000000fe061160[0] 'swapper' THREAD: c0000000fe080000 CPU: 1
GPR00: 0000000000000001 c00000000fff29b0 c000000000873748 0000000000000000
GPR04: c000000000828930 0000000000000000 0000000000000000 0000000000000000
GPR08: c00000000fff2c00 0000000000000001 0000000000000040 0000000000000000
GPR12: 0000000022000082 c0000000008f8500 0000000000000000 000000000796a428
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
GPR24: 0000000000000001 000000000000000b 0000000000000000 c000000000828930
GPR28: 0000000000000000 c000000000828930 c00000000080d0e8 0000000000000000
NIP [c00000000008580c] .smp_call_function_single+0x4c/0x118
LR [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
Call Trace:
[c00000000fff29b0] [c000000000934368] printk_buf+0x0/0x400 (unreliable)
[c00000000fff2aa0] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff2bd0] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff2c50] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff2cd0] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff2d60] [c000000000024a84] .die+0x248/0x28c
[c00000000fff2e10] [c00000000002c7b0] .bad_page_fault+0xb8/0xd4
[c00000000fff2e90] [c000000000005218] handle_page_fault+0x3c/0x5c
--- Exception: 300 at .kmem_cache_alloc+0x44/0xdc
LR = .smp_call_function_single+0xbc/0x118
[c00000000fff3180] [c000000000085960] .smp_call_function_mask+0x60/0x208 (unreliable)
[c00000000fff3220] [c00000000008587c] .smp_call_function_single+0xbc/0x118
[c00000000fff3310] [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
[c00000000fff3440] [c000000000085b3c] .smp_call_function+0x34/0x48
[c00000000fff34c0] [c000000000028848] .smp_send_stop+0x24/0x3c
[c00000000fff3540] [c0000000000589b4] .panic+0x94/0x1cc
[c00000000fff35d0] [c000000000024a84] .die+0x248000000000000001 0000000000000040 0000000000000000
GPR12: 0000000022000082 c0000000008f8500 0000000000000000 000000000796a428
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
GPR24: 0000000000000001 000000000000000b 0000000000000000 c000000000828930
GPR28: 0000000000000000 c000000000828930 c00000000080d0e8 0000000000000000
NIP [c00000000008580c] .smp_call_function_single+0x4c/0x118
LR [c000000000085a0c] .smp_call_function_mask+0x10c/0x208
Call Trace:
Instruction dump:
7c9d2378 f8010010 f821ff11 7cbc2b78 e8010000 f82100b8 f80100b0 60000000
a12d000a 880d01da 21600000 7c0b0114 <0b000000> 7f834800 409e0050 38000000
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000000e35b8
Oops: Kernel access of bad area, sig: 11 [#27]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c0000000000e35b8 LR: c00000000008587c CTR: 0000000000000000
REGS: c00000000ffe99e0 TRAP: 0300 Tainted: G D W (2.6.27-rc4-next-20080826-autotest)
MSR: 8000000000001032 <ME,IR,DR> CR: 42000022 XER: 00000000
DAR: 0000000000000000, DSISR: 0000000040000000
TASK = c0000000fe061160[0] 'swapper' THREAD: c0000000fe080000 CPU: 1
GPR00: c00000000008587c c00000000ffe9c60 c000000000873748 c0000000008ec630
GPR04: 0000000000000020 ffffffffffffffff c00000000008587c 0000000000000000
GPR08: c00000000ffe9f50 0000000000000000 0000000000000040 0000000000000000
GPR12: 0000000022000082 c0000000008f8500 0000000000000000 000000000796a428
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
GPR24: 0000000000000001 000000000000000b 0000000000000000 0000000000000020
GPR28: 0000000000000000 0000000000000000 c00000000080d0e8 0000000000000000
NIP [c0000000000e35b8] .kmem_cache_alloc+0x44/0xdc
LR [c00000000008587c] .smp_call_function_single+0xbc/0x118
Call Trace:
Instruction dump:
7c9b2378 f8010010 f821ff61 39200000 8bad01da 992d01da 7cc802a6 a12d000a
38a0ffff 79291f24 7d291a14 e9290188 <e8090000> 7d274b78 83890018 2fa00000
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
.
.
<snip>
The Badness at kernel/smp.c:290 and Badness at kernel/smp.c:216 goes on in an loop.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* How to access Freesale UPM NAND device
From: Laxmikant Rashinkar @ 2008-08-27 18:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
Hi,
quick question:
I have a custom board running MPC8347 on Linux 2.6.27 with Uboot 1.1.4.
I also have a NAND device (Micron MT29F2G08AACWP) connected to the LBC
and controlled via UPM.
fsl_elbc_nand.ko, fsl_upm.ko are loaded.
I'm wondering how to access the NAND device. Do I need mDOC? TrueFFS?
I have grep'd for the functions declared in fsl_upm.c and fsl_lbc.c and find that no other
code path calls these functions. So it looks like the drivers are loaded but no one calls into
them.
any help appreciated.
thanks
LK
[-- Attachment #2: Type: text/html, Size: 798 bytes --]
^ permalink raw reply
* Re: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B
From: roger blofeld @ 2008-08-27 19:07 UTC (permalink / raw)
To: Scott Wood; +Cc: Wolfram Sang, Arnd Bergmann, linuxppc-embedded
> From: Scott Wood <scottwood@freescale.com>
> To: roger blofeld <blofeldus@yahoo.com>
> Cc: Wolfram Sang <w.sang@pengutronix.de>; Arnd Bergmann <arnd@arndb.de>; linuxppc-embedded@ozlabs.org
> Sent: Monday, August 25, 2008 10:36:48 AM
> Subject: Re: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B
>
> roger blofeld wrote:
> > Hi
> > Since this bug is ATA specific, shouldn't this code be conditioned by
> CONFIG_IDE ?
>
> And then what happens if IDE is built as a module?
>
> -Scott
Good point. Still it seems unfortunate to slow everything down when only ATA requires the fix. I'll just continue to disable this code on my board which has no IDE.
Thanks
-rb
^ permalink raw reply
* Re: Efficient memcpy()/memmove() for G2/G3 cores...
From: Steven Munroe @ 2008-08-27 21:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, David Jander
In-Reply-To: <1219703291.13162.106.camel@pasglop>
On Tue, 2008-08-26 at 08:28 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-08-25 at 15:06 +0200, David Jander wrote:
> > Hi Matt,
> >
> > On Monday 25 August 2008 13:00:10 Matt Sealey wrote:
> > > The focus has definitely been on VMX but that's not to say lower power
> > > processors were forgotten :)
> >
> > lower-power (pun intended) is coming strong these days, as energy-efficiency
> > is getteing more important every day. And the MPC5121 is a brand-new embedded
> > processor, that will pop-up in quite a lot devices around you most
> > probably ;-)
>
> It would be useful of somebody interested in getting things things
> into glibc did the necessary FSF copyright assignment stuff and worked
> toward integrating them.
>
Ben makes a very good point!
There is a process for contributing code to GLIBC, which starts with an
FSF copyright assignment.
There is also a framework for adding and maintaining optimizations of
this type:
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
Since this original effort the powerpc changes have been merged into
mainline glibc (GLIBC-2.7) and no longer require a separate
(powerpc-cpu) addon. But the --with-cpu= configure option still works.
This mechanism also works with the glibc ports addon and eglibc.
So it does no good to complain here. If you have core you want to
contribute, Get your FSF CR assignment and join #glibc on freenode IRC.
And we will help you.
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Kevin Diggs @ 2008-08-27 21:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200808271334.16712.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 27 August 2008, Kevin Diggs wrote:
>
>>Arnd Bergmann wrote:
>
>
>>>Ok, thanks for the explanation. I now saw that you also
>>>use '_v' for variables (I guess). These should probably
>>>go the same way.
>>>
>>
>>Actually the _v means global variable. I would prefer to keep it.
>
>
> The reasoning on Linux is that you can tell from the declaration
> whether something is global or automatic. In fact, functions should
> be so short that you can always see all automatic declarations
> when you look at some code.
>
> If you use nonstandard variable naming, people will never stop
> asking you about that, so it's easier to just to the same as
> everyone else.
>
I will remove the "_v".
>
>>>Then at least for the first two, the common coding style would
>>>be to leave out the '= 0'. For minmaxmode, the most expressive
>>>way would be to define an enum, like
>>>
>>>enum {
>>> MODE_NORMAL,
>>> MODE_MINMAX,
>>>};
>>>
>>>int minmaxmode = MODE_NORMAL;
>>>
>>
>>Since this is a boolean parameter I don't know? What if I change the
>>name to enable_minmax. And actually use the "bool" module parameter
>>type?
>
>
> Module parameter names should be short, so just "minmax" would
> be a good name, but better put the module_param() line right
> after that. If it's a bool type, I would just leave out the
> initialization.
>
Ok. But leaving out the initialization will make me itch. Should I
also replace "override_min_core" with "mincore" (or "min_core")? And
"override_max_core" with "maxcore" (or "max_core")?
Leaving out the initializations makes me ... uneasy. It's ok to leave
them out if they are 0?
>
>>>>..._min_max_mode is a boolean to hold the state of
>>>>minmaxmode. Seems to be only used to print the current
>>>>value.
>>>
>>>
>>>this looks like a duplicate then. why would you need both?
>>>It seems really confusing to have both a cpufreq attribute
>>>and a module attribute with the same name, writing to
>>>different variables.
>>>
>>
>>I probably don't need both? I kinda treat the variables tied to module
>>parameters as read only.
>
>
> But you have marked as read/write in the module_param line.
>
> I would prefer to just have the module parameter and have
> a tool to modify that one.
>
> If a module parameter only makes sense as read-only, you
> should mark it as 0444 instead of 0644, but this one looks
> like it can be writable.
>
I meant I treat them as read only from the code. That is why I have a
separate variable to change from the sysfs routines. I'll eliminate it
if you like. I have removed the auto added sysfs attributes.
>
>>>The completion would certainly be better than the sleep here, but
>>>I think you shouldn't need that in the first place. AFAICT, you
>>>have three different kinds of events that you need to protect
>>>against, when some other code can call into your module:
>>>
>>>1. timer function,
>>>2. cpufreq notifier, and
>>>3. sysfs attribute.
>>>
>>>In each case, the problem is a race between two threads that you
>>>need to close. In case of the timer, you need to call del_timer_sync
>>>because the timers already have this method builtin. For the other
>>>two, you already unregister the interfaces, which ought to be enough.
>>>
>>
>>The choice I made here was to wait for the timer to fire rather than
>>to delete it. I think it is easier to just wait for it than to delete
>>it and try to get things back in order. Though since this is in a
>>module exit routine it probably does not matter. Also I would have to
>>check whether there was an analogous HRTimer call and call the right
>>one.
>
>
> I think the module_exit() function should leave the frequency in a
> well-defined state, so the easiest way to get there is probably
> to delete the timer, and then manually set the frequency.
>
I really don't follow you here? If I let the timer fire then the cpu
(and the cpufreq sub-system) will be left in a well-defined state. I
don't understand why you want me to delete the timer and then
basically do manually what it was going to do anyway. There are two
calls to cpufreq_notify_transition(). One just before the modify_PLL()
call, with CPUFREQ_PRECHANGE as an argument, and one in the
pll_switch_cb() routine, with CPUFREQ_POSTCHANGE as an argument. I
would need to make sure that these are matched up.
Even without the HRTimer stuff being used the timer fires in less than
4 ms (@ 250 HZ). So I can't see the user actually trying to interrupt
a frequency change. With HRTimers it is 100 us.
Can we please, please leave this part as is?
>
> Arnd <><
>
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Kevin Diggs @ 2008-08-27 21:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200808271334.16712.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 27 August 2008, Kevin Diggs wrote:
>
>>Arnd Bergmann wrote:
>
>
>>>Ok, thanks for the explanation. I now saw that you also
>>>use '_v' for variables (I guess). These should probably
>>>go the same way.
>>>
>>
>>Actually the _v means global variable. I would prefer to keep it.
>
>
> The reasoning on Linux is that you can tell from the declaration
> whether something is global or automatic. In fact, functions should
> be so short that you can always see all automatic declarations
> when you look at some code.
>
> If you use nonstandard variable naming, people will never stop
> asking you about that, so it's easier to just to the same as
> everyone else.
>
>
>>>Then at least for the first two, the common coding style would
>>>be to leave out the '= 0'. For minmaxmode, the most expressive
>>>way would be to define an enum, like
>>>
>>>enum {
>>> MODE_NORMAL,
>>> MODE_MINMAX,
>>>};
>>>
>>>int minmaxmode = MODE_NORMAL;
>>>
>>
>>Since this is a boolean parameter I don't know? What if I change the
>>name to enable_minmax. And actually use the "bool" module parameter
>>type?
>
>
> Module parameter names should be short, so just "minmax" would
> be a good name, but better put the module_param() line right
> after that. If it's a bool type, I would just leave out the
> initialization.
>
>
>>>>..._min_max_mode is a boolean to hold the state of
>>>>minmaxmode. Seems to be only used to print the current
>>>>value.
>>>
>>>
>>>this looks like a duplicate then. why would you need both?
>>>It seems really confusing to have both a cpufreq attribute
>>>and a module attribute with the same name, writing to
>>>different variables.
>>>
>>
>>I probably don't need both? I kinda treat the variables tied to module
>>parameters as read only.
>
>
> But you have marked as read/write in the module_param line.
>
> I would prefer to just have the module parameter and have
> a tool to modify that one.
>
> If a module parameter only makes sense as read-only, you
> should mark it as 0444 instead of 0644, but this one looks
> like it can be writable.
>
>
>>>Are there even SMP boards based on a 750? I thought only 74xx
>>>and 603/604 were SMP capable.
>>>
>>
>>Not that I have heard of. I thought it was lacking some hardware that
>>was needed to do SMP? Can the 603 do SMP?
>
>
> No, I was wrong about the 603. The machine I was thinking of is actually
> 604e.
>
>
>>>The completion would certainly be better than the sleep here, but
>>>I think you shouldn't need that in the first place. AFAICT, you
>>>have three different kinds of events that you need to protect
>>>against, when some other code can call into your module:
>>>
>>>1. timer function,
>>>2. cpufreq notifier, and
>>>3. sysfs attribute.
>>>
>>>In each case, the problem is a race between two threads that you
>>>need to close. In case of the timer, you need to call del_timer_sync
>>>because the timers already have this method builtin. For the other
>>>two, you already unregister the interfaces, which ought to be enough.
>>>
>>
>>The choice I made here was to wait for the timer to fire rather than
>>to delete it. I think it is easier to just wait for it than to delete
>>it and try to get things back in order. Though since this is in a
>>module exit routine it probably does not matter. Also I would have to
>>check whether there was an analogous HRTimer call and call the right
>>one.
>
>
> I think the module_exit() function should leave the frequency in a
> well-defined state, so the easiest way to get there is probably
> to delete the timer, and then manually set the frequency.
>
> Arnd <><
>
>
^ 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