is needed to properly lock chip drivers in memory while anyone uses their
/proc entries. This also brings back compatibility with the 2.4 Linux
kernel.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2784 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
- fix voltage scaling
- swap voltage limits
- use lower critical rather than upper hysteresis
for non-temperature sensors
- increase libsensors support to 20 voltage, 10 fan,
10 temperature sensors
Tickets 1406 and 1407.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2017 7894878c-1315-0410-8ee3-d5d059ff63e0
Copy sysctl enums to chip drivers from sensors.h for now,
as seen in drivers included in 2.5 tree. File no longer included
from kernel side.
Apply i2c-proc change in CVS tagged -km2.
Partial clean and sort of includes everywhere.
Add i2c-dev.h, as a partial copy from i2c.
Add to sensors.h from i2c-proc.h to compile things.
Remove i2c-isa.h.
Reflect header file changes to lib/ and prog/.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1705 7894878c-1315-0410-8ee3-d5d059ff63e0
Module refcounting using .owner, removing of inc/dec_use.
These require (yet unreleased) i2c 2.8.0+.
Named initializers everywhere. Unified namespace.
Cleanup for 2.5, remove EXPORT_NO_SYMBOLS, declare everything
static. Apply initcalls.
PCI device registration changes for busses started, replicating
from i2c-amd*. While everything does compile, nothing really
works. Well, maybe i2c-amd* ported back from 2.5 tree.
After updating your work directory, run
> cvs diff -u -r LAST-PRE-2-8-I2C > lm-2.8-patches-1
BEWARE: I have not even insmoded any of these yet.
To compile, you need i2c from cvs too.
For 2.4 kernel :
> cvs co -r lk2-4 i2c
For 2.5 kernel :
> cvs co i2c
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1698 7894878c-1315-0410-8ee3-d5d059ff63e0
Mark D. Studebaker