Problems with f71882fg and NVIDIA graphics card thermal sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2009-01-21 at 08:58 +0100, Jean Delvare wrote:
> Hi Malcolm,
> 
> On Tue, 20 Jan 2009 11:50:45 -0800, Malcolm Lalkaka wrote:
> > I ran sensors-detect, and it told me to load the modules coretemp and
> > f71882fg. I added those to /etc/modules, and restarted my computer.
> > Although coretemp loaded fine, f71882fg did not. Furthermore, I don't
> > think it detected the thermal monitor on my NVIDA GeForce 9800 GTX+,
> > which I know exists because nvidia-settings displays the temperature of
> > the device.
> > 
> > When I run "sudo modprobe f71882fg", I get the following output:
> >         FATAL: Error inserting f71882fg
> >         (/lib/modules/2.6.27-9-generic/kernel/drivers/hwmon/f71882fg.ko): Device or resource busy
> > The following allows is outputted to dmesg:
> >         [66032.953156] f71882fg: Not a Fintek device
> 
> This one is a false positive, already addressed by a patch I sent 2
> days ago.

Thank you :).

> >         [66032.953206] f71882fg: Found F71882FG chip at 0x290, revision 32
> >         [66032.953684] f71882fg.656: failed to claim resource 0
> >         [66032.953687] f71882fg: Device addition failed
> > 
> > The output of sensors-detect is as follows:
> >         # sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)
> >         
> >         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.
> >         
> >         We can start with probing for (PCI) I2C or SMBus adapters.
> >         Do you want to probe now? (YES/no): 
> >         Probing for PCI bus adapters...
> >         Found unknown SMBus adapter 10de:0aa2 at 0000:00:03.2.
> >         Sorry, no supported PCI bus adapters found.
> 
> You appear to have a recent nVidia SMBus controller which we do not
> support yet (MCP79). If it is compatible with previous nVidia south
> bridges then the i2c-nforce2 driver should work. Can you please provide
> the output of lspci -d 10de:0aa2 -vxxx?

The output from "sudo lspci -d 10de:0aa2 -vxxx":
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
	Subsystem: eVga.com. Corp. Device 1006
	Flags: 66MHz, fast devsel, IRQ 5
	I/O ports at ff00 [size=64]
	I/O ports at 1c00 [size=64]
	I/O ports at 1c80 [size=64]
	Capabilities: [44] Power Management version 2
00: de 10 a2 0a 01 00 b0 00 b1 00 05 0c 00 00 80 00
10: 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 1c 00 00 81 1c 00 00 00 00 00 00 42 38 06 10
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 01 00 00
40: 42 38 06 10 01 00 02 c0 00 00 00 00 6a 96 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 00 00
70: 00 00 00 00 00 00 f0 ef 00 00 00 00 01 00 00 00
80: 00 10 fe fe 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: b1 02 00 00 07 00 00 84 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: d4 30 80 01 01 00 00 00 20 82 00 0a 0d 0d 19 19
d0: c0 b0 c0 00 10 00 01 00 05 00 00 00 00 00 00 00
e0: 88 10 01 10 60 40 00 4f 80 60 00 00 23 44 44 00
f0: 7a ff 3d 67 b7 af 9b f8 90 00 80 80 00 00 00 00

