[lm-sensors] Where are all the sensors?

[lm-sensors] Where are all the sensors?

[DB]

Hi all,

I have Fedora 14 running on my MSI 880GM-E41 board.  I've run 
sensors-detect & passed the found info to (I guess) lmsensors.

Whether I run KSensors or gkrellm I only get one temperature reading 
(about 25-26 degrees) which I assume is the ambient temp in my box; no 
fan speeds.  When I look in the bios, I see the CPU temperature & 2 fan 
speeds....  Is there any way to catch these readings & hand them off to 
gkrellm or ksensors?

Thanks for any help!

Dave

Linux 2.6.35.13-92.fc14.x86_64

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Phillip Susi]

On 6/29/2011 12:28 PM, DB wrote:
> I have Fedora 14 running on my MSI 880GM-E41 board. I've run
> sensors-detect & passed the found info to (I guess) lmsensors.

Don't guess; know.  Pay attention to what sensors-detect says.  It tells 
you what sensors it finds, and what modules you need to load in 
/etc/modules.  If it didn't find any, then you don't have any supported 
sensors.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jeff Rickman]

On 6/29/2011 12:01 PM, Phillip Susi wrote:
> On 6/29/2011 12:28 PM, DB wrote:
>> I have Fedora 14 running on my MSI 880GM-E41 board. I've run
>> sensors-detect & passed the found info to (I guess) lmsensors.
>
> Don't guess; know. Pay attention to what sensors-detect says. It tells
> you what sensors it finds, and what modules you need to load in
> /etc/modules. If it didn't find any, then you don't have any supported
> sensors.
>

More information is needed.....

Please show the output from "sensors-detect" command.

Please show the output from the "sensors" command.

Please show the contents of /etc/sysconfig/lm_sensors

Please look in /var/log/messages or run 'dmesg' after a fresh boot. The 
line(s) of interest have the word ACPI in them. You might find something 
like this in 'dmesg' output (pulled from my FC14-i386 box):

[   24.025113] f71805f: Found F71805F/FG chip at 0x290, revision 19
[   24.038969] ACPI: resource f71805f [io  0x0290-0x0297] conflicts with 
ACPI region IP__ [??? 0x00000295-0x00000296 flags 0x5f]
[   24.052702] ACPI: This conflict may cause random problems and system 
instability
[   24.066279] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

If there is an issue loading the LM_Sensors service, it is possible that 
the problem will be logged here. A typical message I find is some or all 
of the IO ports to the sensor chip are already "reserved" by the BIOS 
(see my example above).

