From: Malcolm Lalkaka <mlalkaka@gmail.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
Date: Wed, 21 Jan 2009 08:40:28 +0000 [thread overview]
Message-ID: <1232527228.18494.33.camel@malcolm> (raw)
In-Reply-To: <1232481045.6371.77.camel@malcolm>
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 [sized]
I/O ports at 1c00 [sized]
I/O ports at 1c80 [sized]
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.)
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2009-01-21 8:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 19:50 [lm-sensors] Problems with f71882fg and NVIDIA graphics card Malcolm Lalkaka
2009-01-21 7:58 ` Jean Delvare
2009-01-21 8:15 ` Jean Delvare
2009-01-21 8:40 ` Malcolm Lalkaka [this message]
2009-01-21 9:18 ` Jean Delvare
2009-01-22 0:44 ` Malcolm Lalkaka
2009-01-22 7:47 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1232527228.18494.33.camel@malcolm \
--to=mlalkaka@gmail.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.