FSCSCY chip with linux 2.6 kernel not working

[ticket]

I'm trying to get the FSC Scylla chip working on my Debian Etch server (FSC Primergy P250). My current kernel version is 2.6.18.5-vs2.0.3-rc1.

I took the trunk of the lm-sensors package today and compiled the package using the instructions make user, make user_install. Afterwards I used sensors-detect utility to get the needed configuration but still "modprobe fscscy" fails with module not found.

Do you have a howto document for getting this chip working on my server? I looks like the fscscy.c file has not been ported to 2.6 kernel yet.

Best Regards, Martin Kugler

[jwrdegoede]

Hi Martin,

I've recently been working on improving the fscher and fscpos drivers. Currently my plan is to write a new fscxxx driver for the 2.6 kernel supporting both the fscpos, the fscher and the fscscy chip. Would you be interested in testing the fscscy support of this driver? I only have access to an fscher equiped machine myself.

Thanks & Regards,

Hans

[ticket]

Hello Hans,

yes, I'm very interested in testing this driver. I've tried to port the fscscy driver to the 2.6 kernel by my self using the fscpos source and the chip definitions of the old fscscy driver. But I only got the fan speed working.

Regards, Martin

[jwrdegoede]

Makefile for the driver

[jwrdegoede]

I've just finished the driver, I would be much obliged if you could test this.

To test drop the attached fscscy.c and Makefile in a dir, type make and then insmod fscscy.ko

The easiest way to then read the settings is by using the 3.0 sensors branch, which comes with dyn chipsupport: remove your current lm-sensors userspace package (for example on Fedora do rpm -e lm_sensors --nodeps) svn checkout http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0 cd lm-sensors-3.0.0 make sudo make install sudo ldconfig

lm_sensors-2.x will not work, and probably do funky things as it expects the old very different 2.4 fscscy driver.

Note 1: I have not been able to test this driver myself as I currently do not have access to the fscher equiped machine I was using, I will get access to that again in a few weeks, but for now I just hope this works.

Note 2: I will be away on vacation for 6 days starting coming monday, so I will be reading my mail tomorrow (Sunday) and maybe monday morning and then things will go quiet for 6 days.

[ticket]

After installing driver and using sensors3 for getting fan data I got the following result:

gandalf:~# sensors3
fscscy-i2c-0-73
Adapter: SMBus PIIX4 adapter at f100
in0:        +11.36 V
in1:         +4.97 V
in2:         +3.16 V
Fan1/CPU0:     0 RPM  (div = 2)
Fan2/CPU0:  4920 RPM  (div = 2)
Fan3:       3000 RPM  (div = 2)
Fan4:          0 RPM  (div = 1)
Fan5:          0 RPM  (div = 1)
Fan6:          0 RPM  (div = 1)
Temp1/CPU0:  +38.0°C  (high = +77.0°C)
Temp2/CPU1:  +35.0°C  (high = +75.0°C)
Temp3/MB:    +28.0°C  (high = +40.0°C) 

My machine is equipped with two CPUs and both fan panels. Therefore I think there is still a problem reading fan details.

[jwrdegoede]

New 2.6 kernel FSC Scylla driver

[jwrdegoede]

Ah yes, I discoverd a small but nasty bug in the driver yesterday, that explains why not all your fans are getting read, I've just attached a new version (replacing the old attachment), please try that, Note after this mail I'll really be away for 5 days :)

[ticket]

This is my result now:

gandalf:~# sensors3
fscscy-i2c-0-73
Adapter: SMBus PIIX4 adapter at f100
+12V:       +11.36 V
+5V:         +4.97 V
+3.3V:       +3.14 V
CPU1 Fan1:  4860 RPM  (div = 2)
CPU2 Fan1:  5040 RPM  (div = 2)
Fan3:          0 RPM  (div = 2)
Fan4:       3000 RPM  (div = 2)
Fan5:          0 RPM  (div = 2)
Fan6:       3000 RPM  (div = 1)
Temp1/CPU0:  +37.0°C  (high = +77.0°C)
Temp2/CPU1:  +44.0°C  (high = +75.0°C)
Temp3/MB:    +35.0°C  (high = +40.0°C)
Temp4/AUX:   +26.0°C  (high = +40.0°C)

