In SONiC branch 201911 (Stretch), there is this patch which is applied:

packaging-update-abiname-to-11-2.patch

It changes the kernel ABI from 11 to 11-2

This has the side effect to disable the ABI check performed by the script
debian/bin/buildcheck.py

This is because the buildcheck.py script is looking to compare the file
debian/build/build_amd64_none_amd64/Module.symvers
(generated by the build)
with the file
debian/abi/4.9.0-11-2/amd64_none_amd64

But since the ABI has changed, the Debian file checked-in is still:
debian/abi/4.9.0-11/amd64_none_amd64

So buildcheck.py, not finding the file
debian/abi/4.9.0-11-2/amd64_none_amd64
just bails out, without error, and will not check the ABI change.

In SONiC latest master branch, based on Buster, there is no such patch to change the ABI.
The script buildcheck.py will then compare the file
debian/build/build_amd64_none_amd64/Module.symvers
with the file
debian/abi/4.19.0-6/amd64_none_amd64

so any ABI change will be effectively checked..

For example, the patch:
Support-for-fullcone-nat.patch
which apply fine with SONiC 201911 (Stretch) can not currently be applied in the master branch (Buster), because there is a change in a global kernel structure
(include/net/netfilter/nf_conntrack.h in this example).

I am wondering, what is the plan regarding the ABI in SONiC Buster, are we going to change it like this was done in SONiC Strech?

Without changing the kernel ABI, many patches might just fail because the ABI check...

Seeing log messages like the following in master branch builds:

Aug 26 17:10:02 sonic kernel: [   33.392571] max6620 11-002a: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().

This is the culprit line which needs to be updated to call hwmon_device_register_with_info() instead:

https://github.com/Azure/sonic-linux-kernel/blob/master/patch/driver-hwmon-max6620.patch#L627

Hi,

