Re: regression (crash) in sysmon/acpiacad

[Paul Goyette <paul%whooppee.com@localhost>]

On Sun, 7 Feb 2010, Jukka Ruohonen wrote:

> On Sun, Feb 07, 2010 at 02:24:37PM +0100, Joerg Sonnenberger wrote:
> > The point is that they have specific meaning for the hardware and as I
> > said, are generally not changeable. For example, on my laptop, the power
> > LED turns orange when warning cap is reached and shuts down hard on
> > critical.
>
> You can already alter the low and warning capacity, as documented in
> envsys.conf(5). I am not arguing that it would be a good idea, quite the
> contrary.

You can't necessarily change the values that the hardware monitors, but 
you can set the limits that are used to control the sending of event 
notifications to powerd.  (A sensor can also set the ENVSYS_MONNOTSUPP 
flag to disable changing those limits.)

> If sme_set_limits() is omitted but sme_get_limits() is introduced, the
> visible change would merely imply that from
>
> $ envstat -d acpibat0
>                  Current  CritMax  WarnMax  WarnMin  CritMin Unit
>      warn cap:     2.511                                     Wh ( 5.00%)
>       low cap:     0.200                                     Wh ( 0.40%)
>        charge:    50.230                                     Wh (100.00%)
>
> we would move to
>
> $ envstat -d acpibat0 | grep cap
>                Current  CritMax  WarnMax  WarnMin  CritMin Unit
>         ...
>      charge:    50.230                       2.511    0.200   Wh (100.00%)

At least currently, sensors with the ENVSYS_FPERCENT flag display all of 
their limit values as percentages.  So the output would be more like

       charge:    50.230                     5.000%   0.400%   Wh (100.00%)

> Similar thing is already done in acpitz(4), sdtemp(4), and ipmi(4). The
> argumentation in favor of the percentages goes in similar vein.
>
> As I understand it, these callbacks were introduced specifically for those
> sensors that are capable of checking the limits "in hardware". Supposedly
> this should be the case here.

Yes, the primary rationale for these callbacks is to provide a means for 
userland to obtain (and possibly modify) the values used by the hardware 
device to raise alarms.  At the time I was writing the sdtemp(4) driver, 
it seemed silly to always compare current-vs-limit in software when the 
chip was more than happy to do that task for us, if we would only set a 
threshold value for it to use!


-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------