| Age | Commit message (Collapse) | Author |
|
Callout may ONLY take sme_work_mtx, at IPL_SOFTCLOCK; MUST NOT touch
sme_mtx at IPL_NONE. All state the callout needs is serialized by
sme_work_mtx now:
- calls to sme_schedule_callout
- calls to sme_schedule_halt
- struct sysmon_envsys::sme_events_timeout
- struct sysmon_envsys::sme_events_list
- struct sysmon_envsys::sme_callout_state
- struct envsys_data::flags
=> yes, this is a little silly -- used for ENVSYS_FNEED_REFRESH
=> should maybe separate the static driver-defined features from
the state flags needed by sysmon_envsys but not important now
Sleeping under sme_work_mtx (except on other adaptive locks at
IPL_SOFTCLOCK) is forbidden. Calling out to the driver under
sme_work_mtx is forbidden.
This should properly fix:
https://mail-index.netbsd.org/tech-kern/2015/10/14/msg019511.html
PR kern/56592
|
|
|
|
queries or modifications of the state with the sme_mtx mutex.
Detach the rndsrc before re-attaching it (with potentially new values).
Clean up some lock-ordering issues.
And a couple of KNF issues for good measure!
Should address PR kern/52533
XXX Pullup-8 along with the previous fixes from msaitoh@
XXX http://mail-index.netbsd.org/source-changes/2017/09/06/msg088028.html
~
~
|
|
use sysmon_envsys sleep waiting at "rndsrc" when "drvctl -d".
Don't call rnd_detach_source() in sme_remove_event() which is called
from sme_event_unregister_all(). Instead, call rnd_detach_source() in
sysmon_envsys_sensor_detach() and call sysmon_envsys_sensor_detach()
before sme_event_unregister_sensor(). Each sensor(envsys_data) has each
rnd_src, but some sme_events point to the same rnd_src in a sensor.
Calling rnd_detach_souce() twice with the same rnd_src brokes a reference
count in rnd_src. OK'd by pgoyette@.
|
|
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
|
|
https://mail-index.netbsd.org/tech-kern/2015/10/14/msg019511.html
don't sleep on sme->sme_mtx in the callout but use mutex_tryenter()
and just reschedule the callout if we can't get the mutex now.
This fixes a deadlock which can happen if the backed wants to
sleep with timeout (e.g. cv_timedwait()) as the backed is called with
sme->sme_mtx held.
This is a stopgap measure for netbsd-7; sysmon should be changed to not
sleep (or call a backend which will sleep) with mutexes held.
|
|
one occurred.
|
|
n ot just that one or the other is non-NULL!
|
|
|
|
Protect this counter with a new short time lock "sme_work_mtx" and
keep "sme_mtx" as long time lock.
Removes a deadlock where an active event holds "sme_mtx", the callout
"sme_events_check" blocks on "sme_mtx" and callout processing stops.
|
|
workqueue_destroy may sleep so we shouldn't run it with holding a mutex.
Requested by riastradh@.
|
|
In order to call callout_destroy for a callout safely, we have to ensure
the function of the callout is not running and pending. To do so, we should
use callout_halt, not callout_stop.
In this case, we need to pass an interlock to callout_halt to wait for
the callout complete. And also we make sure that SME_CALLOUT_INITIALIZED
is unset before calling callout_halt to prevent the callout from calling
callout_schedule. This is the same as what we did in sys/netinet6/mld6.c@1.61.
Reviewed by riastradh@.
|
|
We can use sme_mtx for the callout as well. Actually we should do so
because sme_events_list and some other data that are touched in the
callout should be protected by sme_mtx, not sme_callout_mtx.
Discussed with riastradh@ in http://mail-index.netbsd.org/tech-kern/2014/11/11/msg017956.html
|
|
|
|
|
|
|
|
No functional change intended, and atf tests (using swsensor(4)) still
pass 100%
|
|
- don't assume that all batteries have exactly one ENVSYS_INDICATOR
- check capacity and charge sensors for ENVSYS_SVALID before using them
now this works on macppc
|
|
for defflagging these.
|
|
2. Update handling of FMONCRITICAL event reporting. The state
transition does not require a corresponding change in value.
With these changes, you can now have an INDICATOR sensor that
reports the presence or absence of a device, and (if the device
is present) separately monitor it for proper functioning.
Should address the concerns expressed recently with the commit
of changes to wmi(4) BBU handling.
|
|
entropy gathering), allow it to be updated for the current request to
add a real entry.
|
|
|
|
callback to update the value can be polled to provide rnd(4) entropy.
|
|
hook the sensor into rnd subsystem, and make sure we periodically
refresh the sensor whether or not it is being actively monitored.
|
|
all the associated events.
|
|
Battery-charge sensors.
|
|
callout immediately rather than waiting for the previous timer to
expire.
|
|
than duplicating the code every time. Minor reduction in code size
(about 1200 bytes on amd64), no change in functionality.
|
|
whether the properties actually exist.
When setting new limit values, don't complain/ignore about duplicate
values if the associated flag bits (indicating that the limit is valid)
are not set.
These two fixes together should fix a problem reported in private Email
by njoly@ a couple months ago. Issue replicated and solution tested
using my recent swsensor pseudo-device running inside qemu world!
|
|
|
|
one. Fixes a panic reported by njoly@ in private Email
2. Acquire the device before checking whether or not the get_limits
routine exists.
XXX There's still a bug in here somewhere that prevents setting of
XXX limit values after using 'envstat -S'
|
|
which could have modified hardware state are informed so that original
state can be restored.
Welcome to 5.99.27
|
|
are not currently set (and, in case of battery capacity sensors, if there
is no value_max). Ensure that such an event-monitor does not trigger the
delivery of any actual events.
Provide a mechanism for sensors to set their limits at time other than
system startup (for example, when a battery is inserted).
This allows us to boot a system with a battery missing, install the
battery some time later, and automatically monitor it without requiring
any user intervention to create the event-monitor. (The actual changes
for battery sensors to use this new capability will come later.)
|
|
|
|
sensor if no event type is specified.
|
|
|
|
exported to device drivers, so rename it and move the declaration to
<dev/sysmon/sysmonvar.h>
|
|
sme_events_worker().
Provide a wrapper that can be called from sensor drivers' interrupt
routines to find and deliver a specific event.
XXX Actually updating sensor drivers (and their parent devices) to
XXX have interrupts is a future enhancement. This is simply an
XXX enabler.
|
|
|
|
sensors.
|
|
|
|
meaningful for a few limited function calls; all persitent storage
of limit-present flags is maintained in the edata->upropset member.
|
|
|
|
flags to determine which limits are present.
|
|
|
|
its refresh() callback. Just assume that its value has been properly
updated by other means.
|
|
constraints to both driver-requested and user-requested monitoring.
While here, clean up some of the debugging DPRINTFs.
|
|
Use the limits_flags only for calls to the {get,set}_limits() callbacks
and merge the results into upropset, rather than trying to maintain both
values (error prone).
|
|
|
|
event data. Otherwise, they're not processed.
XXX This needs to be rethought. While fixing it this way makes things
XXX "work", we really shouldn't need to replicate these flags. The
XXX limits and their flags should be kept as part of the sensor data,
XXX and not part of the event-monitor data. I'll work on this in the
XXX near future.
|