But I've a problem with fan 3 to 6 because they don't change and the plug in or removal of a fan bay has no effect on the results at all. Do you know which fans in my server have 3000 rpm? An other thing is how to make sensors3 show the min and max values? The munin plugin regular expression expects these values for parsing the result.

[jwrdegoede]

Hmm,

I'm afraid this really is the best I can do as Siemens cannot provide a datasheet for this chip (according to my sources, siemens doesn't even have a datasheet for this chip).

Still lets see if we can do better, first of all I have a hunch that there might be an error in the register definitions of the 2.4 driver which I used, you could try changing line 87 of the driver from:

{ 0x6b, 0x6c, 0x0e, 0xab, 0x5c, 0xbb }, /* scy */

to:

{ 0x6b, 0x6c, 0x0e, 0xab, 0x5b, 0xbb }, /* scy */

(change 0x5c into 0x5b) this is just a hunch though, not sure at all.

Also we could try to find out the real addresses of the fan registers for the panel fans (if these are monitored at all) by some "reverse engineering" can you try these commands: rmmod fscscy modprobe i2c-dev i2cdump -y 0 0x73

And then try to change the fan speeds by slowing them down and repeat the last command.

[ticket]

I did a lot of tests now but did not manage to get the two fan bays working. In the mainboard description only the two CPU fans and the two fan bays are connected. Therefore it could be possible that the last two fans are 0 by design. But removing the bays or slowing them down did not make any change in the RPM value. This is the hex dump with only bay one attached:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 53 43 59 40 04 00 0c 00 00 00 00 00 00 08 00 01    SCY@?.?......?.?
10: 00 00 00 c0 00 00 00 00 00 00 fc 00 00 00 00 00    ...?......?.....
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 a5 00 00 9c 00 00 00 00 00 00 00 00 00 00    ..?..?..........
40: 00 00 c0 00 00 cb 00 00 f3 00 00 00 00 00 00 00    ..?..?..?.......
50: 00 00 08 04 00 3c 48 49 00 00 0b 00 00 00 00 00    ..??.<HI..?.....
60: 00 00 00 00 ab ff 7b 35 00 00 00 51 54 00 00 01    ....?.{5...QT..?
70: 00 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    .?.????.........
80: 00 01 00 a2 16 00 e4 00 00 00 00 00 00 00 00 00    .?.??.?.........
90: 00 01 00 9a 17 00 b2 00 00 00 00 00 00 00 00 00    .?.??.?.........
a0: 00 00 00 04 00 01 7b 35 00 00 00 32 00 00 00 01    ...?.?{5...2...?
b0: 00 00 00 00 00 00 00 00 00 00 00 32 00 00 00 00    ...........2....
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: a7 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    ??.????.........
e0: 9c 01 00 9a 17 00 ff 00 00 00 00 00 00 00 00 00    ??.??...........
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................ 

This is the result with both fan bays:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 53 43 59 40 04 00 0c 00 00 00 00 00 00 08 00 01    SCY@?.?......?.?
10: 00 00 00 c0 00 00 00 00 00 00 fc 00 00 00 00 00    ...?......?.....
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 a5 00 00 9c 00 00 00 00 00 00 00 00 00 00    ..?..?..........
40: 00 00 c0 00 00 cc 00 00 f3 00 00 00 00 00 00 00    ..?..?..?.......
50: 00 00 08 04 00 3c 48 49 00 00 0b 00 00 00 00 00    ..??.<HI..?.....
60: 00 00 00 00 a7 ff 7b 35 00 00 00 52 53 00 00 01    ....?.{5...RS..?
70: 00 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    .?.????.........
80: 00 01 00 a2 16 00 e4 00 00 00 00 00 00 00 00 00    .?.??.?.........
90: 00 01 00 9a 17 00 b2 00 00 00 00 00 00 00 00 00    .?.??.?.........
a0: 00 00 00 04 00 01 7b 35 00 00 00 32 00 00 00 01    ...?.?{5...2...?
b0: 00 00 00 00 00 00 00 00 00 00 00 32 00 00 00 00    ...........2....
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: a6 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    ??.????.........
e0: 9c 01 00 9a 17 00 ff 00 00 00 00 00 00 00 00 00    ??.??...........
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................ 

And this the result with only the onther bay:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 53 43 59 40 05 00 0c 00 00 00 00 00 00 08 00 01    SCY@?.?......?.?
10: 00 00 00 c0 00 00 00 00 00 00 fc 00 00 00 00 00    ...?......?.....
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 9d 00 00 9c 00 00 00 00 00 00 00 00 00 00    ..?..?..........
40: 00 00 c0 00 00 cc 00 00 f3 00 00 00 00 00 00 00    ..?..?..?.......
50: 00 00 08 04 00 3c 48 49 00 00 0b 00 00 00 00 00    ..??.<HI..?.....
60: 00 04 00 00 9f ff 7b 35 00 00 00 51 52 00 00 01    .?..?.{5...QR..?
70: 00 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    .?.????.........
80: 00 01 00 a2 16 00 e4 00 00 00 00 00 00 00 00 00    .?.??.?.........
90: 00 01 00 9a 17 00 b2 00 00 00 00 00 00 00 00 00    .?.??.?.........
a0: 00 00 00 04 00 01 7b 35 00 00 00 32 00 00 00 01    ...?.?{5...2...?
b0: 00 00 00 00 00 00 00 00 00 00 00 32 00 00 00 00    ...........2....
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: a0 01 00 b1 11 cb e4 00 00 00 00 00 00 00 00 00    ??.????.........
e0: 9c 01 00 9a 17 00 ff 00 00 00 00 00 00 00 00 00    ??.??...........
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................ 

The sensors3 print out without the changes to do in last comment!

fscscy-i2c-0-73
Adapter: SMBus PIIX4 adapter at f100
+12V:       +11.36 V
+5V:         +4.97 V
+3.3V:       +3.14 V
CPU1 Fan1:  4860 RPM  (div = 2)
CPU2 Fan1:  5040 RPM  (div = 2)
Fan3:          0 RPM  (div = 2)
Fan4:       3000 RPM  (div = 2)
Fan5:          0 RPM  (div = 2)
Fan6:       3000 RPM  (div = 1)
Temp1/CPU0:  +36.0°C  (high = +100.0°C)
Temp2/CPU1:  +36.0°C  (high = +100.0°C)
Temp3/MB:    +34.0°C  (high = +100.0°C)
Temp4/AUX:   +27.0°C  (high = +50.0°C) 

The module itself is now working more than two weeks very good. The CPU alarm feature is working. Stopping the fan maks the alarm occur. After next sensors read out the alarm is released. I attach the week munin graphs to this ticket.

[ticket]

fan details by week

[ticket]

temperature by week

[ticket]

voltages by week

[jwrdegoede]

Interesting, in the "only the other bay" chip dump, register 0x61 (second fan status register) is changed from 0x00 to 0x04 (fan fault)

Also the status registers 0x0d and 0x52 contain status 0x08 (undocumented status), this are the status registers for fan 3 and fan 5

Last the readings of 3000 seems to be wrong (to stable / different dividers)

Maybe the chip needs some additional initialization, maybe you can activate monitoring for the fan bays in the bios? Does the bios contain sensor readings? And ifso how many fans?

Maybe you can try to change the 0x08 status at 0x0d and 0x52, try this:

rmmod fscscy

modprobe i2c-dev

i2cset -y 0 0x73 0x0d 0x08

i2cset -y 0 0x73 0x52 0x08

i2cdump -y 0 0x73

And the check if the 0x08 has been cleared (the fsc chips often use write to clear), if not try:

i2cset -y 0 0x73 0x0d 0x00

i2cset -y 0 0x73 0x52 0x00

i2cdump -y 0 0x73

If one of the 2 above clears the 0x08 at 0x0d and/or 0x52, try insmodding the driver again and running sensors again.

Thanks!

[ticket]

I was not able to do a reboot up to now for checking monitoring settings in bios.

I tried both ways resetting the status but this had no effect and the result stays 0x08. I will report the bios details mid of next week.

[jwrdegoede]

I've just posted a new version of the driver to the list, there are no changes affecting the Scylla, still it would be nice if you could this a spin. Note its renamed to fschmd now as the fscscy name was giving problems because it was already used in the past.

[jwrdegoede]

Makefile for compiling fschmd.c

[ticket]

One thing regarding the naming. You want to compile a file fschmd.c within your Makefile but the file you have uploaded has the name fscmod.c. Which name doo you want to use because the driver itself after insmod calls itself fschmd-...

[jwrdegoede]

Erm,

The driver and the file are called fschmd, I don't know where you got fscmod.c from, I don't see a file with that name attached here.

[ticket]

Sorry, it was a problem within my wget command downloading your file. But it is working fine now and I think I will manage to check bios settings next week end.

Are there any tests I should do concerning stability, usability, etc that a necessary before it will be added to the package?

[jwrdegoede]

Replying to ticket:

Are there any tests I should do concerning stability, usability, etc that a > necessary before it will be added to the package?

No, the plan is to move forward with this driver as time permits (and depend upon finding a reviewer). If possible I would like to verify that the fscscy readings are correct, but I don't expect there to be any stability issues.

[jwrdegoede]

fschmd.c, which supports this chip has been merged into the mainline kernel now, and is supported in the 2.10.x and 3.x.x lm_sensors series, closing.

I do have a patch lying around which adds support for the reporting of psu status, which needs testing on an actual fscscy (canot be tested on a fscher as I have), let me know if you're willing to test this.

[ticket]

Thank you for integrating it. I'm using this patch since you added it to this ticket and it is working fine. Of course I'm willing to test your PSU status patch. Please provide the patch and a short manual within this issue. What additional information does this patch provide?

[jwrdegoede]

New fschmd.c with powersupply status support

[jwrdegoede]

Replying to ticket:

Thank you for integrating it. I'm using this patch since you added it to this ticket and it is working fine. Of course I'm willing to test your PSU status patch. Please provide the patch and a short manual within this issue. What additional information does this patch provide?

Thanks!

I've just attached a new fschmd.c, save both fschmd.c and Makefile.2 (as Makefile) into a dir, then in this dir do: make sudo rmmod fschmd sudo insmod fschmd

Once loaded, you should get a powersupply dir under /sys/class with in there 2 0-0073.x dirs, one for each of 2 powersupplies that the fscscy can monitor.

You could then read out the status by doing: cat /sys/class/power_supply/0-0073.0/present cat /sys/class/power_supply/0-0073.0/health

cat /sys/class/power_supply/0-0073.1/present cat /sys/class/power_supply/0-0073.1/health

If you're system actually has 2 powersupplies, it would be nice to see if the present bit actually works, iow if you remove one if it goes to 0.

As for the health, with a powersupply present and working it should give some text string indication the psu is fine

[ticket]

I get the following error trying to compile your code:

/usr/src/lm-sensors/fschmd/fschmd.c: In function ‘fschmd_detach_client’:
/usr/src/lm-sensors/fschmd/fschmd.c:695: warning: passing argument 1 of ‘hwmon_device_unregister’ from incompatible pointer type
/usr/src/lm-sensors/fschmd/fschmd.c: At top level:
/usr/src/lm-sensors/fschmd/fschmd.c:802: warning: ‘union power_supply_propval’ declared inside parameter list
/usr/src/lm-sensors/fschmd/fschmd.c:802: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/src/lm-sensors/fschmd/fschmd.c:802: warning: ‘enum power_supply_property’ declared inside parameter list
/usr/src/lm-sensors/fschmd/fschmd.c:802: error: parameter 2 (‘psp’) has incomplete type
/usr/src/lm-sensors/fschmd/fschmd.c: In function ‘fschmd_power_supply_get_property’:
/usr/src/lm-sensors/fschmd/fschmd.c:805: warning: type defaults to ‘int’ in declaration of ‘__mptr’
/usr/src/lm-sensors/fschmd/fschmd.c:805: warning: initialization from incompatible pointer type
/usr/src/lm-sensors/fschmd/fschmd.c:810: error: ‘POWER_SUPPLY_PROP_HEALTH’ undeclared (first use in this function)
/usr/src/lm-sensors/fschmd/fschmd.c:810: error: (Each undeclared identifier is reported only once
/usr/src/lm-sensors/fschmd/fschmd.c:810: error: for each function it appears in.)
/usr/src/lm-sensors/fschmd/fschmd.c:812: error: dereferencing pointer to incomplete type
/usr/src/lm-sensors/fschmd/fschmd.c:812: error: ‘POWER_SUPPLY_HEALTH_GOOD’ undeclared (first use in this function)
/usr/src/lm-sensors/fschmd/fschmd.c:814: error: dereferencing pointer to incomplete type
/usr/src/lm-sensors/fschmd/fschmd.c:814: error: ‘POWER_SUPPLY_HEALTH_UNSPEC_FAILURE’ undeclared (first use in this function)
/usr/src/lm-sensors/fschmd/fschmd.c:816: error: ‘POWER_SUPPLY_PROP_PRESENT’ undeclared (first use in this function)
/usr/src/lm-sensors/fschmd/fschmd.c:818: error: dereferencing pointer to incomplete type
/usr/src/lm-sensors/fschmd/fschmd.c:820: error: dereferencing pointer to incomplete type
/usr/src/lm-sensors/fschmd/fschmd.c: At top level:
/usr/src/lm-sensors/fschmd/fschmd.c:829: error: array type has incomplete element type
/usr/src/lm-sensors/fschmd/fschmd.c:830: error: ‘POWER_SUPPLY_PROP_HEALTH’ undeclared here (not in a function)
/usr/src/lm-sensors/fschmd/fschmd.c:831: error: ‘POWER_SUPPLY_PROP_PRESENT’ undeclared here (not in a function)
/usr/src/lm-sensors/fschmd/fschmd.c: In function ‘fschmd_register_power_supply’:
/usr/src/lm-sensors/fschmd/fschmd.c:848: error: ‘POWER_SUPPLY_TYPE_MAINS’ undeclared (first use in this function)
/usr/src/lm-sensors/fschmd/fschmd.c:851: warning: type defaults to ‘int’ in declaration of ‘type name’
/usr/src/lm-sensors/fschmd/fschmd.c:851: warning: type defaults to ‘int’ in declaration of ‘type name’
/usr/src/lm-sensors/fschmd/fschmd.c:851: error: size of array ‘type name’ is negative
/usr/src/lm-sensors/fschmd/fschmd.c:855: warning: implicit declaration of function ‘power_supply_register’
/usr/src/lm-sensors/fschmd/fschmd.c:866: warning: implicit declaration of function ‘power_supply_unregister’
make[2]: *** [/usr/src/lm-sensors/fschmd/fschmd.o] Fehler 1
make[1]: *** [_module_/usr/src/lm-sensors/fschmd] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.22.16'
make: *** [all] Fehler 2

[jwrdegoede]

I'm afraid thats because your kernel is too old, the new powersupply class interface which this update to the driver uses is pretty new, I think you need atleast 2.6.24

[ticket]

I'm using linux vserver ( http://www.linux-vserver.org) on my server. The latest patch is for the 2.6.22.19 kernel. So I need to wait until a new version will be released to test the new module.

[jwrdegoede]

Replying to ticket:

I'm using linux vserver ( http://www.linux-vserver.org) on my server. The latest patch is for the 2.6.22.19 kernel. So I need to wait until a new version will be released to test the new module.

Ok,

Guess we will just have to wait then, thanks for your efforts so far.

[jwrdegoede]

I just realized that in order to get the info I need to be able to finalize my psu status support patch for the fscscy I don't need you to build the new driver.

Just running the following commands should give me enough info: rmmod fscscy modprobe i2c-dev i2cdump -y 0 0x73

You've also done so in the past (see earlier comments in this tickets), but the results do not match the info I've received from Siemens, if I interpret your dumps according to that info, you don't have any powersupply's installed, which makes doing the dump sort of hard.

So what I could _really_ use, but fully understand if you don't want to / can't do, is for you to remove one psu (the machine has 2 right?) and then run these commands: rmmod fscscy modprobe i2c-dev i2cdump -y 0 0x73

You may remove the psu using coldplugging (so turn of, remove psu, boot with one psu) if that makes you feel more comfortable, that should not be relevant for the results.

Thanks!