RE: [PATH] Reduce per_cpu allocations to minimum needed for bootV3.
Would you mind putting in the patch as it was with 32? I'll put in th V5 version that you just posted ... but this does need some more cleanup. For the hotplug path we should try to allocate both the per-cpu area and the MCA stack space *before* we try to bring the cpu online (i.e. allocation done by some existing cpu ... not by the cpu itself). For the boot time path it is probably fine to just assume that allocations will work (and panic if they don't). Anyone that tries to bring up 1024 cpus on a 512MB system deserves to see a panic :-) -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/kernel/entry.S |5 +-
arch/ia64/kernel/mca.c | 55
arch/ia64/kernel/perfmon.c | 21 +-
arch/ia64/kernel/process.c | 59 +
arch/ia64/kernel/ptrace.c | 139
include/asm-ia64/ptrace.h | 11 +++
include/asm-ia64/thread_info.h | 11 ++-
include/asm-ia64/unistd.h |5 +-
8 files changed, 225 insertions(+), 81 deletions(-)
Petr Tesarik (3):
[IA64] Rename TIF_PERFMON_WORK back to TIF_NOTIFY_RESUME
[IA64] Synchronize kernel RSE to user-space and back
[IA64] Synchronize RBS on PTRACE_ATTACH
Russ Anderson (1):
[IA64] Fix large MCA bootmem allocation
Tony Luck (2):
[IA64] Wire up timerfd_{create,settime,gettime} syscalls
[IA64] Simplify cpu_idle_wait
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATH] Reduce per_cpu allocations to minimum needed for boot V3.
This patch could be using the cpu_possible_map instead of our own. I was reluctant to do that, but there is nothing that prevents it. Does anybody have an opinion? I hate to see duplication ... your new early_cpu_possible_map should just end up with the same contents as cpu_possible_map ... won't it? Is there some downside to using your new code to initialize the existing cpu_possible_map? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATH] Reduce per_cpu allocations to minimum needed for bootV3.
Not that I can think of. The early_cpu_possible_map will be a superset
of the cpu_possible_map.
It might be a bigger superset than we'd like ... I'm not sure if there
are any hard rules about how SRAT tables are populated. W.r.t. memory
the entries tend to be broad: If there is any memory in this range, then
it belongs to this node. Perhaps cpu entries may exist in the SRAT
without much regard to whether than can actually exist on the platform
that we are executing on.
But perhaps this is enough to solve the worst parts of the problem
here. Small platforms will only populate SRAT out as far as they
run their product line (32, 64, 128 cpus) ... so a kernel configured
for 4096 cpus would at least limit the wasted allocations to this
figure ... which is still a giant step forward.
If the machine does not have numa acpi
information, we will default to (currently 4 cpus) and initialize those
on node 0. We will then later only set the actual number in the
cpu_possible_map. There would be nothing (other than the lacking
hardware) which differentiates these processors from ones in the
cpu_possible_map. If you would like to go with the cpu_possible_map, I
will happily do some testing with that over the weekend.
Could I get some direction on the number of cpus to define when there
are no numa tables? Do you know what the hardware limitation is for
number of processors on a FSB?
The entries here are logical cpus, yes? So with Mont{ecito,vale} 4
sockets on the FSB * 2 cores * 2 threads = 16.
I'm not sure that I understand the problems if we have too low a figure
here. Will we:
1) crash
2) fail to use the cpus extra cpus
3) something else
Looking further ahead ... a single node Tukwila will could have four
sockets * 4 cores * 2 threads = 32.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Multiple outstanding ptc.g instructions support
I made a few changes to this:
1) Updated w.r.t. latest kernel (mostly due to cleanups in efi.c)
2) Dropped the palinfo.c piece that provided the PALO values for
number of purges. I think that /proc/pal/cpu*/* should just
return the values that PAL provides. If we need to provide an
API to get at the PALO values, then a new interface is needed
(/proc/pal/palo perhaps?)
3) Removed some global variables.
4) Added code to act on max_purge values found from PAL_VM_SUMMARY.
This got a bit messy. See setup_ptcg_sem() in arch/ia64/mm/tlb.c,
suggestions on how to make this simpler gratefully received.
-Tony
---
commit bf454b2d048f7fd27cb834af87806c85a760d60c
Author: Fenghua Yu [EMAIL PROTECTED]
Date: Thu Feb 7 12:59:04 2008 -0800
[IA64] Multiple outstanding ptc.g instruction support
According to SDM2.2, Itanium supports multiple outstanding ptc.g
instructions.
But current kernel function ia64_global_tlb_purge() uses a spinlock to
serialize
ptc.g instructions issued by multiple processors. This serialization might
have
scalability issue on a big SMP machine where many processors could purge TLB
in parallel.
The patch fixes this problem by issuing multiple ptc.g instructions in
ia64_global_tlb_purge(). It also adds support for the PALO table to get
a platform view of the max number of outstanding ptc.g instructions (which
may be different from the processor view found from PAL_VM_SUMMARY).
PALO specification can be found at:
http://www.dig64.org/home/DIG64_PALO_R1_0.pdf
Signed-off-by: Fenghua Yu [EMAIL PROTECTED]
Signed-off-by: Tony Luck [EMAIL PROTECTED]
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 919070a..5ce6523 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -37,6 +37,7 @@
#include asm/pgtable.h
#include asm/processor.h
#include asm/mca.h
+#include asm/tlbflush.h
#define EFI_DEBUG 0
@@ -403,6 +404,41 @@ efi_get_pal_addr (void)
return NULL;
}
+
+static u8 __init palo_checksum(u8 *buffer, u32 length)
+{
+ u8 sum = 0;
+ u8 *end = buffer + length;
+
+ while (buffer end)
+ sum = (u8) (sum + *(buffer++));
+
+ return sum;
+}
+
+/*
+ * Parse and handle PALO table which is published at:
+ * http://www.dig64.org/home/DIG64_PALO_R1_0.pdf
+ */
+static void __init handle_palo(unsigned long palo_phys)
+{
+ struct palo_table *palo = __va(palo_phys);
+ u8 checksum;
+
+ if (strncmp(palo-signature, PALO_SIG, sizeof(PALO_SIG) - 1)) {
+ printk(KERN_INFO PALO signature incorrect.\n);
+ return;
+ }
+
+ checksum = palo_checksum((u8 *)palo, palo-length);
+ if (checksum) {
+ printk(KERN_INFO PALO checksum incorrect.\n);
+ return;
+ }
+
+ setup_ptcg_sem(palo-max_tlb_purges, 1);
+}
+
void
efi_map_pal_code (void)
{
@@ -432,6 +468,7 @@ efi_init (void)
u64 efi_desc_size;
char *cp, vendor[100] = unknown;
int i;
+ unsigned long palo_phys;
/*
* It's too early to be able to use the standard kernel command line
@@ -496,6 +533,8 @@ efi_init (void)
efi.hcdp = EFI_INVALID_TABLE_ADDR;
efi.uga= EFI_INVALID_TABLE_ADDR;
+ palo_phys = EFI_INVALID_TABLE_ADDR;
+
for (i = 0; i (int) efi.systab-nr_tables; i++) {
if (efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID) == 0) {
efi.mps = config_tables[i].table;
@@ -515,10 +554,17 @@ efi_init (void)
} else if (efi_guidcmp(config_tables[i].guid, HCDP_TABLE_GUID)
== 0) {
efi.hcdp = config_tables[i].table;
printk( HCDP=0x%lx, config_tables[i].table);
+ } else if (efi_guidcmp(config_tables[i].guid,
+PROCESSOR_ABSTRACTION_LAYER_OVERWRITE_GUID) == 0) {
+ palo_phys = config_tables[i].table;
+ printk( PALO=0x%lx, config_tables[i].table);
}
}
printk(\n);
+ if (palo_phys != EFI_INVALID_TABLE_ADDR)
+ handle_palo(palo_phys);
+
runtime = __va(efi.systab-runtime);
efi.get_time = phys_get_time;
efi.set_time = phys_set_time;
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index ebd1a09..93ce69d 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -59,6 +59,7 @@
#include asm/setup.h
#include asm/smp.h
#include asm/system.h
+#include asm/tlbflush.h
#include asm/unistd.h
#include asm/hpsim.h
@@ -946,9 +947,10 @@ cpu_init (void)
#endif
/* set ia64_ctx.max_rid to the maximum RID that is supported by all
CPUs: */
- if (ia64_pal_vm_summary(NULL, vmi) == 0)
+ if (ia64_pal_vm_summary(NULL, vmi) == 0) {
max_ctx = (1U (vmi.pal_vm_info_2_s.rid_size - 3)) - 1;
- else {
+
RE: git pull on ia64 linux tree
Any reason the various ptrace bits are not included in this pull? The ptrace bits depend upon some generic changes to add arch_ptrace_stop() ... I think Andrew included them as part 89/260 of today's early morning mail patch bomb. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] kprobes: kprobe-booster for ia64
+/* Insert a long branch code */
+static void __kprobes set_brl_inst(void *from, void *to)
+{
+ s64 rel = ((s64) to - (s64) from) 4;
+ bundle_t *brl;
+ brl = (bundle_t *) ((u64) from ~0xf);
+ brl-quad0.template = 0x05; /* [MLX](stop) */
+ brl-quad0.slot0 = NOP_M_INST; /* nop.m 0x0 */
+ brl-quad0.slot1_p0 = ((rel 20) 0x7f) 2;
+ brl-quad1.slot1_p1 = (((rel 20) 0x7f) 2) (64 - 46);
+ /* brl.cond.sptk.many.clr rel4 (qp=0) */
+ brl-quad1.slot2 = BRL_INST(rel 59, rel 0xf);
+}
Is this function operating directly on the instruction bundle in the
kernel code? If so, the bundle will contain some interesting
intermediate values as each of the brl-xxx = yyy; are processed.
If another cpu should try to execute this bundle while the modifications
are in progress, then the results will be not what you want.
On cpu models that support st16 you could construct the brl instruction
and use a single st16 to update the whole bundle atomically.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] Fix large MCA bootmem allocation
Is panic the only choice here? It seems unfriendly to panic just because we can't successfully add a new CPU. It'd be nicer to somehow make the addition fail so the new CPU is just not usable. The current code sequence is: start_secondary - cpu_init - ia64_mca_cpu_init and the memory allocation here happens very late in the sequence ... so it it fails we'd have to do a lot of work to back out. Moving the ia64_mca_cpu_init() much earlier would help some ... but we don't currently have a graceful failure path if anything goes wrong. The new cpu has already been passed from SAL control to OS control ... so we'd have to pass it back again. There are probably a whole host of potential failures in this code path that ought to be checked but currently aren't because all these routines were written to be called once at boot time when memory allocations hardly ever fail (and it they do, panic is perhaps the best answer). The liklihood of this particular allocation failing goes up as the configured pagesize is reduced. With the default 64k, the allocation is order=1 ... but with a 4k page we need an order=4 allocation to succeed. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] Fix large MCA bootmem allocation
Given that ia64_mca_cpu_init() does not get called in
the hot-plug path
Surely it must be ... you even have code in it to cope
with this case. The:
if (__per_cpu_mca[cpu]) {
test can only be true if we are back in this code for a
second run through if the cpu was taken offline and added
again. Just like it says in the comment above this test.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
So the percpu changes are innocent ... something else since 2.6.24 is to blame. Only 5749 commits :-) I'll start bisecting. 12 bisections later ... nothing! I think I got lost in the maze. Bisection #5 had a crash, but it looked to be a very differnt crash (and looked to happen later than the bug I was hunting). So I marked that as good on the theory that it looked like this bug wasn't in the kernel. Same thing happened at bisection #9. But I ended up with: commit bfada697bd534d2c16fd07fbef3a4924c4d4e014 Author: Pavel Emelyanov [EMAIL PROTECTED] Date: Sun Dec 2 00:57:08 2007 +1100 [IPV4]: Use ctl paths to register devinet sysctls Which just looks too improbable to be the cause of the UP crash. Git won't revert it out from top of tree automatically so I can't easily test whether some weird magic means that this is the buggy commit. Perhaps the issue is another offset of object X in kernel w.r.t. object Y ... and so the good/bad choices in the bisection are actually pretty random depending on how much code is stuffed between X Y at each bisection point. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
This broke powerpc (and presumably ia64 and sparc64) in current linux-2.6.git: I'm generating a fixup patch right now... thanks! Sorry about that: we cross-built on ARM but not on SMP non-x86 platforms so this dependency/breakage went unnoticed. Yes ... all ia64 builds (UP and SMP) are broken at the moment. Please Cc: me with the fixup patch. Thanks -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
Could you check the patch below? With this applied to latest -git, ia64 buils fine for me in a cross-compiling environment. (but i dont know whether it boots ...) Uni-processor build still fails with this patch (config is arch/ia64/configs/tiger_defconfig with CONFIG_SMP switched from =y to =n). arch/ia64/kernel/built-in.o(.text+0x5012): In function `show_interrupts': : relocation truncated to fit: IMM22 per_cpu__kstat arch/ia64/kernel/built-in.o(.text+0x53e1): In function `__bind_irq_vector': : relocation truncated to fit: IMM22 per_cpu__vector_irq arch/ia64/kernel/built-in.o(.text+0x5612): In function `__clear_irq_vector': : relocation truncated to fit: IMM22 per_cpu__vector_irq arch/ia64/kernel/built-in.o(.text+0x5a81): In function `__setup_vector_irq': : relocation truncated to fit: IMM22 per_cpu__vector_irq arch/ia64/kernel/built-in.o(.text+0x6231): In function `ia64_handle_irq': : relocation truncated to fit: IMM22 per_cpuirq_regs arch/ia64/kernel/built-in.o(.text+0x6272): In function `ia64_handle_irq': : relocation truncated to fit: IMM22 per_cpu__vector_irq arch/ia64/kernel/built-in.o(.text+0x7b81): In function `cpu_idle_wait': : relocation truncated to fit: IMM22 .text arch/ia64/kernel/built-in.o(.text+0x7e21): In function `cpu_idle': : relocation truncated to fit: IMM22 .text arch/ia64/kernel/built-in.o(.text+0x7fd1): In function `ia64_save_extra': : relocation truncated to fit: IMM22 per_cpu__pfm_syst_info arch/ia64/kernel/built-in.o(.text+0x8071): In function `ia64_load_extra': : relocation truncated to fit: IMM22 per_cpu__pfm_syst_info arch/ia64/kernel/built-in.o(.text+0x95c0): In function `pfm_write_ibr_dbr': : additional relocation overflows omitted from the output ld: final link failed: Nonrepresentable section on output make: *** [.tmp_vmlinux1] Error 1 SMP build (config zx1_defconfig) builds ok and boots ok too. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
could you try the full patchset that Travis has just sent and which i've put into x86.git, you can pull it from: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git it's a fixes only tree, ontop of Linus-very-latest. Head 4b9e425c25f84. [pull from ssh://master.kernel.org if it's not on git.kernel.org yet, uploaded it this very minute.] Same build fail for CONFIG_SMP=n. The SMP=y build is good (for tiger_defconfig) and boots ok too. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
I'm having trouble replicating this error. With the latest linux-2.6.git plus the patch I just sent, I get the following errors: drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict drivers/md/md.c:5881: error: __param_start_ro causes a section type conflict Weird. psmouse-base.c builds ok for me. Perhaps there is a compiler version difference? I'm running a rather old 3.4.6 that came with my RHEL 4.5 release. (plenty of warnings too, but no vmlinux) New section mismatch checks are complaining about lots of stuff in this post 2.6.24 world. There are a couple of dozen other warnings in a normal build. I copied arch/ia64/configs/tiger_defconfig to .config, ran menuconfig to turn off SMP and built with this line Yup ... my script is a little different. It uses $ sed -e '/CONFIG_SMP/d' arch/ia64/configs/tiger_defconfig .config $ make oldconfig But the net effect should be equivalent. #ifdef HAVE_MODEL_SMALL_ATTRIBUTE # define PER_CPU_ATTRIBUTES __attribute__((__model__ (__small__))) #endif This is only defined for !__ASSEMBLY__ Some place in there. The CONFIG_SMP=n path in ia64 makes quite radical changes ... rather than putting all the per-cpu stuff into the top 64K of address space and providing a per-cpu TLB mapping for that range to a different physical address ... it just makes all the per-cpu stuff link as ordinary variables in .data. The error messages indicate that some of the new code is unaware of this. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
ah, that was the vital clue. The patch below makes the small memory model only defined on SMP, and makes the config build/link fine here. Does this build and boot on your box? I applied this on top of the git pull from git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git and I see see a build problem for SMP=n :-( -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
could you send the .config you are using? Ok. Attached. -Tony upconfig Description: upconfig
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
this i believe builds an implicit dependency between the mca_asm.o position within the image and the ia64_mca_data percpu variable it accesses - it relies on the immediate 22 addressing mode that has 4MB of scope. Per chance, the .config you sent creates a 14MB image, and the percpu variables moved too far away for the linker to be able to fulfill this constraint. Sounds very plausible. The workaround is to define PER_CPU_ATTRIBUTES to link percpu variables back into the .percpu section on UP too - which ia64 links specially into its vmlinux.lds. But ultimately i think the better solution would be to remove this dependency between arch/ia64/kernel/mca_asm.S and the position of the percpu data. Yup. That fixes the build ... the resulting binary doesn't boot though :-( I just realized that it has been a while since I tried booting a UP kernel ... so the problem may be unrelated bitrot elsewhere. Overall you are right that the mca_asm.S code should not be dependent on the relative location of the data objects. I'll start digging on why this doesn't boot ... but you might as well send the fixes so far upstream to Linus so that the SMP fix is available (which is all anyone really cares about ... there are very, very few UP ia64 systems in existence). Acked-by: Tony Luck [EMAIL PROTECTED] -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
I'll start digging on why this doesn't boot ... but you might as well send the fixes so far upstream to Linus so that the SMP fix is available Well a pure 2.6.24 version compiled with CONFIG_SMP=n booted just fine, so the breakage is recent ... and more than likely related to this change. I've only had a casual dig at the failing case ... kernel dies in memset() as called from kmem_cache_alloc() with the address being written as 0x40117b48 (which is off in the virtual address space range used by users ... not a kernel address). I'll dig some more tomorrow. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]Add TR insert/purge interface for add-on component
Looks pretty good. Stylistically it would be nicer to initialize ia64_max_tr_num to 8 (with a comment that this is the least smallest allowed value allowed by the architecture - SDM p.2:44 section 4.1.1.1) and increase this if PAL_VM_SUMMARY indicates that the current processor model supports a larger value. That way you are sure that it never has a larger value that it should. N.B. SGI ship systems with mixed processor models, so to be completely correct here you either need ia64_max_tr_num to be a per-cpu value, or to make sure you only set it to the smallest value supported by any cpu on the system. Your overlap checking code only looks like it checks for overlaps among the new entries being inserted via this interface. Is there some other non-obvious way that these are prevented from overlapping with the TR entries in use by the base kernel (ITR[0]+DTR[0] mapping the kernel in region 5, ITR[1] for the PAL code and DTR[1] for the current kernel stack granule? I don't know how kvm will use this interface, perhaps the virtual address range is limited to areas that can't overlap? If so, perhaps the ia64_itr_enty() routine should check that the va,size arguments are in the virtual address range that KVM will use? ia64_itr_entry() should check that 'log_size' is a supported page size for this processor, and that 'va' is suitably aligned for that size. ia64_ptr_entry() perhaps this should just take a 'target_mask' and 'reg' argument. Then it could skip all the overlap checks and just lookup the address+size in the __per_cpu_idtrs[][][] array return an error if you try to purge something that you didn't set up (-pte == 0). Calling this routine 'ia64_purge_tr' (which is the name in the header comment :-) would help note the non-symmetric calling arguments between insert and purge. What is the expected usage pattern for itr, dtr, itr+dtr mappings by KVM? If you are going to allocate enough that there might be contention, it could be better to start the allocation search for i+d entries at the top and work downwards, while allocating just-i and just-d entries from low numbers working up. That might avoid issues with not having an i+d pair available becaue all the odd entries were allocated for 'i' and all the even ones allocated for 'd' ... so even though there are plenty of free TR registers, none of the free ones are in pairs. Maybe we should put a 'kvm_' into the names of the exported interfaces? Sadly there isn't a way to just make these visible to KVM ... but I'd like to make it crystal clear that other drivers should not use these. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Export three symbols out.
I can apply this when the kvm code is ready (and I think that is close). One change that I will make to for all three to be EXPORT_SYMBOL_GPL. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on linux ia64 tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/kernel/unaligned.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) Tony Luck (1): [IA64] Fix unaligned handler for floating point instructions with base update - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix unaligned handler for floating point instructions with base update
The compiler team did the hard work for this distilling a problem in large fortran application which showed up when applied to a 290MB input data set down to this instruction: ldfd f34=[r17],-8 Which they noticed incremented r17 by 0x10 rather than decrementing it by 8 when the value in r17 caused an unaligned data fault. I tracked it down to some bad instruction decoding in unaligned.c. The code assumes that the 'x' bit can determine whether the instruction is an ldf or ldfp ... which it is for opcode=6 (see table 4-29 on page 3:302 of the SDM). But for opcode=7 the 'x' bit is irrelevent, all variants are ldf instructions (see table 4-36 on page 3:306). Note also that interpreting the instruction as ldfp means that the paired floating point register (f35 in the example here) will also be corrupted. Signed-off-by: Tony Luck [EMAIL PROTECTED] --- arch/ia64/kernel/unaligned.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) --- a/arch/ia64/kernel/unaligned.c 2007-10-19 16:17:25.0 -0700 +++ b/arch/ia64/kernel/unaligned.c 2008-01-11 13:17:41.877317341 -0800 @@ -1488,16 +1488,19 @@ case LDFA_OP: case LDFCCLR_OP: case LDFCNC_OP: - case LDF_IMM_OP: - case LDFA_IMM_OP: - case LDFCCLR_IMM_OP: - case LDFCNC_IMM_OP: if (u.insn.x) ret = emulate_load_floatpair(ifa, u.insn, regs); else ret = emulate_load_float(ifa, u.insn, regs); break; + case LDF_IMM_OP: + case LDFA_IMM_OP: + case LDFCCLR_IMM_OP: + case LDFCNC_IMM_OP: + ret = emulate_load_float(ifa, u.insn, regs); + break; + case STF_OP: case STF_IMM_OP: ret = emulate_store_float(ifa, u.insn, regs); - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fix unaligned handler for floating point instructions with base update
This sounds like a case of the kernel corrupting user data. Are you pushing this into the distro kernels? Do you have bugzilla numbers? Yes, the kernel is corrupting user data. I'm not aware of bugzilla entries for this at the distros (I only became aware of the issue on Thursday afternoon). I agree that it needs to go to the distros. My bugzilla searching skills are bad (I usually can't find bugs that I know are in there, for which I have all the right keywords :-( ) So if anyone knows of existing bugs that might be caused by this problem ... let me know. Otherwise I can open new entries when I send this patch to Linus. I'm a little puzzled that this hasn't been found before. The code in unaligned.c has been essentially the same since the dawn of ia64 time ... very early 2.4.x releases just used a ? : rather than an if ... else, so the patch would need some massaging before it could be applied to 2.4.3 or earlier. I'm assuming that we haven't hit this before because either (or both) of these are true: 1) Most FP access to memory is aligned. 2) Compilers are not generating the ldf fX = [rY], off (and other mis-decoded variations) very often. Meanwhile ... if you could stare at the code and pages 3:302 - 3:306 of the SDM for a while to check my patch for stupidity, that would be extremely helpful. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH] clean up use of ia64 tool chain check scripts --resent
-GAS_STATUS = $(shell $(srctree)/arch/ia64/scripts/check-gas $(CC) $(OBJDUMP)) -CPPFLAGS += $(shell $(srctree)/arch/ia64/scripts/toolchain-flags $(CC) $(OBJDUMP) $(READELF)) If we delete these calls from the Makefile, then should we also delete the scripts themselves (and the test programs that they use) from arch/ia64/scripts? +CPPFLAGS += -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE and if we are going to just unconditionally set these defines, perhaps we should clean the #ifdef'd code out of the source tree so we can remove this clutter from the Makefile too? It all sounds good to me ... but I'll wait a few more days in case somebody who knows better is still on their winter holiday break. [This is 2.6.25 cleanup material anyway, so waiting is not an issue] -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 1/3] IA64: Slim down __clear_bit_unlock
- I removed the useless volatile stuff from the non-atomic versions of the bit operations. This is the correct thing to do ... but I wonder how we can validate that there are no callers that were depending on the extra ordering that the old volatile versions were providing. Clearly any such callers are broken ... but finding them the hard way (by executing the kernel and waiting to see if something stange happens) is going to be unpleasant. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/sn/kernel/xp_nofault.S | 10 +++--- include/asm-ia64/sn/xpc.h|6 -- 2 files changed, 11 insertions(+), 5 deletions(-) Russ Anderson (2): [IA64] Update Altix BTE error return status patch [IA64] Update Altix nofault code - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/hp/common/sba_iommu.c |3 ++- arch/ia64/ia32/binfmt_elf32.c | 28 arch/ia64/kernel/head.S |1 + arch/ia64/kernel/irq_ia64.c |4 ++-- arch/ia64/kernel/mca.c| 33 + arch/ia64/kernel/process.c|7 +-- arch/ia64/kernel/signal.c | 10 +- arch/ia64/kernel/uncached.c |2 +- arch/ia64/mm/tlb.c| 18 +++--- arch/ia64/sn/kernel/bte.c |4 ++-- arch/ia64/sn/kernel/bte_error.c |8 ++-- arch/ia64/sn/pci/tioce_provider.c |2 +- include/asm-ia64/bitops.h | 17 ++--- include/asm-ia64/gcc_intrin.h |5 + include/asm-ia64/hw_irq.h |2 +- include/asm-ia64/intel_intrin.h |3 +++ include/asm-ia64/sn/bte.h | 31 ++- include/asm-ia64/sn/xp.h | 27 +-- include/asm-ia64/sn/xpc.h |8 +++- include/asm-ia64/tlbflush.h |6 +- 20 files changed, 171 insertions(+), 48 deletions(-) Christoph Lameter (1): IA64: Slim down __clear_bit_unlock Hidetoshi Seto (2): [IA64] Remove assembler warnings on head.S [IA64] Adjust CMCI mask on CPU hotplug Ian Wienand (1): [IA64] set_thread_area fails in IA32 chroot Jan Beulich (1): [IA64] make flush_tlb_kernel_range() an inline function Joe Perches (1): [IA64] Two trivial spelling fixes Kenji Kaneshige (1): [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c Nick Piggin (1): [IA64] ia32 nopage Russ Anderson (1): [IA64] Fix Altix BTE error return status Shi Weihua (1): [IA64] signal: remove redundant code in setup_sigcontext() Simon Horman (1): [IA64] Guard elfcorehdr_addr with #if CONFIG_PROC_FS Tony Luck (1): [IA64] print kernel release in OOPS to make kerneloops.org happy de Dinechin, Christophe (Integrity VM) (1): [IA64] Avoid unnecessary TLB flushes when allocating memory - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] print kernel release in OOPS to make kerneloops.org happy
The ia64 oops message doesn't include the kernel version, which makes it hard to automatically categorize oops messages scraped from mailing lists and bug databases. Signed-off-by: Tony Luck [EMAIL PROTECTED] --- There isn't any consistency about how oops messages are formatted in different architectures. I've added it after the tainted field. If that upsets any existing ia64 oops parsing scripts, then I'm open to placing this somewhere else. --- a/arch/ia64/kernel/process.c2007-12-07 21:06:52.0 -0800 +++ b/arch/ia64/kernel/process.c2007-12-18 08:59:57.0 -0800 @@ -27,6 +27,7 @@ #include linux/interrupt.h #include linux/delay.h #include linux/kdebug.h +#include linux/utsname.h #include asm/cpu.h #include asm/delay.h @@ -107,8 +108,9 @@ print_modules(); printk(\nPid: %d, CPU %d, comm: %20s\n, task_pid_nr(current), smp_processor_id(), current-comm); - printk(psr : %016lx ifs : %016lx ip : [%016lx]%s\n, - regs-cr_ipsr, regs-cr_ifs, ip, print_tainted()); + printk(psr : %016lx ifs : %016lx ip : [%016lx]%s (%s)\n, + regs-cr_ipsr, regs-cr_ifs, ip, print_tainted(), + init_utsname()-release); print_symbol(ip is at %s\n, ip); printk(unat: %016lx pfs : %016lx rsc : %016lx\n, regs-ar_unat, regs-ar_pfs, regs-ar_rsc); - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC][try 2] IA64 signal : remove redundant code in setup_sigcontext()
This patch removes some redundant code in the function setup_sigcontext(). The registers ar.ccv,b7,r14,ar.csd,ar.ssd,r2-r3 and r16-r31 are not restored in restore_sigcontext() when (flags IA64_SC_FLAG_IN_SYSCALL) is true. So we don't need to zero those variables in setup_sigcontext(). Erm, couldn't those registers contain information the process shouldn't see? No, this looks safe. setup_sigcontext() is stashing things out on the user stack to be used by restore_sigcontext() should the application want to return from the signal handler. But restore_sigcontext isn't actually in charge of putting values into machine registers, it just does the copy back from user space to the place where the asm code will restore registers on the way back to userland. In this instance restored means set back to the state they had before the signal happened. If they aren't restored they'll have scratch values ... but those scratch values will have come from the application (while it was executing the signal handler). Not leaked from the kernel or from some other application. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: Avoid unnecessary TLB flushes when allocating memory
As you can see, the global purge rates can be pretty respectable under this kind of load. I chose -j50 to generate enough processes to stress my own system, you may need more with 4G. Check with xosview or similar that the buffer cache fills up memory but is kept relatively small by user-space memory pressure (at around 5-10% for my own testing). My 4G of memory was indeed the problem ... in two ways: 1) I didn't install Everything on this machine. So the 'find /usr -type f | xargs cat' was only juggling with just over 2G of files, which all fit in the page cache! 2) I'd assumed you had used -j50 because you were running on some humungous superdome system with that many cpus. I was only using -j16 ... which probably fit into the remaining available memory. So I moved the 'find' to /home (which has 7G of files), increased the -j factor, and just to make really sure ran a little program that did a malloc() mlock() of 2G of memory. I've been running for about 20 minutes and already see just over half a million cases where your patch avoided flush_tlb_all() (at the moment it is managing to do so in every case). Do you know what the call sequence looks like for the few cases where your patch doesn't manage to avoid (you mentioned just 170 times out of several million in the patch submission)? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: Avoid unnecessary TLB flushes when allocating memory
Test case: Run 'find /usr -type f | xargs cat /dev/null' in the background to fill the buffer cache, then run something that uses memory, e.g. 'gmake -j50 install'. Instrumentation showed that the number of global TLB purges went from a few millions down to about 170 over a 12 hours run of the above. What was your system configuration for this test. I'm running on a 4 socket Montecito (with HT enabled, so 16 logical cpus) with 4G of memory. In the first hour of my test I've only seen 125 calls where the old code would have called flush_tlb_all(). The new code managed to avoid all of these ... so it is batting 100%. This is out of just over a million calls to ia64_global_tlb_purge(). So clearly I'm not manage to stress the system as heavily as you did. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4 of 4] Add efi_guidtest_set to reduce duplication
This is a list of duplicated tests. Using a #define makes it easier to add new ones and harder to introduce an error. The next new one to be added here is likely to be a check for the PALO table (http://www.dig64.org/home/DIG-PALO_09a.pdf) ... but it is unclear whether this fits the pattern dictated by your macro, which requires that everything we find be stashed in the efi structure. I'm not sure that I want/need to add a pointer to the PALO table to struct efi. The series of if-then-else clauses here doesn't look too complex or error prone (especially in the original long-line form before you squeezed it into 80 columns in the first patch in this series). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4 of 4] Add efi_guidtest_set to reduce duplication
Would you like me to regenerate patch 1/4 without the reformatting of those tests, so they maintain the original long-lines? I'm not a big fan of the 80 column rule ... but this file is a bit out of control ... and all the other bizarre formatting that you fixed up looks like an improvement. The patch needs a refresh anyway (4 of the hunks failed to auto-apply ... presumably because of Li Zefan's change to use efi_md_size() everywhere). Please leave out the efi_guidcmp() lines (the worst one is only 92 chars long) in the refresh. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
I thought you already generated the diffstat with git diff --stat, and if so, just adding --summary should do it. My script was written in the early hours (well weeks) of git history. Perhaps I didn't know about --stat or maybe it didn't exist yet. The script currently just pipes git-whatchanged -p output to diffstat -p1. I'll update it with this new fancy ... syntax and use the --summary. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux on Intel Big Sur
I happen to posses an old Big Sur machine manufactured by Intel, based around two Itanium (Merced) CPU's and a 460GX chipset. The machine is labeled as an enginnering sample (label: http://ishells.net/spy/itanium/DSC00873.jpg), and looks identical to the HP i2000 workstation (picture: http://ishells.net/spy/itanium/DSC00880.jpg). I haven't booted kernels on BigSur/Merced based systems for a very long time (3 years? perhaps more) ... and untested code very quickly turns into non-working code :-( Do you reckon it is safe to update? What else would you suggest me to do about my machine to succeed with Linux installation? You'd probably be a lot happier if you re-cycled this machine and found a newer one (at least McKinley based). If you really want to continue you might try to track down some install disks for a version of Linux that is the same age as the machine (e.g. RedHat AS 2.1). At least these are known to work on this h/w. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/Makefile |2 +- arch/ia64/hp/sim/boot/Makefile |2 +- arch/ia64/hp/sim/boot/bootloader.lds |3 ++- arch/ia64/kernel/acpi.c |2 +- arch/ia64/kernel/efi.c | 10 +- arch/ia64/kernel/gate.lds.S |2 +- arch/ia64/kernel/ia64_ksyms.c|3 +++ arch/ia64/kernel/iosapic.c | 21 - arch/ia64/kernel/kprobes.c | 29 ++--- arch/ia64/kernel/setup.c |3 +-- arch/ia64/kernel/signal.c|8 arch/ia64/kernel/vmlinux.lds.S |3 ++- arch/ia64/lib/Makefile |4 ++-- arch/ia64/mm/tlb.c |2 +- arch/ia64/sn/kernel/io_common.c | 13 ++--- include/asm-ia64/iosapic.h |2 -- 16 files changed, 56 insertions(+), 53 deletions(-) Andrew Morton (3): [IA64] increase .data.patch offset [IA64] don't assume that unwcheck.py is executable [IA64] export copy_page() to modules Bernhard Walle (1): [IA64] rename _bss to __bss_start Joe Perches (1): [IA64] Add missing space to concatenated strings Kenji Kaneshige (1): [IA64] Fix iosapic interrupt delivery mode for CPE Li Zefan (1): [IA64] make full use of macro efi_md_size Mike Habeck (1): [IA64] SGI Altix : fix bug in sn_io_late_init() Roel Kluin (1): [IA64] operator priority fix in acpi_map_lsapic() Shaohua Li (1): [IA64] kprobe: make kreturn probe handler stack unwind correct Shi Weihua (1): [IA64] signal : fix missing error checkings Simon Horman (1): [IA64] iosapic cleanup - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
makes the Makefile work even for a non-executable file for when you use inferior tools, but does that mean that we should have thrown away the information that it *is* an executable file when not using those inferior tools? Once I added the python in front of the name in the Makefile, the need for it to be executable went away ... so I did the chmod deliberately as it looked like we didn't need the execute bit any more. This is only wrong if there are people in the habit of running arch/ia64/scripts/unwcheck.py manually from the command line. I've never done this ... but perhaps someone might be sad that I took the execute bit away. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
Hmm. It also did: mode change 100755 = 100644 arch/ia64/scripts/unwcheck.py Should I update my script that makes the Please pull message. Right now it just uses git whatchanged release ^linus | git-shortlog which doesn't mention any mode changes ... thus your understandable confusion about whether I had meant to make this change. What git command would neatly summarize any mode changes? Or would I have to roll my own from the whatchanged output? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2/3] ia64: don't assume that unwcheck.py is executable
What was the exact reason switching to phython and can we do the same in perl? It was a shell script (using awk) before it was pythonised. The motivation was correct functionality when cross-building on a 32-bit host. Here's the commit: http://tinyurl.com/28hmoc -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2/3] ia64: don't assume that unwcheck.py is executable
Oh well, whatever. Please treat this as a bug report. ie: someone please fix it. Perhaps with? - -$(Q)READELF=$(READELF) $(srctree)/arch/ia64/scripts/unwcheck.py $ + -$(Q)READELF=$(READELF) python $(srctree)/arch/ia64/scripts/unwcheck.py $ - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] XPC heartbeat timer function must run on CPU 0
Wouldn't that cpu appear to the new OS instance as cpu0? If so, then it should not be an issue. No, I don't believe that it does. I can try and test this theory if it helps. Perhaps my mind is corrupted by x86 thoughts. We are talking about logical cpu0 here. Surely the new instance must call whatever cpu it is running on first 0. E.g. I could have used kexec to switch to a UP kernel that only supports cpu0. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Move dmi_scan_machine() call ealier
Thanks for the review Simon. Is the patch below more like what you're thinking? I agree that check_bugs doesn't initial seem like the most appropriate place to setup DMI, but think about what DMI is typically used for in the kernel. Then re-name check_bugs() to something more suited to the things that it is now doing. [I think that was what Simon was hinting at]. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sysctl table check failed ... Writable sysctl directory
Stephane,
For a couple of weeks now the kernel has been complaining about
a couple of Writable sysctl directories. When I pulled from
Linus latest git tree today, the complaint got louder with an
added stack trace ... pointing at pfm_init().
This patch fixes the complaint. Did you need mode 0755 for
some reason, or should I just apply this?
-Tony
---
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 59169bf..73e7c2e 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -558,7 +558,7 @@ static ctl_table pfm_sysctl_dir[] = {
{
.ctl_name = CTL_UNNUMBERED,
.procname = perfmon,
- .mode = 0755,
+ .mode = 0555,
.child = pfm_ctl_table,
},
{}
@@ -567,7 +567,7 @@ static ctl_table pfm_sysctl_root[] = {
{
.ctl_name = CTL_KERN,
.procname = kernel,
- .mode = 0755,
+ .mode = 0555,
.child = pfm_sysctl_dir,
},
{}
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Itanium SDM spec update released
http://developer.intel.com/design/itanium/documentation.htm?=Itanium+tab _technical_docs Here's some of what is in it: The October 2007 Intel(r) Itanium(r) Architecture Software Developer's Manual Specification Update supplements SDM 2.2 with recent specification changes, specification clarifications, and document changes. Virtualization specification changes (#1, #3, #4, #5, #10, #11) apply to the dual-core Itanium 2 processor 9000 series and 9100. Virtualization disable control (#10) is available on the dual-core Itanium 2 processor 9100 series. Specification changes for future Itanium processors include the new Resource Utilization Counter (#2), PAL_MC_ERROR_INFO health indicator (#7), Variable Frequency Mode Additions to ACPI P-states (#12), PAL_MC_DYNAMIC redefinition (#13), and increased min-state save area (#14). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: Fix IOSAPIC delivery mode setting
+ if (smp_int_redirect SMP_IRQ_REDIRECTION)
This breaks the build on CONFIG_SMP=n configurations (neither
smp_int_redirect nor SMP_IRQ_REDIRECTION is defined).
Perhaps you could have:
#ifdef CONFIG_SMP
static inline char
choose_dmode(void)
{
if (smp_int_redirect SMP_IRQ_REDIRECTION)
return IOSAPIC_LOWEST_PRIORITY;
else
return IOSAPIC_FIXED:
}
#else
static inline char
choose_dmode(void)
{
return IOSAPIC_FIXED;
}
#endif
...
dmode = choose_dmode();
Unless you can see some less invasive syntax.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] __do_IRQ does not check IRQ_DISABLED when IRQ_PER_CPU is set
One user encountering this behavior is the CPE handler (in arch/ia64/kernel/mca.c). When the CPE handler encounters too many CPEs (such as a solid single bit error), it sets up a polling timer and disables the CPE interrupt (to avoid excessive overhead logging the stream of single bit errors). disable_irq_nosync() is called which sets IRQ_DISABLED. The IRQ_PER_CPU flag was previously set (in ia64_mca_late_init()). The net result is the CPE handler gets called even though it is marked disabled. Presumably we are in this situation because there are still some pending CPE interrupts on some cpus when we disable CPE? Or is there a more serious problem that we aren't manage to disable CPE on all cpus properly? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/configs/sn2_defconfig| 106 ++--- arch/ia64/kernel/efi.c |2 arch/ia64/kernel/gate.lds.S|3 + arch/ia64/kernel/msi_ia64.c|2 arch/ia64/kernel/setup.c | 49 ++--- arch/ia64/kernel/smpboot.c | 21 --- arch/ia64/mm/init.c|4 - arch/ia64/scripts/check-segrel.lds |1 arch/ia64/sn/kernel/mca.c |1 include/asm-ia64/percpu.h |2 include/asm-ia64/smp.h |1 11 files changed, 86 insertions(+), 106 deletions(-) Adrian Bunk (1): [IA64] ia64/mm/init.c: fix section mismatches Alex Chiang (1): [IA64] /proc/cpuinfo physical id field cleanups Jes Sorensen (1): [IA64] update sn2 defconfig to 64kb pages Kenji Kaneshige (1): [IA64] Fix incorrect return value from ia64_setup_msi_irq() Roel Kluin (1): [IA64] arch/ia64/sn/kernel/mca.c: undo lock when sn_oemdata can't be extended Roland McGrath (2): [IA64] check-segrel.lds vs --build-id [IA64] vDSO vs --build-id Simon Horman (1): [IA64] vmcore_find_descriptor_size should be in __init Yu Luming (1): [IA64] fix typo in per_cpu_offset - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [IA64] Effective __clear_bit_unlock V2
Is this the final take on this ... or was there a newer better faster cleaner
version?
-Tony
-Original Message-
From: Christoph Lameter [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 10:54 AM
To: Luck, Tony
Cc: linux-ia64@vger.kernel.org; Zoltan Menyhart
Subject: [IA64] Effective __clear_bit_unlock V2
Avoid the use of cmpxchg in __clear_bit_unlock by calling __clear_bit.
__clear_bit uses a volatile pointer and will generate a store with
release semantics as shown by Zoltan. Add a barrier to make sure that
the compiler does not reorder instructions around it.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Acked-by: Nick Piggin [EMAIL PROTECTED]
---
include/asm-ia64/bitops.h | 12
1 file changed, 12 insertions(+)
Index: linux-2.6/include/asm-ia64/bitops.h
===
--- linux-2.6.orig/include/asm-ia64/bitops.h2007-10-19 04:05:38.0
-0700
+++ linux-2.6/include/asm-ia64/bitops.h 2007-10-19 10:50:34.0 -0700
@@ -118,14 +118,6 @@ clear_bit_unlock (int nr, volatile void
}
/**
- * __clear_bit_unlock - Non-atomically clear a bit with release
- *
- * This is like clear_bit_unlock, but the implementation may use a non-atomic
- * store (this one uses an atomic, however).
- */
-#define __clear_bit_unlock clear_bit_unlock
-
-/**
* __clear_bit - Clears a bit in memory (non-atomic version)
*/
static __inline__ void
@@ -137,6 +129,16 @@ __clear_bit (int nr, volatile void *addr
}
/**
+ * __clear_bit_unlock - Non-atomically clear a bit with release
+ */
+static __inline__ void
+__clear_bit_unlock (int nr, volatile void *addr)
+{
+ barrier();
+ __clear_bit(nr, addr);
+}
+
+/**
* change_bit - Toggle a bit in memory
* @nr: Bit to clear
* @addr: Address to start counting from
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ptrace RSE bug
Thanks. So Tony, how do think about the IA64 part of the patch? Having to use ia64_peek() and ia64_poke() to copy the RBS 8 bytes at a time looks a bit ugly ... but this isn't in the performance path (unless you are running your whole application under strace(1)!) so it probably isn't an issue. If it turns out to be, then an incremental fix on top of this would be the way to go. So I'm ok with the ia64 parts ... which leaves the open issue of the generic part (moving the spin_unlock_irq() after the set_current_state(TASK_TRACED)) ... which (if I follow this thread correctly) is still an open issue, right? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: /proc/cpuinfo physical id field cleanups
The only real change from the prior version is that I change the intialization of socket_id to 0 as default. I think the benefit of displaying information from PAL/SAL (when available) on older platforms outweighs the oddity that the user may see physical_id = 0 for multiple CPUs occasionally. Can't we not print the physical_id if we don't know what it is? That sounds like a better idea than printing wrong information. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] vmcoreinfo support for dump filtering
This? That does the trick, yes. (please tell me if you want me to send this to Linus) I've put it in my tree now ... so I'll ask Linus to pull it from there. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
Hi Linus, And another quick pull to fix an ia64 UP build problem. please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release Or since git is updating slowly right now, from: ssh://master.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the file shown below. Thanks! -Tony arch/ia64/kernel/setup.c |2 ++ 1 file changed, 2 insertions(+) Tony Luck (1): [IA64] Fix build for CONFIG_SMP=n - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/Kconfig| 10
arch/ia64/configs/sn2_defconfig | 443 ---
arch/ia64/hp/common/Makefile |1
arch/ia64/hp/common/aml_nfw.c| 236
arch/ia64/kernel/crash.c | 15 -
arch/ia64/kernel/machine_kexec.c |6
arch/ia64/kernel/mca.c | 88 +++
arch/ia64/kernel/mca_drv.h |2
arch/ia64/kernel/palinfo.c |6
arch/ia64/kernel/perfmon.c |7
arch/ia64/kernel/salinfo.c |4
arch/ia64/kernel/topology.c | 12 -
include/asm-ia64/mca.h |2
include/asm-ia64/sal.h | 15 -
14 files changed, 512 insertions(+), 335 deletions(-)
Bjorn Helgaas (2):
[IA64] abstract SAL_CALL wrapper to allow other firmware entry points
[IA64] add driver for ACPI methods to call native firmware
Jes Sorensen (1):
[IA64] update sn2_defconfig
Kenji Kaneshige (2):
[IA64] Fix kernel panic in kdump on INIT
[IA64] Fix kernel hangup in kdump on INIT
Russ Anderson (2):
[IA64] Remove needless delay in MCA rendezvous
[IA64] Fix race when multiple cpus go through MCA
Satyam Sharma (2):
[IA64] tree-wide: Misc __cpu{initdata, init, exit} annotations
[IA64] perfmon: Remove exit_pfm_fs()
Simon Horman (1):
[IA64] Remove vector from ia64_machine_kexec()
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Register memory ranges in a consistent manner on IA64
While pursuing and unrelated issue with 64Mb granules I noticed a problem related to inconsistent use of add_active_range. There doesn't appear any reason to me why FLATMEM versus DISCONTIG_MEM should register memory to add_active_range with different code. So I've changed the code into a common implementation. The other subtle issue fixed by this patch was calling add_active_range in count_node_pages before granule aligning is performed. We were lucky with 16MB granules but not so with 64MB granules. count_node_pages has reserved regions filtered out and as a consequence linked kernel text and data aren't covered by calls to count_node_pages. So linked kernel regions wasn't reported to add_active_regions. This resulted in free_initmem causing numerous bad_page reports. This won't occur with this patch because now all known memory regions are reported by register_active_ranges. This was applied back in January, but we've now found a hole in the implementation. Skipping the path through filter_rsvd_memory() fixes the problem with kernel regions not being reported to add_active_regions(). But it also bypasses the path through call_pernode_memory() which neatly assigned all memory to the right node. The code Bob added in register_active_ranges() that calls paddr_to_node() on the first address in the block found in the efi_memory map doesn't allow for the fact that a memory block in the efi memory map may span across nodes. And we've now found a system where this happens ... so memory that belongs to node 1 is being attached to node 0 because it happens to be part of a contiguous block of memory that starts on node 0. I'd initially coded but a fix that put the filter_reserved_memory() path back in. But on more careful reading of your comments in the commit I see that will re-introduce problems that were fixed before. Perhaps we should change the calling convention for call_pernode_memory() (It currently takes [start,len] as physical addresses rather than [start,end] as virtual addresses) so it can be used as a first argument to efi_memmap_walk() ... so the code can be: efi_memmap_walk(call_pernode_memory, register_active_ranges); Thoughts? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] module to support ACPI AML calls to native firmware
If you don't object to the two patches, can you incorporate them as originally posted? If you'd prefer a different approach, I'd be happy to rework them, of course. I think that adding 4K to the kernel (about 0.04% increase looking at a recent build ... or 0.0001% of total memory on a 4G system) isn't really a big deal. I'd rather do that than export all the fw_call_*() functions for all the world to see. If there is some other reason why the exports are needed, then the names may have to change ... these are ia64 specific routines, but the fw_call_*() names sound very generic. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled
So far it appears to me that it will be defined for ia64 somewhere in asm-generic/tlb.h and in asm-ia64/tlb.h as platform_global_tlb_ipi_purge() something, but I'm not sure about that, will have to start digging. I'm voting with David on this one ... machvec doesn't look like the right mechanism for this (all of the non-sn2 machvecs would potentially have to be duplicated to provide ptc.g and !ptc.g variants ... that doesn't sound like a good plan). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2
global cache purge in their chipset implementation. (For such cases, Intel provided a SAL table entry to specify if ptc.g is allowed and how many). This seems odd. You never use that sal call to initialized noptcg. Is that an oversight? The mechanism is a SAL table entry, not a SAL call. Currently that entry provides no mechanism to specify that ptc.g should not be used at all (the entry provides the count of how many ptc.g can happen in parallel, but the spec says that the value 0 means 1 :-( ) There is an ongoing discussion with DIG64 to use a currently reserved field in the table to specify the value 0. If that change is approved, then we can add code to enable Natalie's code based on the SAL table. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
Having looked closer, it looks like the magic actually disables some
broken code from happening on other architectures.
Yes. The drivers/char/hpet.c clocksource code was added for ia64 as
part of the switch from the time interpolator to the generic clock
code ... but the patch had languished for a long time, and by the time
it was resurrected, i386 and x86_64 had added their own arch specific
code ... which didn't get noticed until the double hpet bug report
was logged.
However, why was it done in that illogical manner?
Too much LDS back in the sixties? It looked very weird, but in a
cute sort of way ... and I though the lifetime of the code was likely
to be short (since this code is screming to be merged into a single
version used by any arch with HPET) ... so I pushed it in. Sorry.
Your patch is much better.
Here's a commit comment for your patch:
The HPET clocksource code in drivers/char/hpet.c should not be
registered on anything except ia64 (as it is known to cause problems
on x86_64, and perhaps i386 too). Disable this code with an #ifdef
until we can merge all the hpet clocksource code.
Acked-by: Tony Luck [EMAIL PROTECTED]
---
drivers/char/hpet.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 77bf4aa..7ecffc9 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -909,6 +909,8 @@ int hpet_alloc(struct hpet_data *hdp)
hpetp-hp_delta = hpet_calibrate(hpetp);
+/* This clocksource driver currently only works on ia64 */
+#ifdef CONFIG_IA64
if (!hpet_clocksource) {
hpet_mctr = (void __iomem *)hpetp-hp_hpet-hpet_mc;
CLKSRC_FSYS_MMIO_SET(clocksource_hpet.fsys_mmio, hpet_mctr);
@@ -918,6 +920,7 @@ int hpet_alloc(struct hpet_data *hdp)
hpetp-hp_clocksource = clocksource_hpet;
hpet_clocksource = clocksource_hpet;
}
+#endif
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
Hi Linus, I backed up my tree to before the evil HPET disable commit, and then cherry-picked the stuff that follwed. So here's the revised pull without the stupidity. Note to anyone else using my GIT tree ... this means my tree jumped sideways and you won't be able to pull from it if you had done a pull since Thursday. You'll have to back the branch you use to track my tree back up (e.g. to v2.6.23-rc4) before you can pull again. please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/hp/sim/hpsim_console.c| 16 ++-- arch/ia64/hp/sim/hpsim_setup.c |9 ++--- arch/ia64/hp/sim/simeth.c | 12 +++- arch/ia64/hp/sim/simscsi.c |3 +-- arch/ia64/kernel/irq_ia64.c | 28 ++-- arch/ia64/kernel/setup.c| 13 +++-- arch/ia64/kernel/smpboot.c |6 ++ arch/ia64/mm/contig.c |3 +++ arch/ia64/mm/discontig.c|3 +++ arch/ia64/sn/kernel/huberror.c | 14 ++ arch/ia64/sn/kernel/irq.c | 15 +++ arch/ia64/sn/kernel/sn2/sn2_smp.c | 26 ++ arch/ia64/sn/kernel/sn2/sn_hwperf.c |3 ++- arch/ia64/sn/pci/pcibr/pcibr_provider.c |1 + arch/ia64/sn/pci/tioca_provider.c |2 ++ arch/ia64/sn/pci/tioce_provider.c |1 + include/asm-ia64/hpsim.h| 16 include/asm-ia64/sn/arch.h |1 + include/asm-ia64/sn/intr.h |1 + include/asm-ia64/sn/sn_feature_sets.h |1 + 20 files changed, 137 insertions(+), 37 deletions(-) Jesper Juhl (1): [IA64] Remove unnecessary cast of allocation return value in sn_hwperf_enum_objects() John Keller (1): [IA64] SN: Add support for CPU disable Kenji Kaneshige (2): [IA64] Fix unexpected interrupt vector handling [IA64] Clear pending interrupts at CPU boot up time Peter Chubb (2): [IA64] Enable early console for Ski simulator [IA64] Cleanup HPSIM code (was: Re: Enable early console for Ski simulator) Prarit Bhargava (1): [IA64] Stop bogus NMI softlockup warnings in ia64 show_mem - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git pull on ia64 linux tree
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below. The change to drivers/char/hpet.c
makes the hpet timer code there ia64 only until we can do something better
to merge in arch/{i386,x86_64)/kernel/hpet.c
Thanks!
-Tony
arch/ia64/hp/sim/hpsim_console.c| 16 ++--
arch/ia64/hp/sim/hpsim_setup.c |9 ++---
arch/ia64/hp/sim/simeth.c | 12 +++-
arch/ia64/hp/sim/simscsi.c |3 +--
arch/ia64/kernel/irq_ia64.c | 28 ++--
arch/ia64/kernel/setup.c| 13 +++--
arch/ia64/kernel/smpboot.c |6 ++
arch/ia64/mm/contig.c |3 +++
arch/ia64/mm/discontig.c|3 +++
arch/ia64/sn/kernel/huberror.c | 14 ++
arch/ia64/sn/kernel/irq.c | 15 +++
arch/ia64/sn/kernel/sn2/sn2_smp.c | 26 ++
arch/ia64/sn/kernel/sn2/sn_hwperf.c |3 ++-
arch/ia64/sn/pci/pcibr/pcibr_provider.c |1 +
arch/ia64/sn/pci/tioca_provider.c |2 ++
arch/ia64/sn/pci/tioce_provider.c |1 +
drivers/char/hpet.c | 10 ++
include/asm-ia64/hpsim.h| 16
include/asm-ia64/sn/arch.h |1 +
include/asm-ia64/sn/intr.h |1 +
include/asm-ia64/sn/sn_feature_sets.h |1 +
21 files changed, 147 insertions(+), 37 deletions(-)
Jesper Juhl (1):
[IA64] Remove unnecessary cast of allocation return value in
sn_hwperf_enum_objects()
John Keller (1):
[IA64] SN: Add support for CPU disable
John Stultz (1):
[HPET] double hpet clocksource hard freeze
Kenji Kaneshige (2):
[IA64] Fix unexpected interrupt vector handling
[IA64] Clear pending interrupts at CPU boot up time
Peter Chubb (2):
[IA64] Enable early console for Ski simulator
[IA64] Cleanup HPSIM code (was: Re: Enable early console for Ski
simulator)
Prarit Bhargava (1):
[IA64] Stop bogus NMI softlockup warnings in ia64 show_mem
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
__get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1. But, it doesn't fail on rc2-mm2, and kernel can boot up. That looks to be part of the problem here ... failing an order=3 allocation during boot on a system that just a few lines earlier in the boot log reported Memory: 37474000k/37680640k available looks bad ... but perhaps having *more* memory is part of your problem. You may have run low on GFP_DMA memory because some allocation scaled by memory size has chewed up a lot of your memory. To check this try booting with a mem=4G parameter and see if that helps you. But it is also bad that the swiotlb() code failed to handle this. Can you check whether the problem is related to the size of the allocation being just over 256K (a magic number for swiotlb since IO_TLB_SEGSIZE is 128 times a slab size of 2k). Try changing lib/swiotlb.c to set IO_TLB_SEGSIZE to 256 instead. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
[ 20.903201] [a001003aaa50] swiotlb_full+0x50/0x120
[ 20.903202] sp=e0014322fac0 bsp=e00143229120
[ 20.916902] [a001003aac40] swiotlb_map_single+0x120/0x1c0
[ 20.916904] sp=e0014322fac0 bsp=e001432290d8
[ 20.931215] [a001003ab630] swiotlb_alloc_coherent+0x150/0x240
[ 20.931217] sp=e0014322fac0 bsp=e00143229090
[ 20.945923] [a00100550860] PrimeIocFifos+0x4c0/0xb20
[ 20.945925] sp=e0014322fac0 bsp=e00143229010
[ 20.959812] [a00100556a80] mpt_do_ioc_recovery+0xd60/0x28e0
[ 20.959814] sp=e0014322faf0 bsp=e00143228f30
[ 20.974310] [a0010055c8f0] mpt_attach+0x830/0x20e0
Hmmm! So you were in the mpt/fusion driver when you ran out
of SWIOTLB space. That's an area where we both have the same
hardware ... and since it booted for me, it means that the
driver isn't totally broken.
I'm totally ignorant of what goes on inside this driver though.
You have more ioc's than I do. I only see messages from mpt
bringing up ioc0 ioc1. Your boot_log also has ioc2 (which is
where you crash). Here's the sdiff(1) output comparing the MPT
part of your boot log with my successful boot of the same kernel
and config (your log is the one on the left). Maybe some MPT/Fusion
expert can spot something important in this bit?
-Tony
Fusion MPT base driver 3.04.05 Fusion MPT base
driver 3.04.05
Copyright (c) 1999-2007 LSI Corporation Copyright (c)
1999-2007 LSI Corporation
Fusion MPT SPI Host driver 3.04.05 Fusion MPT SPI
Host driver 3.04.05
GSI 40 (level, low) - CPU 3 (0x0600) vector 71 | GSI 28 (level,
low) - CPU 0 (0xc018) vector 48
ACPI: PCI Interrupt :01:03.0[A] - GSI 40 (level, low) - | ACPI: PCI
Interrupt :06:02.0[A] - GSI 28 (level, low) -
mptbase: Initiating ioc0 bringupmptbase:
Initiating ioc0 bringup
ioc0: LSI53C1030 C0: Capabilities={Initiator} | ioc0:
LSI53C1030 B2: Capabilities={Initiator}
scsi0 : ioc0: LSI53C1030 C0, FwRev=01032821h, Ports=1, MaxQ=2 | scsi0 : ioc0:
LSI53C1030 B2, FwRev=01030a00h, Ports=1, MaxQ=2
scsi 0:0:0:0: Direct-Access IBM-ESXS DTN018C1UCDY10F S25 | scsi 0:0:0:0:
Direct-Access QUANTUM ATLAS IV 9 SCA 0B0
target0:0:0: Beginning Domain Validationtarget0:0:0:
Beginning Domain Validation
target0:0:0:
Domain Validation skipping write tests
target0:0:0: Ending Domain Validation target0:0:0:
Ending Domain Validation
target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offse | target0:0:0:
FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offse
sd 0:0:0:0: [sda] 35548320 512-byte hardware sectors (18201 M | sd 0:0:0:0:
[sda] 17942584 512-byte hardware sectors (9187 MB
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0:
[sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, | sd 0:0:0:0:
[sda] Write cache: enabled, read cache: enabled,
sd 0:0:0:0: [sda] 35548320 512-byte hardware sectors (18201 M | sd 0:0:0:0:
[sda] 17942584 512-byte hardware sectors (9187 MB
sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0:
[sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, | sd 0:0:0:0:
[sda] Write cache: enabled, read cache: enabled,
sda: sda1 sda2 | sda: sda1 sda2
sda3
sd 0:0:0:0: [sda] Attached SCSI disksd 0:0:0:0:
[sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0sd 0:0:0:0:
Attached scsi generic sg0 type 0
scsi 0:0:8:0: Processor IBM 25P3495a S320 1 1 | scsi 0:0:1:0:
Direct-Access SEAGATE ST318406LC 010
target0:0:8: Beginning Domain Validation | target0:0:1:
Beginning Domain Validation
target0:0:8: Ending Domain Validation| target0:0:1:
Ending Domain Validation
target0:0:8: asynchronous| target0:0:1:
FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offse
scsi 0:0:8:0: Attached scsi generic sg1 type 3| sd 0:0:1:0:
[sdb] 35843670 512-byte hardware sectors (18352 M
GSI 41 (level, low) - CPU 4 (0x1000) vector 72 | sd 0:0:1:0:
[sdb] Write Protect is off
ACPI: PCI Interrupt :01:03.1[B] - GSI 41 (level, low) - | sd 0:0:1:0:
[sdb] Write cache: enabled, read cache: enabled,
sd 0:0:1:0:
[sdb] 35843670 512-byte hardware sectors (18352 M
sd 0:0:1:0:
[sdb] Write Protect is off
sd 0:0:1:0:
[sdb] Write cache: enabled, read cache: enabled,
RE: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
The more ioc's you have, the more space you will use. Default SW IOTLB allocation is 64MB ... how much should we see used per ioc? Kamelesh: You could try increasing the amount of sw iotlb space available by booting with a swiotlb=131072 argument (argument value is the number of 2K slabs to allocate ... 131072 would give you four times as much space as the default allocation). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][2.6.23-rc2-mm2] small fix for ia64 icache sync patch
+ if (pte_present(pteval) // swap out ? + pte_exec(pteval) // flush only new executable page. pte_user(pteval) // ignore kernel page (!pte_present(*ptep) ||// do_no_page or swap in, migration, pte_pfn(*ptep) != pte_pfn(pteval))) // do_wp_page(), page copy David Mosberger was concerned about the increase in code size from this inline function. We can reduce the bloat a bit by defining a macro that tests for present executable user-mode in one go: #define pte_pux(pte)((pte_val(pte) (_PAGE_P|_PAGE_PL_MASK|_PAGE_AR_RX)) == \ (_PAGE_P|_PAGE_PL_3|_PAGE_AR_RX)) Perhaps there is a better name than pte_pux? I don't know whether the code that this generates is faster, but it is smaller (bloat is only 3k instead of 4k). One last cleanup needed ... don't use C-99/C++ style comments. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]forbid ptrace changes psr.ri to 3
IA64_PSR_RI is in IPSR_MASK, apparently by intent. If you want to change the behavior, you should simply change that mask. psr.ri is more complex because it is two bits where not all of the possible bit settings are defined. We definitely want to allow ptrace to set psr.ri (how else can we single step through instructions in a bundle?) But we should only allow psr.ri to be set to 0, 1, or 2. I don't see how changing IPSR_MASK can help solve this. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: scripts/mod/file2alias.c cross compile problem
-#define ACPI_ID_LEN 9
+#define ACPI_ID_LEN 16 /* only 9 bytes needed here, 16 bytes are used */
What will happen if someone uses more than 9 bytes? With the old
limit there would be a compile time error it someone initialized
with:
{PNP0C0ABCDEFGH, 0},
But if we change ACPI_ID_LEN the error will move to run-time.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: default the NUMA node distance when there is no ACPI SLIT
+ printk(KERN_INFO Building NUMA distance from ACPI 2.0 SLIT\n); This printk just looks like noise during boot. Surely this is normal behavior on a NUMA system? + printk(KERN_INFO No SLIT table, defaulting NUMA distance\n); But this one deserves more prominence than just KERN_INFO. I'd say that it deserves a KERN_ERR rating (without accurate information we'll make some highly questionable scheduling and memory placement decisions). On the other hand the only way for the end-user to fix this is to complain to their system vendor to fix firmware. So perhaps it is just a KERN_NOTICE. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: BINIT and physical address
Some help is needed with debugging of a hang. A system hits BINIT once in a while and the processors are all spinning on the address 0x0012C00 and if the HT is off the address becomes 0x002A80. This is a physical address captured on the bus by analyser. How can this address be decoded to find out what are the processors are spinning on? Natalie, The Linux kernel is typically loaded at physical address 0x40 (64MB) in one continuous block. If that address doesn't exist on your platform then elilo will get some other 64MB aligned address instead. You may be able to tell what is the state on you machine by looking at the TLB 'TR' registers: $ cat /proc/pal/cpu0/tr_info Look at the mappings for ITR0 and DTR0 ... they map the kernel. I say 'may' because some older systems didn't report TR maps correctly. Kernel modules loaded after boot will be all over the place. You can easily find the virtual addresses in use with: $ cat /proc/modules But there isn't a user-mode accessible way to convert them to physical addresses. You could write a small loadable driver to do this. It is unlikely that all the modules would end up with exactly the same physical addresses from one boot to the next, so you'll need to capture this information before the BINIT hits. You should also check whether the memory addresses in question were available for Linux to use. $ cat /proc/iomem Unless the addresses are marked as System RAM they wouldn't have been used by Linux ... so if you are spinning there, it is because they are part of firmware (PAL, SAL, EFI). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [429/2many] MAINTAINERS - SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
@@ -4084,6 +4084,7 @@ P:Pat Gefre M: [EMAIL PROTECTED] L: linux-ia64@vger.kernel.org S: Supported +F: Documentation/ia64/serial.txt SGI VISUAL WORKSTATION 320 AND 540 P: Andrey Panin Huh? Perhaps this should be: +F: drivers/serial/sn_console.c -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte
What about code-size? textdata bss dec hex filename 9499911 911620 1313065 11724596 b2e734 vmlinux-before textdata bss dec hex filename 9504047 911620 1313065 11728732 b2f75c vmlinux-after So about 4K extra. In the kernel I built (tiger_defconfig) there are 27 call-sites for __ia64_sync_icache_dcache ... so that amounts to about 150 bytes each ... or close to 10 bundles. Also, is it OK to call a function from all places where a set_pte() is being done? I'd hope so, but it's a really low-level operation... These are all from normal-looking C code ... so RSE must be valid. What other weird things might be be doing that would make it a problem for the new code to make a function call? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte
This version looks really clean. Thank for keeping working on
this through 9 versions!
A couple of small issues.
1) In arch/ia64/mm/init.c: __ia64_sync_icache_dcache()
- if (!pte_exec(pte))
- return; /* not an executable page... */
+ BUG_ON(!pte_exec(pte));
In this latest version the only route to this routine is from set_pte()
inside the test :
if (pte_exec(pteval) ) {
}
So this BUG_ON is now redundant.
2) In include/asm-ia64/pgtable.h
+ if (pte_exec(pteval) // flush only new executable page.
+ pte_present(pteval) // swap out ?
+ pte_user(pteval) // ignore kernel page
+ (!pte_present(*ptep) ||// do_no_page or swap in, migration,
+ pte_pfn(*ptep) != pte_pfn(pteval))) // do_wp_page(), page copy
+ /* load_module() calles flush_icache_range() explicitly*/
+ __ia64_sync_icache_dcache(pteval);
Just above this there is a comment saying that pte_exec() only works
when pte_present() is true. So we must re-order the conditions so that
we check that the pteval satisfies pte_present() before using either of
pte_exec() or pte_user() on it like this:
if (pte_present(pteval)
pte_exec(pteval)
pte_user(pteval)
I put in some crude counters to see whether we should check pte_exec() or
pte_user() next ... and it was very clear that the pte_exec() check gets
us out of the if() faster (at least during a kernel build).
I also compared how often the old code called lazy_mmu_prot_update()
with how often the new code calls __ia64_sync_icache_dcache() (again
using kernel build as my workload) ... and the answer is about the
same (less than 0.2% change ... probably less than run-to-run variation).
So now the only remaining task is to convince myself that this
new version covers all the cases.
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mmap broken?
There is a libunwind test-case that used to work fine but fails with recent kernels (e.g., 2.6.23-rc2). The problem is exhibited by the attached test program. It attempts to map the page right after the register-backing-store area with a no-access page. The mmap call succeeds, but the kernel incorrectly maps the no-access page not at the desired location, but at the next page. If I specify MAP_FIXED, the mmap() call succeeds, but I don't think MAP_FIXED should be necessary here. Anybody can think of any patches that would explain this change of behavior? It's perfectly legal for the OS to ignore the address if you don't specify the MAP_FIXED flag. The start argument to mmap is just a hint. Possibly some code is trying to leave a red-zone between mapped areas? Or perhaps we just have an off-by-one error when computing the address. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 0/2] SN platform needs platform_irq_to_vector?
Thanks for the info. Your patch looks good to me, along with the other change to sn_irq_to_vector(). Sounds like an Ack ... can one of you fold the changes into a new patch please. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/ia32/sys_ia32.c |1 - arch/ia64/kernel/iosapic.c | 19 ++- arch/ia64/kernel/irq_ia64.c | 17 ++--- arch/ia64/kernel/mca.c | 17 +++-- arch/ia64/kernel/setup.c|1 - arch/ia64/kernel/smp.c |8 +--- arch/ia64/kernel/time.c | 16 +++- arch/ia64/sn/kernel/io_common.c |2 +- arch/ia64/sn/kernel/setup.c |1 - arch/ia64/sn/kernel/sn2/timer.c |7 ++- 10 files changed, 50 insertions(+), 39 deletions(-) Avi Kivity (1): [IA64] Allow smp_call_function_single() to current cpu Christoph Lameter (2): [IA64] SN2: Fix up sn2_rtc clock [IA64] ITC: Reduce rating for ITC clock if ITCs are drifty Jesper Juhl (1): [IA64] Remove a few duplicate includes Kenji Kaneshige (3): [IA64] Fix registered interrupt check [IA64] Fix possible race in destroy_and_reserve_irq() [IA64] Fix wrong access to irq_desc[] in iosapic_register_intr(). Sam Ravnborg (1): [IA64] fix a few section mismatch warnings - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ia64 mmu_gather question
Answers to select questions (that I can do off the top of my head). In addition, however, I do have a question. I haven't tracked every bit of MM code in ia64 land yet and I'm wondering how are the page table translations faulted in ? via a SW miss handler ? Or some HW handler ? The page tables translations are inserted in s/w (by the VHPT miss handler in arch/ia64/kernel/ivt.S). Essentially the first TLB miss in a PMD range will end up here and will insert both the page mapping that we actually want, plus the mapping for the page table (so that a subsequent TLB miss on this address, or another address in the PMD range) can be serviced by the h/w VHPT walker (for as long as the page table mapping survives in the TLB). Is there some locking ? No locking. But we do have race detection. After we chase the PGDPUDPMDPTE pointers we insert the TLB entry. Then we retrace the pointer chain and make sure that the pte we find is still the same. If it isn't, then we purge the entry we just inserted and go for a full page fault. Time to tell bed-time stories to my daughter. More tomorrow (if someone else doesn't fill in the rest of the answers before I get back to this). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: regression on HP zx1 platform from ACPI autoload modulespatches
commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7
Oops. I cut pasted the wrong commit id. The fix went in as
commit 7091138fb762aed22317b4ff91eb211e7da3865c.
FYI, I did a git pull yesterday just before I hit this issue so I should
have had the latest stuff.
So this confuses me. Linus pulled this into his tree on Friday (IIRC), but
at the very latest on Saturday (as there is a commit *after* this one that
is dated 2007-07-28 19:29:37).
The patch that is in the tree appears to be identical to the one that
Thomas Renninger posted to this thread, and you confirmed as working.
So when you have a moment, please pull latest Linus tree. Confirm that
this patch is present:
$ grep hp_ioc_iommu_device_ids arch/ia64/hp/common/sba_iommu.c
static const struct acpi_device_id hp_ioc_iommu_device_ids[] = {
.ids= hp_ioc_iommu_device_ids,
$
and that it builds and boots for you.
Thanks
-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: regression on HP zx1 platform from ACPI autoload modulespatches
Tony, it looks like the patch has not hit Linus tree yet: Huh? I can see it in his tree via gitweb. Here's the patch: http://tinyurl.com/3csnu6 and the raw blob for sba_iommu.c: http://tinyurl.com/397cy6 [Scroll down to line 2018 and you'll see the new code in place]. Something very odd is happening. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Add support for vector domain breaks boot on x355
Trimmed limux-kernel and Linus from the Cc list ... this looks like an ia64 only issue at the moment. Hangs hard after ELILO boot: Uncompressing Linux...done Loading file \EFI\debian\boot\initrd-autobench.img...done Ouch. That isn't far at all. Are you using a serial console with a console=uart,io,0 or console=uart,mmio,0 to get the console up and running at the earliest point in the boot process? [It looks like the answer is no from the console log you attached]. If not, please try this (you can figure out the magic arguments by running dmesg | grep tty after a normal boot, and looking at Documentation/ia64/serial.txt). Looks like uart,io,0x3f8 will be the right magic for you. There are a couple of small extra patches from Kaneshige-san that aren't in Linus' tree yet. I just pushed them up to kernel.org so they should show up in my git tree there in the next few minutes. git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release So you might want to try with those patches included in case this has already been fixed. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: fix a few section mismatch warnings
Oops. You moved the multiply by sizeof(struct ia64_mca_cpu) up into the mca_bootmem() function to make it very specific to this use. But mutiply has higher precedence than addition. Oh crap - good catch. Shall I resubmit a corrected patch? Are there any other ways that we might tag the callsite to let modpost know that this instance is safe? Adding a call to a wrapper function in __init_refok space feels kludgy, and whatever comments you stick on that function, it is sitting there waiting for someone who shouldn't to make a call. If not ... then just make the mca_bootmem() function take no args. It can calculate the amount of memory, it can do the next bit too and return a result KERNEL_STACK_SIZE aligned too. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below. The fs/quota.c change (together with
the changes to arch/{ia64,x86_64}/Kconfig solve a build problem when
CONFIG_COMPAT=n
(discussed to death on LKML/linux-arch in the build fix for x86_64 thread).
Thanks!
-Tony
arch/ia64/Kconfig |3 +++
arch/ia64/hp/common/sba_iommu.c |7 ++-
arch/ia64/hp/sim/simscsi.c |2 +-
arch/ia64/kernel/acpi.c |9 -
arch/ia64/kernel/irq_ia64.c |5 -
arch/x86_64/Kconfig |3 +++
fs/quota.c |2 +-
7 files changed, 22 insertions(+), 9 deletions(-)
Kenji Kaneshige (3):
[IA64] Add sanity check into __bind_irq_vector
[IA64] Fix wrong assumption in acpi_gsi_to_irq
[IA64] Fix wrong return value in parse_vector_domain
Thomas Renninger (1):
[IA64] Use new acpi_device_id struct for HID init in
ia64/hp/common/sba_iommu.c
Tony Luck (1):
[IA64] Fix build failure in fs/quota.c
Yoann Padioleau (1):
[IA64] Compare pointer against NULL, not '0'
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ia64: fix build failure on fs/quota.c
This issue wandered off onto a long thread build fix for x86_64 which died out without a final patch. Here's the summary: +#if defined(CONFIG_X86_64) || (defined(CONFIG_IA64) defined(CONFIG_COMPAT)) It was pointed out that x86-64 also has a CONFIG_COMPAT, so the right #ifdef mess would be: #if defined(CONFIG_COMPAT) (defined(CONFIG_IA64) || defined(CONFIG_X86_64)) But this was thought too ugly. Andi Kleen proposed making a new CONFIG variable for this situation: CONFIG_COMPAT_FOR_U64_ALIGMNENT which could be set in ia64 and x86-64 Kconfig files with: config COMPAT_FOR_U64_ALIGMNENT def_bool COMPAT So the C-code would simply have: #if defined(COMPAT_COMPAT_FOR_U64_ALIGMNENT) (IIRC the syntax correctly). Peter Anvin had some worries about future issues ... but I think he agreed that this was Ok. Anyone still have any objections to this? Signed-off-by: Tony Luck [EMAIL PROTECTED] diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 36c7b96..21aa4fc 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -425,6 +425,9 @@ config COMPAT depends on IA32_SUPPORT default y +config COMPAT_FOR_U64_ALIGNMENT + def_bool COMPAT + config IA64_MCA_RECOVERY tristate MCA recovery from errors other than TLB. diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 45f82ae..ffa0364 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -765,6 +765,9 @@ config COMPAT depends on IA32_EMULATION default y +config COMPAT_FOR_U64_ALIGNMENT + def_bool COMPAT + config SYSVIPC_COMPAT bool depends on COMPAT SYSVIPC diff --git a/fs/quota.c b/fs/quota.c index e6577ac..99b24b5 100644 --- a/fs/quota.c +++ b/fs/quota.c @@ -387,7 +387,7 @@ asmlinkage long sys_quotactl(unsigned int cmd, const char __user *special, qid_t return ret; } -#if defined(CONFIG_X86_64) || defined(CONFIG_IA64) +#if defined(CONFIG_COMPAT_FOR_U64_ALIGNMENT) /* * This code works only for 32 bit quota tools over 64 bit OS (x86_64, ia64) * and is necessary due to alignment problems. - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linus' tree broken?
Have anyone else had seen issues with the Linus git tree failing to boot? I'm trying a pull as of this morning and it seems to hang when it's brining up the ethernet devices. It's not locking up, just the boot scripts never continues - happens both on SLES10 and FC7 roots :( Just wanted to check before spending real time on it. Pulled Linus' tree (the -rc1 commit is at the head) and it built and booted on my tiger. Only new strange stuff in the dmesg is a lot of ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] messages (this pair of message repeats 16 times) -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linus' tree broken?
I heard from John Keller that he had problems too. What kind of userland are you running? I've seen hanging around udev. That box has a RHEL4.5 userland. I'll try it on some others. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linus' tree broken?
I heard from John Keller that he had problems too. What kind of userland are you running? I've seen hanging around udev. I took 2.6.23-rc1 over to a Hitachi box running FC7 userspace. It booted just fine there. Maybe we broke SN2? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linus' tree broken?
I am hitting this on my rx2620, rx6600 and rx2600 (i.e. everywhere I have tried it) and the bisection is showing that it appears to have been broken before -rc1. Are you booting a generic kernel, or a zx1_defconfig based one? Look back in the linux-ia64 archives a few days for a post titled: Regression in serial console on ia64 after 2.6.22 Perhaps you are hitting this? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] fix ia64 clocksource
I need to make the cleanups Tony identified. After that how would you like to proceed? Combining your patch 1/3 and my 1/2 seems logical. I've done the cleanup, and merged Seto-san's parts 1,2,3 with your part 1, and updated it all for the tip of Linus' tree. Result is below. Part 2 stayed the same, except that I also deleted Documentation/time_interpolators.txt I'm going to send both to Linus later today ... so read fast and shout if I botched the merge. Time taken for a single gettimeofday() call via the fsys.S path has increased by about 8 cycles, but this would only be significant for applications doing 1,000,000 gettimeofday calls per second. The scalability problems are so bad that I can't even get close to that rate on 4 cpus (peak cumulative rate is about 600,000). The patched system still has problems, but scalabilty is better (4 cpus can get to 1,100,000 cumulative calls per second). -Tony commit 89f8d0677c72742767f98b9f5fcfbd575e73d0ae Author: Tony Luck [EMAIL PROTECTED] Date: Wed Jul 18 15:38:51 2007 -0700 [IA64] Convert to generic timekeeping/clocksource This is a merge of Peter Keilty's initial patch for this with Hidetoshi Seto's fixes and scaling improvements. Signed-off-by: Tony Luck [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9a54148..68115d7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1154,6 +1154,8 @@ and is between 256 and 4096 characters. It is defined in the file nointroute [IA-64] + nojitter[IA64] Disables jitter checking for ITC timers. + nolapic [IA-32,APIC] Do not enable or use the local APIC. nolapic_timer [IA-32,APIC] Do not use the local APIC timer. diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 616c96e..36c7b96 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -62,7 +62,11 @@ config GENERIC_CALIBRATE_DELAY bool default y -config TIME_INTERPOLATION +config GENERIC_TIME + bool + default y + +config GENERIC_TIME_VSYSCALL bool default y diff --git a/arch/ia64/configs/bigsur_defconfig b/arch/ia64/configs/bigsur_defconfig index 90e9c2e..9eb48c0 100644 --- a/arch/ia64/configs/bigsur_defconfig +++ b/arch/ia64/configs/bigsur_defconfig @@ -85,7 +85,7 @@ CONFIG_MMU=y CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y diff --git a/arch/ia64/configs/gensparse_defconfig b/arch/ia64/configs/gensparse_defconfig index 0d29aa2..3a9ed95 100644 --- a/arch/ia64/configs/gensparse_defconfig +++ b/arch/ia64/configs/gensparse_defconfig @@ -86,7 +86,7 @@ CONFIG_MMU=y CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y diff --git a/arch/ia64/configs/sim_defconfig b/arch/ia64/configs/sim_defconfig index d9146c3..c420d9f 100644 --- a/arch/ia64/configs/sim_defconfig +++ b/arch/ia64/configs/sim_defconfig @@ -86,7 +86,7 @@ CONFIG_MMU=y CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y diff --git a/arch/ia64/configs/sn2_defconfig b/arch/ia64/configs/sn2_defconfig index 64e951d..4c9ffc4 100644 --- a/arch/ia64/configs/sn2_defconfig +++ b/arch/ia64/configs/sn2_defconfig @@ -93,7 +93,7 @@ CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_DMI=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y diff --git a/arch/ia64/configs/tiger_defconfig b/arch/ia64/configs/tiger_defconfig index a144693..e208747 100644 --- a/arch/ia64/configs/tiger_defconfig +++ b/arch/ia64/configs/tiger_defconfig @@ -98,7 +98,7 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_DMI=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y diff --git a/arch/ia64/configs/zx1_defconfig b/arch/ia64/configs/zx1_defconfig index 1c7955c..4a060fc 100644 --- a/arch/ia64/configs/zx1_defconfig +++ b/arch/ia64/configs/zx1_defconfig @@ -96,7 +96,7 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_TIME_INTERPOLATION=y +CONFIG_GENERIC_TIME=y CONFIG_DMI=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y diff --git a/arch/ia64/defconfig b/arch/ia64/defconfig index 90bd960..461f8ee 100644 --- a/arch/ia64/defconfig +++ b/arch/ia64/defconfig @@ -98,7 +98,7
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. I'm touching a few non-ia64 files (they are at the bottom of the diffstat) in here to delete the CONFIG_TIME_INTERPOLATION code that nobody except ia64 used. Thanks! -Tony Documentation/time_interpolators.txt | 40 - Documentation/kernel-parameters.txt |5 arch/ia64/Kconfig |6 arch/ia64/configs/bigsur_defconfig|2 arch/ia64/configs/gensparse_defconfig |2 arch/ia64/configs/sim_defconfig |2 arch/ia64/configs/sn2_defconfig |2 arch/ia64/configs/tiger_defconfig | 322 +++- arch/ia64/configs/zx1_defconfig |2 arch/ia64/defconfig | 338 - arch/ia64/kernel/asm-offsets.c| 35 - arch/ia64/kernel/cyclone.c| 46 + arch/ia64/kernel/entry.S |2 arch/ia64/kernel/fsys.S | 179 +++--- arch/ia64/kernel/fsyscall_gtod_data.h | 23 arch/ia64/kernel/iosapic.c| 872 +++--- arch/ia64/kernel/irq.c|2 arch/ia64/kernel/irq_ia64.c | 391 --- arch/ia64/kernel/msi_ia64.c | 29 - arch/ia64/kernel/smpboot.c|4 arch/ia64/kernel/time.c | 96 +++ arch/ia64/sn/kernel/sn2/timer.c | 29 - drivers/acpi/processor_idle.c |4 drivers/char/hpet.c | 70 +- include/asm-ia64/hw_irq.h | 20 include/asm-ia64/iosapic.h|6 include/asm-ia64/irq.h|9 include/asm-ia64/rwsem.h |4 include/asm-ia64/unistd.h |2 include/linux/clocksource.h |6 include/linux/timex.h | 60 -- kernel/time.c | 88 --- kernel/time/ntp.c | 10 kernel/time/timekeeping.c |4 kernel/timer.c| 188 --- 35 files changed, 1338 insertions(+), 1562 deletions(-) Bob Picco (1): [IA64] remove time interpolator David Chinner (1): [IA64] fallocate system call Robert P. J. Day (1): [IA64] Prevent people from directly including asm/rwsem.h. Tony Luck (2): [IA64] refresh some config files for 64K pagesize [IA64] Convert to generic timekeeping/clocksource Yasuaki Ishimatsu (13): [IA64] Remove block structure for locking in iosapic.c [IA64] Remove duplicated members in iosapic_rte_info [IA64] Cleanup lock order in iosapic_register_intr [IA64] Use per iosapic lock for indirect iosapic register access [IA64] Use dynamic irq for iosapic interrupts [IA64] Fix invalid irq vector assumption for iosapic [IA64] Check if irq is sharable [IA64] Add mapping table between irq and vector [IA64] Add support for vector domain [IA64] Support irq migration across domain [IA64] Enable percpu vector domain for IA64_GENERIC [IA64] Enable percpu vector domain for IA64_DIG [IA64] Delete iosapic_free_rte() - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: revising [patch] add arch_ptrace_stop() hook and use it on ia64
Is anyone ia64-savy interested in revising the patch posted by David in http://marc.info/?l=linux-kernelm=111575781225495w=2 ? This would allow for converting ia64 to the generic ptrace code, something I would love to see. Aren't we heading towards utrace as a ptrace replacement? -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull on ia64 linux tree
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony arch/ia64/hp/common/sba_iommu.c | 20 ++-- arch/ia64/hp/sim/boot/fw-emu.c |5 - arch/ia64/hp/sim/simserial.c|4 arch/ia64/kernel/fsys.S |4 +++- arch/ia64/sn/kernel/sn2/sn_hwperf.c |3 ++- include/asm-ia64/ioctls.h |4 include/asm-ia64/termbits.h |5 - include/asm-ia64/termios.h |6 -- 8 files changed, 35 insertions(+), 16 deletions(-) Alan Cox (1): [IA64] arbitary speed tty ioctl support Hidetoshi Seto (1): [IA64] ar.itc access must really be after xtime_lock.sequence has been read Mark Goodwin (1): [IA64] correctly count CPU objects in the ia64/sn hwperf interface Terry Loftin (1): [IA64] use machvec=dig on hpzx1 platforms Tony Luck (1): [IA64] Clean away some code inside some non-existent CONFIG ifdefs - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH take3 0/12] Support vector domain on ia64
Getting close now. New (I think it's new, I didn't notice it last time, but I may have missed it in the other build noise) concern while compiling this version was the warning: arch/ia64/kernel/iosapic.c:597: warning: 'iosapic_free_rte' defined but not used This isn't spurious, the only call to iosapic_free_rte() has been removed, but there is still a call to iosapic_alloc_rte() ... which means we must have a memory leak. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ia64 clocksource
Half a dozen whines from GIT about whitespace (irrelevent paces followed by a TAB). Here are the lines: + /* Sort out mult/shift values: */ + clocksource_register(clocksource_itc); +#definewrite_counter(V, MC)writel(V, MC) + hpet_mctr = (void __iomem *)hpetp-hp_hpet-hpet_mc; + clocksource_hpet.mult = clocksource_hz2mult(hpetp-hp_tick_freq, + clocksource_register(clocksource_hpet); Part 2 of the patch should also delete Documentation/time_interpolators.txt Seto-san: The fsys.S changes need some close review and you've been looking at this code recently ... so you are declared an independent expert :-) The problem that you found with out of order read of the xtime_lock.sequence (now gtod_lock.sequence) is probably alive and well in this code too (even though the read of ar.itc is later, there is no consumption or r28 before we do so). On the subject of whether to push into 2.6.23 or cook in -mm until 2.6.24 ... I'm not sure how much benefit we'd get from the delay. Anyone want to stand up and be counted as running serious testing on -mm kernels on ia64? I fear that the amount of extra testing that we'd get is really quite small. 2.6.23-rc1 is only a week away, and this code is very subtle in places ... I'm nervous about this. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter
Here are 2 pending patches I'm pushing : - [PATCH] ia64: Scalability improvement of gettimeofday with jitter compensation Bob says his (Pete's) patches will be ready soon (Sunday) so I'll wait for them to make sure this all fits together cleanly. This is a definite 2.6.23 candidate. - [PATCH] fsys_gettimeofday leaps days if it runs with nojitter Applied. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/12] Add mapping table between irq and vector
I found why my machine sometimes crashes during boot with the
vector domain patch applied. The problem is a spurious interrupt
that causes a wild pointer reference, and thus a crash.
The problem occurs because unused entries in the percpu vector_irq
array are filled with VECTOR_IRQ_UNASSIGNED (-1). When a
spurious interrupt occurs ia64_handle_irq() calls:
generic_handle_irq(local_vector_to_irq(vector))
and the local_vector_to_irq(vector) part return -1, which is all bad.
If we initialize the unused entried to IA64_SPURIOUS_INT_VECTOR
instead, then we get the orginal behaviour: a message is printed and
the vector/irq is disabled.
As a bonus we can delete the VECTOR_IRQ_UNASSIGNED define
altogether (which is all too easy to confuse with IRQ_VECTOR_UNASSIGNED).
So I applied this patch onto the end of your sequence (but you should
merge it into patch8/12).
-Tony
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index 91abd1b..ea19ccd 100644
--- a/arch/ia64/kernel/irq_ia64.c
+++ b/arch/ia64/kernel/irq_ia64.c
@@ -47,7 +47,6 @@
#define IRQ_DEBUG 0
#define IRQ_VECTOR_UNASSIGNED (0)
-#define VECTOR_IRQ_UNASSIGNED (-1)
#define IRQ_UNUSED (0)
#define IRQ_USED (1)
@@ -83,7 +82,7 @@ struct irq_cfg irq_cfg[NR_IRQS] __read_mostly = {
};
DEFINE_PER_CPU(int[IA64_NUM_VECTORS], vector_irq) = {
- [0 ... IA64_NUM_VECTORS - 1] = VECTOR_IRQ_UNASSIGNED
+ [0 ... IA64_NUM_VECTORS - 1] = IA64_SPURIOUS_INT_VECTOR
};
static cpumask_t vector_table[IA64_MAX_DEVICE_VECTORS] = {
@@ -168,7 +167,7 @@ static void __clear_irq_vector(int irq)
domain = irq_cfg[irq].domain;
cpus_and(mask, irq_cfg[irq].domain, cpu_online_map);
for_each_cpu_mask(cpu, mask)
- per_cpu(vector_irq, cpu)[vector] = VECTOR_IRQ_UNASSIGNED;
+ per_cpu(vector_irq, cpu)[vector] = IA64_SPURIOUS_INT_VECTOR;
irq_cfg[irq].vector = IRQ_VECTOR_UNASSIGNED;
irq_cfg[irq].domain = CPU_MASK_NONE;
irq_status[irq] = IRQ_UNUSED;
@@ -238,7 +237,7 @@ void __setup_vector_irq(int cpu)
/* Clear vector_irq */
for (vector = 0; vector IA64_NUM_VECTORS; ++vector)
- per_cpu(vector_irq, cpu)[vector] = VECTOR_IRQ_UNASSIGNED;
+ per_cpu(vector_irq, cpu)[vector] = IA64_SPURIOUS_INT_VECTOR;
/* Mark the inuse vectors */
for (irq = 0; irq NR_IRQS; ++irq) {
if (!cpu_isset(cpu, irq_cfg[irq].domain))
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter
I'm guessing here ... I haven't cross-checked with the architects. I'll be glad if we can get a comment from Intel's architects. I talked this through with an architect, and I'm right. In the sequence: ld4.acq rM = [rN] ;; mov rP = ar.itc there are no dependencies, so the read of ar.itc can occur IMMEDIATELY after the load issues. Consuming the result of the load in between will create a dependency ... so the timestamp will be taken as we want it, after the load. So I can apply this patch (moving the and r28 = ~1,r28). What other time patches are you still pushing? The time interpolator changes that were predicted still look like they are pending somewhere (kernel/timer.c hasn't been changed). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Another git pull on ia64 linux tree - one patch to unbreak ia64 build
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release This will update the files shown below. Thanks! -Tony include/asm-ia64/pci.h | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) Tony Luck (1): [IA64] Un-break ia64 build - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [IA64] [kdump] machveg=dig on hpzx1 platforms
Here is a patch to do that. We use this internally, but I had forgotten to post it. Terry, Just got to applying some older patches ... perhaps this one has been sitting too long because I had some apply build problems with it. Building with arch/ia64/configs/zx1_defconfig and with this patch hand applied I get: LD .tmp_vmlinux1 arch/ia64/hp/common/built-in.o(.init.text+0xcc2): In function `sba_init': : undefined reference to `swiotlb_late_init_with_default_size' arch/ia64/hp/common/built-in.o(.init.text+0xd02): In function `sba_init': : undefined reference to `machvec_init' make: *** [.tmp_vmlinux1] Error 1 sba_init() uses these routines inside #ifdef CONFIG_I64_GENERIC, perhaps you need to do the same? Other issues: 1) No Signed-off-by 2) +#include linux/crash_dump.h We usually group all the linux/* includes together before the asm/* ones 3) +extern int swiotlb_late_init_with_default_size (size_t size); extern declarations in .c files are frowned upon. This should be in a header file, which should be included (though I see that this guideline has already been ignored as you were just moving the declaration). -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH take2 0/13] Support vector domain on ia64
I have never seen these messages. I will check them. This seems to be an intermittent problem. I just got my serial console working again to get you a full stack trace, and the first time I booted the kernel with your vector domain patch it didn't crash. Second boot did crash. Here's the stack trace part of the console log: CPU 9: synchronized ITC with CPU 0 (last diff 0 cycles, maxerr 159 cycles) CPU 10: synchronized ITC with CPU 0 (last diff 0 cycles, maxerr 40 cycles) CPU 11: synchronized ITC with CPU 0 (last diff 0 cycles, maxerr 161 cycles) Unable to handle kernel paging request at virtual address a08100974780 swapper[0]: Oops 8813272891392 [1] Modules linked in: Pid: 0, CPU 12, comm: swapper psr : 101008022018 ifs : 8389 ip : [a00100011c50]Not tainted ip is at ia64_handle_irq+0x190/0x2a0 unat: pfs : 03e00389 rsc : 0003 rnat: bsps: pr : 95a5 ldrs: ccv : 0fff fpsr: 0009804c0270033f csd : ssd : b0 : a00100011b10 b6 : a0013320 b7 : e0007fb1bde0 f6 : 0 f7 : 1003e00017000 f8 : 0 f9 : 0 f10 : 0 f11 : 0 r1 : a00100c2db30 r2 : 0001 r3 : r8 : 00fd r9 : 00fc r10 : r11 : 0009804c0270033f r12 : e00180eafc60 r13 : e00180ea r14 : 4b00 r15 : 0428 r16 : r17 : a00100a45c58 r18 : e0007fe131b0 r19 : e0007fb1bde0 r20 : a00100a4b6a0 r21 : a0010097 r22 : a08100974780 r23 : 007fff80 r24 : a00100974800 r25 : a00100a2ef30 r26 : e001800c004c r27 : 004c r28 : e001800c r29 : r30 : e001800d r31 : a00100a44ea0 Call Trace: [a00100012bb0] show_stack+0x50/0xa0 sp=e00180eaf830 bsp=e00180ea0d28 [a00100013480] show_regs+0x820/0x840 sp=e00180eafa00 bsp=e00180ea0ce0 [a001000370c0] die+0x1a0/0x280 sp=e00180eafa00 bsp=e00180ea0c98 [a00100061230] ia64_do_page_fault+0x810/0x900 sp=e00180eafa00 bsp=e00180ea0c38 [a001bcc0] ia64_leave_kernel+0x0/0x270 sp=e00180eafa90 bsp=e00180ea0c38 [a00100011c50] ia64_handle_irq+0x190/0x2a0 sp=e00180eafc60 bsp=e00180ea0be8 [a001bcc0] ia64_leave_kernel+0x0/0x270 sp=e00180eafc60 bsp=e00180ea0be8 [a001000541d0] unlock_ipi_calllock+0x30/0x60 sp=e00180eafe30 bsp=e00180ea0bd0 [a00100055fb0] start_secondary+0x2d0/0x580 sp=e00180eafe30 bsp=e00180ea0b80 [a00189e0] __end_ivt_text+0x6c0/0x6f0 sp=e00180eafe30 bsp=e00180ea0b80 Kernel panic - not syncing: Aiee, killing interrupt handler! The bit of ia64_handle_irq where we crashed looks like this: a00100011c30: 02 80 00 34 10 10 [MII] ld4 r16=[r26] a00100011c36: 00 00 00 02 00 e0 nop.i 0x0;; a00100011c3c: 02 c1 7d 53 dep.z r23=r16,7,32 a00100011c40: 03 00 00 00 01 00 [MII] nop.m 0x0 a00100011c46: 70 02 40 00 42 c0 mov r39=r16;; a00100011c4c: 72 c1 00 80 add r22=r23,r24;; a00100011c50: 0d 70 00 2c 18 10 [MFI] ld8 r14=[r22] r22 has the very bad value of 0xa08100974780 ... so we die. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] fsys_gettimeofday leaps days if it runs with nojitter
ld4.acq r28 = [r29] // xtime_lock.sequence. Must come first for locking purposes + ;; (p8) mov r2 = ar.itc // CPU_TIMER. 36 clocks latency!!! The .acq only causes ordering w.r.t. data accesses. The read from ar.itc isn't a data access, so potentially it could still float before the ld4.acq. Consuming the value loaded into r28 presumably has to ensure that the load completes though. I'm guessing here ... I haven't cross-checked with the architects. Does moving the and r28 = ~1,r28 up into this slot hurt latency for a single call to gettimeofday()? Presumably it will if xtime_lock.sequence is not in the cache. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH take2 0/13] Support vector domain on ia64
This seems to be an intermittent problem. One more note on that ... my test system often kicks out some Unexpected irq vector 0x13 on CPU xx! messages as it boots. Looking at the logs of previous boots, I see between zero and two such messages in the last few dozen boots, When the kernel with the vector-domain patch applied successfully booted this morning, this was one of the times where there were no unexpected interrupts. Since the crash looks like it occurred while dereferencing the desc = irq_desq + irq in generic_handle_irq(), I think this is most likely related. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH take2 0/13] Support vector domain on ia64
Here is a series of patches for ia64 vector domain. By these patches, we can use more than 256 irqs. The patchset is based on existing x86-64 vector domain code. This is for 2.6.22-rc5 and I tested them on my ia64 box. There are a few whitespace issues (spacetab) amongst these patches (I think in parts 6 13). Here's the summary of the broken bits: + unsigned intgsi_base; /* GSI base */ + unsigned short num_rte;/* # of RTEs on this IOSAPIC */ --- + unsigned intgsi_base; /* GSI base */ + unsigned short num_rte;/* # of RTEs on this IOSAPIC */ + if (irq 0) --- + if (irq 0) +#define IRQ_RSVD (2) --- +#define IRQ_RSVD (2) + return vector; --- + return vector; I also got two build errors which broke several configurations: tiger-up (this is arch/ia64/configs/tiger_defconfig with CONFIG_SMP deleted) arch/ia64/kernel/irq_ia64.c: In function `parse_vector_domain': arch/ia64/kernel/irq_ia64.c:270: error: `no_int_routing' undeclared (first use in this function) arch/ia64/kernel/irq_ia64.c:270: error: (Each undeclared identifier is reported only once arch/ia64/kernel/irq_ia64.c:270: error: for each function it appears in.) make[1]: *** [arch/ia64/kernel/irq_ia64.o] Error 1 generic-up (arch/ia64/defconfig with CONFIG_SMP deleted) same error as tiger-up generic-smp (arch/ia64-defconfig) CC arch/ia64/kernel/asm-offsets.s In file included from include/linux/hardirq.h:7, from include/linux/interrupt.h:11, from include/asm-ia64/mca.h:16, from arch/ia64/kernel/asm-offsets.c:15: include/asm/hardirq.h:30:3: #error HARDIRQ_BITS is too low! make[1]: *** [arch/ia64/kernel/asm-offsets.s] Error 1 sn2-smp (arch/ia64/configs/sn2_defconfig) same error as generic-smp generic-sparse (arch/ia64/configs/gensparse_defconfig) same error as generic-smp allnoconfig (make allnoconfig) same error as tiger-up Booting the arch/ia64/configs/tiger_defconfig kernel on my 4-socket Montecito tiger platform, I get an almost immediate oops. I don't have the full stack backtrace, but the highlights were: die ia64_do_page_fault ia64_leave_kernel ia64_handle_irq ia64_leave_kernel unlock_ipi_calllock start_secondary I tried both with and without the new vector=percpu boot option (which needs to be documented in Documentation/kernel-parameters.txt), but it dies with the same stack trace both ways. -Tony - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