> >         If you have undetectable or unsupported I2C/SMBus adapters, you
> >         can have
> >         them scanned by manually loading the modules before running this
> >         script.
> >         
> >         To continue, we need module `i2c-dev' to be loaded.
> >         Do you want to load `i2c-dev' now? (YES/no): 
> >         Module loaded successfully.
> >         
> >         We are now going to do the I2C/SMBus adapter probings. Some
> >         chips may
> >         be double detected; we choose the one with the highest
> >         confidence
> >         value in that case.
> >         If you found that the adapter hung after probing a certain
> >         address,
> >         you can specify that address to remain unprobed.
> >         
> >         Next adapter: NVIDIA i2c adapter  (i2c-0)
> >         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)
> >         
> >         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): 
> 
> No thermal sensor on your graphics adapter's I2C buses. Maybe it has
> another type of thermal sensor, but we do not support that.
> 
> >         
> >         Some chips are also 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 LM78-J' 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
> >         Probing for `IPMI BMC KCS' at 0xca0...                      No
> >         Probing for `IPMI BMC SMIC' at 0xca8...                     No
> >         
> >         Some Super I/O chips may also contain 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'...                                     No
> >         Trying family `VIA/Winbond/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/Fintek'...                       Yes
> >         Found `Fintek F71882FG/F71883FG Super IO Sensors'
> >         Success!
> >             (address 0x295, driver `f71882fg')
> >         
> >         Some south bridges, CPUs or memory controllers may also contain
> >         embedded sensors. Do you want to scan for them? (YES/no): 
> >         Silicon Integrated Systems SIS5595...                       No
> >         VIA VT82C686 Integrated Sensors...                          No
> >         VIA VT8231 Integrated Sensors...                            No
> >         AMD K8 thermal sensors...                                   No
> >         AMD K10 thermal sensors...                                  No
> >         Intel Core family thermal sensor...
> >         Success!
> >             (driver `coretemp')
> >         Intel AMB FB-DIMM thermal sensor...                         No
> >         
> >         Now follows a summary of the probes I have just done.
> >         Just press ENTER to continue: 
> >         
> >         Driver `f71882fg' (should be inserted):
> >           Detects correctly:
> >           * ISA bus, address 0x295
> >             Chip `Fintek F71882FG/F71883FG Super IO
> >         Sensors' (confidence: 9)
> >         
> >         Driver `coretemp' (should be inserted):
> >           Detects correctly:
> >           * Chip `Intel Core family thermal sensor' (confidence: 9)
> >         
> >         I will now generate the commands needed to load the required
> >         modules.
> >         Just press ENTER to continue: 
> >         
> >         To load everything that is needed, add this to /etc/modules:
> >         
> >         #----cut here----
> >         # Chip drivers
> >         f71882fg
> >         coretemp
> >         #----cut here----
> >         
> >         Do you want to add these lines automatically? (yes/NO)
> > 
> > The output of "sudo isadump 0x295 0x296":
> >         WARNING! Running this program can cause system crashes, data
> >         loss and worse!
> >         I will probe address register 0x295 and data register 0x296.
> >         Continue? [Y/n] 
> >              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> >         00: ff 03 00 00 ff ff ff ff ff ff 00 51 55 4c 00 00 
> >         10: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff 
> >         20: d3 79 5e 79 8d 70 5b d3 c6 ff ff ff ff ff ff ff 
> >         30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> >         40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> >         50: ff ff ff ff ff ff ff ff ff ff 03 04 10 19 34 ff 
> >         60: 00 88 88 00 ff ff 02 00 00 00 ff 06 40 24 ff 00 
> >         70: ff ff 23 ff 1f ff 7f ff ff ff ff ff ff ff ff ff 
> >         80: ff ff 64 55 64 55 55 46 ff ff ff ff ff ff a8 ff 
> >         90: 00 0d 0d 00 00 ff 56 ff 44 22 ff 55 55 55 ff 1a 
> >         a0: 03 55 00 c8 01 23 3c 32 28 1e ff d9 b2 99 80 0d 
> >         b0: 04 8f 00 99 02 45 3c 32 28 1e ff d9 b2 99 80 0e 
> >         c0: 0f ff 00 ff 03 ff 3c 32 28 1e ff d9 b2 99 80 0f 
> >         d0: 0f ff 00 ff 03 ff 3c 32 28 1e ff d9 b2 99 80 0f 
> >         e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> >         f0: 00 00 00 00 00 00 3b ff 01 6e ff 00 ff ff ff ff
> > 
> > The output of "sudo i2cdetect 0":
> >         WARNING! This program can confuse your I2C bus, cause data loss
> >         and worse!
> >         I will probe file /dev/i2c-0.
> >         I will probe address range 0x03-0x77.
> >         Continue? [Y/n] 
> >              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> >         00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         30: -- -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- -- 
> >         40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> >         70: -- -- -- -- -- -- -- --                         
> > 
> > The output of "sudo i2cdetect 1" and "sudo i2cdetect 2" had no "XX", but
> > all entries were "--", so I haven't included it here.
> > 
> > The output of "sudo i2cdump 0 0x50":
> > -----
> > 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-0, address 0x50, mode byte
> > Continue? [Y/n] 
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> > 00: 00 ff ff ff ff ff ff 00 4c 2d e5 03 32 32 57 54    ........L-??22WT
> > 10: 29 12 01 03 80 2f 1e 78 2a ee 91 a3 54 4c 99 26    )????/?x*???TL?&
> > 20: 0f 50 54 bf ef 80 b3 00 81 80 81 40 71 4f 01 01    ?PT????.???@qO??
> > 30: 01 01 01 01 01 01 7c 2e 90 a0 60 1a 1e 40 30 20    ??????|.??`??@0 
> > 40: 36 00 da 28 11 00 00 1a 00 00 00 fd 00 38 4b 1e    6.?(?..?...?.8K?
> > 50: 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53    Q?.?      ...?.S
> > 60: 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff    yncMaster?  ....
> > 70: 00 48 56 5a 51 41 30 30 31 31 38 0a 20 20 00 01    .HVZQA00118?  .?
> > 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> > -----
> > 
> > The output of "sudo i2cdump 0 0x37" was all "ff", so I haven't included
> > it here.
> > 
> > The output of "sudo i2cdump 0 0x3a":
> > -----
> > 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-0, address 0x3a, mode byte
> > Continue? [Y/n] 
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> > 00: da 81 3a 3d 8e 00 00 00 00 00 e7 00 00 00 00 00    ??:=?.....?.....
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 2f 00 00 00    ............/...
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 40: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ?...............
> > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> > -----
> 
> What have you the idea to run i2cdump on all addresses? In general this
> is a _very bad_ idea, as i2cdump can damage your system (as the warning
> says.) If there is any documentation lying around that told you to do
> this, it should be fixed quickly.

Assuming I understood it correctly, I was doing what it said on the "How
to Ask for Help" section of the lm-sensors website:
http://www.lm-sensors.org/wiki/FAQ/Chapter4.
        Here's what you should send us:
        ...
        The output of (as root) prog/dump/i2cdump X 0xXX where XX = the
        address of each chip you see in the output of i2cdetect. (run
        once for each chip) (please send this only if it's not all ff)

I read the warning, but I guess I thought it would be alright. (It
sounds foolish now, I know.) I hope I didn't do any damage; how can I
check? Out of curiosity, how can dumping this information cause damage?
Isn't dumping usually a read-only operation?

> > My motherboard is an EVGA nForce 730i. 
> > I'm using sensors version 3.0.2 with libsensors 3.0.2. 
> > My Linux kernel version is 2.6.27, compiled for x86_64.
> > 
> > Does anyone know how to solve these problems? I can provide more
> > information, and can test some things if needed.
> 
> Don't you think it would have been fair to mention that you already
> received some help about this issue over IRC, and that the cause of the
> problem was found?

I apologize for not writing this in the original email; I didn't know
whether you would be on the mailing list, and I had no way to identify
you based on just your IRC name. I figured though that if you were on
the mailing list, you or I would notice each other after I describe the
problem. Sorry again if this has caused anyone confusion or redundant
effort.

> For the others: the problem is a PNP BIOS bug: region 0x295-0x314 is
> reserved by PNP, which is clearly incorrect. This prevents the f71882fg
> driver from declaring its I/O region (0x290-0x297).
> 
> Malcolm, did you try the pnp boot parameters I suggested on IRC?

Yes I tried the boot parameters you suggested; neither "pnpbios=off" nor
"pnp_reserve_io=0x290,8" worked, unfortunately. This led me to believe
the problem may be something different. (I don't know much about this
stuff, though.)






[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux