* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
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
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2009-01-21 7:58 UTC (permalink / raw)
To: lm-sensors
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.
> [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?
> 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.
>
> 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?
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?
--
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] 7+ messages in thread* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
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
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2009-01-21 8:15 UTC (permalink / raw)
To: lm-sensors
On Wed, 21 Jan 2009 08:58:33 +0100, Jean Delvare wrote:
> Malcolm, did you try the pnp boot parameters I suggested on IRC?
If these didn't work (I tried both pnpbios=off and pnp_reserve_io and
neither worked for me) you should try pnpacpi=off, that worked for me.
But of course the real solution is to get your BIOS fixed.
--
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] 7+ messages in thread* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
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
2009-01-21 9:18 ` Jean Delvare
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Malcolm Lalkaka @ 2009-01-21 8:40 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
2009-01-20 19:50 [lm-sensors] Problems with f71882fg and NVIDIA graphics card Malcolm Lalkaka
` (2 preceding siblings ...)
2009-01-21 8:40 ` Malcolm Lalkaka
@ 2009-01-21 9:18 ` Jean Delvare
2009-01-22 0:44 ` Malcolm Lalkaka
2009-01-22 7:47 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2009-01-21 9:18 UTC (permalink / raw)
To: lm-sensors
Hi Malcolm,
On Wed, 21 Jan 2009 00:40:28 -0800, Malcolm Lalkaka wrote:
> On Wed, 2009-01-21 at 08:58 +0100, Jean Delvare wrote:
> > 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
Looks compatible. You may try loading the i2c-nforce2 driver and then
run the following command:
echo "10de 0aa2" > /sys/bus/pci/drivers/nForce2_smbus/new_id
If thinks go well, you should see the nForce2 SMBus (2 channels) in the
output of "i2cdetect -l" (after loading kernel module i2c-dev). Check
with "i2cdetect <n>" (where n is the bus number) that they behave OK.
> > 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)
OK, thanks. Very old FAQ entry... I've fixed that. Sometimes I wonder
if we shouldn't plain delete the FAQ and start a new one from scratch,
as is is sooo out-of-date :(
> 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?
The problem is that I2C doesn't have clear semantics about what is a
read and what is a write. So i2cdump might actually write to I2C chips.
> > 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.)
See my other post: try pnpacpi=off.
--
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] 7+ messages in thread* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
2009-01-20 19:50 [lm-sensors] Problems with f71882fg and NVIDIA graphics card Malcolm Lalkaka
` (3 preceding siblings ...)
2009-01-21 9:18 ` Jean Delvare
@ 2009-01-22 0:44 ` Malcolm Lalkaka
2009-01-22 7:47 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Malcolm Lalkaka @ 2009-01-22 0:44 UTC (permalink / raw)
To: lm-sensors
On Wed, 2009-01-21 at 10:18 +0100, Jean Delvare wrote:
> Hi Malcolm,
>
> On Wed, 21 Jan 2009 00:40:28 -0800, Malcolm Lalkaka wrote:
> > On Wed, 2009-01-21 at 08:58 +0100, Jean Delvare wrote:
> > > 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
>
> Looks compatible. You may try loading the i2c-nforce2 driver and then
> run the following command:
>
> echo "10de 0aa2" > /sys/bus/pci/drivers/nForce2_smbus/new_id
>
> If thinks go well, you should see the nForce2 SMBus (2 channels) in the
> output of "i2cdetect -l" (after loading kernel module i2c-dev).
Yes, this command seemed to work.
The output of "i2cdetect -l":
i2c-0 unknown NVIDIA i2c adapter N/A
i2c-1 unknown NVIDIA i2c adapter N/A
i2c-2 unknown NVIDIA i2c adapter N/A
i2c-3 unknown SMBus nForce2 adapter at 1c00 N/A
i2c-4 unknown SMBus nForce2 adapter at 1c80 N/A
> Check
> with "i2cdetect <n>" (where n is the bus number) that they behave OK.
The output of "sudo i2cdetect 3":
-----
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
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: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
-----
The output of "sudo i2cdetect 4":
-----
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-4.
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: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- 4e --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
-----
Does that mean they're working? I don't see any new information when
running "sensors", though.
EVGA replied to my support request about the PnP BIOS bug that you
found. They said that if "there is a specific reason why you suspect a
PnP bug in the bios, please let us know and we can pass that information
to our product management team to look into." How can I describe this
problem to them? Since you've already found the problem, I may as well
get them to fix it.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [lm-sensors] Problems with f71882fg and NVIDIA graphics card
2009-01-20 19:50 [lm-sensors] Problems with f71882fg and NVIDIA graphics card Malcolm Lalkaka
` (4 preceding siblings ...)
2009-01-22 0:44 ` Malcolm Lalkaka
@ 2009-01-22 7:47 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2009-01-22 7:47 UTC (permalink / raw)
To: lm-sensors
Hi Malcolm,
On Wed, 21 Jan 2009 16:44:30 -0800, Malcolm Lalkaka wrote:
> On Wed, 2009-01-21 at 10:18 +0100, Jean Delvare wrote:
> > Looks compatible. You may try loading the i2c-nforce2 driver and then
> > run the following command:
> >
> > echo "10de 0aa2" > /sys/bus/pci/drivers/nForce2_smbus/new_id
> >
> > If thinks go well, you should see the nForce2 SMBus (2 channels) in the
> > output of "i2cdetect -l" (after loading kernel module i2c-dev).
>
> Yes, this command seemed to work.
> The output of "i2cdetect -l":
> i2c-0 unknown NVIDIA i2c adapter N/A
> i2c-1 unknown NVIDIA i2c adapter N/A
> i2c-2 unknown NVIDIA i2c adapter N/A
> i2c-3 unknown SMBus nForce2 adapter at 1c00 N/A
> i2c-4 unknown SMBus nForce2 adapter at 1c80 N/A
>
> > Check
> > with "i2cdetect <n>" (where n is the bus number) that they behave OK.
>
> The output of "sudo i2cdetect 3":
> -----
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-3.
> 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: -- -- -- -- -- 08 -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> -----
>
> The output of "sudo i2cdetect 4":
> -----
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-4.
> 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: -- -- -- -- -- 08 -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- 4e --
> 50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> -----
>
> Does that mean they're working?
This looks alright. I'll prepare a patch adding support for the MCP79
to the i2c-nforce2 driver (really just adding the new PCI ID). You
could try dumping the SPD EEPROM at 3-0x50 to make sure it works as
well:
i2cdump 3 0x50 b
i2cdump 3 0x50 c
i2cdump 3 0x50 W
All 3 commands should work and should return the same data.
> I don't see any new information when running "sensors", though.
Well, if the Super I/O chip (F71882FG) is used for hardware monitoring,
then there is no reason why there would be an additional chip on the
SMBus (even though some vendors do it... but not EVGA in my
experience.) Addresses 0x48, 0x49 and 0x4e are often used for thermal
sensors though.
I am also a little curious about the chips at 0x50-0x57 on the second
SMBus channel. Maybe a custom EEPROM...
> EVGA replied to my support request about the PnP BIOS bug that you
> found. They said that if "there is a specific reason why you suspect a
> PnP bug in the bios, please let us know and we can pass that information
> to our product management team to look into." How can I describe this
> problem to them? Since you've already found the problem, I may as well
> get them to fix it.
Description of the problem:
In the PnP ACPI tables, the hardware monitoring I/O ports of the
F71882FG chips are declared at 0x295-0x314, that is, 32 I/O ports
starting at 0x295, while this device uses only 2 I/O ports, so this
should be 0x295-0x296. This problem prevents the OS from using the
device. The BIOS should be fixed to declare only ports 0x295-0x296 for
the hardware monitoring function. My guess is that it's a simple matter
of changing the resource length from 0x20 to 0x02.
You can quote the part of the system log (output of the dmesg command
after boot) which starts with "pnp: PnP ACPI: found 13 devices". It
should include the faulty I/O port range.
--
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] 7+ messages in thread