> > My bad, fixed in the attached version. Can you please try again? (No > > need rebooting this time, just unload the old module and load the > > new one instead.) > > problem solved ... Great. > > > btw: speed of fan can show lm_sensors with ne1619 too? > > > > Negative on that, it's a 6-voltage 2-temperature chip, period. No > > fan monitoring. I'm surprised too, but that's how it it. > > I'm not sure if I understand you. Intel sw can show fan speed, e.g. > Sensor Name System Fan 1 > Current Value 3 840 > Upper Threshold not applicable > Lower Threshold 500. > > Current driver cannot show that or something else? Not the driver, but the *chipset* doesn't even know about them. Don't hit me! I'm only the messenger ;) Intel must get their information from somewhere else. Possibilities are: another bus driver we don't support yet (unlikely), another chip on the first bus (unlikely again, the only unknown one is that thing at 0x44 and I still believe it looks like an EEPROM; I could be wrong of course; does the fan speed value sometimes change with that Linux software? if yes the data at 0x44 would have to move the same way too, and you say it didn't) or non-I2C chip (could be ACPI; is your system ACPI-compliant? did you ever try enabling ACPI in your kernel, using the bug ACPI patch?) > btw: > > hippopotamus:/proc/sys/dev/sensors/adm1025-i2c-0-2d# ls > alarms in0 in1 in2 in3 in4 in5 temp1 temp1 temp2 vid vrm > hippopotamus:/proc/sys/dev/sensors/adm1025-i2c-0-2d# cat temp1 > cat: temp1: nen? adres??em (= temp1 in't directory ...) > temp2 is normal proc file with values ... there are two files "temp1" > in this directory, but i didn't reboot ... I think I remember something similar some times ago (see: http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1185) but it is supposed to be fixed. Just in case, is any part of the I2C subsystem or device drivers hard-compiled into your kernel? > (later) this problem solved reboot system ... sorry for useless > messages :o( Not useless at all. I don't like the idea you had to reboot your system to get rid of the problem. Didn't you forget to unload the old module before reloading the new one? I'd like you to try unloading the adm1025 module, and check in /proc if the entries have really gone. Then reload it and check if the entries are back for good, and one of each kind only. If you can reproduce the problem, we'll try to fix it. > adm1025-i2c-0-2d > Adapter: SMBus I801 adapter at efa0 > Algorithm: Non-I2C SMBus adapter > +2.5V: +2.48 V (min = +2.23 V, max = +2.74 V) > VCore: +1.46 V (min = +1.40 V, max = +1.55 V) > +3.3V: +3.33 V (min = +2.95 V, max = +3.62 V) > +5V: +5.02 V (min = +4.47 V, max = +5.49 V) > +12V: +0.00 V (min = +10.75 V, max = +13.18 V) > VCC: +3.26 V (min = +2.95 V, max = +3.62 V) > SYS Temp: +43.0?C (min = +0?C, max = +60?C) > CPU Temp: +42.0?C (min = +0?C, max = +60?C) > vid: +1.50 V The limits are still a bit too low, probably a common rounding issue, I'll take a look at it tomorrow (and probably ask you to test then, if you don't mind). -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
