Hello,
I'm trying to get serveral lm_sensor versions up to CVS lm_sensors2 from
yesterday to run on this mb. Now, I'm at linux-2.4.15-pre4, but also tried
some 2.4.12(-ac?) versions, to no avail.
sensors-detect says:
We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-amd756' for device 00:07.3: AMD-766 Athlon ACPI
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-amd756' already loaded.
Do you now want to be prompted for non-detectable adapters? (yes/NO):
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang halfway
through; we can't really help that. Also, some chips will be double detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you can
specify that address to remain unprobed. That often
includes address 0x69 (clock chip).
Next adapter: SMBus AMD7X6 adapter at 80e0 (Non-I2C SMBus adapter)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F'... Failed!
Client found at address 0x2d
Probing for `Myson MTP008'... Failed!
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `National Semiconductor LM80'... Failed!
Probing for `National Semiconductor LM87'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Success!
(confidence 8, driver `w83781d'), other addresses: 0x48 0x49
[eeprom stuff removed]
Probed modules:
# I2C adapter drivers
modprobe i2c-amd756
# I2C chip drivers
modprobe w83781d <---- FREEZE
kernel log during sensors-detect:
Nov 14 17:28:33 tyrex kernel: i2c-core.o: i2c core module
Nov 14 17:28:33 tyrex kernel: i2c-amd756.o version 2.6.1 (20010830)
Nov 14 17:28:33 tyrex kernel: i2c-core.o: adapter SMBus AMD7X6 adapter at
80e0 registered
as adapter 0.
Nov 14 17:28:33 tyrex kernel: i2c-amd756.o: AMD756/766 bus detected and
initialized
Nov 14 17:28:38 tyrex kernel: i2c-dev.o: i2c /dev entries driver module
Nov 14 17:28:38 tyrex kernel: i2c-core.o: driver i2c-dev dummy driver
registered.
Nov 14 17:28:38 tyrex kernel: i2c-dev.o: Registered 'SMBus AMD7X6 adapter at
80e0' as minor 0
Nov 14 17:28:49 tyrex kernel: i2c-amd756.o: SMBus collision!
Nov 14 17:28:49 tyrex last message repeated 3 times
Any suggestions?
Hans-Peter
On Wed, 14 Nov 2001, Hans-Peter Jansen wrote:
> I'm trying to get serveral lm_sensor versions up to CVS lm_sensors2 from
> yesterday to run on this mb. Now, I'm at linux-2.4.15-pre4, but also tried
> some 2.4.12(-ac?) versions, to no avail.
Known bug in w83781d driver.
http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=697
The fix at the bottom works for me.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
hi all,
i know this is gonna be the lamest question of the year, but i didn't found
a valid answer elsewhere !
I'm using linux as a sysadmin since slack 3.1, and i've subscribed to this
list about 2 month ago. I'm not a developer, i don't have the knowledge, but
i like to watch at all of your e-mails since it makes me feel like i'm
really following the growing of the penguin ! Only now i discovered that
there're 2 trees, the Alans' and the Linus' (here in alphabetical order :-),
and in these days i saw Linus saying that 2.4.15 is ready to be the result
of a merge between the two trees. Now, i wonder if merging the 2 trees is an
usual thing, so it would be happened also with 2.2 and 2.0 (thing that i
can't knew, since at that time i wasn't subscribed to LKML), or if i'm
taking part of a kind of an historycal event, i.e. the fusion of the 2
kernel trees.
tnx for your answer,
have a nice day!
Giorgio A.
"in girum imus nocte
et consumimur igni"
Hi, same question,
running 2.4.14-pre5aa1,
100% no problems on 4 machines.
2.4.14 problems (OK for loop.c)
2.4.15-pre# all with problems, see lkml!
Mario, _not_ in this list.
On Wed, Nov 14, 2001 at 09:32:34PM +0100, Giorgio A. wrote:
> hi all,
> i know this is gonna be the lamest question of the year, but i didn't found
> a valid answer elsewhere !
> I'm using linux as a sysadmin since slack 3.1, and i've subscribed to this
I started back when 2.0.35 was the latest stable. I think slack was 3.5
then...
> list about 2 month ago. I'm not a developer, i don't have the knowledge, but
> i like to watch at all of your e-mails since it makes me feel like i'm
> really following the growing of the penguin !
Yep. You can be very helpful with testing of patches, and documentation
patches...
>Only now i discovered that
> there're 2 trees, the Alans' and the Linus' (here in alphabetical order :-),
> and in these days i saw Linus saying that 2.4.15 is ready to be the result
> of a merge between the two trees.
Not really. Alan has been handling the "almost ready for merging" patches
for a while now. Linus has particular requirements for the patches he
accepts, and Alan helps feed Linus patches the way he likes them.
This has been going on for several years now.
>Now, i wonder if merging the 2 trees is an
> usual thing, so it would be happened also with 2.2 and 2.0 (thing that i
> can't knew, since at that time i wasn't subscribed to LKML), or if i'm
> taking part of a kind of an historycal event, i.e. the fusion of the 2
> kernel trees.
Don't know when 2.2 was placed in Alan's hands. Know even less about 2.0...
Mike
On Wednesday, 14. November 2001 19:04, Hans-Peter Jansen wrote:
> Hello,
>
> I'm trying to get serveral lm_sensor versions up to CVS lm_sensors2 from
> yesterday to run on this mb. Now, I'm at linux-2.4.15-pre4, but also tried
> some 2.4.12(-ac?) versions, to no avail.
I finally managed to get the w83781d loading under 2.4.13-ac7. (b/c it's butt
kicking processor power)
But it's readings are bogus <BIOS>:
tyrex:~# sensors
w83782d-i2c-0-2d
Adapter: SMBus AMD7X6 adapter at 80e0
Algorithm: Non-I2C SMBus adapter
VCore 1: +1.72 V (min = +1.74 V, max = +1.93 V) ALARM <1.75>
VCore 2: +2.83 V (min = +1.74 V, max = +1.93 V) <1.76>
+3.3V: +3.32 V (min = +3.13 V, max = +3.45 V)
+5V: +4.89 V (min = +4.72 V, max = +5.24 V) <5.11>
+12V: +4.67 V (min = +10.79 V, max = +13.19 V) <12.35>
-12V: -2.01 V (min = -10.90 V, max = -13.21 V) <-12.15>
-5V: +2.71 V (min = -4.76 V, max = -5.26 V)
V5SB: +4.32 V (min = +4.72 V, max = +5.24 V)
VBat: +3.29 V (min = +2.40 V, max = +3.60 V)
fan1: 7180 RPM (min = 3000 RPM, div = 2) <3590>
fan2: 7105 RPM (min = 3000 RPM, div = 2) <3515>
fan3: 0 RPM (min = 3000 RPM, div = 2)
temp1: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
<46?C>
temp2: +76.5?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
<41?C>
temp3: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
<46?C>
vid: +1.85 V
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
ALARM flags seems to appear randomly and unrelated to error conditions.
Do I need completely new formula's for that beast?
Any further suggestions?
Cheers,
Hans-Peter
On Wed, 14 Nov 2001, Hans-Peter Jansen wrote:
> fan1: 7180 RPM (min = 3000 RPM, div = 2) <3590>
> fan2: 7105 RPM (min = 3000 RPM, div = 2) <3515>
Fan divisor is wrong.
adjust /proc/sys/dev/sensors/w83782d-i2c-0-2d/fan_div as needed.
> temp1: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
> <46?C>
> temp2: +76.5?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
> <41?C>
> temp3: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor = thermistor
> <46?C>
thermistor type is wrong.
echo "2" > /proc/sys/dev/sensors/w83782d-i2c-0-2d/sensor{1..3}
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
Dan, thanks, for your ultimate help on this topic.
On Thursday, 15. November 2001 03:50, Dan Hollis wrote:
> On Wed, 14 Nov 2001, Hans-Peter Jansen wrote:
> > fan1: 7180 RPM (min = 3000 RPM, div = 2)
> > <3590> fan2: 7105 RPM (min = 3000 RPM, div = 2)
> > <3515>
>
> Fan divisor is wrong.
> adjust /proc/sys/dev/sensors/w83782d-i2c-0-2d/fan_div as needed.
ok, then
tyrex:~# echo "4 4 4" > /proc/sys/dev/sensors/w83782d-i2c-0-2d/fan_div
tyrex:~# sensors | egrep ^fan
fan1: 6887 RPM (min = 1500 RPM, div = 4)
fan2: 7031 RPM (min = 1500 RPM, div = 4)
tyrex:~# echo "1 1 1" > /proc/sys/dev/sensors/w83782d-i2c-0-2d/fan_div
tyrex:~# sensors | egrep ^fan
fan1: 7142 RPM (min = 6000 RPM, div = 1)
fan2: 6716 RPM (min = 6000 RPM, div = 1)
Is adjusting the min value the intended behaviour?
I also tried this in /etc/sensors.conf:
set fan1_div 4
set fan2_div 4
set fan1_min 2000
set fan2_min 2000
ignore fan3
Again, with no success. The fan value isn't corrected. Or is this
a userland problem. (Divide yourself and get happy?)
> > temp1: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor =
> > thermistor <46?C>
> > temp2: +76.5?C (limit = +60?C, hysteresis = +50?C) sensor =
> > thermistor <41?C>
> > temp3: +77.0?C (limit = +60?C, hysteresis = +50?C) sensor =
> > thermistor <46?C>
>
> thermistor type is wrong.
>
> echo "2" > /proc/sys/dev/sensors/w83782d-i2c-0-2d/sensor{1..3}
That does the trick. I was looking at the wrong place ("w83781d")...
set sensor1 2
set sensor2 2
set sensor3 2
# examples for temperature limits
set temp1_over 65???
set temp1_hyst 55???
set temp2_over 65???
set temp2_hyst 55???
set temp3_over 65???
set temp3_hyst 55???
Readings from temp2 are always lower than from 1 and 3.
BIOS says:
temp1 = cpu0
temp2 = cpu1
temp3 = chassis
I tend to distrust the BIOS and think that 1 and 3 are cpu temps,
and 2 is chassis temp, but I also tend to distrust these reading
generally, because of the low variance between the readings:
tyrex:~# sensors | egrep ^temp
temp1: +46.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
temp2: +42.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
temp3: +45.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
tyrex:~# sensors | egrep ^temp
temp1: +46.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
temp2: +43.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
temp3: +46.0?C (limit = +65?C, hysteresis = +55?C) sensor = 3904
transistor
More of a headache are the voltage readings:
VCore 1: +1.74 V (min = +1.74 V, max = +1.93 V) ALARM
VCore 2: +2.84 V (min = +1.74 V, max = +1.93 V)
+3.3V: +3.32 V (min = +3.13 V, max = +3.45 V)
+5V: +4.89 V (min = +4.72 V, max = +5.24 V)
+12V: +4.71 V (min = +10.79 V, max = +13.19 V)
-12V: -2.11 V (min = -10.90 V, max = -13.21 V)
-5V: +2.71 V (min = -4.76 V, max = -5.26 V)
V5SB: +4.32 V (min = +4.72 V, max = +5.24 V)
VBat: +3.29 V (min = +2.40 V, max = +3.60 V)
vid: +1.85 V
VCore 2, +12V, -12V, -5V, V5SB are bogus (and no ALARM flag)
I have no idea how to correct the corresponding formulas in
/etc/sensors.conf. Does somebody did it, before?
> -Dan
Cheers,
Hans-Peter
On Thu, 15 Nov 2001, Hans-Peter Jansen wrote:
> Readings from temp2 are always lower than from 1 and 3.
> BIOS says:
> temp1 = cpu0
> temp2 = cpu1
> temp3 = chassis
Yes. One cpu is generally right below the power supply so the airflow is
obstructed or something, and it runs warmer than cpu0. Everyone's s2460 is
like this.
temp1: +41.0 C (limit = +2 C, hysteresis = +64 C) sensor = 3904 transistor
temp2: +39 C (limit = +80 C, hysteresis = +75 C) sensor = 3904 transistor
temp3: +42 C (limit = +80 C, hysteresis = +75 C) sensor = 3904 transistor
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]