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

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

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 ...

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

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

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

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 =

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

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

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

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

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

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

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

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

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

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

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

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

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]

[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

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).

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

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

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

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

[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

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().

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

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

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

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.

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

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:

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 +-

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,

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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 ---

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

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

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

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.

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

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

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

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:

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 [

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

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))) //

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

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

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.

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

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 -

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

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... */ +

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

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

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 ++-

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

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

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].

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

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

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

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:

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

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

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

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:

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

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

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

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 -

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

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

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

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

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,

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

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

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

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

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

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

  1   2   3   >