Fix temp status sysctl values.
Clear fan alarms after we read them.
Do not read invalid or old fan values.
Do not read voltage and temperature alarms on fan-only chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2485 7894878c-1315-0410-8ee3-d5d059ff63e0
Ticket #1573
--------------
Another update for his issue [kernel panic triggered by bmcsensors}:
The source of the problem are the non-atomic kernel mallocs for device
registration called from an interrupt context - this doesn't seem to be
supported and as observed can crash the kernel.
A possible solution is to create a kernel thread on initialisation,
leave that thread hanging round while the device scan runs, and finaly
signal the init thread when device scan is complete to finish
initialisation be registing the sensors found during scan.
A patch implementing such a scheme was created by Yvon JEGOU, I'll post
it here again.
Thanks, Martin
--------------
Hi Mark,
>> I don't fully understand... sorry if I'm slow.
>> is the problem doing mallocs from an interrupt context or non-atomic
>> mallocs?
>> what's non-atomic about the malloc?
>> how did we get in an interrupt context?
Being no kernel programmer this is fairly hard form me to answer; lets
see how far I get
The problem is non-atomic kmallocs from an interrupt context.
Non-atomic refers to the flags specified in the kmalloc call (GFP_ATOMIC
vs. GFP_KERNEL) (Ref. http://lwn.net/Articles/22909/)
Scanning for sensors is triggered by sending an ipmi message in
bmcsensors_reserve_sdr. Building the list of sensors and finally
creating the required proc entries happens on subsequent reception of
ipmi messages in the ipmi call-back. If I understand correctly how
things interact, that would be in an interrupt context.
Where bmcsensors blows up when trying to register lots of sensors is the
-> bmcsensors_command (which is the i2c-ipmi call-back)
-> bmcsensors_msg_handler
-> bmcsensors_rcv_msg
-> bmcsensors_rcv_sdr_msg
-> bmcsensors_build_proc_table
-> i2c_register_entry
-> create_proc_entry
-> proc_create
-> kmalloc
sequence.
My limited understanding of kernel programming is that if memory is
allocated in an interrupt context, GFP_ATOMIC must be used.
While the kmallocs done directly by bmcsensors_build_proc_table would be
fixable, the calls in proc_create_entry are obviously not changeable.
This makes proc_create and its callers unsafe for use in an interrupt
context.
The patch works around this limitation by creating a separate kernel
thread from sm_bmcsensors_init and calling bmcsensors_build_proc_table
from this thread after scanning for sesnsors has finished.
Hope I've managed to adequately explain what I think is wrong.
Bye, Martin
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2482 7894878c-1315-0410-8ee3-d5d059ff63e0
in our back).
Fix compilation without DEBUG.
Do not read in and temp alarms more than needed.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2481 7894878c-1315-0410-8ee3-d5d059ff63e0
pwm_enable (read-only); handle fan invert.
Fix temp_crit being read from temp_min register.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2479 7894878c-1315-0410-8ee3-d5d059ff63e0
Show more status bits (voltages and temperatures).
Fix incorrect use of const.
Clear status bits on update.
Fix temperature reads (min, crit and current).
Fix temperature writes (min).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2477 7894878c-1315-0410-8ee3-d5d059ff63e0
Fix voltage magnitudes.
Fix voltage limits order.
Add voltage limits write support.
Add temperature limits write support.
Prevent user from setting limit of nonexistent fan 3.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2460 7894878c-1315-0410-8ee3-d5d059ff63e0
* Use unused bits of two more registers (configuration and conversion
rate) to reduce misdetections.
* Return with -ENODEV if the detection fails.
* Change the order in which we try to identify the chips. We better
finish with the LM84 and the MAX1617, in this order, because they are
harder to identify and are more likely to result in false positives.
* Refine LM84 detection. The LM84 has less features than the other chips
(chip cannot be stopped, conversion rate cannot be set, no low limits)
so it has extra unused bits.
* Do not intialize the chip if it was detected as an LM84. This one
cannot be stopped so why would we try to start it again? And as said
right before, conversion rate isn't changeable either.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2395 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare