* Re: [git pull] Please pull powerpc.git master branch
From: Kumar Gala @ 2008-05-02 6:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <18458.44292.817770.800636@cargo.ozlabs.ibm.com>
Paul,
Any plans to start applying some patches to powerpc-next (for .27)?
For example, your NAP patch? the devres_ioremap_prot patch.
- k
^ permalink raw reply
* Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
From: David Gibson @ 2008-05-02 5:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <18458.39064.783013.268948@cargo.ozlabs.ibm.com>
On Fri, May 02, 2008 at 02:29:12PM +1000, Paul Mackerras wrote:
> This fixes a regression reported by Kamalesh Bulabel where a POWER4
> machine would crash because of an SLB miss at a point where the SLB
> miss exception was unrecoverable. This regression is tracked at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=10082
>
> SLB misses at such points shouldn't happen because the kernel stack is
> the only memory accessed other than things in the first segment of the
> linear mapping (which is mapped at all times by entry 0 of the SLB).
> The context switch code ensures that SLB entry 2 covers the kernel
> stack, if it is not already covered by entry 0. None of entries 0
> to 2 are ever replaced by the SLB miss handler.
>
> Where this went wrong is that the context switch code assumes it
> doesn't have to write to SLB entry 2 if the new kernel stack is in the
> same segment as the old kernel stack, since entry 2 should already be
> correct. However, when we start up a secondary cpu, it calls
> slb_initialize, which doesn't set up entry 2. This is correct for
> the boot cpu, where we will be using a stack in the kernel BSS at this
> point (i.e. init_thread_union), but not necessarily for secondary
> cpus, whose initial stack can be allocated anywhere. This doesn't
> cause any immediate problem since the SLB miss handler will just
> create an SLB entry somewhere else to cover the initial stack.
>
> In fact it's possible for the cpu to go quite a long time without SLB
> entry 2 being valid. Eventually, though, the entry created by the SLB
> miss handler will get overwritten by some other entry, and if the next
> access to the stack is at an unrecoverable point, we get the crash.
>
> This fixes the problem by making slb_initialize create a suitable
> entry for the kernel stack, if we are on a secondary cpu and the stack
> isn't covered by SLB entry 0. This requires initializing the
> get_paca()->kstack field earlier, so I do that in smp_create_idle
> where the current field is initialized. This also abstracts a bit of
> the computation that mk_esid_data in slb.c does so that it can be used
> in slb_initialize.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Michael Ellerman pointed out that I should be comparing
> raw_smp_processor_id() with boot_cpuid rather than with 0.
Do you even need the processor ID test at all? The boot processor
should always have its stack covered by SLB entry 0 when we come
through here, shouldn't it?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [git pull] Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-05-02 5:56 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
With the exception of one commit from Grant Likely, these are all
fixes for various bugs and compile problems, or documentation
updates. The one from Grant is something that has been around for a
month or so and only affects MPC5200-based embedded platforms.
Thanks,
Paul.
.../powerpc/mpc52xx-device-tree-bindings.txt | 11 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 23 +++
arch/powerpc/configs/ps3_defconfig | 132 +++++++++++++-------
arch/powerpc/kernel/smp.c | 2
arch/powerpc/mm/slb.c | 27 ++--
arch/powerpc/platforms/ps3/interrupt.c | 6 -
arch/powerpc/sysdev/fsl_rio.c | 9 +
arch/powerpc/sysdev/fsl_soc.c | 4 -
arch/powerpc/sysdev/xilinx_intc.c | 2
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 6 -
drivers/net/fec_mpc52xx.c | 97 +++++++++++----
drivers/net/fec_mpc52xx.h | 19 ---
drivers/ps3/ps3-lpm.c | 1
drivers/ps3/ps3-sys-manager.c | 7 -
drivers/serial/mpc52xx_uart.c | 2
include/asm-powerpc/ps3.h | 3
include/linux/rio.h | 2
17 files changed, 231 insertions(+), 122 deletions(-)
Andrew Liu (1):
Fix a potential issue in mpc52xx uart driver
Anton Vorontsov (1):
[POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot
Becky Bruce (1):
[POWERPC] Squash build warning for print of resource_size_t in fsl_soc.c
FUJITA Tomonori (1):
[POWERPC] PS3: Add time include to lpm
Geert Uytterhoeven (1):
[POWERPC] PS3: Make ps3_virq_setup and ps3_virq_destroy static
Geoff Levand (3):
[POWERPC] Fix slb.c compile warnings
[POWERPC] PS3: Remove unsupported wakeup sources
[POWERPC] PS3: Update ps3_defconfig
Grant Likely (1):
[POWERPC] mpc5200: Allow for fixed speed MII configurations
Jason Jin (1):
[POWERPC] 86xx: Fix the wrong serial1 interrupt for 8610 board
Kumar Gala (1):
[POWERPC] Xilinx: Fix compile warnings
Paul Mackerras (1):
[POWERPC] Bolt in SLB entry for kernel stack on secondary cpus
Randy Dunlap (1):
[RAPIDIO] fix current kernel-doc notation
^ permalink raw reply
* [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
From: Paul Mackerras @ 2008-05-02 4:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
This fixes a regression reported by Kamalesh Bulabel where a POWER4
machine would crash because of an SLB miss at a point where the SLB
miss exception was unrecoverable. This regression is tracked at:
http://bugzilla.kernel.org/show_bug.cgi?id=10082
SLB misses at such points shouldn't happen because the kernel stack is
the only memory accessed other than things in the first segment of the
linear mapping (which is mapped at all times by entry 0 of the SLB).
The context switch code ensures that SLB entry 2 covers the kernel
stack, if it is not already covered by entry 0. None of entries 0
to 2 are ever replaced by the SLB miss handler.
Where this went wrong is that the context switch code assumes it
doesn't have to write to SLB entry 2 if the new kernel stack is in the
same segment as the old kernel stack, since entry 2 should already be
correct. However, when we start up a secondary cpu, it calls
slb_initialize, which doesn't set up entry 2. This is correct for
the boot cpu, where we will be using a stack in the kernel BSS at this
point (i.e. init_thread_union), but not necessarily for secondary
cpus, whose initial stack can be allocated anywhere. This doesn't
cause any immediate problem since the SLB miss handler will just
create an SLB entry somewhere else to cover the initial stack.
In fact it's possible for the cpu to go quite a long time without SLB
entry 2 being valid. Eventually, though, the entry created by the SLB
miss handler will get overwritten by some other entry, and if the next
access to the stack is at an unrecoverable point, we get the crash.
This fixes the problem by making slb_initialize create a suitable
entry for the kernel stack, if we are on a secondary cpu and the stack
isn't covered by SLB entry 0. This requires initializing the
get_paca()->kstack field earlier, so I do that in smp_create_idle
where the current field is initialized. This also abstracts a bit of
the computation that mk_esid_data in slb.c does so that it can be used
in slb_initialize.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Michael Ellerman pointed out that I should be comparing
raw_smp_processor_id() with boot_cpuid rather than with 0.
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index be35ffa..1457aa0 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -386,6 +386,8 @@ static void __init smp_create_idle(unsigned int cpu)
panic("failed fork for CPU %u: %li", cpu, PTR_ERR(p));
#ifdef CONFIG_PPC64
paca[cpu].__current = p;
+ paca[cpu].kstack = (unsigned long) task_thread_info(p)
+ + THREAD_SIZE - STACK_FRAME_OVERHEAD;
#endif
current_set[cpu] = task_thread_info(p);
task_thread_info(p)->cpu = cpu;
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 906daed..b2c43d0 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -44,13 +44,13 @@ static void slb_allocate(unsigned long ea)
slb_allocate_realmode(ea);
}
+#define slb_esid_mask(ssize) \
+ (((ssize) == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T)
+
static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
unsigned long slot)
{
- unsigned long mask;
-
- mask = (ssize == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T;
- return (ea & mask) | SLB_ESID_V | slot;
+ return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
}
#define slb_vsid_shift(ssize) \
@@ -301,11 +301,16 @@ void slb_initialize(void)
create_shadowed_slbe(VMALLOC_START, mmu_kernel_ssize, vflags, 1);
+ /* For the boot cpu, we're running on the stack in init_thread_union,
+ * which is in the first segment of the linear mapping, and also
+ * get_paca()->kstack hasn't been initialized yet.
+ * For secondary cpus, we need to bolt the kernel stack entry now.
+ */
slb_shadow_clear(2);
+ if (raw_smp_processor_id() != boot_cpuid &&
+ (get_paca()->kstack & slb_esid_mask(mmu_kernel_ssize)) > PAGE_OFFSET)
+ create_shadowed_slbe(get_paca()->kstack,
+ mmu_kernel_ssize, lflags, 2);
- /* We don't bolt the stack for the time being - we're in boot,
- * so the stack is in the bolted segment. By the time it goes
- * elsewhere, we'll call _switch() which will bolt in the new
- * one. */
asm volatile("isync":::"memory");
}
^ permalink raw reply related
* Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-05-02 4:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next
I dropped '[POWERPC] Set lower flag bits..' patch and will get it in for
the next release.
-k
to receive the following updates:
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 23 ++++++++++++++++++++++-
arch/powerpc/sysdev/fsl_rio.c | 9 +++++++--
arch/powerpc/sysdev/fsl_soc.c | 4 ++--
arch/powerpc/sysdev/xilinx_intc.c | 2 +-
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 6 +++---
include/linux/rio.h | 2 ++
6 files changed, 37 insertions(+), 9 deletions(-)
Anton Vorontsov (1):
[POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot
Becky Bruce (1):
[POWERPC] Squash build warning for print of resource_size_t in fsl_soc.c
Jason Jin (1):
[POWERPC] 86xx: Fix the wrong serial1 interrupt for 8610 board
Kumar Gala (1):
[POWERPC] Xilinx: Fix compile warnings
Randy Dunlap (1):
[RAPIDIO] fix current kernel-doc notation
^ permalink raw reply
* Re: [PATCH] Squash build warning for print of resource_size_t in fsl_soc.c
From: Kumar Gala @ 2008-05-02 4:06 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0805011814110.8816@monty.am.freescale.net>
On May 1, 2008, at 6:15 PM, Becky Bruce wrote:
>
> When resource_size_t is larger than an int, the current code
> generates a build warning. Kill it.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
From: Kumar Gala @ 2008-05-02 4:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18458.21372.757211.450855@cargo.ozlabs.ibm.com>
On May 1, 2008, at 6:34 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> ok. Was just wondering how the async exception know that the signal
>> it wanted to send belonged to the particular process that is running.
>
> Usually the driver would have a reference to the task_struct of the
> task that should get the signal, and it would send the signal to that
> task, rather than the current task. That task could be the current
> task, of course, but it might not be.
>
> I can't think of a case where an asynchronous interrupt would always
> result in a signal being sent to the current task.
>
>>>> how do we provide someone stick a kprobe on such code today?
>>>
>>> -ENOPARSE
>>
>> I was asking how we prevent the cases you were describing working w/
>> kprobes today. Since it ends up single stepping in kernel codes its
>> possible that someone sets a kprobe in code that shouldn't be
>> interrupted, yet we'd cause a SingleStep Exception.
>
> I'd have to look more closely at the kprobes code to answer that in
> detail. I assume the kprobes exception handlers are sufficiently
> careful about what they do because they are aware they could have
> interrupted interrupt-disabled code.
Can you be a bit more specific about what we have to be careful about?
Also, how does this work in a hypervisor world that has no idea about
when it might interrupt a guest.
>>>> So I'm not if there is any good way to preclude the handlers
>>>> associated with these exceptions from doing the things you listed.
>>>
>>> In that case, you'd better expect to see system freezes, memory
>>> corruption and general instability.
>>
>> So the case I'm trying to make work is debug and kprobes. This case
>> seems like we have pretty good control over what the "handler" does.
>> Are there checks we can add to BUG_ON() so we are at least aware of
>> the code attempts to do something it shouldnt?
>
> Well, there's in_interrupt(), and there's the __kprobes marking, which
> is used to mark functions where kprobes must not put a breakpoint.
> Apart from that I would need to read through the kprobes code to
> comment further...
I would appreciate a review here to make sure we are ok. I'm assuming
if the current code is already safe that calling into it from a
separate exception stack isn't going to make any difference.
- k
^ permalink raw reply
* Re: how to check for "optional" ppc chip features (MSR_BE)
From: Kumar Gala @ 2008-05-02 3:48 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080502012118.96ED926FA07@magilla.localdomain>
On May 1, 2008, at 8:21 PM, Roland McGrath wrote:
> I've been looking at PowerISA_Public.pdf that I downloaded from some
> ppc
> site. It describes various things as "need not be supported on all
> implementations", for example the MSR_BE bit. Is there a generic
> way to
> detect if such a feature is supported, or a known table of models that
> support features, or what?
>
> Right now I'm considering MSR_BE (branch tracing). I have a patch
> to use
> this (arch_has_block_step, enabling a PTRACE_SINGLEBLOCK). The only
> machine handy to test is a Mac G5 (PPC970FX, 3.0 (pvr 003c 0300)).
> I know
> this chip supports MSR_BE. But that's only because I wrote an
> affirmative
> test case and tried it and saw it work right.
Look at arch/powerpc/kernel/cputable.c to see how we handle issues
like this.
> Before submitting the kernel changes, I want to get the CPU model
> conditionalization correct (a runtime check on some feature bit mask
> is
> fine here, if CONFIG_* alone does not indicate for sure).
I believe all PPC that implement MSR[SE] also support MSR[BE]. The
"Book-E" class PPCs have a different mechanism to single branch
completion (these are embedded PPC products).
I've been working on changes related to the Book-E class machines and
would be happy to try and port what you're looking over.
- k
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] Move device_to_mask() to dma-mapping.h
From: Mark Nelson @ 2008-05-02 1:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <b016a9cc9ea0ae22204dc6cbd583af7a@kernel.crashing.org>
On Fri, 2 May 2008 10:32:35 am Segher Boessenkool wrote:
> > I'm not sure exactly what you mean - it was inline before the move.
>
> Heh, I missed that.
>
> > But if everybody thinks it would be better to leave it in dma_64.c and
> > just
> > expose it for use outside, I'm fine with that.
>
> That's what I meant, yes.
Thought so. How's this:
---
arch/powerpc/kernel/dma_64.c | 2 +-
include/asm-powerpc/dma-mapping.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
Index: upstream/arch/powerpc/kernel/dma_64.c
===================================================================
--- upstream.orig/arch/powerpc/kernel/dma_64.c
+++ upstream/arch/powerpc/kernel/dma_64.c
@@ -15,7 +15,7 @@
* Generic iommu implementation
*/
-static inline unsigned long device_to_mask(struct device *dev)
+unsigned long device_to_mask(struct device *dev)
{
if (dev->dma_mask && *dev->dma_mask)
return *dev->dma_mask;
Index: upstream/include/asm-powerpc/dma-mapping.h
===================================================================
--- upstream.orig/include/asm-powerpc/dma-mapping.h
+++ upstream/include/asm-powerpc/dma-mapping.h
@@ -45,6 +45,9 @@ extern void __dma_sync_page(struct page
#endif /* ! CONFIG_NOT_COHERENT_CACHE */
#ifdef CONFIG_PPC64
+
+extern unsigned long device_to_mask(struct device *dev);
+
/*
* DMA operations are abstracted for G5 vs. i/pSeries, PCI vs. VIO
*/
Thanks!
Mark.
>
>
> Segher
>
^ permalink raw reply
* how to check for "optional" ppc chip features (MSR_BE)
From: Roland McGrath @ 2008-05-02 1:21 UTC (permalink / raw)
To: linuxppc-dev
I've been looking at PowerISA_Public.pdf that I downloaded from some ppc
site. It describes various things as "need not be supported on all
implementations", for example the MSR_BE bit. Is there a generic way to
detect if such a feature is supported, or a known table of models that
support features, or what?
Right now I'm considering MSR_BE (branch tracing). I have a patch to use
this (arch_has_block_step, enabling a PTRACE_SINGLEBLOCK). The only
machine handy to test is a Mac G5 (PPC970FX, 3.0 (pvr 003c 0300)). I know
this chip supports MSR_BE. But that's only because I wrote an affirmative
test case and tried it and saw it work right.
Before submitting the kernel changes, I want to get the CPU model
conditionalization correct (a runtime check on some feature bit mask is
fine here, if CONFIG_* alone does not indicate for sure).
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] Move device_to_mask() to dma-mapping.h
From: Segher Boessenkool @ 2008-05-02 0:32 UTC (permalink / raw)
To: Mark Nelson; +Cc: linuxppc-dev, paulus
In-Reply-To: <200805020947.47176.markn@au1.ibm.com>
> I'm not sure exactly what you mean - it was inline before the move.
Heh, I missed that.
> But if everybody thinks it would be better to leave it in dma_64.c and
> just
> expose it for use outside, I'm fine with that.
That's what I meant, yes.
Segher
^ permalink raw reply
* Re: overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands
From: Roland McGrath @ 2008-05-01 23:55 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, Anton Blanchard,
Paralkar Anmol
In-Reply-To: <30110DA2-3887-4679-9073-CC69A267E9DC@kernel.crashing.org>
For the short answer, no, I'd like not to extend PTRACE_SET_DEBUGREG in
the simple fashion. The direction I want to move with this is away from
providing the hardware register formats directly as the user ABI.
What I mean is resurrecting, finishing, and porting the "hw_breakpoint"
work that Alan Stern <stern@rowland.harvard.edu> started, but which was
never finished or merged. This is an in-kernel interface handling the
hardware details and multiplexing in-kernel and user uses, with a
higher-level API that is mostly machine-independent. The idea is that
future user-level extensions for watchpoint-like features would be based
on that, not on exposing hardware features directly as such.
I think someone at IBM told me they were going to look at picking that
work up, but I'll have to remember who and track them down.
> Also, what functionality can GDB take advantage of today? Does it
> comprehend the idea of breakpoints or watchpoints that cover a range?
I'm not the expert on that, but probably the answer is "sort of".
The low-level feature on s390 is range-based, and it supports that.
The hook for machine support uses "addr+len", though on most machines
len has to be 8 or has to be {1,2,4,8} and addr has to be aligned to len.
I'm not sure that high-level watchpoints ever translate into big ranges
in practice.
Understanding the details of all the hardware features in the powerpc
variants would inform ironing out the hw_breakpoint interface details.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] Move device_to_mask() to dma-mapping.h
From: Mark Nelson @ 2008-05-01 23:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <742b5895cdf9b898ec2b4834926a41ac@kernel.crashing.org>
On Thu, 1 May 2008 07:04:30 pm Segher Boessenkool wrote:
> > Move device_to_mask() to dma-mapping.h because we need to use it from
> > outside dma_64.c in a later patch.
>
> Why does this need to become an inline function?
>
>
> Segher
>
I'm not sure exactly what you mean - it was inline before the move.
But, I honestly didn't think about it too much (although I possibly should
have)... I figured that it was static inline before my patch so I should leave
it as such.
But if everybody thinks it would be better to leave it in dma_64.c and just
expose it for use outside, I'm fine with that.
Thanks!
Mark.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
From: Paul Mackerras @ 2008-05-01 23:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2DF41779-732B-4477-9DAC-147CDC5C9885@kernel.crashing.org>
Kumar Gala writes:
> ok. Was just wondering how the async exception know that the signal
> it wanted to send belonged to the particular process that is running.
Usually the driver would have a reference to the task_struct of the
task that should get the signal, and it would send the signal to that
task, rather than the current task. That task could be the current
task, of course, but it might not be.
I can't think of a case where an asynchronous interrupt would always
result in a signal being sent to the current task.
> >> how do we provide someone stick a kprobe on such code today?
> >
> > -ENOPARSE
>
> I was asking how we prevent the cases you were describing working w/
> kprobes today. Since it ends up single stepping in kernel codes its
> possible that someone sets a kprobe in code that shouldn't be
> interrupted, yet we'd cause a SingleStep Exception.
I'd have to look more closely at the kprobes code to answer that in
detail. I assume the kprobes exception handlers are sufficiently
careful about what they do because they are aware they could have
interrupted interrupt-disabled code.
> >> So I'm not if there is any good way to preclude the handlers
> >> associated with these exceptions from doing the things you listed.
> >
> > In that case, you'd better expect to see system freezes, memory
> > corruption and general instability.
>
> So the case I'm trying to make work is debug and kprobes. This case
> seems like we have pretty good control over what the "handler" does.
> Are there checks we can add to BUG_ON() so we are at least aware of
> the code attempts to do something it shouldnt?
Well, there's in_interrupt(), and there's the __kprobes marking, which
is used to mark functions where kprobes must not put a breakpoint.
Apart from that I would need to read through the kprobes code to
comment further...
Paul.
^ permalink raw reply
* [PATCH] Squash build warning for print of resource_size_t in fsl_soc.c
From: Becky Bruce @ 2008-05-01 23:15 UTC (permalink / raw)
To: linuxppc-dev
When resource_size_t is larger than an int, the current code
generates a build warning. Kill it.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/sysdev/fsl_soc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 7b45670..b594087 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -389,8 +389,8 @@ static int __init gfar_of_init(void)
}
gfar_data.phy_id = *id;
- snprintf(gfar_data.bus_id, MII_BUS_ID_SIZE, "%x",
- res.start);
+ snprintf(gfar_data.bus_id, MII_BUS_ID_SIZE, "%llx",
+ (unsigned long long)res.start);
of_node_put(phy);
of_node_put(mdio);
--
1.5.4.1
^ permalink raw reply related
* Re: powerpc boot regression
From: Tony Breeds @ 2008-05-01 23:07 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linux-kernel, LinuxPPC-dev, y-goto, akpm, David Miller
In-Reply-To: <1209653507.27240.7.camel@badari-desktop>
On Thu, May 01, 2008 at 07:51:47AM -0700, Badari Pulavarty wrote:
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
Yes. I'm just using ppc64_defconfig.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Benjamin Herrenschmidt @ 2008-05-01 22:39 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev list
In-Reply-To: <481A3A50.3060101@am.sony.com>
On Thu, 2008-05-01 at 14:46 -0700, Geoff Levand wrote:
>
> It doesn't seem to cause problems on PS3, and I added it into
> ps3-linux.git
> as other/powerpc-vmemmap-variable-page-size.diff, but I couldn't get
> it to
> fail without the patch...
>
> Could you send me your kernel .config?
ps3_defconfig with added vmmemap (which is disabled by default).
Ben.
^ permalink raw reply
* Re: [PATCH] Watchdog on MPC85xx SMP system
From: Andrew Morton @ 2008-05-01 21:51 UTC (permalink / raw)
To: Chen Gong; +Cc: linuxppc-dev, wim, g.chen, linux-kernel
In-Reply-To: <1209458525-8041-2-git-send-email-g.chen@freescale.com>
On Tue, 29 Apr 2008 16:42:05 +0800
Chen Gong <g.chen@freescale.com> wrote:
> On Book-E SMP systems each core has its own private watchdog.
> If only one watchdog is enabled, when the core that doesn't
> enable the watchdog is hung, system can't reset because no
> watchdog is running on it. That's bad. It means we must
> enable watchdogs on both cores.
>
> We can use smp_call_function() to send appropriate messages to
> all the other cores to enable and update the watchdog.
>
> Signed-off-by: Chen Gong <g.chen@freescale.com>
> ---
> Now Tested on MPC8572DS platform.
>
> drivers/watchdog/booke_wdt.c | 31 +++++++++++++++++++++++--------
> 1 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
> index d362f5b..8a4e7f0 100644
> --- a/drivers/watchdog/booke_wdt.c
> +++ b/drivers/watchdog/booke_wdt.c
> @@ -1,12 +1,12 @@
> /*
> - * drivers/char/watchdog/booke_wdt.c
> + * drivers/watchdog/booke_wdt.c
> *
> * Watchdog timer for PowerPC Book-E systems
> *
> * Author: Matthew McClintock
> * Maintainer: Kumar Gala <galak@kernel.crashing.org>
> *
> - * Copyright 2005 Freescale Semiconductor Inc.
> + * Copyright 2005, 2008 Freescale Semiconductor Inc.
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> @@ -16,6 +16,7 @@
>
> #include <linux/module.h>
> #include <linux/fs.h>
> +#include <linux/smp.h>
> #include <linux/miscdevice.h>
> #include <linux/notifier.h>
> #include <linux/watchdog.h>
> @@ -47,23 +48,31 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
> #define WDTP(x) (TCR_WP(x))
> #endif
>
> +static DEFINE_SPINLOCK(booke_wdt_lock);
> +
> +static void __booke_wdt_ping(void *data)
> +{
> + mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
> +}
> +
> /*
> * booke_wdt_ping:
> */
> static __inline__ void booke_wdt_ping(void)
> {
> - mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
> + smp_call_function(__booke_wdt_ping, NULL, 0, 0);
> + __booke_wdt_ping(NULL);
> }
>
> /*
> - * booke_wdt_enable:
> + * __booke_wdt_enable:
> */
> -static __inline__ void booke_wdt_enable(void)
> +static inline void __booke_wdt_enable(void *data)
> {
> u32 val;
>
> /* clear status before enabling watchdog */
> - booke_wdt_ping();
> + __booke_wdt_ping(NULL);
> val = mfspr(SPRN_TCR);
> val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(booke_wdt_period));
>
> @@ -137,12 +146,15 @@ static int booke_wdt_ioctl (struct inode *inode, struct file *file,
> */
> static int booke_wdt_open (struct inode *inode, struct file *file)
> {
> + spin_lock(&booke_wdt_lock);
> if (booke_wdt_enabled == 0) {
> booke_wdt_enabled = 1;
> - booke_wdt_enable();
> + __booke_wdt_enable(NULL);
> + smp_call_function(__booke_wdt_enable, NULL, 0, 0);
It's nonsensical to call an inlined function via smp_call_function(). What
we're asking the compiler to do here is to generate both an out-of-line
copy and an inlined copy.
Also, the above is an open-coded version of on_each_cpu().
so... something like the below should tidy that up, along with numerous
other things. Can you please check it over?
diff -puN drivers/watchdog/booke_wdt.c~watchdog-fix-booke_wdtc-on-mpc85xx-smp-system-fix drivers/watchdog/booke_wdt.c
--- a/drivers/watchdog/booke_wdt.c~watchdog-fix-booke_wdtc-on-mpc85xx-smp-system-fix
+++ a/drivers/watchdog/booke_wdt.c
@@ -1,6 +1,4 @@
/*
- * drivers/watchdog/booke_wdt.c
- *
* Watchdog timer for PowerPC Book-E systems
*
* Author: Matthew McClintock
@@ -39,7 +37,7 @@
#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
#endif /* for timing information */
-u32 booke_wdt_enabled = 0;
+u32 booke_wdt_enabled;
u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#ifdef CONFIG_FSL_BOOKE
@@ -55,19 +53,12 @@ static void __booke_wdt_ping(void *data)
mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
}
-/*
- * booke_wdt_ping:
- */
-static __inline__ void booke_wdt_ping(void)
+static void booke_wdt_ping(void)
{
- smp_call_function(__booke_wdt_ping, NULL, 0, 0);
- __booke_wdt_ping(NULL);
+ on_each_cpu(__booke_wdt_ping, NULL, 0, 0);
}
-/*
- * __booke_wdt_enable:
- */
-static inline void __booke_wdt_enable(void *data)
+static void __booke_wdt_enable(void *data)
{
u32 val;
@@ -79,10 +70,7 @@ static inline void __booke_wdt_enable(vo
mtspr(SPRN_TCR, val);
}
-/*
- * booke_wdt_write:
- */
-static ssize_t booke_wdt_write (struct file *file, const char __user *buf,
+static ssize_t booke_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
booke_wdt_ping();
@@ -90,15 +78,11 @@ static ssize_t booke_wdt_write (struct f
}
static struct watchdog_info ident = {
- .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
- .firmware_version = 0,
- .identity = "PowerPC Book-E Watchdog",
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .identity = "PowerPC Book-E Watchdog",
};
-/*
- * booke_wdt_ioctl:
- */
-static int booke_wdt_ioctl (struct inode *inode, struct file *file,
+static int booke_wdt_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
u32 tmp = 0;
@@ -106,7 +90,7 @@ static int booke_wdt_ioctl (struct inode
switch (cmd) {
case WDIOC_GETSUPPORT:
- if (copy_to_user ((struct watchdog_info __user *) arg, &ident,
+ if (copy_to_user((struct watchdog_info __user *)arg, &ident,
sizeof(struct watchdog_info)))
return -EFAULT;
case WDIOC_GETSTATUS:
@@ -141,18 +125,15 @@ static int booke_wdt_ioctl (struct inode
return 0;
}
-/*
- * booke_wdt_open:
- */
-static int booke_wdt_open (struct inode *inode, struct file *file)
+
+static int booke_wdt_open(struct inode *inode, struct file *file)
{
spin_lock(&booke_wdt_lock);
if (booke_wdt_enabled == 0) {
booke_wdt_enabled = 1;
- __booke_wdt_enable(NULL);
- smp_call_function(__booke_wdt_enable, NULL, 0, 0);
- printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
- booke_wdt_period);
+ on_each_cpu(__booke_wdt_enable, NULL, 0, 0);
+ printk(KERN_INFO "PowerPC Book-E Watchdog Timer Enabled "
+ "(wdt_period=%d)\n", booke_wdt_period);
}
spin_unlock(&booke_wdt_lock);
@@ -160,17 +141,17 @@ static int booke_wdt_open (struct inode
}
static const struct file_operations booke_wdt_fops = {
- .owner = THIS_MODULE,
- .llseek = no_llseek,
- .write = booke_wdt_write,
- .ioctl = booke_wdt_ioctl,
- .open = booke_wdt_open,
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = booke_wdt_write,
+ .ioctl = booke_wdt_ioctl,
+ .open = booke_wdt_open,
};
static struct miscdevice booke_wdt_miscdev = {
- .minor = WATCHDOG_MINOR,
- .name = "watchdog",
- .fops = &booke_wdt_fops,
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &booke_wdt_fops,
};
static void __exit booke_wdt_exit(void)
@@ -178,29 +159,25 @@ static void __exit booke_wdt_exit(void)
misc_deregister(&booke_wdt_miscdev);
}
-/*
- * booke_wdt_init:
- */
static int __init booke_wdt_init(void)
{
int ret = 0;
- printk (KERN_INFO "PowerPC Book-E Watchdog Timer Loaded\n");
+ printk(KERN_INFO "PowerPC Book-E Watchdog Timer Loaded\n");
ident.firmware_version = cur_cpu_spec->pvr_value;
ret = misc_register(&booke_wdt_miscdev);
if (ret) {
- printk (KERN_CRIT "Cannot register miscdev on minor=%d (err=%d)\n",
+ printk(KERN_CRIT "Cannot register miscdev on minor=%d: %d\n",
WATCHDOG_MINOR, ret);
return ret;
}
spin_lock(&booke_wdt_lock);
if (booke_wdt_enabled == 1) {
- printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n",
- booke_wdt_period);
- __booke_wdt_enable(NULL);
- smp_call_function(__booke_wdt_enable, NULL, 0, 0);
+ printk (KERN_INFO "PowerPC Book-E Watchdog Timer Enabled "
+ "(wdt_period=%d)\n", booke_wdt_period);
+ on_each_cpu(__booke_wdt_enable, NULL, 0, 0);
}
spin_unlock(&booke_wdt_lock);
_
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Geoff Levand @ 2008-05-01 21:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1209534108.18023.221.camel@pasglop>
Benjamin Herrenschmidt wrote:
> This patch changes vmemmap to use a different region (region 0xf) of the
> address space whose page size can be dynamically configured at boot.
>
> The problem with the current approach of always using 16M pages is that
> it's not well suited to machines that have small amounts of memory such
> as small partitions on pseries, or PS3's.
>
> In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
> tends to prevent hotplugging the HV's "additional" memory, thus limiting
> the available memory even more, from my experience down to something
> like 80M total, which makes it really not very useable.
>
> The logic used by my match to choose the vmemmap page size is:
>
> - If 16M pages are available and there's 1G or more RAM at boot, use that size.
> - Else if 64K pages are available, use that
> - Else use 4K pages
It doesn't seem to cause problems on PS3, and I added it into ps3-linux.git
as other/powerpc-vmemmap-variable-page-size.diff, but I couldn't get it to
fail without the patch...
Could you send me your kernel .config?
-Geoff
^ permalink raw reply
* RE: SKB corruption on heavy traffic
From: Myron.Dixon @ 2008-05-01 20:55 UTC (permalink / raw)
To: Franca, Jose (NSN - PT/Portugal - MiniMD); +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <56DEE2D3217CD946B290399093C8FA7C212E48@PTLIEXC001.nsn-intra.net>
We have experience a very similar problem using a 2.4.18 kernel on an =
8260 ppc processor.
We have a telecomunication product that for some time only used the fec =
for TCP/IP ethernet=20
traffic only and worked just fine.
After we upgraded our product to implement TDM data over IP we started =
to notice an occasional
kernel oops. We began to evaluate all of our products and determined =
that only some of the units
exhibted this behaviour at various rates of occurrence. Further =
evaluation revealed that the pointers
located in dpram pointing to the fec's buffer descriptors were some how =
getting corrupted.
Note that the 8260 has 4 internal scc/fccs and we use all four for =
various aspects of our application
and each shares dpram for pointers to buffer descriptors that reside in =
sdram. However, only the
fec that is used for IP experiences this buffer descriptor corruption =
and, then, apparently, only under=20
heavy traffic load. We spent about six months evaluating this problem =
including contacting freescale,=20
but never found a solution. We finally, decided to use an external =
ethernet chip on a daughter card=20
for our IP channel.
It is, however, our belief that our problem relates to a possible bug in =
the 8260 CPM, but have yet to
absolutely prove this.
If we are experiencing the same problem (and potentially others) and =
there is a solution we would be
very interested, as, we are not happy about the daughter card solution. =
Myron L. Dixon
Sr. Software Engineer
L-3 Communications, GNS
1519 Grundy's Lane
Bristol, PA 19007
Phone: 215 957 3739
Fax: 215 957 3790
email: Myron.Dixon@L-3Com.com
-----Original Message-----
From: linuxppc-dev-bounces+myron.dixon=3Dl-3com.com@ozlabs.org =
[mailto:linuxppc-dev-bounces+myron.dixon=3Dl-3com.com@ozlabs.org] On =
Behalf Of Franca, Jose (NSN - PT/Portugal - MiniMD)
Sent: Wednesday, April 30, 2008 5:07 AM
To: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: FW: SKB corruption on heavy traffic
>From our latest debugs we found that the problem occurs mainly on skbuff =
code. After some variable time kfree or kalloc result in kernel oops.
-----Original Message-----
From: Franca, Jose (NSN - PT/Portugal - MiniMD)
Sent: quarta-feira, 30 de Abril de 2008 9:44
To: 'ext Scott Wood'
Cc: =09
Subject: RE: SKB corruption on heavy traffic
Hello!
Thank you for replying!
It't quite dificult to say if the problem exists without our changes, =
since the all software is dependent on this changes so to work with the =
hardware. I can't answer to that right now on that, but I forgot to add =
one thing: we have ring buffer full problems on our fcc_enet driver from =
time to time. So, I think the problem could be on linux configurations =
(related to hw) because there is a lot of posts on the web related to =
problems similar to this (none of them has really solved the bottom =
problem).=20
Regards,
Filipe=20
-----Original Message-----
From: ext Scott Wood [mailto:scottwood@freescale.com]
Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: SKB corruption on heavy traffic
On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal - MiniMD) wrote:
> We are developing a MPC8247 based telecom board (512MB), using linux=20
> 2.4 with some proprietary changes on IP stack and we are facing some=20
> problems when we have heavy traffic on our Ethernet interfaces...
Do you see these problems without the proprietary changes, and with a =
current kernel?
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
From: Scott Wood @ 2008-05-01 19:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <17325743-606C-4B3D-88C0-2D0B7902B4E1@kernel.crashing.org>
Kumar Gala wrote:
> copying the flags isn't the issue. Its acting on the flags thats the
> problem. I'm not 100% sure the C code that might clear the flags is
> consistent on how it access them.
Actually *delivering* the signal should never be done except when
returning to user. That's different from sending the signal, though.
BTW, it doesn't seem all that unreasonable for a kernel
profiling/tracing exception to signal a process that, for example, an
event buffer is over a certain threshold.
> So if one bit of code clears
> task_struct->stack->thread_info->flags and other clears
> thread_info(STACK)->flags we get into an issue on how to merge after
> that.
It appears that TIF_SIGPENDING is always accessed through the task
struct, though not so for TIF_NEED_RESCHED.
-Scott
^ permalink raw reply
* Re: powerpc boot regression
From: Geoff Levand @ 2008-05-01 19:01 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linux-kernel, LinuxPPC-dev, y-goto, akpm, David Miller
In-Reply-To: <1209653507.27240.7.camel@badari-desktop>
Badari Pulavarty wrote:
> On Thu, 2008-05-01 at 15:13 +1000, Tony Breeds wrote:
>> On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
>> >
>> > This commit causes bootup failures on sparc64:
>> >
>> > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
>> > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
>> > Date: Mon Apr 28 02:13:33 2008 -0700
>> >
>> > memory hotplug: allocate usemap on the section with pgdat
>>
>>
>> <snip>
>>
>> We're seeing a boot failure on powerpc. git bisect points the problem
>> at this commit. However reverting just this one comitt doesn't fix the
>> regression. I also needed to revert
>> 04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
>> section/node id to free")
>>
>> Problem seen on power4, power5 and ps3.
>
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
The bug is hit with ps3_defconfig. It does not have
CONFIG_SPARSEMEM_VMEMMAP set.
-Geoff
^ permalink raw reply
* Re: NAND command line partiions
From: Scott Wood @ 2008-05-01 19:01 UTC (permalink / raw)
To: Ronald Madrid; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W26E8656DD55138DB5CC3A6F4DB0@phx.gbl>
On Thu, May 01, 2008 at 11:24:35AM -0700, Ronald Madrid wrote:
> I am using u-boot-1.3.1 in order to boot linux 2.6.25 on a custom MPC8313
> based board. In past versions of the kernel I was able to pass the NAND
> partition information to the kernel with this line: root=/dev/mtdblock2
> rootfstype=jffs2 rw console=ttyS0,115200
> mtdparts=nand0:1M(u-boot),3M(kernel),-(jffs2). In this latest version the
> kernel will not mount the partitions because the name that is parsed from
> the command line (nand0) is different from that of the name of the NAND
> that comes from ./drivers/mtd/nand/nand_ids.c (NAND 256MiB 3,3V 8-bit).
This is fixed in the current mtd tree (commit 9ebed3e60f9, fsl_elbc_nand:
fix mtd name).
> I have tried to change the name of the NAND that is passed in via the
> command line, but u-boot does not seem to like the format of the name that
> linux compares against. It doesn't like the ,(comma) in 3,3V.
Why would u-boot care about the format of the kernel command line?
-Scott
^ permalink raw reply
* NAND command line partiions
From: Ronald Madrid @ 2008-05-01 18:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1410.216.70.248.131.1209657620.squirrel@mechanicalanarchy.com>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
I am using u-boot-1.3.1 in order to boot linux 2.6.25 on a custom MPC8313 based board. In past versions of the kernel I was able to pass the NAND partition information to the kernel with this line: root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttyS0,115200 mtdparts=nand0:1M(u-boot),3M(kernel),-(jffs2). In this latest version the kernel will not mount the partitions because the name that is parsed from the command line (nand0) is different from that of the name of the NAND that comes from ./drivers/mtd/nand/nand_ids.c (NAND 256MiB 3,3V 8-bit).
I have tried to change the name of the NAND that is passed in via the command line, but u-boot does not seem to like the format of the name that linux compares against. It doesn't like the ,(comma) in 3,3V.
Does anyone have any suggestions?
Ron Madrid
_________________________________________________________________
Make i'm yours. Create a custom banner to support your cause.
http://im.live.com/Messenger/IM/Contribute/Default.aspx?source=TXT_TAGHM_MSN_Make_IM_Yours
[-- Attachment #2: Type: text/html, Size: 1264 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix a potential issue in mpc52xx uart driver
From: Grant Likely @ 2008-05-01 18:07 UTC (permalink / raw)
To: Andrew Liu; +Cc: linuxppc-dev
In-Reply-To: <4816CFF9.5030505@windriver.com>
On Tue, Apr 29, 2008 at 1:36 AM, Andrew Liu <shengping.liu@windriver.com> wrote:
> mpc52xx_uart_int and __uart_put_char both try to acquire the
> port->lock. Therefore the function sequence of:
>
> mpc52xx_uart_int--> ...-->flush_to_ldisc-->...-->__uart_put_char
>
> can potentially trigger a deadlock. To avoid this deadlock a fix
> similar to that found in the 8250.c serial driver is applied. The
> deadlock is avoided by releasing the lock before pushing a buffer
> and reacquiring it when completed.
>
> Signed-off-by: Andrew Liu <shengping.liu@windriver.com>
Your patch is whitespace damaged and does not apply (tabs have been
converted to spaces). It was trivial so I've applied it manually, but
please be careful when posting future patches.
Thanks,
g.
>
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index d93b357..5f95e53 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -783,7 +783,9 @@ mpc52xx_uart_int_rx_chars(struct uart_port *port)
> }
> }
>
> + spin_unlock(&port->lock);
> tty_flip_buffer_push(tty);
> + spin_lock(&port->lock);
>
> return psc_ops->raw_rx_rdy(port);
> }
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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