1. 21 11月, 2008 1 次提交
    • T
      [IA64] Rationalize kernel mode alignment checking · b704882e
      Tony Luck 提交于
      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: NTony Luck <tony.luck@intel.com>
      b704882e
  2. 30 9月, 2008 1 次提交
  3. 13 8月, 2008 1 次提交
    • T
      [IA64] Ensure cpu0 can access per-cpu variables in early boot code · 10617bbe
      Tony Luck 提交于
      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: NTony Luck <tony.luck@intel.com>
      10617bbe
  4. 02 8月, 2008 1 次提交
    • T
      [IA64] Move include/asm-ia64 to arch/ia64/include/asm · 7f30491c
      Tony Luck 提交于
      After moving the the include files there were a few clean-ups:
      
      1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>
      
      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: NTony Luck <tony.luck@intel.com>
      7f30491c
  5. 28 5月, 2008 1 次提交
  6. 21 2月, 2008 1 次提交
    • H
      [IA64] VIRT_CPU_ACCOUNTING (accurate cpu time accounting) · b64f34cd
      Hidetoshi Seto 提交于
      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: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      b64f34cd
  7. 20 12月, 2007 1 次提交
    • H
      [IA64] Remove assembler warnings on head.S · 09106228
      Hidetoshi Seto 提交于
      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: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      09106228
  8. 26 7月, 2007 1 次提交
  9. 09 9月, 2006 1 次提交
  10. 03 8月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 08 2月, 2006 1 次提交
    • T
      [IA64] Fix CONFIG_PRINTK_TIME · d6e56a2a
      Tony Luck 提交于
      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: NTony Luck <tony.luck@intel.com>
      d6e56a2a
  13. 09 1月, 2006 1 次提交
  14. 10 9月, 2005 1 次提交
  15. 23 4月, 2005 2 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4