diff options
author | Vaibhav Jain <vaibhav@linux.vnet.ibm.com> | 2018-01-18 09:39:43 +0530 |
---|---|---|
committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2018-01-30 20:42:38 -0600 |
commit | 5a959af3fb417c4269b625d9ff2cb204f20728d5 (patch) | |
tree | d13c9a23cac56cb639a6f39cd17a93e3c23641f0 /doc | |
parent | e05798d8757159f621d62f35913eb0bdee2636bf (diff) | |
download | skiboot-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