The picture of this board on www.newegg.com 
(http://www.newegg.com/Product/Product.aspx?Item=N82E16813130295) 
suggests a Fintek chip is being used but I cannot determine the model 
from that picture or from the picture on MSI's web site. This chip is 
located at the back of the board, top-side, near the back panel audio 
jacks. If you can read the complete model number on that chip; that 
information is extremely helpful.

The manual for this board suggests the BIOS screens only report 2 
temperature sensors, 2 fans (1 is 4-pin for CPU and other is 3-pin), and 
4 voltages (Vcore, 3.3V, 5V, 12V). The fan header for the CPU appears to 
be 3-pin or 4-pin selectable in the BIOS with and enable/disable toggle 
for a CPU Smart Fan feature.

BTW I also use Fedora Core 14.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[DB]

Hi Jeff,

Thanks for your suggestions!  Here are the results - as far as I can 
see...... (To save on the amount to transmit, I've clipped the text 
parts of Sensors-detect)


$ sensors -v
sensors version 3.3.0 with libsensors version 3.3.0


# sensors-detect
Stopping lm_sensors:                                       [  OK  ]
# sensors-detect revision 5946 (2011-03-23 11:54:44 +0100)
# System: MSI MS-7623
# Board: MSI 880GM-E41 (MS-7623)

Do you want to scan for them? This is totally safe. (YES/no): Y
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...                           Success!
     (driver `k10temp')
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): Y
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found `Fintek F71889FG/F81801U Super IO Sensors'            Success!
     (address 0x600, driver `f71882fg')

his is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): Y
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Do you want to scan the ISA I/O ports? (yes/NO): y
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

Do you want to probe the I2C/SMBus adapters now? (YES/no): Y
Using driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc 
SB600/SB700/SB800 SMBus
Module i2c-dev loaded successfully.

Next adapter: Radeon i2c bit bus VGA (i2c-0)
Do you want to scan it? (YES/no/selectively): Y
Client found at address 0x4a
Probing for `National Semiconductor LM75'...                No
Probing for `National Semiconductor LM75A'...               No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `National Semiconductor LM77'...                No
Probing for `Analog Devices ADT7410'...                     No
Probing for `Analog Devices ADT7411'...                     No
Probing for `Dallas Semiconductor DS1621/DS1631'...         No
Probing for `National Semiconductor LM73'...                No
Probing for `National Semiconductor LM92'...                No
Probing for `National Semiconductor LM76'...                No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Client found at address 0x4b
Probing for `National Semiconductor LM75'...                No
Probing for `National Semiconductor LM75A'...               No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `National Semiconductor LM77'...                No
Probing for `Analog Devices ADT7410'...                     No
Probing for `Analog Devices ADT7411'...                     No
Probing for `Dallas Semiconductor DS1621/DS1631'...         No
Probing for `Maxim MAX6650/MAX6651'...                      No
Probing for `National Semiconductor LM92'...                No
Probing for `National Semiconductor LM76'...                No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Probing for `Analog Devices ADT7481'...                     No
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)

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `k10temp' (autoloaded):
   * Chip `AMD Family 10h thermal sensors' (confidence: 9)

Driver `f71882fg':
   * ISA bus, address 0x600
     Chip `Fintek F71889FG/F81801U Super IO Sensors' (confidence: 9)



# sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +25.0°C  (high = +70.0°C)


# Generated by sensors-detect on Tue Jun 28 15:35:14 2011
# This file is sourced by /etc/init.d/lm_sensors and defines the modules to
# be loaded/unloaded.
#
# The format of this file is a shell script that simply defines variables:
# HWMON_MODULES for hardware monitoring driver modules, and optionally
# BUS_MODULES for any required bus driver module (for example for I2C or 
SPI).

HWMON_MODULES="f71882fg"

# For compatibility reasons, modules are also listed individually as 
variables
#    MODULE_0, MODULE_1, MODULE_2, etc.
# You should use BUS_MODULES and HWMON_MODULES instead if possible.

MODULE_0÷1882fg

This is what I found in dmesg:

[   21.121981] f71882fg: Found f71889fg chip at 0x600, revision 21
[   21.122030] ACPI: resource f71882fg [io  0x0600-0x0607] conflicts 
with ACPI region HMOR [mem 0x00000605-0x00000606 pref disabled]
[   21.122037] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver


Hope you can make some sense of it!!!

Dave




_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Luca Tettamanti]

On Tue, Jul 5, 2011 at 9:45 PM, DB <Freddog_de@yahoo.co.uk> wrote:
> [   21.121981] f71882fg: Found f71889fg chip at 0x600, revision 21
> [   21.122030] ACPI: resource f71882fg [io  0x0600-0x0607] conflicts with
> ACPI region HMOR [mem 0x00000605-0x00000606 pref disabled]
> [   21.122037] ACPI: If an ACPI driver is available for this device, you
> should use it instead of the native driver

This means that the BIOS is claiming the hwmon chip for itself;
starting from 2.6.31 Linux started enforcing this claim, see
http://lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31.

Asus exposes the hardware monitoring data trough an ACPI interface. If
you send me a copy of /sys/firmware/acpi/tables/DSDT I'll see if
there's something usable.

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[DB]

On 07/05/2011 10:37 PM, Luca Tettamanti wrote:
> On Tue, Jul 5, 2011 at 9:45 PM, DB<Freddog_de@yahoo.co.uk>  wrote:
>> [   21.121981] f71882fg: Found f71889fg chip at 0x600, revision 21
>> [   21.122030] ACPI: resource f71882fg [io  0x0600-0x0607] conflicts with
>> ACPI region HMOR [mem 0x00000605-0x00000606 pref disabled]
>> [   21.122037] ACPI: If an ACPI driver is available for this device, you
>> should use it instead of the native driver
>
> This means that the BIOS is claiming the hwmon chip for itself;
> starting from 2.6.31 Linux started enforcing this claim, see
> http://lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31.
>
> Asus exposes the hardware monitoring data trough an ACPI interface. If
> you send me a copy of /sys/firmware/acpi/tables/DSDT I'll see if
> there's something usable.
>
> Luca
>

