<oops one more time this time with attachment> Hi All, Stefan, As already mentioned in various post to the lm-sensors mailing list, the fscher and fscpos chip are very very similar, this patch adds support for the fscpos chip to the fscher driver, so that over time the fscpos driver can be dropped. Notice that this patch applies on top of the earlier posted max alarms patch for the fscher: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020301.html Stefan, Jean told me that you ported the fscpos driver from 2.4 to 2.6, kan you test if the fscher driver with this patch will also work correctly on your fscpos machine (according to the datasheets it should). I would like to ask you specifically to test the tempX_max attributes, try something like: cat /sys/class/hwmon/hwmon0/device/temp1_max That should give you a reasonable max temperature, on my machine it defaults to 77. This needs testing as I reverse engineered the tempX_max registers on my machine and I hope they are identically on yours. We need them to be able to reset the temp alarms once the alarm condition is cleared, as the chip doesn't do this itself. If the temp1_max look ok try: sudo su -c "echo -n 22000 > /sys/class/hwmon/hwmon0/device/temp1_max" And then wait 5 seconds and: cat /sys/class/hwmon/hwmon0/device/temp1_alarm It should be 1 now. Now put temp1_max back: sudo su -c "echo -n 77000 > /sys/class/hwmon/hwmon0/device/temp1_max" wait 2 seconds and then: cat /sys/class/hwmon/hwmon0/device/temp1_alarm This time is should still be one, but the read should have cleared the alarm, so again: cat /sys/class/hwmon/hwmon0/device/temp1_alarm It should be 0 now. Many thanks for testing! Regards, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: hwmon-fscher-support-fscpos.patch Type: text/x-patch Size: 7726 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070709/646d3092/attachment.bin