I read the README and I want to compile and add the patches to a SONiC Image that I'll build. I use the command make DEST=<destination path> and I obtain this error:
~/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118 ~/Desktop/SONiC_patch/sonic-linux-kernel Initialized empty Git repository in /home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/.git/ Checking for changes in the working directory ... done Importing patch "packaging-update-abiname.patch" ... done Now at patch "packaging-update-abiname.patch" W: Unable to get GNU type for arm64ilp32 W: Unable to get GNU type for mips64r6 Traceback (most recent call last): File "debian/bin/gencontrol.py", line 682, in <module> Gencontrol()() File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 109, in __call__ self.do_main(packages, makefile) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 130, in do_main self.do_main_recurse(packages, makefile, vars, makeflags, extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 152, in do_main_recurse makeflags.copy(), extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 214, in do_arch self.do_arch_recurse(packages, makefile, arch, vars, makeflags, extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 237, in do_arch_recurse vars.copy(), makeflags.copy(), extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 251, in do_featureset makeflags, extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 275, in do_featureset_recurse vars.copy(), makeflags.copy(), extra) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 286, in do_flavour vars, makeflags, extra) File "debian/bin/gencontrol.py", line 394, in do_flavour_packages or config_entry_relations.get(compiler), vars)) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 351, in substitute return re.sub(r'@([-_a-z0-9]+)@', subst, str(s)) File "/usr/lib/python3.5/re.py", line 182, in sub return _compile(pattern, flags).sub(repl, string, count) File "/home/diaccio/Desktop/SONiC_patch/sonic-linux-kernel/linux-4.19.118/debian/bin/debian_linux/gencontrol.py", line 349, in subst return vars[match.group(1)] KeyError: 'gnu-type-package' Makefile:57: recipe for target '/home/diaccio/Desktop/SONiC_patch/sonic-buildimage//linux-headers-4.19.0-9-2-common_4.19.118-2+deb10u1_all.deb' failed make: *** [/home/diaccio/Desktop/SONiC_patch/sonic-buildimage//linux-headers-4.19.0-9-2-common_4.19.118-2+deb10u1_all.deb] Error 1

Can you help me?

Code Path：drivers/misc/eeprom/optoe.c

Issue 1：The write_timeout value is fixed at 25ms. In the test of our products, it is found that the 25ms timeout time of some optical modules is not enough, and I2C read and write failures will occur occasionally.
Issue 2：When switch optoe’s dev_class from 2 to 1 then 1 to 3, clash occurs.

Regarding this issue, our solution is:

Issue1： It may be related to the module characteristics of different manufacturers.
At present, the write_timeout is changed to 50ms in our product, which runs well. Can this parameter be opened to users to set their own timeout time (the default is 25ms, the original logic remains unchanged)?
Issue2：below is the issue code：

	if (optoe->client[1])
		i2c_unregister_device(optoe->client[1]);
	optoe->bin.size = ONE_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 1;

After run the i2c_unregister_device(optoe->client[1]), optoe->client[1] is needed to set to null.If it is not set to null, clash will occur when switch again. Below is the repaired code.

	if (optoe->client[1]) {
		i2c_unregister_device(optoe->client[1]);
		optoe->client[1] = NULL;
}
	optoe->bin.size = ONE_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 1;

Currently, there does not seem to be a policy to upstream the Linux patches, adding maintenance burden.

1. Forward porting these patches takes a lot of effort, which – once upstream – the Linux community would take care of.
2. Work with other network operating systems, like Open Network Linux, which also has no upstreaming policy, is duplicated.
3. The original patch authors are often gone after a while.

OpenBMC has a Development Process, I recommend to adapt.

Upstream is key

In order to leverage the benefits of using the Linux kernel, OpenBMC maintains a policy that all kernel code will be merged upstream.

However, there are often cases where product requirements mean that synchronising with an upstream schedule is not always possible. This process aims to allow both goals (upstream inclusion and a useful OpenBMC build) to occur in parallel.

Description

When unload the psample module will see kernel oops:

[  215.393327] BUG: unable to handle kernel paging request at ffffffffc0c8f070
[  215.400438] IP: [<ffffffffa1b54823>] list_del+0x13/0x30
[  215.405750] PGD 17c0d067 
[  215.408229] PUD 17c0f067 
[  215.410917] PMD 1cc0d2067 
[  215.412173] PTE 80000001bd442061

[  215.417001] Oops: 0003 [#1] SMP
[  215.420191] Modules linked in: psample(-) dummy team_mode_loadbalance team sx_bfd(O) sx_core(O) 8021q garp mrp mst_pciconf(O) mst_pci(O) xt_hl iptable_mangle xt_TCPMSS xt_tcpudp ip6table_mangle nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_conntrack nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo mlxsw_minimal mlxsw_i2c intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm mlx_wdt i2c_mux_reg i2c_mux mlxreg_hotplug mlxreg_io i2c_mlxcpld leds_mlxreg iTCO_wdt iTCO_vendor_support gpio_ich evdev mlx_platform irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf bonding pcspkr mei_me mei sg lpc_ich mfd_core shpchp video button iptable_filter ebt_vlan iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
[  215.492886]  ebtable_broute bridge stp llc ebtable_nat ebtable_filter ebtables xdpe12284 at24 nvmem_core ledtrig_timer tmp102 lm75 coretemp max1363 industrialio_triggered_buffer kfifo_buf industrialio tps53679 pmbus pmbus_core i2c_dev ip_tables x_tables autofs4 loop ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache nls_utf8 nls_cp437 nls_ascii vfat fat overlay squashfs sd_mod mlxsw_core devlink crc32c_intel ahci libahci i2c_i801 i2c_smbus libata scsi_mod ehci_pci ehci_hcd e1000e usbcore ptp usb_common pps_core fan thermal
[  215.544747] CPU: 0 PID: 7778 Comm: modprobe Tainted: G           O    4.9.0-11-2-amd64 Azure/sonic-buildimage#1 Debian 4.9.189-3+deb9u2
[  215.555137] Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018
[  215.563764] task: ffff8be98d220dc0 task.stack: ffffb7eb8176c000
[  215.569809] RIP: 0010:[<ffffffffa1b54823>]  [<ffffffffa1b54823>] list_del+0x13/0x30
[  215.577586] RSP: 0018:ffffb7eb8176fe58  EFLAGS: 00010246
[  215.582938] RAX: dead000000000100 RBX: ffffffffc0c8f070 RCX: dead000000000200
[  215.590157] RDX: ffffffffa272cb90 RSI: 0000000000000246 RDI: ffffffffc0c8f070
[  215.597387] RBP: ffffffffc0c8f000 R08: ffffffffc0c8f070 R09: 0000000000000000
[  215.604632] R10: 0000000000000014 R11: ffffffffa24e1b40 R12: ffffffffa24ddbe8
[  215.611878] R13: ffffffffc0c8f070 R14: 0000000000000000 R15: ffffffffa272cb90
[  215.619176] FS:  00007f8cc90924c0(0000) GS:ffff8be9ddc00000(0000) knlGS:0000000000000000
[  215.627378] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  215.633205] CR2: ffffffffc0c8f070 CR3: 000000021228a000 CR4: 0000000000160670
[  215.640426] Stack:
[  215.642451]  0000000000000002 ffffffffa1d4bca3 ffffffffc0c8f008 ffff8be96bf006d8
[  215.650032]  ffff8be9d3e85e60 ffffffffa1a089ba 000055f51e80f4f8 ffffb7eb8176fed8
[  215.657582]  eb32c7101f06fbab ffffffffc0c90080 0000000000000000 0000000000000800
[  215.665210] Call Trace:
[  215.667721]  [<ffffffffa1d4bca3>] ? genl_unregister_family+0x133/0x220
[  215.674367]  [<ffffffffa1a089ba>] ? __check_object_size+0xfa/0x1d8
[  215.680617]  [<ffffffffa19031df>] ? SyS_delete_module+0x18f/0x270
[  215.686787]  [<ffffffffa1803b7d>] ? do_syscall_64+0x8d/0x100
[  215.692523]  [<ffffffffa1e1d48e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[  215.699591] Code: 48 c7 c2 c0 9f 22 a2 be 3e 00 00 00 48 c7 c7 50 9e 22 a2 e9 a0 64 d2 ff 53 48 89 fb e8 47 ff ff ff 48 b8 00 01 00 00 00 00 ad de <48> 89 03 48 b8 00 02 00 00 00 00 ad de 48 89 43 08 5b c3 66 2e 
[  215.720026] RIP  [<ffffffffa1b54823>] list_del+0x13/0x30
[  215.725445]  RSP <ffffb7eb8176fe58>
[  215.729007] CR2: ffffffffc0c8f070
[  215.732352] ---[ end trace 12e9c23cd91ba53e ]---

Steps to reproduce the issue:
This issue was observed in "config reload" process when integrating a new SDK version, managed to narrow down and can be reproduced only with two simple steps:

1. load psample module by "modprobe psample "
2. unload psample module by "modprobe -r psample"

Describe the results you received:

kernel oops make the deinit process not fully successful.

Describe the results you expected:

deinit should be successful

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
SONiC Software Version: SONiC.201911.135-251dc0a2
Distribution: Debian 9.12
Kernel: 4.9.0-11-2-amd64
Build commit: 251dc0a2
Build date: Sat Jul 11 05:03:00 UTC 2020
Built by: johnar@jenkins-worker-7

Platform: x86_64-mlnx_msn2410-r0
HwSKU: ACS-MSN2410
ASIC: mellanox
Serial Number: MT1848K10624
Uptime: 10:48:12 up 5 min,  1 user,  load average: 0.89, 1.63, 0.93

Docker images:
REPOSITORY                    TAG                   IMAGE ID            SIZE
docker-syncd-mlnx             201911.135-251dc0a2   2536338a22f0        388MB
docker-syncd-mlnx             latest                2536338a22f0        388MB
docker-platform-monitor       201911.135-251dc0a2   36f0573d4490        652MB
docker-platform-monitor       latest                36f0573d4490        652MB
docker-router-advertiser      201911.135-251dc0a2   300c6b4e2208        288MB
docker-router-advertiser      latest                300c6b4e2208        288MB
docker-fpm-frr                201911.135-251dc0a2   a40ef0aa6783        332MB
docker-fpm-frr                latest                a40ef0aa6783        332MB
docker-sflow                  201911.135-251dc0a2   4f58b0d23b38        312MB
docker-sflow                  latest                4f58b0d23b38        312MB
docker-lldp-sv2               201911.135-251dc0a2   13c6649661e1        309MB
docker-lldp-sv2               latest                13c6649661e1        309MB
docker-orchagent              201911.135-251dc0a2   956819392826        330MB
docker-orchagent              latest                956819392826        330MB
docker-dhcp-relay             201911.135-251dc0a2   3aa2b097d186        298MB
docker-dhcp-relay             latest                3aa2b097d186        298MB
docker-database               201911.135-251dc0a2   306492150dba        288MB
docker-database               latest                306492150dba        288MB
docker-snmp-sv2               201911.135-251dc0a2   3c179076818f        346MB
docker-snmp-sv2               latest                3c179076818f        346MB
docker-teamd                  201911.135-251dc0a2   47f74ff56dea        312MB
docker-teamd                  latest                47f74ff56dea        312MB
docker-nat                    201911.135-251dc0a2   9a8cdc01a91f        313MB
docker-nat                    latest                9a8cdc01a91f        313MB
docker-sonic-mgmt-framework   201911.135-251dc0a2   66831bdce069        426MB
docker-sonic-mgmt-framework   latest                66831bdce069        426MB
docker-sonic-telemetry        201911.135-251dc0a2   c565a0343fc1        351MB
docker-sonic-telemetry        latest                c565a0343fc1        351MB
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

Code Path：drivers/i2c/busses/i2c-i801.c

Issue 1：“SMBus is busy, can't use it!”Error happens sometimes. The I2C controller cannot be used.
Issue 2：An occasional I2C deadlock (SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.

Regarding this issue, our solution is:

Issue1：The cause of SMBus Busy is unknown. At present, we have added controller reset logic. When SMBus Busy occurs, the controller is reset, so that the I2C controller can be recovered after a fault occurs.
Issue2： The cause of I2C deadlock is unknown. Now, we have added the I2C nine clocks function. Before I2C transmission, the driver checks whether I2C deadlock occurs (SCL is high voltage level and SDA is low voltage level). If the I2C deadlock occurs, nine clocks are sent to unlock the device

Description

Steps to reproduce the issue:

1. continously config reload

Describe the results you received:

kernel stucked. you can still log from the console.

vlab-01 login:
vlab-01 login:
vlab-01 login:
vlab-01 login: [ 1261.465454] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[ 1811.065939] e1000 0000:02:12.0 eth16: Reset adapter
[ 1813.205187] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[ 2127.229756] e1000 0000:02:0f.0 eth13: Reset adapter
[ 2129.673287] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[ 2207.491968] PortChannel0004: Device Ethernet124 is up. Set it down before adding it as a team port

vlab-01 login: [18280.813411] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[18915.186137] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[19155.297452] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[19394.338225] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[19394.380455] PortChannel0004: Device Ethernet124 is up. Set it down before adding it as a team port
[19470.419520] PortChannel0001: Device Ethernet112 is up. Set it down before adding it as a team port
[19470.643857] PortChannel0004: Device Ethernet124 is up. Set it down before adding it as a team port
[19547.001116] e1000 0000:02:19.0 eth23: Reset adapter
[19706.591864] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[20187.075118] PortChannel0004: Device Ethernet124 is up. Set it down before adding it as a team port
[20589.514165] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[22526.077148] e1000 0000:02:0b.0 eth9: Reset adapter
[22687.097126] e1000 0000:02:0e.0 eth12: Reset adapter
[22771.521558] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[22846.073136] e1000 0000:02:0e.0 eth12: Reset adapter
[22930.530431] PortChannel0003: Device Ethernet120 is up. Set it down before adding it as a team port
[23412.366324] PortChannel0001: Device Ethernet112 is up. Set it down before adding it as a team port
[23567.993260] e1000 0000:02:16.0 eth20: Reset adapter
[24041.081098] e1000 0000:02:0a.0 eth8: Reset adapter
[24288.377534] INFO: task kworker/1:2:10762 blocked for more than 120 seconds.
[24288.383459]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.389095] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.394017] INFO: task kworker/3:1:1370 blocked for more than 120 seconds.
[24288.399291]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.405690] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.410757] INFO: task ntpd:26512 blocked for more than 120 seconds.
[24288.415654]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.419810] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.425214] INFO: task zebra:27720 blocked for more than 120 seconds.
[24288.429796]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.435472] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.439890] INFO: task teamd:27834 blocked for more than 120 seconds.
[24288.443307]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.450309] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.454892] INFO: task teamd:27873 blocked for more than 120 seconds.
[24288.460026]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.463968] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.470292] INFO: task teamd:27889 blocked for more than 120 seconds.
[24288.474081]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.479245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.486232] INFO: task teamd:27898 blocked for more than 120 seconds.
[24288.489960]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.498110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.504240] INFO: task lldpd:27968 blocked for more than 120 seconds.
[24288.507446]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.511638] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24288.517896] INFO: task teamsyncd:27971 blocked for more than 120 seconds.
[24288.521647]       Tainted: G        W   E     4.19.0-6-amd64 Azure/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[24288.529090] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

