Read fan low limit at init.
Do not read temperatures and voltages if no new data is ready.
Drop PWM debugging.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2554 7894878c-1315-0410-8ee3-d5d059ff63e0
Fix enable; implement disable; preserve clock select bit;
/proc value now 0-255; use correct bits in register
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2536 7894878c-1315-0410-8ee3-d5d059ff63e0
Prevent fan_min register overflow on auto fan clock divider
decrease.
Prevent writes on pwm 3 registers on PC87360 and PC87363.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2531 7894878c-1315-0410-8ee3-d5d059ff63e0
Less agressive initialization process (do not reset the chip,
closes ticket #1154; preserve application mode)
Fix temp1 (instead of temp2) limits being unsettable in application
mode 2 (tickets #894 and #1219).
Ensure that temp2 and in4 are not used at the same time (ticket
#894).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2516 7894878c-1315-0410-8ee3-d5d059ff63e0
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
Jean Delvare