Skip to content

Fix false alarm when writing convrate on max6658#82

Merged
lguohan merged 2 commits intosonic-net:masterfrom
byu343:al-temp
Jul 11, 2019
Merged

Fix false alarm when writing convrate on max6658#82
lguohan merged 2 commits intosonic-net:masterfrom
byu343:al-temp

Conversation

@byu343
Copy link
Copy Markdown
Contributor

@byu343 byu343 commented May 2, 2019

We found that max6658 sporadically sends a false overtemp alarm during
changing the convrate by hwmon kernel driver. This workaround will fix it by
forcing to stop conversion before setting the convrate. The false alarm will
trigger reboot and we found it on Arista 7170 switch.

We found that the max6658 sometimes issues a false alarm when its
convrate is changed, with the current hwmon driver. This workaround
will fix it by stopping the conversion before setting the convrate.
@byu343 byu343 marked this pull request as ready for review May 2, 2019 19:44
@lguohan
Copy link
Copy Markdown
Contributor

lguohan commented May 28, 2019

is this a upstream fix? is this a generic fix?

@byu343
Copy link
Copy Markdown
Contributor Author

byu343 commented May 28, 2019

is this a upstream fix? is this a generic fix?
It is not from upstream.

I was thinking that the change would be generic, as it only adds some steps to change the stop/run bit of LM90_REG_R_CONFIG1, which is similar to what has been done in the function lm90_init_client(). But considering that we are not able to test the change on all the chips supported by lm90, maybe it is better to add some if-conditions to make the change only be applied to max6658. I'll make a change.

@lguohan
Copy link
Copy Markdown
Contributor

lguohan commented Jun 9, 2019

agree.

@lguohan lguohan merged commit d03f616 into sonic-net:master Jul 11, 2019
dal00 pushed a commit to kamelnetworks/sonic-linux-kernel that referenced this pull request Jul 20, 2025
…or DualToR config (sonic-net#82)

This PR is a required for changing the L3 IP forwarding Behavior to SoC in active-active toplogy.
Basically a src IP is added to the SNAT rule so that only packets originating from ToR with src IP as vlan IP get natted by the rule and change the src IP to LoopBack IP
However if there are mutiple vlan IP's we only add the source IP as vlan IP, for which the SoC IP belongs to, this PR adds that change.

How I did it
check the config DB if the ToR is a DualToR and has an SoC IP assigned.
put an iptable rule
iptables -t nat -A POSTROUTING --destination -j SNAT --to-source "

Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants