aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorVaibhav Jain <vaibhav@linux.vnet.ibm.com>2018-01-18 09:39:43 +0530
committerStewart Smith <stewart@linux.vnet.ibm.com>2018-01-30 20:42:38 -0600
commit5a959af3fb417c4269b625d9ff2cb204f20728d5 (patch)
treed13c9a23cac56cb639a6f39cd17a93e3c23641f0 /doc
parente05798d8757159f621d62f35913eb0bdee2636bf (diff)
downloadskiboot-5a959af3fb417c4269b625d9ff2cb204f20728d5.zip
skiboot-5a959af3fb417c4269b625d9ff2cb204f20728d5.tar.gz
skiboot-5a959af3fb417c4269b625d9ff2cb204f20728d5.tar.bz2
capi: Disable CAPP virtual machines
When exercising more than one CAPI accelerators simultaneously in cache coherency mode, the verification team is seeing a deadlock. To fix this a workaround of disabling CAPP virtual machines is suggested. These 'virtual machines' let PSL queue multiple CAPP commands for servicing by CAPP there by increasing throughput. Below is the error scenario described by the h/w team: " With virtual machines enabled we had a deadlock scenario where with 2 or more CAPI's in a system you could get in a deadlock scenario due to cast-outs that are required break the deadlock (evict lines that another CAPI is requesting) get stuck in the virtual machine queue by a command ahead of it that is being retried by the same scenario in the other CAPI. " So this patch updates CAPP APC Master Powerbus control register during CAPP init to also set Bit(12) that disables CAPP virtual machines. This forces processing of CAPP commands from PSL one at a time and thereby preventing above mentioned deadlock scenario. Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions