[backport]: i2c: mux: pca954x: allow management of device idle state via sysfs#177
Merged
lguohan merged 1 commit intosonic-net:masterfrom Jan 19, 2021
Merged
[backport]: i2c: mux: pca954x: allow management of device idle state via sysfs#177lguohan merged 1 commit intosonic-net:masterfrom
lguohan merged 1 commit intosonic-net:masterfrom
Conversation
Contributor
|
On what device is this tested? It’d be great, if you sent a backport request to stable@vger.kernel.org, so it gets added to the stable series. |
Closed
4 tasks
Contributor
Author
|
tested here. sonic-net/sonic-buildimage#6429 |
Contributor
|
Thank you for the reference. Commits should still be self-contained, and people cannot be expected to crossreference commits or even repositories. It’d be great, if the Celestica DX010 would be mentioned here too. Also, I really think a message to stable@vger.kernel.org with the backport request should be sent. (And soon SONiC should switch to Linux 5.10 anyway. ;-)) |
driver-i2c-mux-pca954x-allow-management-of-device-idle-stat.patch Signed-off-by: Guohan Lu <lguohan@gmail.com>
Contributor
Author
|
added the tested message. those patches will be removed 5.2-rc1. I haven't sent patch to stable@vger.kernel.org before. let me see what needs to be done before send to that mailing list. |
4 tasks
jleveque
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Jun 5, 2021
#### Why I did it - After [sonic-linux-kernel#177](sonic-net/sonic-linux-kernel#177) changes, the I2C mux channels of Baseboard and Switchboard CPLDs are moved from i2c-4 and i2c-5 to i2c-36 and i2c-37 respectively. - This caused QSFP driver initialization of i2c-36 to i2c-41 to fail causing the ports from Ethernet208 to Ethernet248 fail. #### How I did it - The fix to this problem is to change the order of QSFP driver initialization to I2C mux channels. - Instead of the order i2c-10 to i2c-41, the order i2c-4 to i2c-35 is being utilized. - Also, need to change the i2c-mux-channel number for Baseboard CPLD and switchboard CPLD in scripts to access them.
qiluo-msft
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Jun 9, 2021
#### Why I did it - After [sonic-linux-kernel#177](sonic-net/sonic-linux-kernel#177) changes, the I2C mux channels of Baseboard and Switchboard CPLDs are moved from i2c-4 and i2c-5 to i2c-36 and i2c-37 respectively. - This caused QSFP driver initialization of i2c-36 to i2c-41 to fail causing the ports from Ethernet208 to Ethernet248 fail. #### How I did it - The fix to this problem is to change the order of QSFP driver initialization to I2C mux channels. - Instead of the order i2c-10 to i2c-41, the order i2c-4 to i2c-35 is being utilized. - Also, need to change the i2c-mux-channel number for Baseboard CPLD and switchboard CPLD in scripts to access them.
carl-nokia
pushed a commit
to carl-nokia/sonic-buildimage
that referenced
this pull request
Aug 7, 2021
#### Why I did it - After [sonic-linux-kernel#177](sonic-net/sonic-linux-kernel#177) changes, the I2C mux channels of Baseboard and Switchboard CPLDs are moved from i2c-4 and i2c-5 to i2c-36 and i2c-37 respectively. - This caused QSFP driver initialization of i2c-36 to i2c-41 to fail causing the ports from Ethernet208 to Ethernet248 fail. #### How I did it - The fix to this problem is to change the order of QSFP driver initialization to I2C mux channels. - Instead of the order i2c-10 to i2c-41, the order i2c-4 to i2c-35 is being utilized. - Also, need to change the i2c-mux-channel number for Baseboard CPLD and switchboard CPLD in scripts to access them.
dal00
pushed a commit
to kamelnetworks/sonic-linux-kernel
that referenced
this pull request
Jul 20, 2025
…ic-net#177) Fixes: sonic-net/sonic-buildimage#20662 During some reboots, it was observed that some times featured.service script command fails to start the services like pmon, snmp, lldp etc. From logs, it was observed that 'sudo systemctl enable ' command failed with errorcode 13 (SIGPIPE. 2024 Oct 29 01:31:26.191236 aaa14-rp INFO featured: Running cmd: '['sudo', 'systemctl', 'unmask', 'pmon.service']' 2024 Oct 29 01:31:26.211167 aaa14-rp INFO systemd[1]: Reloading. 2024 Oct 29 01:31:27.212381 aaa14-rp INFO featured: Running cmd: '['sudo', 'systemctl', 'enable', 'pmon.service']' 2024 Oct 29 01:31:27.232428 aaa14-rp INFO systemd[1]: Reloading. 2024 Oct 29 01:31:28.135667 aaa14-rp ERR featured: ['sudo', 'systemctl', 'enable', 'pmon.service'] - failed: return code - -13, output:#012None 2024 Oct 29 01:31:28.135746 aaa14-rp ERR featured: Feature 'pmon.service' failed to be enabled and started 2024 Oct 29 01:34:08.661711 aaa14-rp INFO featured: Running cmd: '['sudo', 'systemctl', 'enable', 'gnmi.service']' 2024 Oct 29 01:34:08.677242 aaa14-rp INFO systemd[1]: Reloading. 2024 Oct 29 01:34:09.316554 aaa14-rp ERR featured: ['sudo', 'systemctl', 'enable', 'gnmi.service'] - failed: return code - -13, output:#012None 2024 Oct 29 01:34:09.316791 aaa14-rp ERR featured: Feature 'gnmi.service' failed to be enabled and started The issue does not recover and the pmon and other services never starts. On supervisor this also leads to swss, syncd and other related docker to stay down. In general systemctl enable does not work for some services like pmon, snmp, lldp etc as there is no WantBy directive set for these services in unit file. The command returns stderr : "The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified. ” featured python script uses subprocess.check_call() function to invoke the command which looks like is not very reliable at handling the stderr and may cause SIGPIPE with big buffer data. Modifying the function to use subprocess.run() resolves this issue. run() is more reliable at handing the return data. Validated the change with multiple reboots.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
f1fb64b04b: driver-i2c-mux-pca954x-allow-management-of-device-idle-stat.patch (v5.2-rc1)
ddd7c492d: i2c: mux: pca954x: remove support for unused platform data (v5.2-rc1)
tested on celestica dx010
Signed-off-by: Guohan Lu lguohan@gmail.com