unknown eeprom type (65) [ticket #1449]

unknown eeprom type (65) [ticket #1449]

[Fernando Rocha Durso]

root@athlon:/etc/rc.d# 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
  You have five seconds to reconsider and press CTRL-C!

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 80 08 07 0d 0a 01 40 00 04 50 65 00 82 08 00 01    ??????@.?Pe.??.?
10: 0c 04 10 01 02 20 00 00 00 00 00 50 28 50 28 40    ????? .....P(P(@
20: 60 60 40 40 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 de    ...............?
40: 43 43 41 54 33 00 00 00 01 00 00 00 00 00 00 00    CCAT3...?.......
50: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 22 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: 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    ................

My memory is Samsung DDR 400, i have one DDR with 256 Mb

I hope this is what you asked for...

thanks.


Em Seg, 2003-11-24 ?s 20:38, Jean Delvare escreveu:
> Hello,
> 
> I saw your ticket about the unknown eeprom type. Could you please tell
> us what type of memory you have, which capacity, and provide a dump of
> the eeprom? (i2cdump 0 0x50).
> 
> Thanks.

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

Hello,

I saw your ticket about the unknown eeprom type. Could you please tell
us what type of memory you have, which capacity, and provide a dump of
the eeprom? (i2cdump 0 0x50).

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Fernando Rocha Durso]

root@athlon:/home/fernando# cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0

root@athlon:/home/fernando# which sensors
/usr/local/bin/sensors

root@athlon:/home/fernando# sensors -v
sensors version 2.8.1

root@athlon:/home/fernando# ldd $(which sensors)
        libsensors.so.2 => /usr/local/lib/libsensors.so.2 (0x40028000)
        libc.so.6 => /lib/libc.so.6 (0x40055000)
        libm.so.6 => /lib/libm.so.6 (0x4018b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

root@athlon:/home/fernando# ls -l /usr/local/lib/libsensors.*
-rw-r--r--    1 root     root       119344 2003-11-18 21:07
/usr/local/lib/libsensors.a
lrwxrwxrwx    1 root     root           15 2003-11-18 21:07
/usr/local/lib/libsensors.so -> libsensors.so.2
lrwxrwxrwx    1 root     root           19 2003-11-18 21:07
/usr/local/lib/libsensors.so.2 -> libsensors.so.2.0.1
-rw-r--r--    1 root     root       117212 2003-11-18 21:07
/usr/local/lib/libsensors.so.2.0.1

root@athlon:/home/fernando# ls -l /usr/lib/libsensors.*
/usr/bin/ls: /usr/lib/libsensors.*: Arquivo ou diret?rio n?o encontrado


Em Ter, 2003-11-25 ?s 18:06, Jean Delvare escreveu:
> Fernando, William,
> 
> Since you are experiencing the same problem with eeprom decoding, I
> merge both threads here.
> 
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> > 00: 80 08 07 0d 0a 01 40 00 04 50 65 00 82 08 00 01   
>             ^^
> > 10: 0c 04 10 01 02 20 00 00 00 00 00 50 28 50 28 40  
> > 20: 60 60 40 40 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 de  
> > 40: 43 43 41 54 33 00 00 00 01 00 00 00 00 00 00 00   
>             ^^
> > 50: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 22 00  
> > (...)
> > My memory is Samsung DDR 400, i have one DDR with 256 Mb
> > I hope this is what you asked for...
> 
> Yes it is. Your memory type is correct (0x07 at 0x02 means "DDR SDRAM
> DIMM"). But for an unknown reason, sensors reads the value at 0x42
> instead (0x41 is 65).
> 
> The problem can come from three components:
> 1* The eeprom driver.
> 2* The libsensors library.
> 3* The sensors program.
> Since I don't have a clue yet, I'd like you to provide the folling
> additional information:
> 
> 1* The output of "cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*".
> 
> 2* The output of "which sensors".
> 
> 3* The output of "sensors -v".
> 
> 4* The output of "ldd $(which sensors)".
> 
> 5* The output of "ls -l /usr/local/lib/libsensors.*
> /usr/lib/libsensors.*".
> 
> Hopefully it'll give me some ideas. Thanks.

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

Fernando, William,

Since you are experiencing the same problem with eeprom decoding, I
merge both threads here.

>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 80 08 07 0d 0a 01 40 00 04 50 65 00 82 08 00 01   
            ^^
> 10: 0c 04 10 01 02 20 00 00 00 00 00 50 28 50 28 40  
> 20: 60 60 40 40 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 de  
> 40: 43 43 41 54 33 00 00 00 01 00 00 00 00 00 00 00   
            ^^
> 50: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 22 00  
> (...)
> My memory is Samsung DDR 400, i have one DDR with 256 Mb
> I hope this is what you asked for...

Yes it is. Your memory type is correct (0x07 at 0x02 means "DDR SDRAM
DIMM"). But for an unknown reason, sensors reads the value at 0x42
instead (0x41 is 65).

The problem can come from three components:
1* The eeprom driver.
2* The libsensors library.
3* The sensors program.
Since I don't have a clue yet, I'd like you to provide the folling
additional information:

1* The output of "cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*".

2* The output of "which sensors".

3* The output of "sensors -v".

4* The output of "ldd $(which sensors)".

5* The output of "ls -l /usr/local/lib/libsensors.*
/usr/lib/libsensors.*".

Hopefully it'll give me some ideas. Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

Requested output below...Sensors installed on this machine are CVS as of a
few days ago...I had to tweak a file to get the package to build but it was
for an unresolved definition for the <kernel/chips/fscher.c> driver file.
Should not have affected anything I hope.

Interesting side note...I have two systems both with the same Motherboard
and RAM setup, basically both system are identical except for video card and
peripherals.  One, the one with the issues, is running redhat 9 somewhat
up2date and the other Fedora Core 1(evaluating prior to second system
install).  The thing that's interesting is the Fedora Core 1 lm_sensors
works out of the box, sensors are functioning.  Also sensors-detect only
suggested i2c-isa and w83781d with Fedora Core 1.  Redhat 9 suggested those
two plus eeprom and i2c-nforce2.  Not sure if that's anything but I thought
it was odd...Just wanted to mention.

Bill

[root@workstation1 root]# cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
[root@workstation1 root]# which sensors
/usr/local/bin/sensors
[root@workstation1 root]# sensors -v
sensors version 2.8.1
[root@workstation1 root]# ldd $(which sensors)
        libsensors.so.3 => /usr/lib/libsensors.so.3 (0x4002c000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libm.so.6 => /lib/tls/libm.so.6 (0x4005e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@workstation1 root]# ls -l /usr/local/lib/libsensors.*
/usr/lib/libsensors.*
ls: /usr/local/lib/libsensors.*: No such file or directory
-rw-r--r--    1 root     root       144724 Nov 24 10:29
/usr/lib/libsensors.a
lrwxrwxrwx    1 root     root           15 Nov 24 10:33
/usr/lib/libsensors.so -> libsensors.so.3
lrwxrwxrwx    1 root     root           19 May  7  2003
/usr/lib/libsensors.so.1 -> libsensors.so.1.2.1
-rwxr-xr-x    1 root     root        79944 Jan 24  2003
/usr/lib/libsensors.so.1.2.1
lrwxrwxrwx    1 root     root           19 Nov 24 10:33
/usr/lib/libsensors.so.2 -> libsensors.so.2.0.1
-rw-r--r--    1 root     root       116278 Nov 17 11:17
/usr/lib/libsensors.so.2.0.1
lrwxrwxrwx    1 root     root           19 Nov 24 10:33
/usr/lib/libsensors.so.3 -> libsensors.so.3.0.0
-rw-r--r--    1 root     root       142747 Nov 24 10:29
/usr/lib/libsensors.so.3.0.0
[root@workstation1 root]#


-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Tuesday, November 25, 2003 11:07 AM
To: Fernando Rocha Durso; McClintock William J Contr MCOM
Cc: sensors@Stimpy.netroedge.com
Subject: Re: unknown eeprom type (65) [ticket #1449]


Fernando, William,

Since you are experiencing the same problem with eeprom decoding, I
merge both threads here.

>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 80 08 07 0d 0a 01 40 00 04 50 65 00 82 08 00 01   
            ^^
> 10: 0c 04 10 01 02 20 00 00 00 00 00 50 28 50 28 40  
> 20: 60 60 40 40 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 de  
> 40: 43 43 41 54 33 00 00 00 01 00 00 00 00 00 00 00   
            ^^
> 50: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 22 00  
> (...)
> My memory is Samsung DDR 400, i have one DDR with 256 Mb
> I hope this is what you asked for...

Yes it is. Your memory type is correct (0x07 at 0x02 means "DDR SDRAM
DIMM"). But for an unknown reason, sensors reads the value at 0x42
instead (0x41 is 65).

The problem can come from three components:
1* The eeprom driver.
2* The libsensors library.
3* The sensors program.
Since I don't have a clue yet, I'd like you to provide the folling
additional information:

1* The output of "cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*".

2* The output of "which sensors".

3* The output of "sensors -v".

4* The output of "ldd $(which sensors)".

5* The output of "ls -l /usr/local/lib/libsensors.*
/usr/lib/libsensors.*".

Hopefully it'll give me some ideas. Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> Requested output below...Sensors installed on this machine are CVS as
> of a few days ago...I had to tweak a file to get the package to build
> but it was for an unresolved definition for the
> <kernel/chips/fscher.c> driver file. Should not have affected anything
> I hope.

This probably means that lm_sensors2 used older i2c headers. Did you
also install i2c-2.8.1 or CVS? It's a requirement.

> Interesting side note...I have two systems both with the same
> Motherboard and RAM setup, basically both system are identical except
> for video card and peripherals.  One, the one with the issues, is
> running redhat 9 somewhat up2date and the other Fedora Core
> 1(evaluating prior to second system install).  The thing that's
> interesting is the Fedora Core 1 lm_sensors works out of the box,
> sensors are functioning.  Also sensors-detect only suggested i2c-isa
> and w83781d with Fedora Core 1.  Redhat 9 suggested those two plus
> eeprom and i2c-nforce2.  Not sure if that's anything but I thought it
> was odd...Just wanted to mention.

This just means that Fedora has no support for the nForce2 yet (it's
faitly recent), and the nForce2 gives access to eeproms. So there's
nothing to be afraid of, and no one to blame either.

> [root@workstation1 root]# cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0

This is odd, and answers my questions. The driver is broken. This should
be the same (in decimal) as what i2cdump shows (in hexadecimal). And as
you can see, it isn't the case. Rows 04 and 05 are repeated instead.

Now, there are two possibilities. Either the driver doesn't return the
correct values, or the procfs interface to the driver is broken.

Please provide the output of "ls -l
/proc/sys/dev/sensors/eeprom-i2c-0-50".

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

> This probably means that lm_sensors2 used older i2c headers. Did you
> also install i2c-2.8.1 or CVS? It's a requirement.

CVS version of i2c and lm_sensors were both installed on the redhat 9
system.  Now whether it installed the headers in the correct place...I never
checked but all seemed to work well so...no harm no fowl...

> Please provide the output of "ls -l
> /proc/sys/dev/sensors/eeprom-i2c-0-50".

[root@workstation1 root]# ls -l /proc/sys/dev/sensors/eeprom-i2c-0-50
total 0
-r--r--r--    1 root     root            0 Nov 25 14:36 00
-r--r--r--    1 root     root            0 Nov 25 14:36 10
-r--r--r--    1 root     root            0 Nov 25 14:36 20
-r--r--r--    1 root     root            0 Nov 25 14:36 30
-r--r--r--    1 root     root            0 Nov 25 14:36 40
-r--r--r--    1 root     root            0 Nov 25 14:36 50
-r--r--r--    1 root     root            0 Nov 25 14:36 60
-r--r--r--    1 root     root            0 Nov 25 14:36 70
-r--r--r--    1 root     root            0 Nov 25 14:36 80
-r--r--r--    1 root     root            0 Nov 25 14:36 90
-r--r--r--    1 root     root            0 Nov 25 14:36 a0
-r--r--r--    1 root     root            0 Nov 25 14:36 b0
-r--r--r--    1 root     root            0 Nov 25 14:36 c0
-r--r--r--    1 root     root            0 Nov 25 14:36 d0
-r--r--r--    1 root     root            0 Nov 25 14:36 e0
-r--r--r--    1 root     root            0 Nov 25 14:36 f0

-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Tuesday, November 25, 2003 1:19 PM
To: McClintock William J Contr MCOM
Cc: sensors@Stimpy.netroedge.com; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]


> Requested output below...Sensors installed on this machine are CVS as
> of a few days ago...I had to tweak a file to get the package to build
> but it was for an unresolved definition for the
> <kernel/chips/fscher.c> driver file. Should not have affected anything
> I hope.

This probably means that lm_sensors2 used older i2c headers. Did you
also install i2c-2.8.1 or CVS? It's a requirement.

> Interesting side note...I have two systems both with the same
> Motherboard and RAM setup, basically both system are identical except
> for video card and peripherals.  One, the one with the issues, is
> running redhat 9 somewhat up2date and the other Fedora Core
> 1(evaluating prior to second system install).  The thing that's
> interesting is the Fedora Core 1 lm_sensors works out of the box,
> sensors are functioning.  Also sensors-detect only suggested i2c-isa
> and w83781d with Fedora Core 1.  Redhat 9 suggested those two plus
> eeprom and i2c-nforce2.  Not sure if that's anything but I thought it
> was odd...Just wanted to mention.

This just means that Fedora has no support for the nForce2 yet (it's
faitly recent), and the nForce2 gives access to eeproms. So there's
nothing to be afraid of, and no one to blame either.

> [root@workstation1 root]# cat /proc/sys/dev/sensors/eeprom-i2c-0-50/*
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0
> 127 127 158 0 0 0 0 0 1 67 77 88 50 53 54 65
> 45 51 50 48 48 76 76 0 0 0 0 0 0 0 0 0

This is odd, and answers my questions. The driver is broken. This should
be the same (in decimal) as what i2cdump shows (in hexadecimal). And as
you can see, it isn't the case. Rows 04 and 05 are repeated instead.

Now, there are two possibilities. Either the driver doesn't return the
correct values, or the procfs interface to the driver is broken.

Please provide the output of "ls -l
/proc/sys/dev/sensors/eeprom-i2c-0-50".

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> > Please provide the output of "ls -l
> > /proc/sys/dev/sensors/eeprom-i2c-0-50".
> 
> [root@workstation1 root]# ls -l /proc/sys/dev/sensors/eeprom-i2c-0-50
> total 0
> -r--r--r--    1 root     root            0 Nov 25 14:36 00
> -r--r--r--    1 root     root            0 Nov 25 14:36 10
> -r--r--r--    1 root     root            0 Nov 25 14:36 20
> -r--r--r--    1 root     root            0 Nov 25 14:36 30
> -r--r--r--    1 root     root            0 Nov 25 14:36 40
> -r--r--r--    1 root     root            0 Nov 25 14:36 50
> -r--r--r--    1 root     root            0 Nov 25 14:36 60
> -r--r--r--    1 root     root            0 Nov 25 14:36 70
> -r--r--r--    1 root     root            0 Nov 25 14:36 80
> -r--r--r--    1 root     root            0 Nov 25 14:36 90
> -r--r--r--    1 root     root            0 Nov 25 14:36 a0
> -r--r--r--    1 root     root            0 Nov 25 14:36 b0
> -r--r--r--    1 root     root            0 Nov 25 14:36 c0
> -r--r--r--    1 root     root            0 Nov 25 14:36 d0
> -r--r--r--    1 root     root            0 Nov 25 14:36 e0
> -r--r--r--    1 root     root            0 Nov 25 14:36 f0

This is correct, so I would say the procfs interface is working OK. So
this is the driver been broken.

Fernando, your problem is exactly the same, as you'll have noticed.

Could you please enable DEBUG in lm_sensors2, recompile and reinstall
it? (All I really want is DEBUG enabled on the eeprom module.) You just
have to edit the Makefile file and uncomment the right line.

Then, unload the old eeprom module, load the new one, and do "cat
/proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
dmesg (or whichever log the debug stuff will have gone into), and tell
me what you see there, from the moment the module was loaded. Hopefully,
this will help me locate where the bug could hide.

Thanks a lot.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

> Then, unload the old eeprom module, load the new one, and do "cat
> /proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
> dmesg (or whichever log the debug stuff will have gone into), and tell
> me what you see there, from the moment the module was loaded. Hopefully,
> this will help me locate where the bug could hide.

Hope this is it...

Starting eeprom update, slice 0
eeprom.o: 0x50 EEPROM contents (row 1): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 2): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 1
eeprom.o: 0x50 EEPROM contents (row 3): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 4): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 2
eeprom.o: 0x50 EEPROM contents (row 5): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 6): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 3
eeprom.o: 0x50 EEPROM contents (row 7): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 8): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 4
eeprom.o: 0x50 EEPROM contents (row 9): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 10): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 5
eeprom.o: 0x50 EEPROM contents (row 11): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 12): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 6
eeprom.o: 0x50 EEPROM contents (row 13): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 14): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Starting eeprom update, slice 7
eeprom.o: 0x50 EEPROM contents (row 15): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
eeprom.o: 0x50 EEPROM contents (row 16): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00


-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Tuesday, November 25, 2003 2:12 PM
To: McClintock William J Contr MCOM
Cc: sensors@Stimpy.netroedge.com; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]



