Re: Freescale P2020 CPU Freeze over PCIe abort signal
On Mon, Oct 18, 2010 at 3:24 AM, Eran Liberty wrote: > In P2020 if I do any of those the CPU is left hung over the transaction. > > something like: > in_le32(addr) > > is turned into: > 7c 00 04 ac sync 7c 00 4c 2c lwbrx r0,0,r9 > 0c 00 00 00 twi 0,r0,0 > 4c 00 01 2c isync > > assembly code, where in r9 (in this example) hold an address which is > physically mapped into the PCIe resource space. > > The CPU will hang over the load instruction. > > Just for the fun of it, I have wrote my own assembly function omitting > everything but the load instruction; still freeze. > Replace "lwbrx" with a simple "lwz"; still freeze. > > It looks like the CPU snoozes till the PCIe transaction is done with no > timeouts, ignoring any abort signal. > It sounds like a similar issue I got with the 83xx PCIe host controller. If there is no valid link established under the PCIe host controller (ie: no device connected), or the device under the PCIe host controller does not respond the configuration access correctly, the host will hang at the instruction of "lwz" when trying to access the PCIe configuration space (in 83xx, it's memory mapped) And I remember the same issue exists in 8548, not sure if it is fixed in P2020. Bin > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG: dead loop in PowerPC hcall tracepoint (Was: [LTP] [PATCH v2] Add ftrace-stress-test to LTP)
Cc: Steven Cc: Ingo Cc: Peter Cc: Anton Blanchard Cc: Paul Mackerras For those Cced, More information here: http://marc.info/?l=ltp-list&m=128569007015044&w=2 http://marc.info/?l=ltp-list&m=128696942432669&w=2 02:37, Subrata Modak wrote: > I get a bigger trace with this patch: > > Unable to handle kernel paging request for data at address 0x > Faulting instruction address: 0xc02133f0 > cpu 0x2: Vector: 300 (Data Access) at [c000d9f8b560] > pc: c02133f0: .trace_clock_global+0xb4/0x2a0 > lr: c0213458: .trace_clock_global+0x11c/0x2a0 > sp: c000d9f8b7e0 >msr: 8200b032 >dar: 0 > dsisr: 4000 > current = 0xc000d9f7d100 > paca= 0xc7fc8e00 > pid = 1667, comm = ftrace_stack_tr > Unrecoverable FP Unavailable Exception 800 at c16a9540 > cpu 0x0: Vector: 8Unable to handle0 kernel paging r0 equest for data (at > address 0xbffFe0175b688 > PU UnavaFaulting instruciltion address: 0xac01017fcb > le) at [c000d9f8a6a0] > p pc: c16a9540: etnetre r? ?f ofro rh ehlepl > > > lr: [c0016a9540: key_type_dns_resolver+0x15110/0x365f8 > sp: c18804e8 >msr: 80001032 > current = 0xc000d838d100 > paca= 0xc7fc8000 > pid = 1668, comm = ftrace_stack_ma > pid = 1668, cc02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8b9b0] c0223178 .ring_buffer_lock_reserve > +0x24c/0x2a4 > [c000d9f8ba40] c022d6f4 .trace_buffer_lock_reserve+0x58/0xe4 > [c000d9f8baf0] c022ec9c .trace_current_buffer_lock_reserve > +0x44/0x6c > [c000d9f8bb80] c0011c5c .ftrace_raw_event_hcall_entry > +0x7c/0x144 > [c000d9f8bc40] c0096624 .__trace_hcall_entry+0xa0/0xec > [c000d9f8bcd0] c009786c .plpar_hcall_norets+0x50/0xd0 > [c000d9f8bd40] c00749c8 .__spin_yield+0x130/0x15c > [c000d9f8bdd0] c0213458 .trace_clock_global+0x11c/0x2a0 This is a dead loop: trace_hcall_entry() -> trace_clock_global() -> trace_hcall_entry() .. And this is a PPC specific bug. Hope some ppc guys will fix it? Or we kill trace_clock_global() if no one actually uses it.. -- Li Zefan > [c000d9f8be90] c02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8bfa0] c0223178 .ring_buffer_lock_reserve > +0x24c/0x2a4 > [c000d9f8c030] c022d6f4 .trace_buffer_lock_reserve+0x58/0xe4 > [c000d9f8c0e0] c022ec9c .trace_current_buffer_lock_reserve > +0x44/0x6c > [c000d9f8c170] c0011c5c .ftrace_raw_event_hcall_entry > +0x7c/0x144 > [c000d9f8c230] c0096624 .__trace_hcall_entry+0xa0/0xec > [c000d9f8c2c0] c009786c .plpar_hcall_norets+0x50/0xd0 > [c000d9f8c330] c00749c8 .__spin_yield+0x130/0x15c > [c000d9f8c3c0] c0213458 .trace_clock_global+0x11c/0x2a0 > [c000d9f8c480] c02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8c590] c0223178 .ring_buffer_lock_reserve > +0x24c/0x2a4 > [c000d9f8c620] c022d6f4 .trace_buffer_lock_reserve+0x58/0xe4 > [c000d9f8c6d0] c022ec9c .trace_current_buffer_lock_reserve > +0x44/0x6c > [c000d9f8c760] c0011c5c .ftrace_raw_event_hcall_entry > +0x7c/0x144 > [c000d9f8c820] c0096624 .__trace_hcall_entry+0xa0/0xec > [c000d9f8c8b0] c009786c .plpar_hcall_norets+0x50/0xd0 > [c000d9f8c920] c00749c8 .__spin_yield+0x130/0x15c > [c000d9f8c9b0] c0213458 .trace_clock_global+0x11c/0x2a0 > [c000d9f8ca70] c02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8cb80] c0223178 .ring_buffer_lock_reserve > +0x24c/0x2a4 > [c000d9f8cc10] c022d6f4 .trace_buffer_lock_reserve+0x58/0xe4 > [c000d9f8ccc0] c022ec9c .trace_current_buffer_lock_reserve > +0x44/0x6c > [c000d9f8cd50] c0011c5c .ftrace_raw_event_hcall_entry > +0x7c/0x144 > [c000d9f8ce10] c0096624 .__trace_hcall_entry+0xa0/0xec > [c000d9f8cea0] c009786c .plpar_hcall_norets+0x50/0xd0 > [c000d9f8cf10] c00749c8 .__spin_yield+0x130/0x15c > [c000d9f8cfa0] c0213458 .trace_clock_global+0x11c/0x2a0 > [c000d9f8d060] c02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8d170] c0223178 .ring_buffer_lock_reserve > +0x24c/0x2a4 > [c000d9f8d200] c022d6f4 .trace_buffer_lock_reserve+0x58/0xe4 > [c000d9f8d2b0] c022ec9c .trace_current_buffer_lock_reserve > +0x44/0x6c > [c000d9f8d340] c0011c5c .ftrace_raw_event_hcall_entry > +0x7c/0x144 > [c000d9f8d400] c0096624 .__trace_hcall_entry+0xa0/0xec > [c000d9f8d490] c009786c .plpar_hcall_norets+0x50/0xd0 > [c000d9f8d500] c00749c8 .__spin_yield+0x130/0x15c > [c000d9f8d590] c0213458 .trace_clock_global+0x11c/0x2a0 > [c000d9f8d650] c02226b0 .rb_reserve_next_event+0x20c/0x804 > [c000d9f8d760] c00
Re: 64K PAGE_SIZE and arch/powerpc/kernel/vdso.c
> Greetings Linux-ppc64 folks,
>
> While trying to compile v2.6.36-rc8 with PAGE_SIZE=65536 I run into the
> following compile failure w/ strict checking on a RHEL5.4 / gcc (GCC)
> 4.1.2 20080704 (Red Hat 4.1.2-46) system:
>
> cc1: warnings being treated as errors
> arch/powerpc/kernel/vdso.c:81: warning: alignment of ‘vdso_data_store’
> is greater than maximum object file alignment. Using 32768
> CC arch/powerpc/sysdev/msi_bitmap.o
> make[1]: *** [arch/powerpc/kernel/vdso.o] Error 1
> make[1]: *** Waiting for unfinished jobs
>
> Any ideas folks..?
It seems this broke it:
commit abe1ee3a221d53778c3e58747bbec6e518e5471b
Author: Tim Abbott
Date: Sun Sep 20 18:14:15 2009 -0400
Use macros for .data.page_aligned section.
This patch changes the remaining direct references to
.data.page_aligned in C and assembly code to use the macros in
include/linux/linkage.h.
Backing out just that part of the change (see below) fixes it.
FYI the error only occurs on gcc 4.1 and 4.2. 4.3 and greater is fine.
Mikey
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 13002fe..c140fce 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -78,7 +78,7 @@ static int vdso_ready;
static union {
struct vdso_datadata;
u8 page[PAGE_SIZE];
-} vdso_data_store __page_aligned_data;
+} vdso_data_store __attribute__((__section__(".data.page_aligned")));
struct vdso_data *vdso_data = &vdso_data_store.data;
/* Format of the patch table */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Freescale P2020 CPU Freeze over PCIe abort signal
This should probably go to the Freescale support, as it feels like a hardware issue yet the end result is a very frozen Linux kernel so I post here first... I have a programmable FPGA PCIe device connected to a Freescale's P2020 PCIe port. As part of the bring-up tests, we are testing two faulty scenarios: 1. The FPGA totally ignores the PCIe transaction. 2. The FPGA return a transaction abort. Both are plausible PCIe behavior and their should be outcome is documented in the PCIe spec. The first should be terminated by the transaction requestor timeout mechanism and raise an error, the second should abort the transaction and raise and error. In P2020 if I do any of those the CPU is left hung over the transaction. something like: in_le32(addr) is turned into: 7c 00 04 ac sync 7c 00 4c 2c lwbrx r0,0,r9 0c 00 00 00 twi 0,r0,0 4c 00 01 2c isync assembly code, where in r9 (in this example) hold an address which is physically mapped into the PCIe resource space. The CPU will hang over the load instruction. Just for the fun of it, I have wrote my own assembly function omitting everything but the load instruction; still freeze. Replace "lwbrx" with a simple "lwz"; still freeze. It looks like the CPU snoozes till the PCIe transaction is done with no timeouts, ignoring any abort signal. I am going to: A. Try to reach the Freescale support. B. Asked the FPGA designed to give me a new behavior that will stall the PCIe transaction replay for 10 sec, but after those return ok. C. report back here with either A or B. If you have any ideas I would love to hear them. -- Liberty ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: sysdev: fix signedness bug
sram_params.sram_size and sram_params.sram_offset were unsigned.
If get_cache_sram_size() or get_cache_sram_offset() returns error code
then it is not seen to the caller. Made sram_size and sram_offset signed.
Signed-off-by: Vasiliy Kulikov
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index cc8d655..23b85ac 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -94,14 +94,14 @@ static int __devinit mpc85xx_l2ctlr_of_probe(struct
platform_device *dev,
l2cache_size = *prop;
sram_params.sram_size = get_cache_sram_size();
- if (sram_params.sram_size <= 0) {
+ if ((int)sram_params.sram_size <= 0) {
dev_err(&dev->dev,
"Entire L2 as cache, Aborting Cache-SRAM stuff\n");
return -EINVAL;
}
sram_params.sram_offset = get_cache_sram_offset();
- if (sram_params.sram_offset <= 0) {
+ if ((int64_t)sram_params.sram_offset <= 0) {
dev_err(&dev->dev,
"Entire L2 as cache, provide a valid sram offset\n");
return -EINVAL;
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ps3disk: passing wrong variable to bvec_kunmap_irq()
On Sun, Oct 17, 2010 at 08:49, Jens Axboe wrote:
> On 2010-10-16 21:39, Geert Uytterhoeven wrote:
>> On Mon, Oct 11, 2010 at 21:42, Jens Axboe wrote:
>>> On 2010-10-11 21:13, Dan Carpenter wrote:
This should pass "buf" to bvec_kunmap_irq() instead of "bv". The api is
like kmap_atomic() instead of kmap().
Signed-off-by: Dan Carpenter
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index e9da874..03688c2 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -113,7 +113,7 @@ static void ps3disk_scatter_gather(struct
ps3_storage_device *dev,
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
flush_kernel_dcache_page(bvec->bv_page);
- bvec_kunmap_irq(bvec, &flags);
+ bvec_kunmap_irq(buf, &flags);
i++;
}
}
>>>
>>> Thanks applied, that bug is all too common.
>>
>> Because bvec_kunmap_irq() is a macro if !CONFIG_HIGHMEM, and thus there's no
>> argument type checking on e.g. pp64, which doesn't support HIGHMEM?
>
> It's a generic problem, not isolated to this case. The problem is that
> the API isn't symmetric, and the unmap parts take a void * pointer.
No, the unmap takes a char *:
static inline void bvec_kunmap_irq(char *buffer, unsigned long *flags)
So it could be detected. Patch will follow.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ps3disk: passing wrong variable to bvec_kunmap_irq()
On 2010-10-16 21:39, Geert Uytterhoeven wrote: > On Mon, Oct 11, 2010 at 21:42, Jens Axboe wrote: >> On 2010-10-11 21:13, Dan Carpenter wrote: >>> This should pass "buf" to bvec_kunmap_irq() instead of "bv". The api is >>> like kmap_atomic() instead of kmap(). >>> >>> Signed-off-by: Dan Carpenter >>> >>> diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c >>> index e9da874..03688c2 100644 >>> --- a/drivers/block/ps3disk.c >>> +++ b/drivers/block/ps3disk.c >>> @@ -113,7 +113,7 @@ static void ps3disk_scatter_gather(struct >>> ps3_storage_device *dev, >>> memcpy(buf, dev->bounce_buf+offset, size); >>> offset += size; >>> flush_kernel_dcache_page(bvec->bv_page); >>> - bvec_kunmap_irq(bvec, &flags); >>> + bvec_kunmap_irq(buf, &flags); >>> i++; >>> } >>> } >> >> Thanks applied, that bug is all too common. > > Because bvec_kunmap_irq() is a macro if !CONFIG_HIGHMEM, and thus there's no > argument type checking on e.g. pp64, which doesn't support HIGHMEM? It's a generic problem, not isolated to this case. The problem is that the API isn't symmetric, and the unmap parts take a void * pointer. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 5/5] mtd: m25p80: add support to parse the partitions by OF node
On Sat, 2010-10-16 at 19:05 -0600, Grant Likely wrote: > On Sat, Oct 16, 2010 at 1:17 PM, Artem Bityutskiy wrote: > > On Tue, 2010-10-12 at 18:18 +0800, Mingkai Hu wrote: > >> Signed-off-by: Mingkai Hu > >> Acked-by: Grant Likely > >> --- > >> v4: > >> - Updated to latest kernel base(Linux 2.6.36-rc7). > >> - Made changes according to Grant's comments. > > > > Looks good to me, pushed to l2-mtd-2.6.git, thanks. > > Wait! It will break whenever CONFIG_OF is not set. I broke > linux-next with this patch. It can be solved by wrapping the block > with #ifdef CONFIG_OF, but I'd like to find a better solution. OK, removed. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
