* [lm-sensors] Will there ever be EMC6w201 support?
@ 2011-04-14 3:46 Harry G McGavran Jr
2011-04-14 7:57 ` Jean Delvare
` (63 more replies)
0 siblings, 64 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-04-14 3:46 UTC (permalink / raw)
To: lm-sensors
The last time anyone supposedly looked into this
was in 2006.
My Dell Precision 670 is still going great guns with
Ubuntu Lucid, but lm_sensors can't deal with
the EMC6w201 in it.
One can get the datasheet for this at:
http://www.datasheetarchive.com/pdf-datasheets/Datasheets-32/DSA-629474.html
It is a 150 page pdf which looks like it should have the info
needed. I have a copy, but don't know who to forward it to
who might be able to conjure up a driver for it.
Harry McGavran
--
Harry G. McGavran, Jr.
E-mail: w5pny@arrl.net
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
@ 2011-04-14 7:57 ` Jean Delvare
2011-04-14 15:19 ` Harry G McGavran Jr
` (62 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-04-14 7:57 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Wed, 13 Apr 2011 21:46:09 -0600, Harry G McGavran Jr wrote:
> The last time anyone supposedly looked into this
> was in 2006.
>
> My Dell Precision 670 is still going great guns with
> Ubuntu Lucid, but lm_sensors can't deal with
> the EMC6w201 in it.
>
> One can get the datasheet for this at:
>
> http://www.datasheetarchive.com/pdf-datasheets/Datasheets-32/DSA-629474.html
>
> It is a 150 page pdf which looks like it should have the info
> needed. I have a copy, but don't know who to forward it to
> who might be able to conjure up a driver for it.
Will be difficult to find a developer motivated to write a driver for 2
users of 2006 hardware, I'm afraid. Do you have anything to offer in
return? I have a wishlist:
http://khali.linux-fr.org/wishlist.html
Meanwhile I've added detection support to sensors-detect:
http://khali.linux-fr.org/devel/misc/sensors-detect
If you could test and report, that would be great. Proper detection of
the chip may bring more user requests to support the chip (although the
old age of the chip makes this event rather unlikely.)
A register dump of the chip would be welcome too. You can obtain it by
loading the i2c-dev kernel driver and running i2cdump (from the
i2c-tools package):
# modprobe i2c-dev
# i2cdump N 0x2e
where N is the i2c bus number displayed by sensors-detect, and 0x2e the
actual chip address on that bus (can be one of 0x2c, 0x2d or 0x2e.)
While the EMC6W201 is a pretty complex chip with many advanced
features, basic monitoring of voltages, fans and temperatures shouldn't
be that hard to implement.
Ric, out of curiosity, are you still interested in EMC6W201 support?
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
2011-04-14 7:57 ` Jean Delvare
@ 2011-04-14 15:19 ` Harry G McGavran Jr
2011-04-14 15:24 ` Harry G McGavran Jr
` (61 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-04-14 15:19 UTC (permalink / raw)
To: lm-sensors
On Thu, 14 Apr 2011 09:57:23 +0200 Jean Delvare wrote:
>
> Will be difficult to find a developer motivated to write a driver for 2
> users of 2006 hardware, I'm afraid. Do you have anything to offer in
> return? I have a wishlist:
> http://khali.linux-fr.org/wishlist.html
I looked at your wishlist, and at the moment, I've only got
one or two short RJ45 cables and possiblye and HDMI cable,
but I'd have to check if its male/male. Might be able to
come up with more from your list at a later time.
>
> Meanwhile I've added detection support to sensors-detect:
> http://khali.linux-fr.org/devel/misc/sensors-detect
> If you could test and report, that would be great. Proper detection of
> the chip may bring more user requests to support the chip (although the
> old age of the chip makes this event rather unlikely.)
# sensors-detect revision 5960 (2011-04-14 09:20:09 +0200)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0XC837
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Next adapter: NVIDIA i2c adapter (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Next adapter: SMBus I801 adapter at e8a0 (i2c-3)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `SMSC EMC6D103S'... No
Probing for `SMSC EMC6W201'... No
Probing for `Winbond WPCD377I'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Analog Devices ADT7490'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `National Semiconductor LM94'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Nuvoton W83795G/ADG'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG/W83667HG/W83677HG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Maxim MAX6639'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `SMSC EMC2103'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
>
> A register dump of the chip would be welcome too. You can obtain it by
> loading the i2c-dev kernel driver and running i2cdump (from the
> i2c-tools package):
>
> # modprobe i2c-dev
> # i2cdump N 0x2e
>
> where N is the i2c bus number displayed by sensors-detect, and 0x2e the
> actual chip address on that bus (can be one of 0x2c, 0x2d or 0x2e.)
>
i2cdump 3 0x2e
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 8c a1 c2 c4 c1 00 36 00 00 00 2f 2c 0f 0d ff ff ?????.6.../,??..
30: c7 09 ff ff ff ff 3f 47 6f 0d 0d 00 00 00 5c b1 ??....?Go??...\?
40: 05 00 00 00 00 00 00 ec 1a 04 7e 98 64 da b3 cd ?......???~?d???
50: b3 cd b3 cd 64 da 81 58 81 58 81 3c 81 37 81 4b ????d??X?X?<?7?K
60: 81 50 50 46 50 46 78 69 f0 ff f0 ff 04 3f 00 ff ?PPFPFxi?.?.??..
70: 00 ff 00 ff 00 ff 00 ff 00 ff ed 1a 04 00 00 00 ..........???...
80: a9 a9 49 99 90 cc ff fa e8 88 3f 47 6f 00 00 00 ??I???.????Go...
90: 40 40 2f 2f 2f 2d 7f 7f 7f 7f 7f 7f 20 0d 0d a4 @@///-?????? ???
a0: 28 69 db 00 04 04 04 04 2f 2f 2f 01 1f 00 62 7f (i?.????///??.b?
b0: 7f 7f 7f 7f 00 00 00 80 00 00 00 00 00 00 00 00 ????...?........
c0: 00 80 40 00 7f 7f 7f 7f 7f 7f 00 00 00 00 00 00 .?@.??????......
d0: 00 ff ff ff ff ff ff ff ff ff ff 6f ff ff ff ff ...........o....
e0: 00 08 a0 2a e8 00 40 00 18 00 00 00 00 00 00 00 .??*?.@.?.......
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> While the EMC6W201 is a pretty complex chip with many advanced
> features, basic monitoring of voltages, fans and temperatures shouldn't
> be that hard to implement.
>
> Ric, out of curiosity, are you still interested in EMC6W201 support?
>
> --
> Jean Delvare
Thanks Jean for your reply and a possible glimmer of hope.
If I come up with anything wish-list I'll let you know AND
if you need any more info from my machine, I'll try to
come up with it.
Thanks for your reply!
Harry McGavran
--
Harry G. McGavran, Jr.
E-mail: w5pny@arrl.net
--
Harry G. McGavran, Jr.
E-mail: w5pny@arrl.net
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
2011-04-14 7:57 ` Jean Delvare
2011-04-14 15:19 ` Harry G McGavran Jr
@ 2011-04-14 15:24 ` Harry G McGavran Jr
2011-04-15 15:25 ` Harry G McGavran Jr
` (60 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-04-14 15:24 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
When I looked at a copy of sent mail on my previous message,
I noticed sedit (I still prefer exmh) or some subsequent
action messed up the formatting of the two data files
I included, so I will include them as attachments here,
and you'll be able to read them better (especially the
i2cdump output).
Thanks again --
Harry McGavran
[-- Attachment #2: Delvare_sensors_detect.txt --]
[-- Type: text/plain , Size: 9196 bytes --]
# sensors-detect revision 5960 (2011-04-14 09:20:09 +0200)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0XC837
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Next adapter: NVIDIA i2c adapter (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively): Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Next adapter: SMBus I801 adapter at e8a0 (i2c-3)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `SMSC EMC6D103S'... No
Probing for `SMSC EMC6W201'... No
Probing for `Winbond WPCD377I'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Analog Devices ADT7490'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `National Semiconductor LM94'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Nuvoton W83795G/ADG'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG/W83667HG/W83677HG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Maxim MAX6639'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `SMSC EMC2103'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[-- Attachment #3: i2cdump_3_0x2e.txt --]
[-- Type: text/plain , Size: 1224 bytes --]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 8c a1 c2 c4 c1 00 36 00 00 00 2f 2c 0f 0d ff ff ?????.6.../,??..
30: c7 09 ff ff ff ff 3f 47 6f 0d 0d 00 00 00 5c b1 ??....?Go??...\?
40: 05 00 00 00 00 00 00 ec 1a 04 7e 98 64 da b3 cd ?......???~?d???
50: b3 cd b3 cd 64 da 81 58 81 58 81 3c 81 37 81 4b ????d??X?X?<?7?K
60: 81 50 50 46 50 46 78 69 f0 ff f0 ff 04 3f 00 ff ?PPFPFxi?.?.??..
70: 00 ff 00 ff 00 ff 00 ff 00 ff ed 1a 04 00 00 00 ..........???...
80: a9 a9 49 99 90 cc ff fa e8 88 3f 47 6f 00 00 00 ??I???.????Go...
90: 40 40 2f 2f 2f 2d 7f 7f 7f 7f 7f 7f 20 0d 0d a4 @@///-?????? ???
a0: 28 69 db 00 04 04 04 04 2f 2f 2f 01 1f 00 62 7f (i?.????///??.b?
b0: 7f 7f 7f 7f 00 00 00 80 00 00 00 00 00 00 00 00 ????...?........
c0: 00 80 40 00 7f 7f 7f 7f 7f 7f 00 00 00 00 00 00 .?@.??????......
d0: 00 ff ff ff ff ff ff ff ff ff ff 6f ff ff ff ff ...........o....
e0: 00 08 a0 2a e8 00 40 00 18 00 00 00 00 00 00 00 .??*?.@.?.......
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[-- Attachment #4: Type: text/plain, Size: 49 bytes --]
Harry G. McGavran, Jr.
E-mail: w5pny@arrl.net
[-- Attachment #5: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (2 preceding siblings ...)
2011-04-14 15:24 ` Harry G McGavran Jr
@ 2011-04-15 15:25 ` Harry G McGavran Jr
2011-05-05 10:10 ` Jean Delvare
` (59 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-04-15 15:25 UTC (permalink / raw)
To: lm-sensors
On Thu, 14 Apr 2011 09:57:23 +0200 Jean Delvare wrote:
> Hi Harry,
.
.
.
>
> While the EMC6W201 is a pretty complex chip with many advanced
> features, basic monitoring of voltages, fans and temperatures shouldn't
> be that hard to implement.
>
FWIW: I installed the i8kutils and driver and forceloaded the driver.
They seem to be able to read the fan speeds, but not the CPU
temperature. So, there is some code around that works with
this machine, but not entirely. That may be a place to look too.
Harry McGavran
--
Harry G. McGavran, Jr.
E-mail: w5pny@arrl.net
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (3 preceding siblings ...)
2011-04-15 15:25 ` Harry G McGavran Jr
@ 2011-05-05 10:10 ` Jean Delvare
2011-05-05 15:16 ` Harry G McGavran Jr
` (58 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-05 10:10 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Thu, 14 Apr 2011 09:57:23 +0200, Jean Delvare wrote:
> Meanwhile I've added detection support to sensors-detect:
> http://khali.linux-fr.org/devel/misc/sensors-detect
> If you could test and report, that would be great. Proper detection of
> the chip may bring more user requests to support the chip (although the
> old age of the chip makes this event rather unlikely.)
Can you please test?
> A register dump of the chip would be welcome too. You can obtain it by
> loading the i2c-dev kernel driver and running i2cdump (from the
> i2c-tools package):
>
> # modprobe i2c-dev
> # i2cdump N 0x2e
>
> where N is the i2c bus number displayed by sensors-detect, and 0x2e the
> actual chip address on that bus (can be one of 0x2c, 0x2d or 0x2e.)
Can I get this register dump, please?
> Ric, out of curiosity, are you still interested in EMC6W201 support?
Ric?
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (4 preceding siblings ...)
2011-05-05 10:10 ` Jean Delvare
@ 2011-05-05 15:16 ` Harry G McGavran Jr
2011-05-05 16:30 ` Jean Delvare
` (57 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-05 15:16 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
Attached are the sensors-detect output and the i2cdump
results...
Thanks -- Harry
On Thu, 5 May 2011 12:10:52 +0200 Jean Delvare wrote:
#forw [original message] +/usr/local/home/hgm/.Mail/inbox 1956
[-- Attachment #2: sensors-detect.out2 --]
[-- Type: application/octet-stream , Size: 9298 bytes --]
# sensors-detect revision 5960 (2011-04-14 09:20:09 +0200)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0XC837
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Module i2c-i801 loaded successfully.
Module i2c-dev loaded successfully.
Next adapter: NVIDIA i2c adapter (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively): Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Next adapter: SMBus I801 adapter at e8a0 (i2c-3)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `SMSC EMC6D103S'... No
Probing for `SMSC EMC6W201'... No
Probing for `Winbond WPCD377I'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Analog Devices ADT7490'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `National Semiconductor LM94'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Nuvoton W83795G/ADG'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG/W83667HG/W83677HG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Maxim MAX6639'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `SMSC EMC2103'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[-- Attachment #3: i2cdump_3_0x2e.txt2 --]
[-- Type: application/octet-stream , Size: 1224 bytes --]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 8c a1 c2 c4 c1 00 36 00 00 00 30 2c 10 0d ff ff ?????.6...0,??..
30: cc 09 ff ff ff ff 3f 47 6f 00 00 00 00 00 5c b1 ??....?Go.....\?
40: 05 0d 0d 00 00 00 00 ec 1a 04 7e 98 64 da b3 cd ???....???~?d???
50: b3 cd b3 cd 64 da 81 58 81 58 81 3c 81 37 81 4b ????d??X?X?<?7?K
60: 81 50 50 46 50 46 78 69 f0 ff f0 ff 04 3f 00 ff ?PPFPFxi?.?.??..
70: 00 ff 00 ff 00 ff 00 ff 00 ff ed 1a 04 00 00 00 ..........???...
80: a9 a9 49 99 90 cc ff fa e8 88 3f 47 6f 00 00 00 ??I???.????Go...
90: 40 40 2f 2f 2f 2d 7f 7f 7f 7f 7f 7f 20 02 02 a4 @@///-?????? ???
a0: 28 69 db 00 0d 0d 04 04 2f 2f 2f 01 1f 00 62 7f (i?.????///??.b?
b0: 7f 7f 7f 7f 00 00 00 80 00 00 00 00 00 00 00 00 ????...?........
c0: 00 80 40 00 7f 7f 7f 7f 7f 7f 00 00 00 00 00 00 .?@.??????......
d0: 00 ff ff ff ff ff ff ff ff ff ff 6f ff ff ff ff ...........o....
e0: 00 0a a0 2a e6 00 40 00 18 00 00 00 00 00 00 00 .??*?.@.?.......
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[-- Attachment #4: Type: text/plain, Size: 50 bytes --]
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
[-- Attachment #5: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (5 preceding siblings ...)
2011-05-05 15:16 ` Harry G McGavran Jr
@ 2011-05-05 16:30 ` Jean Delvare
2011-05-05 16:40 ` Harry G McGavran Jr
` (56 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-05 16:30 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Thu, 05 May 2011 09:16:19 -0600, Harry G McGavran Jr wrote:
> Attached are the sensors-detect output and the i2cdump
> results...
I found just now in the list archives that you had been reporting all
the requested data back on April 14th. For some reason I never received
any of the 3 replies you sent that day :( So sorry for the delay...
Anyway, my detection code was too strict, as it seems you have the
second revision of the EMC6W201 and my code only detected the first
one. I've committed a fixed version of the detection code, successfully
tested on the dump you sent, so I know it works.
I've also updated the entry in wiki/Devices. Hopefully this will get
other owners of this chip, if any, to report to us.
> FWIW: I installed the i8kutils and driver and forceloaded the driver.
> They seem to be able to read the fan speeds, but not the CPU
> temperature. So, there is some code around that works with
> this machine, but not entirely. That may be a place to look too.
Huh. I don't know if this is good news... If the BIOS gets the fan
speeds from the EMC6W201, then we will get a resource conflict if you
try using a native driver for the EMC6W201. If the BIOS gets the fan
speeds from somewhere else, then a native driver for the EMC6W201 may
not be that useful to you. D'oh.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (6 preceding siblings ...)
2011-05-05 16:30 ` Jean Delvare
@ 2011-05-05 16:40 ` Harry G McGavran Jr
2011-05-06 15:24 ` Jeff Rickman
` (55 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-05 16:40 UTC (permalink / raw)
To: lm-sensors
Hi Jean --
On Thu, 5 May 2011 18:30:41 +0200 Jean Delvare wrote:
> Hi Harry,
>
> On Thu, 05 May 2011 09:16:19 -0600, Harry G McGavran Jr wrote:
> > Attached are the sensors-detect output and the i2cdump
> > results...
>
> I found just now in the list archives that you had been reporting all
> the requested data back on April 14th. For some reason I never received
> any of the 3 replies you sent that day :( So sorry for the delay...
>
> Anyway, my detection code was too strict, as it seems you have the
> second revision of the EMC6W201 and my code only detected the first
> one. I've committed a fixed version of the detection code, successfully
> tested on the dump you sent, so I know it works.
>
> I've also updated the entry in wiki/Devices. Hopefully this will get
> other owners of this chip, if any, to report to us.
I;ll keep my fingers crossed --- this is progress...
>
> > FWIW: I installed the i8kutils and driver and forceloaded the driver.
> > They seem to be able to read the fan speeds, but not the CPU
> > temperature. So, there is some code around that works with
> > this machine, but not entirely. That may be a place to look too.
>
> Huh. I don't know if this is good news... If the BIOS gets the fan
> speeds from the EMC6W201, then we will get a resource conflict if you
> try using a native driver for the EMC6W201. If the BIOS gets the fan
> speeds from somewhere else, then a native driver for the EMC6W201 may
> not be that useful to you. D'oh.
I didn't know if that would be helpful or not. Since my machine isn't
i8k, I'm not keen to use it, but I though the fact it got fan info
might be helpful without really knowing how it got the data.
I can hope for an lm-sensors driver...
Thanks again!
Harry
>
> --
> Jean Delvare
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (7 preceding siblings ...)
2011-05-05 16:40 ` Harry G McGavran Jr
@ 2011-05-06 15:24 ` Jeff Rickman
2011-05-07 7:46 ` Jean Delvare
` (54 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-06 15:24 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
I have attached a single text file containing output from
"sensors-detect" Version 5968 and an "i2cdump". My i2cdump looks
different compared to Harry's output. My Dell Precision 670 is running
the A07 BIOS, last public version that I know of.
-------- Original Message --------
See attached text file....
[-- Attachment #2: Dell_sensors_testing.txt --]
[-- Type: text/plain, Size: 10088 bytes --]
[root@XX ~]# ./sensors-detect
# sensors-detect revision 5968 (2011-05-05 22:46:56 +0200)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0U7565
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Next adapter: nouveau-0000:05:00.0-0 (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: nouveau-0000:05:00.0-1 (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: SMBus I801 adapter at ece0 (i2c-2)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `SMSC EMC6D103S'... No
Probing for `SMSC EMC6W201'... Success!
(confidence 6, driver `to-be-written')
Probing for `Winbond WPCD377I'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Analog Devices ADT7490'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `National Semiconductor LM94'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Nuvoton W83795G/ADG'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG/W83667HG/W83677HG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Maxim MAX6639'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `SMSC EMC2103'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `to-be-written':
* Bus `SMBus I801 adapter at ece0'
Busdriver `i2c_i801', I2C address 0x2e
Chip `SMSC EMC6W201' (confidence: 6)
Note: there is no driver for SMSC EMC6W201 yet.
Check http://www.lm-sensors.org/wiki/Devices for updates.
No modules to load, skipping modules configuration.
[root@XX ~]# i2cdump 2 0x2e
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2, address 0x2e, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 8a af c5 c3 c2 ae 2e 30 2c 29 2c 2a 18 0e bf 0b ??????.0,),*????
30: 1e 0b ff ff ff ff 3f 47 6f 00 00 00 00 00 5c b1 ??....?Go.....\?
40: 05 00 00 00 00 00 00 fc 1e 0c 7e 98 64 da b3 cd ?......???~?d???
50: b3 cd b3 cd 64 da 81 58 81 58 81 3c 81 37 81 4b ????d??X?X?<?7?K
60: 81 50 50 46 50 46 78 69 f0 ff f0 ff 00 3f 00 ff ?PPFPFxi?.?..?..
70: 00 ff 00 ff 00 ff 00 ff 00 ff fd 1e 0c 00 00 00 ..........???...
80: a9 a9 49 99 90 cc ff fa e8 88 3f 47 6f 00 00 00 ??I???.????Go...
90: 40 40 2f 2f 2f 2d 7f 7f 7f 7f 7f 7f 22 02 02 a4 @@///-??????"???
a0: 28 69 db 00 04 04 04 04 2f 2f 2f 01 1f 00 5f 5f (i?.????///??.__
b0: 7f 7f 7f 7f 00 00 00 c0 00 00 00 30 00 0e 00 00 ????...?...0.?..
c0: 00 80 40 00 7f 7f 7f 7f 7f 7f 00 00 00 00 00 00 .?@.??????......
d0: 00 ff ff ff ff ff ff ff ff ff ff 6f ff ff ff ff ...........o....
e0: 00 46 00 4e 00 00 00 00 1c 00 00 00 00 00 00 00 .F.N....?.......
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (8 preceding siblings ...)
2011-05-06 15:24 ` Jeff Rickman
@ 2011-05-07 7:46 ` Jean Delvare
2011-05-07 7:49 ` Jean Delvare
` (53 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-07 7:46 UTC (permalink / raw)
To: lm-sensors
Hi Jeff,
On Fri, 06 May 2011 10:24:29 -0500, Jeff Rickman wrote:
> I have attached a single text file containing output from
> "sensors-detect" Version 5968 and an "i2cdump". My i2cdump looks
> different compared to Harry's output. My Dell Precision 670 is running
> the A07 BIOS, last public version that I know of.
Thanks for your report. Third request for EMC6W201 support...
Your dump doesn't look too different from Harry's actually.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (9 preceding siblings ...)
2011-05-07 7:46 ` Jean Delvare
@ 2011-05-07 7:49 ` Jean Delvare
2011-05-07 11:47 ` Jean Delvare
` (52 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-07 7:49 UTC (permalink / raw)
To: lm-sensors
On Thu, 5 May 2011 18:30:41 +0200, Jean Delvare wrote:
> On Thu, 05 May 2011 09:16:19 -0600, Harry G McGavran Jr wrote:
> > FWIW: I installed the i8kutils and driver and forceloaded the driver.
> > They seem to be able to read the fan speeds, but not the CPU
> > temperature. So, there is some code around that works with
> > this machine, but not entirely. That may be a place to look too.
>
> Huh. I don't know if this is good news... If the BIOS gets the fan
> speeds from the EMC6W201, then we will get a resource conflict if you
> try using a native driver for the EMC6W201. If the BIOS gets the fan
> speeds from somewhere else, then a native driver for the EMC6W201 may
> not be that useful to you. D'oh.
Oh, BTW, if you're using the i8k driver, you may want to give a try to
my modified version here:
http://khali.linux-fr.org/devel/misc/i8k/
Generic instructions can be found here:
http://khali.linux-fr.org/devel/misc/INSTALL
This version of the i8k driver has proper hwmon subsystem integration,
so whatever the i8k driver reports should show up in the output of
"sensors".
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (10 preceding siblings ...)
2011-05-07 7:49 ` Jean Delvare
@ 2011-05-07 11:47 ` Jean Delvare
2011-05-07 16:23 ` Harry G McGavran Jr
` (51 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-07 11:47 UTC (permalink / raw)
To: lm-sensors
Hi Harry, Ric and Jeff,
On Thu, 05 May 2011 10:40:28 -0600, Harry G McGavran Jr wrote:
> I can hope for an lm-sensors driver...
I found some time to work on EMC6W201 support and I have something for
you to test. My standalone driver for this chip can be downloaded from:
http://khali.linux-fr.org/devel/misc/emc6w201/
You only need i2c-compat.h for kernels <= 2.6.32. I build-tested the
driver down to kernel 2.6.27, older kernels may or may not work.
emc6w201.conf is a template configuration file, copy to /etc/sensors.d
and add statements as needed. Generic build instructions are available
at:
http://khali.linux-fr.org/devel/misc/INSTALL
At this point the driver only supports basic monitoring, in read-only
mode. It seems to work reasonably well on the dumps sent by Harry and
Jeff, but real hardware can behave differently.
Anyway, let me know how it goes.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (11 preceding siblings ...)
2011-05-07 11:47 ` Jean Delvare
@ 2011-05-07 16:23 ` Harry G McGavran Jr
2011-05-07 16:26 ` Harry G McGavran Jr
` (50 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-07 16:23 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
Hi Jean --
Here is the output from /usr/bin/sensors with the
ecm6w201 driver you just gave us AND from the
new i8k driver you mentioned in an earlier e-mail today.
Thanks for your work on this!!!
Harry McGavran
On Sat, 7 May 2011 13:47:21 +0200 Jean Delvare wrote:
> Hi Harry, Ric and Jeff,
>
> On Thu, 05 May 2011 10:40:28 -0600, Harry G McGavran Jr wrote:
> > I can hope for an lm-sensors driver...
>
> I found some time to work on EMC6W201 support and I have something for
> you to test. My standalone driver for this chip can be downloaded from:
> http://khali.linux-fr.org/devel/misc/emc6w201/
> You only need i2c-compat.h for kernels <= 2.6.32. I build-tested the
> driver down to kernel 2.6.27, older kernels may or may not work.
> emc6w201.conf is a template configuration file, copy to /etc/sensors.d
> and add statements as needed. Generic build instructions are available
> at:
> http://khali.linux-fr.org/devel/misc/INSTALL
>
> At this point the driver only supports basic monitoring, in read-only
> mode. It seems to work reasonably well on the dumps sent by Harry and
> Jeff, but real hardware can behave differently.
>
> Anyway, let me know how it goes.
>
> --
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
[-- Attachment #2: sensors.out --]
[-- Type: application/octet-stream , Size: 1068 bytes --]
i8k-virtual-0
Adapter: Virtual device
Left Fan: 64710 RPM
Right Fan: 48420 RPM
CPU: -22.0 C
emc6w201-i2c-3-2e
Adapter: SMBus I801 adapter at e8a0
in0: +1.82 V (min = +1.64 V, max = +1.98 V)
in1: +1.26 V (min = +0.78 V, max = +1.70 V)
in2: +3.33 V (min = +3.08 V, max = +3.52 V)
in3: +5.10 V (min = +4.66 V, max = +5.34 V)
in4: +1.51 V (min = +1.40 V, max = +1.60 V)
in5: +0.00 V (min = +0.78 V, max = +1.70 V)
fan1: 1614 RPM (min = 300 RPM)
fan2: 0 RPM (min = 300 RPM)
fan3: 2153 RPM (min = 200 RPM)
fan4: 0 RPM (min = 82 RPM)
fan5: 0 RPM (min = 82 RPM)
temp1: +54.0 C (low = -127.0 C, high = +88.0 C)
temp2: +0.0 C (low = -127.0 C, high = +88.0 C)
temp3: +0.0 C (low = -127.0 C, high = +60.0 C)
temp4: +0.0 C (low = -127.0 C, high = +55.0 C)
temp5: +48.0 C (low = -127.0 C, high = +75.0 C)
temp6: +44.0 C (low = -127.0 C, high = +80.0 C)
[-- Attachment #3: Type: text/plain, Size: 50 bytes --]
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
[-- Attachment #4: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (12 preceding siblings ...)
2011-05-07 16:23 ` Harry G McGavran Jr
@ 2011-05-07 16:26 ` Harry G McGavran Jr
2011-05-08 0:05 ` Harry G McGavran Jr
` (49 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-07 16:26 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
By the way -- here is the output from sensors-detect
with the latest i8k and emc6w201...
Harry McGavran
On Sat, 7 May 2011 13:47:21 +0200 Jean Delvare wrote:
> Hi Harry, Ric and Jeff,
>
> On Thu, 05 May 2011 10:40:28 -0600, Harry G McGavran Jr wrote:
> > I can hope for an lm-sensors driver...
>
> I found some time to work on EMC6W201 support and I have something for
> you to test. My standalone driver for this chip can be downloaded from:
> http://khali.linux-fr.org/devel/misc/emc6w201/
> You only need i2c-compat.h for kernels <= 2.6.32. I build-tested the
> driver down to kernel 2.6.27, older kernels may or may not work.
> emc6w201.conf is a template configuration file, copy to /etc/sensors.d
> and add statements as needed. Generic build instructions are available
> at:
> http://khali.linux-fr.org/devel/misc/INSTALL
>
> At this point the driver only supports basic monitoring, in read-only
> mode. It seems to work reasonably well on the dumps sent by Harry and
> Jeff, but real hardware can behave differently.
>
> Anyway, let me know how it goes.
>
> --
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
[-- Attachment #2: sensors-detect.out3 --]
[-- Type: application/octet-stream , Size: 7383 bytes --]
# sensors-detect revision 5818 (2010-01-18 17:22:07 +0100)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0XC837
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
Intel Core family thermal sensor... No
Intel Atom thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Next adapter: NVIDIA i2c adapter (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively): Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Next adapter: SMBus I801 adapter at e8a0 (i2c-3)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Handled by driver `emc6w201' (already loaded), chip type `emc6w201'
(note: this is probably NOT a sensor chip!)
Client found at address 0x4d
Probing for `National Semiconductor LM75'... No
Probing for `Dallas Semiconductor DS75'... No
Probing for `Dallas Semiconductor DS1621/DS1631'... No
Probing for `Analog Devices ADM1021'... No
Probing for `Analog Devices ADM1021A/ADM1023'... No
Probing for `Maxim MAX1617'... No
Probing for `Maxim MAX1617A'... No
Probing for `Maxim MAX1668'... No
Probing for `Maxim MAX1805'... No
Probing for `Maxim MAX1989'... No
Probing for `Maxim MAX6655/MAX6656'... No
Probing for `TI THMC10'... No
Probing for `National Semiconductor LM84'... No
Probing for `Genesys Logic GL523SM'... No
Probing for `Onsemi MC1066'... No
Probing for `Maxim MAX1618'... No
Probing for `Maxim MAX1619'... No
Probing for `National Semiconductor LM82/LM83'... No
Probing for `National Semiconductor LM89/LM99'... No
Probing for `Analog Devices ADM1032'... No
Probing for `Maxim MAX6654/MAX6690'... No
Probing for `Maxim MAX6659'... No
Probing for `Maxim MAX6646'... No
Probing for `Maxim MAX6680/MAX6681'... No
Probing for `Texas Instruments TMP411'... No
Probing for `Texas Instruments TMP421'... No
Probing for `Texas Instruments TMP422'... No
Probing for `Texas Instruments TMP423'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `National Semiconductor LM73'... No
Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
Probing for `Analog Devices ADT7461'... No
Probing for `Fintek F75384S/M'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[-- Attachment #3: Type: text/plain, Size: 50 bytes --]
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
[-- Attachment #4: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (13 preceding siblings ...)
2011-05-07 16:26 ` Harry G McGavran Jr
@ 2011-05-08 0:05 ` Harry G McGavran Jr
2011-05-08 4:09 ` Jeff Rickman
` (48 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-08 0:05 UTC (permalink / raw)
To: lm-sensors
On Sat, 7 May 2011 13:47:21 +0200 Jean Delvare wrote:
> Hi Harry, Ric and Jeff,
>
> On Thu, 05 May 2011 10:40:28 -0600, Harry G McGavran Jr wrote:
> > I can hope for an lm-sensors driver...
>
> I found some time to work on EMC6W201 support and I have something for
> you to test. My standalone driver for this chip can be downloaded from:
> http://khali.linux-fr.org/devel/misc/emc6w201/
> You only need i2c-compat.h for kernels <= 2.6.32. I build-tested the
> driver down to kernel 2.6.27, older kernels may or may not work.
> emc6w201.conf is a template configuration file, copy to /etc/sensors.d
> and add statements as needed. Generic build instructions are available
> at:
> http://khali.linux-fr.org/devel/misc/INSTALL
>
> At this point the driver only supports basic monitoring, in read-only
> mode. It seems to work reasonably well on the dumps sent by Harry and
> Jeff, but real hardware can behave differently.
>
> Anyway, let me know how it goes.
>
> --
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
Hi Jean --
I spent a fair amount of time playing with the emc6w201 you mentioned
above. I wanted to let you know that it seems to be working really
well. It's an absolutely amazing relief to have this after all this time!
All the apps I've tried that depend on it seem to work fine.
For the time being I've left out emc6w201.conf from sensors.d
in case you do some more fine tuning of anything.
I have labels for temp1, temp5, and temp6; and fan1 and fan3
seem to be the fans that were reported by hddtemp.
Are you planning on any further changes? If so, I'll wait
before putting my .conf file in sensors.d.
Thanks a bundle!
Harry McGavran
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (14 preceding siblings ...)
2011-05-08 0:05 ` Harry G McGavran Jr
@ 2011-05-08 4:09 ` Jeff Rickman
2011-05-08 6:27 ` Jean Delvare
` (47 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-08 4:09 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 3537 bytes --]
On 5/7/2011 7:05 PM, Harry G McGavran Jr wrote:
> On Sat, 7 May 2011 13:47:21 +0200 Jean Delvare wrote:
>> Hi Harry, Ric and Jeff,
>>
>> On Thu, 05 May 2011 10:40:28 -0600, Harry G McGavran Jr wrote:
>>> I can hope for an lm-sensors driver...
>>
>> I found some time to work on EMC6W201 support and I have something for
>> you to test. My standalone driver for this chip can be downloaded from:
>> http://khali.linux-fr.org/devel/misc/emc6w201/
>> You only need i2c-compat.h for kernels<= 2.6.32. I build-tested the
>> driver down to kernel 2.6.27, older kernels may or may not work.
>> emc6w201.conf is a template configuration file, copy to /etc/sensors.d
>> and add statements as needed. Generic build instructions are available
>> at:
>> http://khali.linux-fr.org/devel/misc/INSTALL
>>
>> At this point the driver only supports basic monitoring, in read-only
>> mode. It seems to work reasonably well on the dumps sent by Harry and
>> Jeff, but real hardware can behave differently.
>>
>> Anyway, let me know how it goes.
>>
>> --
>> Jean Delvare
>> http://khali.linux-fr.org/wishlist.html
>
> Hi Jean --
>
> I spent a fair amount of time playing with the emc6w201 you mentioned
> above. I wanted to let you know that it seems to be working really
> well. It's an absolutely amazing relief to have this after all this time!
>
> All the apps I've tried that depend on it seem to work fine.
>
> For the time being I've left out emc6w201.conf from sensors.d
> in case you do some more fine tuning of anything.
>
> I have labels for temp1, temp5, and temp6; and fan1 and fan3
> seem to be the fans that were reported by hddtemp.
>
> Are you planning on any further changes? If so, I'll wait
> before putting my .conf file in sensors.d.
>
> Thanks a bundle!
>
> Harry McGavran
>
>
>
>
>
I just tried out the "i8k.c" code from the link shown above. I still get
a crash in Syslog and messages on the Console when loading the new
module. The machine still runs so the crash doesn't appear to be "fatal".
My testing steps:
(1) Completely remove the "i8k" module supplied by Fedora to a "safe"
location. It is not being used on my machine per "lsmod".
(2) Run "depmod -a"
(3) Build the new "i8k" module, but leave it where it is built
(4) Reboot, just to be certain the legacy "i8k" module isn't being loaded
(5) Copy the new "i8k" module to /lib/modules/`uname
-r`/kernel/drivers/hwmon
(6) Run "depmod -a" again
(7) Run "modprobe -v i8k"
At this point I get Console messages and a crashdump to Syslog. See
attached text file for details.
With the new "i8k" module loaded per "lsmod", a "lock up" occurs when
accessing the I2C bus in "sensors-detect" version 5946. A "ctrl-C" is
required to get the script running again. Output at the lock up follows:
Using driver 'i2c-i801' for device 0000:00:1f.3 Intel 82801EB ICH5
Module i2c-dev loaded successfully.
I can sit and wait on this output for minutes unless I issue a "ctrl-C"
to continue script processing. That is not normal behavior.
Harry, is your Dell machine a single CPU or a dual-CPU system? Also,
what Dell BIOS version are you using? I'm curious to know what is
different. My system has 2 physical Intel Xeon 3.0 GHz cpu that are also
hyperthreaded. My Dell BIOS is A07; "dmidecode" will reflect that in
"Handle 0x000" and so will a machine reboot. There is 2G of DRAM
onboard. I am running Fedora Core 14 x86_64. "uname -a" output follows:
Linux xx.xx.xx.xx 2.6.35.12-90.fc14.x86_64 #1 SMP Fri Apr 22 16:01:29
UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[-- Attachment #2: More_Dell_Sensors_Testing.txt --]
[-- Type: text/plain, Size: 26335 bytes --]
[root@XX sensors]# modprobe -v i8k
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/hwmon/i8k.ko
Message from syslogd@XX at May 7 22:35:39 ...
kernel:[ 261.541043] invalid opcode: 0000 [#1] SMP
Message from syslogd@XX at May 7 22:35:39 ...
kernel:[ 261.541114] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
Message from syslogd@XX at May 7 22:35:39 ...
kernel:[ 261.541131] Stack:
Message from syslogd@XX at May 7 22:35:39 ...
kernel:[ 261.541131] Call Trace:
Message from syslogd@XX at May 7 22:35:39 ...
kernel:[ 261.541131] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
Segmentation fault
[root@XX sensors]# tail -40 /var/log/messages
May 7 22:35:19 XX ntpd[1394]: 0.0.0.0 c614 04 freq_mode
May 7 22:35:20 XX ntpd[1394]: 0.0.0.0 c618 08 no_sys_peer
May 7 22:35:39 XX kernel: [ 261.541043] invalid opcode: 0000 [#1] SMP
May 7 22:35:39 XX kernel: [ 261.541114] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
May 7 22:35:39 XX kernel: [ 261.541131] CPU 2
May 7 22:35:39 XX kernel: [ 261.541131] Modules linked in: i8k(+) act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink p4_clockmod freq_table speedstep_lib e1000 iTCO_wdt iT
May 7 22:35:39 XX kernel: CO_vendor_support e752x_edac serio_raw i2c_i801 edac_core shpchp dcdbas microcode firewire_ohci firewire_core crc_itu_t nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: mperf]
May 7 22:35:39 XX kernel: [ 261.541131]
May 7 22:35:39 XX kernel: [ 261.541131] Pid: 1736, comm: modprobe Not tainted 2.6.35.12-90.fc14.x86_64 #1 0U7565/Precision WorkStation 670
May 7 22:35:39 XX kernel: [ 261.541131] RIP: 0010:[<ffffffffa03f7041>] [<ffffffffa03f7041>] i8k_smm+0x41/0x65 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] RSP: 0018:ffff88007e0b5e90 EFLAGS: 00010246
May 7 22:35:39 XX kernel: [ 261.541131] RAX: ffff88007e0b5ea8 RBX: 0000000000000000 RCX: 0000000000000000
May 7 22:35:39 XX kernel: [ 261.541131] RDX: 000000000000fea3 RSI: 0000000000000000 RDI: 0000000000000000
May 7 22:35:39 XX kernel: [ 261.541131] RBP: ffff88007e0b5e98 R08: ffff88007e0b5ea8 R09: 000000000000fea3
May 7 22:35:39 XX kernel: [ 261.541131] R10: ffffffffa03f81e0 R11: 0000000000000000 R12: 0000000000000000
May 7 22:35:39 XX kernel: [ 261.541131] R13: 00007f3d6ee28010 R14: 0000000000000000 R15: 00000000014826c0
May 7 22:35:39 XX kernel: [ 261.541131] FS: 00007f3d6ee8a720(0000) GS:ffff880002080000(0000) knlGS:0000000000000000
May 7 22:35:39 XX kernel: [ 261.541131] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
May 7 22:35:39 XX kernel: [ 261.541131] CR2: 00007f3d6ee98000 CR3: 000000007e571000 CR4: 00000000000006e0
May 7 22:35:39 XX kernel: [ 261.541131] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 7 22:35:39 XX kernel: [ 261.541131] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 7 22:35:39 XX kernel: [ 261.541131] Process modprobe (pid: 1736, threadinfo ffff88007e0b4000, task ffff88007e959740)
May 7 22:35:39 XX kernel: [ 261.541131] Stack:
May 7 22:35:39 XX kernel: [ 261.541131] ffffffffa03fb000 ffff88007e0b5ec8 ffffffffa03f722c 000000000000fea3
May 7 22:35:39 XX kernel: [ 261.541131] <0> 0000000000000000 0000000000000000 ffffffffa03f7429 ffff88007e0b5f08
May 7 22:35:39 XX kernel: [ 261.541131] <0> ffffffffa03fb0a7 00007f3d6ee28010 0000000000000000 ffff88007e0b5f28
May 7 22:35:39 XX kernel: [ 261.541131] Call Trace:
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffffa03fb000>] ? i8k_init+0x0/0x3a4 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffffa03f722c>] i8k_get_dell_signature+0x28/0x48 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffffa03f7429>] ? i8k_get_dmi_data+0xe/0x2c [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffffa03fb0a7>] i8k_init+0xa7/0x3a4 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffff8106ae50>] ? __blocking_notifier_call_chain+0x56/0x60
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffffa03fb000>] ? i8k_init+0x0/0x3a4 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffff810021a1>] do_one_initcall+0x5e/0x155
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffff8107d155>] sys_init_module+0xa6/0x1e4
May 7 22:35:39 XX kernel: [ 261.541131] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
May 7 22:35:39 XX kernel: [ 261.541131] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
May 7 22:35:39 XX kernel: [ 261.541131] RIP [<ffffffffa03f7041>] i8k_smm+0x41/0x65 [i8k]
May 7 22:35:39 XX kernel: [ 261.541131] RSP <ffff88007e0b5e90>
May 7 22:35:39 XX kernel: [ 261.546969] ---[ end trace 5c82ed210ed55e34 ]---
[root@XX sensors]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 750.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5984.55
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 750.000
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5984.80
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 750.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5984.72
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 750.000
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5984.79
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
[root@XX sensors]# dmidecode | more
# dmidecode 2.11
SMBIOS 2.3 present.
101 structures occupying 3625 bytes.
Table at 0x000F0450.
Handle 0xDA00, DMI type 218, 53 bytes
OEM-specific Type
Header and Data:
DA 35 00 DA B2 00 17 4B 0E 38 00 00 80 00 80 01
00 02 80 02 80 01 00 00 A0 00 A0 01 00 58 00 58
00 01 00 59 00 59 00 01 00 05 80 05 80 01 00 FF
FF 00 00 00 00
Handle 0xDA01, DMI type 218, 83 bytes
OEM-specific Type
Header and Data:
DA 53 01 DA B2 00 17 4B 0E 38 00 20 F3 20 F3 00
00 10 F3 10 F3 00 00 30 F3 30 F3 00 00 21 F3 21
F3 00 00 11 F3 11 F3 00 00 31 F3 31 F3 00 00 10
F5 10 F5 00 00 11 F5 11 F5 00 00 12 F5 12 F5 00
00 13 F5 13 F5 00 00 00 00 14 F5 00 00 FF FF 00
00 00 00
Handle 0xDA02, DMI type 218, 137 bytes
OEM-specific Type
Header and Data:
DA 89 02 DA B2 00 17 4B 0E 38 00 20 F4 20 F4 00
00 10 F4 10 F4 00 00 30 F4 30 F4 00 00 40 F4 40
F4 00 00 21 F4 21 F4 00 00 11 F4 11 F4 00 00 31
F4 31 F4 00 00 41 F4 41 F4 00 00 22 F4 22 F4 00
00 12 F4 12 F4 00 00 32 F4 32 F4 00 00 42 F4 42
F4 00 00 23 F4 23 F4 00 00 13 F4 13 F4 00 00 33
F4 33 F4 00 00 43 F4 43 F4 00 00 24 F4 24 F4 00
00 14 F4 14 F4 00 00 34 F4 34 F4 00 00 44 F4 44
F4 00 00 FF FF 00 00 00 00
Handle 0xDA03, DMI type 218, 161 bytes
OEM-specific Type
Header and Data:
DA A1 03 DA B2 00 17 4B 0E 38 00 25 F4 25 F4 00
00 15 F4 15 F4 00 00 35 F4 35 F4 00 00 45 F4 45
F4 00 00 26 F4 26 F4 00 00 16 F4 16 F4 00 00 36
F4 36 F4 00 00 46 F4 46 F4 00 00 27 F4 27 F4 00
00 17 F4 17 F4 00 00 37 F4 37 F4 00 00 47 F4 47
F4 00 00 28 F4 28 F4 00 00 18 F4 18 F4 00 00 38
F4 38 F4 00 00 48 F4 48 F4 00 00 29 F4 29 F4 00
00 19 F4 19 F4 00 00 39 F4 39 F4 00 00 49 F4 49
F4 00 00 2A F4 2A F4 00 00 1A F4 1A F4 00 00 3A
F4 3A F4 00 00 4A F4 4A F4 00 00 FF FF 00 00 00
00
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: Dell Inc.
Version: A07
Release Date: 03/15/2006
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 512 kB
Characteristics:
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
[root@XX sensors]# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
[root@XX sensors]# sensors-detect
# sensors-detect revision 5946 (2011-03-23 11:54:44 +0100)
# System: Dell Inc. Precision WorkStation 670
# Board: Dell Inc. 0U7565
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... Yes
Found `SMSC EMC2700LPC Super IO'
(no information available)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5
Module i2c-dev loaded successfully.
[^C required at this point for script to continue...not normal]
Next adapter: nouveau-0000:05:00.0-0 (i2c-0)
Do you want to scan it? (YES/no/selectively):
Next adapter: nouveau-0000:05:00.0-1 (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: SMBus I801 adapter at ece0 (i2c-2)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `SMSC EMC6D103S'... No
Probing for `Winbond WPCD377I'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Analog Devices ADT7490'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `National Semiconductor LM94'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Nuvoton W83795G/ADG'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG/W83667HG/W83677HG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Maxim MAX6639'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `SMSC EMC2103'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
[root@XX sensors]# sensors -v
sensors version 3.3.0 with libsensors version 3.3.0
[root@XX sensors]# lsmod
Module Size Used by
i2c_dev 7846 0
i8k 15982 1 <-- module is loaded...
act_police 3875 0
cls_flow 6910 0
cls_fw 4086 0
cls_u32 6651 0
sch_tbf 4287 0
sch_prio 4047 0
sch_htb 12694 0
sch_hfsc 12580 0
sch_ingress 1962 0
sch_sfq 5282 0
xt_time 1981 0
xt_connlimit 3260 0
xt_realm 1082 0
iptable_raw 1486 0
xt_comment 1056 18
xt_recent 8395 0
xt_policy 2366 0
ipt_ULOG 11158 0
ipt_REDIRECT 1734 0
ipt_NETMAP 1742 0
ipt_MASQUERADE 2353 0
ipt_ECN 1865 0
ipt_ecn 1449 0
ipt_CLUSTERIP 6732 0
ipt_ah 2238 0
ipt_addrtype 1967 3
nf_nat_tftp 1009 0
nf_nat_snmp_basic 7935 0
nf_nat_sip 5764 0
nf_nat_pptp 4388 0
nf_nat_proto_gre 2664 1 nf_nat_pptp
nf_nat_irc 1793 0
nf_nat_h323 8107 0
nf_nat_ftp 2176 0
nf_nat_amanda 1187 0
ts_kmp 2013 5
nf_conntrack_amanda 2836 1 nf_nat_amanda
nf_conntrack_sane 5418 0
nf_conntrack_tftp 4673 1 nf_nat_tftp
nf_conntrack_sip 20747 1 nf_nat_sip
nf_conntrack_proto_sctp 10516 0
nf_conntrack_pptp 10591 1 nf_nat_pptp
nf_conntrack_proto_gre 6258 1 nf_conntrack_pptp
nf_conntrack_netlink 16349 0
nf_conntrack_netbios_ns 1574 0
nf_conntrack_irc 5174 1 nf_nat_irc
nf_conntrack_h323 61523 1 nf_nat_h323
nf_conntrack_ftp 11381 1 nf_nat_ftp
xt_TPROXY 2190 0
nf_tproxy_core 2267 1 xt_TPROXY,[permanent]
xt_tcpmss 1533 0
xt_pkttype 1152 0
xt_physdev 1810 0
xt_owner 1194 0
xt_NFQUEUE 2107 0
xt_NFLOG 1201 0
nfnetlink_log 7995 1 xt_NFLOG
xt_multiport 2644 4
xt_mark 1323 1
xt_mac 1124 0
xt_limit 2092 0
xt_length 1312 0
xt_iprange 2199 0
xt_helper 1439 0
xt_hashlimit 6913 0
xt_DSCP 2366 0
xt_dscp 1862 0
xt_dccp 2077 0
xt_connmark 1996 0
xt_CLASSIFY 1075 0
ipt_LOG 5435 2
iptable_nat 5018 0
nf_nat 20289 12 ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,iptable_nat
iptable_mangle 1695 1
nfnetlink 3856 2 nf_conntrack_netlink,nfnetlink_log
p4_clockmod 4515 2
freq_table 3955 1 p4_clockmod
speedstep_lib 4822 1 p4_clockmod
e1000 149547 0
iTCO_wdt 11256 0
iTCO_vendor_support 2610 1 iTCO_wdt
e752x_edac 11428 0
serio_raw 4640 0
i2c_i801 11088 0
edac_core 41336 3 e752x_edac
shpchp 30251 0
dcdbas 8540 0
microcode 18500 0
firewire_ohci 21314 0
firewire_core 45817 1 firewire_ohci
crc_itu_t 1563 1 firewire_core
nouveau 411931 1
ttm 55166 1 nouveau
drm_kms_helper 25961 1 nouveau
drm 178014 3 nouveau,ttm,drm_kms_helper
i2c_algo_bit 5205 1 nouveau
video 21637 1 nouveau
output 2253 1 video
i2c_core 27212 6 i2c_dev,i2c_i801,nouveau,drm_kms_helper,drm,i2c_algo_bit
[root@XX sensors]# cat /proc/meminfo
MemTotal: 2055000 kB
MemFree: 1833592 kB
Buffers: 22204 kB
Cached: 135108 kB
SwapCached: 0 kB
Active: 123664 kB
Inactive: 46660 kB
Active(anon): 13200 kB
Inactive(anon): 12 kB
Active(file): 110464 kB
Inactive(file): 46648 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 2044924 kB
SwapFree: 2044924 kB
Dirty: 80 kB
Writeback: 0 kB
AnonPages: 13000 kB
Mapped: 9136 kB
Shmem: 216 kB
Slab: 24464 kB
SReclaimable: 14864 kB
SUnreclaim: 9600 kB
KernelStack: 1072 kB
PageTables: 3080 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3072424 kB
Committed_AS: 64124 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 290660 kB
VmallocChunk: 34359435968 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6696 kB
DirectMap2M: 2088960 kB
[root@XX sensors]# free
total used free shared buffers cached
Mem: 2055000 221408 1833592 0 22212 135108
-/+ buffers/cache: 64088 1990912
Swap: 2044924 0 2044924
[root@XX sensors]# uname -a
Linux XX.XX.XX.XX 2.6.35.12-90.fc14.x86_64 #1 SMP Fri Apr 22 16:01:29 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (15 preceding siblings ...)
2011-05-08 4:09 ` Jeff Rickman
@ 2011-05-08 6:27 ` Jean Delvare
2011-05-08 8:39 ` Hans de Goede
` (46 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-08 6:27 UTC (permalink / raw)
To: lm-sensors
Hi Jeff,
On Sat, 07 May 2011 23:09:40 -0500, Jeff Rickman wrote:
> I just tried out the "i8k.c" code from the link shown above. I still get
> a crash in Syslog and messages on the Console when loading the new
> module. The machine still runs so the crash doesn't appear to be "fatal".
Well you had already tried exactly this version, hadn't you?
>
> My testing steps:
> (1) Completely remove the "i8k" module supplied by Fedora to a "safe"
> location. It is not being used on my machine per "lsmod".
Did you try loading this original i8k driver? Did it work? What are the
contents of /proc/i8k then?
If the original works and mine fails, please send me the two .ko files
in private and I'll try to figure out how they differ. Even better if
you can get the exact kernel sources used by Fedora to build your
running kernel so that I can also compare the source code (the source
file is drivers/misc/i8k.c in the kernel tree.)
> (2) Run "depmod -a"
> (3) Build the new "i8k" module, but leave it where it is built
> (4) Reboot, just to be certain the legacy "i8k" module isn't being loaded
> (5) Copy the new "i8k" module to /lib/modules/`uname
> -r`/kernel/drivers/hwmon
> (6) Run "depmod -a" again
> (7) Run "modprobe -v i8k"
Note that you could simply use insmod with full path to the new module,
so you don't have to install it.
> At this point I get Console messages and a crashdump to Syslog. See
> attached text file for details.
>
> With the new "i8k" module loaded per "lsmod", a "lock up" occurs when
> accessing the I2C bus in "sensors-detect" version 5946. A "ctrl-C" is
> required to get the script running again. Output at the lock up follows:
>
> Using driver 'i2c-i801' for device 0000:00:1f.3 Intel 82801EB ICH5
> Module i2c-dev loaded successfully.
>
> I can sit and wait on this output for minutes unless I issue a "ctrl-C"
> to continue script processing. That is not normal behavior.
With the kernel crash you got, it's nor surprising that anything
related to kernel module loading or unloading will hang.
> Harry, is your Dell machine a single CPU or a dual-CPU system? Also,
> what Dell BIOS version are you using? I'm curious to know what is
> different. My system has 2 physical Intel Xeon 3.0 GHz cpu that are also
> hyperthreaded. My Dell BIOS is A07; "dmidecode" will reflect that in
> "Handle 0x000" and so will a machine reboot. There is 2G of DRAM
> onboard. I am running Fedora Core 14 x86_64. "uname -a" output follows:
>
> Linux xx.xx.xx.xx 2.6.35.12-90.fc14.x86_64 #1 SMP Fri Apr 22 16:01:29
> UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (16 preceding siblings ...)
2011-05-08 6:27 ` Jean Delvare
@ 2011-05-08 8:39 ` Hans de Goede
2011-05-08 9:18 ` Jean Delvare
` (45 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Hans de Goede @ 2011-05-08 8:39 UTC (permalink / raw)
To: lm-sensors
Hi,
On 05/08/2011 08:27 AM, Jean Delvare wrote:
> Hi Jeff,
>
> On Sat, 07 May 2011 23:09:40 -0500, Jeff Rickman wrote:
>> I just tried out the "i8k.c" code from the link shown above. I still get
>> a crash in Syslog and messages on the Console when loading the new
>> module. The machine still runs so the crash doesn't appear to be "fatal".
>
> Well you had already tried exactly this version, hadn't you?
>
>>
>> My testing steps:
>> (1) Completely remove the "i8k" module supplied by Fedora to a "safe"
>> location. It is not being used on my machine per "lsmod".
>
> Did you try loading this original i8k driver? Did it work? What are the
> contents of /proc/i8k then?
>
> If the original works and mine fails, please send me the two .ko files
> in private and I'll try to figure out how they differ. Even better if
> you can get the exact kernel sources used by Fedora to build your
> running kernel so that I can also compare the source code (the source
> file is drivers/misc/i8k.c in the kernel tree.)
>
Note if you (Jeff) can give me the output of "uname -a" I can quite easily
get the matching kernel sources and send Jean the i8k.c from that exact
version (assuming you're not running some homebrewn kernel).
In case you're wondering how, what I would do is go to koji (the Fedora
buildsystem):
http://koji.fedoraproject.org/koji/
Search for kernel, go to the kernel you're running, download an install
the src.rpm, and do a "rpmbuild -bp kernel.spec", which will extract the
sources, apply all patches and then exit (it will do the %prep fase of
the spec file). And then I've an exploded source tree, with the exact
sources used to build your kernel.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (17 preceding siblings ...)
2011-05-08 8:39 ` Hans de Goede
@ 2011-05-08 9:18 ` Jean Delvare
2011-05-08 9:25 ` Jean Delvare
` (44 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-08 9:18 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Sat, 07 May 2011 10:23:57 -0600, Harry G McGavran Jr wrote:
> Here is the output from /usr/bin/sensors with the
> ecm6w201 driver you just gave us AND from the
> new i8k driver you mentioned in an earlier e-mail today.
>
> i8k-virtual-0
> Adapter: Virtual device
> Left Fan: 64710 RPM
> Right Fan: 48420 RPM
> CPU: -22.0 C
I presume that you had to pass force=1 or ignore_dmi=1 or both to get
the i8k driver to load at all?
The output above revealed a bug in my version of the i8k driver, the
-22 is really an error code (EINVAL) and not a temperature, so it
should be reported as such. Did you ever see a valid temperature
reported? If it's always wrong, I guess the driver shouldn't create the
entry in the first place. I've just fixed that, you can download the
updated driver.
As for the fan speed values, they are off by a factor 30. Load the i8k
driver with option fan_mult=1 (the default is 30) and you'll get correct
fan speeds. You'll notice these are the same speeds as reported by the
emc6w201 driver. This is good because it means both drivers are working
fine, but this is also bad because it means that both drivers poke at
the same piece of hardware. So you should really only use i8k, or
emc6w201, but not both drivers at the same time.
> emc6w201-i2c-3-2e
> Adapter: SMBus I801 adapter at e8a0
> in0: +1.82 V (min = +1.64 V, max = +1.98 V)
> in1: +1.26 V (min = +0.78 V, max = +1.70 V)
> in2: +3.33 V (min = +3.08 V, max = +3.52 V)
> in3: +5.10 V (min = +4.66 V, max = +5.34 V)
> in4: +1.51 V (min = +1.40 V, max = +1.60 V)
> in5: +0.00 V (min = +0.78 V, max = +1.70 V)
> fan1: 1614 RPM (min = 300 RPM)
> fan2: 0 RPM (min = 300 RPM)
> fan3: 2153 RPM (min = 200 RPM)
> fan4: 0 RPM (min = 82 RPM)
> fan5: 0 RPM (min = 82 RPM)
> temp1: +54.0 C (low = -127.0 C, high = +88.0 C)
> temp2: +0.0 C (low = -127.0 C, high = +88.0 C)
> temp3: +0.0 C (low = -127.0 C, high = +60.0 C)
> temp4: +0.0 C (low = -127.0 C, high = +55.0 C)
> temp5: +48.0 C (low = -127.0 C, high = +75.0 C)
> temp6: +44.0 C (low = -127.0 C, high = +80.0 C)
This looks pretty good, I'd say. I guess you have a single CPU in the
machine, which explains the missing in5 and temp2. in1 would be the CPU
core voltage, and temp1 the CPU temperature. If the machine is using
DDR2 memory, in0 may be the memory voltage. This would leave maybe in4
for +12V, with scaling factor 8, or for battery voltage with scaling
factor 2. BTW, does the BIOS print any temperature, voltage or fan
speed? This would help us get the labels and scaling factors right.
> Thanks for your work on this!!!
You're welcome.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (18 preceding siblings ...)
2011-05-08 9:18 ` Jean Delvare
@ 2011-05-08 9:25 ` Jean Delvare
2011-05-08 11:19 ` Jeff Rickman
` (43 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-08 9:25 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Sat, 07 May 2011 18:05:08 -0600, Harry G McGavran Jr wrote:
> On Sat, 7 May 2011 13:47:21 +0200 Jean Delvare wrote:
> > I found some time to work on EMC6W201 support and I have something for
> > you to test. My standalone driver for this chip can be downloaded from:
> > http://khali.linux-fr.org/devel/misc/emc6w201/
> > You only need i2c-compat.h for kernels <= 2.6.32. I build-tested the
> > driver down to kernel 2.6.27, older kernels may or may not work.
> > emc6w201.conf is a template configuration file, copy to /etc/sensors.d
> > and add statements as needed. Generic build instructions are available
> > at:
> > http://khali.linux-fr.org/devel/misc/INSTALL
> >
> > At this point the driver only supports basic monitoring, in read-only
> > mode. It seems to work reasonably well on the dumps sent by Harry and
> > Jeff, but real hardware can behave differently.
> >
> > Anyway, let me know how it goes.
>
> I spent a fair amount of time playing with the emc6w201 you mentioned
> above. I wanted to let you know that it seems to be working really
> well. It's an absolutely amazing relief to have this after all this time!
>
> All the apps I've tried that depend on it seem to work fine.
Great :)
> For the time being I've left out emc6w201.conf from sensors.d
> in case you do some more fine tuning of anything.
>
> I have labels for temp1, temp5, and temp6; and fan1 and fan3
> seem to be the fans that were reported by hddtemp.
I guess you mean i8k, not hddtemp. And yes, I agree, see my warning in
a previous reply.
If/when you have a good configuration file for your system, please
share it and I'll put it on the wiki.
> Are you planning on any further changes? If so, I'll wait
> before putting my .conf file in sensors.d.
Further possible improvements to the driver would be extra features
(e.g. temperature offsets, alarm bits, maybe fan control.) The
monitoring part should be as good as we can get already, so I don't
expect any change that would cause incompatibilities in the
configuration file.
BTW, you can test your configuration file with "sensors -c" first, and
only copy it to /etc/sensors.d/ when you're happy with the results.
This avoids doing the tuning work as root.
> Thanks a bundle!
You're welcome. Wish list below - hint hint ;)
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (19 preceding siblings ...)
2011-05-08 9:25 ` Jean Delvare
@ 2011-05-08 11:19 ` Jeff Rickman
2011-05-08 12:29 ` Jean Delvare
` (42 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-08 11:19 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 3888 bytes --]
Hello jean,
On 5/8/2011 1:27 AM, Jean Delvare wrote:
> Hi Jeff,
>
> On Sat, 07 May 2011 23:09:40 -0500, Jeff Rickman wrote:
>> I just tried out the "i8k.c" code from the link shown above. I still get
>> a crash in Syslog and messages on the Console when loading the new
>> module. The machine still runs so the crash doesn't appear to be "fatal".
>
> Well you had already tried exactly this version, hadn't you?
>
>>
>> My testing steps:
>> (1) Completely remove the "i8k" module supplied by Fedora to a "safe"
>> location. It is not being used on my machine per "lsmod".
>
> Did you try loading this original i8k driver? Did it work? What are the
> contents of /proc/i8k then?
>
> If the original works and mine fails, please send me the two .ko files
> in private and I'll try to figure out how they differ. Even better if
> you can get the exact kernel sources used by Fedora to build your
> running kernel so that I can also compare the source code (the source
> file is drivers/misc/i8k.c in the kernel tree.)
>
>> (2) Run "depmod -a"
>> (3) Build the new "i8k" module, but leave it where it is built
>> (4) Reboot, just to be certain the legacy "i8k" module isn't being loaded
>> (5) Copy the new "i8k" module to /lib/modules/`uname
>> -r`/kernel/drivers/hwmon
>> (6) Run "depmod -a" again
>> (7) Run "modprobe -v i8k"
>
> Note that you could simply use insmod with full path to the new module,
> so you don't have to install it.
>
>> At this point I get Console messages and a crashdump to Syslog. See
>> attached text file for details.
>>
>> With the new "i8k" module loaded per "lsmod", a "lock up" occurs when
>> accessing the I2C bus in "sensors-detect" version 5946. A "ctrl-C" is
>> required to get the script running again. Output at the lock up follows:
>>
>> Using driver 'i2c-i801' for device 0000:00:1f.3 Intel 82801EB ICH5
>> Module i2c-dev loaded successfully.
>>
>> I can sit and wait on this output for minutes unless I issue a "ctrl-C"
>> to continue script processing. That is not normal behavior.
>
> With the kernel crash you got, it's nor surprising that anything
> related to kernel module loading or unloading will hang.
>
>> Harry, is your Dell machine a single CPU or a dual-CPU system? Also,
>> what Dell BIOS version are you using? I'm curious to know what is
>> different. My system has 2 physical Intel Xeon 3.0 GHz cpu that are also
>> hyperthreaded. My Dell BIOS is A07; "dmidecode" will reflect that in
>> "Handle 0x000" and so will a machine reboot. There is 2G of DRAM
>> onboard. I am running Fedora Core 14 x86_64. "uname -a" output follows:
>>
>> Linux xx.xx.xx.xx 2.6.35.12-90.fc14.x86_64 #1 SMP Fri Apr 22 16:01:29
>> UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>
[testing with original "i8k" module]
(1) Removed new "i8k" module from /lib/modules tree
(2) Checked "/proc/i8k". No such file or directory
(3) Copied original "i8k" module back to it's location in:
/lib/modules/`uname -r`/drivers/char
(4) Ran "depmod -a"
(5) Rebooted PC to obtain known stable state
After reboot...
(6) Checked "/proc/i8k". No such file or directory
(7) Checked "lsmod". "i8k" is not loaded
(8) Attempted to load original "i8k" but it crashed.
Crash output is attached.
(9) Rechecked "/proc/i8k". No such file or directory
(10) Rebooted PC to return to known stable state
I sent along my "uname -a" output to Hans so he could locate the correct
source files to send to you privately. I bet he can find the correct
source code files and mail them faster than I can, but I will try.
As for the system kernel, I am running a "stock as delivered by Fedora"
kernel; I did not do any recompiling or anything else to it. I loaded
the following Fedora "packages" via "yum":
kernel-devel
kernel-headers
make
gcc
Those "packages" were all I needed to compile your "i8k.c" file using
the "Makefile" also found in the same folder. Again, nothing special here.
[-- Attachment #2: Even_More_Dell_Sensors_Testing.txt --]
[-- Type: text/plain, Size: 6875 bytes --]
[placing original driver back where it came from then loading it]
[root@XX drivers]# modprobe -v i8k
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
Segmentation fault
Message from syslogd@XX at May 8 05:55:32 ...
kernel:[ 151.734753] invalid opcode: 0000 [#1] SMP
[root@XX drivers]#
Message from syslogd@XX at May 8 05:55:32 ...
kernel:[ 151.734830] last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
Message from syslogd@XX at May 8 05:55:32 ...
kernel:[ 151.735678] Stack:
Message from syslogd@XX at May 8 05:55:32 ...
kernel:[ 151.735678] Call Trace:
Message from syslogd@XX at May 8 05:55:32 ...
kernel:[ 151.735678] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
[root@XX drivers]# tail -50 /var/log/messages
May 8 05:53:31 XX smartd[1495]: Device: /dev/sda [SAT], enabled SMART Attribute Autosave.
May 8 05:53:31 XX smartd[1495]: Device: /dev/sda [SAT], enabled SMART Automatic Offline Testing.
May 8 05:53:31 XX smartd[1495]: Device: /dev/sda [SAT], is SMART capable. Adding to "monitor" list.
May 8 05:53:31 XX smartd[1495]: Monitoring 1 ATA and 0 SCSI devices
May 8 05:53:32 XX smartd[1495]: Device: /dev/sda [SAT], initial Temperature is 34 Celsius (Min/Max ??/34)
May 8 05:53:32 XX smartd[1497]: smartd has fork()ed into background mode. New PID=1497.
May 8 05:53:44 XX kernel: [ 44.050113] readahead-collector: sorting
May 8 05:53:44 XX kernel: [ 44.189440] readahead-collector: finished
May 8 05:53:45 XX ntpd[1403]: Deferring DNS for 0.fedora.pool.ntp.org 1
May 8 05:53:45 XX ntpd[1403]: 0.0.0.0 c016 06 restart
May 8 05:53:45 XX ntpd[1403]: 0.0.0.0 c012 02 freq_set kernel -35.543 PPM
May 8 05:53:47 XX ntpd_intres[1530]: DNS 0.fedora.pool.ntp.org -> 184.105.182.7
May 8 05:55:32 XX kernel: [ 151.734753] invalid opcode: 0000 [#1] SMP
May 8 05:55:32 XX kernel: [ 151.734830] last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
May 8 05:55:32 XX kernel: [ 151.734882] CPU 3
May 8 05:55:32 XX kernel: [ 151.734902] Modules linked in: i8k(+) act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink p4_clockmod freq_table speedstep_lib e1000 iTCO_wdt iT
May 8 05:55:32 XX kernel: CO_vendor_support shpchp e752x_edac i2c_i801 serio_raw edac_core dcdbas microcode firewire_ohci firewire_core crc_itu_t nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: mperf]
May 8 05:55:32 XX kernel: [ 151.735678]
May 8 05:55:32 XX kernel: [ 151.735678] Pid: 1674, comm: modprobe Not tainted 2.6.35.12-90.fc14.x86_64 #1 0U7565/Precision WorkStation 670
May 8 05:55:32 XX kernel: [ 151.735678] RIP: 0010:[<ffffffffa03f7041>] [<ffffffffa03f7041>] i8k_smm+0x41/0x65 [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] RSP: 0018:ffff88007d045ea0 EFLAGS: 00010246
May 8 05:55:32 XX kernel: [ 151.735678] RAX: ffff88007d045eb8 RBX: 0000000000000000 RCX: 0000000000000000
May 8 05:55:32 XX kernel: [ 151.735678] RDX: 000000000000fea3 RSI: 0000000000000000 RDI: 0000000000000000
May 8 05:55:32 XX kernel: [ 151.735678] RBP: ffff88007d045ea8 R08: ffff88007d045eb8 R09: 000000000000fea3
May 8 05:55:32 XX kernel: [ 151.735678] R10: ffffffffa03f7d10 R11: 0000000000000000 R12: 0000000000000000
May 8 05:55:32 XX kernel: [ 151.735678] R13: 0000000000db8040 R14: 0000000000000000 R15: 0000000000db16c0
May 8 05:55:32 XX kernel: [ 151.735678] FS: 00007f56f9747720(0000) GS:ffff8800020c0000(0000) knlGS:0000000000000000
May 8 05:55:32 XX kernel: [ 151.735678] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
May 8 05:55:32 XX kernel: [ 151.735678] CR2: 0000003a136e1200 CR3: 000000007d90c000 CR4: 00000000000006e0
May 8 05:55:32 XX kernel: [ 151.735678] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 8 05:55:32 XX kernel: [ 151.735678] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 8 05:55:32 XX kernel: [ 151.735678] Process modprobe (pid: 1674, threadinfo ffff88007d044000, task ffff88007e48dd00)
May 8 05:55:32 XX kernel: [ 151.735678] Stack:
May 8 05:55:32 XX kernel: [ 151.735678] ffffffffa03fb000 ffff88007d045ed8 ffffffffa03f71d2 000000000000fea3
May 8 05:55:32 XX kernel: [ 151.735678] <0> 0000000000000000 0000000000000000 ffffffffa03f721c ffff88007d045f08
May 8 05:55:32 XX kernel: [ 151.735678] <0> ffffffffa03fb0a7 ffff88007d045f28 ffffffff8106ae50 ffffffffa03fb000
May 8 05:55:32 XX kernel: [ 151.735678] Call Trace:
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffffa03fb000>] ? i8k_init+0x0/0x1ad [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffffa03f71d2>] i8k_get_dell_signature+0x28/0x48 [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffffa03f721c>] ? i8k_get_dmi_data+0xe/0x2c [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffffa03fb0a7>] i8k_init+0xa7/0x1ad [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffff8106ae50>] ? __blocking_notifier_call_chain+0x56/0x60
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffffa03fb000>] ? i8k_init+0x0/0x1ad [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffff810021a1>] do_one_initcall+0x5e/0x155
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffff8107d155>] sys_init_module+0xa6/0x1e4
May 8 05:55:32 XX kernel: [ 151.735678] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
May 8 05:55:32 XX kernel: [ 151.735678] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
May 8 05:55:32 XX kernel: [ 151.735678] RIP [<ffffffffa03f7041>] i8k_smm+0x41/0x65 [i8k]
May 8 05:55:32 XX kernel: [ 151.735678] RSP <ffff88007d045ea0>
May 8 05:55:32 XX kernel: [ 151.742261] ---[ end trace 9604dd0c176a3a68 ]---
[root@XX drivers]#
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (20 preceding siblings ...)
2011-05-08 11:19 ` Jeff Rickman
@ 2011-05-08 12:29 ` Jean Delvare
2011-05-08 12:40 ` Jeff Rickman
` (41 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-08 12:29 UTC (permalink / raw)
To: lm-sensors
On Sun, 08 May 2011 06:19:11 -0500, Jeff Rickman wrote:
> On 5/8/2011 1:27 AM, Jean Delvare wrote:
> > Did you try loading this original i8k driver? Did it work? What are the
> > contents of /proc/i8k then?
>
> [testing with original "i8k" module]
> (1) Removed new "i8k" module from /lib/modules tree
> (2) Checked "/proc/i8k". No such file or directory
> (3) Copied original "i8k" module back to it's location in:
> /lib/modules/`uname -r`/drivers/char
> (4) Ran "depmod -a"
> (5) Rebooted PC to obtain known stable state
>
> After reboot...
> (6) Checked "/proc/i8k". No such file or directory
> (7) Checked "lsmod". "i8k" is not loaded
> (8) Attempted to load original "i8k" but it crashed.
> Crash output is attached.
> (9) Rechecked "/proc/i8k". No such file or directory
> (10) Rebooted PC to return to known stable state
This means that my changes aren't responsible for the crash, nor is the
fact of building the driver standalone. So I will leave it to the
Fedora kernel maintainers to resolve, if you care and if they are
interested.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (21 preceding siblings ...)
2011-05-08 12:29 ` Jean Delvare
@ 2011-05-08 12:40 ` Jeff Rickman
2011-05-08 15:27 ` Harry G McGavran Jr
` (40 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-08 12:40 UTC (permalink / raw)
To: lm-sensors
On 5/8/2011 7:29 AM, Jean Delvare wrote:
> On Sun, 08 May 2011 06:19:11 -0500, Jeff Rickman wrote:
>> On 5/8/2011 1:27 AM, Jean Delvare wrote:
>>> Did you try loading this original i8k driver? Did it work? What are the
>>> contents of /proc/i8k then?
>>
>> [testing with original "i8k" module]
>> (1) Removed new "i8k" module from /lib/modules tree
>> (2) Checked "/proc/i8k". No such file or directory
>> (3) Copied original "i8k" module back to it's location in:
>> /lib/modules/`uname -r`/drivers/char
>> (4) Ran "depmod -a"
>> (5) Rebooted PC to obtain known stable state
>>
>> After reboot...
>> (6) Checked "/proc/i8k". No such file or directory
>> (7) Checked "lsmod". "i8k" is not loaded
>> (8) Attempted to load original "i8k" but it crashed.
>> Crash output is attached.
>> (9) Rechecked "/proc/i8k". No such file or directory
>> (10) Rebooted PC to return to known stable state
>
> This means that my changes aren't responsible for the crash, nor is the
> fact of building the driver standalone. So I will leave it to the
> Fedora kernel maintainers to resolve, if you care and if they are
> interested.
>
I agree with your comments.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (22 preceding siblings ...)
2011-05-08 12:40 ` Jeff Rickman
@ 2011-05-08 15:27 ` Harry G McGavran Jr
2011-05-09 3:32 ` Jeff Rickman
` (39 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-08 15:27 UTC (permalink / raw)
To: lm-sensors
On Sun, 8 May 2011 14:29:05 +0200 Jean Delvare wrote:
> On Sun, 08 May 2011 06:19:11 -0500, Jeff Rickman wrote:
> > On 5/8/2011 1:27 AM, Jean Delvare wrote:
> > > Did you try loading this original i8k driver? Did it work? What are the
> > > contents of /proc/i8k then?
> >
> > [testing with original "i8k" module]
> > (1) Removed new "i8k" module from /lib/modules tree
> > (2) Checked "/proc/i8k". No such file or directory
> > (3) Copied original "i8k" module back to it's location in:
> > /lib/modules/`uname -r`/drivers/char
> > (4) Ran "depmod -a"
> > (5) Rebooted PC to obtain known stable state
> >
> > After reboot...
> > (6) Checked "/proc/i8k". No such file or directory
> > (7) Checked "lsmod". "i8k" is not loaded
> > (8) Attempted to load original "i8k" but it crashed.
> > Crash output is attached.
> > (9) Rechecked "/proc/i8k". No such file or directory
> > (10) Rebooted PC to return to known stable state
>
> This means that my changes aren't responsible for the crash, nor is the
> fact of building the driver standalone. So I will leave it to the
> Fedora kernel maintainers to resolve, if you care and if they are
> interested.
>
> --
> Jean Delvare
Hi Jean (and others) ---
This morning I got up to find a number of messages in this thread.
I will comment in some of the queries made of me in it so that
people have the info, but it looks like things are pretty good anyway.
I have a single CPU Dell 670 with the A07 BIOS. I'm running Ubuntu Lucid
with the 2.6.32-31 kernel.
I didn't have any trouble with i2c_dev, i2c_801, the new i8k or
emc6w201.
I've now uninstalled the i8kutils package and i8k, and am using
only libsensors to monitor with. I'm guessing i8k really applies
only to Dell Insirion Laptops, but in any event emc6w201 gives
me everything in a much easier way to deal with.
Thanks again Jean! (I'm keeping your hints list at hand...)
Harry McGavran
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (23 preceding siblings ...)
2011-05-08 15:27 ` Harry G McGavran Jr
@ 2011-05-09 3:32 ` Jeff Rickman
2011-05-09 19:42 ` Jean Delvare
` (38 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-09 3:32 UTC (permalink / raw)
To: lm-sensors
On 5/8/2011 10:27 AM, Harry G McGavran Jr wrote:
> On Sun, 8 May 2011 14:29:05 +0200 Jean Delvare wrote:
>> On Sun, 08 May 2011 06:19:11 -0500, Jeff Rickman wrote:
>>> On 5/8/2011 1:27 AM, Jean Delvare wrote:
>>>> Did you try loading this original i8k driver? Did it work? What are the
>>>> contents of /proc/i8k then?
>>>
>>> [testing with original "i8k" module]
>>> (1) Removed new "i8k" module from /lib/modules tree
>>> (2) Checked "/proc/i8k". No such file or directory
>>> (3) Copied original "i8k" module back to it's location in:
>>> /lib/modules/`uname -r`/drivers/char
>>> (4) Ran "depmod -a"
>>> (5) Rebooted PC to obtain known stable state
>>>
>>> After reboot...
>>> (6) Checked "/proc/i8k". No such file or directory
>>> (7) Checked "lsmod". "i8k" is not loaded
>>> (8) Attempted to load original "i8k" but it crashed.
>>> Crash output is attached.
>>> (9) Rechecked "/proc/i8k". No such file or directory
>>> (10) Rebooted PC to return to known stable state
>>
>> This means that my changes aren't responsible for the crash, nor is the
>> fact of building the driver standalone. So I will leave it to the
>> Fedora kernel maintainers to resolve, if you care and if they are
>> interested.
>>
>> --
>> Jean Delvare
>
>
> Hi Jean (and others) ---
>
> This morning I got up to find a number of messages in this thread.
>
> I will comment in some of the queries made of me in it so that
> people have the info, but it looks like things are pretty good anyway.
>
> I have a single CPU Dell 670 with the A07 BIOS. I'm running Ubuntu Lucid
> with the 2.6.32-31 kernel.
>
> I didn't have any trouble with i2c_dev, i2c_801, the new i8k or
> emc6w201.
>
> I've now uninstalled the i8kutils package and i8k, and am using
> only libsensors to monitor with. I'm guessing i8k really applies
> only to Dell Insirion Laptops, but in any event emc6w201 gives
> me everything in a much easier way to deal with.
>
> Thanks again Jean! (I'm keeping your hints list at hand...)
>
>
> Harry McGavran
>
>
>
What Harry's comments tell me is the original "i8k" code lacks
appropriate code to operate in a SMP environment. I think the Console
messages are trying to say that for "non-programmers" like myself.
Note these differences:
- Harry has a single CPU; I have 2 CPU.
- We both run the same Dell BIOS A07 code.
- Harry's Linux kernel is slightly older than my 2.6.35.12-90 Fedora code.
- I think we would all agree that Jean's changes do not cause my crash
since that code works on Harry's machine but not on mine.
Time permitting, I will start doing the research to submit a properly
documented bug against Fedora Core 14 regarding this code. I suspect
this issue will also reside in FC15 so that is another point to check if
time allows. jean raises the real question: does anyone in the Fedora
team want to fix this?
In closing, I agree with Harry: it is very nice to have some hardware
monitoring in a Dell platform.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (24 preceding siblings ...)
2011-05-09 3:32 ` Jeff Rickman
@ 2011-05-09 19:42 ` Jean Delvare
2011-05-09 19:50 ` Harry G McGavran Jr
` (37 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-09 19:42 UTC (permalink / raw)
To: lm-sensors
Hi Jeff,
On Sun, 08 May 2011 22:32:16 -0500, Jeff Rickman wrote:
> What Harry's comments tell me is the original "i8k" code lacks
> appropriate code to operate in a SMP environment. I think the Console
> messages are trying to say that for "non-programmers" like myself.
>
> Note these differences:
> - Harry has a single CPU; I have 2 CPU.
This is a valuable observation. I presume that these CPUs are too old
to be multicore, best they could have it hyperthreading. Harry, can you
please share the contents of /proc/cpuinfo?
Jeff, could you please try booting with parameter max_cpus=1? I wonder
if it would make a difference. If it does, that would confirm your
theory.
> - We both run the same Dell BIOS A07 code.
> - Harry's Linux kernel is slightly older than my 2.6.35.12-90 Fedora code.
> - I think we would all agree that Jean's changes do not cause my crash
> since that code works on Harry's machine but not on mine.
>
> Time permitting, I will start doing the research to submit a properly
> documented bug against Fedora Core 14 regarding this code. I suspect
> this issue will also reside in FC15 so that is another point to check if
> time allows. jean raises the real question: does anyone in the Fedora
> team want to fix this?
I've seen this nug hit an openSUSE user (on a laptop with one
multi-core CPU), so it's definitely not specific to Fedora. It may be
related to the version of gcc used by the distribution though. If
Fedora people aren't interested, we may open a bug on
bugzilla.kernel.org instead.
> In closing, I agree with Harry: it is very nice to have some hardware
> monitoring in a Dell platform.
I'm glad you like it :)
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (25 preceding siblings ...)
2011-05-09 19:42 ` Jean Delvare
@ 2011-05-09 19:50 ` Harry G McGavran Jr
2011-05-09 20:07 ` Jean Delvare
` (36 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-09 19:50 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
On Mon, 9 May 2011 21:42:31 +0200 Jean Delvare wrote:
> Hi Jeff,
>
> On Sun, 08 May 2011 22:32:16 -0500, Jeff Rickman wrote:
> > What Harry's comments tell me is the original "i8k" code lacks
> > appropriate code to operate in a SMP environment. I think the Console
> > messages are trying to say that for "non-programmers" like myself.
> >
> > Note these differences:
> > - Harry has a single CPU; I have 2 CPU.
>
> This is a valuable observation. I presume that these CPUs are too old
> to be multicore, best they could have it hyperthreading. Harry, can you
> please share the contents of /proc/cpuinfo?
Attached below ...
>
> Jeff, could you please try booting with parameter max_cpus=1? I wonder
> if it would make a difference. If it does, that would confirm your
> theory.
>
> > - We both run the same Dell BIOS A07 code.
> > - Harry's Linux kernel is slightly older than my 2.6.35.12-90 Fedora code.
> > - I think we would all agree that Jean's changes do not cause my crash
> > since that code works on Harry's machine but not on mine.
> >
> > Time permitting, I will start doing the research to submit a properly
> > documented bug against Fedora Core 14 regarding this code. I suspect
> > this issue will also reside in FC15 so that is another point to check if
> > time allows. jean raises the real question: does anyone in the Fedora
> > team want to fix this?
>
> I've seen this nug hit an openSUSE user (on a laptop with one
> multi-core CPU), so it's definitely not specific to Fedora. It may be
> related to the version of gcc used by the distribution though. If
> Fedora people aren't interested, we may open a bug on
> bugzilla.kernel.org instead.
>
> > In closing, I agree with Harry: it is very nice to have some hardware
> > monitoring in a Dell platform.
>
> I'm glad you like it :)
>
> --
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
[-- Attachment #2: cpuinfo.txt --]
[-- Type: text/plain , Size: 652 bytes --]
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 10
cpu MHz : 2992.603
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm
bogomips : 5985.20
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
[-- Attachment #3: Type: text/plain, Size: 50 bytes --]
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
[-- Attachment #4: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (26 preceding siblings ...)
2011-05-09 19:50 ` Harry G McGavran Jr
@ 2011-05-09 20:07 ` Jean Delvare
2011-05-09 20:21 ` Harry G McGavran Jr
` (35 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-09 20:07 UTC (permalink / raw)
To: lm-sensors
On Mon, 09 May 2011 13:50:41 -0600, Harry G McGavran Jr wrote:
> On Mon, 9 May 2011 21:42:31 +0200 Jean Delvare wrote:
> > This is a valuable observation. I presume that these CPUs are too old
> > to be multicore, best they could have it hyperthreading. Harry, can you
> > please share the contents of /proc/cpuinfo?
>
> Attached below ...
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 10
cpu MHz : 2992.603
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm
bogomips : 5985.20
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
Interesting... Your CPU is slightly more recent than Jeff's (stepping
10 instead of 1), both advertise HT but yours has it disabled. Maybe
there's an option in the BIOS to enable or disable HT? Or maybe Linux
didn't like HT for some reason (in which case it should say so in the
boot messages.)
It also seems like Jeff has CPUfreq enabled on his system and you do
not. It's unrelated to hardware monitoring, but for the sake of power
savings, it might be worth investigating.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (27 preceding siblings ...)
2011-05-09 20:07 ` Jean Delvare
@ 2011-05-09 20:21 ` Harry G McGavran Jr
2011-05-09 20:24 ` Guenter Roeck
` (34 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-09 20:21 UTC (permalink / raw)
To: lm-sensors
On Mon, 9 May 2011 22:07:10 +0200 Jean Delvare wrote:
> On Mon, 09 May 2011 13:50:41 -0600, Harry G McGavran Jr wrote:
> > On Mon, 9 May 2011 21:42:31 +0200 Jean Delvare wrote:
> > > This is a valuable observation. I presume that these CPUs are too old
> > > to be multicore, best they could have it hyperthreading. Harry, can you
> > > please share the contents of /proc/cpuinfo?
> >
> > Attached below ...
>
.
.
.
>
> Interesting... Your CPU is slightly more recent than Jeff's (stepping
> 10 instead of 1), both advertise HT but yours has it disabled. Maybe
> there's an option in the BIOS to enable or disable HT? Or maybe Linux
> didn't like HT for some reason (in which case it should say so in the
> boot messages.)
I don't see anything about HT in the boot messages.
I didn't change anything in the BIOS regarding the CPU from
whatever the defaults are. I don't remember seeing any
options for HT (or CPUfreq) in the BIOS and I haven't
changed anything in Linux from the Ubuntu Lucid default distro
regarding either HT or CPUfreq...
>
> It also seems like Jeff has CPUfreq enabled on his system and you do
> not. It's unrelated to hardware monitoring, but for the sake of power
> savings, it might be worth investigating.
If I run cpufreq-selector as root, I get:
No cpufreq support
Harry
>
> --
> Jean Delvare
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (28 preceding siblings ...)
2011-05-09 20:21 ` Harry G McGavran Jr
@ 2011-05-09 20:24 ` Guenter Roeck
2011-05-09 21:06 ` Harry G McGavran Jr
` (33 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Guenter Roeck @ 2011-05-09 20:24 UTC (permalink / raw)
To: lm-sensors
On Mon, May 09, 2011 at 04:07:10PM -0400, Jean Delvare wrote:
> On Mon, 09 May 2011 13:50:41 -0600, Harry G McGavran Jr wrote:
> > On Mon, 9 May 2011 21:42:31 +0200 Jean Delvare wrote:
> > > This is a valuable observation. I presume that these CPUs are too old
> > > to be multicore, best they could have it hyperthreading. Harry, can you
> > > please share the contents of /proc/cpuinfo?
> >
> > Attached below ...
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 4
> model name : Intel(R) Xeon(TM) CPU 3.00GHz
> stepping : 10
> cpu MHz : 2992.603
> cache size : 2048 KB
> physical id : 0
> siblings : 1
> core id : 0
> cpu cores : 1
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm
> bogomips : 5985.20
> clflush size : 64
> cache_alignment : 128
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> Interesting... Your CPU is slightly more recent than Jeff's (stepping
> 10 instead of 1), both advertise HT but yours has it disabled. Maybe
> there's an option in the BIOS to enable or disable HT? Or maybe Linux
> didn't like HT for some reason (in which case it should say so in the
> boot messages.)
>
More likely the BIOS. I have several Dell systems with HT CPU, and the BIOS always
offers the option to disable it.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (29 preceding siblings ...)
2011-05-09 20:24 ` Guenter Roeck
@ 2011-05-09 21:06 ` Harry G McGavran Jr
2011-05-10 13:54 ` Jeff Rickman
` (32 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-09 21:06 UTC (permalink / raw)
To: lm-sensors
On Mon, 9 May 2011 22:07:10 +0200 Jean Delvare wrote:
.
.
.
>
> It also seems like Jeff has CPUfreq enabled on his system and you do
> not. It's unrelated to hardware monitoring, but for the sake of power
> savings, it might be worth investigating.
I just checked and I've never installed any of the CPUfreq packages.
They were not installed by default and hence that's why it's disabled.
There certainly could be some power savings with it.
Harry McGavran
>
> --
> Jean Delvare
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (30 preceding siblings ...)
2011-05-09 21:06 ` Harry G McGavran Jr
@ 2011-05-10 13:54 ` Jeff Rickman
2011-05-10 14:06 ` Jeff Rickman
` (31 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-10 13:54 UTC (permalink / raw)
To: lm-sensors
On 5/9/2011 2:42 PM, Jean Delvare wrote:
> Hi Jeff,
>
> On Sun, 08 May 2011 22:32:16 -0500, Jeff Rickman wrote:
>> What Harry's comments tell me is the original "i8k" code lacks
>> appropriate code to operate in a SMP environment. I think the Console
>> messages are trying to say that for "non-programmers" like myself.
>>
>> Note these differences:
>> - Harry has a single CPU; I have 2 CPU.
>
> This is a valuable observation. I presume that these CPUs are too old
> to be multicore, best they could have it hyperthreading. Harry, can you
> please share the contents of /proc/cpuinfo?
>
> Jeff, could you please try booting with parameter max_cpus=1? I wonder
> if it would make a difference. If it does, that would confirm your
> theory.
>
>> - We both run the same Dell BIOS A07 code.
>> - Harry's Linux kernel is slightly older than my 2.6.35.12-90 Fedora code.
>> - I think we would all agree that Jean's changes do not cause my crash
>> since that code works on Harry's machine but not on mine.
>>
>> Time permitting, I will start doing the research to submit a properly
>> documented bug against Fedora Core 14 regarding this code. I suspect
>> this issue will also reside in FC15 so that is another point to check if
>> time allows. jean raises the real question: does anyone in the Fedora
>> team want to fix this?
>
> I've seen this nug hit an openSUSE user (on a laptop with one
> multi-core CPU), so it's definitely not specific to Fedora. It may be
> related to the version of gcc used by the distribution though. If
> Fedora people aren't interested, we may open a bug on
> bugzilla.kernel.org instead.
>
>> In closing, I agree with Harry: it is very nice to have some hardware
>> monitoring in a Dell platform.
>
> I'm glad you like it :)
>
I checked for any packages that could manipulate the CPU frequency. I
only found "cpuspeed". I removed the "cpuspeed" package and rebooted to
ensure a known state. Attempting to install the "stock i8k" module
causes a crash. Reboot to return to known state.
I changed the "maxcpus=4" in "grub.conf" to "maxcpus=1". Reboot.
Attempt to load "stock i8k" module. Crash. "/proc/cpuinfo" shows 1 CPU.
Return system to previous configuration with "cpuspeed" and reboot.
My only other choice would be to physically pull CPU2, leaving CPU1 in
the system, but we know that config should work based on Harry's testing.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (31 preceding siblings ...)
2011-05-10 13:54 ` Jeff Rickman
@ 2011-05-10 14:06 ` Jeff Rickman
2011-05-10 14:08 ` Jeff Rickman
` (30 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-10 14:06 UTC (permalink / raw)
To: lm-sensors
On 5/9/2011 4:06 PM, Harry G McGavran Jr wrote:
> On Mon, 9 May 2011 22:07:10 +0200 Jean Delvare wrote:
> .
> .
> .
>>
>> It also seems like Jeff has CPUfreq enabled on his system and you do
>> not. It's unrelated to hardware monitoring, but for the sake of power
>> savings, it might be worth investigating.
>
> I just checked and I've never installed any of the CPUfreq packages.
> They were not installed by default and hence that's why it's disabled.
>
> There certainly could be some power savings with it.
>
> Harry McGavran
>
>>
>> --
>> Jean Delvare
>
In the case of Fedora I only have to load the "cpuspeed" package. Then I
edit the "/etc/sysconfig/cpuspeed" file to add:
GOVERNOR=userspace [field is 'GOVERNOR=' by default]
MAX_SPEED= (value) [field is 'MAX_SPEED=' by default]
MIN_SPEED= (value) [field is 'MIN_SPEED=' by default]
The speed values are copied directly from
"/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies"
where "cpu*" is any CPU you wish to examine. Also, "cat
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies" will
display output for all CPUs, one line per CPU.
Supported GOVERNORs can be found in
"/sys/devices/system/cpu/cpu0/scaling_available_governors"
"cpuspeed" seems to work fine for me. My CPUs scale from 375MHz up to
3GHz as needed based on load on the system. With "cpuspeed" removed,
both CPU blocks run at full speed all the time. So there should be a
power saving.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (32 preceding siblings ...)
2011-05-10 14:06 ` Jeff Rickman
@ 2011-05-10 14:08 ` Jeff Rickman
2011-05-10 14:24 ` Jean Delvare
` (29 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-10 14:08 UTC (permalink / raw)
To: lm-sensors
On 5/10/2011 8:54 AM, Jeff Rickman wrote:
> On 5/9/2011 2:42 PM, Jean Delvare wrote:
>> Hi Jeff,
>>
>> On Sun, 08 May 2011 22:32:16 -0500, Jeff Rickman wrote:
>>> What Harry's comments tell me is the original "i8k" code lacks
>>> appropriate code to operate in a SMP environment. I think the Console
>>> messages are trying to say that for "non-programmers" like myself.
>>>
>>> Note these differences:
>>> - Harry has a single CPU; I have 2 CPU.
>>
>> This is a valuable observation. I presume that these CPUs are too old
>> to be multicore, best they could have it hyperthreading. Harry, can you
>> please share the contents of /proc/cpuinfo?
>>
>> Jeff, could you please try booting with parameter max_cpus=1? I wonder
>> if it would make a difference. If it does, that would confirm your
>> theory.
>>
>>> - We both run the same Dell BIOS A07 code.
>>> - Harry's Linux kernel is slightly older than my 2.6.35.12-90 Fedora
>>> code.
>>> - I think we would all agree that Jean's changes do not cause my crash
>>> since that code works on Harry's machine but not on mine.
>>>
>>> Time permitting, I will start doing the research to submit a properly
>>> documented bug against Fedora Core 14 regarding this code. I suspect
>>> this issue will also reside in FC15 so that is another point to check if
>>> time allows. jean raises the real question: does anyone in the Fedora
>>> team want to fix this?
>>
>> I've seen this nug hit an openSUSE user (on a laptop with one
>> multi-core CPU), so it's definitely not specific to Fedora. It may be
>> related to the version of gcc used by the distribution though. If
>> Fedora people aren't interested, we may open a bug on
>> bugzilla.kernel.org instead.
>>
>>> In closing, I agree with Harry: it is very nice to have some hardware
>>> monitoring in a Dell platform.
>>
>> I'm glad you like it :)
>>
>
> I checked for any packages that could manipulate the CPU frequency. I
> only found "cpuspeed". I removed the "cpuspeed" package and rebooted to
> ensure a known state. Attempting to install the "stock i8k" module
> causes a crash. Reboot to return to known state.
>
> I changed the "maxcpus=4" in "grub.conf" to "maxcpus=1". Reboot.
>
> Attempt to load "stock i8k" module. Crash. "/proc/cpuinfo" shows 1 CPU.
>
> Return system to previous configuration with "cpuspeed" and reboot.
>
> My only other choice would be to physically pull CPU2, leaving CPU1 in
> the system, but we know that config should work based on Harry's testing.
>
Forgot to add....
The crashdump info looked the same in all cases. The Console messages
looked the same in all cases...complaint about SMP.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (33 preceding siblings ...)
2011-05-10 14:08 ` Jeff Rickman
@ 2011-05-10 14:24 ` Jean Delvare
2011-05-10 15:05 ` Jeff Rickman
` (28 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-10 14:24 UTC (permalink / raw)
To: lm-sensors
Hi Jeff,
On Tue, 10 May 2011 08:54:21 -0500, Jeff Rickman wrote:
> I checked for any packages that could manipulate the CPU frequency. I
> only found "cpuspeed". I removed the "cpuspeed" package and rebooted to
> ensure a known state. Attempting to install the "stock i8k" module
> causes a crash. Reboot to return to known state.
>
> I changed the "maxcpus=4" in "grub.conf" to "maxcpus=1". Reboot.
>
> Attempt to load "stock i8k" module. Crash. "/proc/cpuinfo" shows 1 CPU.
Care to try again with maxcpus=0? I seem to recall that this disables
even more of SMP than maxcpus=1 does.
> Return system to previous configuration with "cpuspeed" and reboot.
>
> My only other choice would be to physically pull CPU2, leaving CPU1 in
> the system, but we know that config should work based on Harry's testing.
We don't, actually. You have different software environments and maybe
different BIOS options. And not exactly the same hardware either...
But I totally understand that you don't want to physically remove the
second CPU. I'm not even sure if that would help.
OTOH, if you see an option in the BIOS to disable HT, that would be
worth trying.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (34 preceding siblings ...)
2011-05-10 14:24 ` Jean Delvare
@ 2011-05-10 15:05 ` Jeff Rickman
2011-05-11 12:43 ` Luca Tettamanti
` (27 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-10 15:05 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
On 5/10/2011 9:24 AM, Jean Delvare wrote:
> Hi Jeff,
>
> On Tue, 10 May 2011 08:54:21 -0500, Jeff Rickman wrote:
>> I checked for any packages that could manipulate the CPU frequency. I
>> only found "cpuspeed". I removed the "cpuspeed" package and rebooted to
>> ensure a known state. Attempting to install the "stock i8k" module
>> causes a crash. Reboot to return to known state.
>>
>> I changed the "maxcpus=4" in "grub.conf" to "maxcpus=1". Reboot.
>>
>> Attempt to load "stock i8k" module. Crash. "/proc/cpuinfo" shows 1 CPU.
>
> Care to try again with maxcpus=0? I seem to recall that this disables
> even more of SMP than maxcpus=1 does.
>
>> Return system to previous configuration with "cpuspeed" and reboot.
>>
>> My only other choice would be to physically pull CPU2, leaving CPU1 in
>> the system, but we know that config should work based on Harry's testing.
>
> We don't, actually. You have different software environments and maybe
> different BIOS options. And not exactly the same hardware either...
>
> But I totally understand that you don't want to physically remove the
> second CPU. I'm not even sure if that would help.
>
> OTOH, if you see an option in the BIOS to disable HT, that would be
> worth trying.
>
Slightly different crash with "maxcpus=0". See attached.
I will have to go the that office to change the BIOS in that machine for
retest. It could be a few days.
[-- Attachment #2: Dell_Sensors_Testing_3.txt --]
[-- Type: text/plain, Size: 7639 bytes --]
After a reboot with "maxcpus=0" in "/boot/grub/grub.conf", "cpuspeed" removed, and loading the "stock i8k" driver
[root@XX ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 2992.262
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5984.52
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
[root@XX ~]# modprobe -v i8k
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
Message from syslogd@XX at May 10 09:54:59 ...
kernel:[ 74.591343] invalid opcode: 0000 [#1] SMP
Message from syslogd@XX at May 10 09:54:59 ...
kernel:[ 74.591373] last sysfs file: /sys/devices/virtual/vc/vcsa6/uevent
Message from syslogd@XX at May 10 09:54:59 ...
kernel:[ 74.592241] Stack:
Message from syslogd@XX at May 10 09:54:59 ...
kernel:[ 74.592309] Call Trace:
Message from syslogd@XX at May 10 09:54:59 ...
kernel:[ 74.592309] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
Segmentation fault
[root@XX ~]# tail -50 /var/log/messages
May 10 09:54:14 XX smartd[1470]: Device: /dev/sda [SAT], is SMART capable. Adding to "monitor" list.
May 10 09:54:14 XX smartd[1470]: Monitoring 1 ATA and 0 SCSI devices
May 10 09:54:14 XX smartd[1470]: Device: /dev/sda [SAT], initial Temperature is 34 Celsius (Min/Max ??/34)
May 10 09:54:14 XX smartd[1473]: smartd has fork()ed into background mode. New PID=1473.
May 10 09:54:24 XX kernel: [ 40.216053] type=1305 audit(1305039264.929:15016): auid=4294967295 ses=4294967295 op="remove rule" key=(null) list=4 res=1
May 10 09:54:24 XX kernel: [ 40.216089] type=1305 audit(1305039264.929:15017): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1
May 10 09:54:25 XX kernel: [ 40.790445] readahead-collector: sorting
May 10 09:54:25 XX kernel: [ 40.883562] readahead-collector: finished
May 10 09:54:28 XX ntpd[1378]: Deferring DNS for 0.fedora.pool.ntp.org 1
May 10 09:54:28 XX ntpd[1378]: 0.0.0.0 c016 06 restart
May 10 09:54:28 XX ntpd[1378]: 0.0.0.0 c012 02 freq_set kernel -29.660 PPM
May 10 09:54:30 XX ntpd_intres[1505]: DNS 0.fedora.pool.ntp.org -> 216.45.57.38
May 10 09:54:59 XX kernel: [ 74.591343] invalid opcode: 0000 [#1] SMP
May 10 09:54:59 XX kernel: [ 74.591373] last sysfs file: /sys/devices/virtual/vc/vcsa6/uevent
May 10 09:54:59 XX kernel: [ 74.591389] CPU 0
May 10 09:54:59 XX kernel: [ 74.591397] Modules linked in: i8k(+) act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink e1000 dcdbas microcode iTCO_wdt iTCO_vendor_support i2
May 10 09:54:59 XX kernel: c_i801 serio_raw e752x_edac shpchp edac_core firewire_ohci firewire_core crc_itu_t nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: scsi_wait_scan]
May 10 09:54:59 XX kernel: [ 74.591983]
May 10 09:54:59 XX kernel: [ 74.591993] Pid: 1557, comm: modprobe Not tainted 2.6.35.12-90.fc14.x86_64 #1 0U7565/Precision WorkStation 670
May 10 09:54:59 XX kernel: [ 74.592015] RIP: 0010:[<ffffffffa0362041>] [<ffffffffa0362041>] i8k_smm+0x41/0x65 [i8k]
May 10 09:54:59 XX kernel: [ 74.592043] RSP: 0018:ffff88007dcb3ea0 EFLAGS: 00010246
May 10 09:54:59 XX kernel: [ 74.592056] RAX: ffff88007dcb3eb8 RBX: 0000000000000000 RCX: 0000000000000000
May 10 09:54:59 XX kernel: [ 74.592073] RDX: 0000000044494147 RSI: 0000000000000000 RDI: 0000000000000000
May 10 09:54:59 XX kernel: [ 74.592090] RBP: ffff88007dcb3ea8 R08: ffff88007dcb3eb8 R09: 000000000000fea3
May 10 09:54:59 XX kernel: [ 74.592107] R10: ffffffffa0362d10 R11: 0000000000000000 R12: 0000000000000000
May 10 09:54:59 XX kernel: [ 74.592123] R13: 000000000217c040 R14: 0000000000000000 R15: 00000000021756c0
May 10 09:54:59 XX kernel: [ 74.592141] FS: 00007fc8205bb720(0000) GS:ffff880002000000(0000) knlGS:0000000000000000
May 10 09:54:59 XX kernel: [ 74.592158] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
May 10 09:54:59 XX kernel: [ 74.592172] CR2: 0000003a136e1200 CR3: 000000007e6d4000 CR4: 00000000000006f0
May 10 09:54:59 XX kernel: [ 74.592189] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 10 09:54:59 XX kernel: [ 74.592207] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 10 09:54:59 XX kernel: [ 74.592224] Process modprobe (pid: 1557, threadinfo ffff88007dcb2000, task ffff88007ea52e80)
May 10 09:54:59 XX kernel: [ 74.592241] Stack:
May 10 09:54:59 XX kernel: [ 74.592250] ffffffffa0366000 ffff88007dcb3ed8 ffffffffa03621d2 0000000044494147
May 10 09:54:59 XX kernel: [ 74.592277] <0> 44454c4c00000000 0000000000000000 ffffffffa036221c ffff88007dcb3f08
May 10 09:54:59 XX kernel: [ 74.592309] <0> ffffffffa03660a7 ffff88007dcb3f28 ffffffff8106ae50 ffffffffa0366000
May 10 09:54:59 XX kernel: [ 74.592309] Call Trace:
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffffa0366000>] ? i8k_init+0x0/0x1ad [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffffa03621d2>] i8k_get_dell_signature+0x28/0x48 [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffffa036221c>] ? i8k_get_dmi_data+0xe/0x2c [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffffa03660a7>] i8k_init+0xa7/0x1ad [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffff8106ae50>] ? __blocking_notifier_call_chain+0x56/0x60
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffffa0366000>] ? i8k_init+0x0/0x1ad [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffff810021a1>] do_one_initcall+0x5e/0x155
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffff8107d155>] sys_init_module+0xa6/0x1e4
May 10 09:54:59 XX kernel: [ 74.592309] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
May 10 09:54:59 XX kernel: [ 74.592309] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
May 10 09:54:59 XX kernel: [ 74.592309] RIP [<ffffffffa0362041>] i8k_smm+0x41/0x65 [i8k]
May 10 09:54:59 XX kernel: [ 74.592309] RSP <ffff88007dcb3ea0>
May 10 09:54:59 XX kernel: [ 74.598783] ---[ end trace a413158da8f753a8 ]---
[root@XX ~]#
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (35 preceding siblings ...)
2011-05-10 15:05 ` Jeff Rickman
@ 2011-05-11 12:43 ` Luca Tettamanti
2011-05-11 13:48 ` Luca Tettamanti
` (26 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-11 12:43 UTC (permalink / raw)
To: lm-sensors
On Tue, May 10, 2011 at 10:05:29AM -0500, Jeff Rickman wrote:
> On 5/10/2011 9:24 AM, Jean Delvare wrote:
> >Hi Jeff,
> >
> >On Tue, 10 May 2011 08:54:21 -0500, Jeff Rickman wrote:
> >>I checked for any packages that could manipulate the CPU frequency. I
> >>only found "cpuspeed". I removed the "cpuspeed" package and rebooted to
> >>ensure a known state. Attempting to install the "stock i8k" module
> >>causes a crash. Reboot to return to known state.
> >>
> >>I changed the "maxcpus=4" in "grub.conf" to "maxcpus=1". Reboot.
> >>
> >>Attempt to load "stock i8k" module. Crash. "/proc/cpuinfo" shows 1 CPU.
> >
> >Care to try again with maxcpus=0? I seem to recall that this disables
> >even more of SMP than maxcpus=1 does.
> >
> >>Return system to previous configuration with "cpuspeed" and reboot.
> >>
> >>My only other choice would be to physically pull CPU2, leaving CPU1 in
> >>the system, but we know that config should work based on Harry's testing.
> >
> >We don't, actually. You have different software environments and maybe
> >different BIOS options. And not exactly the same hardware either...
> >
> >But I totally understand that you don't want to physically remove the
> >second CPU. I'm not even sure if that would help.
> >
> >OTOH, if you see an option in the BIOS to disable HT, that would be
> >worth trying.
> >
>
> Slightly different crash with "maxcpus=0". See attached.
From the log:
> [ 74.591343] invalid opcode: 0000 [#1] SMP
[...]
> [ 74.592309] Code: 52 8b 58 04 8b 48 08 8b 50 0c 8b 70 10 8b 78 14 58 e6 b2 e6 84 48 87 04 24 89 58 04 89 48 08 89 50 0c 89 70 10 89 78 14 5a 89 10 <9f> c1 e8 08 83 e0 01 85 c0 ba ea ff ff ff 75 0f 41 8b 08 66 83
> May 10 09:54:59 XX kernel: [ 74.592309] RIP [<ffffffffa0362041>] i8k_smm+0x41/0x65 [i8k]
0: 52 push %rdx
1: 8b 58 04 mov 0x4(%rax),%ebx
4: 8b 48 08 mov 0x8(%rax),%ecx
7: 8b 50 0c mov 0xc(%rax),%edx
a: 8b 70 10 mov 0x10(%rax),%esi
d: 8b 78 14 mov 0x14(%rax),%edi
10: 58 pop %rax
11: e6 b2 out %al,$0xb2
13: e6 84 out %al,$0x84
15: 48 87 04 24 xchg %rax,(%rsp)
19: 89 58 04 mov %ebx,0x4(%rax)
1c: 89 48 08 mov %ecx,0x8(%rax)
1f: 89 50 0c mov %edx,0xc(%rax)
22: 89 70 10 mov %esi,0x10(%rax)
25: 89 78 14 mov %edi,0x14(%rax)
28: 5a pop %rdx
29: 89 10 mov %edx,(%rax)
2b:* 9f lahf <-- trapping instruction
2c: c1 e8 08 shr $0x8,%eax
2f: 83 e0 01 and $0x1,%eax
32: 85 c0 test %eax,%eax
34: ba ea ff ff ff mov $0xffffffea,%edx
39: 75 0f jne 0x4a
3b: 41 8b 08 mov (%r8),%ecx
lahf is present in the assembly block inside the driver in i8k_smm; lahf
moves the lowest byte of eflags into ah.
Wikipedia[1] tells me that:
Early AMD64 and Intel 64 CPUs lacked LAHF and SAHF instructions. AMD
introduced the instructions with their Athlon 64, Opteron and Turion 64
revision D processors in March 2005 while Intel introduced
the instructions with the Pentium 4 G1 stepping in December 2005.
Jeff's CPU does indeed lack lahf (see cpuinfo), so the driver should not
unconditionally use the intruction.
The driver should check X86_FEATURE_LAHF_LM or use use a different
method to read EFLAFS (pushf?).
drivers/char/toshiba.c (tosh_smm) also suffers from the same issue.
Luca
[1] http://en.wikipedia.org/wiki/X86-64
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (36 preceding siblings ...)
2011-05-11 12:43 ` Luca Tettamanti
@ 2011-05-11 13:48 ` Luca Tettamanti
2011-05-11 14:15 ` Jean Delvare
` (25 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-11 13:48 UTC (permalink / raw)
To: lm-sensors
On Wed, May 11, 2011 at 02:43:35PM +0200, Luca Tettamanti wrote:
> Jeff's CPU does indeed lack lahf (see cpuinfo), so the driver should not
> unconditionally use the intruction.
> The driver should check X86_FEATURE_LAHF_LM or use use a different
> method to read EFLAFS (pushf?).
The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
shifts it to right and test the lowest bit (CF).
Using pushf instead we get the whole EFLAGS and test the lowest bit.
Does it make sense? Someone should double check the patch, I don't trust
my assembly skills ;)
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d72433f..3554d10 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edi,20(%%rax)\n\t"
"popq %%rdx\n\t"
"movl %%edx,0(%%rax)\n\t"
- "lahf\n\t"
- "shrl $8,%%eax\n\t"
+ "pusfh\n\t"
+ "popl %%eax\n\t"
"andl $1,%%eax\n"
:"=a"(rc)
: "a"(regs)
Luca
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (37 preceding siblings ...)
2011-05-11 13:48 ` Luca Tettamanti
@ 2011-05-11 14:15 ` Jean Delvare
2011-05-11 14:28 ` Luca Tettamanti
` (24 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-11 14:15 UTC (permalink / raw)
To: lm-sensors
On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
> On Wed, May 11, 2011 at 02:43:35PM +0200, Luca Tettamanti wrote:
> > Jeff's CPU does indeed lack lahf (see cpuinfo), so the driver should not
> > unconditionally use the intruction.
> > The driver should check X86_FEATURE_LAHF_LM or use use a different
> > method to read EFLAFS (pushf?).
>
> The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
> shifts it to right and test the lowest bit (CF).
> Using pushf instead we get the whole EFLAGS and test the lowest bit.
> Does it make sense? Someone should double check the patch, I don't trust
> my assembly skills ;)
>
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index d72433f..3554d10 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> "movl %%edi,20(%%rax)\n\t"
> "popq %%rdx\n\t"
> "movl %%edx,0(%%rax)\n\t"
> - "lahf\n\t"
> - "shrl $8,%%eax\n\t"
> + "pusfh\n\t"
I think you meant pushf, not pusfh, right?
> + "popl %%eax\n\t"
> "andl $1,%%eax\n"
> :"=a"(rc)
> : "a"(regs)
I am no asm expert, but I don't get why you removed the shrl
instruction. As I understand it, your pushf+popl replaces only lahf,
the bit shifting is still needed (I assume the code wants to test bit 8
in the flag register.)
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (38 preceding siblings ...)
2011-05-11 14:15 ` Jean Delvare
@ 2011-05-11 14:28 ` Luca Tettamanti
2011-05-11 15:08 ` Jean Delvare
` (23 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-11 14:28 UTC (permalink / raw)
To: lm-sensors
On Wed, May 11, 2011 at 04:15:45PM +0200, Jean Delvare wrote:
> On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
> > On Wed, May 11, 2011 at 02:43:35PM +0200, Luca Tettamanti wrote:
> > > Jeff's CPU does indeed lack lahf (see cpuinfo), so the driver should not
> > > unconditionally use the intruction.
> > > The driver should check X86_FEATURE_LAHF_LM or use use a different
> > > method to read EFLAFS (pushf?).
> >
> > The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
> > shifts it to right and test the lowest bit (CF).
> > Using pushf instead we get the whole EFLAGS and test the lowest bit.
> > Does it make sense? Someone should double check the patch, I don't trust
> > my assembly skills ;)
> >
> > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > index d72433f..3554d10 100644
> > --- a/drivers/char/i8k.c
> > +++ b/drivers/char/i8k.c
> > @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> > "movl %%edi,20(%%rax)\n\t"
> > "popq %%rdx\n\t"
> > "movl %%edx,0(%%rax)\n\t"
> > - "lahf\n\t"
> > - "shrl $8,%%eax\n\t"
> > + "pusfh\n\t"
>
> I think you meant pushf, not pusfh, right?
Yeah, right... hand me that brown paper bag ;)
>
> > + "popl %%eax\n\t"
> > "andl $1,%%eax\n"
> > :"=a"(rc)
> > : "a"(regs)
>
> I am no asm expert, but I don't get why you removed the shrl
> instruction. As I understand it, your pushf+popl replaces only lahf,
> the bit shifting is still needed (I assume the code wants to test bit 8
> in the flag register.)
AFAIK lahf loads the lowest byte of EFLAGS into AH which is the upper
half of AX, hence the shift.
The popl is wrong though, pushf only pushes 2 bytes... so let's try
again:
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d72433f..f71f266 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edi,20(%%rax)\n\t"
"popq %%rdx\n\t"
"movl %%edx,0(%%rax)\n\t"
- "lahf\n\t"
- "shrl $8,%%eax\n\t"
+ "pushf\n\t"
+ "pop %%ax\n\t"
"andl $1,%%eax\n"
:"=a"(rc)
: "a"(regs)
Luca
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (39 preceding siblings ...)
2011-05-11 14:28 ` Luca Tettamanti
@ 2011-05-11 15:08 ` Jean Delvare
2011-05-11 17:15 ` Harry G McGavran Jr
` (22 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-11 15:08 UTC (permalink / raw)
To: lm-sensors
On Wed, 11 May 2011 16:28:04 +0200, Luca Tettamanti wrote:
> On Wed, May 11, 2011 at 04:15:45PM +0200, Jean Delvare wrote:
> > On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
> > > The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
> > > shifts it to right and test the lowest bit (CF).
> > > Using pushf instead we get the whole EFLAGS and test the lowest bit.
> > > Does it make sense? Someone should double check the patch, I don't trust
> > > my assembly skills ;)
> > >
> > > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > > index d72433f..3554d10 100644
> > > --- a/drivers/char/i8k.c
> > > +++ b/drivers/char/i8k.c
> > > @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> > > "movl %%edi,20(%%rax)\n\t"
> > > "popq %%rdx\n\t"
> > > "movl %%edx,0(%%rax)\n\t"
> > > - "lahf\n\t"
> > > - "shrl $8,%%eax\n\t"
> > > + "pusfh\n\t"
> >
> > I think you meant pushf, not pusfh, right?
>
> Yeah, right... hand me that brown paper bag ;)
>
> >
> > > + "popl %%eax\n\t"
> > > "andl $1,%%eax\n"
> > > :"=a"(rc)
> > > : "a"(regs)
> >
> > I am no asm expert, but I don't get why you removed the shrl
> > instruction. As I understand it, your pushf+popl replaces only lahf,
> > the bit shifting is still needed (I assume the code wants to test bit 8
> > in the flag register.)
>
> AFAIK lahf loads the lowest byte of EFLAGS into AH which is the upper
> half of AX, hence the shift.
Yes, you're right, of course. So much for my asm skills. Please return
the brown paper bag to me when you're done ;)
> The popl is wrong though, pushf only pushes 2 bytes... so let's try
> again:
>
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index d72433f..f71f266 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> "movl %%edi,20(%%rax)\n\t"
> "popq %%rdx\n\t"
> "movl %%edx,0(%%rax)\n\t"
> - "lahf\n\t"
> - "shrl $8,%%eax\n\t"
> + "pushf\n\t"
> + "pop %%ax\n\t"
> "andl $1,%%eax\n"
> :"=a"(rc)
> : "a"(regs)
Looks reasonable. I can't test it as I don't have the hardware, but I
have updated the driver at:
http://khali.linux-fr.org/devel/misc/i8k/
with the above fix. Jeff, Harry, can you test?
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (40 preceding siblings ...)
2011-05-11 15:08 ` Jean Delvare
@ 2011-05-11 17:15 ` Harry G McGavran Jr
2011-05-11 17:23 ` Jeff Rickman
` (21 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-11 17:15 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2688.1305134105.1@kahu.w5pny.comcast.net>
This new i8k crashes on my machine, the old one does not.
Harry McGavran
On Wed, 11 May 2011 17:08:17 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <2688.1305134105.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Wed, 11 May 2011 09:48:20 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id 8A01E1A9865
for <w5pny@localhost.localdomain>; Wed, 11 May 2011 09:48:20 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.40; Wed, 11 May 2011 08:34:28 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1008.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: AzyUr7wcZAqVNUkZJfKNTbXFskNqFMJoZzBy9C1hjthsEXpX
Emi.9NLdspaLDcj0ArFkYiNa_Pp64C6brB1rtmHD8ReAYEouu5wLInrjxmHw
Xn3yFkmAuS.jENIfO.O5_IcMdcW9.Rr9rVg2crywgbMat_sn6I7GCXc32fst
X1FFc8YywQnoXuFU2crUhycKx7WHD_EeoxzkOJe2_40C2QMcxjhuOAa09_k6
LyMImhNXzBhJZ6TwgZil_uTkLWN3z3IgljSXGMCTIVHPlKIVQo1iSPHors35
zWtt1wz.0KE1RxuL1LMTrhv8OmlLZjNd3uZX5nYaGidtFsy2w5eYvVF1QULE
ezBvi079Ae9LR5OyLsl24Q1io9KSmiJzwWpKcBOz2kk2BtXWaeom1FedAph8
.hMBDnndKNmC8sCkrPkaokrtgQeL4C9pww36RXdCsY8zHB4TbNUd_pB9v9zx
r7qDMMB6_9GFM0hB714BXyrGEbT38D9xvb779dtj9DPffDp.vbr1Y0LvwJRQ
sSd7ui4P0X.a1_1aKGrHpkZNt7KF
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1008.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.sp1.yahoo.com [69.147.84.46]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Wed, 11 May 2011 09:48:20 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1008.biz.mail.mud.yahoo.com with SMTP; Wed, 11 May 2011 08:34:28 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKC9R-0005WC-4E
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Wed, 11 May 2011 18:20:41 +0200
Date: Wed, 11 May 2011 17:08:17 +0200
From: Jean Delvare <khali@linux-fr.org>
To: Luca Tettamanti <kronos.it@gmail.com>
Cc: Jeff Rickman <jrickman@myamigos.us>, w5pny@w5pny.com, Ric
<fhj52rags@yahoo.com>, lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110511170817.08d8a203@endymion.delvare>
In-Reply-To: <20110511142804.GA27621@nb-core2.darkstar.lan>
References: <20110508152737.6DB861A987F@localhost.localdomain>
<4DC76040.2020908@myamigos.us>
<20110509214231.26a98b87@endymion.delvare>
<4DC9438D.7000301@myamigos.us>
<20110510162433.0dbd4d76@endymion.delvare>
<4DC95439.8080001@myamigos.us>
<20110511124334.GA23421@nb-core2.darkstar.lan>
<20110511134859.GA24405@nb-core2.darkstar.lan>
<20110511161545.0f8aeb78@endymion.delvare>
<20110511142804.GA27621@nb-core2.darkstar.lan>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => Dell670
On Wed, 11 May 2011 16:28:04 +0200, Luca Tettamanti wrote:
> On Wed, May 11, 2011 at 04:15:45PM +0200, Jean Delvare wrote:
> > On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
> > > The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
> > > shifts it to right and test the lowest bit (CF).
> > > Using pushf instead we get the whole EFLAGS and test the lowest bit.
> > > Does it make sense? Someone should double check the patch, I don't trust
> > > my assembly skills ;)
> > >
> > > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > > index d72433f..3554d10 100644
> > > --- a/drivers/char/i8k.c
> > > +++ b/drivers/char/i8k.c
> > > @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> > > "movl %%edi,20(%%rax)\n\t"
> > > "popq %%rdx\n\t"
> > > "movl %%edx,0(%%rax)\n\t"
> > > - "lahf\n\t"
> > > - "shrl $8,%%eax\n\t"
> > > + "pusfh\n\t"
> >
> > I think you meant pushf, not pusfh, right?
>
> Yeah, right... hand me that brown paper bag ;)
>
> >
> > > + "popl %%eax\n\t"
> > > "andl $1,%%eax\n"
> > > :"=a"(rc)
> > > : "a"(regs)
> >
> > I am no asm expert, but I don't get why you removed the shrl
> > instruction. As I understand it, your pushf+popl replaces only lahf,
> > the bit shifting is still needed (I assume the code wants to test bit 8
> > in the flag register.)
>
> AFAIK lahf loads the lowest byte of EFLAGS into AH which is the upper
> half of AX, hence the shift.
Yes, you're right, of course. So much for my asm skills. Please return
the brown paper bag to me when you're done ;)
> The popl is wrong though, pushf only pushes 2 bytes... so let's try
> again:
>
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index d72433f..f71f266 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> "movl %%edi,20(%%rax)\n\t"
> "popq %%rdx\n\t"
> "movl %%edx,0(%%rax)\n\t"
> - "lahf\n\t"
> - "shrl $8,%%eax\n\t"
> + "pushf\n\t"
> + "pop %%ax\n\t"
> "andl $1,%%eax\n"
> :"=a"(rc)
> : "a"(regs)
Looks reasonable. I can't test it as I don't have the hardware, but I
have updated the driver at:
http://khali.linux-fr.org/devel/misc/i8k/
with the above fix. Jeff, Harry, can you test?
Thanks,
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2688.1305134105.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (41 preceding siblings ...)
2011-05-11 17:15 ` Harry G McGavran Jr
@ 2011-05-11 17:23 ` Jeff Rickman
2011-05-11 17:59 ` Jeff Rickman
` (20 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-11 17:23 UTC (permalink / raw)
To: lm-sensors
On 5/11/2011 10:08 AM, Jean Delvare wrote:
> On Wed, 11 May 2011 16:28:04 +0200, Luca Tettamanti wrote:
>> On Wed, May 11, 2011 at 04:15:45PM +0200, Jean Delvare wrote:
>>> On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
>>>> The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
>>>> shifts it to right and test the lowest bit (CF).
>>>> Using pushf instead we get the whole EFLAGS and test the lowest bit.
>>>> Does it make sense? Someone should double check the patch, I don't trust
>>>> my assembly skills ;)
>>>>
>>>> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
>>>> index d72433f..3554d10 100644
>>>> --- a/drivers/char/i8k.c
>>>> +++ b/drivers/char/i8k.c
>>>> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
>>>> "movl %%edi,20(%%rax)\n\t"
>>>> "popq %%rdx\n\t"
>>>> "movl %%edx,0(%%rax)\n\t"
>>>> - "lahf\n\t"
>>>> - "shrl $8,%%eax\n\t"
>>>> + "pusfh\n\t"
>>>
>>> I think you meant pushf, not pusfh, right?
>>
>> Yeah, right... hand me that brown paper bag ;)
>>
>>>
>>>> + "popl %%eax\n\t"
>>>> "andl $1,%%eax\n"
>>>> :"=a"(rc)
>>>> : "a"(regs)
>>>
>>> I am no asm expert, but I don't get why you removed the shrl
>>> instruction. As I understand it, your pushf+popl replaces only lahf,
>>> the bit shifting is still needed (I assume the code wants to test bit 8
>>> in the flag register.)
>>
>> AFAIK lahf loads the lowest byte of EFLAGS into AH which is the upper
>> half of AX, hence the shift.
>
> Yes, you're right, of course. So much for my asm skills. Please return
> the brown paper bag to me when you're done ;)
>
>> The popl is wrong though, pushf only pushes 2 bytes... so let's try
>> again:
>>
>> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
>> index d72433f..f71f266 100644
>> --- a/drivers/char/i8k.c
>> +++ b/drivers/char/i8k.c
>> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
>> "movl %%edi,20(%%rax)\n\t"
>> "popq %%rdx\n\t"
>> "movl %%edx,0(%%rax)\n\t"
>> - "lahf\n\t"
>> - "shrl $8,%%eax\n\t"
>> + "pushf\n\t"
>> + "pop %%ax\n\t"
>> "andl $1,%%eax\n"
>> :"=a"(rc)
>> : "a"(regs)
>
> Looks reasonable. I can't test it as I don't have the hardware, but I
> have updated the driver at:
> http://khali.linux-fr.org/devel/misc/i8k/
> with the above fix. Jeff, Harry, can you test?
>
> Thanks,
Preliminary feedback...seeing new errors. New "i8k" module reporting 'no
such device' when inserted. More details to follow when I finish testing
and capture outputs.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (42 preceding siblings ...)
2011-05-11 17:23 ` Jeff Rickman
@ 2011-05-11 17:59 ` Jeff Rickman
2011-05-11 19:03 ` Jean Delvare
` (19 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-11 17:59 UTC (permalink / raw)
To: lm-sensors
On 5/11/2011 10:08 AM, Jean Delvare wrote:
> On Wed, 11 May 2011 16:28:04 +0200, Luca Tettamanti wrote:
>> On Wed, May 11, 2011 at 04:15:45PM +0200, Jean Delvare wrote:
>>> On Wed, 11 May 2011 15:48:59 +0200, Luca Tettamanti wrote:
>>>> The driver uses lahf to copy the lowest byte of EFLAGS to eax, then
>>>> shifts it to right and test the lowest bit (CF).
>>>> Using pushf instead we get the whole EFLAGS and test the lowest bit.
>>>> Does it make sense? Someone should double check the patch, I don't trust
>>>> my assembly skills ;)
>>>>
>>>> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
>>>> index d72433f..3554d10 100644
>>>> --- a/drivers/char/i8k.c
>>>> +++ b/drivers/char/i8k.c
>>>> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
>>>> "movl %%edi,20(%%rax)\n\t"
>>>> "popq %%rdx\n\t"
>>>> "movl %%edx,0(%%rax)\n\t"
>>>> - "lahf\n\t"
>>>> - "shrl $8,%%eax\n\t"
>>>> + "pusfh\n\t"
>>>
>>> I think you meant pushf, not pusfh, right?
>>
>> Yeah, right... hand me that brown paper bag ;)
>>
>>>
>>>> + "popl %%eax\n\t"
>>>> "andl $1,%%eax\n"
>>>> :"=a"(rc)
>>>> : "a"(regs)
>>>
>>> I am no asm expert, but I don't get why you removed the shrl
>>> instruction. As I understand it, your pushf+popl replaces only lahf,
>>> the bit shifting is still needed (I assume the code wants to test bit 8
>>> in the flag register.)
>>
>> AFAIK lahf loads the lowest byte of EFLAGS into AH which is the upper
>> half of AX, hence the shift.
>
> Yes, you're right, of course. So much for my asm skills. Please return
> the brown paper bag to me when you're done ;)
>
>> The popl is wrong though, pushf only pushes 2 bytes... so let's try
>> again:
>>
>> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
>> index d72433f..f71f266 100644
>> --- a/drivers/char/i8k.c
>> +++ b/drivers/char/i8k.c
>> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
>> "movl %%edi,20(%%rax)\n\t"
>> "popq %%rdx\n\t"
>> "movl %%edx,0(%%rax)\n\t"
>> - "lahf\n\t"
>> - "shrl $8,%%eax\n\t"
>> + "pushf\n\t"
>> + "pop %%ax\n\t"
>> "andl $1,%%eax\n"
>> :"=a"(rc)
>> : "a"(regs)
>
> Looks reasonable. I can't test it as I don't have the hardware, but I
> have updated the driver at:
> http://khali.linux-fr.org/devel/misc/i8k/
> with the above fix. Jeff, Harry, can you test?
>
> Thanks,
[test results]
compile new i8k module
no compile errors noticed
do not load new i8k module
do not copy new module to /lib/modules tree
load "stock" driver (to verify baseline behavior)
non-fatal crash results
reboot
remove "stock" i8k module
copy new i8k module to /lib/modules/`uname -r`/kernel/drivers/char
run depmod -a
modinfo /lib/modules/`uname -r`/kernel/drivers/char/i8k.ko
filename:
/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
license: GPL
description: Driver for accessing SMM BIOS on Dell laptops
author: Massimo Dal Zotto (dz@debian.org)
srcversion: 0FCA3FE04945CA449B9A849
depends:
vermagic: 2.6.35.12-90.fc14.x86_64 SMP mod_unload
parm: force:Force loading without checking for supported
models (bool)
parm: ignore_dmi:Continue probing hardware even if DMI data
does not match (bool)
parm: restricted:Allow fan control if SYS_ADMIN capability set
(bool)
parm: power_status:Report power status in /proc/i8k (bool)
parm: fan_mult:Factor to multiply fan speed with (int)
load new i8k module
modprobe -v i8k
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
FATAL: Error inserting i8k
(/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko): No
such device
from /var/log/messages
May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
signature
modprobe -v i8k force
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
force
from /var/log/messages
May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
signature
May 11 12:40:52 XX kernel: [ 365.019189] i8k: unable to get SMM Dell
signature
May 11 12:40:52 XX kernel: [ 365.020148] i8k: unable to get SMM BIOS
version
May 11 12:40:52 XX kernel: [ 365.027736] Dell laptop SMM driver v1.14
21/02/2005 Massimo Dal Zotto (dz@debian.org)
I will guess that this detection issue is not due to the changes made by
Jean and Luca. This module may be at a dead end for my hardware.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (43 preceding siblings ...)
2011-05-11 17:59 ` Jeff Rickman
@ 2011-05-11 19:03 ` Jean Delvare
2011-05-12 13:02 ` Luca Tettamanti
` (18 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-11 19:03 UTC (permalink / raw)
To: lm-sensors
On Wed, 11 May 2011 14:43:35 +0200, Luca Tettamanti wrote:
> lahf is present in the assembly block inside the driver in i8k_smm; lahf
> moves the lowest byte of eflags into ah.
> Wikipedia[1] tells me that:
>
> Early AMD64 and Intel 64 CPUs lacked LAHF and SAHF instructions. AMD
> introduced the instructions with their Athlon 64, Opteron and Turion 64
> revision D processors in March 2005 while Intel introduced
> the instructions with the Pentium 4 G1 stepping in December 2005.
>
> Jeff's CPU does indeed lack lahf (see cpuinfo), so the driver should not
> unconditionally use the intruction.
> The driver should check X86_FEATURE_LAHF_LM or use use a different
> method to read EFLAFS (pushf?).
Thanks for the investigation, BTW... Brilliant!
> drivers/char/toshiba.c (tosh_smm) also suffers from the same issue.
That one currently depends on X86_32, which I seem to understand is
unaffected by the bug. But if this driver is ever extended to work on
64-bit machines, then yes, care will be needed.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (44 preceding siblings ...)
2011-05-11 19:03 ` Jean Delvare
@ 2011-05-12 13:02 ` Luca Tettamanti
2011-05-12 13:38 ` Jean Delvare
` (17 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-12 13:02 UTC (permalink / raw)
To: lm-sensors
On Wed, May 11, 2011 at 7:59 PM, Jeff Rickman <jrickman@myamigos.us> wrote:
> [test results]
> load new i8k module
>
> modprobe -v i8k
> insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
> FATAL: Error inserting i8k
> (/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko): No such
> device
>
> from /var/log/messages
> May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
> signature
>
> modprobe -v i8k force
> insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
> force
>
> from /var/log/messages
> May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
> signature
> May 11 12:40:52 XX kernel: [ 365.019189] i8k: unable to get SMM Dell
> signature
> May 11 12:40:52 XX kernel: [ 365.020148] i8k: unable to get SMM BIOS
> version
> May 11 12:40:52 XX kernel: [ 365.027736] Dell laptop SMM driver v1.14
> 21/02/2005 Massimo Dal Zotto (dz@debian.org)
>
> I will guess that this detection issue is not due to the changes made by
> Jean and Luca. This module may be at a dead end for my hardware.
Hum, maybe my change is not correct. It should be possible to verify
to functionality of the patch on Harry's machine
Luca
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (45 preceding siblings ...)
2011-05-12 13:02 ` Luca Tettamanti
@ 2011-05-12 13:38 ` Jean Delvare
2011-05-12 13:47 ` Jean Delvare
` (16 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-12 13:38 UTC (permalink / raw)
To: lm-sensors
Hi Jeff, Luca,
On Thu, 12 May 2011 15:02:08 +0200, Luca Tettamanti wrote:
> On Wed, May 11, 2011 at 7:59 PM, Jeff Rickman <jrickman@myamigos.us> wrote:
> > [test results]
> > load new i8k module
> >
> > modprobe -v i8k
> > insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
> > FATAL: Error inserting i8k
> > (/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko): No such
> > device
> >
> > from /var/log/messages
> > May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
> > signature
> >
> > modprobe -v i8k force
> > insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
> > force
> >
> > from /var/log/messages
> > May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
> > signature
> > May 11 12:40:52 XX kernel: [ 365.019189] i8k: unable to get SMM Dell
> > signature
> > May 11 12:40:52 XX kernel: [ 365.020148] i8k: unable to get SMM BIOS
> > version
> > May 11 12:40:52 XX kernel: [ 365.027736] Dell laptop SMM driver v1.14
> > 21/02/2005 Massimo Dal Zotto (dz@debian.org)
This is not a fatal error, you may still see interesting things
in /proc/i8k or the output of "sensors". Although Harry's report makes
it unlikely...
> > I will guess that this detection issue is not due to the changes made by
> > Jean and Luca. This module may be at a dead end for my hardware.
>
> Hum, maybe my change is not correct. It should be possible to verify
> to functionality of the patch on Harry's machine
Harry already reported:
"This new i8k crashes on my machine, the old one does not."
This suggests that your patch is indeed not correct, however it looks
good to me so I don't know what else to suggest.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (46 preceding siblings ...)
2011-05-12 13:38 ` Jean Delvare
@ 2011-05-12 13:47 ` Jean Delvare
2011-05-12 13:49 ` Luca Tettamanti
` (15 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-12 13:47 UTC (permalink / raw)
To: lm-sensors
Hi Harry,
On Wed, 11 May 2011 11:15:05 -0600, Harry G McGavran Jr wrote:
> This new i8k crashes on my machine, the old one does not.
This is bad news. Can you tell us more? Maybe a backtrace in the logs
when the crash happens? The full error message would be useful.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (47 preceding siblings ...)
2011-05-12 13:47 ` Jean Delvare
@ 2011-05-12 13:49 ` Luca Tettamanti
2011-05-12 15:18 ` Harry G McGavran Jr
` (14 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-12 13:49 UTC (permalink / raw)
To: lm-sensors
On Wed, May 11, 2011 at 7:15 PM, Harry G McGavran Jr <w5pny@w5pny.com> wrote:
> This new i8k crashes on my machine, the old one does not.
Ok, this is bad :)
Do you get something interesting in the kernel log?
Luca
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (48 preceding siblings ...)
2011-05-12 13:49 ` Luca Tettamanti
@ 2011-05-12 15:18 ` Harry G McGavran Jr
2011-05-12 16:00 ` Jean Delvare
` (13 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-12 15:18 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23613.1305213521.1@kahu.w5pny.comcast.net>
The latest i8k insmod's ok, but when I run /usr/bin/sensors
after loading it I get the emc report and then the i8k report.
Right after sensors prints the i8k line and just before
it would give me the sensors info I get a segfault
from something related to the app, maybe /usr/bin/sensors
itself, but the window where the command is typed is frozen.
No keyboard interrupts will stop it, one has to kill the
window to stop /usr/bin/sensors. At that point other windows
are still active. There are no messages in the /var/log/messages,
syslog, or daemon log about it. As root if I try to rmmod i8k
that hangs in the same way. Ps reports that the rmmod
is in some kind of wait state and that is not interuptable either.
A reboot is the only way to clear it up.
emc6w201 seems to depend on i2c_801 and i2c_dev which I believe
i8k does as well, so I didn't load any other modules except i8k.
I had removed the Ubuntu i8kutils package as I'm no longer using i8k,
and perhaps there is some module in that package that the i8k module
needs -- I didn't check. That might be the reason, but I was guessing
the i8k modules dependencies were the came as emc6w201's.
There was nothing in the logs about any of this and no core file
for whatever is segfaulting. The only error message is the "segmentation fault"
after the /usr/bin/sensors i8k announcement line.
Harry
On Thu, 12 May 2011 15:47:43 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <23613.1305213521.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Thu, 12 May 2011 09:09:04 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id CF7601A9865
for <w5pny@localhost.localdomain>; Thu, 12 May 2011 09:09:04 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.33; Thu, 12 May 2011 06:48:31 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1025.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: y0O54XMcZAoWX4ZZo6J6M2jo3E3C6X4fxENSkZp4k.Ilmtl7
f1mZ9DAvRdmAfEKsIBlTvGXFOi8eCU69GwbMeIGHOQzJ49KCMH5St2rjrND9
Bi24X9TMKz2yZgxxsRVC4kymwkqQ7kMyatCoQeGWWK.rrayEZPUcNejTO64N
ERFcUxeRFeMnzssZVNakaIzB.KSJ15ijKKAF4P4RAoN1SDGqebAsTyWpWrMi
qrTQ3OWdqZ9HieirzOqENbPXu5fA05_l34vVggBvUqA6z8USKBxlY8A_Yhcd
3cw7ZY1WD5I8m5JSpbDxRmMrqBtZwIbYTXmQWnTXRwDFCwBJkP.MF042VKKR
SsKRTV.AgA2EcnQYTDU37jFy8gWUxosBt2jBsVq26NnZPp.Zm7.ecm7hRwnc
wUayxaAUNiemabnwnalA7jEN3f78Wsqtw0nBNx8EPkHg3sDixHk1EH2u0EU_
03Lgsyeb7mgaho88UeP5yv32GuUDKkmWNwUmt23icCV_XgGtSA--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1025.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.sp1.yahoo.com [69.147.84.46]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Thu, 12 May 2011 09:09:04 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1025.biz.mail.mud.yahoo.com with SMTP; Thu, 12 May 2011 06:48:30 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKXNg-0008H2-9D
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Thu, 12 May 2011 17:00:48 +0200
Date: Thu, 12 May 2011 15:47:43 +0200
From: Jean Delvare <khali@linux-fr.org>
To: w5pny@w5pny.com
Cc: Jeff Rickman <jrickman@myamigos.us>, Ric <fhj52rags@yahoo.com>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110512154743.64d11d7b@endymion.delvare>
In-Reply-To: <20110511171506.076881A987F@localhost.localdomain>
References: <20110511170817.08d8a203@endymion.delvare>
<20110511171506.076881A987F@localhost.localdomain>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi Harry,
On Wed, 11 May 2011 11:15:05 -0600, Harry G McGavran Jr wrote:
> This new i8k crashes on my machine, the old one does not.
This is bad news. Can you tell us more? Maybe a backtrace in the logs
when the crash happens? The full error message would be useful.
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23613.1305213521.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (49 preceding siblings ...)
2011-05-12 15:18 ` Harry G McGavran Jr
@ 2011-05-12 16:00 ` Jean Delvare
2011-05-12 16:11 ` Harry G McGavran Jr
` (12 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-12 16:00 UTC (permalink / raw)
To: lm-sensors
On Thu, 12 May 2011 09:18:41 -0600, Harry G McGavran Jr wrote:
> The latest i8k insmod's ok, but when I run /usr/bin/sensors
> after loading it I get the emc report and then the i8k report.
> Right after sensors prints the i8k line and just before
> it would give me the sensors info I get a segfault
> from something related to the app, maybe /usr/bin/sensors
> itself, but the window where the command is typed is frozen.
> No keyboard interrupts will stop it, one has to kill the
> window to stop /usr/bin/sensors. At that point other windows
> are still active. There are no messages in the /var/log/messages,
> syslog, or daemon log about it. As root if I try to rmmod i8k
> that hangs in the same way. Ps reports that the rmmod
> is in some kind of wait state and that is not interuptable either.
>
> A reboot is the only way to clear it up.
>
> emc6w201 seems to depend on i2c_801 and i2c_dev which I believe
There is a soft dependency between i2c-i801 and emc6w201, in that the
former is needed for the latter to reach the monitoring device, yes.
i2c-dev isn't needed other than for sensors-detect and debugging.
> i8k does as well, so I didn't load any other modules except i8k.
i8k doesn't depend on any other kernel module.
> I had removed the Ubuntu i8kutils package as I'm no longer using i8k,
> and perhaps there is some module in that package that the i8k module
> needs -- I didn't check. That might be the reason, but I was guessing
No, i8kutils contains a user-space helper for the i8k module, and
that's all. My changes to the i8k make it partly useless (on purpose).
> the i8k modules dependencies were the came as emc6w201's.
> There was nothing in the logs about any of this and no core file
> for whatever is segfaulting. The only error message is the "segmentation fault"
> after the /usr/bin/sensors i8k announcement line.
You can check with "ulimit -c" if a core dump will be written on
segmentation fault. But it could be that no core is written because the
problem is in i8k itself and not in the user-space application.
Unfortunately I have no idea how to investigate this further. This
makes me feel sad because Luca's findings were very promising :(
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (50 preceding siblings ...)
2011-05-12 16:00 ` Jean Delvare
@ 2011-05-12 16:11 ` Harry G McGavran Jr
2011-05-12 20:37 ` Jeff Rickman
` (11 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-12 16:11 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25820.1305216710.1@kahu.w5pny.comcast.net>
ulimit -c
81920
On Thu, 12 May 2011 18:00:51 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <25820.1305216710.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Thu, 12 May 2011 10:08:34 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id B09221A9865
for <w5pny@localhost.localdomain>; Thu, 12 May 2011 10:08:34 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.38; Thu, 12 May 2011 09:02:21 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1025.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: XpSk3fccZApIGqRdol7.I_eI9OkkbnfQv2a.P_HimnqVclE2
.Gv2pnkqejyTCp2TXjumG9aOfGrN82cnU9gFqKwuWbI_mXMc25ltIJgNPipQ
.0XbOXA.M1WbwuIji39KVFmqnNB2l8RqzGFn5lQEyIhm73ACOYhlowAXUMWq
ujyFKGixVse_6QQKZ.QPZPmpYBzN6vptPkuMWpURSMl4rI9BKm1rUiNEVURg
bFIYdz7gxGVhwhBTN7eNbMk6hIgWnuHPGQBgwg24sCYyZNLwt2Pb.D8P9m9s
mwfKNAU_ySSMQz1bnGIzNTDcOoHchCDOxN2MGVXAURL8SVEzG6qsKpszTng0
17RUCnzeF_2jCS8XcMgRUMB5Z98faCZj1spAGH2ATiOoF4YbP.magOyj9pzS
xygnJ50ZJiMGS3TANVuQKEzGP4ZhK3aYUkN4bEpzLNJCVxDrAr1QYl8kfHrj
zEx00L8PXvuFsdg_jl6qUObLbiGkjQGmwgcWTxRxIJrVZjJa4w--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1025.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.sp1.yahoo.com [69.147.84.46]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Thu, 12 May 2011 10:08:34 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1025.biz.mail.mud.yahoo.com with SMTP; Thu, 12 May 2011 09:02:21 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKZTB-0006Dq-8r
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Thu, 12 May 2011 19:14:37 +0200
Date: Thu, 12 May 2011 18:00:51 +0200
From: Jean Delvare <khali@linux-fr.org>
To: w5pny@w5pny.com
Cc: Jeff Rickman <jrickman@myamigos.us>, Ric <fhj52rags@yahoo.com>,
lm-sensors@lm-sensors.org, Luca Tettamanti <kronos.it@gmail.com>
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110512180051.50b1525b@endymion.delvare>
In-Reply-To: <20110512151841.B706F1A987F@localhost.localdomain>
References: <20110512154743.64d11d7b@endymion.delvare>
<20110512151841.B706F1A987F@localhost.localdomain>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => ALSA
On Thu, 12 May 2011 09:18:41 -0600, Harry G McGavran Jr wrote:
> The latest i8k insmod's ok, but when I run /usr/bin/sensors
> after loading it I get the emc report and then the i8k report.
> Right after sensors prints the i8k line and just before
> it would give me the sensors info I get a segfault
> from something related to the app, maybe /usr/bin/sensors
> itself, but the window where the command is typed is frozen.
> No keyboard interrupts will stop it, one has to kill the
> window to stop /usr/bin/sensors. At that point other windows
> are still active. There are no messages in the /var/log/messages,
> syslog, or daemon log about it. As root if I try to rmmod i8k
> that hangs in the same way. Ps reports that the rmmod
> is in some kind of wait state and that is not interuptable either.
>
> A reboot is the only way to clear it up.
>
> emc6w201 seems to depend on i2c_801 and i2c_dev which I believe
There is a soft dependency between i2c-i801 and emc6w201, in that the
former is needed for the latter to reach the monitoring device, yes.
i2c-dev isn't needed other than for sensors-detect and debugging.
> i8k does as well, so I didn't load any other modules except i8k.
i8k doesn't depend on any other kernel module.
> I had removed the Ubuntu i8kutils package as I'm no longer using i8k,
> and perhaps there is some module in that package that the i8k module
> needs -- I didn't check. That might be the reason, but I was guessing
No, i8kutils contains a user-space helper for the i8k module, and
that's all. My changes to the i8k make it partly useless (on purpose).
> the i8k modules dependencies were the came as emc6w201's.
> There was nothing in the logs about any of this and no core file
> for whatever is segfaulting. The only error message is the "segmentation fault"
> after the /usr/bin/sensors i8k announcement line.
You can check with "ulimit -c" if a core dump will be written on
segmentation fault. But it could be that no core is written because the
problem is in i8k itself and not in the user-space application.
Unfortunately I have no idea how to investigate this further. This
makes me feel sad because Luca's findings were very promising :(
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25820.1305216710.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (51 preceding siblings ...)
2011-05-12 16:11 ` Harry G McGavran Jr
@ 2011-05-12 20:37 ` Jeff Rickman
2011-05-12 23:49 ` Harry G McGavran Jr
` (10 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-12 20:37 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
On 5/12/2011 8:38 AM, Jean Delvare wrote:
> Hi Jeff, Luca,
>
> On Thu, 12 May 2011 15:02:08 +0200, Luca Tettamanti wrote:
>> On Wed, May 11, 2011 at 7:59 PM, Jeff Rickman<jrickman@myamigos.us> wrote:
>>> [test results]
>>> load new i8k module
>>>
>>> modprobe -v i8k
>>> insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
>>> FATAL: Error inserting i8k
>>> (/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko): No such
>>> device
>>>
>>> from /var/log/messages
>>> May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
>>> signature
>>>
>>> modprobe -v i8k force
>>> insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
>>> force
>>>
>>> from /var/log/messages
>>> May 11 12:39:11 XX kernel: [ 263.320306] i8k: unable to get SMM Dell
>>> signature
>>> May 11 12:40:52 XX kernel: [ 365.019189] i8k: unable to get SMM Dell
>>> signature
>>> May 11 12:40:52 XX kernel: [ 365.020148] i8k: unable to get SMM BIOS
>>> version
>>> May 11 12:40:52 XX kernel: [ 365.027736] Dell laptop SMM driver v1.14
>>> 21/02/2005 Massimo Dal Zotto (dz@debian.org)
>
> This is not a fatal error, you may still see interesting things
> in /proc/i8k or the output of "sensors". Although Harry's report makes
> it unlikely...
>
Jean, these are very interesting questions. I got a crash message on the
Console and found a lengthy (~70 lines) dump in Syslog. Like last time,
assembly coding skills will be required to figure it out. Sensors output
tells me I have to run "sensors-detect". Output attached.
>
>>> I will guess that this detection issue is not due to the changes made by
>>> Jean and Luca. This module may be at a dead end for my hardware.
>>
>> Hum, maybe my change is not correct. It should be possible to verify
>> to functionality of the patch on Harry's machine
>
> Harry already reported:
>
> "This new i8k crashes on my machine, the old one does not."
>
> This suggests that your patch is indeed not correct, however it looks
> good to me so I don't know what else to suggest.
>
[-- Attachment #2: Dell_Sensors_Testing_5.txt --]
[-- Type: text/plain, Size: 9549 bytes --]
[root@XX char]# cat /proc/i8k
Killed
Message from syslogd@XX at May 12 15:28:53 ...
kernel:[96086.545317] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
[root@XX char]#
Message from syslogd@XX at May 12 15:28:53 ...
kernel:[96086.545317] Stack:
Message from syslogd@XX at May 12 15:28:53 ...
kernel:[96086.545317] Call Trace:
Message from syslogd@XX at May 12 15:28:53 ...
kernel:[96086.545317] Code: 5d 41 5e 41 5f c9 c3 55 48 89 e5 53 48 83 ec 58 0f 1f 44 00 00 48 89 fb 48 89 55 d0 48 89 4d d8 4c 89 45 e0 4c 89 4d e8 48 89 f2 <48> 8b 7f 18 48 3b 7b 08 73 3e 48 8b 73 08 48 8d 45 10 48 8d 4d
Message from syslogd@XX at May 12 15:28:53 ...
kernel:[96086.545317] CR2: 0000000000000018
from /var/log/messages
May 12 15:28:08 XX kernel: [96041.748222] ------------[ cut here ]------------
May 12 15:28:08 XX kernel: [96041.755366] i8k: unable to get SMM Dell signature
May 12 15:28:08 XX kernel: [96041.756179] i8k: unable to get SMM BIOS version
May 12 15:28:08 XX kernel: [96041.748222] WARNING: at kernel/sched_clock.c:207 sched_clock_tick+0x3d/0x78()
May 12 15:28:08 XX kernel: [96041.748222] Hardware name: Precision WorkStation 670
May 12 15:28:08 XX kernel: [96041.748222] Modules linked in: i8k(+) act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit
May 12 15:28:08 XX kernel: [96041.748222] xt_realm iptable_raw
May 12 15:28:08 XX kernel: [96041.759086] Dell laptop SMM driver v1.14 21/02/2005 Massimo Dal Zotto (dz@debian.org)
May 12 15:28:08 XX kernel: [96041.748222] xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink p4_clockmod freq_table speedstep_lib e752x_edac edac_core iTCO_wdt i2c_i801 iTCO_vendor_support e1000 shpchp dcdbas serio_raw microcode firewire_ohci firewire_core crc_itu_t nouveau ttm drm_kms_helper drm i2c_a
May 12 15:28:08 XX kernel: lgo_bit video output i2c_core [last unloaded: i2c_dev]
May 12 15:28:08 XX kernel: [96041.748222] Pid: 0, comm: swapper Not tainted 2.6.35.12-90.fc14.x86_64 #1
May 12 15:28:08 XX kernel: [96041.748222] Call Trace:
May 12 15:28:08 XX kernel: [96041.748222] <IRQ> [<ffffffff8104dce1>] warn_slowpath_common+0x85/0x9d
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8104dd13>] warn_slowpath_null+0x1a/0x1c
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8106b9e6>] sched_clock_tick+0x3d/0x78
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8106ba33>] sched_clock_idle_wakeup_event+0x12/0x1b
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8107315d>] tick_nohz_stop_idle+0x3e/0x43
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81073785>] tick_check_idle+0x57/0xa8
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8100abdc>] ? call_softirq+0x1c/0x30
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81053ee1>] irq_enter+0x49/0x74
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff810218d1>] smp_call_function_single_interrupt+0x13/0x2a
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff8100a833>] call_function_single_interrupt+0x13/0x20
May 12 15:28:08 XX kernel: [96041.748222] <EOI> [<ffffffff810111b8>] ? mwait_idle+0x72/0x7b
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff810111ab>] ? mwait_idle+0x65/0x7b
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81008325>] cpu_idle+0xaa/0xcc
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81452736>] rest_init+0x8a/0x8c
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81ba1c49>] start_kernel+0x40b/0x416
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81ba12c6>] x86_64_start_reservations+0xb1/0xb5
May 12 15:28:08 XX kernel: [96041.748222] [<ffffffff81ba13c2>] x86_64_start_kernel+0xf8/0x107
May 12 15:28:08 XX kernel: [96041.748222] ---[ end trace 33dd116366d42f77 ]---
May 12 15:28:53 XX kernel: [96086.544428] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
May 12 15:28:53 XX kernel: [96086.544551] IP: [<ffffffff8112fd09>] seq_printf+0x24/0x7e
May 12 15:28:53 XX kernel: [96086.545317] PGD 7e443067 PUD 7e3fa067 PMD 0
May 12 15:28:53 XX kernel: [96086.545317] Oops: 0000 [#1] SMP
May 12 15:28:53 XX kernel: [96086.545317] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
May 12 15:28:53 XX kernel: [96086.545317] CPU 3
May 12 15:28:53 XX kernel: [96086.545317] Modules linked in: i8k act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink p4_clockmod freq_table speedstep_lib e752x_edac edac_core
May 12 15:28:53 XX kernel: iTCO_wdt i2c_i801 iTCO_vendor_support e1000 shpchp dcdbas serio_raw microcode firewire_ohci firewire_core crc_itu_t nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: i2c_dev]
May 12 15:28:53 XX kernel: [96086.545317]
May 12 15:28:53 XX kernel: [96086.545317] Pid: 27584, comm: cat Tainted: G W 2.6.35.12-90.fc14.x86_64 #1 0U7565/Precision WorkStation 670
May 12 15:28:53 XX kernel: [96086.545317] RIP: 0010:[<ffffffff8112fd09>] [<ffffffff8112fd09>] seq_printf+0x24/0x7e
May 12 15:28:53 XX kernel: [96086.545317] RSP: 0018:ffff88007ea21d58 EFLAGS: 00010292
May 12 15:28:53 XX kernel: [96086.545317] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffa0012274
May 12 15:28:53 XX kernel: [96086.545317] RDX: ffffffffa00119e6 RSI: ffffffffa00119e6 RDI: 0000000000000000
May 12 15:28:53 XX kernel: [96086.545317] RBP: ffff88007ea21db8 R08: ffffffff81e4406c R09: 00000000ffffffea
May 12 15:28:53 XX kernel: [96086.545317] R10: 0000000000000001 R11: 0000000000000246 R12: 00000000ffffffff
May 12 15:28:53 XX kernel: [96086.545317] R13: 00000000ffffffea R14: 00000000ffffffea R15: 00000000ffffffea
May 12 15:28:53 XX kernel: [96086.545317] FS: 00007fa138fd3720(0000) GS:ffff8800020c0000(0000) knlGS:0000000000000000
May 12 15:28:53 XX kernel: [96086.545317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 12 15:28:53 XX kernel: [96086.545317] CR2: 0000000000000018 CR3: 000000007d2b4000 CR4: 00000000000006e0
May 12 15:28:53 XX kernel: [96086.545317] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 12 15:28:53 XX kernel: [96086.545317] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 12 15:28:53 XX kernel: [96086.545317] Process cat (pid: 27584, threadinfo ffff88007ea20000, task ffff88007d80ae80)
May 12 15:28:53 XX kernel: [96086.545317] Stack:
May 12 15:28:53 XX kernel: [96086.545317] 0000000000000246 ffff88007ea21d78 0000000000000018 0000000000000025
May 12 15:28:53 XX kernel: [96086.545317] <0> 0000000000000246 0000000000000000 ffffffffa00119e2 ffffffffa0012274
May 12 15:28:53 XX kernel: [96086.545317] <0> ffffffff81e4406c 00000000ffffffea ffff88007ea21db8 0000000000000000
May 12 15:28:53 XX kernel: [96086.545317] Call Trace:
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffffa0011580>] i8k_proc_show+0xbe/0xcd [i8k]
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffff8112fff2>] seq_read+0x18d/0x36b
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffff81161330>] proc_reg_read+0x73/0x8c
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffff81117a45>] vfs_read+0xa9/0xfd
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffff81117ae3>] sys_read+0x4a/0x6e
May 12 15:28:53 XX kernel: [96086.545317] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
May 12 15:28:53 XX kernel: [96086.545317] Code: 5d 41 5e 41 5f c9 c3 55 48 89 e5 53 48 83 ec 58 0f 1f 44 00 00 48 89 fb 48 89 55 d0 48 89 4d d8 4c 89 45 e0 4c 89 4d e8 48 89 f2 <48> 8b 7f 18 48 3b 7b 08 73 3e 48 8b 73 08 48 8d 45 10 48 8d 4d
May 12 15:28:53 XX kernel: [96086.545317] RIP [<ffffffff8112fd09>] seq_printf+0x24/0x7e
May 12 15:28:53 XX kernel: [96086.545317] RSP <ffff88007ea21d58>
May 12 15:28:53 XX kernel: [96086.545317] CR2: 0000000000000018
May 12 15:28:53 XX kernel: [96086.545317] [drm] nouveau 0000:05:00.0: Setting dpms mode 0 on vga encoder (output 0)
May 12 15:28:53 XX kernel: [96086.627526] ---[ end trace 33dd116366d42f78 ]---
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (52 preceding siblings ...)
2011-05-12 20:37 ` Jeff Rickman
@ 2011-05-12 23:49 ` Harry G McGavran Jr
2011-05-13 12:48 ` Luca Tettamanti
` (9 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-12 23:49 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10855.1305244184.1@kahu.w5pny.comcast.net>
I went back through the logs to make sure there was nothing
about the latest i8k in them. Actually I found only ONE
line in syslog:
May 11 11:07:12 XX kernel: [173400.479332] [<ffffffffa00613f2>]
i8k_hwmon_show_fan+0x32/0x40 [i8k]
So, presumably set segfault occurs right after that....
But, maybe it's a clue for Jean or someone...
Harry
On Thu, 12 May 2011 18:00:51 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <10855.1305244184.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Thu, 12 May 2011 10:08:34 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id B09221A9865
for <w5pny@localhost.localdomain>; Thu, 12 May 2011 10:08:34 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.38; Thu, 12 May 2011 09:02:21 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1025.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: XpSk3fccZApIGqRdol7.I_eI9OkkbnfQv2a.P_HimnqVclE2
.Gv2pnkqejyTCp2TXjumG9aOfGrN82cnU9gFqKwuWbI_mXMc25ltIJgNPipQ
.0XbOXA.M1WbwuIji39KVFmqnNB2l8RqzGFn5lQEyIhm73ACOYhlowAXUMWq
ujyFKGixVse_6QQKZ.QPZPmpYBzN6vptPkuMWpURSMl4rI9BKm1rUiNEVURg
bFIYdz7gxGVhwhBTN7eNbMk6hIgWnuHPGQBgwg24sCYyZNLwt2Pb.D8P9m9s
mwfKNAU_ySSMQz1bnGIzNTDcOoHchCDOxN2MGVXAURL8SVEzG6qsKpszTng0
17RUCnzeF_2jCS8XcMgRUMB5Z98faCZj1spAGH2ATiOoF4YbP.magOyj9pzS
xygnJ50ZJiMGS3TANVuQKEzGP4ZhK3aYUkN4bEpzLNJCVxDrAr1QYl8kfHrj
zEx00L8PXvuFsdg_jl6qUObLbiGkjQGmwgcWTxRxIJrVZjJa4w--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1025.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.sp1.yahoo.com [69.147.84.46]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Thu, 12 May 2011 10:08:34 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1025.biz.mail.mud.yahoo.com with SMTP; Thu, 12 May 2011 09:02:21 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKZTB-0006Dq-8r
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Thu, 12 May 2011 19:14:37 +0200
Date: Thu, 12 May 2011 18:00:51 +0200
From: Jean Delvare <khali@linux-fr.org>
To: w5pny@w5pny.com
Cc: Jeff Rickman <jrickman@myamigos.us>, Ric <fhj52rags@yahoo.com>,
lm-sensors@lm-sensors.org, Luca Tettamanti <kronos.it@gmail.com>
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110512180051.50b1525b@endymion.delvare>
In-Reply-To: <20110512151841.B706F1A987F@localhost.localdomain>
References: <20110512154743.64d11d7b@endymion.delvare>
<20110512151841.B706F1A987F@localhost.localdomain>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => ALSA
On Thu, 12 May 2011 09:18:41 -0600, Harry G McGavran Jr wrote:
> The latest i8k insmod's ok, but when I run /usr/bin/sensors
> after loading it I get the emc report and then the i8k report.
> Right after sensors prints the i8k line and just before
> it would give me the sensors info I get a segfault
> from something related to the app, maybe /usr/bin/sensors
> itself, but the window where the command is typed is frozen.
> No keyboard interrupts will stop it, one has to kill the
> window to stop /usr/bin/sensors. At that point other windows
> are still active. There are no messages in the /var/log/messages,
> syslog, or daemon log about it. As root if I try to rmmod i8k
> that hangs in the same way. Ps reports that the rmmod
> is in some kind of wait state and that is not interuptable either.
>
> A reboot is the only way to clear it up.
>
> emc6w201 seems to depend on i2c_801 and i2c_dev which I believe
There is a soft dependency between i2c-i801 and emc6w201, in that the
former is needed for the latter to reach the monitoring device, yes.
i2c-dev isn't needed other than for sensors-detect and debugging.
> i8k does as well, so I didn't load any other modules except i8k.
i8k doesn't depend on any other kernel module.
> I had removed the Ubuntu i8kutils package as I'm no longer using i8k,
> and perhaps there is some module in that package that the i8k module
> needs -- I didn't check. That might be the reason, but I was guessing
No, i8kutils contains a user-space helper for the i8k module, and
that's all. My changes to the i8k make it partly useless (on purpose).
> the i8k modules dependencies were the came as emc6w201's.
> There was nothing in the logs about any of this and no core file
> for whatever is segfaulting. The only error message is the "segmentation fault"
> after the /usr/bin/sensors i8k announcement line.
You can check with "ulimit -c" if a core dump will be written on
segmentation fault. But it could be that no core is written because the
problem is in i8k itself and not in the user-space application.
Unfortunately I have no idea how to investigate this further. This
makes me feel sad because Luca's findings were very promising :(
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10855.1305244184.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (53 preceding siblings ...)
2011-05-12 23:49 ` Harry G McGavran Jr
@ 2011-05-13 12:48 ` Luca Tettamanti
2011-05-13 15:01 ` Jean Delvare
` (8 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Luca Tettamanti @ 2011-05-13 12:48 UTC (permalink / raw)
To: lm-sensors
On Thu, May 12, 2011 at 05:49:44PM -0600, Harry G McGavran Jr wrote:
> I went back through the logs to make sure there was nothing
> about the latest i8k in them. Actually I found only ONE
> line in syslog:
>
> May 11 11:07:12 XX kernel: [173400.479332] [<ffffffffa00613f2>]
> i8k_hwmon_show_fan+0x32/0x40 [i8k]
Ok, this is consistent with the hung program reported by Jeff, there's
an error at kernel level while the sensor is being read.
AMD64 Architecture Manual says that:
(pushf) In 64-bit mode, this instruction defaults to a 64-bit operand
size and there is no prefix available to encode a 32-bit operand size.
so my patch may be corrupting the stack. Lets try like this:
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d72433f..ee01716 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edi,20(%%rax)\n\t"
"popq %%rdx\n\t"
"movl %%edx,0(%%rax)\n\t"
- "lahf\n\t"
- "shrl $8,%%eax\n\t"
+ "pushfq\n\t"
+ "popq %%rax\n\t"
"andl $1,%%eax\n"
:"=a"(rc)
: "a"(regs)
If it still doesn't work we should involve someone who actually has a
clue about x86 asm ;)
Luca
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (54 preceding siblings ...)
2011-05-13 12:48 ` Luca Tettamanti
@ 2011-05-13 15:01 ` Jean Delvare
2011-05-13 15:42 ` Harry G McGavran Jr
` (7 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-13 15:01 UTC (permalink / raw)
To: lm-sensors
On Fri, 13 May 2011 14:48:01 +0200, Luca Tettamanti wrote:
> On Thu, May 12, 2011 at 05:49:44PM -0600, Harry G McGavran Jr wrote:
> > I went back through the logs to make sure there was nothing
> > about the latest i8k in them. Actually I found only ONE
> > line in syslog:
> >
> > May 11 11:07:12 XX kernel: [173400.479332] [<ffffffffa00613f2>]
> > i8k_hwmon_show_fan+0x32/0x40 [i8k]
>
> Ok, this is consistent with the hung program reported by Jeff, there's
> an error at kernel level while the sensor is being read.
>
> AMD64 Architecture Manual says that:
>
> (pushf) In 64-bit mode, this instruction defaults to a 64-bit operand
> size and there is no prefix available to encode a 32-bit operand size.
D'oh. I suspected something like this, but given that pushfq exists, I
assumed pushf had to be different. I guess I shouldn't have assumed...
>
> so my patch may be corrupting the stack. Lets try like this:
>
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index d72433f..ee01716 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> "movl %%edi,20(%%rax)\n\t"
> "popq %%rdx\n\t"
> "movl %%edx,0(%%rax)\n\t"
> - "lahf\n\t"
> - "shrl $8,%%eax\n\t"
> + "pushfq\n\t"
> + "popq %%rax\n\t"
> "andl $1,%%eax\n"
> :"=a"(rc)
> : "a"(regs)
>
>
> If it still doesn't work we should involve someone who actually has a
> clue about x86 asm ;)
Hopefully it will work OK this time. I've updated the driver at:
http://khali.linux-fr.org/devel/misc/i8k/
Harry, Jeff, care to try again? 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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (55 preceding siblings ...)
2011-05-13 15:01 ` Jean Delvare
@ 2011-05-13 15:42 ` Harry G McGavran Jr
2011-05-13 16:44 ` Jean Delvare
` (6 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-13 15:42 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13666.1305301348.1@kahu.w5pny.comcast.net>
This new i8k seems to work on my system.
====================
XX% /usr/bin/sensors
i8k-virtual-0
Adapter: Virtual device
Left Fan: 64650 RPM
Right Fan: 48390 RPM
emc6w201-i2c-0-2e
Adapter: SMBus I801 adapter at e8a0
Aux: +1.82 V (min = +1.64 V, max = +1.98 V)
CPU VCore: +1.26 V (min = +0.78 V, max = +1.70 V)
+3.3V: +3.33 V (min = +3.08 V, max = +3.52 V)
+5V: +5.10 V (min = +4.66 V, max = +5.34 V)
+12V: +12.06 V (min = +0.81 V, max = +12.81 V)
Chassis: 1613 RPM (min = 300 RPM)
CPU: 2153 RPM (min = 200 RPM)
CPU: +54.0 C (low = -127.0 C, high = +88.0 C)
Remote Diode 5: +48.0 C (low = -127.0 C, high = +75.0 C)
Mainboard: +44.0 C (low = -127.0 C, high = +80.0 C)
=======================
The only entry in syslog as a result of the above is:
May 13 09:37:40 kahu kernel: [167232.194108] i8k: unable to get SMM BIOS
version
but that has occurred with all the i8k's I've tried.
Harry
On Fri, 13 May 2011 17:01:30 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <13666.1305301348.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Fri, 13 May 2011 09:16:48 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id 0D6BC1A9880
for <w5pny@localhost.localdomain>; Fri, 13 May 2011 09:16:48 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.33; Fri, 13 May 2011 08:03:00 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1009.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: AkPoQkocZArspGm3vSjnya9_4oRE7pbyKXdy1uEFoY.W2Hw2
pbslEzOv9IVATq7YtWGPhF2wv7WY0WouJwP18d8kJZh4Km.CFBCW0OJlHEMC
0S5p7_enWWOfACf.1PTlQ9EtvF4dRtBFQ5hwMNi6hsGxfDMGX3A56Oq7zn17
1yEUFiIv4l.Wp.c4Uuo7TZXVkMCkaepU2j14tTq5n5Xg09jag.Tfe0F_f4lb
nmSWqjAOTQfwztbq_rHQ2iEUGyksmB68sirIl.mXVJAJSfGcEy4AjZGq9R49
06YpVfKU4rekKPRv02p39RJdnnypA7Rmx.sk2pn52hm4Zq15Pfh3FWrd2Nah
U81PJECAw8UDQOQh.hpDxGjwHuXuJRbb4oclUd__KltqE9C6Tn88g.SqJZBL
9_tB1QoLMHWIK1Tc4OtkRyRfsqKSiuOGZuK6pbxofN0UcHRCTcFv_KYHGRyA
Sa61.sjUGn8l33Br5VJMkUi.GHBMPdj1E3gC5y4bwXRFTRQn3dWyVuZmwAAp
ifTrZ0iGEvXyzTX2h6Gzt7VkfkS0
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1009.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.ne1.yahoo.com [98.138.82.28]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Fri, 13 May 2011 09:16:48 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1009.biz.mail.mud.yahoo.com with SMTP; Fri, 13 May 2011 08:03:00 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKv1J-0005iS-L0
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Fri, 13 May 2011 18:15:17 +0200
Date: Fri, 13 May 2011 17:01:30 +0200
From: Jean Delvare <khali@linux-fr.org>
To: Luca Tettamanti <kronos.it@gmail.com>
Cc: Harry G McGavran Jr <w5pny@w5pny.com>, Jeff Rickman
<jrickman@myamigos.us>, Ric <fhj52rags@yahoo.com>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110513170130.70957eec@endymion.delvare>
In-Reply-To: <20110513124726.GA20870@nb-core2.darkstar.lan>
References: <20110512180051.50b1525b@endymion.delvare>
<20110512234944.9205E1A987F@localhost.localdomain>
<20110513124726.GA20870@nb-core2.darkstar.lan>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => Dell670
On Fri, 13 May 2011 14:48:01 +0200, Luca Tettamanti wrote:
> On Thu, May 12, 2011 at 05:49:44PM -0600, Harry G McGavran Jr wrote:
> > I went back through the logs to make sure there was nothing
> > about the latest i8k in them. Actually I found only ONE
> > line in syslog:
> >
> > May 11 11:07:12 XX kernel: [173400.479332] [<ffffffffa00613f2>]
> > i8k_hwmon_show_fan+0x32/0x40 [i8k]
>
> Ok, this is consistent with the hung program reported by Jeff, there's
> an error at kernel level while the sensor is being read.
>
> AMD64 Architecture Manual says that:
>
> (pushf) In 64-bit mode, this instruction defaults to a 64-bit operand
> size and there is no prefix available to encode a 32-bit operand size.
D'oh. I suspected something like this, but given that pushfq exists, I
assumed pushf had to be different. I guess I shouldn't have assumed...
>
> so my patch may be corrupting the stack. Lets try like this:
>
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index d72433f..ee01716 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -139,8 +139,8 @@ static int i8k_smm(struct smm_regs *regs)
> "movl %%edi,20(%%rax)\n\t"
> "popq %%rdx\n\t"
> "movl %%edx,0(%%rax)\n\t"
> - "lahf\n\t"
> - "shrl $8,%%eax\n\t"
> + "pushfq\n\t"
> + "popq %%rax\n\t"
> "andl $1,%%eax\n"
> :"=a"(rc)
> : "a"(regs)
>
>
> If it still doesn't work we should involve someone who actually has a
> clue about x86 asm ;)
Hopefully it will work OK this time. I've updated the driver at:
http://khali.linux-fr.org/devel/misc/i8k/
Harry, Jeff, care to try again? Thanks.
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13666.1305301348.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (56 preceding siblings ...)
2011-05-13 15:42 ` Harry G McGavran Jr
@ 2011-05-13 16:44 ` Jean Delvare
2011-05-13 17:28 ` Harry G McGavran Jr
` (5 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-13 16:44 UTC (permalink / raw)
To: lm-sensors
On Fri, 13 May 2011 09:42:28 -0600, Harry G McGavran Jr wrote:
> This new i8k seems to work on my system.
>
> ====================>
> XX% /usr/bin/sensors
> i8k-virtual-0
> Adapter: Virtual device
> Left Fan: 64650 RPM
> Right Fan: 48390 RPM
As said before, you'd need option fan_mult=1 to get proper readings.
But well, in the long run I guess you'll stop using i8k anyway, as it
provides fewer values than the emc6w201 driver.
> emc6w201-i2c-0-2e
> Adapter: SMBus I801 adapter at e8a0
> Aux: +1.82 V (min = +1.64 V, max = +1.98 V)
> CPU VCore: +1.26 V (min = +0.78 V, max = +1.70 V)
> +3.3V: +3.33 V (min = +3.08 V, max = +3.52 V)
> +5V: +5.10 V (min = +4.66 V, max = +5.34 V)
> +12V: +12.06 V (min = +0.81 V, max = +12.81 V)
> Chassis: 1613 RPM (min = 300 RPM)
> CPU: 2153 RPM (min = 200 RPM)
> CPU: +54.0 C (low = -127.0 C, high = +88.0 C)
> Remote Diode 5: +48.0 C (low = -127.0 C, high = +75.0 C)
> Mainboard: +44.0 C (low = -127.0 C, high = +80.0 C)
>
> =======================>
> The only entry in syslog as a result of the above is:
>
> May 13 09:37:40 kahu kernel: [167232.194108] i8k: unable to get SMM BIOS
> version
>
> but that has occurred with all the i8k's I've tried.
Looks very promising. Now let's wait for Jeff's report.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (57 preceding siblings ...)
2011-05-13 16:44 ` Jean Delvare
@ 2011-05-13 17:28 ` Harry G McGavran Jr
2011-05-13 17:47 ` Jeff Rickman
` (4 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-13 17:28 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18804.1305307729.1@kahu.w5pny.comcast.net>
Yes, I just did "insmod i8k.ko" without any options.
BTW, you had said in an earlier e-mail that you though
I'd have to pass force=1 or ignore_dmi=1 to get i8k to
load, but I never needed either of these.
This i8k seems to work fine, but the emc6w201 driver
does what I really need (almost) much much better.
Thanks again!
Harry
On Fri, 13 May 2011 18:44:10 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <18804.1305307729.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Fri, 13 May 2011 11:19:14 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id 0E5DF1A9865
for <w5pny@localhost.localdomain>; Fri, 13 May 2011 11:19:14 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.37; Fri, 13 May 2011 09:45:42 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1023.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: sZ57BdgcZAoIoMgKiWcH_HMrPXp8jnf_mWHlnzzcYoIw1CDg
3X2KVhWKpm1rJfVDKTFY6AVkpDW7LsoXe6KcobbNyAvlS7fY18y8L8yMpwLj
nnsNcBysS4qGBDrUuwHOD57nwy_.3q.VqMCouZjYeLs5.LxnlZePkxb364SK
N2weMoKAR2.rCEt8CCS8eYqwMnP8t2BgnPtsiOzRfDQW0efcf5r_ivqyAP0x
kwanBF7rYlb7iDXbq9XcTyUtTSY.mxdoQtL4s_4ewng.mMuXRO35fldsJpje
Fi_tcAb62qSUkWtmBJUUzZpXGywQL2iBSpfj7KHZ.3r8MHM7O1qa3ihw4DYB
R.JJdkrhxNjVKS5QNX8eKjuXoszE87MZ7h.G8hV9CGnN0wnng5BvXhl4Pr1r
UGBYQ4fixQFY3S.cD.GRvLwJx9aYJoybkPP8q64XzLGryL_uxmnNLz4kVH7.
RRGiCJgbaZywJsvFjU6SMswZwwXiXAOieJH.h2jLx5j.iso5nQ--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1023.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.ne1.yahoo.com [98.138.82.28]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Fri, 13 May 2011 11:19:14 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1023.biz.mail.mud.yahoo.com with SMTP; Fri, 13 May 2011 09:45:41 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKwcf-0004DI-I1
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Fri, 13 May 2011 19:57:57 +0200
Date: Fri, 13 May 2011 18:44:10 +0200
From: Jean Delvare <khali@linux-fr.org>
To: w5pny@w5pny.com
Cc: Jeff Rickman <jrickman@myamigos.us>, Ric <fhj52rags@yahoo.com>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110513184410.1b60d368@endymion.delvare>
In-Reply-To: <20110513154228.89DA01A987F@localhost.localdomain>
References: <20110513170130.70957eec@endymion.delvare>
<20110513154228.89DA01A987F@localhost.localdomain>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => Dell670
On Fri, 13 May 2011 09:42:28 -0600, Harry G McGavran Jr wrote:
> This new i8k seems to work on my system.
>
> ====================>
> XX% /usr/bin/sensors
> i8k-virtual-0
> Adapter: Virtual device
> Left Fan: 64650 RPM
> Right Fan: 48390 RPM
As said before, you'd need option fan_mult=1 to get proper readings.
But well, in the long run I guess you'll stop using i8k anyway, as it
provides fewer values than the emc6w201 driver.
> emc6w201-i2c-0-2e
> Adapter: SMBus I801 adapter at e8a0
> Aux: +1.82 V (min = +1.64 V, max = +1.98 V)
> CPU VCore: +1.26 V (min = +0.78 V, max = +1.70 V)
> +3.3V: +3.33 V (min = +3.08 V, max = +3.52 V)
> +5V: +5.10 V (min = +4.66 V, max = +5.34 V)
> +12V: +12.06 V (min = +0.81 V, max = +12.81 V)
> Chassis: 1613 RPM (min = 300 RPM)
> CPU: 2153 RPM (min = 200 RPM)
> CPU: +54.0 C (low = -127.0 C, high = +88.0 C)
> Remote Diode 5: +48.0 C (low = -127.0 C, high = +75.0 C)
> Mainboard: +44.0 C (low = -127.0 C, high = +80.0 C)
>
> =======================>
> The only entry in syslog as a result of the above is:
>
> May 13 09:37:40 kahu kernel: [167232.194108] i8k: unable to get SMM BIOS
> version
>
> but that has occurred with all the i8k's I've tried.
Looks very promising. Now let's wait for Jeff's report.
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18804.1305307729.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (58 preceding siblings ...)
2011-05-13 17:28 ` Harry G McGavran Jr
@ 2011-05-13 17:47 ` Jeff Rickman
2011-05-13 19:36 ` Jean Delvare
` (3 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jeff Rickman @ 2011-05-13 17:47 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On 5/13/2011 11:44 AM, Jean Delvare wrote:
> On Fri, 13 May 2011 09:42:28 -0600, Harry G McGavran Jr wrote:
>> This new i8k seems to work on my system.
>>
>> =========================================
>>
>> XX% /usr/bin/sensors
>> i8k-virtual-0
>> Adapter: Virtual device
>> Left Fan: 64650 RPM
>> Right Fan: 48390 RPM
>
> As said before, you'd need option fan_mult=1 to get proper readings.
> But well, in the long run I guess you'll stop using i8k anyway, as it
> provides fewer values than the emc6w201 driver.
>
>> emc6w201-i2c-0-2e
>> Adapter: SMBus I801 adapter at e8a0
>> Aux: +1.82 V (min = +1.64 V, max = +1.98 V)
>> CPU VCore: +1.26 V (min = +0.78 V, max = +1.70 V)
>> +3.3V: +3.33 V (min = +3.08 V, max = +3.52 V)
>> +5V: +5.10 V (min = +4.66 V, max = +5.34 V)
>> +12V: +12.06 V (min = +0.81 V, max = +12.81 V)
>> Chassis: 1613 RPM (min = 300 RPM)
>> CPU: 2153 RPM (min = 200 RPM)
>> CPU: +54.0 C (low = -127.0 C, high = +88.0 C)
>> Remote Diode 5: +48.0 C (low = -127.0 C, high = +75.0 C)
>> Mainboard: +44.0 C (low = -127.0 C, high = +80.0 C)
>>
>> ===============================================
>>
>> The only entry in syslog as a result of the above is:
>>
>> May 13 09:37:40 kahu kernel: [167232.194108] i8k: unable to get SMM BIOS
>> version
>>
>> but that has occurred with all the i8k's I've tried.
>
> Looks very promising. Now let's wait for Jeff's report.
>
I have promising results; no crash messages. "sensors" out that shows
N/A. See attached.
I still need to use the "force" option or else I get the "no such
device" error message. See attached.
[-- Attachment #2: Dell_Sensors_Testing_6.txt --]
[-- Type: text/plain, Size: 973 bytes --]
# modprobe -v i8k
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko
FATAL: Error inserting i8k (/lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko): No such device
# tail /var/log/messages
May 13 12:38:52 XX kernel: [ 88.685362] i8k: unable to get SMM Dell signature
# modprobe -v i8k force
insmod /lib/modules/2.6.35.12-90.fc14.x86_64/kernel/drivers/char/i8k.ko force
# tail /var/log/messages
May 13 12:38:52 XX kernel: [ 88.685362] i8k: unable to get SMM Dell signature
May 13 12:39:12 XX kernel: [ 108.804152] i8k: unable to get SMM Dell signature
May 13 12:39:12 XX kernel: [ 108.805114] i8k: unable to get SMM BIOS version
May 13 12:39:12 XX kernel: [ 108.816693] Dell laptop SMM driver v1.14 21/02/2005 Massimo Dal Zotto (dz@debian.org)
# sensors
i8k-virtual-0
Adapter: Virtual device
Left Fan: N/A
Right Fan: N/A
No further messages in Syslog. No error messages related to running "sensors" command.
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (59 preceding siblings ...)
2011-05-13 17:47 ` Jeff Rickman
@ 2011-05-13 19:36 ` Jean Delvare
2011-05-13 19:47 ` Harry G McGavran Jr
` (2 subsequent siblings)
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-13 19:36 UTC (permalink / raw)
To: lm-sensors
Hi Jeff,
On Fri, 13 May 2011 12:47:07 -0500, Jeff Rickman wrote:
> On 5/13/2011 11:44 AM, Jean Delvare wrote:
> > Looks very promising. Now let's wait for Jeff's report.
>
> I have promising results; no crash messages. "sensors" out that shows
> N/A. See attached.
>
> I still need to use the "force" option or else I get the "no such
> device" error message. See attached.
That's good enough as far as I'm concerned. The driver wasn't written
for this machine, it happens to work on Harry's, good for him, but as
long as the driver doesn't crash, that's fine with me. If you see N/A
in the output of "sensors" because the driver doesn't get any value
from the BIOS (cat /proc/i8k will certainly return many -22s.) Why it
works on Harry's machine and not on yours while they seem pretty
similar is certainly strange, but that's out of scope for me.
So, thanks Jeff and Harry for the testing on i8k, at least the assembly
code problem is solved. Luca, are you going to make a proper
submission, or should I handle it? I don't want to steal the credit
from you.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (60 preceding siblings ...)
2011-05-13 19:36 ` Jean Delvare
@ 2011-05-13 19:47 ` Harry G McGavran Jr
2011-05-13 21:10 ` Jean Delvare
2011-05-13 22:55 ` Harry G McGavran Jr
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-13 19:47 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26415.1305316033.1@kahu.w5pny.comcast.net>
I'm certainly not a wiz on device drivers, but could it be
that the N/A's Jeff is getting have something to do with
that fact the he has to do the "force" insmod option to avoid
"no such device" errors.
Harry
On Fri, 13 May 2011 21:36:17 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <26415.1305316033.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Fri, 13 May 2011 13:45:05 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id D7AB41A9865
for <w5pny@localhost.localdomain>; Fri, 13 May 2011 13:45:05 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.48; Fri, 13 May 2011 12:37:48 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1006.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: VxcVmJIcZAo3rMyxv4sVfGvBV8IFFOp9zfpQBc2SNKfNCws3
uLcYIUhG.D9XXBwNPXHkI0dXjY6108NrBvE5oKQ4qlj02ll4tBsfJbPlp21Z
tSmG1XwTlMCZRqnaZkNoDqqoE_4pqRMUL5bMq3JukhrVkvrtDsI4xeKJGSaF
PvoOP8pp9NobJPlD7k2kV7y9mJb84wFNWi0uv90VQh2PaJ5Hbdu1ZiNdHH7g
NToeYXsy4UdFofheKV4zHb4uDwqMJe4YCVLUNWbXVp7AdVfxWo_GVCnZo4HS
I3tvTC8zGM3uEwL.UYttbjK50d_7bmkPktLIakoouhjQ2yBdijqnul6fzQ50
56auRU0bDEwdHi.KoumO7WOIkAqyy62rS.mxsQEpTIrncDZGxbp8fDM1iGzJ
531A_GZi4CTbFIJ0DHcuobVsC1dw2b4xLUnFNVf8oqxmlZ.JeaxfMW81WDX9
RnYkN1KH9Ljzr8zRbnpwlGVQFnqep0SKPL0ry98zEd0DdU2rHA--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1006.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.bf1.yahoo.com [98.139.210.98]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Fri, 13 May 2011 13:45:05 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1006.biz.mail.mud.yahoo.com with SMTP; Fri, 13 May 2011 12:37:48 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QKzJF-0005Jb-77
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Fri, 13 May 2011 22:50:05 +0200
Date: Fri, 13 May 2011 21:36:17 +0200
From: Jean Delvare <khali@linux-fr.org>
To: Jeff Rickman <jrickman@myamigos.us>
Cc: w5pny@w5pny.com, Ric <fhj52rags@yahoo.com>, lm-sensors@lm-sensors.org,
Luca Tettamanti <kronos.it@gmail.com>
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110513213617.5bfac5b5@endymion.delvare>
In-Reply-To: <4DCD6E9B.7020700@myamigos.us>
References: <20110513170130.70957eec@endymion.delvare>
<20110513154228.89DA01A987F@localhost.localdomain>
<20110513184410.1b60d368@endymion.delvare>
<4DCD6E9B.7020700@myamigos.us>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => Dell670
Hi Jeff,
On Fri, 13 May 2011 12:47:07 -0500, Jeff Rickman wrote:
> On 5/13/2011 11:44 AM, Jean Delvare wrote:
> > Looks very promising. Now let's wait for Jeff's report.
>
> I have promising results; no crash messages. "sensors" out that shows
> N/A. See attached.
>
> I still need to use the "force" option or else I get the "no such
> device" error message. See attached.
That's good enough as far as I'm concerned. The driver wasn't written
for this machine, it happens to work on Harry's, good for him, but as
long as the driver doesn't crash, that's fine with me. If you see N/A
in the output of "sensors" because the driver doesn't get any value
from the BIOS (cat /proc/i8k will certainly return many -22s.) Why it
works on Harry's machine and not on yours while they seem pretty
similar is certainly strange, but that's out of scope for me.
So, thanks Jeff and Harry for the testing on i8k, at least the assembly
code problem is solved. Luca, are you going to make a proper
submission, or should I handle it? I don't want to steal the credit
from you.
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26415.1305316033.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (61 preceding siblings ...)
2011-05-13 19:47 ` Harry G McGavran Jr
@ 2011-05-13 21:10 ` Jean Delvare
2011-05-13 22:55 ` Harry G McGavran Jr
63 siblings, 0 replies; 65+ messages in thread
From: Jean Delvare @ 2011-05-13 21:10 UTC (permalink / raw)
To: lm-sensors
On Fri, 13 May 2011 13:47:13 -0600, Harry G McGavran Jr wrote:
> I'm certainly not a wiz on device drivers, but could it be
> that the N/A's Jeff is getting have something to do with
> that fact the he has to do the "force" insmod option to avoid
> "no such device" errors.
Yes Harry this is certainly related. But I have no idea why he needs
the force and you don't.
--
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] 65+ messages in thread
* Re: [lm-sensors] Will there ever be EMC6w201 support?
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
` (62 preceding siblings ...)
2011-05-13 21:10 ` Jean Delvare
@ 2011-05-13 22:55 ` Harry G McGavran Jr
63 siblings, 0 replies; 65+ messages in thread
From: Harry G McGavran Jr @ 2011-05-13 22:55 UTC (permalink / raw)
To: lm-sensors
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2562.1305327316.1@kahu.w5pny.comcast.net>
What I was getting at was the "device" that was not found
might be the same device that fan data was obtained from.
It just seemed like a good hunch based of the fact that
the fan tachometer is a "device" and the module isn't
finding a "device." Granted there is no reason for the
"devices" to be the same. Coincidences are not all that
common so it was a guess.
Harry McGavran
On Fri, 13 May 2011 23:10:51 +0200 Jean Delvare wrote:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <2562.1305327316.2@kahu.w5pny.comcast.net>
Content-Description: original message
Return-Path: khali@linux-fr.org
Delivery-Date: Fri, 13 May 2011 16:50:45 -0600
Return-Path: <khali@linux-fr.org>
X-Original-To: w5pny@localhost.localdomain
Delivered-To: w5pny@localhost.localdomain
Received: from kahu.w5pny.comcast.net (localhost.localdomain [127.0.0.1])
by localhost.localdomain (Postfix) with ESMTP id C24F51A987F
for <w5pny@localhost.localdomain>; Fri, 13 May 2011 16:50:45 -0600 (MDT)
X-Apparently-To: w5pny@w5pny.com via 74.6.114.38; Fri, 13 May 2011 14:12:20 -0700
X-YahooFilteredBulk: 212.85.147.21
Received-SPF: none (mta1009.biz.mail.mud.yahoo.com: domain of khali@linux-fr.org does not designate permitted sender hosts)
X-YMailISG: iBF4R2IcZAon2SOiKCUTMGMJaCcyaj2iYoIb2cYcMBdXCK_4
cEiCvp6vSKemuuvmR0DQFZOcKPKsbjyApPC4eyZJyKvDRg_S5QszM0._GmES
1Vkzrf3UVkMrfQRPpVtOj8spsrjIXpqH_u_ri9WVzctpJf4BJoUXYIXOOVFQ
RrjmR7U5gLWu_lsIUk0xXJjw_YCeG7MCdR.dgTgJsOR6U.oXGzh.D0T5c2JX
6JfhWMUcRHRe10G0MAtK4cW5JWBVnOSwzilP.3oxirhsx.gKg5GqHDJlGdyK
d7UbRgmEhsyA7qr5sro8yrlu2t4FLZ.JxsJVW.mVtvkK90ZOPgouk5BxZMVb
UeNWsXP8ByYyKWVuDVS5B.h9.JbRmC95b6qobhHTogTKMEeHnS0s3eTG.VGJ
FHfAjo2I.Skqb_H5KeRdzXC2mRBeWzNfXC.Nn5xnCkARm0UreTlTrTKf0KCD
p7i75bxyaHwk8B2CYMbAwVj2TiN4haXp7arTxvmBGxPlpUsK6A--
X-Originating-IP: [212.85.147.21]
Authentication-Results: mta1009.biz.mail.mud.yahoo.com from=linux-fr.org; domainkeys=neutral (no sig); from=linux-fr.org; dkim=neutral (no sig)
Received: from pop1.biz.mail.vip.bf1.yahoo.com [98.139.210.98]
by kahu.w5pny.comcast.net with POP3 (fetchmail-6.3.19)
for <w5pny@localhost.localdomain> (single-drop); Fri, 13 May 2011 16:50:45 -0600 (MDT)
Received: from 127.0.0.1 (EHLO services.gcu-squad.org) (212.85.147.21)
by mta1009.biz.mail.mud.yahoo.com with SMTP; Fri, 13 May 2011 14:12:20 -0700
Received: from jdelvare.pck.nerim.net ([62.212.121.182] helo=endymion.delvare)
by services.gcu-squad.org (GCU Mailer Daemon) with esmtpsa id 1QL0mk-00036d-By
(TLSv1:AES128-SHA:128)
(envelope-from <khali@linux-fr.org>)
; Sat, 14 May 2011 00:24:38 +0200
Date: Fri, 13 May 2011 23:10:51 +0200
From: Jean Delvare <khali@linux-fr.org>
To: w5pny@w5pny.com
Cc: Ric <fhj52rags@yahoo.com>, lm-sensors@lm-sensors.org, Luca Tettamanti
<kronos.it@gmail.com>
Subject: Re: [lm-sensors] Will there ever be EMC6w201 support?
Message-ID: <20110513231051.29c767a7@endymion.delvare>
In-Reply-To: <20110513194713.30E4C1A987F@localhost.localdomain>
References: <20110513213617.5bfac5b5@endymion.delvare>
<20110513194713.30E4C1A987F@localhost.localdomain>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-filter: ifile 1.3.8 => inbox
On Fri, 13 May 2011 13:47:13 -0600, Harry G McGavran Jr wrote:
> I'm certainly not a wiz on device drivers, but could it be
> that the N/A's Jeff is getting have something to do with
> that fact the he has to do the "force" insmod option to avoid
> "no such device" errors.
Yes Harry this is certainly related. But I have no idea why he needs
the force and you don't.
--
Jean Delvare
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2562.1305327316.3@kahu.w5pny.comcast.net>
--
Harry G. McGavran, Jr.
E-mail: w5pny@w5pny.com
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
------- =_aaaaaaaaaa0--
^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2011-05-13 22:55 UTC | newest]
Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-14 3:46 [lm-sensors] Will there ever be EMC6w201 support? Harry G McGavran Jr
2011-04-14 7:57 ` Jean Delvare
2011-04-14 15:19 ` Harry G McGavran Jr
2011-04-14 15:24 ` Harry G McGavran Jr
2011-04-15 15:25 ` Harry G McGavran Jr
2011-05-05 10:10 ` Jean Delvare
2011-05-05 15:16 ` Harry G McGavran Jr
2011-05-05 16:30 ` Jean Delvare
2011-05-05 16:40 ` Harry G McGavran Jr
2011-05-06 15:24 ` Jeff Rickman
2011-05-07 7:46 ` Jean Delvare
2011-05-07 7:49 ` Jean Delvare
2011-05-07 11:47 ` Jean Delvare
2011-05-07 16:23 ` Harry G McGavran Jr
2011-05-07 16:26 ` Harry G McGavran Jr
2011-05-08 0:05 ` Harry G McGavran Jr
2011-05-08 4:09 ` Jeff Rickman
2011-05-08 6:27 ` Jean Delvare
2011-05-08 8:39 ` Hans de Goede
2011-05-08 9:18 ` Jean Delvare
2011-05-08 9:25 ` Jean Delvare
2011-05-08 11:19 ` Jeff Rickman
2011-05-08 12:29 ` Jean Delvare
2011-05-08 12:40 ` Jeff Rickman
2011-05-08 15:27 ` Harry G McGavran Jr
2011-05-09 3:32 ` Jeff Rickman
2011-05-09 19:42 ` Jean Delvare
2011-05-09 19:50 ` Harry G McGavran Jr
2011-05-09 20:07 ` Jean Delvare
2011-05-09 20:21 ` Harry G McGavran Jr
2011-05-09 20:24 ` Guenter Roeck
2011-05-09 21:06 ` Harry G McGavran Jr
2011-05-10 13:54 ` Jeff Rickman
2011-05-10 14:06 ` Jeff Rickman
2011-05-10 14:08 ` Jeff Rickman
2011-05-10 14:24 ` Jean Delvare
2011-05-10 15:05 ` Jeff Rickman
2011-05-11 12:43 ` Luca Tettamanti
2011-05-11 13:48 ` Luca Tettamanti
2011-05-11 14:15 ` Jean Delvare
2011-05-11 14:28 ` Luca Tettamanti
2011-05-11 15:08 ` Jean Delvare
2011-05-11 17:15 ` Harry G McGavran Jr
2011-05-11 17:23 ` Jeff Rickman
2011-05-11 17:59 ` Jeff Rickman
2011-05-11 19:03 ` Jean Delvare
2011-05-12 13:02 ` Luca Tettamanti
2011-05-12 13:38 ` Jean Delvare
2011-05-12 13:47 ` Jean Delvare
2011-05-12 13:49 ` Luca Tettamanti
2011-05-12 15:18 ` Harry G McGavran Jr
2011-05-12 16:00 ` Jean Delvare
2011-05-12 16:11 ` Harry G McGavran Jr
2011-05-12 20:37 ` Jeff Rickman
2011-05-12 23:49 ` Harry G McGavran Jr
2011-05-13 12:48 ` Luca Tettamanti
2011-05-13 15:01 ` Jean Delvare
2011-05-13 15:42 ` Harry G McGavran Jr
2011-05-13 16:44 ` Jean Delvare
2011-05-13 17:28 ` Harry G McGavran Jr
2011-05-13 17:47 ` Jeff Rickman
2011-05-13 19:36 ` Jean Delvare
2011-05-13 19:47 ` Harry G McGavran Jr
2011-05-13 21:10 ` Jean Delvare
2011-05-13 22:55 ` Harry G McGavran Jr
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.