Hi Jean, > The reject message explained that you shouldn't be sending HTML mails. > This makes your mails more than twice as big as they should, and that > explains the reject. Sorry, i'm not able to change it. I'm using just a freemail account. > Sounds like a bug in the driver then. Setting pwm1_enable to 0 should > turn the fan to full speed. Fixed, using new driver version lets the fan turn to full speed. > > I try to set limits in sensors.conf but i could see no change. > > You must run "sensors -s" after changing the limits > in /etc/sensors.conf for the new limits to be applied. Please test this, > this is a good way to test both the libsensors code you added, and the > driver itself. After using "sensors -s" i can see the limits i set in sensors.conf (e.g. "VCC: +1.72 V (min = +1.65 V, max = +1.85 V)"). But a inx_alarm is missing, so i see only the values. What would be a good value for the sensors.conf.eg entry e.g. set in0_min 1.72 * 0.95 set in0_max 1.72 * 1.05 ? > > > Lastly, you really shouldn't have to divide the values by 1000. This > > > suggests that the magnitude wasn't set properly in libsensors (it > > > should be 3, I suggest it is 0). This issue is most probably related to > > > the incorrect symbol names. > > > > I saw values >800V so i thought i have to divide it by 1000 in sensors.conf. > > Magnitude is 3 and the symbol name is correct now, but the values are still > > over 800V. What's the reason? > > I guess that's a bug in the driver. What values do you see in the > in*_input sysfs files? Fixed, if i use the new driver version i can see correct values (e.g. 1.72V). > > > This means that the driver isn't reporting the values in RPM as it > > > should. Usually no compute statement is needed for fans. > > > > That's correct, the value is not in RPM, in the document '2005111153128.pdf' you can download on the fintek page > > ( http://www.fintek.com.tw/eng/products.asp?BID=4&SID=5 )its written on page 8: > > "Determine the fan counter according to: > > Count = (1.5?10^6) / RPM " > > That means that the driver is reporting the count value, not the rpm. > > So i have to compute in sensors.conf: > > RPM = (1.5?10^6)/ Count > > Almost all chips do that, but that's not the point. Our sysfs-interface > standard says that the conversion to RPM must occur in the driver and > not in user-space. So the f75375 driver needs to be updated. Fixed, if i use the new driver version i can see correct values (e.g. 2329 RPM). > > > +#define SENSORS_F75373_FAN_FEATURES(nr) \ > > > + { { SENSORS_F75373_FAN(nr), "fan" #nr, \ > > > + NOMAP, NOMAP, R }, \ > > > + NOSYSCTL, VALUE(2), 0 }, \ > > > + { { SENSORS_F75373_FAN_MAX(nr), "fan" #nr "_max", \ > > > + SENSORS_F75373_FAN(nr), SENSORS_F75373_FAN(nr), RW }, \ > > > + NOSYSCTL, VALUE(1), 0 }, \ > > > > > > Strange, I've never seen a fan speed sensor with a high limit. What > > > does it correspond to exactly? Why don't you display this value in > > > "sensors"? > > > > I get the information out of the documentation on page 26: > > "When power on, the PWMOUT1 will output full duty cycle (FFh) to > > enable system FAN. After 10 seconds when detecting FANIN1 > > signal, assuming the fan has been fully turned on, the fan speed > > count detected will be recorded in the register.". > > Dunno if it should be removed? > > Oh, I see, it is recording the maximum possible speed. It should be > marked read-only then, I guess. I am also reluctant to naming this > feature fan1_max, even if we don't use that name yet, because the _max > suffix is only used for limits at the moment so it might be confusing > to use _max for something else now. Maybe fan1_full? This should be > discussed separately. In the meantime, I suggest that you omit this > value in libsensors. I have omited the fan1_max/_full part. > > > + { { SENSORS_F75373_FAN_MIN(nr), "fan" #nr "_min", \ > > > + SENSORS_F75373_FAN(nr), NOMAP, R }, \ > > > + NOSYSCTL, VALUE(1), 0 } > > > > > > SENSORS_F75373_FAN(nr) instead of NOMAP. > > > > > > Is it really read-only? > > > > I changed it to SENSORS_F75373_FAN(nr), it is RW. > > But fanX_min is allways zero, so it lead to an error on calling > > 'sensors_get_feature(*name, SENSORS_F75373_FAN_MIN(i), &min)', > > i have to disable it, sensors output is now > > CPU Fan: 1866 RPM (min = 0 RPM) > > to > > CPU Fan: 1866 RPM > > fan1_min = 0 isn't an error per se. If you see an error, then something > else must be wrong. Can you read the value from fan1_min directly from > sysfs? Yes, i read 0 directly from sysfs, but i can set another value, i've discussed it with Riku Voipio, the author of the driver, he said maybe my bios is setting it to zero. Should the fanx_min value be displayed using sensors (e.g. "CPU Fan: 1866 RPM (min = 4242 RPM)" ) ? > > > > I only copied it from SENSORS_DME1737_PWM_FEATURES, should i remove it? > > Ah, I hadn't noticed that the DME1737 had definitions for PWM. It's > more of an exception than the rule. So yes, please remove the PWM stuff. I deleted the PWM- stuff. > > > + if (valid) { > > > + print_label(label, 10); > > > + print_temp_info(cur, max, 0, HYST , 0, 0); > > > + printf("%s\n", alarm ? "ALARM" : ""); > > > + } > > > > > > This doesn't make sense. What is SENSORS_F75373_TEMP_HYST exactly? Why > > > do you display it as an alarm? > > > > It was a mistake, i deleted the Alarm output, now it is only printf("\n"), > > there seems not to be a value for an alarm. > > temp1_max_hyst is always zero, i don't now what it is exactly and > > when it is not zero. > > temp1_max_hyst is supposed to represent the hysteresis temperature > value for the temp1_max limit, and the value should be passed as the > 3rd argument to print_temp_info(). If it reads 0, maybe that's a driver > bug. Again, try reading the value directly from sysfs. And please > report the problems you find to the driver author so that he can fix > them. > tempx_max_hyst is always zero: <output> root at pc:/sys/devices/pci0000:00/0000:00:01.1/i2c-2/2-002d# cat temp1_max_hyst 0 </output> but i can set it by hand. It's now shown ( e.g. "CPU Temp: +47?C (high = +54?C, hyst = +41?C)" ). > > ERROR: Can't get feature `fan1_min' data! > > CPU PWM: 31.00 (pwm1) > > What's the reason? Did I still have to use "F75373"? > > I see. This suggests that the driver itself identifies the chip as > F75373, and that's not correct. You need to put "f75373" in sensors, > and the driver needs to be updated in the same way. Fixed in the driver. > > > Also, what about the F75375 support? As far as I know the f75375s > > > driver > > > supports both chips, so it'd be nice to have user-space support for > > > both. Also, it might be less confusing to use F75375 for all the > > > libsensors defines, rather than F75373, so that they match the driver > > > name. > > > > I changed every define/function from F75373 to F75375, i added also: > > #define SENSORS_F75373_PREFIX "f75373" > > #define SENSORS_F75375_PREFIX "f75375" > > and > > { SENSORS_F75375_PREFIX, f75375_features }, > > { SENSORS_F75373_PREFIX, f75375_features }, > > and > > { "F75375", print_f75375 }, > > { "F75373", print_f75375 }, > > Except for the leading capital, yes, it's OK. That being said, what's > the difference between the F75373 and the F75375? If the F75375 has > less inputs, then you'll need to adjust the code in "sensors" to not > try to display the missing inputs. Fixed i can now use f75375 & f75373. best regards christian. --------------------------------- Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yahoo! zu Ihrer Startseite! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070710/498236ce/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fintek_75373s_support_v3.patch Type: application/octet-stream Size: 7800 bytes Desc: pat943948581 Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070710/498236ce/attachment.obj
