Bug 15634 - mobo D2778: fschmd works only if it is loaded even times and does not work if is loaded odd times
mobo D2778: fschmd works only if it is loaded even times and does not work if...
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Hardware Monitoring
All Linux
: P1 normal
Assigned To: Jean Delvare
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-26 13:40 UTC by Sergey Spiridonov
Modified: 2010-07-19 07:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.30, 2.6.31
Tree: Mainline
Regression: No


Attachments
output of dmidecode on 2.6.31 (21.59 KB, text/plain)
2010-04-19 12:56 UTC, Sergey Spiridonov
Details
Fix autoloading of fschmd on recent Fujitsu machines (1.51 KB, patch)
2010-06-27 07:47 UTC, Jean Delvare
Details | Diff
Fix autoloading of fschmd on recent Fujitsu machines (v2 with debug messages) (2.48 KB, patch)
2010-07-08 14:05 UTC, Jean Delvare
Details | Diff
patch log (1.42 KB, text/plain)
2010-07-08 15:04 UTC, Sergey Spiridonov
Details

Description Sergey Spiridonov 2010-03-26 13:40:18 UTC
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.
Comment 1 Rainer Koenig 2010-03-31 10:53:57 UTC
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
Comment 2 Sergey Spiridonov 2010-03-31 12:10:57 UTC
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."
Comment 3 Rainer Koenig 2010-03-31 13:40:57 UTC
Hi Sergey,

that's why I (copy&paste)'d that comment form Red Hats bugzilla. :-)

Regards
Rainer
Comment 4 Jean Delvare 2010-04-07 09:56:32 UTC
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.
Comment 5 Hans de Goede 2010-04-07 10:17:38 UTC
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
Comment 6 Jean Delvare 2010-04-16 09:42:19 UTC
Sergey, any progress on this? Did you try Hans' suggestion?
Comment 7 Sergey Spiridonov 2010-04-19 12:48:46 UTC
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.
Comment 8 Sergey Spiridonov 2010-04-19 12:56:52 UTC
Created attachment 26049 [details]
output of dmidecode on 2.6.31
Comment 9 Hans de Goede 2010-04-19 14:01:07 UTC
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
Comment 10 Jean Delvare 2010-04-19 14:21:16 UTC
Hans, yes, the kernel supports strcasecmp().
Comment 11 Sergey Spiridonov 2010-04-19 14:51:42 UTC
I modified i2c-i801.c as proposed and recompiled kernel-2.6.31. fschmd is not loaded automatically and original problem still exist.
Comment 12 Hans de Goede 2010-04-20 11:46:18 UTC
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.
Comment 13 Jean Delvare 2010-06-27 07:25:18 UTC
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.
Comment 14 Jean Delvare 2010-06-27 07:47:56 UTC
Created attachment 26959 [details]
Fix autoloading of fschmd on recent Fujitsu machines
Comment 15 Sergey Spiridonov 2010-06-28 09:34:49 UTC
Unfortunately I do not have access to the board D2778 right now. I will check this ASAP. Thank you for support.
Comment 16 Jean Delvare 2010-07-07 13:02:25 UTC
Any news? I would like to push this fix into kernel 2.6.35, but it needs to be tested first.
Comment 17 Sergey Spiridonov 2010-07-08 11:47:44 UTC
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.
Comment 18 Jean Delvare 2010-07-08 14:02:43 UTC
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.
Comment 19 Jean Delvare 2010-07-08 14:05:03 UTC
Created attachment 27041 [details]
Fix autoloading of fschmd on recent Fujitsu machines (v2 with debug messages)
Comment 20 Sergey Spiridonov 2010-07-08 15:04:27 UTC
Created attachment 27042 [details]
patch log

Unfortunately I can not apply patch completely (look at the log file in attachment)
Comment 21 Jean Delvare 2010-07-08 15:22:30 UTC
It's OK, the missing part of the patch will result in a warning about an unused variable, which you can safely ignore.
Comment 22 Sergey Spiridonov 2010-07-08 15:58:45 UTC
Yes, it works now. Thank you very much guys for your efforts and valuable support. Great job.

Note You need to log in before you can comment on or make changes to this bug.