Summary: | bsnmpd: using bsnmpd + devd + an empty CD-ROM drive = 100% CPU load | ||
---|---|---|---|
Product: | Base System | Reporter: | Vladyslav V. Prodan <admin> |
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed DUPLICATE | ||
Severity: | Affects Only Me | CC: | cem, eugen, franco, jamie, nbari |
Priority: | --- | ||
Version: | 11.0-STABLE | ||
Hardware: | Any | ||
OS: | Any |
Description
Vladyslav V. Prodan
2017-03-21 18:37:59 UTC
When this reproduces, can you run 'procstat -kka | egrep "bsnmpd|devd"' and paste the output in this bug? Possibly run it a couple times and paste each output. (In reply to Conrad Meyer from comment #1) Ok. (In reply to Conrad Meyer from comment #1) # procstat -kka | egrep "bsnmpd|devd" 1047 100600 devd - mi_switch+0xd2 sleepq_catch_signals+0xb7 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x1d3 seltdwait+0xc3 kern_select+0x89f sys_select+0x54 amd64_syscall+0x50e Xfast_syscall+0xfb 2632 100566 bsnmpd - mi_switch+0xd2 sleepq_timedwait+0x42 _sleep+0x27b g_waitfor_event+0xf3 sysctl_kern_geom_confxml+0x39 sysctl_root_handler_locked+0xbf sysctl_root+0x1f8 userland_sysctl+0x1d0 sys___sysctl+0x5f amd64_syscall+0x50e Xfast_syscall+0xfb # procstat -kka | egrep "bsnmpd|devd" 1047 100600 devd - mi_switch+0xd2 sleepq_catch_signals+0xb7 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x1d3 seltdwait+0xc3 kern_select+0x89f sys_select+0x54 amd64_syscall+0x50e Xfast_syscall+0xfb 2632 100566 bsnmpd - mi_switch+0xd2 sleepq_wait+0x3a _sleep+0x29b cam_periph_runccb+0xcd cdprevent+0xa6 cdcheckmedia+0x22 cdopen+0x226 g_disk_access+0xc6 g_access+0x194 g_dev_open+0x116 devfs_open+0x11f VOP_OPEN_APV+0x84 vn_open_vnode+0x209 vn_open_cred+0x2f9 kern_openat+0x1f4 amd64_syscall+0x50e Xfast_syscall+0xfb # procstat -kka | egrep "bsnmpd|devd" 1047 100600 devd - mi_switch+0xd2 sleepq_catch_signals+0xb7 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x1d3 seltdwait+0xc3 kern_select+0x89f sys_select+0x54 amd64_syscall+0x50e Xfast_syscall+0xfb 2632 100566 bsnmpd - mi_switch+0xd2 sleepq_wait+0x3a _sleep+0x29b cam_periph_runccb+0xcd cdcheckmedia+0xe3 cdopen+0x226 g_disk_access+0xc6 g_access+0x194 g_dev_open+0x116 devfs_open+0x11f VOP_OPEN_APV+0x84 vn_open_vnode+0x209 vn_open_cred+0x2f9 kern_openat+0x1f4 amd64_syscall+0x50e Xfast_syscall+0xfb # procstat -kka | egrep "bsnmpd|devd" 1047 100600 devd - mi_switch+0xd2 sleepq_catch_signals+0xb7 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x1d3 seltdwait+0xc3 kern_select+0x89f sys_select+0x54 amd64_syscall+0x50e Xfast_syscall+0xfb 2632 100566 bsnmpd - mi_switch+0xd2 sleepq_wait+0x3a _sleep+0x29b cam_periph_runccb+0xcd cdprevent+0xa6 cdcheckmedia+0x19a cdopen+0x226 g_disk_access+0xc6 g_access+0x194 g_dev_open+0x116 devfs_open+0x11f VOP_OPEN_APV+0x84 vn_open_vnode+0x209 vn_open_cred+0x2f9 kern_openat+0x1f4 amd64_syscall+0x50e Xfast_syscall+0xfb # procstat -kka | egrep "bsnmpd|devd" 1047 100600 devd - mi_switch+0xd2 sleepq_catch_signals+0xb7 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x1d3 seltdwait+0xc3 kern_select+0x89f sys_select+0x54 amd64_syscall+0x50e Xfast_syscall+0xfb 2632 100566 bsnmpd - mi_switch+0xd2 sleepq_wait+0x3a _sleep+0x29b cam_periph_runccb+0xcd cdprevent+0xa6 cdcheckmedia+0x22 cdopen+0x226 g_disk_access+0xc6 g_access+0x194 g_dev_open+0x116 devfs_open+0x11f VOP_OPEN_APV+0x84 vn_open_vnode+0x209 vn_open_cred+0x2f9 kern_openat+0x1f4 amd64_syscall+0x50e Xfast_syscall+0xfb Thanks! I am getting this on vultr.com/netcup.de seems to be happening only on "QEMU" since in AWS or GCE I don't see the error: Processing event '!system=CAM subsystem=periph type=error device=cd0 serial="QM00003" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 3a 00" CDB="00 00 00 00 00 00 " Just in case I am using this kerne: https://github.com/fabrik-red/images/blob/master/fabrik.kernel This should be fixed by now in stable branches. *** This bug has been marked as a duplicate of bug 215471 *** Isn't the bug actually addressed in PR 209368? The currently linked bug is also a duplicate of PR 209368 (but still open for some reason, maybe it can be closed). (In reply to Conrad Meyer from comment #7) Yes, all three of them seem to describe same problem. Cool. *** This bug has been marked as a duplicate of bug 209368 *** |