-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Arista] Increase switch PCIe timeout for 7060 #9248
Conversation
The platform-init, similar to hwsku-init, would be scripts that need to be called for a specific platform.
/azp run Azure.sonic-buildimage |
Commenter does not have sufficient privileges for PR 9248 in repo Azure/sonic-buildimage |
Testing done:
From these findings I believe there is no danger to changing the timeout on a production device. |
/azp run Azure.sonic-buildimage |
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
Azure Pipelines successfully started running 1 pipeline(s). |
@zzhiyuan is x86_64-arista_7060_cx32s the only platform sku applicable for this change? |
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com> Why I did it Arista 7060 platform has a rare and unreproduceable PCIe timeout that could possibly be solved with increasing the switch PCIe timeout value. To do this we'll call a script for this platform to increase the PCIe timeout on boot-up. No issues would be expected from the setpci command. From the PCIe spec: "Software is permitted to change the value in this field at any time. For Requests already pending when the Completion Timeout Value is changed, hardware is permitted to use either the new or the old value for the outstanding Requests, and is permitted to base the start time for each Request either on when this value was changed or on when each request was issued. " How I did it Add "platform-init" support in swss docker similar to how "hwsku-init" is called, only this would be for any device belonging to a platform. Then the script would reside in device data folder. Additionally, add pciutils dependency to docker-orchagent so it can run the setpci commands. How to verify it On bootup of an Arista 7060, can execute: lspci -vv -s 01:00.0 | grep -i "devctl2" In order to check that the timeout has changed.
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com> Why I did it Arista 7060 platform has a rare and unreproduceable PCIe timeout that could possibly be solved with increasing the switch PCIe timeout value. To do this we'll call a script for this platform to increase the PCIe timeout on boot-up. No issues would be expected from the setpci command. From the PCIe spec: "Software is permitted to change the value in this field at any time. For Requests already pending when the Completion Timeout Value is changed, hardware is permitted to use either the new or the old value for the outstanding Requests, and is permitted to base the start time for each Request either on when this value was changed or on when each request was issued. " How I did it Add "platform-init" support in swss docker similar to how "hwsku-init" is called, only this would be for any device belonging to a platform. Then the script would reside in device data folder. Additionally, add pciutils dependency to docker-orchagent so it can run the setpci commands. How to verify it On bootup of an Arista 7060, can execute: lspci -vv -s 01:00.0 | grep -i "devctl2" In order to check that the timeout has changed.
looks like this fix is already included and picked up in 20191130 branch but missing in 202012 and 20181130 branches. |
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com> Why I did it Arista 7060 platform has a rare and unreproduceable PCIe timeout that could possibly be solved with increasing the switch PCIe timeout value. To do this we'll call a script for this platform to increase the PCIe timeout on boot-up. No issues would be expected from the setpci command. From the PCIe spec: "Software is permitted to change the value in this field at any time. For Requests already pending when the Completion Timeout Value is changed, hardware is permitted to use either the new or the old value for the outstanding Requests, and is permitted to base the start time for each Request either on when this value was changed or on when each request was issued. " How I did it Add "platform-init" support in swss docker similar to how "hwsku-init" is called, only this would be for any device belonging to a platform. Then the script would reside in device data folder. Additionally, add pciutils dependency to docker-orchagent so it can run the setpci commands. How to verify it On bootup of an Arista 7060, can execute: lspci -vv -s 01:00.0 | grep -i "devctl2" In order to check that the timeout has changed.
…202012 Due to confliction in files/image_config/platform/rc.local Related work items: sonic-net#9248, sonic-net#10224, sonic-net#10923, sonic-net#12164, sonic-net#12775, sonic-net#12796, sonic-net#12806, sonic-net#12808
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com> Why I did it Arista 7060 platform has a rare and unreproduceable PCIe timeout that could possibly be solved with increasing the switch PCIe timeout value. To do this we'll call a script for this platform to increase the PCIe timeout on boot-up. No issues would be expected from the setpci command. From the PCIe spec: "Software is permitted to change the value in this field at any time. For Requests already pending when the Completion Timeout Value is changed, hardware is permitted to use either the new or the old value for the outstanding Requests, and is permitted to base the start time for each Request either on when this value was changed or on when each request was issued. " How I did it Add "platform-init" support in swss docker similar to how "hwsku-init" is called, only this would be for any device belonging to a platform. Then the script would reside in device data folder. Additionally, add pciutils dependency to docker-orchagent so it can run the setpci commands. How to verify it On bootup of an Arista 7060, can execute: lspci -vv -s 01:00.0 | grep -i "devctl2" In order to check that the timeout has changed.
The platform-init, similar to hwsku-init, would be scripts that need to
be called for a specific platform.
Why I did it
Arista 7060 platform has a rare and unreproduceable PCIe timeout that could possibly be solved with increasing the switch PCIe timeout value. To do this we'll call a script for this platform to increase the PCIe timeout on boot-up.
No issues would be expected from the setpci command. From the PCIe spec:
"Software is permitted to change the value in this field at any
time. For Requests already pending when the Completion
Timeout Value is changed, hardware is permitted to use either
the new or the old value for the outstanding Requests, and is
permitted to base the start time for each Request either on when
this value was changed or on when each request was issued. "
How I did it
Add "platform-init" support in swss docker similar to how "hwsku-init" is called, only this would be for any device belonging to a platform. Then the script would reside in device data folder.
Additionally, add pciutils dependency to docker-orchagent so it can run the setpci commands.
How to verify it
On bootup of an Arista 7060, can execute:
lspci -vv -s 01:00.0 | grep -i "devctl2"
In order to check that the timeout has changed.
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)