Skip to content
  • 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.com
    
    
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    77ed23f8