hints that project might be LGPL or that we can offer special permission
for non-GPL use. Added SMBus and I2C trademark notices (owned by Intel
and Philips, respectively). Updated package copyright to 2004.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2522 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
I found a small bug in sensors and sensord when used with a w83781d
chip. On this chip the alarms for temp2 and temp3 are merged. However
that is not handled in sensors and sensord.
Please find attached two patches to fix that, one concerning sensors and
the other one concerning sensord.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2511 7894878c-1315-0410-8ee3-d5d059ff63e0
When running sensors-detect on a system with devfs enabled, and the
/proc/mounts report its device different from 'none' (for example devfsd
uses 'devfs' as device name), sensors-detect don't detect devfs and try
to use normal names for i2c devices.
The attached patch fixes that.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2509 7894878c-1315-0410-8ee3-d5d059ff63e0
Discard unused hexchar function.
Massive reindent.
Rework the command line parameters handling.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2489 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
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
Jean Delvare