We recently encountered some kernel driver issues on M2-W6510-48V8C:

1. Problems encountered by optoe drivers
   Code Path：drivers/misc/eeprom/optoe.c
   Issue 1：The write_timeout value is fixed at 25ms. In the test of our products, it is found that the 25ms timeout time of some optical modules is not enough, and I2C read and write failures will occur occasionally.
   Issue 2：When switch optoe’s dev_class from 2 to 1 then 1 to 3, clash occurs.

2. Problems encountered by tmp401 drivers
   Code Path：drivers/hwmon/tmp401.c
   Issue：We used the TMP411 temperature sensor chip, which occasionally read the Issue of abnormal temperature values (255.2℃).

3. Problems encountered by i2c-i801 drivers
   Code Path：drivers/i2c/busses/i2c-i801.c
   Issue 1：“SMBus is busy, can't use it!”Error happens sometimes. The I2C controller cannot be used.
   Issue 2：An occasional I2C deadlock (SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.

4. Problems encountered by i2c-ismt drivers
   Code Path：drivers/i2c/busses/i2c-ismt.c
   Issue：An occasional I2C deadlock(SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.

5. Problems encountered by i2c-gpio drivers
   Code Path：drivers/i2c/algos/i2c-algo-bit.c
   Issue 1：An occasional I2C deadlock (SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.
   Issue 2：Insert a faulty optical module with SDA and GND short-circuited， the I2C GPIO controller cannot identify the exception, and all the data read is 0 (The access is successful from the I2C protocol)

6. Problems encountered by i2c-mux-pca954x drivers
   Code Path：drivers/i2c/muxes/i2c-mux-pca954x.c
   Issue 1：After accessing the peripherals under PCA9548, the PCA9548 channel is not closed. One I2C controller of our product is connected to multiple PCA9548s, and each PCA9548 channel is connected to an optical module (address is 0x50). After accessing the device under PCA9548, the channel is not closed, and I2C address conflicts will occur, resulting in access exceptions.
   Issue 2：After connecting the faulty optical module with SCL and GND short-circuited, and then opening the PCA9548 channel where the optical module is located. SCL is pulled to a low voltage level, causing the entire I2C controller to not work properly, and all I2C peripherals under the entire controller to be inaccessible and cannot be recovered (the fault scope has expanded)

Below are our solutions to reslove above issues：

1. Problems encountered by optoe drivers
   Issue1： It may be related to the module characteristics of different manufacturers.
   At present, the write_timeout is changed to 50ms in our product, which runs well. Can this parameter be opened to users to set their own timeout time (the default is 25ms, the original logic remains unchanged)?
   Issue2：below is the issue code：

	if (optoe->client[1])
		i2c_unregister_device(optoe->client[1]);
	optoe->bin.size = ONE_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 1;

After run the i2c_unregister_device(optoe->client[1]), optoe->client[1] is needed to set to null.If it is not set to null, clash will occur when switch again. Below is the repaired code.

	if (optoe->client[1]) {
		i2c_unregister_device(optoe->client[1]);
		optoe->client[1] = NULL;
}
	optoe->bin.size = ONE_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 1;

2. Problems encountered by tmp401 drivers
   Issue reason：The TMP411 temperature reading exception is caused by the timeout mechanism of TMP411.
   The following content is excerpted from the TMP411 data sheet

TIMEOUT FUNCTION
When bit 7 of the Consecutive Alert Register is set high,the TMP411 timeout function is enabled. The TMP411resets the serial interface if either SCL or SDA are held lowfor 30ms (typical) between a START and STOP condition.If the TMP411 is holding the bus low, it releases the busand waits for a START condition. To avoid activating thetimeout function, it is necessary to maintain acommunication speed of at least 1kHz for the SCLoperating frequency. The default state of the timeoutfunction is enabled (bit 7 = high).

At present, this issue can be resolved by modifying the driver and disabling the timeout mechanism of TMP411 when driving probe.

3. Problems encountered by i2c-i801 drivers
   Issue1：The cause of SMBus Busy is unknown. At present, we have added controller reset logic. When SMBus Busy occurs, the controller is reset, so that the I2C controller can be recovered after a fault occurs.
   Issue2： The cause of I2C deadlock is unknown. Now, we have added the I2C nine clocks function. Before I2C transmission, the driver checks whether I2C deadlock occurs (SCL is high voltage level and SDA is low voltage level). If the I2C deadlock occurs, nine clocks are sent to unlock the device

4. Problems encountered by i2c-ismt drivers
   Code Path：drivers/i2c/busses/i2c-ismt.c
   Issue：The solution is the same as the i2c-i801 driver, which also imports 9 clock unlock functions

5. Problems encountered by i2c-gpio drivers
   Code Path：drivers/i2c/algos/i2c-algo-bit.c
   Issue1：The solution is the same as the i2c-i801 driver, which also imports 9 clock unlock functions
   Issue2：Add I2C-GPIO voltage level detection to determine SCL and SDA voltage levels before I2C begins transmission. If the SCL and SDA voltage levels are not high at the same time, a failure is returned.

6. Problems encountered by i2c-mux-pca954x drivers
   Code Path：drivers/i2c/muxes/i2c-mux-pca954x.c
   Issue1：By default, idle_state is MUX_IDLE_AS_IS (that is, after accessing the devices under PCA9548, maintaining the original state without closing the channels). The default idle_state can only be changed by using the device tree, and X86 products do not support device trees. At present, we decided to directly modify the driver code and change the default idle_state status to MUX_IDLE_DISCONNECT
   Issue2：Add the PCA9548 reset logic to the PCA9548 closed channel logic. If the PCA9548 channel fails to be closed, perform a PCA9548 reset (after the PCA9548 reset, all channels are closed) to isolate the faulty device.

Are there any better solutions or suggestions from the kernel community regarding these issues? Thanks.

ubuntu 16.04

Can't exec "/home/dingrui/projects/sonic-linux-kernel/linux-4.9.168/debian/linux-cpupower.install": No such file or directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 776.
dh_install: cannot run debian/linux-cpupower.install: No such file or directory
make[3]: *** [install-source] Error 2
make[2]: *** [binary-indep] Error 2
make[1]: *** [binary-indep] Error 2
make: *** [/linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u5_all.deb] Error 2

See https://github.com/Azure/sonic-linux-kernel/blob/8eee9d8f7ba51fde40b8ae0dd3fab99c935a3d98/Makefile#L28 for example

LINUX_IMAGE_URL resolves to
https://sonicstorage.blob.core.windows.net/packages/kernel-public/linux-image-4.19.0-9-2-amd64_4.19.118-2+deb10u1_amd64.deb?sv=2015-04-05&sr=b&sig=oRGGO9xJ6jmF31KGy%2BwoqEYMuTfCDcfILKIJbbaRFkU%3D&se=2128-12-23T19%3A06%3A47Z&sp=r
in the build time.

I get 403 Server failed to authenticate the request. Make sure the value of Autho rization header is formed correctly including the signature. error message from wget.

If I try to download the file from the browser, the result is the same 403.

Please make these links work as rebuilding the kernel from sources is a very time-consuming process and I'd like to just download it.

Are there any plans to move to Linux 6.1? I guess, when SONiC moves the Debian “base image” to bookworm, which is currently testing?

Code Path：drivers/i2c/muxes/i2c-mux-pca954x.c

Issue 1：After accessing the peripherals under PCA9548, the PCA9548 channel is not closed. One I2C controller of our product is connected to multiple PCA9548s, and each PCA9548 channel is connected to an optical module (address is 0x50). After accessing the device under PCA9548, the channel is not closed, and I2C address conflicts will occur, resulting in access exceptions.
Issue 2：After connecting the faulty optical module with SCL and GND short-circuited, and then opening the PCA9548 channel where the optical module is located. SCL is pulled to a low voltage level, causing the entire I2C controller to not work properly, and all I2C peripherals under the entire controller to be inaccessible and cannot be recovered (the fault scope has expanded)

Regarding this issue, our solution is:

Issue1：By default, idle_state is MUX_IDLE_AS_IS (that is, after accessing the devices under PCA9548, maintaining the original state without closing the channels). The default idle_state can only be changed by using the device tree, and X86 products do not support device trees. At present, we decided to directly modify the driver code and change the default idle_state status to MUX_IDLE_DISCONNECT
Issue2：Add the PCA9548 reset logic to the PCA9548 closed channel logic. If the PCA9548 channel fails to be closed, perform a PCA9548 reset (after the PCA9548 reset, all channels are closed) to isolate the faulty device.

Hi Team,
We are trying to run/execute SONiC community defined T1-topology test-suite using '202305 Release build' on platform 'Accton-AS7716-32X'.
On every attempt of our test-run, we are facing 'CPU Stall Issue' randomly, wherein noticed that Kernel-threads are getting into Hung state (randomly) and NMI watch-dog timer is getting triggered, which results in board restart.

We are observing the same issue in 202311 & 'master' branch release builds (generated from Community Azure pipeline) i.e. CPU stall issue is seen with SONiC NOS builds having Bullseye/5.10-Kernel version (i.e. 202311) & Bookworm/6.1-kernel version (i.e. master), as well.

We consulted Accton team and shared our observations, they confirmed that it is not a hardware issue and need to be checked further from Community NOS. We have made some initial analysis based on the received logs and reported issue in Community GITHub link (currently unable to proceed further & conclude/resolve the issue).

Request your expert advice in this regard to solve this issue and provide any suggestions in this regard.

GITHub Issue Links for CPU Stall Issues:
1. CPU Stall: Soft Lockup issue observed in 202305 Release Branch [Kernel: 5.10.140-1] [Accton-AS7716-32X]
sonic-net/sonic-buildimage#17358

2. CPU Stall: Hard Lockup issue observed in 202305 Release Branch [Kernel: 5.10.140-1] [Accton-AS7716-32X]
sonic-net/sonic-buildimage#17361
sonic-net/sonic-buildimage#17363

Some Observations:
- These CPU Stall issues are seen RANDOMLY, while executing community test-suite.
- These CPU Stall issues are predominantly seen while executing 'T1-topology cases' and not with T0-topology cases.
- These CPU Stall issues are seen only when test cases are executed in a batch. If the same test-case is executed individually, then such issues are not seen.

During compilation config-mlnx-sn2700.patch patch fails:

Checking for changes in the working directory ... done
Importing patch "config-dell-s6000.patch" ... done
Importing patch "config-mlnx-sn2700.patch" ... error: patch failed: debian/build/build_amd64_none_amd64/.config:3492
error: debian/build/build_amd64_none_amd64/.config: patch does not apply
stg import: Diff does not apply cleanly

Code Path：drivers/i2c/busses/i2c-ismt.c

Issue：An occasional I2C deadlock(SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.

Regarding this issue, our solution is:

The solution is the same as the i2c-i801 driver, which also imports 9 clock unlock functions

Flow:
Modifying a kernel flag of string type (flag example below) in the filename: sonic-linux-kernel/patch/kconfig-inclusions.
the expectation is that after the kernel build we should found a kernel .config file including this modification, but its not happened.
The kernel flag in the /linux-5.10.46/debian/build/build_amd64_none_amd64/.config remained like was at before the modification in the kconfig-inclusions.

kernel flag example:
CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/new_cert.key

How to repro:
tested on branch: master

1. add a line in kconfig-inclusions file with the kernel flag, i.e

CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/new_cert.key

2. make the kernel
3. read the kernel .config file created in /linux-5.10.46/debian/build/build_amd64_none_amd64/.config
4. check the value of the keyname CONFIG_SYSTEM_TRUSTED_KEYS.

Note:
I think the problem is happening just with kernel flags that contain some string default values, like in this case:
CONFIG_SYSTEM_TRUSTED_KEYS have a default value of "debian/certs/debian-uefi-certs.pem

**Description

Steps to reproduce the issue:**

1. set dev_class to SFP family firstly
2. set dev_class to QSFP or CMIS family twice

Log as follow:
root@localhost:/sys/bus/i2c/devices/69-0050# echo 2 > dev_class
root@localhost:/sys/bus/i2c/devices/69-0050#
root@localhost:/sys/bus/i2c/devices/69-0050#
root@localhost:/sys/bus/i2c/devices/69-0050#
root@localhost:/sys/bus/i2c/devices/69-0050# echo 3 > dev_class
root@localhost:/sys/bus/i2c/devices/69-0050# echo 3 > dev_class
[499859.513979] general protection fault: 0000 [#1] SMP
[499859.573455] Modules linked in: linux_bcm_knet(PO) linux_user_bde(PO) linux_kernel_bde(PO) dummy ip6table_filter ip6_tables firmware_gpio_driver(O) lpc_dbg(O) optoe rg_cpld(O) at24 nvmem_core rg_gpio_xeon(O) nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo i2c_gpio fpga_pcie_drv(O) fpga_i2c_ocores(O) ruijie_common(O) i2c_mux_pca954x(O) i2c_mux_pca9641(O) i2c_mux i2c_dev 8021q garp mrp ixgbe(O) linux_uk_proxy(PO) intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel igb(O) kvm ptp pps_core i2c_algo_bit r8168(O) cdc_ether cdc_subset irqbypass crct10dif_pclmul usbnet mii crc32_pclmul bonding ghash_clmulni_intel iTCO_wdt gpio_ich iTCO_vendor_support mxm_wmi intel_cstate evdev intel_uncore pcspkr intel_rapl_perf efi_pstore mei_me mei efivars lpc_ich mfd_core sg ipmi_si[499860.424548] wmi ipmi_msghandler acpi_pad ioatdma dca shpchp button xt_conntrack ebtable_broute bridge iptable_filter stp llc ipt_MASQUERADE nf_nat_masquerade_ipv4 ebtable_nat xt_addrtype ebtable_filter ebtables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack efivarfs ip_tables x_tables autofs4 loop ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache nls_utf8 nls_cp437 nls_ascii vfat fat overlay squashfs sd_mod crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd i2c_i801(O) scsi_mod i2c_smbus usbcore usb_common [last unloaded: linux_kernel_bde]
[499861.127424] CPU: 4 PID: 11454 Comm: bash Tainted: P IO 4.9.0-14-2-amd64 #1 Debian 4.9.246-2
[499861.241063] Hardware name: Default string Default string/Default string, BIOS 5.14(3CNHU008) 09/21/2020
[499861.354702] task: ffff924ed68cd100 task.stack: ffffbbdf02330000
[499861.426676] RIP: 0010:[] [] device_del+0x31/0x260
[499861.522714] RSP: 0018:ffffbbdf02333e10 EFLAGS: 00010206
[499861.587402] RAX: 75643a6332693d53 RBX: ffff924f1c644420 RCX: 0000000000000000
[499861.673960] RDX: 0000000080000000 RSI: 000000000000000a RDI: ffff924f1c644420
[499861.760517] RBP: ffff924f1c644420 R08: 0000000000000003 R09: 0000000000000001
[499861.847075] R10: 000000000000000a R11: f000000000000000 R12: 0000000000000000
[499861.933633] R13: ffff924e60980c48 R14: ffffbbdf02333f08 R15: ffff924f87732918
[499862.020196] FS: 00007f671b131700(0000) GS:ffff924fbfd00000(0000) knlGS:0000000000000000
[499862.118212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[499862.188107] CR2: 000055d8f11b5d60 CR3: 0000000054aee000 CR4: 0000000000360670
[499862.274665] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[499862.361224] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[499862.447785] Stack:
[499862.472889] ffff924f22e88c20 ffffffffa3752362 d86cff62dd2c6236 ffff924f1c644420
[499862.562984] ffff924f22e88c20 0000000000000002 ffff924e60980c48 ffffffffa3882fe6
[499862.653084] ffff924e60980c00 ffffffffc07d40ec 0000000300000000 d86cff62dd2c6236
[499862.743183] Call Trace:
[499862.773499] [] ? kstrtoll+0x32/0x90
[499862.836104] [] ? device_unregister+0x16/0x60
[499862.908086] [] ? set_dev_class+0x7c/0x140 [optoe]
[499862.985274] [] ? kernfs_fop_write+0x107/0x180
[499863.058296] [] ? vfs_write+0xb0/0x190
[499863.122979] [] ? SyS_write+0x5a/0xd0
[499863.186622] [] ? do_syscall_64+0x8d/0x100
[499863.255473] [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[499863.339950] Code: 55 41 54 55 53 48 89 fd 48 83 ec 18 4c 8b 27 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 48 8b 87 88 00 00 00 48 85 c0 74 1b <48> 8b b8 90 00 00 00 48 89 ea be 02 00 00 00 48 81 c7 f8 00 00
[499863.572956] RIP [] device_del+0x31/0x260
[499863.640870] RSP
[499863.683752] ---[ end trace 97ac2df35d8da511 ]---
[499864.263748] Kernel panic - not syncing: Fatal exception
[499864.327402] Kernel Offset: 0x22400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[499864.502574] Rebooting in 10 seconds..

The reason is that the optoe does not set the client[1] pointer to NULL while setting dev_class to QSFP or CMIS family. During the second time setting dev_class to QSFP or CMIS family, it will try to unregister client[1] (which is already unregistered) again. The dev of client[1] is NULL now, hence the kernel panic occurred

The solution is to set client[1] to NULL after unregistation

Code is shown as following
`

mutex_lock(&optoe->lock);
if (dev_class == TWO_ADDR) {
	/* SFP family */
	/* if it doesn't exist, create 0x51 i2c address */
	if (!optoe->client[1]) {
		optoe->client[1] = i2c_new_dummy(client->adapter, 0x51);
		if (!optoe->client[1]) {
			dev_err(&client->dev,
				"address 0x51 unavailable\n");
			mutex_unlock(&optoe->lock);
			return -EADDRINUSE;
		}
	}
	optoe->bin.size = TWO_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 2;
} else {
	/* one-address (eg QSFP) and CMIS family */
	/* if it exists, remove 0x51 i2c address */
	if (optoe->client[1])
		i2c_unregister_device(optoe->client[1]);
	optoe->bin.size = ONE_ADDR_EEPROM_SIZE;
	optoe->num_addresses = 1;
}
optoe->dev_class = dev_class;
mutex_unlock(&optoe->lock);


`

Hi,

Made this on the github repo named SONiC, would it be possible to add a license.md to this repo?

sonic-net/SONiC#5 (comment)

Code Path：drivers/hwmon/tmp401.c

Issue：We used the TMP411 temperature sensor chip, which occasionally read the Issue of abnormal temperature values (255.2℃).

Regarding this issue, our solution is:

Issue reason：The TMP411 temperature reading exception is caused by the timeout mechanism of TMP411.
The following content is excerpted from the TMP411 data sheet

TIMEOUT FUNCTION
When bit 7 of the Consecutive Alert Register is set high,the TMP411 timeout function is enabled. The TMP411resets the serial interface if either SCL or SDA are held lowfor 30ms (typical) between a START and STOP condition.If the TMP411 is holding the bus low, it releases the busand waits for a START condition. To avoid activating thetimeout function, it is necessary to maintain acommunication speed of at least 1kHz for the SCLoperating frequency. The default state of the timeoutfunction is enabled (bit 7 = high).

At present, this issue can be resolved by modifying the driver and disabling the timeout mechanism of TMP411 when driving probe.

Code Path：drivers/i2c/algos/i2c-algo-bit.c

Issue 1：An occasional I2C deadlock (SCL is high voltage level and SDA is low voltage level) cannot be recovered, making the I2C controller unusable.
Issue 2：Insert a faulty optical module with SDA and GND short-circuited， the I2C GPIO controller cannot identify the exception, and all the data read is 0 (The access is successful from the I2C protocol)

Regarding this issue, our solution is:

Issue1：The solution is the same as the i2c-i801 driver, which also imports 9 clock unlock functions
Issue2：Add I2C-GPIO voltage level detection to determine SCL and SDA voltage levels before I2C begins transmission. If the SCL and SDA voltage levels are not high at the same time, a failure is returned.

Description

Steps to reproduce the issue:

1. Install master.339 image to DUT
2. sudo reboot

Describe the results you received:
+----------------------------------------------------------------------------+
| SONiC-OS-201911.0-7d436b33 |
|*SONiC-OS-master.339-31baf381 |
| ONIE |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------------------------------+

  Use the ^ and v keys to select which entry is highlighted.
  Press enter to boot the selected OS, `e' to edit the commands
  before booting or `c' for a command-line.

Loading SONiC-OS OS kernel ...
Loading SONiC-OS OS initial ramdisk ...
[ 5.956688] pstore: crypto_comp_decompress failed, ret = -22!
[ 6.025465] pstore: decompression failed: -22
[ 8.015487] rc.local[338]: + sonic-cfggen -y /etc/sonic/sonic_version.yml -v build_version
[ 9.456310] kdump-tools[355]: Starting kdump-tools: no crashkernel= parameter in the kernel cmdline ... failed!
[ 10.882070] kvm: disabled by bios
[ 10.975780] kvm: disabled by bios
[ 11.052886] kvm: disabled by bios
[ 11.211011] kvm: disabled by bios
[ 13.274025] rc.local[338]: + SONIC_VERSION=master.339-31baf381
[ 13.352848] rc.local[338]: + FIRST_BOOT_FILE=/host/image-master.339-31baf381/platform/firsttime
[ 13.475293] rc.local[338]: + logger SONiC version master.339-31baf381 starting up...
[ 13.580693] rc.local[338]: + [ ! -e /host/machine.conf ]
[ 13.661107] rc.local[338]: + . /host/machine.conf
[ 13.720928] rc.local[338]: + onie_version=3.20.1.5
[ 13.780935] rc.local[338]: + onie_vendor_id=674
[ 13.842340] rc.local[338]: + onie_platform=x86_64-dell_s6000_s1220-r0
[ 13.928766] rc.local[338]: + onie_machine=dell_s6000_s1220
[ 14.000666] rc.local[338]: + onie_machine_rev=0
[ 14.061165] rc.local[338]: + onie_arch=x86_64
[ 14.124761] rc.local[338]: + onie_config_version=1
[ 14.188694] rc.local[338]: + onie_build_date=2016-02-09T17:14-0800
[ 14.268655] rc.local[338]: + onie_partition_type=gpt
[ 14.341208] rc.local[338]: + onie_kernel_version=3.15.10
[ 14.412676] rc.local[338]: + onie_firmware=auto
[ 14.472687] rc.local[338]: + program_console_speed
[ 14.536373] rc.local[338]: + cat /proc/cmdline
[ 14.606010] rc.local[338]: + cut -d , -f2
[ 14.665629] rc.local[338]: + grep -Eo console=ttyS[0-9]+,[0-9]+
[ 14.750144] rc.local[338]: + speed=9600
[ 14.805031] rc.local[338]: + [ -z 9600 ]
[ 14.860756] rc.local[338]: + CONSOLE_SPEED=9600
[ 14.920880] rc.local[338]: + sed -i s|--keep-baud .* %I| 9600 %I|g /lib/systemd/system/[email protected]
[ 15.048694] rc.local[338]: + systemctl daemon-reload
[ 15.120727] rc.local[338]: + [ -f /host/image-master.339-31baf381/platform/firsttime ]
[ 15.224707] rc.local[338]: + [ -f /var/log/fsck.log.gz ]
[ 15.312109] rc.local[338]: + logger -t FSCK
[ 15.373750] rc.local[338]: + gunzip -d -c /var/log/fsck.log.gz
[ 15.449362] rc.local[338]: + rm -f /var/log/fsck.log.gz
[ 15.520799] rc.local[338]: + exit 0

Debian GNU/Linux 10 str-s6000-acs-8 ttyS0

[ 33.176426] list_add corruption. prev->next should be next (ffff97342e094110), but was ffff97342e094118. (prev=ffff97342e094118).
[ 33.316220] kernel BUG at lib/list_debug.c:28!
[ 33.369561] invalid opcode: 0000 [#1] SMP NOPTI
[ 33.423853] CPU: 1 PID: 770 Comm: set-fan-speed Tainted: G OE 4.19.0-6-2-amd64 sonic-net/sonic-buildimage#1 Debian 4.19.67-2+deb10u2
[ 33.554057] Hardware name: Dell Inc S6000-ACS/S6000 CPU, BIOS 4.6.5 10/12/2015
[ 33.640599] RIP: 0010:__list_add_valid.cold.0+0x26/0x28
[ 33.703201] Code: 00 00 00 c3 48 89 d1 48 c7 c7 b8 b1 09 b2 48 89 c2 e8 c0 96 d0 ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 10 b2 09 b2 e8 ac 96 d0 ff <0f> 0b 48 89 fe 48 89 c2 48 c7 c7 a0 b2 09 b2 e8 98 96 d0 ff 0f 0b
[ 33.928045] RSP: 0000:ffffb94a41307db0 EFLAGS: 00010246
[ 33.990645] RAX: 0000000000000075 RBX: ffffb94a41307e00 RCX: 0000000000000000
[ 34.076131] RDX: 0000000000000000 RSI: ffff973437a966b8 RDI: ffff973437a966b8
[ 34.161503] RBP: ffff97342e094110 R08: 0000000000000339 R09: 0000000000000004
[ 34.246887] R10: 000000000000072e R11: ffffffffb27f26ad R12: ffff97342e094118
[ 34.332270] R13: ffff97342e094100 R14: ffffb94a41307f08 R15: ffff97342e094100
[ 34.417657] FS: 00007fa40d4dc740(0000) GS:ffff973437a80000(0000) knlGS:0000000000000000
[ 34.514481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 34.583222] CR2: 00007f52592af024 CR3: 000000022e194000 CR4: 00000000000006e0
[ 34.668610] Call Trace:
[ 34.697843] __mutex_add_waiter+0x23/0x50
[ 34.745783] __mutex_lock.isra.8+0x1d1/0x4a0
[ 34.796846] ? __handle_mm_fault+0xa83/0x1270
[ 34.848948] ? _kstrtoull+0x3b/0x90
[ 34.890657] set_target+0x95/0xf0 [dni_dps460]
[ 34.943797] kernfs_fop_write+0x116/0x190
[ 34.991740] vfs_write+0xa5/0x1a0
[ 35.031363] ksys_write+0x57/0xd0
[ 35.070990] do_syscall_64+0x53/0x110
[ 35.114773] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 35.175195] RIP: 0033:0x7fa40d5c9504
[ 35.217939] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
[ 35.442692] RSP: 002b:00007ffc1ff54c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 35.533268] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007fa40d5c9504
[ 35.618648] RDX: 0000000000000006 RSI: 00005648cb0ea6c0 RDI: 0000000000000001
[ 35.704032] RBP: 00005648cb0ea6c0 R08: 000000000000000a R09: 00007fa40d69aca0
[ 35.789415] R10: 000000000000000a R11: 0000000000000246 R12: 00007fa40d69b760
[ 35.874801] R13: 0000000000000006 R14: 00007fa40d696760 R15: 0000000000000006
[ 35.960186] Modules linked in: optoe(E) lm75(E) ltc4215(E) max6620(E) emc1403(E) jc42(E) dni_dps460(E) pmbus_core(E) at24(E) dell_s6000_platform(OE) i2c_mux_gpio(E) i2c_mux(E) nvram(E) nft_counter(E) xt_conntrack(E) nf_nat(E) nf_conntrack_netlink(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) libcrc32c(E) xfrm_user(E) xfrm_algo(E) intel_powerclamp(E) coretemp(E) bonding(E) kvm(E) evdev(E) dcdbas(E) efi_pstore(E) irqbypass(E) efivars(E) pcspkr(E) ie6xx_wdt(E) sg(E) linux_knet_cb(OE) linux_bcm_knet(OE) psample(OE) linux_user_bde(OE) linux_kernel_bde(OE) button(E) ebt_vlan(E) ebtable_broute(E) bridge(E) stp(E) llc(E) ebtable_nat(E) ebtable_filter(E) ebtables(E) nf_tables(E) nfnetlink(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) loop(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E)
[ 36.808149] fscrypto(E) ecb(E) crypto_simd(E) cryptd(E) glue_helper(E) aes_x86_64(E) nls_utf8(E) nls_cp437(E) nls_ascii(E) vfat(E) fat(E) overlay(E) squashfs(E) zstd_decompress(E) xxhash(E) sd_mod(E) i2c_isch(E) gpio_sch(E) ohci_pci(E) ohci_hcd(E) ehci_pci(E) ehci_hcd(E) ahci(E) lpc_sch(E) libahci(E) i2c_ismt(E) e1000e(E) libata(E) usbcore(E) usb_common(E) scsi_mod(E) thermal(E)
[ 37.211027] ---[ end trace 0b237926c185882f ]---
[ 37.278141] RIP: 0010:__list_add_valid.cold.0+0x26/0x28
[ 37.340781] Code: 00 00 00 c3 48 89 d1 48 c7 c7 b8 b1 09 b2 48 89 c2 e8 c0 96 d0 ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 10 b2 09 b2 e8 ac 96 d0 ff <0f> 0b 48 89 fe 48 89 c2 48 c7 c7 a0 b2 09 b2 e8 98 96 d0 ff 0f 0b
[ 37.565735] RSP: 0000:ffffb94a41307db0 EFLAGS: 00010246
[ 37.628361] RAX: 0000000000000075 RBX: ffffb94a41307e00 RCX: 0000000000000000
[ 37.713962] RDX: 0000000000000000 RSI: ffff973437a966b8 RDI: ffff973437a966b8
[ 37.799537] RBP: ffff97342e094110 R08: 0000000000000339 R09: 0000000000000004
[ 37.884991] R10: 000000000000072e R11: ffffffffb27f26ad R12: ffff97342e094118
[ 37.970487] R13: ffff97342e094100 R14: ffffb94a41307f08 R15: ffff97342e094100
[ 38.055977] FS: 00007fa40d4dc740(0000) GS:ffff973437a80000(0000) knlGS:0000000000000000
[ 38.152895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 38.221705] CR2: 00007f52592af024 CR3: 000000022e194000 CR4: 00000000000006e0
[ 38.390127] e1000e: eth0 NIC Link is Down
[ OK ] Started Dell S6000 Platform modules.
[ OK ] Started Dell S6000 fan speed regulator.
Starting Platform monitor container...
Stopping System Logging Service...
[ OK ] Stopped System Logging Service.
Starting System Logging Service...
[ OK ] Started System Logging Service.
[ OK ] Started Update rsyslog configuration.
[ OK ] Started BGP container.
[ OK ] Started Platform monitor container.

**Output of `show version`:**

```

admin@str-s6000-acs-8:~$ show vers

SONiC Software Version: SONiC.master.339-31baf381
Distribution: Debian 10.4
Kernel: 4.19.0-6-2-amd64
Build commit: 31baf381
Build date: Tue Jul 7 07:01:13 UTC 2020
Built by: johnar@jenkins-worker-8

Platform: x86_64-dell_s6000_s1220-r0
HwSKU: Force10-S6000
ASIC: broadcom
Serial Number: 1QBRX42
Uptime: 20:32:35 up 1:09, 1 user, load average: 1.12, 1.09, 1.12

Docker images:
REPOSITORY TAG IMAGE ID SIZE
docker-sonic-mgmt-framework-dbg latest 794af0888273 532MB
docker-sonic-mgmt-framework-dbg master.339-31baf381 794af0888273 532MB
docker-sonic-mgmt-framework latest 794af0888273 532MB
docker-sonic-mgmt-framework master.339-31baf381 794af0888273 532MB
docker-router-advertiser-dbg latest 955c10a491a8 409MB
docker-router-advertiser-dbg master.339-31baf381 955c10a491a8 409MB
docker-router-advertiser latest 955c10a491a8 409MB
docker-router-advertiser master.339-31baf381 955c10a491a8 409MB
docker-lldp-dbg latest 91902f23a0e2 440MB
docker-lldp-dbg master.339-31baf381 91902f23a0e2 440MB
docker-lldp latest 91902f23a0e2 440MB
docker-lldp master.339-31baf381 91902f23a0e2 440MB
docker-dhcp-relay-dbg latest 2e3649d1b65c 417MB
docker-dhcp-relay-dbg master.339-31baf381 2e3649d1b65c 417MB
docker-dhcp-relay latest 2e3649d1b65c 417MB
docker-dhcp-relay master.339-31baf381 2e3649d1b65c 417MB
docker-database-dbg latest dd1067175c65 409MB
docker-database-dbg master.339-31baf381 dd1067175c65 409MB
docker-database latest dd1067175c65 409MB
docker-database master.339-31baf381 dd1067175c65 409MB
docker-orchagent-dbg latest 6db66c4c240d 502MB
docker-orchagent-dbg master.339-31baf381 6db66c4c240d 502MB
docker-orchagent latest 6db66c4c240d 502MB
docker-orchagent master.339-31baf381 6db66c4c240d 502MB
docker-sonic-telemetry-dbg latest 7596d23edc61 472MB
docker-sonic-telemetry-dbg master.339-31baf381 7596d23edc61 472MB
docker-sonic-telemetry latest 7596d23edc61 472MB
docker-sonic-telemetry master.339-31baf381 7596d23edc61 472MB
docker-snmp-dbg latest 4c7efb40365c 453MB
docker-snmp-dbg master.339-31baf381 4c7efb40365c 453MB
docker-snmp latest 4c7efb40365c 453MB
docker-snmp master.339-31baf381 4c7efb40365c 453MB
docker-teamd latest 049b0865b5c8 420MB
docker-teamd master.339-31baf381 049b0865b5c8 420MB
docker-teamd-dbg latest 049b0865b5c8 420MB
docker-teamd-dbg master.339-31baf381 049b0865b5c8 420MB
docker-syncd-brcm-dbg latest 046236ae18c9 534MB
docker-syncd-brcm-dbg master.339-31baf381 046236ae18c9 534MB
docker-syncd-brcm latest 046236ae18c9 534MB
docker-syncd-brcm master.339-31baf381 046236ae18c9 534MB
docker-sflow-dbg latest ed900f1d0288 391MB
docker-sflow-dbg master.339-31baf381 ed900f1d0288 391MB
docker-sflow latest ed900f1d0288 391MB
docker-sflow master.339-31baf381 ed900f1d0288 391MB
docker-platform-monitor-dbg latest 18bcfbee046d 425MB
docker-platform-monitor-dbg master.339-31baf381 18bcfbee046d 425MB
docker-platform-monitor latest 18bcfbee046d 425MB
docker-platform-monitor master.339-31baf381 18bcfbee046d 425MB
docker-nat-dbg latest b143359092bd 421MB
docker-nat-dbg master.339-31baf381 b143359092bd 421MB
docker-nat latest b143359092bd 421MB
docker-nat master.339-31baf381 b143359092bd 421MB
docker-fpm-frr-dbg latest e68c02a1a8aa 449MB
docker-fpm-frr-dbg master.339-31baf381 e68c02a1a8aa 449MB
docker-fpm-frr latest e68c02a1a8aa 449MB
docker-fpm-frr master.339-31baf381 e68c02a1a8aa 449MB
```