> > Please provide the output of "ls -l
> > /proc/sys/dev/sensors/eeprom-i2c-0-50".
> 
> [root@workstation1 root]# ls -l /proc/sys/dev/sensors/eeprom-i2c-0-50
> total 0
> -r--r--r--    1 root     root            0 Nov 25 14:36 00
> -r--r--r--    1 root     root            0 Nov 25 14:36 10
> -r--r--r--    1 root     root            0 Nov 25 14:36 20
> -r--r--r--    1 root     root            0 Nov 25 14:36 30
> -r--r--r--    1 root     root            0 Nov 25 14:36 40
> -r--r--r--    1 root     root            0 Nov 25 14:36 50
> -r--r--r--    1 root     root            0 Nov 25 14:36 60
> -r--r--r--    1 root     root            0 Nov 25 14:36 70
> -r--r--r--    1 root     root            0 Nov 25 14:36 80
> -r--r--r--    1 root     root            0 Nov 25 14:36 90
> -r--r--r--    1 root     root            0 Nov 25 14:36 a0
> -r--r--r--    1 root     root            0 Nov 25 14:36 b0
> -r--r--r--    1 root     root            0 Nov 25 14:36 c0
> -r--r--r--    1 root     root            0 Nov 25 14:36 d0
> -r--r--r--    1 root     root            0 Nov 25 14:36 e0
> -r--r--r--    1 root     root            0 Nov 25 14:36 f0

This is correct, so I would say the procfs interface is working OK. So
this is the driver been broken.

Fernando, your problem is exactly the same, as you'll have noticed.

Could you please enable DEBUG in lm_sensors2, recompile and reinstall
it? (All I really want is DEBUG enabled on the eeprom module.) You just
have to edit the Makefile file and uncomment the right line.

Then, unload the old eeprom module, load the new one, and do "cat
/proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
dmesg (or whichever log the debug stuff will have gone into), and tell
me what you see there, from the moment the module was loaded. Hopefully,
this will help me locate where the bug could hide.

Thanks a lot.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Fernando Rocha Durso]

I've recompiled the lm-sensors and reinstaled it, after i did rmmod
eeprom and then modprobe eeprom, but  I made a slight change in my
hardware, i've changed the DDR place, it was at the green bank, and I've
put it now in the purple bank (the closest to the processor), my error
changed to:

root@athlon:/home/fernando# sensors
eeprom-i2c-0-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Unknown EEPROM type (65)

