1. 20 12月, 2007 4 次提交
    • R
      [IA64] Fix Altix BTE error return status · 64135fa9
      Russ Anderson 提交于
      The Altix shub2 BTE error detail bits are in a different location
      than on shub1.  The current code does not take this into account
      resulting in all shub2 BTE failures mapping to "unknown".
      
      This patch reads the error detail bits from the proper location,
      so the correct BTE failure reason is returned for both shub1
      and shub2.
      Signed-off-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      64135fa9
    • 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
    • K
      [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c · 373167e8
      Kenji Kaneshige 提交于
      This patch removes the following compiler warning messages.
      
        CC      arch/ia64/kernel/irq_ia64.o
      arch/ia64/kernel/irq_ia64.c: In function 'create_irq':
      arch/ia64/kernel/irq_ia64.c:343: warning: 'domain.bits[0u]' may be used uninitialized in this function
      arch/ia64/kernel/irq_ia64.c: In function 'assign_irq_vector':
      arch/ia64/kernel/irq_ia64.c:203: warning: 'domain.bits[0u]' may be used uninitialized in this function
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      373167e8
    • I
      [IA64] set_thread_area fails in IA32 chroot · e384f414
      Ian Wienand 提交于
      I tried to upgrade an IA32 chroot on my IA64 to a new glibc with TLS.
      It kept dying because set_thread_area was returning -ESRCH
      (bugs.debian.org/451939).
      
      I instrumented arch/ia64/ia32/sys_ia32.c:get_free_idx() and ended up
      seeing output like
      
      [pid] idx   desc->a  desc->b
      -----------------------------
      [2710] 0 -> c6b0ffff 40dff31b
      [2710] 1 -> 0 0
      [2710] 2 -> 0 0
      
      [2710] 0 -> c6b0ffff 40dff31b
      [2710] 1 -> c6b0ffff 40dff31b
      [2710] 2 -> 0 0
      
      [2711] 0 -> c6b0ffff 40dff31b
      [2711] 1 -> c6b0ffff 40dff31b
      [2711] 2 -> 48c0ffff 40dff317
      
      which suggested to me that TLS pointers were surviving exec() calls,
      leading to GDT pointers filling up and the eventual failure of
      get_free_idx().
      
      I think the solution is flushing the tls array on exec.
      Signed-Off-By: NIan Wienand <ianw@gelato.unsw.edu.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e384f414
  2. 19 12月, 2007 6 次提交
  3. 18 12月, 2007 30 次提交