* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
@ 2005-05-19 6:24 ` Fernando Durso
2005-05-19 6:24 ` Jean Delvare
` (28 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Fernando Durso @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
2005-05-19 6:24 ` Fernando Durso
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
` (27 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
2005-05-19 6:24 ` Fernando Durso
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Mark Studebaker
` (26 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (2 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Mark Studebaker
` (25 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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...
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (3 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Jean Delvare
` (24 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (4 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (23 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (5 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Jean Delvare
` (22 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (6 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (21 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> > 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (7 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (20 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (8 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Fernando Rocha Durso
` (19 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (9 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Fernando Rocha Durso
2005-05-19 6:24 ` Jean Delvare
` (18 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Fernando Rocha Durso @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (10 preceding siblings ...)
2005-05-19 6:24 ` Fernando Rocha Durso
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
` (17 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (11 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Mark Studebaker
` (16 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (12 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Mark Studebaker
` (15 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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?
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (13 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Mark Studebaker
` (14 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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...
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (14 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Fernando Rocha Durso
` (13 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (15 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` Fernando Rocha Durso
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (12 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Fernando Rocha Durso @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (16 preceding siblings ...)
2005-05-19 6:24 ` Fernando Rocha Durso
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Jean Delvare
` (11 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (17 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (10 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (18 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Mark Studebaker
` (9 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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?
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (19 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (8 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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?
>>
>
>
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (20 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Mark Studebaker
` (7 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
> >
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (21 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (6 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (22 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Fernando Rocha Durso
` (5 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (23 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Fernando Rocha Durso
2005-05-19 6:24 ` Fernando Durso
` (4 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Fernando Rocha Durso @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (24 preceding siblings ...)
2005-05-19 6:24 ` Fernando Rocha Durso
@ 2005-05-19 6:24 ` Fernando Durso
2005-05-19 6:24 ` Mark Studebaker
` (3 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Fernando Durso @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (25 preceding siblings ...)
2005-05-19 6:24 ` Fernando Durso
@ 2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` McClintock William J Contr MCOM
` (2 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: Mark Studebaker @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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
> >
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (26 preceding siblings ...)
2005-05-19 6:24 ` Mark Studebaker
@ 2005-05-19 6:24 ` McClintock William J Contr MCOM
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
29 siblings, 0 replies; 31+ messages in thread
From: McClintock William J Contr MCOM @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
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?
>>
>
>
>
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (27 preceding siblings ...)
2005-05-19 6:24 ` McClintock William J Contr MCOM
@ 2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> > [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/
^ permalink raw reply [flat|nested] 31+ messages in thread* unknown eeprom type (65) [ticket #1449]
2005-05-19 6:24 unknown eeprom type (65) [ticket #1449] Fernando Rocha Durso
` (28 preceding siblings ...)
2005-05-19 6:24 ` Jean Delvare
@ 2005-05-19 6:24 ` Jean Delvare
29 siblings, 0 replies; 31+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 UTC (permalink / raw)
To: lm-sensors
> 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/
^ permalink raw reply [flat|nested] 31+ messages in thread