From: jason.craig@gmail.com (Jason Craig)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] ticket #1986, occasional bad data from lm85
Date: Mon, 16 Oct 2006 13:28:14 +0000 [thread overview]
Message-ID: <453388EE.1090907@gmail.com> (raw)
Hi,
Issue 1986 was put on the backburner for awhile, but I am now looking into it
again. I have done what Khali suggested as far as running i2cdetect and
i2cdump. I have some results that may or may not be normal and I was hoping
someone could help me. The hardware is the same, Radisys LS855 motherboard. I
have lm_sensors 2.9.2 with libsensors 2.9.2 now. The linux kernel version is
2.4.31.
The *new* problem, which I assume is related to the previous one mentioned in
ticket 2038 is described here. Assume the system has just booted.
# lsmod
Module Size Used by Not tainted
i2c-dev 3808 0 (unused)
e1000 67564 0 (unused)
e100 47832 1
rtc 6012 0 (autoclean)
eeprom 3656 0 (unused)
lm85 17032 0 (unused)
i2c-proc 6020 0 [eeprom lm85]
i2c-i801 4632 0 (unused)
i2c-core 14852 0 [i2c-dev eeprom lm85 i2c-proc i2c-i801]
apm 9096 1
If I run i2cdetect, I get the following output:
# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: XX XX XX XX XX 08 XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX
30: 30 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX 44 XX XX XX XX XX XX XX XX XX XX XX
50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX
>/From what I understand, this means that there are I2C devices at the following
/addresses:
0x08 0x2e 0x30 0x44 0x50 0x69
I seem to be able to run i2cdump for all of these addresses except 0x69, which
from what I gathered from the I2C tools page
(http://netroedge.com/~lm78/i2ctools.html <http://netroedge.com/%7Elm78/i2ctools.html>) seems to be a clock chip.
Here is the output I get for this address.
# i2cdump -y 0 0x69 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ????????????????
10: 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ????????????????
20: 0f 1f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ????????????????
30: 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ????????????????
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
Basically, the first 4 lines of output are output as normal with a slight delay
between echos, but then there is a short pause, and the rest of the lines are
output immediately with no delay. Subsequent i2cdump commands generate the
following output immediately (no delay like before for the first 4 lines).
# i2cdump -y 0 0x69 b
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
I am assuming that I am hosing some hardware registers each time I try to dump
this clock chip. Maybe I shouldn't be trying to do that?? I'm not exactly
sure. The i2cdumps behave the same way until I reboot the system. I've tried
removing the modules from the kernel and then installing them again, but the
problem? remains.
Furthermore, subsequent i2cdetect commands give the following output:
# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX
Which shows that I don't have the same addresses as before.
Thanks for any suggestions.
-Jason
next reply other threads:[~2006-10-16 13:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-16 13:28 Jason Craig [this message]
2006-10-16 20:53 ` [lm-sensors] ticket #1986, occasional bad data from lm85 Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453388EE.1090907@gmail.com \
--to=jason.craig@gmail.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.