All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
From: correomm correomm@gmail.com To: CentOS mailing list centos@centos.org Sent: Thursday, August 18, 2016 1:55 PM Subject: Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]
Yes, I tried it, but does not exists:
vmguest # cat /proc/sys/kernel/softlockup_thresh cat: /proc/sys/kernel/softlockup_thresh: No such file or directory
On Thu, Aug 18, 2016 at 2:06 PM, Carlos A. Carnero Delgado < carloscarnero@gmail.com> wrote:
2016-08-18 12:39 GMT-04:00 correomm correomm@gmail.com:
This bug is reported only on the VM's with CentOS 7 running on on VMware ESXi 5.1. The vSphere performance graph shows high CPU consume and disk activity
only
on VM's with CentOS 7. Sometimes I can not connect remotely with ssh (timeout error).
I'm also seeing those errors in several servers, running under 5.5. Currently investigating if this https://kb.vmware.com/selfservice/microsites/search. do?language=en_US&cmd=displayKC&externalId=1009996 has anything to do (the resource overcommit bit).
HTH, Carlos. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
| | Virus-free. www.avg.com |
Never saw this email....Did anyone get it? anyone know how to fix this?thanks again.
From: KM info4km@yahoo.com To: CentOS mailing list centos@centos.org Sent: Monday, August 7, 2017 11:26 AM Subject: Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
From: correomm correomm@gmail.com To: CentOS mailing list centos@centos.org Sent: Thursday, August 18, 2016 1:55 PM Subject: Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]
Yes, I tried it, but does not exists:
vmguest # cat /proc/sys/kernel/softlockup_thresh cat: /proc/sys/kernel/softlockup_thresh: No such file or directory
On Thu, Aug 18, 2016 at 2:06 PM, Carlos A. Carnero Delgado < carloscarnero@gmail.com> wrote:
2016-08-18 12:39 GMT-04:00 correomm correomm@gmail.com:
This bug is reported only on the VM's with CentOS 7 running on on VMware ESXi 5.1. The vSphere performance graph shows high CPU consume and disk activity
only
on VM's with CentOS 7. Sometimes I can not connect remotely with ssh (timeout error).
I'm also seeing those errors in several servers, running under 5.5. Currently investigating if this https://kb.vmware.com/selfservice/microsites/search. do?language=en_US&cmd=displayKC&externalId=1009996 has anything to do (the resource overcommit bit).
HTH, Carlos. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
| | Virus-free. www.avg.com |
Never saw this email....Did anyone get it? anyone know how to fix this?thanks again.
From: KM info4km@yahoo.com To: CentOS mailing list centos@centos.org Sent: Monday, August 7, 2017 11:26 AM Subject: Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
From: correomm correomm@gmail.com To: CentOS mailing list centos@centos.org Sent: Thursday, August 18, 2016 1:55 PM Subject: Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]
Yes, I tried it, but does not exists:
vmguest # cat /proc/sys/kernel/softlockup_thresh cat: /proc/sys/kernel/softlockup_thresh: No such file or directory
On Thu, Aug 18, 2016 at 2:06 PM, Carlos A. Carnero Delgado < carloscarnero@gmail.com> wrote:
2016-08-18 12:39 GMT-04:00 correomm correomm@gmail.com:
This bug is reported only on the VM's with CentOS 7 running on on VMware ESXi 5.1. The vSphere performance graph shows high CPU consume and disk activity
only
on VM's with CentOS 7. Sometimes I can not connect remotely with ssh (timeout error).
I'm also seeing those errors in several servers, running under 5.5. Currently investigating if this https://kb.vmware.com/selfservice/microsites/search. do?language=en_US&cmd=displayKC&externalId=1009996 has anything to do (the resource overcommit bit).
HTH, Carlos. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
| | Virus-free. www.avg.com |
On Mon, 2017-08-07 at 15:26 +0000, KM wrote:
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
Yes, I see this behavior as well. Never have found a solution - other than increasing the threshold and pretending it doesn't happen.
Adam Tauno Williams wrote:
On Mon, 2017-08-07 at 15:26 +0000, KM wrote:
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
Yes, I see this behavior as well. Never have found a solution - other than increasing the threshold and pretending it doesn't happen.
We see it a fair bit, and this is on server running on bare metal, not VMs.
mark
On 24 April 2018 at 17:16, m.roth@5-cent.us wrote:
Adam Tauno Williams wrote:
On Mon, 2017-08-07 at 15:26 +0000, KM wrote:
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
Yes, I see this behavior as well. Never have found a solution - other than increasing the threshold and pretending it doesn't happen.
We see it a fair bit, and this is on server running on bare metal, not VMs.
On bare metal is usually means some hardware has gone into an uninteruptable IRQ and the CPU is waiting for it to go away. I saw this with systems with Green disk drives a while ago. Something going to talk to the drive would just sit for long times while the drive spun up, the cache was validated etc. Other things would be drives on USB disks too when some other USB item started needing input.. since it is a hub environment they can spew for a while and the CPU would report a soft-lockup.
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 04/24/18 17:33, Stephen John Smoogen wrote:
On 24 April 2018 at 17:16, m.roth@5-cent.us wrote:
Adam Tauno Williams wrote:
On Mon, 2017-08-07 at 15:26 +0000, KM wrote:
All,This happens on all of our CentOS 7 VMs. but as stated in the email trail, the file softlockup_thresh does not exist. Should it be added? What is the best way to get rid of this behavior. Thanks in advance and sorry if I missed something along the way.KM
Yes, I see this behavior as well. Never have found a solution - other than increasing the threshold and pretending it doesn't happen.
We see it a fair bit, and this is on server running on bare metal, not VMs.
On bare metal is usually means some hardware has gone into an uninteruptable IRQ and the CPU is waiting for it to go away. I saw this with systems with Green disk drives a while ago. Something going to talk to the drive would just sit for long times while the drive spun up, the cache was validated etc. Other things would be drives on USB disks too when some other USB item started needing input.. since it is a hub environment they can spew for a while and the CPU would report a soft-lockup.
Not hardly. We discovered green drives were nothing we wanted right after they came out. And I'm talking at work, with servers, all drives are either enterprise, as we bought them, or NAS-rated (e.g. WD Red).
mark
-
Adam Tauno Williams -
KM -
m.roth＠5-cent.us -
mark
-
Stephen John Smoogen