September 24, 200817 yr [From http://lime-technology.com/forum/index.php?topic=2110.msg19656#msg19656, in a thread on an interface to unRAID that exposes lm_sensors but does not concern the functionality itself.] @ReneV, lm_sensors requires ... After a bit of legwork (with perl), I gather that the P5B-VM DO motherboard has a w83627ehf sensor. From what I understand, I therefore only need to obtain the appropriate w83627ehf.ko file, put it in the right place (which appears to be /etc/modprobe.d), execute `modprobe w83627ehf', install lm_sensors, and I should be on my way. [using modprobe should mean that I do not need to mess with the kernel's .config file.] w83627ehf.ko is available in the kernel-modules-FOOBAR files that can be found in the slackware repository, but the 3 different ones I've tried have resulted in errors when modprobe'd, and I've concluded that this is a prudent time to admit that I've been attempting to follow instructions without any real sort of understanding. Would anyone care to comment on what I've tried doing? Do you have lm_sensors working bubbaQ?
September 24, 200817 yr >> Would anyone care to comment on what I've tried doing? While I cannot provide satisfying comment on what you are doing, I thank you for starting the new thread. I mention this needs a topic, because it has merit and should be given consideration. Generally the kernel has been pruned for the smallest size possible to save on ram. My thoughts lately have been that some of these drivers (or at least the hardware sensors) should be compiled into the kernel, but perhaps left off the bzroot file system, and instead presented as an addon package. This would let people extract what they need or only install the drivers/packages if a need arose. It's not hard to recompile a kernel. It just takes a bit of time with the setup. I.E. you need a dev system, then the kernel source, then extracting the root, compiling the kernel, updating bzroot, recompressing and putting it on your flash. While somewhat daunting to a novice, it still takes time for anyone. Maybe someone knows a way to install drivers from a different compilation. I know in the past I was prevented and if I forced it. sooner or later the kernel would oops. Therefore I open the matter for discussion and consideration to have the drivers compiled as part of the kernel and either included or posted externally so users may grab what is needed.
September 24, 200817 yr Would anyone care to comment... Have you considerd building a new kernel with the drivers you need?
September 24, 200817 yr Author Have you considerd building a new kernel with the drivers you need? Yes, but realistically speaking it"s not gonna happen unless I miraculously find several extras hours a day. Thanks for all the info, though; it's bound to be useful somehow ...
September 24, 200817 yr Actually, that may not work, because of some other references The better solution is to get the proper .ko file, and run: insmod /<path>/w83627ehf.ko Try the attached file... .compiled on my unRAID system, running 2.6.26.5 ... if that doesn't work, I can post one from 2.6.24.5.
September 24, 200817 yr Actually, that may not work, because of some other references The better solution is to get the proper .ko file, and run: insmod /<path>/w83627ehf.ko I agree, but should the "proper" module be one that was originally compiled with the unRAID kernel? Perhaps I'm not up to date on this, but if I compile a kernel with modules. Can I build another module on a different system (even if it is the same source) and install it elsewhere with all references being resolved? Does depmod come into play here in any manner? Anytime I had to add a module, I thought the basic framework for supporting that module needed to be compiled first.
September 24, 200817 yr Author The better solution is to get the proper .ko file, and run: insmod /<path>/w83627ehf.ko I'm afraid I'm getting "Invalid module format". I would be keen to try a .ko from an earlier kernel, if you can be bothered. (4.3.3 is using 2.6.24.4, but 2.6.24.5 could be worth a shot ...)
September 24, 200817 yr Author The better solution is to get the proper .ko file, and run: insmod /<path>/w83627ehf.ko I'm afraid I'm getting "Invalid module format". I would be keen to try a .ko from an earlier kernel, if you can be bothered. (4.3.3 is using 2.6.24.4, but 2.6.24.5 could be worth a shot ...) I just noticed the following in my syslog: <date and time> 192 kernel: w83627ehf: version magic '2.6.24.4-unRAID-special mod_unload PENTIUM4 ' should be '2.6.24.4-unRAID mod_unload PENTIUM4 '
September 25, 200817 yr Author Did you try the "--force" option? Yes. (Well, -f, at any rate.) Try this one.... Same result as before. I gather it's due to the unraid environment being (too) different from the compile environment, which would rather suggest that lm_sensors is an issue for limetech to look into ... At any rate, thank you so much for your efforts and kindness, bubbaQ and WeeboTech.
January 13, 200917 yr I obtained sensors drivers (f71882fg.ko & coretemp.ko) from this link http://packages.slackware.it/package.php?q=current/kernel-modules-smp-2.6.27.7_smp-i686-1 and when i try to manually install them through insmod, i got following error insmod ./coretemp.ko insmod: error inserting './coretemp.ko': -1 Invalid module format and through dmesg i saw following error. coretemp: version magic '2.6.27.7-smp SMP mod_unload 686 ' should be '2.6.27.7-unRAID SMP mod_unload CORE2 ' Any idea how do i fix this problem? Do i need to compile driver by myself?
Archived
This topic is now archived and is closed to further replies.