* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
@ 2007-05-14 5:13 ` Rudolf Marek
2007-05-14 19:54 ` Rudolf Marek
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Rudolf Marek @ 2007-05-14 5:13 UTC (permalink / raw)
To: lm-sensors
Hi
Please provide the output of
isadump -y 0x0A05 0xA06
isadump -y -k 0x87,0x87 0x2e 0x2f 0xb 0x7
And cat /proc/ioports
Thanks!
Rudolf
David Hubbard wrote:
> Hi Lambert,
>
> On 5/13/07, Lambert Carsten <reply01@lhcarsten.org> wrote:
>> Hello David,
>>
>> Just starting out with lm sensors I found a sensor chip that is recognized by
>> the 'sensors-detect' script as :
>>
>> Found `Winbond W83627DHG Super IO Sensors' Success!
>> (address 0xa00, driver `w83627ehf')
>>
>> Driver `w83627ehf' (should be inserted):
>> Detects correctly:
>> * ISA bus address 0x0a00 (Busdriver `i2c-isa')
>> Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
>>
>> I saw you had added support for this chip in the 2.6.21 kernel. However when
>> loading the module I get:
>>
>> w83627ehf: unsupported chip ID: 0xffff
>>
>> I am not contacting you for support, but I figured I might be of help,
>> testing, gathering information, whatever is usefull.
>> I do know my way around the command line but I am not a programmer so you
>> might have to tell me how to gather any information you need.
>>
>> Don't waste your time replying unless I can be of help to you. :)
>>
>> Kind regards,
>>
>> Lambert Carsten
>
> You've got the right person here. I'm CCing the lm-sensors list so
> that this information will be publicly available. So it would be easy
> to just add 0xffff as a chip ID and forget about it -- but somehow,
> that doesn't seem like a valid chip ID to me. So I'm going to treat it
> as some kind of bug and try to get your motherboard to report a
> different chip ID. That's just my initial guess...
>
> Would you mind providing the following information?
>
> Kernel version
>
> Motherboard manufacturer and model number
>
> sensors version
>
> Full output of sensors-detect.pl
>
> Any additional clues -- what caused the failure? Did you upgrade to
> linux 2.6.21, or is this new hardware ... ?
>
> Thanks for the report!
> David
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
2007-05-14 5:13 ` Rudolf Marek
@ 2007-05-14 19:54 ` Rudolf Marek
2007-05-15 8:19 ` Lambert Carsten
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Rudolf Marek @ 2007-05-14 19:54 UTC (permalink / raw)
To: lm-sensors
Hi Lambert,
Please CC the list too.
Lambert Carsten wrote:
> Client found at address 0x2f
> Probing for `National Semiconductor LM78'... No
> Probing for `National Semiconductor LM78-J'... No
> Probing for `National Semiconductor LM79'... No
> Probing for `National Semiconductor LM80'... No
> Probing for `Analog Devices ADT7470'... No
> Probing for `Winbond W83781D'... No
> Probing for `Winbond W83782D'... No
> Probing for `Winbond W83792D'... No
> Probing for `Winbond W83793R/G'... No
> Probing for `Winbond W83791SD'... No
> Probing for `Winbond W83627HF'... No
> Probing for `Winbond W83627EHF'... No
> Probing for `Winbond W83627DHG'... No
> Probing for `Asus AS99127F (rev.1)'... No
> Probing for `Asus AS99127F (rev.2)'... No
> Probing for `Asus ASB100 Bach'... No
> Probing for `Analog Devices ADM9240'... No
> Probing for `Dallas Semiconductor DS1780'... No
> Probing for `National Semiconductor LM81'... No
> Probing for `Analog Devices ADM1029'... No
> Probing for `ITE IT8712F'... No
> Probing for `Fintek custom power control IC'... No
> Probing for `Winbond W83791D'... No
> Client found at address 0x30
> Client found at address 0x32
> Client found at address 0x44
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> Client found at address 0x50
> Handled by driver `eeprom' (already loaded), chip type `eeprom'
> Client found at address 0x52
> Handled by driver `eeprom' (already loaded), chip type `eeprom'
> Client found at address 0x69
> Client found at address 0x6a
>
> Found `Winbond W83627DHG Super IO Sensors' Success!
> (address 0xa00, driver `w83627ehf')
>
> Now follows a summary of the probes I have just done.
> Just press ENTER to continue:
>
> Driver `eeprom' (should be inserted):
> Detects correctly:
> * Bus `SMBus I801 adapter at 0400'
> Busdriver `i2c-i801', I2C address 0x50
> Chip `eeprom' (confidence: 6)
> * Bus `SMBus I801 adapter at 0400'
> Busdriver `i2c-i801', I2C address 0x52
> Chip `eeprom' (confidence: 6)
>
> EEPROMs are *NOT* sensors! They are data storage chips commonly
> found on memory modules (SPD), in monitors (EDID), or in some
> laptops, for example.
>
> Driver `w83627ehf' (should be inserted):
> Detects correctly:
> * ISA bus address 0x0a00 (Busdriver `i2c-isa')
> Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
> Do you want to overwrite /etc/conf.d/lm_sensors? Enter s to specify other file
> name?
> (yes/NO/s):
>
> ######################
> isadump -y 0x0A05 0xA05
> ######################
>
So there is some chip I think you did:
isadump -y 0x0A05 0xA06
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: 04 ff 04 60 14 00 37 10 01 50 01 50 3c 10 02 02
> 10: 04 ff ff 00 00 01 01 3c 43 17 00 00 ff ff ff d7
> 20: a5 e8 cc cc c5 cf c2 31 ff c2 ff da 00 04 10 10
> 30: 12 ca 3b 02 a2 08 a8 21 90 13 0a 06 fe 00 01 ff
> 40: 01 00 10 ff ff ff 07 e5 2d 00 00 84 18 95 00 a3
> 50: ff ff 00 ff ff ff 80 80 c1 7f ff ff 19 a5 00 05
> 60: 04 ff 40 00 01 01 3c ff 01 ff 01 ff ff ff ff ff
> 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 80: 04 ff 04 60 14 00 37 10 01 50 01 50 3c 10 02 02
> 90: 04 ff ff 00 00 01 01 3c 43 17 00 00 ff ff ff d7
> a0: a5 e8 cc cc c5 cf c2 31 ff c2 ff da 00 04 10 10
> b0: 12 ca 3b 02 a2 08 a8 21 90 13 0a 06 fe 00 01 ff
> c0: 01 00 10 ff ff ff 07 e5 2d 00 00 84 18 95 00 a3
> d0: ff ff 00 ff ff ff 80 80 c1 7f ff ff 19 a5 00 05
> e0: 04 ff 40 00 01 01 3c ff 01 ff 01 ff ff ff ff ff
> f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> ######################
> isadump -y -k 0x87,0x87 0x2e 0x2f 0xb 0x7
> ######################
>
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Maybe it lives on 0x4e/0x4f ? Could you please try the latest sensors-detect
(check our devices page how to get it) and try with:
isadump -y -k 0x87,0x87 0x4e 0x4f 0xb 0x7
Thanks,
Rudolf
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
2007-05-14 5:13 ` Rudolf Marek
2007-05-14 19:54 ` Rudolf Marek
@ 2007-05-15 8:19 ` Lambert Carsten
2007-05-15 18:16 ` Jean Delvare
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Lambert Carsten @ 2007-05-15 8:19 UTC (permalink / raw)
To: lm-sensors
Hi Rudolf,
Actually I think it is working with the latest lm_sensors (2.10.3). I didn't
configure anything except uncommenting 'ignore in9' in /etc/sensors.conf as
advised by the emerge script (gentoo) for the W83627DHG chip. Here is the
output of sensors after installing and running the init script:
sensors
w83627dhg-isa-0a00
Adapter: ISA adapter
VCore: +1.26 V (min = +0.00 V, max = +1.74 V)
in1: +12.30 V (min = +1.37 V, max = +7.55 V) ALARM
AVCC: +3.26 V (min = +1.06 V, max = +2.18 V) ALARM
3VCC: +3.26 V (min = +1.71 V, max = +3.74 V)
in4: +1.58 V (min = +1.11 V, max = +1.04 V) ALARM
in5: +1.66 V (min = +1.52 V, max = +0.09 V) ALARM
in6: +4.94 V (min = +5.43 V, max = +1.31 V) ALARM
VSB: +3.26 V (min = +2.58 V, max = +2.21 V) ALARM
VBAT: +3.17 V (min = +2.22 V, max = +3.90 V)
Case Fan: 0 RPM (min = 0 RPM, div = 64) ALARM
CPU Fan: 683 RPM (min = 664 RPM, div = 8)
Aux Fan: 0 RPM (min = 1757 RPM, div = 64) ALARM
fan4: 0 RPM (min = 56250 RPM, div = 8) ALARM
fan5: 0 RPM (min = 9375 RPM, div = 8) ALARM
Sys Temp: +45 C (high = +115 C, hyst = +27 C)
CPU Temp: +24.5 C (high = +80.0 C, hyst = +75.0 C)
AUX Temp: +121.5 C (high = +80.0 C, hyst = +75.0 C) ALARM
The CPU Temp reading seems low but I put the machine to work and the temp went
up as expected and seems right. The CPU Fan reading I think is corrct too.
The bios is configured to speed up the fan when the CPU reaches 50 C.
Here follows the isadumps you requested in case they are still usefull. It's
all 'middle clicked' this time so no typo.
isadump -y 0x0A05 0xA05
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
80: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
90: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
a0: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
b0: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
c0: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
d0: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
e0: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
f0: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
isadump -y -k 0x87,0x87 0x4e 0x4f 0xb 0x7
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: a0 23 ff 00 44 00 40 ff 50 00 00 00 03 21 00 ff
30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: 0a 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: 81 ff 80 ff 00 01 00 00 ff ff ff ff ff ff ff ff
Here is the 'header' of lm_sensors-2.10.3 and relevant(?) output of the
sensors-detect script:
# sensors-detect revision 4348 (2007-03-18 02:45:21 -0700)
...
Trying family `VIA/Winbond/Fintek'... Yes
Found `Winbond W83627DHG Super IO Sensors' Success!
(address 0xa00, driver `w83627ehf')
...
Here is the dmesg output after running /etc/init.d/lm_sensors (gentoo):
...
i2c_adapter i2c-2: SMBus Quick command not supported, can't probe for chips
i2c_adapter i2c-3: SMBus Quick command not supported, can't probe for chips
w83627ehf: unsupported chip ID: 0xffff
Thanks for the good work,
Lambert
On Monday 14 May 2007 21:54, you wrote:
> Hi Lambert,
>
> Please CC the list too.
>
> Lambert Carsten wrote:
> > Client found at address 0x2f
> > Probing for `National Semiconductor LM78'... No
> > Probing for `National Semiconductor LM78-J'... No
> > Probing for `National Semiconductor LM79'... No
> > Probing for `National Semiconductor LM80'... No
> > Probing for `Analog Devices ADT7470'... No
> > Probing for `Winbond W83781D'... No
> > Probing for `Winbond W83782D'... No
> > Probing for `Winbond W83792D'... No
> > Probing for `Winbond W83793R/G'... No
> > Probing for `Winbond W83791SD'... No
> > Probing for `Winbond W83627HF'... No
> > Probing for `Winbond W83627EHF'... No
> > Probing for `Winbond W83627DHG'... No
> > Probing for `Asus AS99127F (rev.1)'... No
> > Probing for `Asus AS99127F (rev.2)'... No
> > Probing for `Asus ASB100 Bach'... No
> > Probing for `Analog Devices ADM9240'... No
> > Probing for `Dallas Semiconductor DS1780'... No
> > Probing for `National Semiconductor LM81'... No
> > Probing for `Analog Devices ADM1029'... No
> > Probing for `ITE IT8712F'... No
> > Probing for `Fintek custom power control IC'... No
> > Probing for `Winbond W83791D'... No
> > Client found at address 0x30
> > Client found at address 0x32
> > Client found at address 0x44
> > Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> > Client found at address 0x50
> > Handled by driver `eeprom' (already loaded), chip type `eeprom'
> > Client found at address 0x52
> > Handled by driver `eeprom' (already loaded), chip type `eeprom'
> > Client found at address 0x69
> > Client found at address 0x6a
> >
> > Found `Winbond W83627DHG Super IO Sensors' Success!
> > (address 0xa00, driver `w83627ehf')
> >
> > Now follows a summary of the probes I have just done.
> > Just press ENTER to continue:
> >
> > Driver `eeprom' (should be inserted):
> > Detects correctly:
> > * Bus `SMBus I801 adapter at 0400'
> > Busdriver `i2c-i801', I2C address 0x50
> > Chip `eeprom' (confidence: 6)
> > * Bus `SMBus I801 adapter at 0400'
> > Busdriver `i2c-i801', I2C address 0x52
> > Chip `eeprom' (confidence: 6)
> >
> > EEPROMs are *NOT* sensors! They are data storage chips commonly
> > found on memory modules (SPD), in monitors (EDID), or in some
> > laptops, for example.
> >
> > Driver `w83627ehf' (should be inserted):
> > Detects correctly:
> > * ISA bus address 0x0a00 (Busdriver `i2c-isa')
> > Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
> > Do you want to overwrite /etc/conf.d/lm_sensors? Enter s to specify other
> > file name?
> > (yes/NO/s):
> >
> > ######################
> > isadump -y 0x0A05 0xA05
> > ######################
>
> So there is some chip I think you did:
> isadump -y 0x0A05 0xA06
>
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: 04 ff 04 60 14 00 37 10 01 50 01 50 3c 10 02 02
> > 10: 04 ff ff 00 00 01 01 3c 43 17 00 00 ff ff ff d7
> > 20: a5 e8 cc cc c5 cf c2 31 ff c2 ff da 00 04 10 10
> > 30: 12 ca 3b 02 a2 08 a8 21 90 13 0a 06 fe 00 01 ff
> > 40: 01 00 10 ff ff ff 07 e5 2d 00 00 84 18 95 00 a3
> > 50: ff ff 00 ff ff ff 80 80 c1 7f ff ff 19 a5 00 05
> > 60: 04 ff 40 00 01 01 3c ff 01 ff 01 ff ff ff ff ff
> > 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 80: 04 ff 04 60 14 00 37 10 01 50 01 50 3c 10 02 02
> > 90: 04 ff ff 00 00 01 01 3c 43 17 00 00 ff ff ff d7
> > a0: a5 e8 cc cc c5 cf c2 31 ff c2 ff da 00 04 10 10
> > b0: 12 ca 3b 02 a2 08 a8 21 90 13 0a 06 fe 00 01 ff
> > c0: 01 00 10 ff ff ff 07 e5 2d 00 00 84 18 95 00 a3
> > d0: ff ff 00 ff ff ff 80 80 c1 7f ff ff 19 a5 00 05
> > e0: 04 ff 40 00 01 01 3c ff 01 ff 01 ff ff ff ff ff
> > f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >
> > ######################
> > isadump -y -k 0x87,0x87 0x2e 0x2f 0xb 0x7
> > ######################
> >
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> Maybe it lives on 0x4e/0x4f ? Could you please try the latest
> sensors-detect (check our devices page how to get it) and try with:
> isadump -y -k 0x87,0x87 0x4e 0x4f 0xb 0x7
>
> Thanks,
>
> Rudolf
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (2 preceding siblings ...)
2007-05-15 8:19 ` Lambert Carsten
@ 2007-05-15 18:16 ` Jean Delvare
2007-05-15 18:53 ` David Hubbard
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Jean Delvare @ 2007-05-15 18:16 UTC (permalink / raw)
To: lm-sensors
Hi Lambert, David,
On Tue, 15 May 2007 10:19:59 +0200, Lambert Carsten wrote:
> Actually I think it is working with the latest lm_sensors (2.10.3). I didn't
> configure anything except uncommenting 'ignore in9' in /etc/sensors.conf as
> advised by the emerge script (gentoo) for the W83627DHG chip. Here is the
> output of sensors after installing and running the init script:
>
> sensors
> w83627dhg-isa-0a00
> Adapter: ISA adapter
> VCore: +1.26 V (min = +0.00 V, max = +1.74 V)
> in1: +12.30 V (min = +1.37 V, max = +7.55 V) ALARM
> AVCC: +3.26 V (min = +1.06 V, max = +2.18 V) ALARM
> 3VCC: +3.26 V (min = +1.71 V, max = +3.74 V)
> in4: +1.58 V (min = +1.11 V, max = +1.04 V) ALARM
> in5: +1.66 V (min = +1.52 V, max = +0.09 V) ALARM
> in6: +4.94 V (min = +5.43 V, max = +1.31 V) ALARM
> VSB: +3.26 V (min = +2.58 V, max = +2.21 V) ALARM
> VBAT: +3.17 V (min = +2.22 V, max = +3.90 V)
> Case Fan: 0 RPM (min = 0 RPM, div = 64) ALARM
> CPU Fan: 683 RPM (min = 664 RPM, div = 8)
> Aux Fan: 0 RPM (min = 1757 RPM, div = 64) ALARM
> fan4: 0 RPM (min = 56250 RPM, div = 8) ALARM
> fan5: 0 RPM (min = 9375 RPM, div = 8) ALARM
> Sys Temp: +45 C (high = +115 C, hyst = +27 C)
> CPU Temp: +24.5 C (high = +80.0 C, hyst = +75.0 C)
> AUX Temp: +121.5 C (high = +80.0 C, hyst = +75.0 C) ALARM
>
> The CPU Temp reading seems low but I put the machine to work and the temp went
> up as expected and seems right. The CPU Fan reading I think is corrct too.
> The bios is configured to speed up the fan when the CPU reaches 50 C.
Could be that the Sys Temp and CPU Temp labels need to be swapped.
Check the order and values in your BIOS (if it prints them.)
> Here follows the isadumps you requested in case they are still usefull. It's
> all 'middle clicked' this time so no typo.
> (...)
> isadump -y -k 0x87,0x87 0x4e 0x4f 0xb 0x7
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: a0 23 ff 00 44 00 40 ff 50 00 00 00 03 21 00 ff
> 30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 60: 0a 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: 81 ff 80 ff 00 01 00 00 ff ff ff ff ff ff ff ff
This confirms that the configuration space of the W83627DHG is mapped
to 0x4e/0x4f. This explains the log message that you reported: the
driver printed it after it failed to find a device at 0x2e/0x2f. Then
it tried 0x4e/0x4f and succeeded, so the message was only a warning,
not an error.
The w83627ehf driver should be changed to _not_ print a message when the
device ID reads 0xffff (or 0x0000, for that matter) as it means there
is _no_ chip at this address.
On top of that, the driver should _not_ print a message by default when
it finds an unsupported ID. It is perfectly valid to have a W83627DHG
at 0x4e/0x4f and another LPC chip at 0x2e/0x2f. I think we already
heard of boards with two LPC chips, and we don't want to fill the log
with irrelevant messages in that case. So I believe that the driver
should only print this message when compiled with debugging enabled, as
the w83627hf driver is doing.
David, can you please submit a patch doing that?
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (3 preceding siblings ...)
2007-05-15 18:16 ` Jean Delvare
@ 2007-05-15 18:53 ` David Hubbard
2007-05-15 23:51 ` Rudolf Marek
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Hubbard @ 2007-05-15 18:53 UTC (permalink / raw)
To: lm-sensors
Hi Jean, All,
On 5/15/07, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Lambert, David,
>
> On Tue, 15 May 2007 10:19:59 +0200, Lambert Carsten wrote:
> > Actually I think it is working with the latest lm_sensors (2.10.3). I didn't
> > configure anything except uncommenting 'ignore in9' in /etc/sensors.conf as
> > advised by the emerge script (gentoo) for the W83627DHG chip. Here is the
> > output of sensors after installing and running the init script:
> >
> > sensors
> > w83627dhg-isa-0a00
> > Adapter: ISA adapter
> > VCore: +1.26 V (min = +0.00 V, max = +1.74 V)
> > in1: +12.30 V (min = +1.37 V, max = +7.55 V) ALARM
> > AVCC: +3.26 V (min = +1.06 V, max = +2.18 V) ALARM
> > 3VCC: +3.26 V (min = +1.71 V, max = +3.74 V)
> > in4: +1.58 V (min = +1.11 V, max = +1.04 V) ALARM
> > in5: +1.66 V (min = +1.52 V, max = +0.09 V) ALARM
> > in6: +4.94 V (min = +5.43 V, max = +1.31 V) ALARM
> > VSB: +3.26 V (min = +2.58 V, max = +2.21 V) ALARM
> > VBAT: +3.17 V (min = +2.22 V, max = +3.90 V)
> > Case Fan: 0 RPM (min = 0 RPM, div = 64) ALARM
> > CPU Fan: 683 RPM (min = 664 RPM, div = 8)
> > Aux Fan: 0 RPM (min = 1757 RPM, div = 64) ALARM
> > fan4: 0 RPM (min = 56250 RPM, div = 8) ALARM
> > fan5: 0 RPM (min = 9375 RPM, div = 8) ALARM
> > Sys Temp: +45 C (high = +115 C, hyst = +27 C)
> > CPU Temp: +24.5 C (high = +80.0 C, hyst = +75.0 C)
> > AUX Temp: +121.5 C (high = +80.0 C, hyst = +75.0 C) ALARM
> >
> > The CPU Temp reading seems low but I put the machine to work and the temp went
> > up as expected and seems right. The CPU Fan reading I think is corrct too.
> > The bios is configured to speed up the fan when the CPU reaches 50 C.
>
> Could be that the Sys Temp and CPU Temp labels need to be swapped.
> Check the order and values in your BIOS (if it prints them.)
>
> > Here follows the isadumps you requested in case they are still usefull. It's
> > all 'middle clicked' this time so no typo.
> > (...)
> > isadump -y -k 0x87,0x87 0x4e 0x4f 0xb 0x7
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
> > 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 20: a0 23 ff 00 44 00 40 ff 50 00 00 00 03 21 00 ff
> > 30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 60: 0a 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > f0: 81 ff 80 ff 00 01 00 00 ff ff ff ff ff ff ff ff
>
> This confirms that the configuration space of the W83627DHG is mapped
> to 0x4e/0x4f. This explains the log message that you reported: the
> driver printed it after it failed to find a device at 0x2e/0x2f. Then
> it tried 0x4e/0x4f and succeeded, so the message was only a warning,
> not an error.
>
> The w83627ehf driver should be changed to _not_ print a message when the
> device ID reads 0xffff (or 0x0000, for that matter) as it means there
> is _no_ chip at this address.
>
> On top of that, the driver should _not_ print a message by default when
> it finds an unsupported ID. It is perfectly valid to have a W83627DHG
> at 0x4e/0x4f and another LPC chip at 0x2e/0x2f. I think we already
> heard of boards with two LPC chips, and we don't want to fill the log
> with irrelevant messages in that case. So I believe that the driver
> should only print this message when compiled with debugging enabled, as
> the w83627hf driver is doing.
>
> David, can you please submit a patch doing that?
Yes, I'd consider it a bug when it finds an OK chip at 0x43. I'll look
at how w83627hf driver does it and copy that.
David
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (4 preceding siblings ...)
2007-05-15 18:53 ` David Hubbard
@ 2007-05-15 23:51 ` Rudolf Marek
2007-05-16 22:59 ` David Hubbard
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Rudolf Marek @ 2007-05-15 23:51 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
100% Agree, I wanted to write that too but have no time :/
Btw david. You can set the HEFRAS bit in CR26 to move your superio to 0x4e/4f.
(write 0x40 to 0x26 + key)
I tried that and now I got same err
...
Ending clean XFS mount for filesystem: dm-2
w83627ehf: unsupported chip ID: 0xffff
ruik:/home/ruik#
I think test for 0xffff should be there. I think ISA decodes empty spaces as 0xff.
Rudolf
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (5 preceding siblings ...)
2007-05-15 23:51 ` Rudolf Marek
@ 2007-05-16 22:59 ` David Hubbard
2007-06-08 14:46 ` Jean Delvare
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Hubbard @ 2007-05-16 22:59 UTC (permalink / raw)
To: lm-sensors
Hi Rudolf,
> Yes. Maybe you can enhance Jean's patch which he posted today.
>
> Rudolf
Of course Jean's patch is for the 627hf chip.
David
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (6 preceding siblings ...)
2007-05-16 22:59 ` David Hubbard
@ 2007-06-08 14:46 ` Jean Delvare
2007-06-08 19:13 ` David Hubbard
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Jean Delvare @ 2007-06-08 14:46 UTC (permalink / raw)
To: lm-sensors
Hi David,
On Tue, 15 May 2007 12:53:18 -0600, David Hubbard wrote:
> On 5/15/07, Jean Delvare <khali@linux-fr.org> wrote:
> > This confirms that the configuration space of the W83627DHG is mapped
> > to 0x4e/0x4f. This explains the log message that you reported: the
> > driver printed it after it failed to find a device at 0x2e/0x2f. Then
> > it tried 0x4e/0x4f and succeeded, so the message was only a warning,
> > not an error.
> >
> > The w83627ehf driver should be changed to _not_ print a message when the
> > device ID reads 0xffff (or 0x0000, for that matter) as it means there
> > is _no_ chip at this address.
> >
> > On top of that, the driver should _not_ print a message by default when
> > it finds an unsupported ID. It is perfectly valid to have a W83627DHG
> > at 0x4e/0x4f and another LPC chip at 0x2e/0x2f. I think we already
> > heard of boards with two LPC chips, and we don't want to fill the log
> > with irrelevant messages in that case. So I believe that the driver
> > should only print this message when compiled with debugging enabled, as
> > the w83627hf driver is doing.
> >
> > David, can you please submit a patch doing that?
>
> Yes, I'd consider it a bug when it finds an OK chip at 0x43. I'll look
> at how w83627hf driver does it and copy that.
Do you have a patch ready? A bug report now exists on kernel.org:
http://bugzilla.kernel.org/show_bug.cgi?id…93
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (7 preceding siblings ...)
2007-06-08 14:46 ` Jean Delvare
@ 2007-06-08 19:13 ` David Hubbard
2007-06-16 12:43 ` Jean Delvare
2007-06-21 19:24 ` David Hubbard
10 siblings, 0 replies; 12+ messages in thread
From: David Hubbard @ 2007-06-08 19:13 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
> On Tue, 15 May 2007 12:53:18 -0600, David Hubbard wrote:
> > On 5/15/07, Jean Delvare <khali@linux-fr.org> wrote:
> > > This confirms that the configuration space of the W83627DHG is mapped
> > > to 0x4e/0x4f. This explains the log message that you reported: the
> > > driver printed it after it failed to find a device at 0x2e/0x2f. Then
> > > it tried 0x4e/0x4f and succeeded, so the message was only a warning,
> > > not an error.
> > >
> > > The w83627ehf driver should be changed to _not_ print a message when the
> > > device ID reads 0xffff (or 0x0000, for that matter) as it means there
> > > is _no_ chip at this address.
> > >
> > > On top of that, the driver should _not_ print a message by default when
> > > it finds an unsupported ID. It is perfectly valid to have a W83627DHG
> > > at 0x4e/0x4f and another LPC chip at 0x2e/0x2f. I think we already
> > > heard of boards with two LPC chips, and we don't want to fill the log
> > > with irrelevant messages in that case. So I believe that the driver
> > > should only print this message when compiled with debugging enabled, as
> > > the w83627hf driver is doing.
> > >
> > > David, can you please submit a patch doing that?
> >
> > Yes, I'd consider it a bug when it finds an OK chip at 0x43. I'll look
> > at how w83627hf driver does it and copy that.
>
> Do you have a patch ready? A bug report now exists on kernel.org:
> http://bugzilla.kernel.org/show_bug.cgi?id…93
Thanks for the heads up. I'm still working on getting rid of i2c-isa,
but I'll include a patch to fix this in my next update.
David
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (8 preceding siblings ...)
2007-06-08 19:13 ` David Hubbard
@ 2007-06-16 12:43 ` Jean Delvare
2007-06-21 19:24 ` David Hubbard
10 siblings, 0 replies; 12+ messages in thread
From: Jean Delvare @ 2007-06-16 12:43 UTC (permalink / raw)
To: lm-sensors
Hi David,
On Fri, 8 Jun 2007 13:13:04 -0600, David Hubbard wrote:
> > Do you have a patch ready? A bug report now exists on kernel.org:
> > http://bugzilla.kernel.org/show_bug.cgi?id…93
>
> Thanks for the heads up. I'm still working on getting rid of i2c-isa,
> but I'll include a patch to fix this in my next update.
Any news on this? I'd like to get rid of i2c-isa during the week-end,
or beginning of next week at the latest. I have a new motherboard
available for development and testing with a W83627EHG on it (thanks to
Observit) so if you won't have the possibility to make it on time,
please just tell me and I'll fix the latest version of your patches
myself.
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [lm-sensors] hwmon/w83627ehf
2007-05-14 3:35 [lm-sensors] hwmon/w83627ehf David Hubbard
` (9 preceding siblings ...)
2007-06-16 12:43 ` Jean Delvare
@ 2007-06-21 19:24 ` David Hubbard
10 siblings, 0 replies; 12+ messages in thread
From: David Hubbard @ 2007-06-21 19:24 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
> On Fri, 8 Jun 2007 13:13:04 -0600, David Hubbard wrote:
> > > Do you have a patch ready? A bug report now exists on kernel.org:
> > > http://bugzilla.kernel.org/show_bug.cgi?id…93
> >
> > Thanks for the heads up. I'm still working on getting rid of i2c-isa,
> > but I'll include a patch to fix this in my next update.
>
> Any news on this? I'd like to get rid of i2c-isa during the week-end,
> or beginning of next week at the latest. I have a new motherboard
> available for development and testing with a W83627EHG on it (thanks to
> Observit) so if you won't have the possibility to make it on time,
> please just tell me and I'll fix the latest version of your patches
> myself.
I haven't finished a new set of patches, since work has kept me quite
busy. I wouldn't mind if you wanted to finish the platform or the
error message bug.
Thanks,
David
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 12+ messages in thread