1. 27 May, 2010 2 commits
  2. 08 Feb, 2010 1 commit
    • Tony Luck's avatar
      [IA64] Remove COMPAT_IA32 support · 32974ad4
      Tony Luck authored
      This has been broken since May 2008 when Al Viro killed altroot support.
      Since nobody has complained, it would appear that there are no users of
      this code (A plausible theory since the main OSVs that support ia64 prefer
      to use the IA32-EL software emulation).
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  3. 17 Jun, 2009 1 commit
    • Matthew Wilcox's avatar
      [IA64] Convert ia64 to use int-ll64.h · e088a4ad
      Matthew Wilcox authored
      It is generally agreed that it would be beneficial for u64 to be an
      unsigned long long on all architectures.  ia64 (in common with several
      other 64-bit architectures) currently uses unsigned long.  Migrating
      piecemeal is too painful; this giant patch fixes all compilation warnings
      and errors that come as a result of switching to use int-ll64.h.
      Note that userspace will still see __u64 defined as unsigned long.  This
      is important as it affects C++ name mangling.
      [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
       u64 for start/end rather than unsigned long]
      Signed-off-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  4. 15 Jun, 2009 1 commit
  5. 16 Mar, 2009 1 commit
  6. 19 Feb, 2009 2 commits
    • Alex Chiang's avatar
      [IA64] Remove redundant cpu_clear() in __cpu_disable path · c0acdea2
      Alex Chiang authored
      The second call to cpu_clear() is redundant, as we've already removed
      the CPU from cpu_online_map before calling migrate_platform_irqs().
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
    • Alex Chiang's avatar
      [IA64] Revert "prevent ia64 from invoking irq handlers on offline CPUs" · 66db2e63
      Alex Chiang authored
      This reverts commit e7b14036.
      Commit e7b14036 removes the targetted disabled CPU from the
      cpu_online_map after calls to migrate_platform_irqs and fixup_irqs.
      Paul McKenney states that the reasoning behind the patch was to
      prevent irq handlers from running on CPUs marked offline because:
      	RCU happily ignores CPUs that don't have their bits set in
      	cpu_online_map, so if there are RCU read-side critical sections
      	in the irq handlers being run, RCU will ignore them.  If the
      	other CPUs were running, they might sequence through the RCU
      	state machine, which could result in data structures being
      	yanked out from under those irq handlers, which in turn could
      	result in oopses or worse.
      Unfortunately, both ia64 functions above look at cpu_online_map to find
      a new CPU to migrate interrupts onto. This means we can potentially
      migrate an interrupt off ourself back to... ourself. Uh oh.
      This causes an oops when we finally try to process pending interrupts on
      the CPU we want to disable. The oops results from calling __do_IRQ with
      a NULL pt_regs:
      Unable to handle kernel NULL pointer dereference (address 0000000000000040)
      Call Trace:
       [<a000000100016930>] show_stack+0x50/0xa0
                                      sp=e0000009c922fa00 bsp=e0000009c92214d0
       [<a0000001000171a0>] show_regs+0x820/0x860
                                      sp=e0000009c922fbd0 bsp=e0000009c9221478
       [<a00000010003c700>] die+0x1a0/0x2e0
                                      sp=e0000009c922fbd0 bsp=e0000009c9221438
       [<a0000001006e92f0>] ia64_do_page_fault+0x950/0xa80
                                      sp=e0000009c922fbd0 bsp=e0000009c92213d8
       [<a00000010000c7a0>] ia64_native_leave_kernel+0x0/0x270
                                      sp=e0000009c922fc60 bsp=e0000009c92213d8
       [<a0000001000ecdb0>] profile_tick+0xd0/0x1c0
                                      sp=e0000009c922fe30 bsp=e0000009c9221398
       [<a00000010003bb90>] timer_interrupt+0x170/0x3e0
                                      sp=e0000009c922fe30 bsp=e0000009c9221330
       [<a00000010013a800>] handle_IRQ_event+0x80/0x120
                                      sp=e0000009c922fe30 bsp=e0000009c92212f8
       [<a00000010013aa00>] __do_IRQ+0x160/0x4a0
                                      sp=e0000009c922fe30 bsp=e0000009c9221290
       [<a000000100012290>] ia64_process_pending_intr+0x2b0/0x360
                                      sp=e0000009c922fe30 bsp=e0000009c9221208
       [<a0000001000112d0>] fixup_irqs+0xf0/0x2a0
                                      sp=e0000009c922fe30 bsp=e0000009c92211a8
       [<a00000010005bd80>] __cpu_disable+0x140/0x240
                                      sp=e0000009c922fe30 bsp=e0000009c9221168
       [<a0000001006c5870>] take_cpu_down+0x50/0xa0
                                      sp=e0000009c922fe30 bsp=e0000009c9221148
       [<a000000100122610>] stop_cpu+0xd0/0x200
                                      sp=e0000009c922fe30 bsp=e0000009c92210f0
       [<a0000001000e0440>] kthread+0xc0/0x140
                                      sp=e0000009c922fe30 bsp=e0000009c92210c8
       [<a000000100014ab0>] kernel_thread_helper+0xd0/0x100
                                      sp=e0000009c922fe30 bsp=e0000009c92210a0
       [<a00000010000a4c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000009c922fe30 bsp=e0000009c92210a0
      I don't like this revert because it is fragile. ia64 is getting lucky
      because we seem to only ever process timer interrupts in this path, but
      if we ever race with an IPI here, we definitely use RCU and have the
      potential of hitting an oops that Paul describes above.
      Patching ia64's timer_interrupt() to check for NULL pt_regs is
      insufficient though, as we still hit the above oops.
      As a short term solution, I do think that this revert is the right
      answer. The revert hold up under repeated testing (24+ hour test runs)
      with this setup:
      	- 8-way rx6600
      	- randomly toggling CPU online/offline state every 2 seconds
      	- running CPU exercisers, memory hog, disk exercisers, and
      	  network stressors
      	- average system load around ~160
      In the long term, we really need to figure out why we set pt_regs = NULL
      in ia64_process_pending_intr(). If it turns out that it is unnecessary
      to do so, then we could safely re-introduce e7b14036
       (along with some
      other logic to be smarter about migrating interrupts).
      One final note: x86 also removes the disabled CPU from cpu_online_map
      and then re-enables interrupts for 1ms, presumably to handle any pending
      arch/x86/kernel/irq_32.c (and irq_64.c):
      	[remove cpu from cpu_online_map]
      			[break CPU affinities]
      So they are doing implicitly what ia64 is doing explicitly.
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
  7. 13 Dec, 2008 2 commits
    • Rusty Russell's avatar
      cpumask: make irq_set_affinity() take a const struct cpumask · 0de26520
      Rusty Russell authored
      Impact: change existing irq_chip API
      Not much point with gentle transition here: the struct irq_chip's
      setaffinity method signature needs to change.
      Fortunately, not widely used code, but hits a few architectures.
      Note: In irq_select_affinity() I save a temporary in by mangling
      irq_desc[irq].affinity directly.  Ingo, does this break anything?
      (Folded in fix from KOSAKI Motohiro)
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Acked-by: default avatarIngo Molnar <mingo@redhat.com>
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: jeremy@xensource.com
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    • Rusty Russell's avatar
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell authored
      Impact: cleanup
      Each SMP arch defines these themselves.  Move them to a central
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
  8. 10 Sep, 2008 1 commit
  9. 08 Sep, 2008 1 commit
    • Manfred Spraul's avatar
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul authored
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: default avatarManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  10. 25 Aug, 2008 1 commit
  11. 12 Aug, 2008 1 commit
    • Tony Luck's avatar
      [IA64] Ensure cpu0 can access per-cpu variables in early boot code · 10617bbe
      Tony Luck authored
      ia64 handles per-cpu variables a litle differently from other architectures
      in that it maps the physical memory allocated for each cpu at a constant
      virtual address (0xffffffffffff0000). This mapping is not enabled until
      the architecture specific cpu_init() function is run, which causes problems
      since some generic code is run before this point. In particular when
      CONFIG_PRINTK_TIME is enabled, the boot cpu will trap on the access to
      per-cpu memory at the first printk() call so the boot will fail without
      the kernel printing anything to the console.
      Fix this by allocating percpu memory for cpu0 in the kernel data section
      and doing all initialization to enable percpu access in head.S before
      calling any generic code.
      Other cpus must take care not to access per-cpu variables too early, but
      their code path from start_secondary() to cpu_init() is all in arch/ia64
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  12. 26 Jun, 2008 2 commits
  13. 27 May, 2008 1 commit
  14. 29 Apr, 2008 1 commit
  15. 09 Apr, 2008 1 commit
  16. 06 Feb, 2008 2 commits
    • Adrian Bunk's avatar
      idle_regs() must be __cpuinit · 6b2fb3c6
      Adrian Bunk authored
      Fix the following section mismatch with CONFIG_HOTPLUG=n,
      WARNING: vmlinux.o(.text+0x399a6): Section mismatch: reference to .init.text.5:idle_regs (between 'fork_idle' and 'get_task_mm')
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Adrian Bunk's avatar
      calibrate_delay() must be __cpuinit · 6c81c32f
      Adrian Bunk authored
      calibrate_delay() must be __cpuinit, not __{dev,}init.
      I've verified that this is correct for all users.
      While doing the latter, I also did the following cleanups:
      - remove pointless additional prototypes in C files
      - ensure all users #include <linux/delay.h>
      This fixes the following section mismatches with CONFIG_HOTPLUG=n,
      WARNING: vmlinux.o(.text+0x1128d): Section mismatch: reference to .init.text.1:calibrate_delay (between 'check_cx686_slop' and 'set_cx86_reorder')
      WARNING: vmlinux.o(.text+0x25102): Section mismatch: reference to .init.text.1:calibrate_delay (between 'smp_callin' and 'cpu_coregroup_map')
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Christian Zankel <chris@zankel.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 05 Feb, 2008 1 commit
  18. 29 Oct, 2007 1 commit
    • Alex Chiang's avatar
      [IA64] /proc/cpuinfo "physical id" field cleanups · 113134fc
      Alex Chiang authored
      Clean up the process for presenting the "physical id" field in
      	- remove global smp_num_cpucores, as it is mostly useless
      	- remove check_for_logical_procs(), since we do the same
      	  functionality in identify_siblings()
      	- reflow logic in identify_siblings(). If an older CPU
      	  does not implement PAL_LOGICAL_TO_PHYSICAL, we may still
      	  be able to get useful information from SAL_PHYSICAL_ID_INFO
      	- in identify_siblings(), threads/cores are a property of
      	  the CPU, not the platform
      	- remove useless printk's about multi-core / thread
      	  capability in identify_siblings(), as that information
      	  is readily available in /proc/cpuinfo, and printing for
      	  the BSP only adds little value
      	- smp_num_siblings is now meaningful if any CPU in the
      	  system supports threads, not just the BSP
      	- expose "physical id" field, even on CPUs that are not
      	  multi-core / multi-threaded (as long as we have a valid
      	  value). Now we know what sockets Madisons live in too.
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  19. 16 Oct, 2007 1 commit
  20. 01 Sep, 2007 1 commit
  21. 25 Jul, 2007 1 commit
  22. 17 Jul, 2007 1 commit
    • Yasuaki Ishimatsu's avatar
      [IA64] Add mapping table between irq and vector · e1b30a39
      Yasuaki Ishimatsu authored
      Add mapping tables between irqs and vectors, and its management code.
      This is necessary for supporting multiple vector domain because 1:1
      mapping between irq and vector will be changed to n:1.
      The irq == vector relationship between irqs and vectors is explicitly
      remained for percpu interrupts, platform interrupts, isa IRQs and
      vectors assigned using assign_irq_vector() because some programs might
      depend on it.
      And I should consider the following problem.
      When pci drivers enabled/disabled devices dynamically, its irq number
      is changed to the different one. Therefore, suspend/resume code may
      happen problem.
      To fix this problem, I bound gsi to irq.
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  23. 23 May, 2007 1 commit
  24. 11 May, 2007 1 commit
  25. 08 May, 2007 1 commit
  26. 29 Mar, 2007 1 commit
  27. 05 Dec, 2006 1 commit
  28. 26 Sep, 2006 1 commit
  29. 03 Jul, 2006 1 commit
  30. 30 Jun, 2006 1 commit
  31. 29 Jun, 2006 2 commits
    • Ingo Molnar's avatar
      [PATCH] genirq: cleanup: remove irq_descp() · a8553acd
      Ingo Molnar authored
      Cleanup: remove irq_descp() - explicit use of irq_desc[] is shorter and more
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] genirq: rename desc->handler to desc->chip · d1bef4ed
      Ingo Molnar authored
      This patch-queue improves the generic IRQ layer to be truly generic, by adding
      various abstractions and features to it, without impacting existing
      While the queue can be best described as "fix and improve everything in the
      generic IRQ layer that we could think of", and thus it consists of many
      smaller features and lots of cleanups, the one feature that stands out most is
      the new 'irq chip' abstraction.
      The irq-chip abstraction is about describing and coding and IRQ controller
      driver by mapping its raw hardware capabilities [and quirks, if needed] in a
      straightforward way, without having to think about "IRQ flow"
      (level/edge/etc.) type of details.
      This stands in contrast with the current 'irq-type' model of genirq
      architectures, which 'mixes' raw hardware capabilities with 'flow' details.
      The patchset supports both types of irq controller designs at once, and
      converts i386 and x86_64 to the new irq-chip design.
      As a bonus side-effect of the irq-chip approach, chained interrupt controllers
      (master/slave PIC constructs, etc.) are now supported by design as well.
      The end result of this patchset intends to be simpler architecture-level code
      and more consolidation between architectures.
      We reused many bits of code and many concepts from Russell King's ARM IRQ
      layer, the merging of which was one of the motivations for this patchset.
      This patch:
      rename desc->handler to desc->chip.
      Originally i did not want to do this, because it's a big patch.  But having
      both "desc->handler", "desc->handle_irq" and "action->handler" caused a
      large degree of confusion and made the code appear alot less clean than it
      truly is.
      I have also attempted a dual approach as well by introducing a
      desc->chip alias - but that just wasnt robust enough and broke
      So lets get over with this quickly.  The conversion was done automatically
      via scripts and converts all the code in the kernel.
      This renaming patch is the first one amongst the patches, so that the
      remaining patches can stay flexible and can be merged and split up
      without having some big monolithic patch act as a merge barrier.
      [akpm@osdl.org: build fix]
      [akpm@osdl.org: another build fix]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  32. 24 Mar, 2006 1 commit
    • Fenghua Yu's avatar
      [IA64] New IA64 core/thread detection patch · 4129a953
      Fenghua Yu authored
      IPF SDM 2.2 changes definition of PAL_LOGICAL_TO_PHYSICAL to add
      proc_number=-1 to get core/thread mapping info on the running processer.
      Based on this change, we had better to update existing core/thread
      detection in IA64 kernel correspondingly. The attached patch implements
      this change. It simplifies detection code and eliminates potential race
      condition. It also runs a bit faster and has better scalability especially
      when cores and threads number grows up in one package.
      Signed-off-by: default avatarFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  33. 14 Feb, 2006 1 commit
  34. 05 Jan, 2006 1 commit
    • Ashok Raj's avatar
      [IA64] support for cpu0 removal · ff741906
      Ashok Raj authored
      here is the BSP removal support for IA64. Its pretty much the same thing that
      was released a while back, but has your feedback incorporated.
      - Removed CONFIG_BSP_REMOVE_WORKAROUND and associated cmdline param
      - Fixed compile issue with sn2/zx1 due to a undefined fix_b0_for_bsp
      - some formatting nits (whitespace etc)
      This has been tested on tiger and long back by alex on hp systems as well.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>