#### Why I did it
Improve readability of `show environment` output.
#### How I did it
In all sensors.conf, give the customized labels according to HW specifications for each model.
Signed-off-by: Sean Wu <sean_wu@edge-core.com>
Add support for Accton as9726-32d platform
This pull request is based on as9716-32d, so I reference as9716-32d to create new model: as9726-32d.
This module do not need led driver to control led, FPGA can handle it.
I also implement API2.0(sonic_platform) for this model, CPLD driver, PSU driver, Fan driver to control these HW behavior.
#### Why I did it
MSN4700 A1/A0 used different sensor chip but keep the existing platform name *x86_64-mlnx_msn4700-r0*, this is a workaround to replace the sensor conf on MSN4700 A1/A0
#### How I did it
Use a shell script to get the sensor conf path and copy that files to /etc/sensors.d/sensors.conf
- Why I did it
Current platform.json lacks some peripheral device related facts, like chassis/fan/pasu/drawer/thermal/components names, numbers, etc.
- How I did it
Add platform device facts to the platform.json file
- How to verify it
Run sonic-mgmt platform API tests which depend on these facts.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
* [202012] Add SOC property to enable AN/LT on some platforms
Why I did it
To enable autonegotiation/link training on some Broadcom-based platforms (Arista 7060CX, 7260CX3, 7050cx3, Celestica DX010)
How I did it
Add appropriate SOC property for enabling the feature to the Broadcom config files of appropriate platforms
Also convert line endings to UNIX format for one Celestica file
* Add 'phy_an_lt_msft' to BCM config file permitted list
Incorporate the below changes in DellEMC Z9332F platform:
- Implemented watchdog platform API support
- Implement ‘get_position_in_parent’, ‘is_replaceable’ methods for all device types
- Change return type of SFP methods to match specification in sonic_platform_common/sfp_base.py
- Added platform.json file in device directory.
Co-authored-by: V P Subramaniam <Subramaniam_Vellalap@dell.com>
- Why I did it
Enable VXLAN src port range configuration via SAI profile for Mellanox-SN3800-D28C49S1 SKU
- How I did it
Added SAI_VXLAN_SRCPORT_RANGE_ENABLE=1 configuration to appropriate sai.profile
Signed-off-by: Andriy Yurkiv <ayurkiv@nvidia.com>
Set hierarchical ecmp level to 2 instead of 3. Based on CS00011833367, ecmp level must be set to 2.
This is already handled for TH2 platforms. Change is required only for TD3
Co-authored-by: Ubuntu <prsunny@prince-vm.vzw1i4tqyeburcdz5lrgulxi2c.yx.internal.cloudapp.net>
#### Why I did it
- xcvrd crash was seen in latest 201811 images.
- For Dell S6100,API 2.0 uses poll mode while 1.0 was still using interrupt mode.
#### How I did it
- Modified get_transceiver_change_event in 1.0 to poll mode.
Fix to the correct value for all SPC1 devices.
For 10G added 10GB_CX4_XAUI, 10GB_KX4, 10GB_KR, 10GB_SR and 10GB_ER_LR
For 50G added 50GB_SR2
This bitmask represents all the options available for interface type and some were missing.
Note: it was working just fine if you were setting the value from SONiC CLI but not from the default SAI Profile.
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
* 7260cx3 DualToR config.bcm support based on DualToR setting in device metadata at boot time.
For HWSKU Arista-7260CX3-C64 the MMU setting SOC for T0/T1 is also combined into the config.bcm.j2 logic so use just one config file and adding delta based on Switch Roles.
Why I did it
These ports are being enumerated by the latest SAI. But they are not defined in port_config.ini.
SONiC end up trying to delete these 3 ports and hit SAI error and crash.
How I did it
Add the GbE and the 2 HiGig ports in the port_config.ini.
How to verify it
Put the port_config.ini on a device crashing with port deleting. load minigraph and the crash stopped.
Signed-off-by: Ying Xie ying.xie@microsoft.com
The platform name for MSN4600C in sfputil pliugin is not complete: "x86_64-mlnx_msn4600c" -> "x86_64-mlnx_msn4600c-r0"
Signed-off-by: Kebo Liu <kebol@nvidia.com>
- Why I did it
Add missed files for dynamic buffer calculation for ACS-MSN3420 and ACS-MSN4410
- How I did it
asic_table.j2: Add mapping from platform to ASIC
Add buffer_dynamic.json.j2 for ACS-MSN4410.
- How to verify it
Check whether the dynamic buffer calculation daemon starts successfully.
Signed-off-by: Stephen Sun <stephens@nvidia.com>
The file device/mellanox/x86_64-mlnx_msn4410-r0/plugins/sfputil.py is not a software link for device/mellanox/x86_64-mlnx_msn2700-r0/plugins/sfputil.py. And it is still using python2 syntex which causes some SFP CLI error. The PR is to change it to a softlink and add 4410 support in device/mellanox/x86_64-mlnx_msn2700-r0/plugins/sfputil.py.
- Why I did it
Mellanox-SN4600C-D112C8 SKU is not configured properly.
It should have 112 50G interfaces and 8 100G interfaces as described on this PR.
- How I did it
Changed port_config.ini & sai profile.
- How to verify it
Apply this HwSKU to a MSN4600C Mellanox platform.
#### Why I did it
- The xcvrd service requires an event detection function, unplug or plug in the transceiver.
#### How I did it
- Add sysfs interrupt to notify userspace app of external interrupt
- Implement get_change_event() in chassis api.
- Also begin installing Python 3 sonic-platform package for Celestica platforms
As booting on DCS-7060DX4-32 would use the default sku of DCS-7060PX4-32 which is not compatible,
thus move some files around to properly separate the configurations that are device specific.
Signed-off-by: Samuel Angebault <staphylo@arista.com>
#### Why I did it
Change buffer config for new SKU Mellanox-SN2700-D40C8S8
#### How I did it
Reuse the buffer config of SKU Mellanox-SN2700-D48C8
#### How to verify it
Run sonic-mgmt qos test and all passed
- Why I did it
To fix PCIEd errors in log.
- How I did it
Update pcie.yaml with the right PCI addresses.
- How to verify it
Check logs, operation occurs each minute.
Signed-off-by: liora <liora@nvidia.com>
- Why I did it
Add support for new 64x200G SN4600 systems
- How I did it
Add all relevant files (w/o platform.json and hwsku.json as they will come later) with default SKU.
- How to verify it
Install image on switch, verify all ports are up and configured properly, run full platform SONiC tests.
#### Why I did it
Add new SKU for SN2700 Mellanox system that supports the following port configuration:
8 X 100G
40 X 50G
8 X 10G
#### How I did it
Add new Folder - "Mellanox-SN2700-D40C8S8" under /sonic-buildimage/device/mellanox/x86_64-mlnx_msn2700-r0/
that contains the relevant files supporting this SKU
the buffers are based on SKU: D48C8 . Later on it will be configured specific for this SKU
#### How to verify it
Bring up the image, run "show interface status" and make sure that all ports are up and reflect the following requirement:
Port 1/3 will be used as 4x10G
Port 2/4 - Not exist (blocked since 1 and 3 split to 4)
Port 7/8/9/10/23/24/25/26 will used as 100G
All other ports will be used as 2x50G
#### Which release branch to backport (provide reason below if selected)
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [X] 202012
#### Description for the changelog
Support new SKU under the name of SN2700-D40C8S8
In preparation for the merging of Azure/sonic-platform-common#173, which properly defines class and instance members in the Platform API base classes.
It is proper object-oriented methodology to call the base class initializer, even if it is only the default initializer. This also future-proofs the potential addition of custom initializers in the base classes down the road.
The S6000 devices, the cold reboot is abrupt and it is likely to cause issues which will cause the device to land into EFI shell. Hence the platform reboot will happen after graceful unmount of all the filesystems as in S6100.
Moved the platform_reboot to platform_reboot_override and hooked it to the systemd shutdown services as in S6100
- Why I did it
The pcie configuration file location is under plugin directory not under platform directory.
#6437
- How I did it
Move all pcie.yaml configuration file from plugin to platform directory.
Remove unnecessary timer to start pcie-check.service
Move pcie-check.service to sonic-host-services
- How to verify it
Verify on the device
- Why I did it
While DPB files are provided, SONiC community deploy via minigraph is not supported.
As of that platfrom.json and hwsku.json files related to Mellanox platforms are removed for now.
- How I did it
Remove platfrom.json and hwsku.json files for Mellanox platforms/SKU
- Add support for `DCS-7050SX3-48YC8` and `DCS-7050SX3-48C8` platform
- Add support for more variants of `DCS-7280CR3-32[PD]4`
- Add Supervisor to Linecard consutil support
- Complete Watchdog platform API support
- Fix some PSU behavior on `DCS-7050QX-32` and `DCS-7060CX-32S`
- Fix SEU management on `DCS-7060CX-32S`
- Allow kernel modules to build up to linux 5.10
- Rename led color `orange` to `amber`
- Miscellaneous fixes
- Improve sonic-mgmt platform test suite pass rate
- Improve coverage of platform unit tests
- Provide platform specific reboot logic as per platform porting guide
- Fix bug due to pcie.yaml file being located in the wrong directory
- Why I did it
Support shared headroom pool
Signed-off-by: Stephen Sun stephens@nvidia.com
- How I did it
Port configurations for SKUs based on 2700/3800 platform from 201911
For SN3800 platform:
C64: 32 100G down links and 32 100G up links.
D112C8: 112 50G down links and 8 100G up links.
D24C52: 24 50G down links, 20 100G down links, and 32 100G up links.
D28C50: 28 50G down links, 18 100G down links, and 32 100G up links.
For SN2700 platform:
D48C8: 48 50G down links and 8 100G up links
C32: 16 100G downlinks and 16 100G uplinks
Add configuration for Mellanox-SN4600C-D112C8
112 50G down links and 8 100G up links.
- How to verify it
Run regression test.
- Why I did it
Enable platform API tests to run successfully by providing required test infrastructure files along with supporting changes.
- How I did it
Added platform.json along with supporting changes.
- Addition of pcie.yaml supporting pcied
- Addition of Real fan drawer support vs Virtual
- Removal of python2 wheel with support in place for python3
- supporting changes platform api tests
Submodule commits included:
* src/sonic-platform-common 6ad0004...bd4dc03 (1):
> [sonic_sfp/qsfp_dd.py] Update DOM capability method name to align with other drivers (#163)
Also align all calling function names to match.
Port_config update for hwsku 7050CX3-32S-C3 - add two 10G ports.
This change is added to fix issue of "PortsOrch initialization failure" seen by previous removal of these 10G ports.
Tested on the device with new minigraph, and the PortsOrch initialization failure is not seen.
BRCM SDK 6.5.21 includes firmware updates (premier cancun) for TD3 platforms. The firmware update is required on TD3 platforms, which is packaged with BCMSAI 4.3.0.10.
**- How I did it**
Updated BCM config with a new variable that specifies the firmware package path. SDK uses this path to locate firmware packages and load during cold boot.
**- How to verify it**
bsv
BRCM SAI ver: [4.3.0.10], OCP SAI ver: [1.7.1], SDK ver: [sdk-6.5.21] CANCUN ver: [5.3.3]
drivshell>
admin@str2-7050cx3-acs-02:~$ bcmsh
Press Enter to show prompt.
Press Ctrl+C to exit.
NOTICE: Only one bcmsh or bcmcmd can connect to the shell at same time.
drivshell>cancun stat
cancun stat
UNIT0 CANCUN:
CIH: LOADED
Ver: 06.06.01
CMH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
CCH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
CEH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
drivshell>
**- Why I did it**
PR https://github.com/Azure/sonic-platform-common/pull/102 modified the name of the SFF-8436 (QSFP) method to align the method name between all drivers, renaming it from `parse_qsfp_dom_capability` to `parse_dom_capability`. Once the submodule was updated, the callers using the old nomenclature broke. This PR updates all callers to use the new naming convention.
**- How I did it**
Update the name of the function globally for all calls into the SFF-8436 driver.
Note that the QSFP-DD driver still uses the old nomenclature and should be modified similarly. I will open a PR to handle this separately.
**- Why I did it**
To incorporate the below changes in DellEMC S6100, S6000 platforms.
- S6100, S6000:
- Enable 'thermalctld'
- Implement DeviceBase methods (presence, status, model, serial) for Fantray and Component
- Implement ‘get_position_in_parent’, ‘is_replaceable’ methods for all device types
- Implement ‘get_status’ method for Fantray
- Implement ‘get_temperature’, ‘get_temperature_high_threshold’, ‘get_voltage_high_threshold’, ‘get_voltage_low_threshold’ methods for PSU
- Implement ‘get_status_led’, ‘set_status_led’ methods for Chassis
- SFP:
- Make EEPROM read both Python2 and Python3 compatible
- Fix ‘get_tx_disable_channel’ method’s return type
- Implement ‘tx_disable’, ‘tx_disable_channel’ and ‘set_power_override’ methods
- S6000:
- Move PSU thermal sensors from Chassis to respective PSU
- Make available the data of both Fans present in each Fantray
**- How I did it**
- Remove 'skip_thermalctld:true' in pmon_daemon_control.json
- Implement the platform API methods in the respective device files
- Use `bytearray` for data read from transceiver EEPROM
- Change return type of 'get_tx_disable_channel' to match specification in sonic_platform_common/sfp_base.py
**- Why I did it**
- Add as4630_54pe SDK configuration parameters.
**- How I did it**
- Add l3_alpm_enable=2 and ipv6_lpm_128b_enable=1 in hx5-as4630-48x1G+4x25G+2x100G.bcm.
Co-authored-by: derek_sun <derek_sun@edge-core>
Co-authored-by: derek_sun <ecsonic@edge-core.com>
port_config.ini for HWSKU Arista-7050CX3-32S-C32 has missing speed column and duplicated lanes.
The incorrect speed causes issues in Orchagent RESTARTCHECK as the below task remains as the remaining item during swss shutdown.
**- Why I did it**
- The thermalctld daemon on the Pmon docker requires support from the thermal manager API.
**- How I did it**
- Removed the old function for detecting a faulty fan.
- Removed the old function for detecting excess temperature.
- Implement thermal_manager APIs based on ThermalManagerBase
- Implement thermal_conditions APIs based on ThermalPolicyConditionBase
- Implement thermal_actions APIs based on ThermalPolicyActionBase
- Implement thermal_info APIs based on ThermalPolicyInfoBase
- Add thermal_policy.json
In order to build up device hierachy, PSU and module thermals are no longer child of chassis. PSU thermal belongs to PSU objects and SFP thermals belong to SFP object now. Need align this change in platform.json. Move thermal objects to correct parent device
fix platform driver breakage due to python3 upgrade and fix load minigraph errors with config load_minigraph -y
**- How I did it**
added python3-smbus to the pmon docker template since the previous was python2 specific
fixed additional "ord" python2 specific code
fixed the jinja templates used by qos reload - the template logic required data to be parsed
**- How to verify it**
run "show platform XXX" commands and verify output
run "sudo config load_minigraph -y" and verify configuration
run "show interfaces XXX" and verify output
Co-authored-by: Carl Keene <keene@nokia.com>
Y* profile is the name pattern for p4 programs that developed for the current platform. The difference between them is features enabled and resource reservation.
For this platform, it is expected to work on any Y profile. but after the latest changes, the first Y profile is always used.
Prevent system-healthd from service from failing at boot time due to missing configuration.
Also adds basic support for healthd.
The following caveat exists with this placeholder configuration:
- No PSU monitoring (sensors/fans)
- No ASIC temperature monitoring
- Why I did it
The sai.profile file in kvm images overrides the warmboot file with path /var/cache/sai_warmboot.bin. Since the directory /var/cache is not mounted in syncd, it will be cleared in an image upgrade, the warm-reboot image upgrade will fail if the file is put in the directory.
Fix#6183
- How I did it
Remove the path that overrides the default path. The warmboot file path will then be the default value /var/warmboot/sai-warmboot.bin. Since /var/warmboot/ is mounted by /host/warmboot/ in the host, it could survive an image upgrade.
- How to verify it
Tested warm reboot upgrading kvm image locally.
**- Why I did it**
To support dynamic buffer calculation.
This PR also depends on the following PRs for sub modules
- [sonic-swss: [buffermgr/bufferorch] Support dynamic buffer calculation #1338](https://github.com/Azure/sonic-swss/pull/1338)
- [sonic-swss-common: Dynamic buffer calculation #361](https://github.com/Azure/sonic-swss-common/pull/361)
- [sonic-utilities: Support dynamic buffer calculation #973](https://github.com/Azure/sonic-utilities/pull/973)
**- How I did it**
1. Introduce field `buffer_model` in `DEVICE_METADATA|localhost` to represent which buffer model is running in the system currently:
- `dynamic` for the dynamic buffer calculation model
- `traditional` for the traditional model in which the `pg_profile_lookup.ini` is used
2. Add the tables required for the feature:
- ASIC_TABLE in platform/\<vendor\>/asic_table.j2
- PERIPHERAL_TABLE in platform/\<vendor\>/peripheral_table.j2
- PORT_PERIPHERAL_TABLE on a per-platform basis in device/\<vendor\>/\<platform\>/port_peripheral_config.j2 for each platform with gearbox installed.
- DEFAULT_LOSSLESS_BUFFER_PARAMETER and LOSSLESS_TRAFFIC_PATTERN in files/build_templates/buffers_config.j2
- Add lossless PGs (3-4) for each port in files/build_templates/buffers_config.j2
3. Copy the newly introduced j2 files into the image and rendering them when the system starts
4. Update the CLI options for buffermgrd so that it can start with dynamic mode
5. Fetches the ASIC vendor name in orchagent:
- fetch the vendor name when creates the docker and pass it as a docker environment variable
- `buffermgrd` can use this passed-in variable
6. Clear buffer related tables from STATE_DB when swss docker starts
7. Update the src/sonic-config-engine/tests/sample_output/buffers-dell6100.json according to the buffer_config.j2
8. Remove buffer pool sizes for ingress pools and egress_lossy_pool
Update the buffer settings for dynamic buffer calculation
python2 is end of life and SONiC is going to support python3. This PR is going to support:
1. Mellanox SONiC platform API python3 support
2. Install both python2 and python3 verson of Mellanox SONiC platform API or pmon and host side
platform.json is needed for sonic-mgmt testing. Also in the future it will be used as part of dynamic port breakout.
Also removed the folder symlink for BlackhawkDD because it has a different platform.json than BlackhawkO.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
Fixes#6126.
There is a bug in getting the path of voltage, current and power. The
list object is directly converted to string to format the file path. As
a result, read_txt_file will get None value and a WARNING will be
recorded. This commit fix the issue.
Signed-off-by: bingwang <bingwang@microsoft.com>
Current support for the 7060PX4-32 and 7060DX4 was broken.
With this change, ports are now linking fine.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
Rename chip name dps1900-i2c-X-58 to pmbus-i2c-X-58 in sensors.conf for Arista 7170 due to latest updates for Arista driver submodules #5686. After these updates adapter dps1900 was renamed and sensors.conf file is not applied properly. Issue was observed started from BFN SONiC image 16.
Signed-off-by: Nazar Tkachuk <nazarx.tkachuk@intel.com>
Submodule updates include the following commits:
* src/sonic-utilities 9dc58ea...f9eb739 (18):
> Remove unnecessary calls to str.encode() now that the package is Python 3; Fix deprecation warning (#1260)
> [generate_dump] Ignoring file/directory not found Errors (#1201)
> Fixed porstat rate and util issues (#1140)
> fix error: interface counters is mismatch after warm-reboot (#1099)
> Remove unnecessary calls to str.decode() now that the package is Python 3 (#1255)
> [acl-loader] Make list sorting compliant with Python 3 (#1257)
> Replace hard-coded fast-reboot with variable. And some typo corrections (#1254)
> [configlet][portconfig] Remove calls to dict.has_key() which is not available in Python 3 (#1247)
> Remove unnecessary conversions to list() and calls to dict.keys() (#1243)
> Clean up LGTM alerts (#1239)
> Add 'requests' as install dependency in setup.py (#1240)
> Convert to Python 3 (#1128)
> Fix mock SonicV2Connector in python3: use decode_responses mode so caller code will be the same as python2 (#1238)
> [tests] Do not trim from PATH if we did not append to it; Clean up/fix shebangs in scripts (#1233)
> Updates to bgp config and show commands with BGP_INTERNAL_NEIGHBOR table (#1224)
> [cli]: NAT show commands newline issue after migrated to Python3 (#1204)
> [doc]: Update Command-Reference.md (#1231)
> Added 'import sys' in feature.py file (#1232)
* src/sonic-py-swsssdk 9d9f0c6...1664be9 (2):
> Fix: no need to decode() after redis client scan, so it will work for both python2 and python3 (#96)
> FieldValueMap `contains`(`in`) will also work when migrated to libswsscommon(C++ with SWIG wrapper) (#94)
- Also fix Python 3-related issues:
- Use integer (floor) division in config_samples.py (sonic-config-engine)
- Replace print statement with print function in eeprom.py plugin for x86_64-kvm_x86_64-r0 platform
- Update all platform plugins to be compatible with both Python 2 and Python 3
- Remove shebangs from plugins files which are not intended to be executable
- Replace tabs with spaces in Python plugin files and fix alignment, because Python 3 is more strict
- Remove trailing whitespace from plugins files
Fix 259 alerts reported by the LGTM tool:
- 245 for Unused import
- 7 for Testing equality to None
- 5 for Duplicate key in dict literal
- 1 for Module is imported more than once
- 1 for Unused local variable
**- Why I did it**
We were building a custom version of Supervisor because I had added patches to prevent hangs and crashes if the system clock ever rolled backward. Those changes were merged into the upstream Supervisor repo as of version 3.4.0 (http://supervisord.org/changes.html#id9), therefore, we should be able to simply install the vanilla package via pip. This will also allow us to easily move to Python 3, as Python 3 support was added in version 4.0.0.
**- How I did it**
- Remove Makefiles and patches for building supervisor package from source
- Install Python 3 supervisor package version 4.2.1 in Buster base container
- Also install Python 3 version of supervisord-dependent-startup in Buster base container
- Debian package installed binary in `/usr/bin/`, but pip package installs in `/usr/local/bin/`, so rather than update all absolute paths, I changed all references to simply call `supervisord` and let the system PATH find the executable to prevent future need for changes just in case we ever need to switch back to build a Debian package, then we won't need to modify these again.
- Install Python 2 supervisor package >= 3.4.0 in Stretch and Jessie base containers
Need A mmu configuration to get the device going without generating lots of warnings.
Similar to dummy MMU configuration for Arista-7050CX3-32S-C32, this configuration will need to be updated with correct numbers. This MMU configuration is copied from 7060 comparable hwsku.
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
This change introduces PDDF which is described here: https://github.com/Azure/SONiC/pull/536
Most of the platform bring up effort goes in developing the platform device drivers, SONiC platform APIs and validating them. Typically each platform vendor writes their own drivers and platform APIs which is very tailor made to that platform. This involves writing code, building, installing it on the target platform devices and testing. Many of the details of the platform are hard coded into these drivers, from the HW spec. They go through this cycle repetitively till everything works fine, and is validated before upstreaming the code.
PDDF aims to make this platform driver and platform APIs development process much simpler by providing a data driven development framework. This is enabled by:
JSON descriptor files for platform data
Generic data-driven drivers for various devices
Generic SONiC platform APIs
Vendor specific extensions for customisation and extensibility
Signed-off-by: Fuzail Khan <fuzail.khan@broadcom.com>
* [Juniper] Platform bug fixes / improvements
This patch set introduces the following changes for
the two platforms.
- QFX5210
- Fixes a driver bug related to reboot notifier
- Disable pcied
- Introduces a wrapper script for fast / warm reboots
for unloading the driver containing reboot handler
- Support for PSM4 optics in media_settings
- QFX5200
- BCM configuration file updates
- Bug fixes for EM policy
- Fixes a driver bug related to reboot notifier
- Introduces a wrapper script for fast / warm reboots
for unloading the driver containing reboot handler
- Disable pcied
- Support for PSM4 optics
Signed-off-by: Ciju Rajan K <crajank@juniper.net>
Treat devices that are ToRRouters (ToRRouters and BackEndToRRouters) the same when rendering templates
Except for BackEndToRRouters belonging to a storage cluster, since these devices have extra sub-interfaces created
Treat devices that are LeafRouters (LeafRouters and BackEndLeafRouters) the same when rendering templates
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
- Why I did it
On Arista-7050CX3-32S-C32, there are constant stream of errors like following.
Nov 3 21:56:24.415190 str2-7050cx3-acs-06 NOTICE swss#orchagent: :- registerInWdDb: No lossless TC found on port Ethernet68
Which causes:
loganalyzer to claim test failed.
leaving the system without MMU configuration. Which couldn't be good for any IO test.
- How I did it
Added these MMU configuraions are copied from another platform and guaranteed to be incorrect for hwsku Arista-7050CX3-32S-C32.
Adding them so that we have A MMU configuration and the system won't throw a whole bunch of errors and leave MMU unconfigured. The correct MMU configuration will come later.
This configuration is definitely not suitable for testing system performance or QoS behavior.
Signed-off-by: Ying Xie ying.xie@microsoft.com
- How to verify it
Test will have chance to pass. Ran a few test that would fail otherwise.
This PR has a dependency on community change to move PCIe config files from $PLATFORM/plugin folder to $PLATFORM/ folder
- Why I did it
To support PCIed daemon on Mellanox platforms
- How I did it
Add PCIed config yaml files for all Mellanox platforms
Update pmon daemon config files for SimX platforms
We don't need a custom platform reboot on Clearwater2(Ms). They are expected to be rebooted via a normal linux soft reboot.
Remove symlink to the arista common platform reboot for those 2 platforms.
**- Why I did it**
Converted two SP model to single pool model and modified the buffer size.
**- How I did it**
Changed buffer_default settings for all the DellEMC Z9264f HWSKU's.
**- How to verify it**
Check SP register values in NPU shell.
**- Which release branch to backport (provide reason below if selected)**
Need to be cherry picked for 201911 branch.
- Enable thermalctld support for our platforms
- Fix Chassis.get_num_sfp which had an off by one
- Implement read_eeprom and write_eeprom in SfpBase
- Refactor of Psus and PsuSlots. Psus they are now detected and metadata reported
- Improvements to modular support
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
The `get_serial_number()` method in the ChassisBase and ModuleBase classes was redundant, as the `get_serial()` method is inherited from the DeviceBase class. This method was removed from the base classes in sonic-platform-common and the submodule was updated in https://github.com/Azure/sonic-buildimage/pull/5625.
This PR aligns the existing vendor platform API implementations to remove the `get_serial_number()` methods and ensure the `get_serial()` methods are implemented, if they weren't previously.
Note that this PR does not modify the Dell platform API implementations, as this will be handled as part of https://github.com/Azure/sonic-buildimage/pull/5609
- Make DellEMC platform modules Python3 compliant.
- Change return type of PSU Platform APIs in DellEMC Z9264, S5232 and Thermal Platform APIs in S5232 to 'float'.
- Remove multiple copies of pcisysfs.py.
- PEP8 style changes for utility scripts.
- Build and install Python3 version of sonic_platform package.
- Fix minor Platform API issues.
bring up chassisdb service on sonic switch according to the design in
Distributed Forwarding in VoQ Arch HLD
Signed-off-by: Honggang Xu <hxu@arista.com>
**- Why I did it**
To bring up new ChassisDB service in sonic as designed in ['Distributed forwarding in a VOQ architecture HLD' ](90c1289eaf/doc/chassis/architecture.md).
**- How I did it**
Implement the section 2.3.1 Global DB Organization of the VOQ architecture HLD.
**- How to verify it**
ChassisDB service won't start without chassisdb.conf file on the existing platforms.
ChassisDB service is accessible with global.conf file in the distributed arichitecture.
Signed-off-by: Honggang Xu <hxu@arista.com>
* system health first commit
* system health daemon first commit
* Finish healthd
* Changes due to lower layer logic change
* Get ASIC temperature from TEMPERATURE_INFO table
* Add system health make rule and service files
* fix bugs found during manual test
* Change make file to install system-health library to host
* Set system LED to blink on bootup time
* Caught exceptions in system health checker to make it more robust
* fix issue that fan/psu presence will always be true
* fix issue for external checker
* move system-health service to right after rc-local service
* Set system-health service start after database service
* Get system up time via /proc/uptime
* Provide more information in stat for CLI to use
* fix typo
* Set default category to External for external checker
* If external checker reported OK, save it to stat too
* Trim string for external checker output
* fix issue: PSU voltage check always return OK
* Add unit test cases for system health library
* Fix LGTM warnings
* fix demo comments: 1. get boot up timeout from monit configuration file; 2. set system led in library instead of daemon
* Remove boot_timeout configuration because it will get from monit config file
* Fix argument miss
* fix unit test failure
* fix issue: summary status is not correct
* Fix format issues found in code review
* rename th to threshold to make it clearer
* Fix review comment: 1. add a .dep file for system health; 2. deprecated daemon_base and uses sonic-py-common instead
* Fix unit test failure
* Fix LGTM alert
* Fix LGTM alert
* Fix review comments
* Fix review comment
* 1. Add relevant comments for system health; 2. rename external_checker to user_define_checker
* Ignore check for unknown service type
* Fix unit test issue
* Rename user define checker to user defined checker
* Rename user_define_checkers to user_defined_checkers for configuration file
* Renmae file user_define_checker.py -> user_defined_checker.py
* Fix typo
* Adjust import order for config.py
Co-authored-by: Joe LeVeque <jleveque@users.noreply.github.com>
* Adjust import order for src/system-health/health_checker/hardware_checker.py
Co-authored-by: Joe LeVeque <jleveque@users.noreply.github.com>
* Adjust import order for src/system-health/scripts/healthd
Co-authored-by: Joe LeVeque <jleveque@users.noreply.github.com>
* Adjust import orders in src/system-health/tests/test_system_health.py
* Fix typo
* Add new line after import
* If system health configuration file not exist, healthd should exit
* Fix indent and enable pytest coverage
* Fix typo
* Fix typo
* Remove global logger and use log functions inherited from super class
* Change info level logger to notice level
Co-authored-by: Joe LeVeque <jleveque@users.noreply.github.com>
This is to fix pcie firmware check assert in Broadcom SDK once the SAI changes merges. This will be in the future but adding the soc property in the broadcom config now.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
**- Why I did it**
There is error i2c mapping for port 11,12 and port 19, 20.
**- How I did it**
Fix to correct i2c mapping
Co-authored-by: Jostar Yang <jostar_yang@accton.com.tw>
* buildimage: Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature
* scripts and configuration needed to support a second syncd docker (physyncd)
* physyncd supports gearbox device and phy SAI APIs and runs multiple instances of syncd, one per phy in the device
* support for VS target (sonic-sairedis vslib has been extended to support a virtual BCM81724 gearbox PHY).
HLD is located at b817a12fd8/doc/gearbox/gearbox_mgr_design.md
**- Why I did it**
This work is part of the gearbox phy joint effort between Microsoft and Broadcom, and is based
on multi-switch support in sonic-sairedis.
**- How I did it**
Overall feature was implemented across several projects. The collective pull requests (some in late stages of review at this point):
https://github.com/Azure/sonic-utilities/pull/931 - CLI (merged)
https://github.com/Azure/sonic-swss-common/pull/347 - Minor changes (merged)
https://github.com/Azure/sonic-swss/pull/1321 - gearsyncd, config parsers, changes to orchargent to create gearbox phy on supported systems
https://github.com/Azure/sonic-sairedis/pull/624 - physyncd, virtual BCM81724 gearbox phy added to vslib
**- How to verify it**
In a vslib build:
root@sonic:/home/admin# show gearbox interfaces status
PHY Id Interface MAC Lanes MAC Lane Speed PHY Lanes PHY Lane Speed Line Lanes Line Lane Speed Oper Admin
-------- ----------- --------------- ---------------- --------------- ---------------- ------------ ----------------- ------ -------
1 Ethernet48 121,122,123,124 25G 200,201,202,203 25G 204,205 50G down down
1 Ethernet49 125,126,127,128 25G 206,207,208,209 25G 210,211 50G down down
1 Ethernet50 69,70,71,72 25G 212,213,214,215 25G 216 100G down down
In addition, docker ps | grep phy should show a physyncd docker running.
Signed-off-by: syd.logan@broadcom.com
As part of Platform api testing for multiple platforms, this pull request adds a platform.json file which contains all
the static data for Mellanox-2700 platform. This file would provide all the platform specific data required for testing of all the Platform tests . As part of testing the API's the values of static/default objects within this specific platform file will be compared against the values returned by calling the Platform specific API's in a typical platform test
However in SAI 3.7 default behaviout got changes to 128 Group and 128
Memeber each.
This change is to make sure we are using same ECMP Group/Memeber Per
Group for 3.7 also so that behaviour is consistent.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
C64: 32 100G down links and 32 100G up links.
D112C8: 112 50G down links and 8 100G up links.
D24C52: 24 50G down links, 20 100G down links, and 32 100G up links.
D28C50: 28 50G down links, 18 100G down links, and 32 100G up links.
Signed-off-by: Stephen Sun <stephens@nvidia.com>
This include the platform.json for Seastone platform and
individual hwsku.json for each HWSKU
port_config.ini will be removed once the CLI/parser library etc changes are merged
**- What I did**
On boarding DPB feature to Seastone HWSKUs
**- How I did it**
Add platform.json for Seastone and hwsku.json files to relevant HWSKUs.
**- How to verify it**
```
sudo sonic-cfggen -H -k Seastone-DX010 --preset=t1 > config_db.json
sudo config reload config_db.json -y
show interface status:
admin@lnos-x1-a-csw03:~$ show interfaces status
Interface Lanes Speed MTU FEC Alias Vlan Oper Admin Type Asym PFC
----------- --------------- ------- ----- ----- ------- ------ ------ ------- ------ ----------
Ethernet0 65,66,67,68 100G 9100 N/A Eth1/1 routed down up N/A N/A
Ethernet4 69,70,71,72 100G 9100 N/A Eth2/1 routed down up N/A N/A
Ethernet8 73,74,75,76 100G 9100 N/A Eth3/1 routed down up N/A N/A
Ethernet12 77,78,79,80 100G 9100 N/A Eth4/1 routed down up N/A N/A
Ethernet16 33,34,35,36 100G 9100 N/A Eth5/1 routed down up N/A N/A
Ethernet20 37,38,39,40 100G 9100 N/A Eth6/1 routed down up N/A N/A
Ethernet24 41,42,43,44 100G 9100 N/A Eth7/1 routed down up N/A N/A
Ethernet28 45,46,47,48 100G 9100 N/A Eth8/1 routed down up N/A N/A
Ethernet32 49,50,51,52 100G 9100 N/A Eth9/1 routed down up N/A N/A
Ethernet36 53,54,55,56 100G 9100 N/A Eth10/1 routed down up N/A N/A
Ethernet40 57,58,59,60 100G 9100 N/A Eth11/1 routed down up N/A N/A
Ethernet44 61,62,63,64 100G 9100 N/A Eth12/1 routed down up N/A N/A
Ethernet48 81,82,83,84 100G 9100 N/A Eth13/1 routed down up N/A N/A
Ethernet52 85,86,87,88 100G 9100 N/A Eth14/1 routed down up N/A N/A
Ethernet56 89,90,91,92 100G 9100 N/A Eth15/1 routed down up N/A N/A
Ethernet60 93,94,95,96 100G 9100 N/A Eth16/1 routed down up N/A N/A
Ethernet64 97,98,99,100 100G 9100 N/A Eth17/1 routed down up N/A N/A
Ethernet68 101,102,103,104 100G 9100 N/A Eth18/1 routed down up N/A N/A
Ethernet72 105,106,107,108 100G 9100 N/A Eth19/1 routed up up N/A N/A
Ethernet76 109,110,111,112 100G 9100 N/A Eth20/1 routed down up N/A N/A
Ethernet80 1,2,3,4 100G 9100 N/A Eth21/1 routed down up N/A N/A
Ethernet84 5,6,7,8 100G 9100 N/A Eth22/1 routed down up N/A N/A
Ethernet88 9,10,11,12 100G 9100 N/A Eth23/1 routed down up N/A N/A
Ethernet92 13,14,15,16 100G 9100 N/A Eth24/1 routed down up N/A N/A
Ethernet96 17,18,19,20 100G 9100 N/A Eth25/1 routed down up N/A N/A
Ethernet100 21,22,23,24 100G 9100 N/A Eth26/1 routed down up N/A N/A
Ethernet104 25,26,27,28 100G 9100 N/A Eth27/1 routed down up N/A N/A
Ethernet108 29,30,31,32 100G 9100 N/A Eth28/1 routed down up N/A N/A
Ethernet112 113,114,115,116 100G 9100 N/A Eth29/1 routed down up N/A N/A
Ethernet116 117,118,119,120 100G 9100 N/A Eth30/1 routed down up N/A N/A
Ethernet120 121,122,123,124 100G 9100 N/A Eth31/1 routed down up N/A N/A
Ethernet124 125,126,127,128 100G 9100 N/A Eth32/1 routed down up N/A N/A
```
**Breakout to 2x50G:**
```
admin@lnos-x1-a-csw03:~$ sudo config interface breakout Ethernet0 2x50G -y -f
Running Breakout Mode : 1x100G[40G]
Target Breakout Mode : 2x50G
Ports to be deleted :
{
"Ethernet0": "100000"
}
Ports to be added :
{
"Ethernet2": "50000",
"Ethernet0": "50000"
}
After running Logic to limit the impact
Final list of ports to be deleted :
{
"Ethernet0": "100000"
}
Final list of ports to be added :
{
"Ethernet2": "50000",
"Ethernet0": "50000"
}
Loaded below Yang Models
['sonic-acl', 'sonic-extension', 'sonic-interface', 'sonic-loopback-interface', 'sonic-port', 'sonic-portchannel', 'sonic-types', 'sonic-vlan']
Note: Below table(s) have no YANG models:
CONTAINER_FEATURE, BGP_NEIGHBOR, VERSIONS, DEVICE_METADATA, FEATURE, LOCK, BREAKOUT_CFG, CRM,
Below Config can not be verified, It may cause harm to the system
{
"BREAKOUT_CFG": {
"Ethernet0": {
"brkout_mode": "1x100G[40G]"
}
}
}
Do you wish to Continue? [y/N]: y
Breakout process got successfully completed.
Please note loaded setting will be lost after system reboot. To preserve setting, run `config save`.
admin@lnos-x1-a-csw03:~$
admin@lnos-x1-a-csw03:~$
admin@lnos-x1-a-csw03:~$ show interfaces status
Interface Lanes Speed MTU FEC Alias Vlan Oper Admin Type Asym PFC
----------- --------------- ------- ----- ----- ------- ------ ------ ------- ------ ----------
Ethernet0 65,66 50G N/A N/A Eth1/1 routed down up N/A N/A
Ethernet2 67,68 50G 9100 N/A Eth1/3 routed down up N/A N/A
admin@lnos-x1-a-csw03:~$ bcmcmd ps
ps
ena/ speed/ link auto STP lrn inter max cut loop
port link Lns duplex scan neg? state pause discrd ops face frame thru? back
xe0( 68) down 2 50G FD SW No Forward None FA KR2 9412 No
xe1( 69) !ena 1 - SW No Forward None FA None 9122 No
```
**Breakout to 4x25G[10G]:**
```
admin@lnos-x1-a-csw03:~$ sudo config interface breakout Ethernet0 4x25G[10G] -y -f
Running Breakout Mode : 2x50G
Target Breakout Mode : 4x25G[10G]
Ports to be deleted :
{
"Ethernet2": "50000",
"Ethernet0": "50000"
}
Ports to be added :
{
"Ethernet2": "25000",
"Ethernet3": "25000",
"Ethernet0": "25000",
"Ethernet1": "25000"
}
After running Logic to limit the impact
Final list of ports to be deleted :
{
"Ethernet2": "50000",
"Ethernet0": "50000"
}
Final list of ports to be added :
{
"Ethernet2": "25000",
"Ethernet3": "25000",
"Ethernet0": "25000",
"Ethernet1": "25000"
}
Loaded below Yang Models
['sonic-acl', 'sonic-extension', 'sonic-interface', 'sonic-loopback-interface', 'sonic-port', 'sonic-portchannel', 'sonic-types', 'sonic-vlan']
Note: Below table(s) have no YANG models:
CONTAINER_FEATURE, BGP_NEIGHBOR, VERSIONS, DEVICE_METADATA, FEATURE, LOCK, BREAKOUT_CFG, CRM,
Below Config can not be verified, It may cause harm to the system
{
"BREAKOUT_CFG": {
"Ethernet0": {
"brkout_mode": "2x50G"
}
}
}
Do you wish to Continue? [y/N]: y
Breakout process got successfully completed.
Please note loaded setting will be lost after system reboot. To preserve setting, run `config save`.
admin@lnos-x1-a-csw03:~$ show interfaces status
Interface Lanes Speed MTU FEC Alias Vlan Oper Admin Type Asym PFC
----------- --------------- ------- ----- ----- ------- ------ ------ ------- ------ ----------
Ethernet0 65 25G N/A N/A Eth1/1 routed down up N/A N/A
Ethernet1 66 25G 9100 N/A Eth1/2 routed down up N/A N/A
Ethernet2 67 25G N/A N/A Eth1/3 routed down up N/A N/A
Ethernet3 68 25G 9100 N/A Eth1/4 routed down up N/A N/A
admin@lnos-x1-a-csw03:~$ bcmcmd ps
ps
ena/ speed/ link auto STP lrn inter max cut loop
port link Lns duplex scan neg? state pause discrd ops face frame thru? back
xe0( 68) down 1 25G FD SW No Forward None FA KR 9412 No
xe1( 69) down 1 25G FD SW No Forward None FA KR 9122 No
xe2( 70) down 1 25G FD SW No Forward None FA KR 9412 No
xe3( 71) down 1 25G FD SW No Forward None FA KR 9122 No
```
**Breakin back to 1x100G[40G]:**
```
admin@lnos-x1-a-csw03:~$ sudo config interface breakout Ethernet0 1x10G[40G] -y -f
[ERROR] Target mode 1x10G[40G] is not available for the port Ethernet0
Aborted!
admin@lnos-x1-a-csw03:~$ sudo config interface breakout Ethernet0 1x100G[40G] -y -f
Running Breakout Mode : 4x25G[10G]
Target Breakout Mode : 1x100G[40G]
Ports to be deleted :
{
"Ethernet2": "25000",
"Ethernet3": "25000",
"Ethernet0": "25000",
"Ethernet1": "25000"
}
Ports to be added :
{
"Ethernet0": "100000"
}
After running Logic to limit the impact
Final list of ports to be deleted :
{
"Ethernet2": "25000",
"Ethernet3": "25000",
"Ethernet0": "25000",
"Ethernet1": "25000"
}
Final list of ports to be added :
{
"Ethernet0": "100000"
}
Loaded below Yang Models
['sonic-acl', 'sonic-extension', 'sonic-interface', 'sonic-loopback-interface', 'sonic-port', 'sonic-portchannel', 'sonic-types', 'sonic-vlan']
Note: Below table(s) have no YANG models:
CONTAINER_FEATURE, BGP_NEIGHBOR, VERSIONS, DEVICE_METADATA, FEATURE, LOCK, FLEX_COUNTER_TABLE, BREAKOUT_CFG, CRM,
Below Config can not be verified, It may cause harm to the system
{
"BREAKOUT_CFG": {
"Ethernet0": {
"brkout_mode": "4x25G[10G]"
}
}
}
Do you wish to Continue? [y/N]: y
Breakout process got successfully completed.
Please note loaded setting will be lost after system reboot. To preserve setting, run `config save`.
admin@lnos-x1-a-csw03:~$ show interfaces status
Interface Lanes Speed MTU FEC Alias Vlan Oper Admin Type Asym PFC
----------- --------------- ------- ----- ----- ------- ------ ------ ------- ------ ----------
Ethernet0 65,66,67,68 100G N/A N/A Eth1/1 routed down up N/A N/A
admin@lnos-x1-a-csw03:~$ bcmcmd ps
ps
ena/ speed/ link auto STP lrn inter max cut loop
port link Lns duplex scan neg? state pause discrd ops face frame thru? back
ce0( 68) down 4 100G FD SW No Forward None FA KR4 9412 No
xe0( 69) !ena 1 - SW No Forward None FA None 9122 No
xe1( 70) !ena 2 - SW No Forward None FA None 9412 No
xe2( 71) !ena 1 - SW No Forward None FA None 9122 No
```
Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
Refactor SFP reset, low power get/set API, and plugins with new SDK SX APIs. Previously they were calling SDK SXD APIs which have glibc dependency because of shared memory usage.
Remove implementation "set_power_override", "tx_disable_channel", "tx_disable" which using SXD APIs, once related SDK SX API available, will add them back based on new SDK SX APIs.
- Merge chassis codebase upstream
- Add support for Otterlake supervisor
- Add support for NorthFace and Camp chassis
- Add support for Eldridge, Dragonfly and Brooks fabrics
- Add support for Clearwater2 and Clearwater2Ms linecards
- Add new arista Cli to power on/off cards
- Add new arista show Cli to inspect supervisor, chassis, fabrics and linecards
as needed by SAI 3.7 and above. Without this change
Warmboot fails from 3.5 to 3.7 as Braodcoam Datastructure
gets corrupted after warm-boot.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Modify port_config.ini files multi-asic vs platform. Changes done:
- Add new columns: index, asic_port_name, role(Int/Ext)
- Modify alias of interface names. Alias should match the interface names present in minigraph file.
Signed-off-by: SuvarnaMeenakshi <sumeenak@microsoft.com>
Calculate pool size in t1 as 24 * downlink port + 8 * uplink port
- Take both port and peer MTU into account when calculating headroom
- Worst case factor is decreased to 50%
- Mellanox-SN2700-C28D8 t0, assume 48 * 50G/5m + 8 * 100G/40m ports
- Mellanox-SN2700 (C32)
- t0: 16 * 100G/5m + 16 * 100G/40m
- t1: 16 * 100G/40m + 16 * 100G/300m
Signed-off-by: Stephen Sun <stephens@mellanox.com>
Co-authored-by: Stephen Sun <stephens@mellanox.com>
summary of E530 platfrom:
- CPU: CTC5236, arm64
- LAN switch chip set: CENTEC CTC7132 (TsingMa). TsingMa is a purpose built device to address the challenge in the recent network evolution such as Cloud computing. CTC7132 provides 440Gbps I/O bandwidth and 400Gcore bandwidth, the CTC7132 family combines a feature-rich switch core and an embedded ARM A53 CPU Core running at 800MHz/1.2GHz. CTC7132 supports a variety of port configurations, such as QSGMII and USXGMII-M, providing full-rate port capability from 100M to 100G.
- device E530-48T4X: 48 * 10/100/1000 Base-T Ports, 4 * 10GE SFP+ Ports.
- device E530-24X2C: 24 * 10 GE SFP+ Ports, 2 * 100GE QSFP28 Ports.
add new files in three directories:
device/centec/arm64-centec_e530_24x2c-r0
device/centec/arm64-centec_e530_48t4x_p-r0
platform/centec-arm64
Co-authored-by: taocy <taocy2@centecnetworks.com>
Co-authored-by: Gu Xianghong <gxh2001757@163.com>
Co-authored-by: shil <shil@centecnetworks.com>
As part of consolidating all common Python-based functionality into the new sonic-py-common package, this pull request:
1. Redirects all Python applications/scripts in sonic-buildimage repo which previously imported sonic_device_util or sonic_daemon_base to instead import sonic-py-common, which was added in https://github.com/Azure/sonic-buildimage/pull/5003
2. Replaces all calls to `sonic_device_util.get_platform_info()` to instead call `sonic_py_common.get_platform()` and removes any calls to `sonic_device_util.get_machine_info()` which are no longer necessary (i.e., those which were only used to pass the results to `sonic_device_util.get_platform_info()`.
3. Removes unused imports to the now-deprecated sonic-daemon-base package and sonic_device_util.py module
This is the next step toward resolving https://github.com/Azure/sonic-buildimage/issues/4999
Also reverted my previous change in which device_info.get_platform() would first try obtaining the platform ID string from Config DB and fall back to gathering it from machine.conf upon failure because this function is called by sonic-cfggen before the data is in the DB, in which case, the db_connect() call will hang indefinitely, which was not the behavior I expected. As of now, the function will always reference machine.conf.
