tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: regression (crash) in sysmon/acpiacad



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  |
-------------------------------------------------------------------------


Home | Main Index | Thread Index | Old Index