so, i did  cat /proc/sys/dev/sensors/eeprom-i2c-0-51/*

and it returned:

root@athlon:/home/fernando# cat /proc/sys/dev/sensors/eeprom-i2c-0-51/*
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0

my dmesg

Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 2): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 1
eeprom.o: 0x51 EEPROM contents (row 3): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 4): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 2
eeprom.o: 0x51 EEPROM contents (row 5): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 6): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 3
eeprom.o: 0x51 EEPROM contents (row 7): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 8): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 4
eeprom.o: 0x51 EEPROM contents (row 9): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 10): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 5
eeprom.o: 0x51 EEPROM contents (row 11): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 12): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 6
eeprom.o: 0x51 EEPROM contents (row 13): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 14): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 7
eeprom.o: 0x51 EEPROM contents (row 15): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 16): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 2): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 3): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 4): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 5): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 6): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 7): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 8): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 9): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 10): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 11): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 12): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 13): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 14): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 15): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 16): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00


if it is a problem i can reopen my case and turn the DDR back to the
green bank...

bye the way, in using Slackware 9.1

thanks.

Em Ter, 2003-11-25 ?s 21:12, Jean Delvare escreveu:
> > > Please provide the output of "ls -l
> > > /proc/sys/dev/sensors/eeprom-i2c-0-50".
> > 
> > [root@workstation1 root]# ls -l /proc/sys/dev/sensors/eeprom-i2c-0-50
> > total 0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 00
> > -r--r--r--    1 root     root            0 Nov 25 14:36 10
> > -r--r--r--    1 root     root            0 Nov 25 14:36 20
> > -r--r--r--    1 root     root            0 Nov 25 14:36 30
> > -r--r--r--    1 root     root            0 Nov 25 14:36 40
> > -r--r--r--    1 root     root            0 Nov 25 14:36 50
> > -r--r--r--    1 root     root            0 Nov 25 14:36 60
> > -r--r--r--    1 root     root            0 Nov 25 14:36 70
> > -r--r--r--    1 root     root            0 Nov 25 14:36 80
> > -r--r--r--    1 root     root            0 Nov 25 14:36 90
> > -r--r--r--    1 root     root            0 Nov 25 14:36 a0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 b0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 c0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 d0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 e0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 f0
> 
> This is correct, so I would say the procfs interface is working OK. So
> this is the driver been broken.
> 
> Fernando, your problem is exactly the same, as you'll have noticed.
> 
> Could you please enable DEBUG in lm_sensors2, recompile and reinstall
> it? (All I really want is DEBUG enabled on the eeprom module.) You just
> have to edit the Makefile file and uncomment the right line.
> 
> Then, unload the old eeprom module, load the new one, and do "cat
> /proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
> dmesg (or whichever log the debug stuff will have gone into), and tell
> me what you see there, from the moment the module was loaded. Hopefully,
> this will help me locate where the bug could hide.
> 
> Thanks a lot.

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

don't rule out a bus driver problem. They're both using nforce2.
Note that i2cdump uses read_byte_data
while eeprom.c writes the address then uses read_byte.
There's also a couple of failure paths in eeprom that don't have
printks.
I'll add them to CVS now.

We have had previous reports (months ago) that the ddcmon driver
was reading off-by-one, we never figured that out.
This looks different though (off-by-slices).

mds


McClintock William J Contr MCOM wrote:
> 
> > Then, unload the old eeprom module, load the new one, and do "cat
> > /proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
> > dmesg (or whichever log the debug stuff will have gone into), and tell
> > me what you see there, from the moment the module was loaded. Hopefully,
> > this will help me locate where the bug could hide.
> 
> Hope this is it...
> 
> Starting eeprom update, slice 0
> eeprom.o: 0x50 EEPROM contents (row 1): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 2): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 1
> eeprom.o: 0x50 EEPROM contents (row 3): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 4): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 2
> eeprom.o: 0x50 EEPROM contents (row 5): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 6): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 3
> eeprom.o: 0x50 EEPROM contents (row 7): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 8): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 4
> eeprom.o: 0x50 EEPROM contents (row 9): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 10): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 5
> eeprom.o: 0x50 EEPROM contents (row 11): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 12): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 6
> eeprom.o: 0x50 EEPROM contents (row 13): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 14): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Starting eeprom update, slice 7
> eeprom.o: 0x50 EEPROM contents (row 15): 0x7F 0x7F 0x9E 0x00 0x00 0x00 0x00
> 0x00 0x01 0x43 0x4D 0x58 0x32 0x35 0x36 0x41
> eeprom.o: 0x50 EEPROM contents (row 16): 0x2D 0x33 0x32 0x30 0x30 0x4C 0x4C
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> 
> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Tuesday, November 25, 2003 2:12 PM
> To: McClintock William J Contr MCOM
> Cc: sensors@Stimpy.netroedge.com; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> > > Please provide the output of "ls -l
> > > /proc/sys/dev/sensors/eeprom-i2c-0-50".
> >
> > [root@workstation1 root]# ls -l /proc/sys/dev/sensors/eeprom-i2c-0-50
> > total 0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 00
> > -r--r--r--    1 root     root            0 Nov 25 14:36 10
> > -r--r--r--    1 root     root            0 Nov 25 14:36 20
> > -r--r--r--    1 root     root            0 Nov 25 14:36 30
> > -r--r--r--    1 root     root            0 Nov 25 14:36 40
> > -r--r--r--    1 root     root            0 Nov 25 14:36 50
> > -r--r--r--    1 root     root            0 Nov 25 14:36 60
> > -r--r--r--    1 root     root            0 Nov 25 14:36 70
> > -r--r--r--    1 root     root            0 Nov 25 14:36 80
> > -r--r--r--    1 root     root            0 Nov 25 14:36 90
> > -r--r--r--    1 root     root            0 Nov 25 14:36 a0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 b0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 c0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 d0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 e0
> > -r--r--r--    1 root     root            0 Nov 25 14:36 f0
> 
> This is correct, so I would say the procfs interface is working OK. So
> this is the driver been broken.
> 
> Fernando, your problem is exactly the same, as you'll have noticed.
> 
> Could you please enable DEBUG in lm_sensors2, recompile and reinstall
> it? (All I really want is DEBUG enabled on the eeprom module.) You just
> have to edit the Makefile file and uncomment the right line.
> 
> Then, unload the old eeprom module, load the new one, and do "cat
> /proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
> dmesg (or whichever log the debug stuff will have gone into), and tell
> me what you see there, from the moment the module was loaded. Hopefully,
> this will help me locate where the bug could hide.
> 
> Thanks a lot.
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

I've added a 'c' mode to i2cdump in CVS.
If 'i2cdump 0 0x50 c' returns different data than 'i2cdump 0 0x50' then
the problem is in the nforce2 driver. Otherwise it's in eeprom.c.


Mark Studebaker wrote:
> 
> don't rule out a bus driver problem. They're both using nforce2.
> Note that i2cdump uses read_byte_data
> while eeprom.c writes the address then uses read_byte.
> There's also a couple of failure paths in eeprom that don't have
> printks.
> I'll add them to CVS now.
> 
> We have had previous reports (months ago) that the ddcmon driver
> was reading off-by-one, we never figured that out.
> This looks different though (off-by-slices).
> 
> mds
> 
> McClintock William J Contr MCOM wrote:
> >
> > > Then, unload the old eeprom module, load the new one, and do "cat
> > > /proc/sys/dev/sensors/eeprom-i2c-0-50/*" again. Then take a look at
> > > dmesg (or whichever log the debug stuff will have gone into), and tell
> > > me what you see there, from the moment the module was loaded. Hopefully,
> > > this will help me locate where the bug could hide.
> >
> > Hope this is it...
>

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> don't rule out a bus driver problem. They're both using nforce2.

OMG, you're just too good. (Yes, that's another way to say I'm just too
bad.) That said, the debug logs clearly point in that direction too, so
maybe I'd have thought of it in the end ;) Since the rows and slices
indexes are correct, one logical conclusion is that the I2C read
commands wouldn't be returning what they should.

There was another report for the same problem 3 weeks ago. I asked for
additional information but the guy never replied. Guess which bus driver
he was using? Nforce2 of course.

> We have had previous reports (months ago) that the ddcmon driver
> was reading off-by-one, we never figured that out.
> This looks different though (off-by-slices).

Not really off-by-slices. I'd say that it returns row 5 for each odd
row, and row 6 for each even row. Very strange bug indeed.

Thanks a lot for helping me on this.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Fernando Durso]

Guys i?ve downloaded i2c and lm-sensors from CVS patched a new brand kernel source, compiled it and installed i2c and sensors, after i?ve ran sensors-detect, then rebooted and typed sensors... it worked!
here?s my output:
 
fernando@athlon:~$ sensors
eeprom-i2c-0-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Unknown EEPROM type (65)
w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.63 V  (min =  +1.57 V, max =  +1.73 V)
VCore 2:   +1.71 V  (min =  +1.57 V, max =  +1.73 V)       ALARM
+3.3V:     +3.28 V  (min =  +3.14 V, max =  +3.46 V)
+5V:       +5.01 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +12.08 V  (min = +10.83 V, max = +13.19 V)
-12V:     -11.93 V  (min = -13.16 V, max = -10.90 V)
-5V:       -5.14 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.54 V  (min =  +4.74 V, max =  +5.24 V)
VBat:      +2.98 V  (min =  +2.40 V, max =  +3.60 V)
fan1:        0 RPM  (min = 14062 RPM, div = 2)
fan2:     3609 RPM  (min = 112500 RPM, div = 2)
fan3:        0 RPM  (min = 2481 RPM, div = 4)
temp1:       +41?C  (high =   +99?C, hyst =    +1?C)   sensor = thermistor      
temp2:     +45.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor      
temp3:     +33.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor      
vid:      +1.650 V
alarms:
beep_enable:
          Sound alarm disabled

root@athlon:~# lsmod
Module                  Size  Used by    Not tainted
ppp_synctty             6304   0  (unused)
ppp_async               7680   1
ppp_generic            15996   3  [ppp_synctty ppp_async]
slhc                    5392   0  [ppp_generic]
w83781d                20432   0  (unused)
eeprom                  4496   0  (unused)
i2c-proc                6548   0  [w83781d eeprom]
i2c-isa                  748   0  (unused)
i2c-nforce2             3368   0  (unused)
i2c-core               14660   0  [w83781d eeprom i2c-proc i2c-isa i2c-nforce2]
parport_pc             15684   1  (autoclean)
lp                      6784   0  (autoclean)
parport                24992   1  (autoclean) [parport_pc lp]
ipt_REJECT              3512   4  (autoclean)
iptable_filter          1740   1  (autoclean)
ip_tables              15136   2  [ipt_REJECT iptable_filter]
printer                 7392   0
usb-ohci               19016   0  (unused)
ehci-hcd               17544   0  (unused)
usbcore                62016   1  [printer usb-ohci ehci-hcd]
8139too                16200   1
mii                     2496   0  [8139too]
crc32                   2848   0  [8139too]
ide-scsi               10224   0
agpgart                41688   0  (unused)
apm                    10024   1

root@athlon:~# cat /proc/sys/dev/sensors/eeprom-i2c-0-51/*
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0

root@athlon:~# wich sensors
-su: wich: command not found
root@athlon:~# ldd $(wich sensors)
-su: wich: command not found
ldd: missing file arguments

 
root@athlon:~# ls -l /usr/local/lib/libsensors.*
-rw-r--r--    1 root     root       146396 2003-11-26 13:48 /usr/local/lib/libsensors.a
lrwxrwxrwx    1 root     root           15 2003-11-26 13:48 /usr/local/lib/libsensors.so -> libsensors.so.3
lrwxrwxrwx    1 root     root           19 2003-11-25 22:45 /usr/local/lib/libsensors.so.2 -> libsensors.so.2.0.1
-rw-r--r--    1 root     root       117212 2003-11-25 22:45 /usr/local/lib/libsensors.so.2.0.1
lrwxrwxrwx    1 root     root           19 2003-11-26 13:48 /usr/local/lib/libsensors.so.3 -> libsensors.so.3.0.0
-rw-r--r--    1 root     root       144065 2003-11-26 13:48 /usr/local/lib/libsensors.so.3.0.0

root@athlon:~# ls -l /usr/lib/libsensors.*
/usr/bin/ls: /usr/lib/libsensors.*: Arquivo ou diret?rio n?o encontrado

dmesg:
 
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 2): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 1
eeprom.o: 0x51 EEPROM contents (row 3): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 4): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 2
eeprom.o: 0x51 EEPROM contents (row 5): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 6): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 3
eeprom.o: 0x51 EEPROM contents (row 7): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 8): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 4
eeprom.o: 0x51 EEPROM contents (row 9): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 10): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 5
eeprom.o: 0x51 EEPROM contents (row 11): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 12): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 6
eeprom.o: 0x51 EEPROM contents (row 13): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 14): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 7
eeprom.o: 0x51 EEPROM contents (row 15): 0x43 0x43 0x41 0x54 0x33 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 16): 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00

thanks



---------------------------------
Yahoo! Mail - 6MB, anti-spam e antiv?rus gratuito. Crie sua conta agora!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031126/69015969/attachment.html

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> don't rule out a bus driver problem. They're both using nforce2.

Actually I think I've narrowed it to i2c-nforce2's
i2c_smbus_write_byte() being broken. After performing the checksum, the
address register has value 0x40. The i2c_smbus_write_byte() call should
change that value to the right one for each read slice, but for some
reason fails to do so. This is why it always returns rows 5 and 6
(because this slice really begins at 0x40).

As to why the call fails, I have no clue. I've never messed with (real)
bus drivers. I'll contact the author of the module, I hope he'll be able
to help. Only a few chip drivers use that call, among which there is no
widely used monitoring chip, so we can reasonnably suppose that a bug
here could have been left uncaught so far (especially since the
i2c-nforce2 driver itself is fairly new).

BTW, Mark, what's the difference between (2c_smbus_write_byte and
i2c_smbus_write_quick? I can't really tell, since they have the same
prototype. For a moment, I wondered if I shouldn't have been using
_quick instead of _byte, but since _byte works OK for me...

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

I'd like the two folks with the problem (or anybody else with a nforce2)
try the new i2cdump in cvs to confirm.
if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
is in the amd756 driver.

Actually, if anybody has an amd756/66/68 then they could try this too.
Maybe the nforce2 acts a little differently...

Write quick doesn't have any data at all, other than the
single read/write bit at the end of the address byte.

Jean Delvare wrote:

>>don't rule out a bus driver problem. They're both using nforce2.
> 
> 
> Actually I think I've narrowed it to i2c-nforce2's
> i2c_smbus_write_byte() being broken. After performing the checksum, the
> address register has value 0x40. The i2c_smbus_write_byte() call should
> change that value to the right one for each read slice, but for some
> reason fails to do so. This is why it always returns rows 5 and 6
> (because this slice really begins at 0x40).
> 
> As to why the call fails, I have no clue. I've never messed with (real)
> bus drivers. I'll contact the author of the module, I hope he'll be able
> to help. Only a few chip drivers use that call, among which there is no
> widely used monitoring chip, so we can reasonnably suppose that a bug
> here could have been left uncaught so far (especially since the
> i2c-nforce2 driver itself is fairly new).
> 
> BTW, Mark, what's the difference between (2c_smbus_write_byte and
> i2c_smbus_write_quick? I can't really tell, since they have the same
> prototype. For a moment, I wondered if I shouldn't have been using
> _quick instead of _byte, but since _byte works OK for me...
> 

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> I'd like the two folks with the problem (or anybody else with a
> nforce2) try the new i2cdump in cvs to confirm.
> if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
> is in the amd756 driver.

Bill, Fernando, if you please could get i2cdump from CVS and give it a
try... Thanks.

> Actually, if anybody has an amd756/66/68 then they could try this too.
> Maybe the nforce2 acts a little differently...

I think you're mixing things up. The i2c-amd756 driver covers the
nforce (1), not the nforce2. I2c-nforce2 is a different driver.

> Write quick doesn't have any data at all, other than the
> single read/write bit at the end of the address byte.

Interesting. So basically it is just meant to check wether someone would
acknoledge the address or not?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

Jean Delvare wrote:

>>I'd like the two folks with the problem (or anybody else with a
>>nforce2) try the new i2cdump in cvs to confirm.
>>if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
>>is in the amd756 driver.
> 
> 
> Bill, Fernando, if you please could get i2cdump from CVS and give it a
> try... Thanks.
> 
> 
>>Actually, if anybody has an amd756/66/68 then they could try this too.
>>Maybe the nforce2 acts a little differently...
> 
> 
> I think you're mixing things up. The i2c-amd756 driver covers the
> nforce (1), not the nforce2. I2c-nforce2 is a different driver.
> 

oops you're right.


> 
>>Write quick doesn't have any data at all, other than the
>>single read/write bit at the end of the address byte.
> 
> 
> Interesting. So basically it is just meant to check wether someone would
> acknoledge the address or not?
> 

that's what we use it for.
In theory, you write a single bit of data.
So you could use it for a single addressible switch.

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

Output from todays CVS below...Not sure if I should have expected results or
what...Attached from modprobes through partial lsmod.

[root@workstation1 cvs2]# modprobe i2c-isa
[root@workstation1 cvs2]# modprobe eeprom
[root@workstation1 cvs2]# modprobe i2c-nforce2
[root@workstation1 cvs2]# modprobe w83781d
[root@workstation1 cvs2]# sensors
eeprom-i2c-1-50
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Unknown EEPROM type (158)

eeprom-i2c-1-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Unknown EEPROM type (158)

w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
VCore 2:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
+3.3V:     +3.25 V  (min =  +3.14 V, max =  +3.46 V)
+5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
-12V:     -11.52 V  (min = -13.16 V, max = -10.90 V)
-5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)       ALARM
VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
fan1:     5113 RPM  (min = 2678 RPM, div = 2)
fan2:     5357 RPM  (min = 6887 RPM, div = 2)              ALARM
fan3:        0 RPM  (min = 2280 RPM, div = 4)              ALARM
temp1:       +24?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor
temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
vid:      +1.650 V
alarms:
beep_enable:
          Sound alarm disabled

[root@workstation1 cvs2]# i2cdump 0 50
No size specified (using byte-data access)
Error: Adapter for i2c bus 0 does not have byte read capability
[root@workstation1 cvs2]# i2cdump 0 50 c
Error: Adapter for i2c bus 0 does not have read capability
[root@workstation1 cvs2]# lsmod
Module                  Size  Used by    Tainted: P
i2c-dev                 5088   0  (autoclean)
w83781d                21744   0  (unused)
i2c-nforce2             4040   0  (unused)
eeprom                  5040   0  (unused)
i2c-proc                7988   0  [w83781d eeprom]
i2c-isa                 1292   0
i2c-core               19556   0  [i2c-dev w83781d i2c-nforce2 eeprom
i2c-proc i2c-isa]

-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Wednesday, November 26, 2003 1:50 PM
To: sensors@Stimpy.netroedge.com
Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]


> I'd like the two folks with the problem (or anybody else with a
> nforce2) try the new i2cdump in cvs to confirm.
> if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
> is in the amd756 driver.

Bill, Fernando, if you please could get i2cdump from CVS and give it a
try... Thanks.

> Actually, if anybody has an amd756/66/68 then they could try this too.
> Maybe the nforce2 acts a little differently...

I think you're mixing things up. The i2c-amd756 driver covers the
nforce (1), not the nforce2. I2c-nforce2 is a different driver.

> Write quick doesn't have any data at all, other than the
> single read/write bit at the end of the address byte.

Interesting. So basically it is just meant to check wether someone would
acknoledge the address or not?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

Output below...?...The WARNING...Should I be concerned?  Reboot?  etc...

[root@workstation1 cvs2]# i2cdump 1 50
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-1, address 0x32, mode byte
  You have five seconds to reconsider and press CTRL-C!

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
[root@workstation1 cvs2]# i2cdump 1 50 c
  WARNING! This program can confuse your I2C bus, cause data loss and worse!
  I will probe file /dev/i2c-1, address 0x32, mode byte consecutive read
  You have five seconds to reconsider and press CTRL-C!

Segmentation fault
[root@workstation1 cvs2]#


-----Original Message-----
From: Mark Studebaker [mailto:mds@paradyne.com]
Sent: Wednesday, November 26, 2003 2:10 PM
To: McClintock William J Contr MCOM
Cc: 'sensors@Stimpy.netroedge.com'; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]


for the i2cdump test please replace '0' with '1' since
your eeproms are now on bus 1.
thanks

McClintock William J Contr MCOM wrote:

> Output from todays CVS below...Not sure if I should have expected results
or
> what...Attached from modprobes through partial lsmod.
> 
> [root@workstation1 cvs2]# modprobe i2c-isa
> [root@workstation1 cvs2]# modprobe eeprom
> [root@workstation1 cvs2]# modprobe i2c-nforce2
> [root@workstation1 cvs2]# modprobe w83781d
> [root@workstation1 cvs2]# sensors
> eeprom-i2c-1-50
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (158)
> 
> eeprom-i2c-1-51
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (158)
> 
> w83627hf-isa-0290
> Adapter: ISA adapter
> Algorithm: ISA algorithm
> VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
> VCore 2:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
> +3.3V:     +3.25 V  (min =  +3.14 V, max =  +3.46 V)
> +5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
> +12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
> -12V:     -11.52 V  (min = -13.16 V, max = -10.90 V)
> -5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
> V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)       ALARM
> VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
> fan1:     5113 RPM  (min = 2678 RPM, div = 2)
> fan2:     5357 RPM  (min = 6887 RPM, div = 2)              ALARM
> fan3:        0 RPM  (min = 2280 RPM, div = 4)              ALARM
> temp1:       +24?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor
> temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
> temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
> vid:      +1.650 V
> alarms:
> beep_enable:
>           Sound alarm disabled
> 
> [root@workstation1 cvs2]# i2cdump 0 50
> No size specified (using byte-data access)
> Error: Adapter for i2c bus 0 does not have byte read capability
> [root@workstation1 cvs2]# i2cdump 0 50 c
> Error: Adapter for i2c bus 0 does not have read capability
> [root@workstation1 cvs2]# lsmod
> Module                  Size  Used by    Tainted: P
> i2c-dev                 5088   0  (autoclean)
> w83781d                21744   0  (unused)
> i2c-nforce2             4040   0  (unused)
> eeprom                  5040   0  (unused)
> i2c-proc                7988   0  [w83781d eeprom]
> i2c-isa                 1292   0
> i2c-core               19556   0  [i2c-dev w83781d i2c-nforce2 eeprom
> i2c-proc i2c-isa]
> 
> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Wednesday, November 26, 2003 1:50 PM
> To: sensors@Stimpy.netroedge.com
> Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> 
> 
>>I'd like the two folks with the problem (or anybody else with a
>>nforce2) try the new i2cdump in cvs to confirm.
>>if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
>>is in the amd756 driver.
> 
> 
> Bill, Fernando, if you please could get i2cdump from CVS and give it a
> try... Thanks.
> 
> 
>>Actually, if anybody has an amd756/66/68 then they could try this too.
>>Maybe the nforce2 acts a little differently...
> 
> 
> I think you're mixing things up. The i2c-amd756 driver covers the
> nforce (1), not the nforce2. I2c-nforce2 is a different driver.
> 
> 
>>Write quick doesn't have any data at all, other than the
>>single read/write bit at the end of the address byte.
> 
> 
> Interesting. So basically it is just meant to check wether someone would
> acknoledge the address or not?
> 

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

for the i2cdump test please replace '0' with '1' since
your eeproms are now on bus 1.
thanks

McClintock William J Contr MCOM wrote:

> Output from todays CVS below...Not sure if I should have expected results or
> what...Attached from modprobes through partial lsmod.
> 
> [root@workstation1 cvs2]# modprobe i2c-isa
> [root@workstation1 cvs2]# modprobe eeprom
> [root@workstation1 cvs2]# modprobe i2c-nforce2
> [root@workstation1 cvs2]# modprobe w83781d
> [root@workstation1 cvs2]# sensors
> eeprom-i2c-1-50
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (158)
> 
> eeprom-i2c-1-51
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (158)
> 
> w83627hf-isa-0290
> Adapter: ISA adapter
> Algorithm: ISA algorithm
> VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
> VCore 2:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
> +3.3V:     +3.25 V  (min =  +3.14 V, max =  +3.46 V)
> +5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
> +12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
> -12V:     -11.52 V  (min = -13.16 V, max = -10.90 V)
> -5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
> V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)       ALARM
> VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
> fan1:     5113 RPM  (min = 2678 RPM, div = 2)
> fan2:     5357 RPM  (min = 6887 RPM, div = 2)              ALARM
> fan3:        0 RPM  (min = 2280 RPM, div = 4)              ALARM
> temp1:       +24?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor
> temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
> temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
> vid:      +1.650 V
> alarms:
> beep_enable:
>           Sound alarm disabled
> 
> [root@workstation1 cvs2]# i2cdump 0 50
> No size specified (using byte-data access)
> Error: Adapter for i2c bus 0 does not have byte read capability
> [root@workstation1 cvs2]# i2cdump 0 50 c
> Error: Adapter for i2c bus 0 does not have read capability
> [root@workstation1 cvs2]# lsmod
> Module                  Size  Used by    Tainted: P
> i2c-dev                 5088   0  (autoclean)
> w83781d                21744   0  (unused)
> i2c-nforce2             4040   0  (unused)
> eeprom                  5040   0  (unused)
> i2c-proc                7988   0  [w83781d eeprom]
> i2c-isa                 1292   0
> i2c-core               19556   0  [i2c-dev w83781d i2c-nforce2 eeprom
> i2c-proc i2c-isa]
> 
> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Wednesday, November 26, 2003 1:50 PM
> To: sensors@Stimpy.netroedge.com
> Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> 
> 
>>I'd like the two folks with the problem (or anybody else with a
>>nforce2) try the new i2cdump in cvs to confirm.
>>if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
>>is in the amd756 driver.
> 
> 
> Bill, Fernando, if you please could get i2cdump from CVS and give it a
> try... Thanks.
> 
> 
>>Actually, if anybody has an amd756/66/68 then they could try this too.
>>Maybe the nforce2 acts a little differently...
> 
> 
> I think you're mixing things up. The i2c-amd756 driver covers the
> nforce (1), not the nforce2. I2c-nforce2 is a different driver.
> 
> 
>>Write quick doesn't have any data at all, other than the
>>single read/write bit at the end of the address byte.
> 
> 
> Interesting. So basically it is just meant to check wether someone would
> acknoledge the address or not?
> 

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

sorry. my bad. that's 0x50, not 50.
so try i2cdump 1 0x50
and i2cdump 1 0x50 c

McClintock William J Contr MCOM wrote:

> Output below...?...The WARNING...Should I be concerned?  Reboot?  etc...
> 
> [root@workstation1 cvs2]# i2cdump 1 50
> 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-1, address 0x32, mode byte
>   You have five seconds to reconsider and press CTRL-C!
> 
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> [root@workstation1 cvs2]# i2cdump 1 50 c
>   WARNING! This program can confuse your I2C bus, cause data loss and worse!
>   I will probe file /dev/i2c-1, address 0x32, mode byte consecutive read
>   You have five seconds to reconsider and press CTRL-C!
> 
> Segmentation fault
> [root@workstation1 cvs2]#
> 
> 
> -----Original Message-----
> From: Mark Studebaker [mailto:mds@paradyne.com]
> Sent: Wednesday, November 26, 2003 2:10 PM
> To: McClintock William J Contr MCOM
> Cc: 'sensors@Stimpy.netroedge.com'; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> 
> for the i2cdump test please replace '0' with '1' since
> your eeproms are now on bus 1.
> thanks
> 
> McClintock William J Contr MCOM wrote:
> 
> 
>>Output from todays CVS below...Not sure if I should have expected results
> 
> or
> 
>>what...Attached from modprobes through partial lsmod.
>>
>>[root@workstation1 cvs2]# modprobe i2c-isa
>>[root@workstation1 cvs2]# modprobe eeprom
>>[root@workstation1 cvs2]# modprobe i2c-nforce2
>>[root@workstation1 cvs2]# modprobe w83781d
>>[root@workstation1 cvs2]# sensors
>>eeprom-i2c-1-50
>>Adapter: SMBus nForce2 adapter at 5000
>>Algorithm: Non-I2C SMBus adapter
>>Unknown EEPROM type (158)
>>
>>eeprom-i2c-1-51
>>Adapter: SMBus nForce2 adapter at 5000
>>Algorithm: Non-I2C SMBus adapter
>>Unknown EEPROM type (158)
>>
>>w83627hf-isa-0290
>>Adapter: ISA adapter
>>Algorithm: ISA algorithm
>>VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
>>VCore 2:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
>>+3.3V:     +3.25 V  (min =  +3.14 V, max =  +3.46 V)
>>+5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
>>+12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
>>-12V:     -11.52 V  (min = -13.16 V, max = -10.90 V)
>>-5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
>>V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)       ALARM
>>VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
>>fan1:     5113 RPM  (min = 2678 RPM, div = 2)
>>fan2:     5357 RPM  (min = 6887 RPM, div = 2)              ALARM
>>fan3:        0 RPM  (min = 2280 RPM, div = 4)              ALARM
>>temp1:       +24?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor
>>temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
>>temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
>>vid:      +1.650 V
>>alarms:
>>beep_enable:
>>          Sound alarm disabled
>>
>>[root@workstation1 cvs2]# i2cdump 0 50
>>No size specified (using byte-data access)
>>Error: Adapter for i2c bus 0 does not have byte read capability
>>[root@workstation1 cvs2]# i2cdump 0 50 c
>>Error: Adapter for i2c bus 0 does not have read capability
>>[root@workstation1 cvs2]# lsmod
>>Module                  Size  Used by    Tainted: P
>>i2c-dev                 5088   0  (autoclean)
>>w83781d                21744   0  (unused)
>>i2c-nforce2             4040   0  (unused)
>>eeprom                  5040   0  (unused)
>>i2c-proc                7988   0  [w83781d eeprom]
>>i2c-isa                 1292   0
>>i2c-core               19556   0  [i2c-dev w83781d i2c-nforce2 eeprom
>>i2c-proc i2c-isa]
>>
>>-----Original Message-----
>>From: Jean Delvare [mailto:khali@linux-fr.org]
>>Sent: Wednesday, November 26, 2003 1:50 PM
>>To: sensors@Stimpy.netroedge.com
>>Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
>>Subject: Re: unknown eeprom type (65) [ticket #1449]
>>
>>
>>
>>
>>>I'd like the two folks with the problem (or anybody else with a
>>>nforce2) try the new i2cdump in cvs to confirm.
>>>if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
>>>is in the amd756 driver.
>>
>>
>>Bill, Fernando, if you please could get i2cdump from CVS and give it a
>>try... Thanks.
>>
>>
>>
>>>Actually, if anybody has an amd756/66/68 then they could try this too.
>>>Maybe the nforce2 acts a little differently...
>>
>>
>>I think you're mixing things up. The i2c-amd756 driver covers the
>>nforce (1), not the nforce2. I2c-nforce2 is a different driver.
>>
>>
>>
>>>Write quick doesn't have any data at all, other than the
>>>single read/write bit at the end of the address byte.
>>
>>
>>Interesting. So basically it is just meant to check wether someone would
>>acknoledge the address or not?
>>
> 
> 
> 

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

i2cdump 1 0x50 c...segfaults...i2cdump 1 0x50...never comes back after first
line...

[root@workstation1 root]# i2cdump 1 0x50 c
  WARNING! This program can confuse your I2C bus, cause data loss and worse!
  I will probe file /dev/i2c-1, address 0x50, mode byte consecutive read
  You have five seconds to reconsider and press CTRL-C!

Segmentation fault
[root@workstation1 root]# i2cdump 1 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-1, address 0x50, mode byte
  You have five seconds to reconsider and press CTRL-C!

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef


-----Original Message-----
From: Mark Studebaker [mailto:mds@paradyne.com]
Sent: Wednesday, November 26, 2003 2:37 PM
To: McClintock William J Contr MCOM
Cc: 'sensors@Stimpy.netroedge.com'; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]


sorry. my bad. that's 0x50, not 50.
so try i2cdump 1 0x50
and i2cdump 1 0x50 c

McClintock William J Contr MCOM wrote:

> Output below...?...The WARNING...Should I be concerned?  Reboot?  etc...
> 
> [root@workstation1 cvs2]# i2cdump 1 50
> 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-1, address 0x32, mode byte
>   You have five seconds to reconsider and press CTRL-C!
> 
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> [root@workstation1 cvs2]# i2cdump 1 50 c
>   WARNING! This program can confuse your I2C bus, cause data loss and
worse!
>   I will probe file /dev/i2c-1, address 0x32, mode byte consecutive read
>   You have five seconds to reconsider and press CTRL-C!
> 
> Segmentation fault
> [root@workstation1 cvs2]#
> 
> 
> -----Original Message-----
> From: Mark Studebaker [mailto:mds@paradyne.com]
> Sent: Wednesday, November 26, 2003 2:10 PM
> To: McClintock William J Contr MCOM
> Cc: 'sensors@Stimpy.netroedge.com'; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> 
> for the i2cdump test please replace '0' with '1' since
> your eeproms are now on bus 1.
> thanks
> 
> McClintock William J Contr MCOM wrote:
> 
> 
>>Output from todays CVS below...Not sure if I should have expected results
> 
> or
> 
>>what...Attached from modprobes through partial lsmod.
>>
>>[root@workstation1 cvs2]# modprobe i2c-isa
>>[root@workstation1 cvs2]# modprobe eeprom
>>[root@workstation1 cvs2]# modprobe i2c-nforce2
>>[root@workstation1 cvs2]# modprobe w83781d
>>[root@workstation1 cvs2]# sensors
>>eeprom-i2c-1-50
>>Adapter: SMBus nForce2 adapter at 5000
>>Algorithm: Non-I2C SMBus adapter
>>Unknown EEPROM type (158)
>>
>>eeprom-i2c-1-51
>>Adapter: SMBus nForce2 adapter at 5000
>>Algorithm: Non-I2C SMBus adapter
>>Unknown EEPROM type (158)
>>
>>w83627hf-isa-0290
>>Adapter: ISA adapter
>>Algorithm: ISA algorithm
>>VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
>>VCore 2:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
>>+3.3V:     +3.25 V  (min =  +3.14 V, max =  +3.46 V)
>>+5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
>>+12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
>>-12V:     -11.52 V  (min = -13.16 V, max = -10.90 V)
>>-5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
>>V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)       ALARM
>>VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
>>fan1:     5113 RPM  (min = 2678 RPM, div = 2)
>>fan2:     5357 RPM  (min = 6887 RPM, div = 2)              ALARM
>>fan3:        0 RPM  (min = 2280 RPM, div = 4)              ALARM
>>temp1:       +24?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor
>>temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
>>temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor
>>vid:      +1.650 V
>>alarms:
>>beep_enable:
>>          Sound alarm disabled
>>
>>[root@workstation1 cvs2]# i2cdump 0 50
>>No size specified (using byte-data access)
>>Error: Adapter for i2c bus 0 does not have byte read capability
>>[root@workstation1 cvs2]# i2cdump 0 50 c
>>Error: Adapter for i2c bus 0 does not have read capability
>>[root@workstation1 cvs2]# lsmod
>>Module                  Size  Used by    Tainted: P
>>i2c-dev                 5088   0  (autoclean)
>>w83781d                21744   0  (unused)
>>i2c-nforce2             4040   0  (unused)
>>eeprom                  5040   0  (unused)
>>i2c-proc                7988   0  [w83781d eeprom]
>>i2c-isa                 1292   0
>>i2c-core               19556   0  [i2c-dev w83781d i2c-nforce2 eeprom
>>i2c-proc i2c-isa]
>>
>>-----Original Message-----
>>From: Jean Delvare [mailto:khali@linux-fr.org]
>>Sent: Wednesday, November 26, 2003 1:50 PM
>>To: sensors@Stimpy.netroedge.com
>>Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
>>Subject: Re: unknown eeprom type (65) [ticket #1449]
>>
>>
>>
>>
>>>I'd like the two folks with the problem (or anybody else with a
>>>nforce2) try the new i2cdump in cvs to confirm.
>>>if 'i2cdump 0 50' works but 'i2cdump 0 50 c' fails then the problem
>>>is in the amd756 driver.
>>
>>
>>Bill, Fernando, if you please could get i2cdump from CVS and give it a
>>try... Thanks.
>>
>>
>>
>>>Actually, if anybody has an amd756/66/68 then they could try this too.
>>>Maybe the nforce2 acts a little differently...
>>
>>
>>I think you're mixing things up. The i2c-amd756 driver covers the
>>nforce (1), not the nforce2. I2c-nforce2 is a different driver.
>>
>>
>>
>>>Write quick doesn't have any data at all, other than the
>>>single read/write bit at the end of the address byte.
>>
>>
>>Interesting. So basically it is just meant to check wether someone would
>>acknoledge the address or not?
>>
> 
> 
> 

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> > [root@workstation1 cvs2]# i2cdump 1 50 c
> >   WARNING! This program can confuse your I2C bus, cause data loss
> >   and worse! I will probe file /dev/i2c-1, address 0x32, mode byte
> >   consecutive read You have five seconds to reconsider and press
> >   CTRL-C!
> > 
> > Segmentation fault

Still this needs fixing. Mark, any idea about that? Could it be caused
by the i2c-nforce2 driver? Doing the same here (i2c-i801) exits cleanly:
Error: Write start address failed, return code -1

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

does dmesg have anything about a module going oops?


Jean Delvare wrote:

>>>[root@workstation1 cvs2]# i2cdump 1 50 c
>>>  WARNING! This program can confuse your I2C bus, cause data loss
>>>  and worse! I will probe file /dev/i2c-1, address 0x32, mode byte
>>>  consecutive read You have five seconds to reconsider and press
>>>  CTRL-C!
>>>
>>>Segmentation fault
> 
> 
> Still this needs fixing. Mark, any idea about that? Could it be caused
> by the i2c-nforce2 driver? Doing the same here (i2c-i801) exits cleanly:
> Error: Write start address failed, return code -1
> 

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

i2c-core.o: i2c core module version 2.8.1 (20031005)
i2c-isa.o version 2.8.1 (20031005)
i2c-proc.o version 2.8.1 (20031005)
w83781d.o version 2.8.1 (20031005)
eeprom.o version 2.8.1 (20031005)
i2c-nforce2.o version 2.8.1 (20031005)
i2c-nforce2.o: nForce2 SMBus adapter at 0x5000
i2c-nforce2.o: nForce2 SMBus adapter at 0x5040
i2c-dev.o: i2c /dev entries driver module version 2.8.1 (20031005)
i2c-dev.o: Registered 'ISA main adapter' as minor 0
i2c-dev.o: Registered 'SMBus nForce2 adapter at 5000' as minor 1
i2c-dev.o: Registered 'SMBus nForce2 adapter at 5040' as minor 2
Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
e0a5a216
*pde = 00000000
Oops: 0000
i2c-dev i2c-nforce2 eeprom w83781d i2c-proc i2c-isa i2c-core nvaudio
ac97_codec
soundcore parport_pc lp parport iptable_filter ip_tables autofs nfs lockd
sunr
CPU:    0
EIP:    0060:[<e0a5a216>]    Tainted: P
EFLAGS: 00010246

EIP is at nforce2_access [i2c-nforce2] 0x1b6 (2.4.20-13.9)
eax: 00000000   ebx: 00005000   ecx: c17baa00   edx: 00000001
esi: c17baa00   edi: 00000000   ebp: c17baa00   esp: d82a3e78
ds: 0068   es: 0068   ss: 0068
Process i2cdump (pid: 3542, stackpageÿ2a3000)
Stack: d82cd340 dffd2400 00000296 c25a6bb8 dffd2400 003462b0 00500000
c17baa40
       00000000 00000001 c17baa04 e0a40cc9 c17baa04 00000050 00000000
00000000
       00000000 00000001 00000000 e0a5af20 d8277420 d83ec180 420ac6a0
00000050
Call Trace:   [<e0a40cc9>] i2c_smbus_xfer_R935cccc0 [i2c-core] 0x89
(0xd82a3ea4)
)
[<e0a5af20>] smbus_algorithm [i2c-nforce2] 0x0 (0xd82a3ec4))
[<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3ef0))
[<e0a5c5af>] i2cdev_ioctl [i2c-dev] 0x463 (0xd82a3ef4))
[<c01186c0>] schedule [kernel] 0x170 (0xd82a3f40))
[<c01254d7>] schedule_timeout [kernel] 0x67 (0xd82a3f64))
[<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3f90))
[<c0153d4c>] sys_ioctl [kernel] 0xbc (0xd82a3f94))
[<c010939f>] system_call [kernel] 0x33 (0xd82a3fc0))


Code: 8a 07 8d 53 04 ee e6 80 83 ce 04 e9 a3 fe ff ff 8b 9d f0 00


-----Original Message-----
From: Mark Studebaker [mailto:mds@paradyne.com]
Sent: Wednesday, November 26, 2003 3:41 PM
To: sensors@Stimpy.netroedge.com
Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
Subject: Re: unknown eeprom type (65) [ticket #1449]


does dmesg have anything about a module going oops?


Jean Delvare wrote:

>>>[root@workstation1 cvs2]# i2cdump 1 50 c
>>>  WARNING! This program can confuse your I2C bus, cause data loss
>>>  and worse! I will probe file /dev/i2c-1, address 0x32, mode byte
>>>  consecutive read You have five seconds to reconsider and press
>>>  CTRL-C!
>>>
>>>Segmentation fault
> 
> 
> Still this needs fixing. Mark, any idea about that? Could it be caused
> by the i2c-nforce2 driver? Doing the same here (i2c-i801) exits cleanly:
> Error: Write start address failed, return code -1
> 

unknown eeprom type (65) [ticket #1449]

[Mark Studebaker]

I found and fixed what looked like the problem in i2c-nforce
that the eeprom module was seeing with byte writes.
It was writing the wrong data to the wrong place.
Can't say for sure because I don't have a datasheet.
Doubt that this was the cause of the oopses so there may be something
else going on too.
For those of you testing, if the old i2c-nforce won't rmmod you
will have to reboot. 


McClintock William J Contr MCOM wrote:
> 
> i2c-core.o: i2c core module version 2.8.1 (20031005)
> i2c-isa.o version 2.8.1 (20031005)
> i2c-proc.o version 2.8.1 (20031005)
> w83781d.o version 2.8.1 (20031005)
> eeprom.o version 2.8.1 (20031005)
> i2c-nforce2.o version 2.8.1 (20031005)
> i2c-nforce2.o: nForce2 SMBus adapter at 0x5000
> i2c-nforce2.o: nForce2 SMBus adapter at 0x5040
> i2c-dev.o: i2c /dev entries driver module version 2.8.1 (20031005)
> i2c-dev.o: Registered 'ISA main adapter' as minor 0
> i2c-dev.o: Registered 'SMBus nForce2 adapter at 5000' as minor 1
> i2c-dev.o: Registered 'SMBus nForce2 adapter at 5040' as minor 2
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> e0a5a216
> *pde = 00000000
> Oops: 0000
> i2c-dev i2c-nforce2 eeprom w83781d i2c-proc i2c-isa i2c-core nvaudio
> ac97_codec
> soundcore parport_pc lp parport iptable_filter ip_tables autofs nfs lockd
> sunr
> CPU:    0
> EIP:    0060:[<e0a5a216>]    Tainted: P
> EFLAGS: 00010246
> 
> EIP is at nforce2_access [i2c-nforce2] 0x1b6 (2.4.20-13.9)
> eax: 00000000   ebx: 00005000   ecx: c17baa00   edx: 00000001
> esi: c17baa00   edi: 00000000   ebp: c17baa00   esp: d82a3e78
> ds: 0068   es: 0068   ss: 0068
> Process i2cdump (pid: 3542, stackpageØ2a3000)
> Stack: d82cd340 dffd2400 00000296 c25a6bb8 dffd2400 003462b0 00500000
> c17baa40
>        00000000 00000001 c17baa04 e0a40cc9 c17baa04 00000050 00000000
> 00000000
>        00000000 00000001 00000000 e0a5af20 d8277420 d83ec180 420ac6a0
> 00000050
> Call Trace:   [<e0a40cc9>] i2c_smbus_xfer_R935cccc0 [i2c-core] 0x89
> (0xd82a3ea4)
> )
> [<e0a5af20>] smbus_algorithm [i2c-nforce2] 0x0 (0xd82a3ec4))
> [<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3ef0))
> [<e0a5c5af>] i2cdev_ioctl [i2c-dev] 0x463 (0xd82a3ef4))
> [<c01186c0>] schedule [kernel] 0x170 (0xd82a3f40))
> [<c01254d7>] schedule_timeout [kernel] 0x67 (0xd82a3f64))
> [<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3f90))
> [<c0153d4c>] sys_ioctl [kernel] 0xbc (0xd82a3f94))
> [<c010939f>] system_call [kernel] 0x33 (0xd82a3fc0))
> 
> Code: 8a 07 8d 53 04 ee e6 80 83 ce 04 e9 a3 fe ff ff 8b 9d f0 00
> 
> -----Original Message-----
> From: Mark Studebaker [mailto:mds@paradyne.com]
> Sent: Wednesday, November 26, 2003 3:41 PM
> To: sensors@Stimpy.netroedge.com
> Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> does dmesg have anything about a module going oops?
> 
> Jean Delvare wrote:
> 
> >>>[root@workstation1 cvs2]# i2cdump 1 50 c
> >>>  WARNING! This program can confuse your I2C bus, cause data loss
> >>>  and worse! I will probe file /dev/i2c-1, address 0x32, mode byte
> >>>  consecutive read You have five seconds to reconsider and press
> >>>  CTRL-C!
> >>>
> >>>Segmentation fault
> >
> >
> > Still this needs fixing. Mark, any idea about that? Could it be caused
> > by the i2c-nforce2 driver? Doing the same here (i2c-i801) exits cleanly:
> > Error: Write start address failed, return code -1
> >

unknown eeprom type (65) [ticket #1449]

[Fernando Rocha Durso]

I don't know if you received this...

I?ve downloaded i2c and lm-sensors from CVS patched a new "fresh" kernel
source, compiled it and installed i2c and sensors, after i?ve ran
sensors-detect, then rebooted and typed sensors... it worked!

Hope it's usefull...

here?s my output:
 
fernando@athlon:~$ sensors
eeprom-i2c-0-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Unknown EEPROM type (65)
w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.63 V  (min =  +1.57 V, max =  +1.73 V)
VCore 2:   +1.71 V  (min =  +1.57 V, max =  +1.73 V)       ALARM
+3.3V:     +3.28 V  (min =  +3.14 V, max =  +3.46 V)
+5V:       +5.01 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +12.08 V  (min = +10.83 V, max = +13.19 V)
-12V:     -11.93 V  (min = -13.16 V, max = -10.90 V)
-5V:       -5.14 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.54 V  (min =  +4.74 V, max =  +5.24 V)
VBat:      +2.98 V  (min =  +2.40 V, max =  +3.60 V)
fan1:        0 RPM  (min = 14062 RPM, div = 2)
fan2:     3609 RPM  (min = 112500 RPM, div = 2)
fan3:        0 RPM  (min = 2481 RPM, div = 4)
temp1:       +41?C  (high =   +99?C, hyst =    +1?C)   sensor thermistor      
temp2:     +45.0?C  (high =  +120?C, hyst =  +115?C)   sensor thermistor      
temp3:     +33.0?C  (high =  +120?C, hyst =  +115?C)   sensor thermistor      
vid:      +1.650 V
alarms:
beep_enable:
          Sound alarm disabled

root@athlon:~# lsmod
Module                  Size  Used by    Not tainted
ppp_synctty             6304   0  (unused)
ppp_async               7680   1
ppp_generic            15996   3  [ppp_synctty ppp_async]
slhc                    5392   0  [ppp_generic]
w83781d                20432   0  (unused)
eeprom                  4496   0  (unused)
i2c-proc                6548   0  [w83781d eeprom]
i2c-isa                  748   0  (unused)
i2c-nforce2             3368   0  (unused)
i2c-core               14660   0  [w83781d eeprom i2c-proc i2c-isa
i2c-nforce2]
parport_pc             15684   1  (autoclean)
lp                      6784   0  (autoclean)
parport                24992   1  (autoclean) [parport_pc lp]
ipt_REJECT              3512   4  (autoclean)
iptable_filter          1740   1  (autoclean)
ip_tables              15136   2  [ipt_REJECT iptable_filter]
printer                 7392   0
usb-ohci               19016   0  (unused)
ehci-hcd               17544   0  (unused)
usbcore                62016   1  [printer usb-ohci ehci-hcd]
8139too                16200   1
mii                     2496   0  [8139too]
crc32                   2848   0  [8139too]
ide-scsi               10224   0
agpgart                41688   0  (unused)
apm                    10024   1

root@athlon:~# cat /proc/sys/dev/sensors/eeprom-i2c-0-51/*
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0
67 67 65 84 51 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 2 0 0 34 0

root@athlon:~# wich sensors
-su: wich: command not found
root@athlon:~# ldd $(wich sensors)
-su: wich: command not found
ldd: missing file arguments

 
root@athlon:~# ls -l /usr/local/lib/libsensors.*
-rw-r--r--    1 root     root       146396 2003-11-26 13:48
/usr/local/lib/libsensors.a
lrwxrwxrwx    1 root     root           15 2003-11-26 13:48
/usr/local/lib/libsensors.so -> libsensors.so.3
lrwxrwxrwx    1 root     root           19 2003-11-25 22:45
/usr/local/lib/libsensors.so.2 -> libsensors.so.2.0.1
-rw-r--r--    1 root     root       117212 2003-11-25 22:45
/usr/local/lib/libsensors.so.2.0.1
lrwxrwxrwx    1 root     root           19 2003-11-26 13:48
/usr/local/lib/libsensors.so.3 -> libsensors.so.3.0.0
-rw-r--r--    1 root     root       144065 2003-11-26 13:48
/usr/local/lib/libsensors.so.3.0.0

root@athlon:~# ls -l /usr/lib/libsensors.*
/usr/bin/ls: /usr/lib/libsensors.*: Arquivo ou diret?rio n?o encontrado

dmesg:
 
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<7>Starting device update
Starting eeprom update, slice 0
eeprom.o: 0x51 EEPROM contents (row 1): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 2): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 1
eeprom.o: 0x51 EEPROM contents (row 3): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 4): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 2
eeprom.o: 0x51 EEPROM contents (row 5): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 6): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 3
eeprom.o: 0x51 EEPROM contents (row 7): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 8): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 4
eeprom.o: 0x51 EEPROM contents (row 9): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 10): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 5
eeprom.o: 0x51 EEPROM contents (row 11): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 12): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 6
eeprom.o: 0x51 EEPROM contents (row 13): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 14): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00
Starting eeprom update, slice 7
eeprom.o: 0x51 EEPROM contents (row 15): 0x43 0x43 0x41 0x54 0x33 0x00
0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
eeprom.o: 0x51 EEPROM contents (row 16): 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x22 0x00

thanks

unknown eeprom type (65) [ticket #1449]

[Jean Delvare]

> I don't know if you received this...

Now we do, but not before, if that was your question.

> I've downloaded i2c and lm-sensors from CVS patched a new "fresh"
> kernel source, compiled it and installed i2c and sensors, after i've
> ran sensors-detect, then rebooted and typed sensors... it worked!

Great :)

> fernando@athlon:~$ sensors
> eeprom-i2c-0-51
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (65)

That problem is still there.

Could you please ensure you have the change Mark made, that is supposed
to fix it? In lm_sensors2, type "cvs status
kernel/busses/i2c-nforce2.c". If it says version 1.6, you don't have the
fix. Please do "cvs update", recompile, reinstall and recycle modules
and try again. If it says version 1.7, this means that Mark's fix did
not work.

> root@athlon:~# wich sensors
> -su: wich: command not found
> root@athlon:~# ldd $(wich sensors)
> -su: wich: command not found
> ldd: missing file arguments

This is "which", not "wich" (this is why the commands are failing). But
we don't need that information anymore anyway.

Thanks for your help.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

unknown eeprom type (65) [ticket #1449]

[Fernando Durso]

Jean, you were right, my lm-sensors was using the 1.6 version of i2c-nforce2.c, so i did what you asked anda now here is my output of sensors:
 
root@athlon:/usr/src/teste/cvs/lm_sensors2# sensors
eeprom-i2c-0-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM
Memory size (MB):       256
w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.60 V  (min =  +1.57 V, max =  +1.73 V)
VCore 2:   +1.68 V  (min =  +1.57 V, max =  +1.73 V)
+3.3V:     +3.26 V  (min =  +3.14 V, max =  +3.46 V)
+5V:       +5.01 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +12.05 V  (min = +10.83 V, max = +13.19 V)
-12V:     -11.93 V  (min = -13.16 V, max = -10.90 V)
-5V:       -5.14 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.51 V  (min =  +4.74 V, max =  +5.24 V)
VBat:      +2.98 V  (min =  +2.40 V, max =  +3.60 V)
fan1:        0 RPM  (min = 14062 RPM, div = 2)
fan2:     3609 RPM  (min = 112500 RPM, div = 2)              ALARM
fan3:        0 RPM  (min = 1687 RPM, div = 4)              ALARM
temp1:       +36?C  (high =   +99?C, hyst =    +1?C)   sensor = thermistor      
temp2:     +41.5?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor      
temp3:     +32.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor      
vid:      +1.650 V
alarms:
beep_enable:
          Sound alarm disabled

Now it?s "realy" okay :-) isn?t it?
 
Thanks.

Jean Delvare <khali@linux-fr.org> wrote:
> I don't know if you received this...

Now we do, but not before, if that was your question.

> I've downloaded i2c and lm-sensors from CVS patched a new "fresh"
> kernel source, compiled it and installed i2c and sensors, after i've
> ran sensors-detect, then rebooted and typed sensors... it worked!

Great :)

> fernando@athlon:~$ sensors
> eeprom-i2c-0-51
> Adapter: SMBus nForce2 adapter at 5000
> Algorithm: Non-I2C SMBus adapter
> Unknown EEPROM type (65)

That problem is still there.

Could you please ensure you have the change Mark made, that is supposed
to fix it? In lm_sensors2, type "cvs status
kernel/busses/i2c-nforce2.c". If it says version 1.6, you don't have the
fix. Please do "cvs update", recompile, reinstall and recycle modules
and try again. If it says version 1.7, this means that Mark's fix did
not work.

> root@athlon:~# wich sensors
> -su: wich: command not found
> root@athlon:~# ldd $(wich sensors)
> -su: wich: command not found
> ldd: missing file arguments

This is "which", not "wich" (this is why the commands are failing). But
we don't need that information anymore anyway.

Thanks for your help.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/


---------------------------------
Yahoo! Mail - 6MB, anti-spam e antiv?rus gratuito. Crie sua conta agora!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031128/582907a9/attachment.html

unknown eeprom type (65) [ticket #1449]

[McClintock William J Contr MCOM]

Looks good to me...thanks...

[root@workstation1 lm_sensors2]# cvs status kernel/busses/i2c-nforce2.c
=================================File: i2c-nforce2.c     Status: Up-to-date

   Working revision:    1.7
   Repository revision: 1.7
/home/cvs/lm_sensors2/kernel/busses/i2c-nforce2.
c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

[root@workstation1 lm_sensors2]# sensors
w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.62 V  (min =  +1.57 V, max =  +1.73 V)
VCore 2:   +1.63 V  (min =  +1.57 V, max =  +1.73 V)
+3.3V:     +3.23 V  (min =  +3.14 V, max =  +3.46 V)
+5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +11.78 V  (min = +10.83 V, max = +13.19 V)
-12V:     -11.47 V  (min = -13.16 V, max = -10.90 V)
-5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.41 V  (min =  +4.74 V, max =  +5.24 V)
VBat:      +0.62 V  (min =  +2.40 V, max =  +3.60 V)
fan1:     5075 RPM  (min = 2678 RPM, div = 2)
fan2:     5273 RPM  (min = 6887 RPM, div = 2)
fan3:        0 RPM  (min = 2280 RPM, div = 4)
temp1:       +23?C  (high =   +34?C, hyst =   +91?C)   sensor = thermistor

temp2:     +30.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor

temp3:     +25.0?C  (high =  +120?C, hyst =  +115?C)   sensor = thermistor

vid:      +1.650 V
alarms:
beep_enable:
          Sound alarm disabled

eeprom-i2c-1-50
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM
Memory size (MB):       256

eeprom-i2c-1-51
Adapter: SMBus nForce2 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM
Memory size (MB):       256

[root@workstation1 lm_sensors2]# lsmod | head
Module                  Size  Used by    Tainted: P
i2c-nforce2             4040   0  (unused)
eeprom                  5040   0  (unused)
w83781d                21744   0  (unused)
i2c-proc                7988   0  [eeprom w83781d]
i2c-isa                 1292   0  (unused)
i2c-core               19556   0  [i2c-nforce2 eeprom w83781d i2c-proc
i2c-isa]
nvaudio                39732   0  (unused)
ac97_codec             14536   0  [nvaudio]
soundcore               6468   2  [nvaudio]
[root@workstation1 lm_sensors2]#

-----Original Message-----
From: Mark Studebaker [mailto:mds@paradyne.com]
Sent: Wednesday, November 26, 2003 7:13 PM
To: McClintock William J Contr MCOM
Cc: sensors@Stimpy.netroedge.com; frdurso@yahoo.com.br; Hans-Frieder
Vogt
Subject: Re: unknown eeprom type (65) [ticket #1449]


I found and fixed what looked like the problem in i2c-nforce
that the eeprom module was seeing with byte writes.
It was writing the wrong data to the wrong place.
Can't say for sure because I don't have a datasheet.
Doubt that this was the cause of the oopses so there may be something
else going on too.
For those of you testing, if the old i2c-nforce won't rmmod you
will have to reboot. 


McClintock William J Contr MCOM wrote:
> 
> i2c-core.o: i2c core module version 2.8.1 (20031005)
> i2c-isa.o version 2.8.1 (20031005)
> i2c-proc.o version 2.8.1 (20031005)
> w83781d.o version 2.8.1 (20031005)
> eeprom.o version 2.8.1 (20031005)
> i2c-nforce2.o version 2.8.1 (20031005)
> i2c-nforce2.o: nForce2 SMBus adapter at 0x5000
> i2c-nforce2.o: nForce2 SMBus adapter at 0x5040
> i2c-dev.o: i2c /dev entries driver module version 2.8.1 (20031005)
> i2c-dev.o: Registered 'ISA main adapter' as minor 0
> i2c-dev.o: Registered 'SMBus nForce2 adapter at 5000' as minor 1
> i2c-dev.o: Registered 'SMBus nForce2 adapter at 5040' as minor 2
> Unable to handle kernel NULL pointer dereference at virtual address
00000000
>  printing eip:
> e0a5a216
> *pde = 00000000
> Oops: 0000
> i2c-dev i2c-nforce2 eeprom w83781d i2c-proc i2c-isa i2c-core nvaudio
> ac97_codec
> soundcore parport_pc lp parport iptable_filter ip_tables autofs nfs lockd
> sunr
> CPU:    0
> EIP:    0060:[<e0a5a216>]    Tainted: P
> EFLAGS: 00010246
> 
> EIP is at nforce2_access [i2c-nforce2] 0x1b6 (2.4.20-13.9)
> eax: 00000000   ebx: 00005000   ecx: c17baa00   edx: 00000001
> esi: c17baa00   edi: 00000000   ebp: c17baa00   esp: d82a3e78
> ds: 0068   es: 0068   ss: 0068
> Process i2cdump (pid: 3542, stackpageØ2a3000)
> Stack: d82cd340 dffd2400 00000296 c25a6bb8 dffd2400 003462b0 00500000
> c17baa40
>        00000000 00000001 c17baa04 e0a40cc9 c17baa04 00000050 00000000
> 00000000
>        00000000 00000001 00000000 e0a5af20 d8277420 d83ec180 420ac6a0
> 00000050
> Call Trace:   [<e0a40cc9>] i2c_smbus_xfer_R935cccc0 [i2c-core] 0x89
> (0xd82a3ea4)
> )
> [<e0a5af20>] smbus_algorithm [i2c-nforce2] 0x0 (0xd82a3ec4))
> [<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3ef0))
> [<e0a5c5af>] i2cdev_ioctl [i2c-dev] 0x463 (0xd82a3ef4))
> [<c01186c0>] schedule [kernel] 0x170 (0xd82a3f40))
> [<c01254d7>] schedule_timeout [kernel] 0x67 (0xd82a3f64))
> [<e0a5c14c>] i2cdev_ioctl [i2c-dev] 0x0 (0xd82a3f90))
> [<c0153d4c>] sys_ioctl [kernel] 0xbc (0xd82a3f94))
> [<c010939f>] system_call [kernel] 0x33 (0xd82a3fc0))
> 
> Code: 8a 07 8d 53 04 ee e6 80 83 ce 04 e9 a3 fe ff ff 8b 9d f0 00
> 
> -----Original Message-----
> From: Mark Studebaker [mailto:mds@paradyne.com]
> Sent: Wednesday, November 26, 2003 3:41 PM
> To: sensors@Stimpy.netroedge.com
> Cc: william.mcclintock@schriever.af.mil; frdurso@yahoo.com.br
> Subject: Re: unknown eeprom type (65) [ticket #1449]
> 
> does dmesg have anything about a module going oops?
> 
> Jean Delvare wrote:
> 
> >>>[root@workstation1 cvs2]# i2cdump 1 50 c
> >>>  WARNING! This program can confuse your I2C bus, cause data loss
> >>>  and worse! I will probe file /dev/i2c-1, address 0x32, mode byte
> >>>  consecutive read You have five seconds to reconsider and press
> >>>  CTRL-C!
> >>>
> >>>Segmentation fault
> >
> >
> > Still this needs fixing. Mark, any idea about that? Could it be caused
> > by the i2c-nforce2 driver? Doing the same here (i2c-i801) exits cleanly:
> > Error: Write start address failed, return code -1
> >