29 Oct, 2009

1 commit

  • This patch updates percpu related symbols in ia64 such that percpu
    symbols are unique and don't clash with local symbols. This serves
    two purposes of decreasing the possibility of global percpu symbol
    collision and allowing dropping per_cpu__ prefix from percpu symbols.

    * arch/ia64/kernel/setup.c: s/cpu_info/ia64_cpu_info/

    Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
    which cause name clashes" patch.

    Signed-off-by: Tejun Heo
    Reviewed-by: Christoph Lameter
    Cc: Rusty Russell
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: linux-ia64@vger.kernel.org

    Tejun Heo
     

25 Sep, 2009

1 commit

  • Back in January 2008 Nick Piggin implemented "ticket" spinlocks
    for X86 (See commit 314cdbefd1fd0a7acf3780e9628465b77ea6a836).

    IA64 implementation has a couple of differences because of the
    available atomic operations ... e.g. we have no fetchadd2 instruction
    that operates on a 16-bit quantity so we make ticket locks use
    a 32-bit word for each of the current ticket and now-serving values.

    Performance on uncontended locks is about 8% worse than the previous
    implementation, but this seems a good trade for determinism in the
    contended case. Performance impact on macro-level benchmarks is in
    the noise.

    Signed-off-by: Tony Luck

    Tony Luck
     

16 Sep, 2009

2 commits


15 Sep, 2009

1 commit

  • Summary:

    INIT asserted on kdump kernel invokes INIT handler not only on a
    cpu that running on the kdump kernel, but also BSP of the panicked
    kernel, because the (badly) frozen BSP can be thawed by INIT.

    Description:

    The kdump_cpu_freeze() is called on cpus except one that initiates
    panic and/or kdump, to stop/offline the cpu (on ia64, it means we
    pass control of cpus to SAL, or put them in spinloop). Note that
    CPU0(BSP) always go to spinloop, so if panic was happened on an AP,
    there are at least 2cpus (= the AP and BSP) which not back to SAL.

    On the spinning cpus, interrupts are disabled (rsm psr.i), but INIT
    is still interruptible because psr.mc for mask them is not set unless
    kdump_cpu_freeze() is not called from MCA/INIT context.

    Therefore, assume that a panic was happened on an AP, kdump was
    invoked, new INIT handlers for kdump kernel was registered and then
    an INIT is asserted. From the viewpoint of SAL, there are 2 online
    cpus, so INIT will be delivered to both of them. It likely means
    that not only the AP (= a cpu executing kdump) enters INIT handler
    which is newly registered, but also BSP (= another cpu spinning in
    panicked kernel) enters the same INIT handler. Of course setting of
    registers in BSP are still old (for panicked kernel), so what happen
    with running handler with wrong setting will be extremely unexpected.
    I believe this is not desirable behavior.

    How to Reproduce:

    Start kdump on one of APs (e.g. cpu1)
    # taskset 0x2 echo c > /proc/sysrq-trigger
    Then assert INIT after kdump kernel is booted, after new INIT handler
    for kdump kernel is registered.

    Expected results:

    An INIT handler is invoked only on the AP.

    Actual results:

    An INIT handler is invoked on the AP and BSP.

    Sample of results:

    I got following console log by asserting INIT after prompt "root:/>".
    It seems that two monarchs appeared by one INIT, and one panicked at
    last. And it also seems that the panicked one supposed there were
    4 online cpus and no one did rendezvous:

    :
    [ 0 %]dropping to initramfs shell
    exiting this shell will reboot your system
    root:/> Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=0
    ia64_init_handler: Promoting cpu 0 to monarch.
    Delaying for 5 seconds...
    All OS INIT slaves have reached rendezvous
    Processes interrupted by INIT - 0 (cpu 0 task 0xa000000100af0000)
    :
    <>
    :
    Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=1
    Delaying for 5 seconds...
    mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail.
    OS INIT slave did not rendezvous on cpu 1 2 3
    INIT swapper 0[0]: bugcheck! 0 [1]
    :
    <>
    :
    Kernel panic - not syncing: Attempted to kill the idle task!

    Proposed fix:

    To avoid this problem, this patch inserts ia64_set_psr_mc() to mask
    INIT on cpus going to be frozen. This masking have no effect if the
    kdump_cpu_freeze() is called from INIT handler when kdump_on_init == 1,
    because psr.mc is already turned on to 1 before entering OS_INIT.
    I confirmed that weird log like above are disappeared after applying
    this patch.

    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
     

27 Mar, 2009

1 commit


21 Nov, 2008

1 commit

  • Itanium processors can handle some misaligned data accesses. They
    also provide a mode where all such accesses are forced to trap. The
    kernel was schizophrenic about use of this mode:

    * Base kernel code ran in permissive mode where the only traps
    generated were from those cases that the h/w could not handle.
    * Interrupt, syscall and trap code ran in strict mode where all
    unaligned accesses caused traps to the 0x5a00 unaligned reference
    vector.

    Use strict alignment checking throughout the kernel, but make
    sure that we continue to let user mode use more relaxed mode
    as the default.

    Signed-off-by: Tony Luck

    Tony Luck
     

