Got Fujitsu mainboard labeled as D2778-D14 GS50. fschmd module works only if it is loaded even times and does not work if it is loaded odd times. Here is what happened: Module fschmd is loaded at boot time by lm_sensors initialization script, but is not working, sensors command does not show values and /sys/class/hwmon does not contain entries. If I remove fschmd with command "rmmod fschmd" and load it second time with "modprobe fschmd", it starts working (sensors command shows temperatures, fans speed and so on). If I remove it with rmmod and load 3rd time, it does not work. If I remove it and load 4th time, it works and so on. So, I did it several times with same effect: 1st, 3rd, 5th time it does not work, 2nd, 4th, 6th time it works. I assume this has to be something with initialization, timing or something like this in kernel driver fschmd. Updating BIOS to version R1.09C does not help. Here is link to lm_sensors maillist discussion: http://thread.gmane.org/gmane.linux.drivers.sensors/21649/focus=21689 Distribution is Gentoo.
Sergey, may I point to https://bugzilla.redhat.com/show_bug.cgi?id=513101#c18 that says --------------8<-snip----------------------------------- I've worked together with Dean on getting the driver working, and it is working fine now on my Syleus test system. There is one problem though, simply doing: modprobe fschmd Won't work as there is a bug in the Syleus ASIC where it temporary drops of the smbus after receiving an smbus quick command. Normally smbus quick commands are not used to communicate with the Syleus, but the linux i2c subsystem uses an smbus quick command to test for device presence at i2c addresses, before calling the drivers probe function. This "ping" done by the i2c subsystem can be avoided by explicitly telling the i2c subsystem that there is a device present like this: modprobe fschmd force=0,0x73 When used like this, the ping which confuses the Syleus is avoided and the driver works as intended. Note the upstream kernel has a workaround for this, which makes things work without the module parameter, but that depends on major changes in the i2c subsystem and thus cannot be backported to the RHEL-5 kernel. -----------------8<-snip------------------------------------- So now I actually tried on my D2778 board with RHEL5.5 and the module parameter and it worked on the first try. HTH Rainer
Thanks a lot, it works with option "force=0,0x73". PS The link you send requires special permissions, i get "You are not authorized to access bug #513101."
Hi Sergey, that's why I (copy&paste)'d that comment form Red Hats bugzilla. :-) Regards Rainer
This was a known issue of the Syleus device, documented in the sensors-detect script: http://www.lm-sensors.org/changeset/5657/lm-sensors/trunk/prog/detect/sensors-detect Sorry for not remembering it.
Hi Sergey, Short self intro, I'm the author of the fschmd driver, as well as the author of the comment Rainer copy and pasted from RH's bugzilla :) As you're a gentoo user I assume you have a recent kernel, this kernel should auto load the fschmd module. Can you try removing fschmd from /etc/sysconfig/lm_sensors (or gentoo's equivalent config file), so that it does not get loaded by the lm_sensors init script, and remove the "force=0,0x73" from modules.conf (assuming you put it there). Then reboot. After reboot the fschmd module should have been auto loaded by the kernel based on DMI info (assuming the i2c 8xx module got autoloaded based on its PCI id as that module does the loading of the fschmd driver). If this does not work, please run the following command as root: dmidecode > dmi.log And attach dmi.log here Thanks, Hans
Sergey, any progress on this? Did you try Hans' suggestion?
On Gentoo I have kernel 2.6.31. Is this recent enough or should I try something newer? With 2.6.31 fschmd is not loaded automatically. Loading manually produces the problem described above. I also try to install vanilla kernel 2.6.32 on CentOS on this mainboard. There fschmd is not loaded automaticaly also. With manual laoding I get same problems as described above.
Created attachment 26049 [details] output of dmidecode on 2.6.31
Hi Sergey, Thanks for the dmidecode output. If you look at: drivers/i2c/busses/i2c-i801.c In a recent kernel tree, around line 628, you'll find: static struct dmi_onboard_device_info __devinitdata dmi_devices[] = { { "Syleus", DMI_DEV_TYPE_OTHER, 0x73, "fscsyl" }, { "Hermes", DMI_DEV_TYPE_OTHER, 0x73, "fscher" }, { "Hades", DMI_DEV_TYPE_OTHER, 0x73, "fschds" }, }; Notice the "Syleus" your DMI data has "SYLEUS". So it looks like we will have to make the strcmp case insensitive. Jean, lame question, does the kernel have a strcasecmp function ? Sergey, try changing the Syleus to SYLEUS and recompiling the kernel / module. After that the driver should auto load and your problems should be fixed. Regards, Hans
Hans, yes, the kernel supports strcasecmp().
I modified i2c-i801.c as proposed and recompiled kernel-2.6.31. fschmd is not loaded automatically and original problem still exist.
Did you also rebuild and re-install the kernel modules ? i2c-801 is most likely build as a module. I see no reason why autoloading would not work once the issue with SYLEUS being all caps in your DMI table is fixed. Otherwise try replacing the contens of the dmi_check_onboard_device() function with: struct i2c_board_info info; memset(&info, 0, sizeof(struct i2c_board_info)); info.addr = 0x73; strlcpy(info.type, "fscsyl", I2C_NAME_SIZE); i2c_new_device(adap, &info); That should certainly autoload the driver, if that does not work you're not using the new / modified version of the i2c-801 driver / module.
A workaround for this problem was merged into kernel 2.6.34: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1d4b390ea4bb480e65974ce522a04022608a8df Sergey, can you please confirm that it solves your problem? Obviously a clean fix would be preferred. And I think I get it now... Not only the device name changed to uppercase on Sergey's system, but the board manufacturer string changed as well, from "FUJITSU SIEMENS" to just "FUJITSU". This would explain why the fschmd driver wouldn't load automatically. I'll attach a patch shortly, which should make driver auto-loading work again.
Created attachment 26959 [details] Fix autoloading of fschmd on recent Fujitsu machines
Unfortunately I do not have access to the board D2778 right now. I will check this ASAP. Thank you for support.
Any news? I would like to push this fix into kernel 2.6.35, but it needs to be tested first.
Must I apply the patch from [1] to kernel 2.6.34, or is 2.6.31 also OK? [1] https://bugzilla.kernel.org/show_bug.cgi?id=15634#c14 I applied the patch to kernel 2.6.31 (Gentoo) with no effect. As before fschmd works if loaded even times and does not work if is loaded odd times.
My patch should apply fine to kernel 2.6.31. But maybe I haven't loosen the checks sufficiently, apparently there's some trailing space after the vendor string, maybe this explains why the patch didn't work. I'll attach a modified patch, which is more tolerant to string badness, and also prints a couple debugging messages so that we can track what happens if it still doesn't work. Please give it a try and report.
Created attachment 27041 [details] Fix autoloading of fschmd on recent Fujitsu machines (v2 with debug messages)
Created attachment 27042 [details] patch log Unfortunately I can not apply patch completely (look at the log file in attachment)
It's OK, the missing part of the patch will result in a warning about an unused variable, which you can safely ignore.
Yes, it works now. Thank you very much guys for your efforts and valuable support. Great job.
Fix committed upstream, closing. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=faabd47f7e3a36574abcdff0b3506abb092bbe24