Re: [PATCH][SPARC64] fix section mismatchs from dr_cpu_data
From: Sam Ravnborg [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 21:32:29 +0100 [SPARC64] fix section mismatchs from dr_cpu_data Fix following warnings: WARNING: vmlinux.o(.text+0x4b258): Section mismatch in reference from the function dr_cpu_data() to the function .devinit.text:mdesc_fill_in_cpu_data() WARNING: vmlinux.o(.text+0x4b290): Section mismatch in reference from the function dr_cpu_data() to the function .cpuinit.text:cpu_up() mdesc_fill_in_cpu_data() is only used during early init and for cpu hotplug so the __cpuinit annotation is the correct choice. We have the call chain: dr_cpu_data() = dr_cpu_configure() = mdesc_fill_in_cpu_data() dr_cpu_data() is used only during early init and for cpu hotplug. So annotating them all __cpuinit solves the section mismatch and should be correct. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] --- Please review before you apply. I am not 100% sure if my assumptions are correct. Sam It does look good, applied, thanks Sam. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][SPARC64] fix section mismatch from kernel_map_range
From: Sam Ravnborg [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 21:33:31 +0100 Fix following warnings: WARNING: vmlinux.o(.text+0x4f980): Section mismatch in reference from the function kernel_map_range() to the function .init.text:__alloc_bootmem() WARNING: vmlinux.o(.text+0x4f9cc): Section mismatch in reference from the function kernel_map_range() to the function .init.text:__alloc_bootmem() alloc_bootmem() is only used during early init and for any subsequent call to kernel_map_range() the program logic avoid the call. So annotate kernel_map_range() with __ref to tell modpost to ignore the reference to a __init function. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Applied, thanks Sam. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc64 section mismatch status
From: Sam Ravnborg [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 21:39:10 +0100 After applying the patches I just sent to you and a third for hpt366 (sent to Bart) my sparc64 build is section mismatch clean. Great. I have not tried different configs neither allyesconfig etc. We can get to that later. If you see any section mismatch warnings in the configs you use then please do a make CONFIG_DEBUG_SECTION_MISMATCH=y build and send me the config + the warning output and I will see if I can fix it. Or even better - fix it up yourself... I've noticed this facility and I will try to take care of any leftovers, thanks! - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc64 section mismatch warnings
From: Sam Ravnborg [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 22:50:20 +0100 Full diff of the included changes below. If you can use this in part or in toal they have my: Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Looks good, applied. Yes, this stuff is all only user past __init time if we have cpuhotplug enabled. WARNING: vmlinux.o(.text+0x47094): Section mismatch in reference from the function dr_cpu_data() to the function .devinit.text:mdesc_fill_in_cpu_data() The function dr_cpu_data() references the function __devinit mdesc_fill_in_cpu_data(). This is often because dr_cpu_data lacks a __devinit annotation or the annotation of mdesc_fill_in_cpu_data is wrong. I could not see how to fix this in a clean way. dr_cpu_data() references mdesc_fill_in_cpu_data() via dr_cpu_configure() and that looks bogus. This is how CPUs are hotplugged on LDOM systems. We receive a message from the control node which is processed by this dr_cpu_configure() stuff. The thing to do is likely mark mdesc_fill_in_cpu_data() and it's helper functions __cpuinit instead of __devinit. But yes then there is the issue of how to annotate dr_cpu_data() and dr_cpu_configure(). Hmmm... These two dr_*() functions are essentially roots of the __cpuinit scope call sites here. We have to find some way for the mismatch checker to learn that this is OK because we only build this code if cpu hotplug is enabled. Any ideas? - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ESP driver
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Tue, 19 Feb 2008 10:20:10 +0100 Only one question. For you, where can I find this bug ? In arch/sparc, in shared code or in ESP driver itself ? I have to be terse and frank with you, I do not have the time necessary to sit down and teach someone how to debug these problems. Besides, you will learn much more about the system if you try to explore it yourself. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala [EMAIL PROTECTED]
Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
We introduced a bug in fixing lmb_add_region to handle an initial
region being non-zero. Before that fix it was impossible to insert
a region at the head of the list since the first region always started
at zero.
Now that its possible for the first region to be non-zero we need to
check to see if the new region should be added at the head and if so
actually add it.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
...
@@ -184,6 +184,11 @@ static long __init lmb_add_region(struct lmb_region
*rgn, u64 base, u64 size)
break;
}
}
+
+ if (base rgn-region[0].base) {
+ rgn-region[0].base = base;
+ rgn-region[0].size = size;
+ }
rgn-cnt++;
return 0;
Are you sure this is sufficient?
It seems to me, to handle this properly, you'll need to handle
the case where the lower addressed entry you are inserting is
not contiguous with the existing entry 0.
Therefore, you need to move all existing entries up a slot,
then you can set the 0 entry to 'base' and 'size'.
What do you think?
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala [EMAIL PROTECTED] Date: Tue, 19 Feb 2008 23:16:18 -0600 The for loop above the code I added will move all the existing slots up one. Its just the tail cleanup we are missing. Aha, I see how this works now, thanks! I'll add this to my LMB tree. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ESP driver
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Mon, 18 Feb 2008 22:34:25 +0100 I think I have found a bug in esp_scsi.c. Without this patch, my SS20/SMP was not able to rebuild its internal raid1 volume due to esp0 DMA errors. With the following patch, same workstation is building a kernel, doing a rsync (between two local directories) and rebuilding a 26 GB raid1 volume without any trouble. Signed-off-by: BERTRAND Joel [EMAIL PROTECTED] It may correct your problem for some reason, but this change is not correct (and your email client or your editor used spaces instead of tab characters in your change). The FAS100A implements the ESP_STAT_INTR bit correctly. If the FAS100A needed this change, you would get spurious IRQs or other state machine errors, not DMA errors. I think your change merely changes timings, making the DMA problem harder to trigger. I'm sorry I don't have more desirable feedback for your patch, but it's the best I can do :-) - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4]: Respun LMB patches.
From: Becky Bruce [EMAIL PROTECTED] Date: Thu, 14 Feb 2008 14:58:22 -0600 Thanks for picking up the patches from Kumar and myself and fitting them into your series - this is much appreciated. FYI, I applied the entire patch series to my local tree and test-booted both mpc8641 and mpc8568mds and both build and boot cleanly. I also built pasemi and ebony, those build cleanly as well. Thanks for all of the testing. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4]: Respun LMB patches.
From: Josh Boyer [EMAIL PROTECTED] Date: Thu, 14 Feb 2008 15:24:48 -0600 I plan on actually testing this on Ebony, Walnut, and Bamboo either later tonight or tomorrow. I don't expect many issues. Dave, those above boards would cover the build of PowerPC 4xx CPU cores. Ok. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT]: Make LMB code sharable with sparc64.
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add Kconfig machinery to build this
stuff on sparc64.
2) Fix a bug in lmb_alloc() wherein the size was not aligned
so we could easily run out of reserve blocks because
every aligned allocation would create a tiny hole, and
secondly the lmb_reserve() call there did not have it's
return value checked.
Powerpc folks, if there are no objections please pull, thanks!
The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
Linus Torvalds (1):
WMI: initialize wmi_blocks.list even if ACPI is disabled
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
David S. Miller (2):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
arch/powerpc/Kconfig|3 +
arch/powerpc/kernel/btext.c |2 +-
arch/powerpc/kernel/crash.c |2 +-
arch/powerpc/kernel/crash_dump.c|2 +-
arch/powerpc/kernel/machine_kexec.c |2 +-
arch/powerpc/kernel/prom.c |2 +-
arch/powerpc/kernel/rtas.c |2 +-
arch/powerpc/kernel/setup-common.c |2 +-
arch/powerpc/kernel/setup_64.c |2 +-
arch/powerpc/kernel/vdso.c |2 +-
arch/powerpc/mm/Makefile|2 +-
arch/powerpc/mm/hash_utils_64.c |2 +-
arch/powerpc/mm/init_32.c |2 +-
arch/powerpc/mm/init_64.c |2 +-
arch/powerpc/mm/mem.c |2 +-
arch/powerpc/mm/numa.c |2 +-
arch/powerpc/mm/ppc_mmu_32.c|2 +-
arch/powerpc/mm/stab.c |2 +-
arch/powerpc/platforms/cell/iommu.c |2 +-
arch/powerpc/platforms/maple/setup.c|2 +-
arch/powerpc/platforms/powermac/setup.c |2 +-
arch/powerpc/platforms/ps3/htab.c |2 +-
arch/powerpc/platforms/ps3/mm.c |2 +-
arch/powerpc/platforms/ps3/os-area.c|2 +-
arch/powerpc/sysdev/dart_iommu.c|2 +-
arch/sparc64/Kconfig|3 +
include/asm-powerpc/abs_addr.h |2 +-
include/asm-powerpc/lmb.h | 82 +++---
include/asm-sparc64/lmb.h | 10
include/linux/lmb.h | 83 +++
lib/Makefile|2 +
{arch/powerpc/mm = lib}/lmb.c | 39 ---
32 files changed, 155 insertions(+), 117 deletions(-)
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
rename {arch/powerpc/mm = lib}/lmb.c (92%)
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT]: Make LMB code sharable with sparc64.
From: Sam Ravnborg [EMAIL PROTECTED] Date: Wed, 13 Feb 2008 09:57:35 +0100 Review had been easier if the patch was inlined. Sorry :) Can we plase have this changed to use: config SPARC64 + select HAVE_LMB And then in lib/Kconfig have +config HAVE_LMB + bool So we avoid creating a new variable each time we introdce LMB support. You would need to update powerpc Kconfig too of course. Sure, I'll rework this in the next day or so to do things that way. Thanks for the review. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT]: Make LMB code sharable with sparc64.
From: Kumar Gala [EMAIL PROTECTED] Date: Wed, 13 Feb 2008 07:12:26 -0600 Does sparc have the concept of a phys_addr_t? We are in the process of expanding the lmb support to deal with 36-bit physical addresses on 32-bit machines. On sparc64, where I intend to use this, unsigned long's are 64-bit. If you use some phys_addr_t type instead to help ppc32 along, that would be perfectly fine with me. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala [EMAIL PROTECTED] Date: Wed, 13 Feb 2008 07:37:27 -0600 (CST) If we add to an empty lmb region with a non-zero base we will not coalesce the number of regions done to one. This causes problems on ppc32 for the memory region as its assumed to only have one region. We can fix this be easily specially casing the initial add to just replace the dummy region. --- Posting this since Dave's looking a pulling the lmb code out into lib/ and sharing it between powerpc and sparc. (this is my git tree git.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git) I noticed this issue when I use lmb on sparc64 and I intended to bring it up eventually. Thanks for fixing it! - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] [POWERPC] Make lmb support large physical addressing
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Thu, 14 Feb 2008 09:50:42 +1100 On Wed, 2008-02-13 at 16:43 -0600, Becky Bruce wrote: Convert the lmb code to use phys_addr_t instead of unsigned long for physical addresses and sizes. This is needed to support large amounts of RAM on 32-bit systems that support 36-bit physical addressing. Built/booted on mpc8641; build tested on pasemi and 44x. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- Folks, This has been sitting in my tree for a few days, and now it looks like David M. has submitted a patch that changes the lmb code to be shared between sparc and powerpc. Sparc has no notion of a phys_addr_t. Should we just use u64 everywhere in this code instead? Thoughts? An option would be to use resource_size_t, though it's a bit yucky... Dave, what do you prefer ? u64 is fine with me, either way we'll be casting the printk() arguments all over the place so the choice really isn't so important one way or the other as far as I can tell. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4]: [LMB]: Make lmb support large physical addressing
[LMB]: Make lmb support large physical addressing
Convert the lmb code to use u64 instead of unsigned long for physical
addresses and sizes. This is needed to support large amounts of RAM
on 32-bit systems that support 36-bit physical addressing.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
include/linux/lmb.h | 38 ++--
lib/lmb.c | 93 +--
2 files changed, 65 insertions(+), 66 deletions(-)
diff --git a/include/linux/lmb.h b/include/linux/lmb.h
index 8b93f63..632717c 100644
--- a/include/linux/lmb.h
+++ b/include/linux/lmb.h
@@ -19,19 +19,19 @@
#define MAX_LMB_REGIONS 128
struct lmb_property {
- unsigned long base;
- unsigned long size;
+ u64 base;
+ u64 size;
};
struct lmb_region {
unsigned long cnt;
- unsigned long size;
+ u64 size;
struct lmb_property region[MAX_LMB_REGIONS+1];
};
struct lmb {
unsigned long debug;
- unsigned long rmo_size;
+ u64 rmo_size;
struct lmb_region memory;
struct lmb_region reserved;
};
@@ -40,36 +40,36 @@ extern struct lmb lmb;
extern void __init lmb_init(void);
extern void __init lmb_analyze(void);
-extern long __init lmb_add(unsigned long base, unsigned long size);
-extern long __init lmb_reserve(unsigned long base, unsigned long size);
-extern unsigned long __init lmb_alloc(unsigned long size, unsigned long align);
-extern unsigned long __init lmb_alloc_base(unsigned long size,
- unsigned long align, unsigned long max_addr);
-extern unsigned long __init __lmb_alloc_base(unsigned long size,
- unsigned long align, unsigned long max_addr);
-extern unsigned long __init lmb_phys_mem_size(void);
-extern unsigned long __init lmb_end_of_DRAM(void);
-extern void __init lmb_enforce_memory_limit(unsigned long memory_limit);
-extern int __init lmb_is_reserved(unsigned long addr);
+extern long __init lmb_add(u64 base, u64 size);
+extern long __init lmb_reserve(u64 base, u64 size);
+extern u64 __init lmb_alloc(u64 size, u64 align);
+extern u64 __init lmb_alloc_base(u64 size,
+ u64, u64 max_addr);
+extern u64 __init __lmb_alloc_base(u64 size,
+ u64 align, u64 max_addr);
+extern u64 __init lmb_phys_mem_size(void);
+extern u64 __init lmb_end_of_DRAM(void);
+extern void __init lmb_enforce_memory_limit(u64 memory_limit);
+extern int __init lmb_is_reserved(u64 addr);
extern void lmb_dump_all(void);
-static inline unsigned long
+static inline u64
lmb_size_bytes(struct lmb_region *type, unsigned long region_nr)
{
return type-region[region_nr].size;
}
-static inline unsigned long
+static inline u64
lmb_size_pages(struct lmb_region *type, unsigned long region_nr)
{
return lmb_size_bytes(type, region_nr) PAGE_SHIFT;
}
-static inline unsigned long
+static inline u64
lmb_start_pfn(struct lmb_region *type, unsigned long region_nr)
{
return type-region[region_nr].base PAGE_SHIFT;
}
-static inline unsigned long
+static inline u64
lmb_end_pfn(struct lmb_region *type, unsigned long region_nr)
{
return lmb_start_pfn(type, region_nr) +
diff --git a/lib/lmb.c b/lib/lmb.c
index e34a9e5..e3c8dcb 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -34,33 +34,34 @@ void lmb_dump_all(void)
DBG(lmb_dump_all:\n);
DBG(memory.cnt = 0x%lx\n, lmb.memory.cnt);
- DBG(memory.size = 0x%lx\n, lmb.memory.size);
+ DBG(memory.size = 0x%llx\n,
+ (unsigned long long)lmb.memory.size);
for (i=0; i lmb.memory.cnt ;i++) {
- DBG(memory.region[0x%x].base = 0x%lx\n,
- i, lmb.memory.region[i].base);
- DBG( .size = 0x%lx\n,
- lmb.memory.region[i].size);
+ DBG(memory.region[0x%x].base = 0x%llx\n,
+ i, (unsigned long long)lmb.memory.region[i].base);
+ DBG( .size = 0x%llx\n,
+ (unsigned long long)lmb.memory.region[i].size);
}
DBG(\nreserved.cnt = 0x%lx\n, lmb.reserved.cnt);
DBG(reserved.size= 0x%lx\n, lmb.reserved.size);
for (i=0; i lmb.reserved.cnt ;i++) {
- DBG(reserved.region[0x%x].base = 0x%lx\n,
- i, lmb.reserved.region[i].base);
- DBG( .size = 0x%lx\n,
- lmb.reserved.region[i].size);
+ DBG(reserved.region[0x%x].base = 0x%llx\n,
+ i, (unsigned long long)lmb.reserved.region[i].base);
+ DBG( .size = 0x%llx\n,
+ (unsigned long long)lmb.reserved.region[i].size);
}
#endif /* DEBUG */
}
-static unsigned long __init lmb_addrs_overlap(unsigned long
[PATCH 1/4]: [LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
arch/powerpc/Kconfig|1 +
arch/powerpc/kernel/btext.c |3 +-
arch/powerpc/kernel/crash.c |3 +-
arch/powerpc/kernel/crash_dump.c|3 +-
arch/powerpc/kernel/machine_kexec.c |3 +-
arch/powerpc/kernel/prom.c |2 +-
arch/powerpc/kernel/rtas.c |2 +-
arch/powerpc/kernel/setup-common.c |2 +-
arch/powerpc/kernel/setup_64.c |2 +-
arch/powerpc/kernel/vdso.c |3 +-
arch/powerpc/mm/Makefile|2 +-
arch/powerpc/mm/hash_utils_64.c |3 +-
arch/powerpc/mm/init_32.c |2 +-
arch/powerpc/mm/init_64.c |2 +-
arch/powerpc/mm/lmb.c | 357 ---
arch/powerpc/mm/mem.c |2 +-
arch/powerpc/mm/numa.c |3 +-
arch/powerpc/mm/ppc_mmu_32.c|2 +-
arch/powerpc/mm/stab.c |4 +-
arch/powerpc/platforms/cell/iommu.c |2 +-
arch/powerpc/platforms/maple/setup.c|2 +-
arch/powerpc/platforms/powermac/setup.c |2 +-
arch/powerpc/platforms/ps3/htab.c |3 +-
arch/powerpc/platforms/ps3/mm.c |3 +-
arch/powerpc/platforms/ps3/os-area.c|3 +-
arch/powerpc/sysdev/dart_iommu.c|2 +-
arch/sparc64/Kconfig|1 +
include/asm-powerpc/abs_addr.h |3 +-
include/asm-powerpc/lmb.h | 82 +---
include/asm-sparc64/lmb.h | 10 +
include/linux/lmb.h | 83 +++
lib/Kconfig |3 +
lib/Makefile|2 +
lib/lmb.c | 354 ++
34 files changed, 500 insertions(+), 456 deletions(-)
delete mode 100644 arch/powerpc/mm/lmb.c
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
create mode 100644 lib/lmb.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 485513c..bd645f0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -90,6 +90,7 @@ config PPC
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_KPROBES
+ select HAVE_LMB
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index 80e2eef..9f93777 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -7,6 +7,7 @@
#include linux/string.h
#include linux/init.h
#include linux/module.h
+#include linux/lmb.h
#include asm/sections.h
#include asm/prom.h
@@ -15,7 +16,7 @@
#include asm/mmu.h
#include asm/pgtable.h
#include asm/io.h
-#include asm/lmb.h
+#include asm/prom.h
#include asm/processor.h
#include asm/udbg.h
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 571132e..eae401d 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -24,12 +24,13 @@
#include linux/init.h
#include linux/irq.h
#include linux/types.h
+#include linux/lmb.h
#include asm/processor.h
#include asm/machdep.h
#include asm/kexec.h
#include asm/kdump.h
-#include asm/lmb.h
+#include asm/prom.h
#include asm/firmware.h
#include asm/smp.h
#include asm/system.h
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 29ff77c..9ee3c52 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -13,8 +13,9 @@
#include linux/crash_dump.h
#include linux/bootmem.h
+#include linux/lmb.h
#include asm/kdump.h
-#include asm/lmb.h
+#include asm/prom.h
#include asm/firmware.h
#include asm/uaccess.h
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c0c8e8c..2d202f2 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -12,8 +12,9 @@
#include linux/kexec.h
#include linux/reboot.h
#include linux/threads.h
+#include linux/lmb.h
#include asm/machdep.h
-#include asm/lmb.h
+#include asm/prom.h
void machine_crash_shutdown(struct pt_regs *regs)
{
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b5efbc..c17a585 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -31,10 +31,10 @@
#include linux/kexec.h
#include linux/debugfs.h
#include linux/irq.h
+#include linux/lmb.h
#include asm/prom.h
#include asm/rtas.h
-#include asm/lmb.h
#include asm/page.h
#include asm/processor.h
#include asm/irq.h
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 52e95c2..e2e78d9 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -22,6 +22,7 @@
#include linux/smp.h
#include linux/completion.h
#include linux/cpumask.h
+#include linux/lmb.h
#include asm/prom.h
#include asm/rtas.h
Re: [PATCH] SPARC: Use shorter form of get_zeroed_page.
From: Robert P. J. Day [EMAIL PROTECTED] Date: Sun, 10 Feb 2008 15:05:34 -0500 (EST) Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SPARC64: Use shorter get_zeroed_page call.
From: Robert P. J. Day [EMAIL PROTECTED] Date: Sun, 10 Feb 2008 15:16:57 -0500 (EST) Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with linux sunvdc driver and solaris zfs partitions
From: John Cater [EMAIL PROTECTED] Date: Thu, 7 Feb 2008 22:10:48 -0500 [15473.014047] sunvdc.c:v1.0 (June 25, 2007) [15473.031275] sunvdc: VD_OP_GET_VTOC returns error -48 [15473.031319] vdc_port: probe of vdc-port-0-0 failed with error -48 We only support file and full device exports that use Sun disk labels. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gcc 4.2 or kernel bug ?
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Fri, 08 Feb 2008 11:53:42 +0100 swapper: page allocation failure. order:1, mode:0x4020 This is harmless and will happen from time to time under certain kinds of loads. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gcc 4.2 or kernel bug ?
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Fri, 08 Feb 2008 12:05:43 +0100 Same constatation on U2/SMP. On a 32-threads T1000, I obtain : BUG: soft lockup - CPU#1 stuck for 11s! [md2_raid1:2736] Unlike the other message, this might be a real problem. I'm not sure that both constatations come from the same bug. They are not. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: section mismatch 2.6.24
From: Daniel Smolik [EMAIL PROTECTED] Date: Thu, 31 Jan 2008 21:03:03 +0100 Hi, I today start compile 2.6.24 and get this warnning: MODPOST vmlinux.o WARNING: vmlinux.o(.text+0x3ffac): Section mismatch: reference to .init.text:sun4v_ktsb_register (between 'smp_callin' and 'smp_fill_in_sib_core_maps') WARNING: vmlinux.o(.text+0x4092c): Section mismatch: reference to .init.text:sun4v_register_mondo_queues (between 'after_lock_tlb' and 'hv_cpu_startup') WARNING: vmlinux.o(.text+0x40b6c): Section mismatch: reference to .init.text:sun4v_register_mondo_queues (between 'hv_cpu_startup' and 'hv_cpu_startup_end') WARNING: vmlinux.o(.sun4v_2insn_patch+0x3d8): Section mismatch: reference to .init.text: Have anybody solution ? These warnings are harmless, please just ignore them. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS 2.6.20 E450
From: Daniel Smolik [EMAIL PROTECTED] Date: Thu, 31 Jan 2008 21:24:06 +0100 Hi, I today work on my E450 and get this :-(. I run vanilla 2.6.20. There were several TCP bugs fixes in 2.6.20.1 and later, any one of which could have caused your OOPS. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][SPARC64] fix inconsistent .section usage in lib/
From: Sam Ravnborg [EMAIL PROTECTED] Date: Sun, 27 Jan 2008 13:56:23 +0100 A few places missed the a specifier for the __ex_table section. Add these so we avoid generation an additional section at link time. Latest modpost would otherwise complain like this: WARNING: vmlinux.o (__ex_table.2): section name inconsistency. (.[number]+) following section name. Did you forget to use ax/aw in a .S file? Note that for example linux/init.h contains section definitions for use in .S files. WARNING: vmlinux.o (__ex_table.4): section name inconsistency. (.[number]+) following section name. Did you forget to use ax/aw in a .S file? Note that for example linux/init.h contains section definitions for use in .S files. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Applied, thanks Sam. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compile failure in Solaris emulation
From: Meelis Roos [EMAIL PROTECTED] Date: Thu, 24 Jan 2008 16:26:32 +0200 (EET) Tried to ompile todays 2.6.24-rc8+git on sparc64 and got this: CC [M] arch/sparc64/solaris/socksys.o arch/sparc64/solaris/socksys.c: In function 'init_socksys': arch/sparc64/solaris/socksys.c:192: error: assignment of read-only variable 'socksys_file_ops' arch/sparc64/solaris/socksys.c:195: error: assignment of read-only variable 'socksys_file_ops' arch/sparc64/solaris/socksys.c:196: error: assignment of read-only variable 'socksys_file_ops' Already fixed in Linus's tree. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 9106] Sun Fire v100 dmfe driver bug
From: Grant Grundler [EMAIL PROTECTED] Date: Tue, 22 Jan 2008 23:19:50 -0700 On Mon, Jan 21, 2008 at 11:27:56PM -0800, David Miller wrote: BTW, I noticed this while reading the DMFE code: db-buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4, db-buf_pool_dma_ptr); That size looks strange, is this supposed to be: (TX_BUF_ALLOC * TX_DESC_CNT) + 4 or: TX_BUF_ALLOC * (TX_DESC_CNT + 4) I think the latter is the intention, but the former is what is actually happening. Note the same thing is happening in the pci_free_consistent call. After looking the code a bit, my guess would be the former was intended. I suspect this driver once suffered from alignment issues: /* pointer for memory physical address */ dma_addr_t buf_pool_dma_ptr;/* Tx buffer pool memory */ dma_addr_t buf_pool_dma_start; /* Tx buffer pool align dword */ ... and I'm going a bit out on a limb here by guessing this line: db-buf_pool_dma_start = db-buf_pool_dma_ptr; might used to read something like: db-buf_pool_dma_start = db-buf_pool_dma_ptr ~3ULL; or two lines: db-buf_pool_dma_start = db-buf_pool_dma_ptr; db-buf_pool_dma_ptr = ~3ULL; to guarantee the DMA pool had a 4-byte alignment. So I think the +4 can just be dropped. Great, since we are guarenteed at least PAGE_SIZE alignment from these allocations. Maybe time to orphan the driver or find a new maintainer? It's a simple enough driver that if I had some cards I would be willing to keep an eye on it. Anyways, here is a fix for the above regression, if that DMA sizing error above is a real one that will need a fix too: [TULIP] DMFE: Fix SROM parsing regression. Changeset 16b110c3fd760620b4a787db6ed512fe531ab1b5 (dmfe warning fix) bothed up the offsets read from the SROM so that it doesn't read the same datums it used to. In case it matters, looks good to me. Thanks for reviewing. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sparc64: fix section error in sparcspkr
From: Sam Ravnborg [EMAIL PROTECTED] Date: Mon, 21 Jan 2008 22:50:36 +0100 With a sparc64 defconfig modified to set CONFIG_HOTPLUG=n the following error happened during link of vmlinux: local symbol 0: discarded in section `.devexit.text' from drivers/built-in.o local symbol 1: discarded in section `.devexit.text' from drivers/built-in.o (The error message above is from kbuild.git but it happens in mainline too) The error happens becase there is a reference from .text/.data to a function marked __devexit. With CONFIG_HOTPLUG=n all code marked __devexit are discarded and the linker complains. It was tracked down to sparcspkr.c which were missing __devexit_p() around the function pointers. Unfortunately modpost did not catch this since modpost do not warn about references from .data to .devexit from variables named *_driver. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Applied, thanks Sam. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [SPARC/64] remove of_platform_device_create
From: Stephen Rothwell [EMAIL PROTECTED] Date: Wed, 16 Jan 2008 16:54:19 +1100 There are no callers of this on the Sparc platforms. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Thanks Stephen, I'll apply this. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gettimeofday not monotonous on sun4m
From: Martin Habets [EMAIL PROTECTED] Date: Sun, 13 Jan 2008 14:51:20 + It almost works. Reaching the l10 limit does not indicate a second overflow, but rather 10 milliseconds. I actually checked in a fixed version which properly divided by HZ. Thanks. I can still make it fail on SMP, gettimeofday is always off by 10 milliseconds. do_gettimeofday() uses read_seqbegin_irqsave(). This blocks the l10 interrupt from being taken on the local CPU, but I think it will just get taken on the other CPU. In essence xtime and l10_counter are not guaranteed to be consistent on all CPUs. This means the update code isn't taking the seqlock as a writer as it needs to. Try adding that. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc oops in ip_fast_csum
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 14 Jan 2008 07:09:22 +0100 But I agree to your suggestion, that will allow us to properly handle packets with IP options. I'll take care of this. Thanks a lot Patrick. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compile-time error with gcc-4.3 on sparc64
From: David Martin [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 10:31:45 +0100
Please report sparc problems to the Sparc mailing list,
sparclinux@vger.kernel.org, thanks.
I get the following error compiling latest kernel from git on sparc64
using gcc-4.3:
CC arch/sparc64/kernel/signal.o
cc1: warnings being treated as errors
arch/sparc64/kernel/signal.c: En la función 'do_notify_resume':
include/asm/uaccess.h:233: error: el subíndice de la matriz está por
arriba de los límites de la matriz
make[1]: *** [arch/sparc64/kernel/signal.o] Error 1
make: *** [arch/sparc64/kernel] Error 2
(On function 'do_notify resume: error: matrix subindex is over matrix
limits)
I think you mean array instead of matrix in your translation.
In fact, you should rerun should build failures with LANG=C
for the benefit of people reading your report.
Something is very wrong with the compiler, do_notify_resume() reads:
void do_notify_resume(struct pt_regs *regs, unsigned long orig_i0, int
restart_syscall,
unsigned long thread_info_flags)
{
if (thread_info_flags (_TIF_SIGPENDING | _TIF_RESTORE_SIGMASK))
do_signal(regs, orig_i0, restart_syscall);
}
uaccess.h, line 233 is:
static inline unsigned long __must_check
copy_to_user(void __user *to, const void *from, unsigned long size)
{
unsigned long ret = ___copy_to_user(to, from, size);
copy_to_user() isn't being called in do_notify_resume() at all.
Perhaps it's probably warning about some call to copy_to_user() that
results from the inline expansion of do_signal() and all sub-calls.
But it's a bug that GCC isn't indicating exactly where the problem is,
and in what specific function. My guess is that it's losing context
during all of the inline expansions.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gettimeofday not monotonous on sun4m
From: Martin Habets [EMAIL PROTECTED]
Date: Sun, 6 Jan 2008 22:40:13 +
The microseconds are determined by:
(xtime.tv_nsec / 1000) + (l10_counter 10)
I dumped both variables with a simple kernel module (first 2 attachments),
which shows that xtime is monotonous, but l10_counter looks random to me.
I do not know the problem here, and cannot find details on the operation
of this counter property on sun4m. Maybe this l10_counter needs to be
callibrated?
I understand from include/asm-sparc/timer.h that l10_counter should count
down on sun4m, which makes the current code all the more puzzling.
Actually, the l10_counter counts up in microseconds. When the
l10_counter equals l10_limit an interrupt is generated.
Those values that look random to you have bit 31 set for some
reason.
Clear that bit and the values look much more sane.
I couldn't find my old STP1040 et al manuals so I took a look
at the OpenBSD sparc code. It masks the shifted value with
0x1f and has a note in one of it's header files mentioning
that bit 0x8000 in the counter register means the counter
has hit the limit and the interrupt hasn't been cleared yet
(which is done by reading the limit register).
We are masking like that so this aspect is fine.
But it is that case with the 0x8000 bit being set that
is causing the problems.
It means an interrupt is pending and the counter wraps back
down to the beginning and starts to count from zero again.
When the interrupt is serviced, xtime would get advanced
forward.
We need to integrate that pending interrupt event into
the calculations.
Please try this patch:
diff --git a/arch/sparc/kernel/time.c b/arch/sparc/kernel/time.c
index 45cb7c5..ccd2ed5 100644
--- a/arch/sparc/kernel/time.c
+++ b/arch/sparc/kernel/time.c
@@ -436,7 +436,14 @@ void __init time_init(void)
static inline unsigned long do_gettimeoffset(void)
{
- return (*master_l10_counter 10) 0x1f;
+ unsigned long val = *master_l10_counter;
+ unsigned long usec = (val 10) 0x1f;
+
+ /* Limit hit? */
+ if (val 0x8000)
+ usec += 100;
+
+ return usec;
}
/* Ok, my cute asm atomicity trick doesn't work anymore.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc64: ultra 60 fails to boot with 64kB pages
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Wed, 9 Jan 2008 20:14:16 +0100 So ... am I doing something wrong here or something is broken? I know that non-8K page sizes are broken but haven't had time to go fix it, sorry. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.24-rc7: sparc64: WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Tue, 8 Jan 2008 19:42:16 +0100 Hello, Got this when doing usual looping over /proc entries on fresh test kernel: WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show() Call Trace: [00492704] lockdep_stats_show+0x6ac/0x6c0 [004eb4b4] seq_read+0x5c/0x340 [0050b2bc] proc_reg_read+0x64/0xa0 [004cd72c] vfs_read+0x74/0x120 [004cdb4c] sys_read+0x34/0x60 [004062d4] linux_sparc_syscall32+0x3c/0x40 [00012ff4] 0x12ffc Please turn off lockdep on sparc64, currently it not reliable. I have many things to audit, including how the stack frames are presented to the lockdep layer. So any problem you run into can be due to issues like that. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.24-rc7: sparc64: WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
From: Ingo Molnar [EMAIL PROTECTED] Date: Tue, 8 Jan 2008 23:56:31 +0100 is this anything the core lockdep code could help improve? Let us know if any aspect is hindering you. No, it's a sparc64 issue. Another problem I ran into are the huge static table sizes lockdep uses. They really need to be either made smaller or dynamically allocated. Sparc64 has hard limitations on kernel size (due to firmware and bootloader issues) and I hit these limits if I am not careful on SMP with lockdep enabled. Andi Kleen and I discussed in a thread several weeks ago. I believe Andi even came up with a suggested direction to fix this. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1: sparc64: undefined reference to `vmemmap_table'
From: Andrew Morton [EMAIL PROTECTED] Date: Sun, 6 Jan 2008 02:15:54 -0800 On Sun, 6 Jan 2008 11:03:02 +0100 Mariusz Kozlowski [EMAIL PROTECTED] wrote: This is from allnoconfig on sparc64: LD .tmp_vmlinux1 arch/sparc64/kernel/head.o: In function `kvmap_vmemmap': (.text+0x34ec): undefined reference to `vmemmap_table' arch/sparc64/kernel/head.o: In function `kvmap_vmemmap': (.text+0x34f4): undefined reference to `vmemmap_table' Happens in mainline too. Maybe arch/sparc64/kernel/ktlb.S needs to be taught about CONFIG_SPARSEMEM_VMEMMAP=n. It's pointless to support this thing being off. If possible I'd like a method to force it always to be enabled and I'll look into doing that. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: Adrian Bunk [EMAIL PROTECTED] Date: Sat, 29 Dec 2007 01:22:56 +0200 At least the sunserial_console_match() one is an obvious Oops (EXPORT_SYMBOL of an __init function). The comment in the description of commit 58d784a5c754cd66ecd4791222162504d3c16c74 the warning was bogus is bullshit. I'm not sure whether this might count as a 2.6.24-rc regression or whether 2.6.23 is simply differently but similarly broken (does anyone actually use the Sun console drivers modular?). You can't do that, the FOO_CONSOLE config options depend upon FOO=y. That's why I'm not worried about this issue and it's not critical at all. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: David Miller [EMAIL PROTECTED] Date: Sat, 29 Dec 2007 00:14:11 -0800 (PST) You can't do that, the FOO_CONSOLE config options depend upon FOO=y. That's why I'm not worried about this issue and it's not critical at all. Adrian, if you're interested in tackling this fun problem, have a look at add_preferred_console() and find a way to make that not marked __init. (it's called by sunserial_console_match) That's what causes this dependency chain of __init problems for the Sun serial console drivers. It's problematic, furthermore, because even if one could call add_preferred_console() from a module properly, it doesn't have the desired effect of changing init's stdin/stdout/stderr - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: Adrian Bunk [EMAIL PROTECTED] Date: Sat, 29 Dec 2007 10:48:46 +0200 On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote: That's why I'm not worried about this issue and it's not critical at all. If a module calls sunserial_console_match() that's an Oops. That's true. I'm trying to figure out a way to fix this. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Wed, 26 Dec 2007 13:29:07 +0100 WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to .init.text:sun4v_ktsb_register (between 'smp_callin' and 'smp_fill_in_sib_core_maps') Well known and I see them every build and so does everyone else on sparc64. They are harmless and as time allows I try to find ways to get rid of them but it's very low priority. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Stefan Richter [EMAIL PROTECTED]
Date: Wed, 19 Dec 2007 17:33:05 +0100
Does arch/sparc64/kernel/pci.c fill them in incorrectly or too late?
The problem is that I created indirection that was totally unused, the
operation vectors members for these cases thus didn't get filled in,
and we OOPS trying to call NULL pointers as functions :-)
This should fix the crash:
diff --git a/include/asm-sparc64/dma-mapping.h
b/include/asm-sparc64/dma-mapping.h
index 1fc6554..38cbec7 100644
--- a/include/asm-sparc64/dma-mapping.h
+++ b/include/asm-sparc64/dma-mapping.h
@@ -25,15 +25,9 @@ struct dma_ops {
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction);
- void (*sync_single_for_device)(struct device *dev,
- dma_addr_t dma_handle, size_t size,
- enum dma_data_direction direction);
void (*sync_sg_for_cpu)(struct device *dev, struct scatterlist *sg,
int nelems,
enum dma_data_direction direction);
- void (*sync_sg_for_device)(struct device *dev, struct scatterlist *sg,
- int nelems,
- enum dma_data_direction direction);
};
extern const struct dma_ops *dma_ops;
@@ -105,7 +99,7 @@ static inline void dma_sync_single_for_device(struct device
*dev,
size_t size,
enum dma_data_direction direction)
{
- dma_ops-sync_single_for_device(dev, dma_handle, size, direction);
+ /* No flushing needed to sync cpu writes to the device. */
}
static inline void dma_sync_single_range_for_cpu(struct device *dev,
@@ -123,7 +117,7 @@ static inline void dma_sync_single_range_for_device(struct
device *dev,
size_t size,
enum dma_data_direction
direction)
{
- dma_sync_single_for_device(dev, dma_handle+offset, size, direction);
+ /* No flushing needed to sync cpu writes to the device. */
}
@@ -138,7 +132,7 @@ static inline void dma_sync_sg_for_device(struct device
*dev,
struct scatterlist *sg, int nelems,
enum dma_data_direction direction)
{
- dma_ops-sync_sg_for_device(dev, sg, nelems, direction);
+ /* No flushing needed to sync cpu writes to the device. */
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/sparc64/: Spelling fixes
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 17 Dec 2007 11:30:22 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/sparc/: Spelling fixes
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 17 Dec 2007 11:30:21 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Thu, 20 Dec 2007 20:47:55 +0100 [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC: 005119b0 Y: Not tainted [ 145.128940] TPC: kpagecount_read+0x94/0xe0 My suspicion at this point is that with certain RAM layouts, simply iterating over PFN's is simply not working out. pfn_to_page() seems to be doing no range checking, and with sparsemem vmemmap, which sparc64 always uses, this can be problematic. It just blindly goes vmemmap + pfn which is asking for trouble, in particular when the physical RAM layout really is sparse. Maybe it's enough to add a pfn_valid() check here? If pfn_valid() means there is a vmemmap translation setup for that page struct too, it would work. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags
From: Matt Mackall [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 19:06:55 -0600
@@ -707,7 +707,10 @@ static ssize_t kpagecount_read(struct fi
return -EIO;
while (count 0) {
- ppage = pfn_to_page(pfn++);
+ ppage = 0;
+ if (pfn_valid(pfn))
+ ppage = pfn_to_page(pfn);
+ pfn++;
if (!ppage)
pcount = 0;
else
Yes that should work, please use NULL in the final
version of the patch instead of 0 so that sparse is
happy.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Stefan Richter [EMAIL PROTECTED] Date: Wed, 19 Dec 2007 17:33:05 +0100 drivers/firewire/fw_ohci.c needs them for dma_map_single() + dma_sync_single_for_device() in the pci_driver.probe(), sometime after it called pci_enable_device(), before finishing the probe. I'll take a look at this and try to figure out exactly what might be going wrong. The dev_archdata should be fully setup at this time. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sparc64] 2.6.23.x kernel and udev on U2E
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 09:33:46 +0100 If I restart udev, it is restarted without any timeout. I don't understand where is the mistake (PCI support ?). It seems to be a bad interaction between udev and kernel but I don't know the last configuration where kernel and udev work fine together. I have trie to find an old configuration that boots without this timeout without any success. I don't understand why with exactly the same .config I cannot see the same trouble on my U60. Probably something unique about the ESP scsi driver, although I have no idea what that might be. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Stefan Richter [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 11:38:27 +0100 Also note: - The very same code did not oops at this point in 2.6.22. It only started doing so in 2.6.23. 2.6.23 is when the sparc64 IOMMU code started relying upon the dev_archdata bits being correct. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Stefan Richter [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 11:38:27 +0100 - There has been no other report of this kind for any other architecture yet. I would expect e.g. the PPC64 folks to report bugs in our dma mappings eventually. Irrelevant fact, powerpc handles it's dev_archdata differently from sparc64. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc64 with 32-bit user-space context switching question
From: Mikael Pettersson [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 13:06:55 +0100 My main question is: what does the kernel do to the high 32 bits of the 64-bit integer registers during context switches? Only %oX and %gX registers have the full 64-bit preserved across context switches for 32-bit processes. The %lX and %iX registers cannot have their full 64-bits preserved because the amount of save space is fixed by the register window save area layout on the stack, which only saves 32-bit values for each register. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sparc64 with 32-bit user-space context switching question
From: Mikael Pettersson [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 13:06:55 +0100 Also, does anyone know what Solaris does to the high 32 bits during context switches? Solaris handles things identically to Linux. These rules are even encoded into places like the GCC backend for sparc, when generating v9 code for 32-bit. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
From: Chris Newport [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 02:58:29 + (GMT) On Tue, 18 Dec 2007, Stefan Richter wrote: It's a 100% reproducible oops on Sparc (with FireWire controller) for 2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that the bug also happens How do you achieve a sparc system with firewire ? AFAIK there is no SBUS firewire card. He means sparc64, which have PCI firewire onboard many systems. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 17:05:55 +0100 Tested - the patch seems to fix the problem as the machine is still alive and working well after several hours of running the buggy aptitude -u in a loop. I'll leave the kernel running and make sure the machine gets some more users and load during the next days. Thanks for testing, let me know if any more issues trigger. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 22:17:07 +0100
the v880 (4x US III) here was hit by a stuck process again, after
running fine for some time now. But the machine didn't freeze, one CPU
was running at 100%, but otherwise the machine was responsible.
In your dump all of the cpus seem to be alive and healthy, and
thus able to receive cpu messages, yet we are stuck on one cpu
in cheetah_xcall_deliver().
I suspect that the code in cheetah_xcall_deliver() can get into an
endless loop because of the way it interprets the dispatch status
register.
For example, if there are stray BUSY or NACK bits set in that register
for processors we are not trying to send a message to (for example,
from a previous message send) the logic can clear all the bits in the
cpu mask and then endlessly cycle in that function because no new
messages are sent and therefore no forward progress is made. The
cycle repeats forever.
I shoule be easily fixed using the patch below. It records which bits
we should actually be concerned about, and only tests those specific
bits in the dispatch status register.
Could you please give this patch a test?
Thanks.
diff --git a/arch/sparc64/kernel/smp.c b/arch/sparc64/kernel/smp.c
index 894b506..c399449 100644
--- a/arch/sparc64/kernel/smp.c
+++ b/arch/sparc64/kernel/smp.c
@@ -476,7 +476,7 @@ static inline void spitfire_xcall_deliver(u64 data0, u64
data1, u64 data2, cpuma
*/
static void cheetah_xcall_deliver(u64 data0, u64 data1, u64 data2, cpumask_t
mask)
{
- u64 pstate, ver;
+ u64 pstate, ver, busy_mask;
int nack_busy_id, is_jbus, need_more;
if (cpus_empty(mask))
@@ -508,14 +508,20 @@ retry:
i (ASI_INTR_W));
nack_busy_id = 0;
+ busy_mask = 0;
{
int i;
for_each_cpu_mask(i, mask) {
u64 target = (i 14) | 0x70;
- if (!is_jbus)
+ if (is_jbus) {
+ busy_mask |= (0x1UL (i * 2));
+ } else {
target |= (nack_busy_id 24);
+ busy_mask |= (0x1UL
+ (nack_busy_id * 2));
+ }
__asm__ __volatile__(
stxa %%g0, [%0] %1\n\t
membar #Sync\n\t
@@ -531,15 +537,16 @@ retry:
/* Now, poll for completion. */
{
- u64 dispatch_stat;
+ u64 dispatch_stat, nack_mask;
long stuck;
stuck = 10 * nack_busy_id;
+ nack_mask = busy_mask 1;
do {
__asm__ __volatile__(ldxa [%%g0] %1, %0
: =r (dispatch_stat)
: i (ASI_INTR_DISPATCH_STAT));
- if (dispatch_stat == 0UL) {
+ if (!(dispatch_stat (busy_mask | nack_mask))) {
__asm__ __volatile__(wrpr %0, 0x0, %%pstate
: : r (pstate));
if (unlikely(need_more)) {
@@ -556,12 +563,12 @@ retry:
}
if (!--stuck)
break;
- } while (dispatch_stat 0xUL);
+ } while (dispatch_stat busy_mask);
__asm__ __volatile__(wrpr %0, 0x0, %%pstate
: : r (pstate));
- if ((dispatch_stat ~(0xUL)) == 0) {
+ if (dispatch_stat busy_mask) {
/* Busy bits will not clear, continue instead
* of freezing up on this cpu.
*/
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Sat, 08 Dec 2007 01:14:46 +0100 works well, thanks for fixing! Thanks a lot for testing. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-mm1: some issues on sparc64
From: Andrew Morton [EMAIL PROTECTED] Date: Sat, 8 Dec 2007 10:22:39 -0800 That's J_ASSERT_BH(bh, !buffer_jbddirty(bh)); at the end of journal_unmap_buffer(). I don't recall seeing that before and I can't think of anything we've done recently which could cause it, sorry. If the per-cpu data patches are in the -mm tree that is the first place I would start looking at for possible cause. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Thu, 06 Dec 2007 13:09:18 +0100
ERROR(0): Cheetah error trap taken afsr[1000]
afar[040001c0] TL1(0)
ERROR(0): TPC[4351dc] TNPC[4351e0] O7[4353b4] TSTATE[80001606]
ERROR(0): TPCinterpret_one_decode_reg+0x0/0xfc
ERROR(0): M_SYND(0), E_SYND(0)
Please try this patch:
commit 980a9fd582ee9ac6729d6f0ac19ce21ca55aa401
Author: David S. Miller [EMAIL PROTECTED]
Date: Fri Dec 7 00:58:55 2007 -0800
[SPARC64]: Fix memory controller register access when non-SMP.
get_cpu() always returns zero on non-SMP builds, but we
really want the physical cpu number in this code in order
to do the right thing.
Based upon a non-SMP kernel boot failure report from Bernd Zeimetz.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/arch/sparc64/kernel/chmc.c b/arch/sparc64/kernel/chmc.c
index 777d345..6d4f02e 100644
--- a/arch/sparc64/kernel/chmc.c
+++ b/arch/sparc64/kernel/chmc.c
@@ -1,7 +1,6 @@
-/* $Id: chmc.c,v 1.4 2002/01/08 16:00:14 davem Exp $
- * memctrlr.c: Driver for UltraSPARC-III memory controller.
+/* memctrlr.c: Driver for UltraSPARC-III memory controller.
*
- * Copyright (C) 2001 David S. Miller ([EMAIL PROTECTED])
+ * Copyright (C) 2001, 2007 David S. Miller ([EMAIL PROTECTED])
*/
#include linux/module.h
@@ -16,6 +15,7 @@
#include linux/init.h
#include asm/spitfire.h
#include asm/chmctrl.h
+#include asm/cpudata.h
#include asm/oplib.h
#include asm/prom.h
#include asm/io.h
@@ -242,8 +242,11 @@ int chmc_getunumber(int syndrome_code,
*/
static u64 read_mcreg(struct mctrl_info *mp, unsigned long offset)
{
- unsigned long ret;
- int this_cpu = get_cpu();
+ unsigned long ret, this_cpu;
+
+ preempt_disable();
+
+ this_cpu = real_hard_smp_processor_id();
if (mp-portid == this_cpu) {
__asm__ __volatile__(ldxa [%1] %2, %0
@@ -255,7 +258,8 @@ static u64 read_mcreg(struct mctrl_info *mp, unsigned long
offset)
: r (mp-regs + offset),
i (ASI_PHYS_BYPASS_EC_E));
}
- put_cpu();
+
+ preempt_enable();
return ret;
}
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Fri, 16 Nov 2007 22:17:07 +0100 The sysrq-g output is attached, I hope you can make sense out of it. We'll also add some extra workload to the other machines here to try to trigger the bug on other CPUs, too. I just got back from my vacation and started looking at these dumps. I think there might be some bug in cheetah_xcall_deliver(), I'll try to diagnose this some more. If you cannot reproduce this bug on non-Ultra-III systems that would help confirm or deny my theory. Have you been able to trigger this on your Ultra-II machine for example? If so, what do the sysrq-g traces look like there? - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Thu, 06 Dec 2007 11:43:45 +0100 David Miller wrote: From: Bernd Zeimetz [EMAIL PROTECTED] Date: Fri, 16 Nov 2007 22:17:07 +0100 The sysrq-g output is attached, I hope you can make sense out of it. We'll also add some extra workload to the other machines here to try to trigger the bug on other CPUs, too. I just got back from my vacation and started looking at these dumps. I think there might be some bug in cheetah_xcall_deliver(), I'll try to diagnose this some more. I'm not sure if it is related, but non-SMP Kernels don't boot at all on the machine. I doubt it's related as non-SMP kernels won't even have that code compiled in :-) What does a failed non-SMP boot say? If it doesn't even bring up the console, give it -p on the kernel command line. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Aurora SPARC Linux Build 2.99 (Beta 2 for 3.0)
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Sat, 01 Dec 2007 13:43:30 +0100 - Systems that boot off qlogic attached disks are not supported, because there is no working firmware loader in anaconda, and the qlogic driver needs firmware. That's very unfortunate, how are qlogic device handled on other platforms? In Debian you just install the firmware package, udevl will handle it then. If you have to boot from it, you need to rebuild your initrd after installing the firmware package. The installer doesn't support non-free modules yet unfortunately, but with some not too complicated tricks you can install Debian without problems. I said other platforms as in x86, x86_64, powerpc. I know debian can do it, as I run ubuntu on most of my qlogic based sparc64 systems just fine. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/59] arch/sparc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 23:48:36 -0800 On Mon, 2007-11-19 at 23:45 -0800, David Miller wrote: From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:58 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Please check your patches, for trailing white space. Adds trailing whitespace. diff:10:prom_printf(PCIC: Error, cannot map Adds trailing whitespace. diff:19:prom_printf(PCIC: Error, cannot map warning: 2 lines add whitespace errors. I've fixed it up this time. It doesn't add whitespace, but it does keep the trailing whitespace that's already there. I know that, you should still do sanity checks and fix these kinds of things up because they trigger errors in my patch applying scripts and that of many other developers. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SPARC64: check for possible NULL pointer dereference
From: Cyrill Gorcunov [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 20:28:33 +0300 From: Cyrill Gorcunov [EMAIL PROTECTED] This patch adds checking for possible NULL pointer dereference if of_find_property() failed. Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Minor cleanups of the sparc serial drivers
From: Martin Habets [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 02:10:15 + This patch against 2.6.23 sparc-2.6.git contains a number of minor cleanups of the sparc serial drivers. Initially I fixed this build warning: WARNING: vmlinux.o(.text+0x107a2c): Section mismatch: reference to .init.text:add_preferred_console (between 'sunserial_console_match' and 'sunserial_console_termios') which is done by declaring sunserial_console_match() as __init. I haven't touched this known problem because I think it's legitimate to register serial consoles from a module, yet the current console layer doesn't allow it. I can't think of a clean way to make add_preferred_console() non-init so I'll likely apply your patch. Thanks! - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Icedtea for Linux_sparc
From: Tom \spot\ Callaway [EMAIL PROTECTED] Date: Tue, 13 Nov 2007 13:46:22 -0500 On Tue, 2007-11-06 at 10:12 -0500, Scot P. Floess wrote: Not sure as icedtea took care of whatever downloads it required... The only requirement I saw was the latest RH gcj with generics extension... When I installed this under Fedora 7 - its just downloaded and built everything it needed. I looked into this, and there is definitely missing code. Everything in openjdk/hotspot/src/os_cpu/linux_sparc/vm/* would need to be written. I don't know SPARC asm, so I can't do this work. (CCing [EMAIL PROTECTED], in the hopes that someone there might be interested in writing this code) I'll see if I can devote some cycles to this when I get back from my trip to Korea. I had looked briefly at this earlier and I have a decent idea of what's involved, in fact the most difficult part is getting a build going, the number of dependencies is just rediculious. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Fri, 16 Nov 2007 22:17:07 +0100 first the good news: The U60 here still building and working fine, also I didn't hear any bad news from lebrun.d.o. the not so good news: the v880 (4x US III) here was hit by a stuck process again, after running fine for some time now. But the machine didn't freeze, one CPU was running at 100%, but otherwise the machine was responsible. I think I'll also run a full diag in service mode to make it's not a CPU bug. The sysrq-g output is attached, I hope you can make sense out of it. We'll also add some extra workload to the other machines here to try to trigger the bug on other CPUs, too. I'll look into this when I get a chance, thanks for the report. I'm leaving for a 2 week trip on Wednesday, so I might not be able to look into this until early December. Thanks. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/59] arch/sparc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:58 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Please check your patches, for trailing white space. Adds trailing whitespace. diff:10:prom_printf(PCIC: Error, cannot map Adds trailing whitespace. diff:19:prom_printf(PCIC: Error, cannot map warning: 2 lines add whitespace errors. I've fixed it up this time. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/59] arch/sparc64: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:59 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vmstat: Small revisions to refresh_cpu_vm_stats()
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 03:37:55 -0800
: undefined reference to `__xchg_called_with_bad_pointer'
This is sparc64's way of telling you that you can'd do xchg on an s8.
Dave, is that fixable?
I assume not, in which case we either go for some open-coded implementation
for 8- and 16-bits or we should ban (at compile time) 8- and 16-bit xchg on
all architectures.
Right, let's write some generic code for this because other platforms
are going to need this too.
Basically, do a normal ll/sc or load/cas sequence on a u32 with
some shifting and masking as needed.
int shift = (((unsigned long) addr) % 4) * 8;
unsigned long mask = 0xff shift;
unsigned long val = newval shift;
u32 *ptr = (u32 *) ((unsigned long)addr ~0x3UL);
while (1) {
u32 orig, tmp = *ptr;
orig = tmp;
tmp = ~mask;
tmp |= val;
cmpxchg_u32(ptr, orig, tmp);
if (orig == tmp)
break;
}
Repeat for u16, etc.
However, for platforms like sparc32 that can do a xchg() atomically
but can't do cmpxchg, this idea won't work :-/
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Wed, 07 Nov 2007 15:35:42 +0100 But I did the artificial tests, like running dpkg-query --search libc.so.6 in loops, and this seems to work well. Thanks a lot! I was running aptitude -u in a loop for half an hour now, and it didn't crash, so I assume that fixed the bug. Many thanks for the patch David! Many thanks for helping me track it down. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Andrew Morton [EMAIL PROTECTED] Date: Fri, 9 Nov 2007 12:22:08 -0800 I tagged this as needed-in-2.6.23.x. Please let me know if that is not appropriate. It is. I have it queued up for -stable already. I'm just waiting for it Linus to get back from wherever he has been the past few days so he can suck it in and it's upstream before I submit it to -stable. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Wed, 07 Nov 2007 15:35:42 +0100 But I did the artificial tests, like running dpkg-query --search libc.so.6 in loops, and this seems to work well. Thanks a lot! I was running aptitude -u in a loop for half an hour now, and it didn't crash, so I assume that fixed the bug. Many thanks for the patch David! Many thanks for testing :-) - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Tue, 06 Nov 2007 04:51:07 +0100 Here's also some output from apt-get which got stuck in my unstable chroot while I wanted to retrieve the klibc source to try to debug it... So the good news is that I started getting the hang seen on the Debain buildd on my workstation. The bad news is that it's very sporadic, for a while I could trigger it during bootup, on every boot, and now I can't get it to wedge at all. Anyways, we're getting closer. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix for sparc64 cpu hangs.
[ Bernd, Josip, and Fabio, I think I finally nailed this
cpu hang bug we were all seeing on sparc64. ]
[FUTEX]: Fix address computation in compat code.
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').
Things explode if the 32-bit sign bit is set in futex_offset.
Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.
This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().
Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.
Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bits clear.
Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():
1) load from address '0xf7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
for address '0xf7f16bd8' which succeeds
3) goto #1
I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index 00b5726..8089e7e 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -76,11 +76,16 @@ void compat_exit_robust_list(struct task_struct *curr)
* A pending lock might already be on the list, so
* dont process it twice:
*/
- if (entry != pending)
- if (handle_futex_death((void __user *)entry +
futex_offset,
- curr, pi))
- return;
+ if (entry != pending) {
+ void __user *uaddr;
+ compat_uptr_t base;
+
+ base = ptr_to_compat(entry);
+ uaddr = compat_ptr(base + futex_offset);
+ if (handle_futex_death(uaddr, curr, pi))
+ return;
+ }
if (rc)
return;
uentry = next_uentry;
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for sparc64 cpu hangs.
From: David Miller [EMAIL PROTECTED]
Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST)
[FUTEX]: Fix address computation in compat code.
Sorry, I just noticed there is a second handle_futex_death()
call in compat_exit_robust_list() which has the same
address computation bug.
Here is an updated patch:
[FUTEX]: Fix address computation in compat code.
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').
Things explode if the 32-bit sign bit is set in futex_offset.
Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.
This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().
Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.
Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.
Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():
1) load from address '0xf7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
for address '0xf7f16bd8' which succeeds
3) goto #1
I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index 00b5726..1931457 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -30,6 +30,15 @@ fetch_robust_entry(compat_uptr_t *uentry, struct robust_list
__user **entry,
return 0;
}
+static void __user *futex_uaddr(struct robust_list *entry,
+ compat_long_t futex_offset)
+{
+ compat_uptr_t base = ptr_to_compat(entry);
+ void __user *uaddr = compat_ptr(base + futex_offset);
+
+ return uaddr;
+}
+
/*
* Walk curr-robust_list (very carefully, it's a userspace list!)
* and mark any locks found there dead, and notify any waiters.
@@ -76,11 +85,13 @@ void compat_exit_robust_list(struct task_struct *curr)
* A pending lock might already be on the list, so
* dont process it twice:
*/
- if (entry != pending)
- if (handle_futex_death((void __user *)entry +
futex_offset,
- curr, pi))
- return;
+ if (entry != pending) {
+ void __user *uaddr = futex_uaddr(entry,
+futex_offset);
+ if (handle_futex_death(uaddr, curr, pi))
+ return;
+ }
if (rc)
return;
uentry = next_uentry;
@@ -94,9 +105,11 @@ void compat_exit_robust_list(struct task_struct *curr)
cond_resched();
}
- if (pending)
- handle_futex_death((void __user *)pending + futex_offset,
- curr, pip);
+ if (pending) {
+ void __user *uaddr = futex_uaddr(pending, futex_offset);
+
+ handle_futex_death(uaddr, curr, pip);
+ }
}
asmlinkage long
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/12] arch/sparc: Remove duplicate includes.
From: Lucas Woods [EMAIL PROTECTED] Date: Tue, 06 Nov 2007 07:15:22 +1100 Signed-off-by: Lucas Woods [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Josip Rodin [EMAIL PROTECTED] Date: Fri, 2 Nov 2007 17:21:06 +0100 Great. Here you go, three of them, while the load was 3 and this process was stuck: buildd 10813 100 0.8 987368 17504 ?RN 14:44 155:49 dpkg-query --search libpthread.so.0 libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libc.so.6 libFLAC.so.8 libid3tag.so.0 libz.so.1 libmad.so.0 libglib-2.0.so.0 libmikmod.so.2 libsndfile.so.1 libvorbis.so.0 libogg.so.0 libvorbisfile.so.3 ... Nov 2 17:02:04 lebrun kernel: CPU[ 0]: TSTATE[80009604] TPC[00407924] TNPC[00407928] TASK[dpkg-query:10813] Nov 2 17:02:04 lebrun kernel: TPC[sparc64_realfault_common+0x8/0x20] It looks like dpkg_query is stuck on a page fault. Typically this means the fault processing is not putting a valid translation into the TLB to satisfy the fault, so we loop forever never making forward progress. I've had to debug something similar to this before, so I'll piece together a debugging patch you can use to get more information. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Sun, 04 Nov 2007 20:55:20 +0100 So I'm not sure if the result is really useful for you - if not just let me know. I've attached the last ~10-20 sysrq-g outputs - as it was running in a loop I have a ton of them. In case you're wondering: http is aptitude's http method. The http module is stuck in a different place, I'll try to see if I can make sense of it. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 02 Nov 2007 16:37:25 +0100
I've sent g several times to sysrq, output is attached.
According to top the two hanging aptitude processes were running on CPU
1 + 3.
3204 root 20 0 19552 5088 4072 R 100 0.1 6:54.49 1 aptitude
3203 root 20 0 19552 5088 4072 R 100 0.1 6:56.39 3 aptitude
Ok, the key in the trace is:
Nov 2 16:25:30 titan kernel: [ 978.134874] CPU[ 1]:
TSTATE[80009603] TPC[0067d2e0] TNPC[0067d2d4]
TASK[aptitude:3204]
Nov 2 16:25:30 titan kernel: [ 978.257809]
TPC[_write_unlock_irq+0x20/0x110]
...
Nov 2 16:25:30 titan kernel: [ 978.507778] CPU[ 3]:
TSTATE[11009605] TPC[004419f8] TNPC[004419fc]
TASK[aptitude:3203]
Nov 2 16:25:30 titan kernel: [ 978.630707]
TPC[cheetah_xcall_deliver+0x174/0x23c]
The first symbol is misleading, it says _write_unlock_irq but actually
in the assembler the PC is in the spinlock read spinning loop
section. So actually it's hanging in _spin_lock().
CPU #3 is trying to send a cross-call message interrupt, but for
some reason that isn't making forward progress.
Let's see what's calling these things by adding some more debugging
information. Please retry the test with the following patch on
top of the original sysrq-g debugging patch and please get new
logs when it hangs.
Thanks!
--- arch/sparc64/kernel/process.c.ORIG 2007-11-03 20:53:27.0 -0700
+++ arch/sparc64/kernel/process.c 2007-11-03 21:05:47.0 -0700
@@ -49,6 +49,7 @@
#include asm/hypervisor.h
#include asm/sstate.h
#include asm/irq_regs.h
+#include asm/smp.h
/* #define VERBOSE_SHOWREGS */
@@ -394,7 +395,11 @@ struct global_reg_snapshot {
unsigned long tstate;
unsigned long tpc;
unsigned long tnpc;
+ unsigned long o7;
+ unsigned long i7;
struct thread_info *thread;
+ unsigned long pad1;
+ unsigned long pad2;
} global_reg_snapshot[NR_CPUS];
static DEFINE_SPINLOCK(global_reg_snapshot_lock);
@@ -413,6 +418,8 @@ static void sysrq_handle_globreg(int key
global_reg_snapshot[cpu].tstate = regs-tstate;
global_reg_snapshot[cpu].tpc = regs-tpc;
global_reg_snapshot[cpu].tnpc = regs-tnpc;
+ global_reg_snapshot[cpu].o7 = regs-u_regs[UREG_I7];
+ global_reg_snapshot[cpu].i7 = 0;
} else {
global_reg_snapshot[cpu].tstate = 0;
global_reg_snapshot[cpu].tpc = 0;
@@ -432,9 +439,19 @@ static void sysrq_handle_globreg(int key
((tp tp-task) ? tp-task-comm : NULL),
((tp tp-task) ? tp-task-pid : -1));
#ifdef CONFIG_KALLSYMS
- if ((gp-tstate TSTATE_PRIV) (gp-tpc != 0UL)) {
- sprint_symbol(buffer, gp-tpc);
- printk( TPC[%s]\n, buffer);
+ if (gp-tstate TSTATE_PRIV) {
+ if (gp-tpc != 0UL) {
+ sprint_symbol(buffer, gp-tpc);
+ printk( TPC[%s]\n, buffer);
+ }
+ if (gp-o7 != 0UL) {
+ sprint_symbol(buffer, gp-o7);
+ printk( O7[%s]\n, buffer);
+ }
+ if (gp-i7 != 0UL) {
+ sprint_symbol(buffer, gp-i7);
+ printk( I7[%s]\n, buffer);
+ }
}
#endif
}
--- arch/sparc64/mm/ultra.S.ORIG2007-11-03 20:53:27.0 -0700
+++ arch/sparc64/mm/ultra.S 2007-11-03 20:57:12.0 -0700
@@ -528,7 +528,7 @@ xcall_fetch_glob_regs:
sethi %hi(global_reg_snapshot), %g1
or %g1, %lo(global_reg_snapshot), %g1
__GET_CPUID(%g2)
- sllx%g2, 5, %g3
+ sllx%g2, 6, %g3
add %g1, %g3, %g1
rdpr%tstate, %g7
stx %g7, [%g1 + 0x00]
@@ -536,12 +536,14 @@ xcall_fetch_glob_regs:
stx %g7, [%g1 + 0x08]
rdpr%tnpc, %g7
stx %g7, [%g1 + 0x10]
+ stx %o7, [%g1 + 0x18]
+ stx %i7, [%g1 + 0x20]
sethi %hi(trap_block), %g7
or %g7, %lo(trap_block), %g7
sllx%g2, TRAP_BLOCK_SZ_SHIFT, %g2
add %g7, %g2, %g7
ldx [%g7 + TRAP_PER_CPU_THREAD], %g3
- stx %g3, [%g1 + 0x18]
+ stx %g3, [%g1 + 0x28]
retry
#ifdef DCACHE_ALIASING_POSSIBLE
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: unkillable dpkg-query processes
From: David Miller [EMAIL PROTECTED] Date: Thu, 01 Nov 2007 15:01:13 -0700 (PDT) I'm working on a kernel patch for 2.6.23 that will allow you to get some useful debugging information in situations like this. I'll try to get you that patch by the end of tonight. As promised, here is the patch below. To trigger the debugging log, simple give the console a Alt-SysRQ then a g. On a serial console you can do this by giving a single BREAK then a g. If you're having trouble triggering the sysrq on the console, try instead: bash# echo g /proc/sysrq-trigger Here is some sample output from my Niagara-2 system while running a benchmark. The current CPU is denoted by the leading * character. [81940.250994] SysRq : Show Global CPU Regs [81940.251800] * CPU[ 0]: TSTATE[e2001602] TPC[0055813c] TNPC[00558140] TASK[dd:2940] [81940.252206] TPC[NGbzero_loop+0x1c/0x38] [81940.252422] CPU[ 1]: TSTATE[004411001607] TPC[0055c9bc] TNPC[0055c9c0] TASK[dd:2926] [81940.252739] TPC[atomic_sub_ret+0x4/0x30] [81940.252936] CPU[ 2]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2899] [81940.253238] TPC[NG2copy_to_user+0x46c/0x680] [81940.253451] CPU[ 3]: TSTATE[e2001602] TPC[00558130] TNPC[00558134] TASK[dd:2929] [81940.253776] TPC[NGbzero_loop+0x10/0x38] [81940.253993] CPU[ 4]: TSTATE[e2001602] TPC[00558124] TNPC[00558128] TASK[dd:2947] [81940.254325] TPC[NGbzero_loop+0x4/0x38] [81940.254497] CPU[ 5]: TSTATE[004411001606] TPC[00495f94] TNPC[00495f98] TASK[dd:2908] [81940.254893] TPC[do_generic_mapping_read+0xbc/0x428] [81940.255203] CPU[ 6]: TSTATE[11001607] TPC[0055fee8] TNPC[0055feec] TASK[dd:2920] [81940.255699] TPC[NG2copy_to_user+0x468/0x680] [81940.256104] CPU[ 7]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2935] [81940.256574] TPC[NG2copy_to_user+0x46c/0x680] [81940.256972] CPU[ 8]: TSTATE[e2001602] TPC[00558124] TNPC[00558128] TASK[dd:2903] [81940.257399] TPC[NGbzero_loop+0x4/0x38] [81940.257899] CPU[ 9]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2904] [81940.258240] TPC[NG2copy_to_user+0x46c/0x680] [81940.258482] CPU[ 10]: TSTATE[e2001602] TPC[00558138] TNPC[0055813c] TASK[dd:2902] [81940.258808] TPC[NGbzero_loop+0x18/0x38] [81940.258999] CPU[ 11]: TSTATE[e2001602] TPC[00558120] TNPC[00558124] TASK[dd:2941] [81940.259319] TPC[NGbzero_loop+0x0/0x38] [81940.259487] CPU[ 12]: TSTATE[e2001602] TPC[00558130] TNPC[00558134] TASK[dd:2919] [81940.259801] TPC[NGbzero_loop+0x10/0x38] [81940.260012] CPU[ 13]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2950] [81940.260350] TPC[NG2copy_to_user+0x46c/0x680] [81940.260564] CPU[ 14]: TSTATE[e2001602] TPC[00558134] TNPC[00558138] TASK[dd:2936] [81940.260937] TPC[NGbzero_loop+0x14/0x38] [81940.261150] CPU[ 15]: TSTATE[11001607] TPC[0055fee8] TNPC[0055feec] TASK[dd:2905] [81940.261457] TPC[NG2copy_to_user+0x468/0x680] [81940.261677] CPU[ 16]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2923] [81940.261973] TPC[NG2copy_to_user+0x46c/0x680] [81940.262167] CPU[ 17]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2897] [81940.262462] TPC[NG2copy_to_user+0x46c/0x680] [81940.262643] CPU[ 18]: TSTATE[e2001602] TPC[00558128] TNPC[0055812c] TASK[dd:2909] [81940.262987] TPC[NGbzero_loop+0x8/0x38] [81940.263180] CPU[ 19]: TSTATE[11001607] TPC[0055fee8] TNPC[0055feec] TASK[dd:2913] [81940.263500] TPC[NG2copy_to_user+0x468/0x680] [81940.263901] CPU[ 20]: TSTATE[e2001602] TPC[00558128] TNPC[0055812c] TASK[dd:2890] [81940.264403] TPC[NGbzero_loop+0x8/0x38] [81940.264679] CPU[ 21]: TSTATE[11001607] TPC[0055fee8] TNPC[0055feec] TASK[dd:2906] [81940.265152] TPC[NG2copy_to_user+0x468/0x680] [81940.265535] CPU[ 22]: TSTATE[11001607] TPC[0055feec] TNPC[0055fef0] TASK[dd:2918] [81940.266075] TPC[NG2copy_to_user+0x46c/0x680] [81940.266448] CPU[ 23]: TSTATE[11001607] TPC[0055fee8] TNPC[0055feec] TASK[dd:2900] [81940.266942] TPC[NG2copy_to_user+0x468/0x680] [81940.267328] CPU[ 24]: TSTATE[11001602] TPC[0049a618] TNPC[0049a61c] TASK[dd:2938] [81940.267710] TPC
Re: unkillable dpkg-query processes
From: Josip Rodin [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 00:37:13 +0100 I'd try doing a debootstrap of lenny (that's Debian testing), and then inside it, run one or more of those 'dpkg-query -S libc.so.6'. Thanks for the info. While waiting for you to reply I created a lenny buildd build root on my SunFire 280R using: debootstrap --variant=buildd lenny /org/buildd/chroots/lenny \ http://mirrors.kernel.org/debian basically following roughly the instructions at: http://www.debian.org/devel/buildd/setting-up And then once chroot'ed into the lenny build root you have to setup a few manual things like /proc, /sys/, and /dev/pts mounts for anything to work: chroot /org/buildd/chroots/lenny mount -t proc none /proc mount -t sysfs none /sys mount -t devpts none /dev/pts So, it's a lot more than just running the appropriate debootstrap command. I have done a GCC package build and am now running a libc6 build under this lenny chroot and haven't hit any problems yet. This is with a stock 2.6.23.1 kernel. BTW, in your buildroot, can you do something like: strace -o x.log dpkg-query -S libc.so.6 and send me that x.log file? That might give some important clues. Thanks. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 01:50:30 +0100 What we're missing here is a probably important piece: If dpkg-query is running during a build, it is running in a fakeroot environment. I've straced that, see the attachment. What I find in the strace are at least several clones, which is the point where aptitude -u crashed according to the straces in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433187#102 Thanks for the fakeroot trace. I am pretty sure the clone()'s we see here are just normal fork()'s, in both the fakeroot's dpkg-query and the aptitude case. I'll go study up on fakeroot's implementation to look for potential clues. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 01:47:33 +0100 mount -t devpts none /dev/pts mount --bind /dev /thechroot/dev is what I use here, running udev in a chroot is no fun. Ok. I'm almost done with a howto which is cutpaste for 95% to debootstrap and boot a debian system, unfortunately it doesn't boot as the klibc (which is used in the initramfs) is broken on sparc again... So I'll modify it to setup a proper chroot only, it should also allow to boot into it if you use the Kernel/initrd form Ubuntu. This should allow Josip and you to setup a complete chroot. Thanks. I have done a GCC package build and am now running a libc6 build under this lenny chroot and haven't hit any problems yet. The following things also like to crash here (on Etch, not in a chroot): - running aptitude -u several times (at least with libnss-db installed) - since I've installed 2.6.24-rc1: vgdisplay (with and without active libnss-db) There are several issues with 2.6.24, stay away from it for now. I will fix things there. Let's stick to 2.6.23 testing for pinpointing these bugs. there're some comparisons of the strace of aptitude -u in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433187#102 Probably interesting as there're futexes in the game. Of course there are, as soon as you start using libnss-db there will be futexes. Can you reproduce the aptitute problems under 2.6.23 with libnss-db disabled? The interesting thing is that it didn't crash the machine while running under strace. If the futex problem I suspect is in fact the issue, strace'ing would definitely make that problem go away. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 02:54:14 +0100 Ok. Do you have a .deb with a kernel for me? If not - would you like to have any specific options enabled - I have to build one then. I usually just cp arch/sparc64/defconfig ./.config in a fresh vanilla kernel tree and tweak from there. For my 280R I enabled SMP, accepted the NR_CPUS default value (64), set SERIAL_SUNSAB to y and enabled console support, and then enabled the qlogic fibrechannel driver and the SUNGEM driver as modules. Oh yes, I also enabled INITRD support so I can use initramfs to get the firmware loaded properly in the qlogic FC card. Really, I don't use anything fancy, just enough to get the machine functional. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: tcp rfc 2385 security/bugfix for sparc64
From: Matthias Dellweg [EMAIL PROTECTED] Date: Tue, 16 Oct 2007 18:47:56 +0200 while reviewing the tcp_md5-related code further i came across with another two of these casts which you probably have missed. I don't actually think that they impose a problem by now, but as you said we should remove them. I'll apply this patch, thanks Matthias. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Mon, 29 Oct 2007 02:18:30 +0100 But if this bug isn't fixed chances are good that the next Debian release won't support Sparc at all. Please don't use pseudo-threats like this, it only deters me even more from working on this bug. This explains why you have trouble to reproduce this, while Josip and me get hit by this bug way too often. Josip stated explicitly that he has a SunFire280R, which disagrees with what you're saying here. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Mon, 29 Oct 2007 03:06:13 +0100 David Miller wrote: Josip stated explicitly that he has a SunFire280R, which disagrees with what you're saying here. Sorry, I mixed something up here. I was somehow sure that they were using a v440, but it was somebody else. Ok, since I have a 280R just like Josip, I think a good plan is for him to show me the commands he used to create the build root where he can trigger bad things. I think we can move forward much better starting with this. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Sun, 28 Oct 2007 04:03:44 +0100 I think things got worse with 2.6.24... The machine shoots itself now, I guess by running cron jobs or so. [29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC: 0042f928 Y: Not tainted [29074.884191] TPC: sched_clock+0x0/0x30 What kind of OOPS is this? Please provide the kernel log messages that appeared right before these register dumps. Thanks. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sat, 27 Oct 2007 20:09:47 +0200
titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s!
[aptitude:13375]
[ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC:
0042f7d0 Y: Not tainted
[ 2427.506821] TPC: __delay+0x1c/0x48
[ 2427.549494] g0: 9000 g1: 0042f7d0 g2:
g3:
[ 2427.653670] g4: f8a00793c960 g5: f89fff994000 g6: f8a007dfc000
g7:
[ 2427.757835] o0: 0020 o1: 0020 o2:
o3:
[ 2427.862001] o4: 0030a0d0 o5: sp: f8a007dff071
ret_pc: 0042f938
[ 2427.970337] RPC: __delay+0x18/0x48
[ 2428.013031] l0: 0005a6cab647 l1: 11009601 l2: 004417a8
l3: 0400
[ 2428.117206] l4: l5: 0001 l6:
l7: 0008
[ 2428.221374] i0: i1: f8a007dffa88 i2: 0004
i3: 0001
[ 2428.325538] i4: i5: i6: f8a007dff131
i7: 004417ec
[ 2428.429710] I7: cheetah_xcall_deliver+0x1c0/0x23c
and an unkillable, cpu-eating aptitude.
One cpu can't send a message successfully to another cpu, likely
because it is stuck somewhere with interrupts off.
I was going to give you a patch like the one at the end of this email
to try and get a register dump from all cpus with Alt-Sysrq-p but that
is guarenteed not to work. It will just call back into
cheetah_xcall_deliver() and wedge further. Again, don't use the
patch, trying to get a register dump with it in this state will just
wedge the machine further.
I don't know how to suggest a way to debug this further, sorry.
I'm sick of these bugs and I need to reproduce all of these
UltraSPARC-III issues locally to fix them. So let's go.
Everyone who sees these UltraSPARC-III problems please send me PRECISE
and FULL description of how to install from scratch a machine and run
something that will trigger these errors.
DO NOT leave out any detail of your installation. Any minor omission
will mean that I potentially won't be able to reproduce this bug and
therefore I won't be able to fix it either.
If you are using NIS, say so and give the exact configuration. If you
have any modifications to some core configuration file like
/etc/nsswitch.conf, tell me. If you are using static IP addresses,
tell me. If you have netfilter enabled, tell me. If you have even
installed some extra package, like libnss-db or anything else, tell me
even if you think it's not in use.
In short I want a flawless cook-book style recipe for installing a
machine that I can reproduce this problem on. Do not omit any detail.
Thanks!
diff --git a/arch/sparc64/kernel/process.c b/arch/sparc64/kernel/process.c
index ca7cdfd..e10fdce 100644
--- a/arch/sparc64/kernel/process.c
+++ b/arch/sparc64/kernel/process.c
@@ -348,7 +348,7 @@ void show_regs(struct pt_regs *regs)
extern long etrap, etraptl1;
#endif
__show_regs(regs);
-#if 0
+#if 1
#ifdef CONFIG_SMP
{
extern void smp_report_regs(void);
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: possible typo in arch/sparc64/kernel/time.c
From: Roel Kluin [EMAIL PROTECTED] Date: Sat, 27 Oct 2007 17:25:51 +0200 I already posted something on lkml, but it wasn't picked up in arch/sparc64/kernel/time.c, line 1073 it reads: if (!mregs !dregs !bregs) shouldn this be if (!mregs !dregs !bregs) Yep, thanks I'll fix it up. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Bernd Zeimetz [EMAIL PROTECTED] Date: Fri, 26 Oct 2007 14:30:21 +0200 at least it runs with 100% CPU, attaching strace to the pid doesn't give any results strace-ing the whole process doesn't result in more useful output, but the hanging processes were killable when they were running under strace... When it runs with 100% CPU that's what makes me suspect it's spinning in the kernel futex code somewhere or similar. One thing I notice in the debian bug report is a mention of libnss-db So I did some testing here and without libnss-db installed, running dpkg-query does not use futexes at all. But once I install libnss-db and enable it (by running 'make' under /var/lib/misc then editing /etc/nsswitch.conf to make 'db' get searched first) indeed dpkg-query starts using futexes via the libnss-db library. Josip, do you guys have libnss-db or similar in use on the buildd machine? For those who can reproduce it an have something like libnss-db enabled, try disabling it. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
Josip, give this debugging patch a try. It is against 2.6.23.1
but it should apply to most recent kernels.
It should give you debugging messages in the kernel log that
start with FUTEX_BUG if the debugging code triggers.
Please post just a few samples of whatever it spits out.
Thanks!
diff --git a/kernel/futex.c b/kernel/futex.c
index fcc94e7..6da8b3c 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1874,6 +1874,25 @@ err_unlock:
return ret;
}
+static void log_futex_bug(u32 __user *uaddr, struct task_struct *curr, int pi)
+{
+ struct mm_struct *mm = curr-mm;
+ struct vm_area_struct *vma;
+ unsigned long addr;
+
+ printk(KERN_ERR FUTEX_BUG: Looping too much in futex death\n);
+ printk(KERN_ERR FUTEX_BUG: uaddr[%p] task[%s:%d] pi(%d)\n,
+ uaddr, curr-comm, curr-pid, pi);
+
+ addr = (unsigned long) uaddr;
+ vma = find_vma(mm, addr);
+ if (vma)
+ printk(KERN_ERR FUTEX_BUG: VMA start[%lx] end[%lx]
flags[%lx]\n,
+ vma-vm_start,
+ vma-vm_end,
+ vma-vm_flags);
+}
+
/*
* Process a futex-list entry, check whether it's owned by the
* dying task, and do notification if so:
@@ -1881,6 +1900,7 @@ err_unlock:
int handle_futex_death(u32 __user *uaddr, struct task_struct *curr, int pi)
{
u32 uval, nval, mval;
+ int limit = 0;
retry:
if (get_user(uval, uaddr))
@@ -1903,8 +1923,12 @@ retry:
if (nval == -EFAULT)
return -1;
- if (nval != uval)
- goto retry;
+ if (nval != uval) {
+ if (++limit 100)
+ goto retry;
+ log_futex_bug(uaddr, curr, pi);
+ put_user(mval, uaddr);
+ }
/*
* Wake robust non-PI futexes here. The wakeup of
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch/sparc64/kernel/iommu_common.c:237: error: implicit declaration of function 'next_sg'
From: Josip Rodin [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 23:11:02 +0200
Hi,
Just tried 2.6.24-rc1... but:
arch/sparc64/kernel/iommu_common.c: In function 'prepare_sg':
arch/sparc64/kernel/iommu_common.c:237: error: implicit declaration of
function 'next_sg'
cc1: warnings being treated as errors
arch/sparc64/kernel/iommu_common.c:237: warning: assignment makes pointer
from integer without a cast
make[1]: *** [arch/sparc64/kernel/iommu_common.o] Error 1
The error looks like a simple typo - should this be sg_next(), like
elsewhere in the file? It compiles the file when I replace that.
Yep, I tossed that fix to Jens last night, it should show up
in Linus's tree soon:
diff --git a/arch/sparc64/kernel/iommu_common.c
b/arch/sparc64/kernel/iommu_common.c
index b70324e..efd5dff 100644
--- a/arch/sparc64/kernel/iommu_common.c
+++ b/arch/sparc64/kernel/iommu_common.c
@@ -234,7 +234,7 @@ unsigned long prepare_sg(struct scatterlist *sg, int nents)
dma_sg-dma_length = dent_len;
if (dma_sg != sg) {
- dma_sg = next_sg(dma_sg);
+ dma_sg = sg_next(dma_sg);
dma_sg-dma_length = 0;
}
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unkillable dpkg-query processes
From: Josip Rodin [EMAIL PROTECTED] Date: Thu, 25 Oct 2007 00:33:32 +0200 We've been having grave issues with a few of our sparc build daemon machines in Debian. Something causes dpkg-query(8) processes, otherwise harmless, to run amok and allocate too much memory, but keep running and become resilient to killing. They eventually push the machine to the point where you can only ping it, but all the userland and the console is dead. I know, I've seen this report a million times :-) I can't reproduce it, I've even tried the fabled test case where you spawn thousands of dpkg-query instances and it never does anything wrong on my Niagara boxes. So something is different about your environment than mine. Let's see if there is some aspect of the environment that contributed to the problem occurring. Please reproduce with 2.6.23-final and then list (I know this is redundant, just humor me :-): 1) system type 2) compiler used to build kernel and is it SMP? 3) glibc in use 4) compiler used to build running glibc If you have a reproducable test case, that's even better. If necessary I'll try to install a replica of your build environment here in order to reproduce. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Raid1/5 over iSCSI trouble
From: Dan Williams [EMAIL PROTECTED] Date: Wed, 24 Oct 2007 16:49:28 -0700 Hopefully it is as painless to run on sparc as it is on IA: opcontrol --start --vmlinux=/path/to/vmlinux wait opcontrol --stop opreport --image-path=/lib/modules/`uname -r` -l It is painless, I use it all the time. The only caveat is to make sure the /path/to/vmlinux is the pre-stripped kernel image. The images installed under /boot/ are usually stripped and thus not suitable for profiling. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sparc64: pass correct addr in get_fb_unmapped_area(MAP_FIXED)
From: Chris Wright [EMAIL PROTECTED] Date: Tue, 23 Oct 2007 15:50:38 -0700 Looks like the MAP_FIXED case is using the wrong address hint. I'd expect the comment don't mess with it means pass the request straight on through, not change the address requested to -ENOMEM. Signed-off-by: Chris Wright [EMAIL PROTECTED] --- BTW, just noticed by random code inspection, perhaps I've missed something. Looks entirely like a correct fix to me, applied. Thanks! - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: David Miller [EMAIL PROTECTED] Date: Wed, 17 Oct 2007 04:22:29 -0700 (PDT) From: Michael Ellerman [EMAIL PROTECTED] Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST) Use of_get_pci_dev_node() in axon_msi.c. Switch to including linux/of.h so we get the prototype. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] I find it ironic that you add of_get_pci_dev_node() as a function which gets the node and grabs a reference to it, and then the very first usage you make of it doesn't drop the reference at all. Ignore this poor attempt at humor, I misread your patch :) - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.
Better late than never...
Ok, I think I nailed this, the simplest test case is:
register unsigned long regval asm(g5);
extern void cond_resched(void);
unsigned int var;
void *expression(unsigned long regval)
{
void *ret;
__asm__( : =r (ret) : 0 (var));
return ret + regval;
}
void func(void **pp)
{
int i;
for (i = 0; i 56; i++) {
cond_resched();
*pp = expression(regval);
}
}
If you build that with gcc-4.2 -m64 -Os -S -o test.s test.c
the compiler moves expression() outside of the loop because it
things it is invariant.
The dataflow pass doesn't mark global registers correctly, and
the new thing in gcc-4.2.x vs. gcc-4.1.x is that it uses the
dataflow pass for the loop optimizers.
I've bootstrapped and regression tested the following gcc-4.2.x
patch, I'll test some test kernel builds after I get some sleep.
--- ./gcc/df-scan.c.ORIG2007-10-16 02:07:46.0 -0700
+++ ./gcc/df-scan.c 2007-10-16 23:00:32.0 -0700
@@ -1584,12 +1584,19 @@ df_insn_refs_record (struct dataflow *df
so they are recorded as used. */
for (i = 0; i FIRST_PSEUDO_REGISTER; i++)
if (global_regs[i])
- df_uses_record (dflow, regno_reg_rtx[i],
- DF_REF_REG_USE, bb, insn,
- 0);
+ {
+ df_uses_record (dflow, regno_reg_rtx[i],
+ DF_REF_REG_USE, bb, insn, 0);
+ df_ref_record (dflow, regno_reg_rtx[i], regno_reg_rtx[i],
+ bb, insn, DF_REF_REG_DEF, 0, true);
+ }
+
EXECUTE_IF_SET_IN_BITMAP (df_invalidated_by_call, 0, ui, bi)
- df_ref_record (dflow, regno_reg_rtx[ui], regno_reg_rtx[ui],
bb,
- insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER, false);
+ {
+ if (!global_regs[ui])
+ df_ref_record (dflow, regno_reg_rtx[ui],
regno_reg_rtx[ui], bb,
+ insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER,
false);
+ }
}
}
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Q] iSCSI on sparc64
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Tue, 16 Oct 2007 15:29:27 +0200 lot of messages like : Kernel unaligned access at TPC[1016b334] set_offset_and_length+0xdc/0x1a0 [iscsi_trgt] The iSCSI code makes unaligned accesses for the data types being dereferenced, and needs to be fixed. I don't have the resources to do any of this work, please report the problem to the iSCSI people. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sun4v_data_access_exception on new 2.6.23
From: BERTRAND_Joël [EMAIL PROTECTED] Date: Fri, 12 Oct 2007 09:04:16 +0200 Writing inode tables: Kernel unaligned access at TPC[56004c] xor_niagara_4+0x5c/0x128 sun4v_data_access_exception: ADDR[0053d354] CTX[] TYPE[000a], going. Please try this patch: diff --git a/arch/sparc64/lib/xor.S b/arch/sparc64/lib/xor.S index a79c888..f44f58f 100644 --- a/arch/sparc64/lib/xor.S +++ b/arch/sparc64/lib/xor.S @@ -491,12 +491,12 @@ xor_niagara_4:/* %o0=bytes, %o1=dest, %o2=src1, %o3=src2, %o4=src3 */ ldda[%i1 + 0x10] %asi, %i2 /* %i2/%i3 = src1 + 0x10 */ xor %g2, %i4, %g2 xor %g3, %i5, %g3 - ldda[%i7 + 0x10] %asi, %i4 /* %i4/%i5 = src2 + 0x10 */ + ldda[%l7 + 0x10] %asi, %i4 /* %i4/%i5 = src2 + 0x10 */ xor %l0, %g2, %l0 xor %l1, %g3, %l1 stxa%l0, [%i0 + 0x00] %asi stxa%l1, [%i0 + 0x08] %asi - ldda[%i6 + 0x10] %asi, %g2 /* %g2/%g3 = src3 + 0x10 */ + ldda[%l6 + 0x10] %asi, %g2 /* %g2/%g3 = src3 + 0x10 */ ldda[%i0 + 0x10] %asi, %l0 /* %l0/%l1 = dest + 0x10 */ xor %i4, %i2, %i4 @@ -504,12 +504,12 @@ xor_niagara_4:/* %o0=bytes, %o1=dest, %o2=src1, %o3=src2, %o4=src3 */ ldda[%i1 + 0x20] %asi, %i2 /* %i2/%i3 = src1 + 0x20 */ xor %g2, %i4, %g2 xor %g3, %i5, %g3 - ldda[%i7 + 0x20] %asi, %i4 /* %i4/%i5 = src2 + 0x20 */ + ldda[%l7 + 0x20] %asi, %i4 /* %i4/%i5 = src2 + 0x20 */ xor %l0, %g2, %l0 xor %l1, %g3, %l1 stxa%l0, [%i0 + 0x10] %asi stxa%l1, [%i0 + 0x18] %asi - ldda[%i6 + 0x20] %asi, %g2 /* %g2/%g3 = src3 + 0x20 */ + ldda[%l6 + 0x20] %asi, %g2 /* %g2/%g3 = src3 + 0x20 */ ldda[%i0 + 0x20] %asi, %l0 /* %l0/%l1 = dest + 0x20 */ xor %i4, %i2, %i4 @@ -517,12 +517,12 @@ xor_niagara_4:/* %o0=bytes, %o1=dest, %o2=src1, %o3=src2, %o4=src3 */ ldda[%i1 + 0x30] %asi, %i2 /* %i2/%i3 = src1 + 0x30 */ xor %g2, %i4, %g2 xor %g3, %i5, %g3 - ldda[%i7 + 0x30] %asi, %i4 /* %i4/%i5 = src2 + 0x30 */ + ldda[%l7 + 0x30] %asi, %i4 /* %i4/%i5 = src2 + 0x30 */ xor %l0, %g2, %l0 xor %l1, %g3, %l1 stxa%l0, [%i0 + 0x20] %asi stxa%l1, [%i0 + 0x28] %asi - ldda[%i6 + 0x30] %asi, %g2 /* %g2/%g3 = src3 + 0x30 */ + ldda[%l6 + 0x30] %asi, %g2 /* %g2/%g3 = src3 + 0x30 */ ldda[%i0 + 0x30] %asi, %l0 /* %l0/%l1 = dest + 0x30 */ prefetch[%i1 + 0x40], #one_read - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