30 Sep, 2008

1 commit


13 Aug, 2008

1 commit

  • 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: Tony Luck

    Tony Luck
     

02 Aug, 2008

1 commit

  • After moving the the include files there were a few clean-ups:

    1) Some files used #include , changed to

    2) Some comments alerted maintainers to look at various header files to
    make matching updates if certain code were to be changed. Updated these
    comments to use the new include paths.

    3) Some header files mentioned their own names in initial comments. Just
    deleted these self references.

    Signed-off-by: Tony Luck

    Tony Luck
     

28 May, 2008

1 commit


21 Feb, 2008

1 commit

  • This patch implements VIRT_CPU_ACCOUNTING for ia64,
    which enable us to use more accurate cpu time accounting.

    The VIRT_CPU_ACCOUNTING is an item of kernel config, which s390
    and powerpc arch have. By turning this config on, these archs
    change the mechanism of cpu time accounting from tick-sampling
    based one to state-transition based one.

    The state-transition based accounting is done by checking time
    (cycle counter in processor) at every state-transition point,
    such as entrance/exit of kernel, interrupt, softirq etc.
    The difference between point to point is the actual time consumed
    during in the state. There is no doubt about that this value is
    more accurate than that of tick-sampling based accounting.

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

    Hidetoshi Seto
     

20 Dec, 2007

1 commit

  • This patch removes the following assembler warning messages.

    AS arch/ia64/kernel/head.o
    arch/ia64/kernel/head.S: Assembler messages:
    arch/ia64/kernel/head.S:1179: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data)
    arch/ia64/kernel/head.S:1179: Warning: Only the first path encountering the conflict is reported
    arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage
    arch/ia64/kernel/head.S:1180: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data)
    arch/ia64/kernel/head.S:1180: Warning: Only the first path encountering the conflict is reported
    arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage
    :
    arch/ia64/kernel/head.S:1213: Warning: Use of 'ldf.fill.nta' violates RAW dependency 'CR[PTA]' (data)
    arch/ia64/kernel/head.S:1213: Warning: Only the first path encountering the conflict is reported
    arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage

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

    Hidetoshi Seto
     

26 Jul, 2007

1 commit

  • In 741f98fe298a73c9d47ed53703c1279a29718581 Sam added full
    checking across the entire vmlinux image. This flushed out
    a dozen new section mismatch warnings. Start the whack-a-mole
    game again to stomp them out.

    Signed-off-by: Tony Luck

    Tony Luck
     

09 Sep, 2006

1 commit

  • The SN PROM uses the register stack in the slave loop. The contents
    must be preserved for the OS to return to the slave loop via offlining
    a cpu or for kexec. A 'flushrs" is needed to force the stack to be written
    to memory prior to changing bspstore.

    Signed-off-by: Jack Steiner
    Signed-off-by: Tony Luck

    Jack Steiner
     

03 Aug, 2006

1 commit


01 Jul, 2006

1 commit


08 Feb, 2006

1 commit

  • There were two problems with enabling the PRINTK_TIME config
    option:
    1) The first calls to printk() occur before per-cpu data virtual
    address is pinned into the TLB, so sched_clock() can fault.
    2) sched_clock() is based on ar.itc, which may not be synchronized
    across cpus.

    Ken Chen started this patch, Tony Luck tinkered with it, and Jes
    Sorensen perfected it.

    Signed-off-by: Tony Luck

    Tony Luck
     

09 Jan, 2006

1 commit

  • Remove various things which were checking for gcc-1.x and gcc-2.x compilers.

    From: Adrian Bunk

    Some documentation updates and removes some code paths for gcc < 3.2.

    Acked-by: Russell King
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

10 Sep, 2005

1 commit


23 Apr, 2005

2 commits

  • Signed-off-by: Ashok Raj
    Signed-off-by: Tony Luck

    Ashok Raj
     
  • This patch is required to support cpu removal for IPF systems. Existing code
    just fakes the real offline by keeping it run the idle thread, and polling
    for the bit to re-appear in the cpu_state to get out of the idle loop.

    For the cpu-offline to work correctly, we need to pass control of this CPU
    back to SAL so it can continue in the boot-rendez mode. This gives the
    SAL control to not pick this cpu as the monarch processor for global MCA
    events, and addition does not wait for this cpu to checkin with SAL
    for global MCA events as well. The handoff is implemented as documented in
    SAL specification section 3.2.5.1 "OS_BOOT_RENDEZ to SAL return State"

    Signed-off-by: Ashok Raj
    Signed-off-by: Tony Luck

    Ashok Raj
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds