1. 17 May, 2011 2 commits
  2. 16 May, 2011 1 commit
    • Youquan Song's avatar
      x86, apic: Fix spurious error interrupts triggering on all non-boot APs · e503f9e4
      Youquan Song authored
      This patch fixes a bug reported by a customer, who found
      that many unreasonable error interrupts reported on all
      non-boot CPUs (APs) during the system boot stage.
      
      According to Chapter 10 of Intel Software Developer Manual
      Volume 3A, Local APIC may signal an illegal vector error when
      an LVT entry is set as an illegal vector value (0~15) under
      FIXED delivery mode (bits 8-11 is 0), regardless of whether
      the mask bit is set or an interrupt actually happen. These
      errors are seen as error interrupts.
      
      The initial value of thermal LVT entries on all APs always reads
      0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
      sequence to them and LVT registers are reset to 0s except for
      the mask bits which are set to 1s when APs receive INIT IPI.
      
      When the BIOS takes over the thermal throttling interrupt,
      the LVT thermal deliver mode should be SMI and it is required
      from the kernel to keep AP's LVT thermal monitoring register
      programmed as such as well.
      
      This issue happens when BIOS does not take over thermal throttling
      interrupt, AP's LVT thermal monitor register will be restored to
      0x10000 which means vector 0 and fixed deliver mode, so all APs will
      signal illegal vector error interrupts.
      
      This patch check if interrupt delivery mode is not fixed mode before
      restoring AP's LVT thermal monitor register.
      Signed-off-by: default avatarYouquan Song <youquan.song@intel.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarYong Wang <yong.y.wang@intel.com>
      Cc: hpa@linux.intel.com
      Cc: joe@perches.com
      Cc: jbaron@redhat.com
      Cc: trenn@suse.de
      Cc: kent.liu@intel.com
      Cc: chaohong.guo@intel.com
      Cc: <stable@kernel.org> # As far back as possible
      Link: http://lkml.kernel.org/r/1303402963-17738-1-git-send-email-youquan.song@intel.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e503f9e4
  3. 13 May, 2011 1 commit
  4. 12 May, 2011 1 commit
    • Cliff Wickman's avatar
      x86: Fix UV BAU for non-consecutive nasids · 77ed23f8
      Cliff Wickman authored
      This is a fix for the SGI Altix-UV Broadcast Assist Unit code,
      which is used for TLB flushing.
      
      Certain hardware configurations (that customers are ordering)
      cause nasids (numa address space id's) to be non-consecutive.
      Specifically, once you have more than 4 blades in a IRU
      (Individual Rack Unit - or 1/2 rack) but less than the maximum
      of 16, the nasid numbering becomes non-consecutive.  This
      currently results in a 'catastrophic error' (CATERR) detected by
      the firmware during OS boot.  The BAU is generating an 'INTD'
      request that is targeting a non-existent nasid value. Such
      configurations may also occur when a blade is configured off
      because of hardware errors. (There is one UV hub per blade.)
      
      This patch is required to support such configurations.
      
      The problem with the tlb_uv.c code is that is using the
      consecutive hub numbers as indices to the BAU distribution bit
      map. These are simply the ordinal position of the hub or blade
      within its partition.  It should be using physical node numbers
      (pnodes), which correspond to the physical nasid values. Use of
      the hub number only works as long as the nasids in the partition
      are consecutive and increase with a stride of 1.
      
      This patch changes the index to be the pnode number, thus
      allowing nasids to be non-consecutive.
      It also provides a table in local memory for each cpu to
      translate target cpu number to target pnode and nasid.
      And it improves naming to properly reflect 'node' and 'uvhub'
      versus 'nasid'.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org>
      Link: http://lkml.kernel.org/r/E1QJmxX-0002Mz-Fk@eag09.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      77ed23f8
  5. 10 May, 2011 3 commits
  6. 09 May, 2011 27 commits
  7. 08 May, 2011 5 commits