Hi Luca,

I tried cat /sys/firmware/acpi/tables/DSDT & got a lot of characters all 
over the page, nothing really readable.... ls -l gives
   ls -l /sys/firmware/acpi/tables/DSDT
-r--------. 1 root root 0 Jul  5 22:42 /sys/firmware/acpi/tables/DSDT

Here's the last page of the file:

       �pTAAXAAXB��A�B�TTT0
pAAXBTAAXpCMRQBUF0p
BUF1pBUF2pBUF3pMBUFAAXBp
�PSMI["
        �pAAXBMBUFpBUF2cp�PPI1pc�PPI1pTAAXAAXB�PPI1�K�
                                                      �TTT0
�
�L�J�TTT0
pAAXBTAAXpCMRQBUF0p
�BUF1pBUF2pBUF3pMBUFAAXBp
�PSMI["
        �pAAXBMBUFzBUF2
cpCMERBUF0p
�BUF1pBUF2pBUF3pMBUFAAXBp
�PSMI["
        �pAAXBMBUFpBUF2frCMERdpdBUF0p
�BUF1pBUF2pBUF3pMBUFAAXBp
�PSMI["
        �pAAXBMBUFpBUF2gwg
                          brbfbp�PPI2pc�PPI2��b
                                               ��p
                                                  �����PPI2
�"��b
      ��p
         �����PPI2
�
  pb�PPI2
pTAAXAAXB�PPI2��
�TTT0
�����h
�T`7�uF�GV���TTT1p�jTTT1�
                          �TTT1��H�C�TTT1pAAXBTAAXpCMORBUF0p
�BUF1p���kBUF2pBUF3pMBUFAAXBp
�PSMI["
        �
         pTAAXAAXB��_S0_�SS1_S1_�SS3_S3_
�SS4_S4_
_S5_
FPTS_�>h\/_SB_PCI0SBRGSIOShNB2ShSPTSh\/_SB_PCI0SBRGEPTShNPTShAPTShHWAK_\/_SB_PCI0SBRGSIOWhNB2WhSWAKh\/_SB_PCI0SBRGEWAKhNWAKhA


Is there some other way I ought to have looked at the file???

Thanks for your help!!!

Dave

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jeff Rickman]

On 7/5/2011 3:54 PM, DB wrote:
> On 07/05/2011 10:37 PM, Luca Tettamanti wrote:
>> On Tue, Jul 5, 2011 at 9:45 PM, DB<Freddog_de@yahoo.co.uk> wrote:
>>> [ 21.121981] f71882fg: Found f71889fg chip at 0x600, revision 21
>>> [ 21.122030] ACPI: resource f71882fg [io 0x0600-0x0607] conflicts with
>>> ACPI region HMOR [mem 0x00000605-0x00000606 pref disabled]
>>> [ 21.122037] ACPI: If an ACPI driver is available for this device, you
>>> should use it instead of the native driver
>>
>> This means that the BIOS is claiming the hwmon chip for itself;
>> starting from 2.6.31 Linux started enforcing this claim, see
>> http://lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31.
>>
>>
>> Asus exposes the hardware monitoring data trough an ACPI interface. If
>> you send me a copy of /sys/firmware/acpi/tables/DSDT I'll see if
>> there's something usable.
>>
>> Luca
>>
>
> Hi Luca,
>
> I tried cat /sys/firmware/acpi/tables/DSDT & got a lot of characters all
> over the page, nothing really readable.... ls -l gives
> ls -l /sys/firmware/acpi/tables/DSDT
> -r--------. 1 root root 0 Jul 5 22:42 /sys/firmware/acpi/tables/DSDT
>
> Here's the last page of the file:
>

[..snip..]

>
> Is there some other way I ought to have looked at the file???
>
> Thanks for your help!!!
>
> Dave
>

DSDT is "binary" so "cat" will not work. When I need a copy of DSDT I do 
the following:

cp /proc/acpi/dsdt /home/jeff

The "ls -al /home/jeff" shows me a file called DSDT in that directory.

Then I can attach that DSDT file to an email or whatever....

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jeff Rickman]

Hi,

On 7/5/2011 2:45 PM, DB wrote:
> Hi Jeff,
>
> Thanks for your suggestions! Here are the results - as far as I can
> see...... (To save on the amount to transmit, I've clipped the text
> parts of Sensors-detect)
>
>
> $ sensors -v
> sensors version 3.3.0 with libsensors version 3.3.0
>
>
> # sensors-detect
> Stopping lm_sensors: [ OK ]
> # sensors-detect revision 5946 (2011-03-23 11:54:44 +0100)
> # System: MSI MS-7623
> # Board: MSI 880GM-E41 (MS-7623)
>
> Do you want to scan for them? This is totally safe. (YES/no): Y
> 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... Success!
> (driver `k10temp')
> 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): Y
> Probing for Super-I/O at 0x2e/0x2f
> Trying family `National Semiconductor'... No
> Trying family `SMSC'... No
> Trying family `VIA/Winbond/Nuvoton/Fintek'... No
> Trying family `ITE'... No
> Probing for Super-I/O at 0x4e/0x4f
> Trying family `National Semiconductor'... No
> Trying family `SMSC'... No
> Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
> Found `Fintek F71889FG/F81801U Super IO Sensors' Success!
> (address 0x600, driver `f71882fg')
>
> his is normally safe. Do you want to scan for IPMI
> interfaces? (YES/no): Y
> Probing for `IPMI BMC KCS' at 0xca0... No
> Probing for `IPMI BMC SMIC' at 0xca8... No
>
> Do you want to scan the ISA I/O ports? (yes/NO): y
> 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
>
> Do you want to probe the I2C/SMBus adapters now? (YES/no): Y
> Using driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc
> SB600/SB700/SB800 SMBus
> Module i2c-dev loaded successfully.
>
> Next adapter: Radeon i2c bit bus VGA (i2c-0)
> Do you want to scan it? (YES/no/selectively): Y
> Client found at address 0x4a
> Probing for `National Semiconductor LM75'... No
> Probing for `National Semiconductor LM75A'... No
> Probing for `Dallas Semiconductor DS75'... No
> Probing for `National Semiconductor LM77'... No
> Probing for `Analog Devices ADT7410'... No
> Probing for `Analog Devices ADT7411'... No
> Probing for `Dallas Semiconductor DS1621/DS1631'... No
> Probing for `National Semiconductor LM73'... No
> Probing for `National Semiconductor LM92'... No
> Probing for `National Semiconductor LM76'... No
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> Client found at address 0x4b
> Probing for `National Semiconductor LM75'... No
> Probing for `National Semiconductor LM75A'... No
> Probing for `Dallas Semiconductor DS75'... No
> Probing for `National Semiconductor LM77'... No
> Probing for `Analog Devices ADT7410'... No
> Probing for `Analog Devices ADT7411'... No
> Probing for `Dallas Semiconductor DS1621/DS1631'... No
> Probing for `Maxim MAX6650/MAX6651'... No
> Probing for `National Semiconductor LM92'... No
> Probing for `National Semiconductor LM76'... No
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> Probing for `Analog Devices ADT7481'... No
> 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)
>
> Now follows a summary of the probes I have just done.
> Just press ENTER to continue:
>
> Driver `k10temp' (autoloaded):
> * Chip `AMD Family 10h thermal sensors' (confidence: 9)
>
> Driver `f71882fg':
> * ISA bus, address 0x600
> Chip `Fintek F71889FG/F81801U Super IO Sensors' (confidence: 9)
>
>
>
> # sensors
> k10temp-pci-00c3
> Adapter: PCI adapter
> temp1: +25.0°C (high = +70.0°C)
>
>
> # Generated by sensors-detect on Tue Jun 28 15:35:14 2011
> # This file is sourced by /etc/init.d/lm_sensors and defines the modules to
> # be loaded/unloaded.
> #
> # The format of this file is a shell script that simply defines variables:
> # HWMON_MODULES for hardware monitoring driver modules, and optionally
> # BUS_MODULES for any required bus driver module (for example for I2C or
> SPI).
>
> HWMON_MODULES="f71882fg"
>
> # For compatibility reasons, modules are also listed individually as
> variables
> # MODULE_0, MODULE_1, MODULE_2, etc.
> # You should use BUS_MODULES and HWMON_MODULES instead if possible.
>
> MODULE_0÷1882fg
>
> This is what I found in dmesg:
>
> [ 21.121981] f71882fg: Found f71889fg chip at 0x600, revision 21
> [ 21.122030] ACPI: resource f71882fg [io 0x0600-0x0607] conflicts with
> ACPI region HMOR [mem 0x00000605-0x00000606 pref disabled]
> [ 21.122037] ACPI: If an ACPI driver is available for this device, you
> should use it instead of the native driver
>
>
> Hope you can make some sense of it!!!
>
> Dave
>

ACPI is claiming the ports that LM_Sensors wants to use to access the 
Fintek F71882FG chip. It happens. At least the k10temp driver loaded so 
you can monitor CPU temperatures so that says LM_Sensors is installed 
correctly.

I saw Luca's email asking for a DSDT file and saw your reply. Sometimes 
the DSDT file has helpful info and sometimes not; it's up to the BIOS 
vendor and/or board manufacturer. I am still trying to learn how to 
understand DSDT files.

Luca, would that modified F71882FG driver (from ~June last year) be 
useful/helpful here? In my case it was a F71862FG chip where ACPI 
claimed the ports but DSDT suggested something to you. I guess it really 
depends on the DSDT code. BTW, I still use that modified driver on that 
Jetway NC92-330 board and it still works fine even with Fedora Core 15.

Using the "acpi_enforce_resources=lax" parameter in "grub.conf" can be 
useful to expose the Fintek chip for LM_Sensors, but it is also risky. 
Some boards "behave badly" (lock up, act strange, etc.) when the sensor 
chip (Fintek in this case) is being poked (to setup for reading values) 
and then accessed by multiple applications; both the sensor chip and the 
access bus were not designed for access by multiple applications.

Hanging out on this list has been and remains educational for me...


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Luca Tettamanti]

On Tue, Jul 5, 2011 at 10:54 PM, DB <Freddog_de@yahoo.co.uk> wrote:
> I tried cat /sys/firmware/acpi/tables/DSDT & got a lot of characters all
> over the page, nothing really readable....

Yes, it's a binary file ;)
Create a copy, e.g:
cp /sys/firmware/acpi/tables/DSDT /tmp/DSDT
and attach the file.

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Luca Tettamanti]

On Wed, Jul 6, 2011 at 2:34 AM, Jeff Rickman <jrickman@myamigos.us> wrote:
> Luca, would that modified F71882FG driver (from ~June last year) be
> useful/helpful here? In my case it was a F71862FG chip where ACPI claimed
> the ports but DSDT suggested something to you. I guess it really depends on
> the DSDT code. BTW, I still use that modified driver on that Jetway NC92-330
> board and it still works fine even with Fedora Core 15.

It was an ugly hack :) I modified the driver to access the hwmon chip
using the methods exposed by the firmware instead of letting the
driver touch the chip directly. Unfortunately the hack is very board
specific...

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jean Delvare]

Hi Luca,

On Wed, 6 Jul 2011 10:48:43 +0200, Luca Tettamanti wrote:
> On Wed, Jul 6, 2011 at 2:34 AM, Jeff Rickman <jrickman@myamigos.us> wrote:
> > Luca, would that modified F71882FG driver (from ~June last year) be
> > useful/helpful here? In my case it was a F71862FG chip where ACPI claimed
> > the ports but DSDT suggested something to you. I guess it really depends on
> > the DSDT code. BTW, I still use that modified driver on that Jetway NC92-330
> > board and it still works fine even with Fedora Core 15.
> 
> It was an ugly hack :) I modified the driver to access the hwmon chip
> using the methods exposed by the firmware instead of letting the
> driver touch the chip directly. Unfortunately the hack is very board
> specific...

I still have to test this approach on a Jetway board of mine with a
Fintek F71805F chip.

Why do you say this is ugly? Of course it is vendor specific (or even
board specific) but so is the asus_atk0110 driver. Wouldn't it be a
proper way to deal with the ACPI resource conflict at least on the
Jetway boards, and maybe others? If it works then I can't really see a
reason to not do it, can you? It seems preferable to
acpi_enforce_resources=lax people are using at the moment, at least.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jeff Rickman]

On 7/6/2011 4:04 AM, Jean Delvare wrote:
> Hi Luca,
>
> On Wed, 6 Jul 2011 10:48:43 +0200, Luca Tettamanti wrote:
>> On Wed, Jul 6, 2011 at 2:34 AM, Jeff Rickman<jrickman@myamigos.us>  wrote:
>>> Luca, would that modified F71882FG driver (from ~June last year) be
>>> useful/helpful here? In my case it was a F71862FG chip where ACPI claimed
>>> the ports but DSDT suggested something to you. I guess it really depends on
>>> the DSDT code. BTW, I still use that modified driver on that Jetway NC92-330
>>> board and it still works fine even with Fedora Core 15.
>>
>> It was an ugly hack :) I modified the driver to access the hwmon chip
>> using the methods exposed by the firmware instead of letting the
>> driver touch the chip directly. Unfortunately the hack is very board
>> specific...
>
> I still have to test this approach on a Jetway board of mine with a
> Fintek F71805F chip.
>
> Why do you say this is ugly? Of course it is vendor specific (or even
> board specific) but so is the asus_atk0110 driver. Wouldn't it be a
> proper way to deal with the ACPI resource conflict at least on the
> Jetway boards, and maybe others? If it works then I can't really see a
> reason to not do it, can you? It seems preferable to
> acpi_enforce_resources=lax people are using at the moment, at least.
>

If a "modified" F71805 driver appeared I would be happy to test it. I 
think my Jetway board (J7F4 series) is different from Jean's board.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jeff Rickman]

On 7/6/2011 3:48 AM, Luca Tettamanti wrote:
> On Wed, Jul 6, 2011 at 2:34 AM, Jeff Rickman<jrickman@myamigos.us>  wrote:
>> Luca, would that modified F71882FG driver (from ~June last year) be
>> useful/helpful here? In my case it was a F71862FG chip where ACPI claimed
>> the ports but DSDT suggested something to you. I guess it really depends on
>> the DSDT code. BTW, I still use that modified driver on that Jetway NC92-330
>> board and it still works fine even with Fedora Core 15.
>
> It was an ugly hack :) I modified the driver to access the hwmon chip
> using the methods exposed by the firmware instead of letting the
> driver touch the chip directly. Unfortunately the hack is very board
> specific...
>
> Luca
>

Thank you for the comment as to how it was done.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[DB]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On 07/06/2011 10:45 AM, Luca Tettamanti wrote:
> On Tue, Jul 5, 2011 at 10:54 PM, DB<Freddog_de@yahoo.co.uk>  wrote:
>> I tried cat /sys/firmware/acpi/tables/DSDT&  got a lot of characters all
>> over the page, nothing really readable....
>
> Yes, it's a binary file ;)
> Create a copy, e.g:
> cp /sys/firmware/acpi/tables/DSDT /tmp/DSDT
> and attach the file.
>
> Luca
>


Thanks Luca,

File copy is attached......

Dave

[-- Attachment #2: DSDT --]
[-- Type: application/octet-stream, Size: 40888 bytes --]

[-- 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

Re: [lm-sensors] Where are all the sensors?

[Luca Tettamanti]

On Wed, Jul 6, 2011 at 12:30 PM, DB <Freddog_de@yahoo.co.uk> wrote:
> File copy is attached......

Uhm, the quality of that implementation is... below par. I see a lot
of copy&past, there's even this:

Name (VEND, Buffer (0x05)
{
    "ASUS"
})
the BIOS writer definitely did too much copying around ;-)

The good news is that there's accessor for the hwmon chip, the bad
news is that the chip is actually used by the bios itself, it reads
the second voltage (in1) to do some stuff related to ACC.

L

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Luca Tettamanti]

n Wed, Jul 6, 2011 at 11:04 AM, Jean Delvare <khali@linux-fr.org> wrote:
>> It was an ugly hack :) I modified the driver to access the hwmon chip
>> using the methods exposed by the firmware instead of letting the
>> driver touch the chip directly. Unfortunately the hack is very board
>> specific...
>
> I still have to test this approach on a Jetway board of mine with a
> Fintek F71805F chip.
>
> Why do you say this is ugly?

As it is it's poorly engineered. Ideally there should be an
independent IO layer (that uses the IO ports, the Jetway methods, the
MSI methods, etc) shared by all the drivers. At the very least the
fintek driver should be modified to support the differrent IO methods.

> Of course it is vendor specific (or even
> board specific) but so is the asus_atk0110 driver. Wouldn't it be a
> proper way to deal with the ACPI resource conflict at least on the
> Jetway boards, and maybe others?

Two problems: 16 bits access are still not atomic (i.e. the two ACPI
calls may be interleaved with something else touching the chip), so
it's not 100% race free.
The second one is deciding when to use the ACPI methods: I don't see a
well defined interface with a proper HID like ATK0110, what I see are
utility method used by the rest of the code. It wouldn't be possible
to auto-detect such boards, we would need to resort to a DMI
whitelist.

That said, since Dave has a different board with different ACPI
methods for the same Fintek chip I'll try to code something to
accommodate this situation soon(ish).

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Where are all the sensors?

[Jean Delvare]

Hi Luca,

Sorry for the late reply.

On Wed, 6 Jul 2011 13:19:26 +0200, Luca Tettamanti wrote:
> n Wed, Jul 6, 2011 at 11:04 AM, Jean Delvare <khali@linux-fr.org> wrote:
> >> It was an ugly hack :) I modified the driver to access the hwmon chip
> >> using the methods exposed by the firmware instead of letting the
> >> driver touch the chip directly. Unfortunately the hack is very board
> >> specific...
> >
> > I still have to test this approach on a Jetway board of mine with a
> > Fintek F71805F chip.
> >
> > Why do you say this is ugly?
> 
> As it is it's poorly engineered. Ideally there should be an
> independent IO layer (that uses the IO ports, the Jetway methods, the
> MSI methods, etc) shared by all the drivers. At the very least the
> fintek driver should be modified to support the differrent IO methods.

Yes, I agree. But nothing prevents us from starting small, improvements
can happen over time.

> > Of course it is vendor specific (or even
> > board specific) but so is the asus_atk0110 driver. Wouldn't it be a
> > proper way to deal with the ACPI resource conflict at least on the
> > Jetway boards, and maybe others?
> 
> Two problems: 16 bits access are still not atomic (i.e. the two ACPI
> calls may be interleaved with something else touching the chip), so
> it's not 100% race free.

D'oh, yes you're right, I had totally forgotten about
this :( Thankfully 16-bit access is relatively rare, and when we're
only reading values it should be mostly correct. Maybe we can read
twice to make sure.

> The second one is deciding when to use the ACPI methods: I don't see a
> well defined interface with a proper HID like ATK0110, what I see are
> utility method used by the rest of the code. It wouldn't be possible
> to auto-detect such boards, we would need to resort to a DMI
> whitelist.

My own guess was a per-vendor approach, using DMI strings. For example
it seems that Jetway implemented the same utility methods on many
boards, so whenever direct I/O is impossible on a Jetway board, we
could look for these methods and use them if available.

> That said, since Dave has a different board with different ACPI
> methods for the same Fintek chip I'll try to code something to
> accommodate this situation soon(ish).

This would be great, yes. I wanted to do it too but could never find
the time.

I would consider that the current situation is bad enough that any
improvement would be great to have. Even if it works on only some
boards, even if some features are missing (e.g. read-only access and/or
without 16-bit access) and even if the user has to pass a module
parameter to enable the alternative way to reach the chip for the time
being.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors