29 Mar, 2011

1 commit


03 Mar, 2011

1 commit

  • ia64_mca_cpu_init has a void *data local variable that is assigned
    the value from either __get_free_pages() or mca_bootmem(). The problem
    is that __get_free_pages returns an unsigned long and mca_bootmem, via
    alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *,
    and it's also used with __pa(), but that casts it to long anyway.

    This results in the following build warning:

    arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from
    integer without a cast

    Cast the return of __get_free_pages to a void * to avoid
    the warning.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: Tony Luck

    Jeff Mahoney
     

25 Feb, 2011

1 commit


08 Oct, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

08 Jan, 2010

1 commit

  • __per_cpu_idtrs is statically allocated ... on CONFIG_NR_CPUS=4096
    systems it hogs 16MB of memory. This is way too much for a quite
    probably unused facility (only KVM uses dynamic TR registers).

    Change to an array of pointers, and allocate entries as needed on
    a per cpu basis. Change the name too as the __per_cpu_ prefix is
    confusing (this isn't a classic type object).

    Signed-off-by: Tony Luck

    Tony Luck
     

15 Dec, 2009

1 commit

  • This is a patch related to this discussion.
    http://www.spinics.net/lists/linux-ia64/msg07605.html

    When INIT is sent, ip/psr/pfs register is stored to the I-resources
    (iip/ipsr/ifs registers), and they are copied in the min-state save
    area(pmsa_{iip,ipsr,ifs}).

    Therefore, in creating pt_regs at ia64_mca_modify_original_stack(),
    cr_{iip,ipsr,ifs} should be derived from pmsa_{iip,ipsr,ifs}. But
    current code copies pmsa_{xip,xpsr,xfs} to cr_{iip,ipsr,ifs}
    when PSR.ic is 0.

    finish_pt_regs(struct pt_regs *regs, const pal_min_state_area_t *ms,
    unsigned long *nat)
    {
    (snip)
    if (ia64_psr(regs)->ic) {
    regs->cr_iip = ms->pmsa_iip;
    regs->cr_ipsr = ms->pmsa_ipsr;
    regs->cr_ifs = ms->pmsa_ifs;
    } else {
    regs->cr_iip = ms->pmsa_xip;
    regs->cr_ipsr = ms->pmsa_xpsr;
    regs->cr_ifs = ms->pmsa_xfs;
    }

    It's ok when PSR.ic is not 0. But when PSR.ic is 0, this could be
    a problem when we investigate kernel as the value of regs->cr_iip does
    not point to where INIT really interrupted.

    At first I tried to change finish_pt_regs() so that it uses always
    pmsa_{iip,ipsr,ifs} for cr_{iip,ipsr,ifs}, but Keith Owens pointed out
    it could cause another problem if I change it.

    >The only problem I can think of is an MCA/INIT
    >arriving while code like SAVE_MIN or SAVE_REST is executing. Back
    >tracing at that point using pmsa_iip is going to be a problem, you have
    >no idea what state the registers or stack are in.

    I confirmed he was right, so I decided to keep it as-is and to
    save pmsa_{iip,ipsr,ifs} to ia64_sal_os_state for debugging.

    An attached patch is just adding new members into ia64_sal_os_state to
    save pmsa_{iip,ipsr,ifs}.

    Signed-off-by: Takao Indoh
    Signed-off-by: Tony Luck

    Takao Indoh
     

14 Oct, 2009

1 commit

  • Registers are not saved anywhere when INIT comes during fsys mode and
    we cannot know what happened when we investigate vmcore captured by
    kdump. This patch adds new function finish_pt_regs() so registers can
    be saved in such a case.

    Signed-off-by: Takao Indoh
    Signed-off-by: Tony Luck

    Takao Indoh
     

15 Sep, 2009

1 commit

  • Setting monarch_cpu = -1 to let slaves frozen might not work, because
    there might be slaves being late, not entered the rendezvous yet.
    Such slaves might be caught in while (monarch_cpu == -1) loop.

    Use kdump_in_progress instead of monarch_cpus to break INIT rendezvous
    and let all slaves enter DIE_INIT_SLAVE_LEAVE smoothly.

    And monarch no longer need to manage rendezvous if once kdump_in_progress
    is set, catch the monarch in DIE_INIT_MONARCH_ENTER then.

    Signed-off-by: Hidetoshi Seto
    Cc: Vivek Goyal
    Cc: Haren Myneni
    Cc: kexec@lists.infradead.org
    Acked-by: Fenghua Yu
    Signed-off-by: Tony Luck

    Hidetoshi Seto
     

18 Jun, 2009

2 commits

  • Tony Luck
     
  • 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: Matthew Wilcox
    Signed-off-by: Tony Luck

    Matthew Wilcox
     

17 Jun, 2009

1 commit

  • Callers of alloc_pages_node() can optionally specify -1 as a node to mean
    "allocate from the current node". However, a number of the callers in
    fast paths know for a fact their node is valid. To avoid a comparison and
    branch, this patch adds alloc_pages_exact_node() that only checks the nid
    with VM_BUG_ON(). Callers that know their node is valid are then
    converted.

    Signed-off-by: Mel Gorman
    Reviewed-by: Christoph Lameter
    Reviewed-by: KOSAKI Motohiro
    Reviewed-by: Pekka Enberg
    Acked-by: Paul Mundt [for the SLOB NUMA bits]
    Cc: Peter Zijlstra
    Cc: Nick Piggin
    Cc: Dave Hansen
    Cc: Lee Schermerhorn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

16 Jun, 2009

1 commit

  • The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have
    been kept around for migration reasons. After more than two years it's
    time to remove them finally.

    This patch cleans up one of the remaining users. When all such patches
    hit mainline we can remove the defines and typedefs finally.

    Impact: cleanup

    Convert the last remaining users and remove the typedef.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Tony Luck

    Thomas Gleixner
     

16 Mar, 2009

1 commit


21 Nov, 2008

1 commit


26 Jun, 2008

2 commits


22 Apr, 2008

2 commits


18 Apr, 2008

1 commit


10 Apr, 2008

2 commits

  • The functions time_before, time_before_eq, time_after, and time_after_eq are
    more robust for comparing jiffies against other values.

    So use the time_after() & time_before() macros, defined at linux/jiffies.h,
    which deal with wrapping correctly

    [akpm@linux-foundation.org: coding-style fixes]

    Signed-off-by: S.Caglar Onur
    Reviewed-by: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    Signed-off-by: Tony Luck

    S.Caglar Onur
     
  • While it is convenient that we can invoke kdump by asserting INIT
    via button on chassis etc., there are some situations that invoking
    kdump on fatal MCA is not welcomed rather than rebooting fast without
    dump.

    This patch adds a new flag 'kdump_on_fatal_mca' that is independent
    from 'kdump_on_init' currently available. Adding this flag enable
    us to turning on/off of kdump depend on the event, INIT and/or fatal
    MCA. Default for this flag is to take the dump.

    Signed-off-by: Hidetoshi Seto
    Signed-off-by: Tony Luck

    Hidetoshi Seto
     

04 Apr, 2008

1 commit


07 Mar, 2008

1 commit


09 Feb, 2008

1 commit

  • The MCA code allocates bootmem memory for NR_CPUS, regardless
    of how many cpus the system actually has. This change allocates
    memory only for cpus that actually exist.

    On my test system with NR_CPUS = 1024, reserved memory was reduced by 130944k.

    Before: Memory: 27886976k/28111168k available (8282k code, 242304k reserved, 5928k data, 1792k init)
    After: Memory: 28017920k/28111168k available (8282k code, 111360k reserved, 5928k data, 1792k init)

    Signed-off-by: Russ Anderson
    Signed-off-by: Tony Luck

    Russ Anderson
     

05 Feb, 2008

1 commit


20 Dec, 2007

1 commit


07 Nov, 2007

1 commit

  • When the CPE handler encounters too many CPEs (such as a solid single
    bit memory 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() calls chip->disable() to provide
    a chipset specifiec interface for disabling the interrupt. This patch
    adds the Altix specific support to disable and re-enable the CPE interrupt.

    Signed-off-by: Russ Anderson (rja@sgi.com)
    Signed-off-by: Tony Luck

    Russ Anderson
     

13 Oct, 2007

2 commits

  • Additional testing uncovered a situation where the MCA recovery code could
    hang due to a race condition.

    According to the SAL spec, SAL sends a rendezvous interrupt to all but the first
    CPU that goes into MCA. This includes other CPUs that go into MCA at the same
    time. Those other CPUs will go into the linux MCA handler (rather than the
    slave loop) with the rendezvous interrupt pending. When all the CPUs have
    completed MCA processing and the last monarch completes, freeing all the CPUs,
    the CPUs with the pended rendezvous interrupt then go into the
    ia64_mca_rendez_int_handler(). In ia64_mca_rendez_int_handler() the CPUs
    get marked as rendezvoused, but then leave the handler (due to no MCA).
    That leaves the CPUs marked as rendezvoused _before_ the next MCA event.

    When the next MCA hits, the monarch will mistakenly believe that all the CPUs
    are rendezvoused when they are not, opening up a window where a CPU can get
    stuck in the slave loop.

    This patch avoids leaving CPUs marked as rendezvoused when they are not.

    Signed-off-by: Russ Anderson
    Signed-off-by: Tony Luck

    Russ Anderson
     
  • While testing the MCA recovery code, noticed that some machines would have a
    five second delay rendezvousing cpus. What was happening is that
    ia64_wait_for_slaves() would check to see if all the slave CPUs had
    rendezvoused. If any had not, it would wait 1 millisecond then check again.
    If any CPUs had still not rendezvoused, it would wait 5 seconds before
    checking again.

    On some configs the rendezvous takes more than 1 millisecond, causing the code
    to wait the full 5 seconds, even though the last CPU rendezvoused after only
    a few milliseconds.

    The fix is to check every 1 millisecond to see if all the cpus have
    rendezvoused. After 5 seconds the code concludes the CPUs will never
    rendezvous (same as before).

    The MCA code is, by definition, not performance critical, but a needless
    delay of 5 seconds is senseless. The 5 seconds also adds up quickly
    when running the error injection code in a loop.

    This patch both simplifies the code and removes the needless delay.

    Signed-off-by: Russ Anderson
    Signed-off-by: Tony Luck

    Russ Anderson
     

14 Aug, 2007

1 commit

  • Use local_vector_to_irq() instead of looping through all NR_IRQS.
    This avoids registering the CPE handler on multiple irqs. Only
    register if the irq is valid. If no valid irq is found, print an
    error message and set up polling.

    Signed-off-by: Russ Anderson
    Signed-off-by: Tony Luck

    Russ Anderson
     

31 Jul, 2007

1 commit

  • Fix the following section mismatch warnings:

    WARNING: vmlinux.o(.text+0x41902): Section mismatch: reference to .init.text:__alloc_bootmem (between 'ia64_mca_cpu_init' and 'ia64_do_tlb_purge')
    WARNING: vmlinux.o(.text+0x49222): Section mismatch: reference to .init.text:__alloc_bootmem (between 'register_intr' and 'iosapic_register_intr')
    WARNING: vmlinux.o(.text+0x62beb2): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'hubdev_init_node' and 'cnodeid_get_geoid')

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Tony Luck

    Sam Ravnborg
     

12 Jul, 2007

1 commit

  • Linux does not gracefully deal with multiple processors going
    through OS_MCA aa part of the same MCA event. The first cpu
    into OS_MCA grabs the ia64_mca_serialize lock. Subsequent
    cpus wait for that lock, preventing them from reporting in as
    rendezvoused. The first cpu waits 5 seconds then complains
    that all the cpus have not rendezvoused. The first cpu then
    handles its MCA and frees up all the rendezvoused cpus and
    releases the ia64_mca_serialize lock. One of the subsequent
    cpus going thought OS_MCA then gets the ia64_mca_serialize
    lock, waits another 5 seconds and then complains that none of
    the other cpus have rendezvoused.

    This patch allows multiple CPUs to gracefully go through OS_MCA.

    The first CPU into ia64_mca_handler() grabs a mca_count lock.
    Subsequent CPUs into ia64_mca_handler() are added to a list of cpus
    that need to go through OS_MCA (a bit set in mca_cpu), and report
    in as rendezvoused, and but spin waiting their turn.

    The first CPU sees everyone rendezvous, handles his MCA, wakes up
    one of the other CPUs waiting to process their MCA (by clearing
    one mca_cpu bit), and then waits for the other cpus to complete
    their MCA handling. The next CPU handles his MCA and the process
    repeats until all the CPUs have handled their MCA. When the last
    CPU has handled it's MCA, it sets monarch_cpu to -1, releasing all
    the CPUs.

    In testing this works more reliably and faster.

    Thanks to Keith Owens for suggesting numerous improvements
    to this code.

    Signed-off-by: Russ Anderson
    Signed-off-by: Tony Luck

    Russ Anderson
     

16 May, 2007

1 commit

  • Building with GCC 4.2, I get the following error:

    CC arch/ia64/kernel/mca.o
    arch/ia64/kernel/mca.c:275: error: __ksymtab_ia64_mlogbuf_finish causes a
    section type conflict

    This is because ia64_mlogbuf_finish is both declared static and exported.
    Fix by removing the export (which is unneeded now).

    Signed-off-by: Martin Michlmayr
    Signed-off-by: Tony Luck

    Martin Michlmayr
     

15 May, 2007

1 commit

  • The current implementation of kdump on INIT events would enter
    kdump processing on DIE_INIT_MONARCH_ENTER and DIE_INIT_SLAVE_ENTER
    events. Thus, the monarch cpu would go ahead and boot up the kdump

    On SN shub2 systems, this out-of-sync situation causes some slave
    cpus on different nodes to enter POD.

    This patch moves kdump entry points to DIE_INIT_MONARCH_LEAVE and
    DIE_INIT_SLAVE_LEAVE. It also sets kdump_in_progress variable in
    the DIE_INIT_MONARCH_PROCESS event to not dump all active stack
    traces to the console in the case of kdump.

    I have tested this patch on an SN machine and a HP RX2600.

    Signed-off-by: Jay Lan
    Acked-by: Zou Nan hai
    Signed-off-by: Tony Luck

    Jay Lan
     

11 May, 2007

1 commit


10 May, 2007

1 commit

  • This finally renames the thread_info field in task structure to stack, so that
    the assumptions about this field are gone and archs have more freedom about
    placing the thread_info structure.

    Nonbroken archs which have a proper thread pointer can do the access to both
    current thread and task structure via a single pointer.

    It'll allow for a few more cleanups of the fork code, from which e.g. ia64
    could benefit.

    Signed-off-by: Roman Zippel
    [akpm@linux-foundation.org: build fix]
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Russell King
    Cc: Ian Molton
    Cc: Haavard Skinnemoen
    Cc: Mikael Starvik
    Cc: David Howells
    Cc: Yoshinori Sato
    Cc: "Luck, Tony"
    Cc: Hirokazu Takata
    Cc: Geert Uytterhoeven
    Cc: Roman Zippel
    Cc: Greg Ungerer
    Cc: Ralf Baechle
    Cc: Ralf Baechle
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Heiko Carstens
    Cc: Martin Schwidefsky
    Cc: Paul Mundt
    Cc: Kazumoto Kojima
    Cc: Richard Curnow
    Cc: William Lee Irwin III
    Cc: "David S. Miller"
    Cc: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Cc: Miles Bader
    Cc: Andi Kleen
    Cc: Chris Zankel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     

09 May, 2007

2 commits

  • Remove includes of where it is not used/needed.
    Suggested by Al Viro.

    Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
    sparc64, and arm (all 59 defconfigs).

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • This patch moves the die notifier handling to common code. Previous
    various architectures had exactly the same code for it. Note that the new
    code is compiled unconditionally, this should be understood as an appel to
    the other architecture maintainer to implement support for it aswell (aka
    sprinkling a notify_die or two in the proper place)

    arm had a notifiy_die that did something totally different, I renamed it to
    arm_notify_die as part of the patch and made it static to the file it's
    declared and used at. avr32 used to pass slightly less information through
    this interface and I brought it into line with the other architectures.

    [akpm@linux-foundation.org: build fix]
    [akpm@linux-foundation.org: fix vmalloc_sync_all bustage]
    [bryan.wu@analog.com: fix vmalloc_sync_all in nommu]
    Signed-off-by: Christoph Hellwig
    Cc:
    Cc: Russell King
    Signed-off-by: Bryan Wu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

09 Mar, 2007

1 commit

  • Jack Steiner noticed that duplicate TLB DTC entries do not cause a
    linux panic. See discussion:

    http://www.gelato.unsw.edu.au/archives/linux-ia64/0307/6108.html

    The current TLB recovery code is recovering from the duplicate itr.d
    dropins, masking the underlying problem. This change modifies
    the MCA recovery code to look for the TLB check signature of the
    duplicate TLB entry and panic in that case.

    Signed-off-by: Russ Anderson (rja@sgi.com)
    Signed-off-by: Tony Luck

    Russ Anderson