I2C crash - ADM1021

I2C crash - ADM1021

[Peter Hyman]

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030918/a9b12c1b/attachment.bin

I2C crash - ADM1021

[Jean Delvare]

> Hi, and thanks for all your work on lm sensors and i2c!
> I am running Mandrake Linux 9.1 with a lot of Cooker additions. 
> Mandrake's Kernel 2.4.21-0.13 with Win4Lin hook.

What's that Win4Lin thing?

> My system is a homemade one with a Soyo SY-Kt400 (Dragon Ultra Black)
> with Phoenix Bios updated as of April 2003 with an AMD XP 2000 CPU.
> 
> I compiled and successfully installed the CVS versions of I2C and
> lm_sensors2.
> 
> After performing sensors-detect, On MY system, the loading of the
> driver ADM1021 causes a catostrophic system failure which requires a
> complete restore of the hard drive partition that Linux is on.  In the
> sensors-detect messages, it DOES say that this driver can cause
> problems.

Well, I am really sorry for you. We are doing our best to prevent these
problems, but it turns out that the I2C/SMBus operations are risky on a
few systems, and there's almost nothing we can do against that, apart
from plain stopping the project.

> After some thinking and many system restores, I removed the ADM1021
> driver modprobe line in rc.local, and the corresponding line in
> modules.conf and the sensors program seems to run fine.  I get both
> the die temperature of the CPU accurately and the system temperature
> also(which is all I am interested in).
> 
> I am attaching 3 files for you to review.
> 1) sensors-output.txt which shows my system info -- alarms and all
> (which I ignore) from the sensors program
> 2) sensors-detect-output.txt which shows your program's analysis of my
> system
> 3) i2cdetect-i2cdump-output.txt which shows the I2C dumps of devices
> uncovered by your program.
> 
> Of course, there is no I2C support in my kernel, and as I mentioned,
> the sensors output runs rine.
> 
> Best wishes, and thank you for your efforts.  If I can help clarify
> anything, or provide you with additional details, please let me know!

Thanks a lot for taking the time to report (and not even complain about
what happened to you).

There are a few comments and questions that come to me after reading the
files you attached.

Although I don't know which chipset is at 0x18, I remember that we had a
similar dump reported a few days ago.

The chip at 0x4c is doubtlessly a LM90, and is detected as such (BTW,
note that you need the latest CVS for it to refresh correctly).

No idea what could be at 0x4e, but it is neither a LM75 nor a ADM1021
clone, sensors-detect is obviously wrong here. So you can remove lm75
from your module list.

At 0x52 you have a SPD EEPROM, also detected OK by sensors-detect.

At 0x69, this must be a clock ship that we usually advise not to play
with ;)

Now, for the adm1021 problems, I'm puzzled. The option line in
/etc/sensors.conf, as suggested by sensors-detect, prevents the driver
from using any of the three addresses at which you have chipsets (0x18,
0x4c, 0x4e) so loading it shouldn't have had any effect. But, since it
was crashing your system, it must have been doing something. What, that
I can't understand. Do you have any log that survived the crashes so
that we could try understanding what happened?

Again, thanks for reporting.

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

I2C crash - ADM1021

[Peter Hyman]

Hi Jean!  Thank you for the reply.  Please understand that I was not
complaining.  I was just reporting a problem I had in the hope that it
will help others.  It just took awhile for me to figure it out and I
found it very curious!

I'm going to answer all your questions.

On Thu, 2003-09-18 at 17:07, Jean Delvare wrote:

> What's that Win4Lin thing?
A program that allows a true windows system to run inside of Linux under
X.  Similar to VMWare except I can cut and paste between Windows and
Linux, and it is much less of a system hog.  I still do some work in
Windows :(!  http://www.netraverse.com if you're interested.
> 

> Well, I am really sorry for you. We are doing our best to prevent these
> problems, but it turns out that the I2C/SMBus operations are risky on a
> few systems, and there's almost nothing we can do against that, apart
> from plain stopping the project.

Oh, don't do that!  I am not sorry, I enjoy learning.  What got me going
was the line that adm1021 COULD cause problems.  I wanted to know WHAT!
> 
> Thanks a lot for taking the time to report (and not even complain about
> what happened to you).
> 
> There are a few comments and questions that come to me after reading the
> files you attached.
> 
> Although I don't know which chipset is at 0x18, I remember that we had a
> similar dump reported a few days ago.
> 
> The chip at 0x4c is doubtlessly a LM90, and is detected as such (BTW,
> note that you need the latest CVS for it to refresh correctly).
Yes, I have the latest CVS
> 
> No idea what could be at 0x4e, but it is neither a LM75 nor a ADM1021
> clone, sensors-detect is obviously wrong here. So you can remove lm75
> from your module list.
> 
> At 0x52 you have a SPD EEPROM, also detected OK by sensors-detect.
> 
> At 0x69, this must be a clock ship that we usually advise not to play
> with ;)
> 
> Now, for the adm1021 problems, I'm puzzled. The option line in
> /etc/sensors.conf, as suggested by sensors-detect, prevents the driver
> from using any of the three addresses at which you have chipsets (0x18,
> 0x4c, 0x4e) so loading it shouldn't have had any effect. But, since it
> was crashing your system, it must have been doing something. What, that
> I can't understand. Do you have any log that survived the crashes so
> that we could try understanding what happened?
> 
No, nothing survived.  As soon as modprobe adm1021 is executed, the
system goes dead, and worse, the hard disk gets corrupted so that when
fsck runs on reboot, Linux cannot even boot -- all the inode tables are
trashed.  The only possible thing I was thinking was that in my kernel
config file, while no modules are loaded, there is one line that is
strange.

CONFIG_I2C_MAINBOARD=y

is the only thing checked off.  I think this is just to allow the kernel
to create modules, not actually install anything.

> Again, thanks for reporting.

If I can help narrow it down more, I will let you know.  Best wishes!
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030918/dee440c7/attachment.bin

I2C crash - ADM1021

[Jean Delvare]

> > Now, for the adm1021 problems, I'm puzzled. The option line in
> > /etc/sensors.conf, as suggested by sensors-detect, prevents the
> > driver from using any of the three addresses at which you have
> > chipsets (0x18, 0x4c, 0x4e) so loading it shouldn't have had any
> > effect.

Now that I come to think of it again, one question: did you actually
edit /etc/modules.conf as sensors-detect told you? Having failed to do
so would explain (but not forgive) how adm1021 could cause trouble on
your system.

> The only possible thing I was thinking was that in my
> kernel config file, while no modules are loaded, there is one line
> that is strange.
> 
> CONFIG_I2C_MAINBOARD=y

I never saw that option anywhere. Grep'ing linux 2.4.22 sources for it
did not return anything. Could it be some Mandrake add-on?

> is the only thing checked off.

You mean checked *on*?

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

I2C crash - ADM1021

[Peter Hyman]

On Fri, 2003-09-19 at 14:00, Jean Delvare wrote:
> > > Now, for the adm1021 problems, I'm puzzled. The option line in
> > > /etc/sensors.conf, as suggested by sensors-detect, prevents the
> > > driver from using any of the three addresses at which you have
> > > chipsets (0x18, 0x4c, 0x4e) so loading it shouldn't have had any
> > > effect.
> 
> Now that I come to think of it again, one question: did you actually
> edit /etc/modules.conf as sensors-detect told you? Having failed to do
> so would explain (but not forgive) how adm1021 could cause trouble on
> your system.
> 
Yes, I edited modules.conf exactly as suggested with the exclusions for
adm1021 listed.

> > The only possible thing I was thinking was that in my
> > kernel config file, while no modules are loaded, there is one line
> > that is strange.
> > 
> > CONFIG_I2C_MAINBOARD=y
> 
> I never saw that option anywhere. Grep'ing linux 2.4.22 sources for it
> did not return anything. Could it be some Mandrake add-on?
> 
> > is the only thing checked off.
> 
> You mean checked *on*?
Yes, sorry.Selected.  As I said, I think that is for a submenu to allow
for selecting modules for compilation or to be built in the kernel. 
Saying N above would skip all the choices if using xconfig or menuconfig
to edit .config.  I don't think it's a driver, but simply a group
selector.

As I said, I am happy it works, but the failure of adm1021 remains a
mystery!

Cheers!
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030919/f5476c20/attachment.bin

I2C crash - ADM1021

[Peter Hyman]

Well, FWIW, removing the driver from loading still gives me valid info
from the it87 and lm90 that match the sensor readings from the mobo
bios.  I can only assume that the implementation of the chip on my mobo
is non-standard or incorrect.  Nonetheless, the reaction was SEVERE!  I
felt it was worth reporting if for no other reason than to spare others
what occurred with me.  Not to worry, I was fully backed up, so all I
lost was a little time!!!!!

Thanks for writing back.

On Fri, 2003-10-03 at 07:22, Mark Studebaker wrote:
> this could simply be from chip reset or limit setting by the driver
> at initialization. This causes an ALERT output from the chip
> which the BIOS interprets as an overtemp and shuts the
> system down immediately.
> 
> (another reason for init=0 being the default)
> 
> But if the option line prevents the driver from accessing
> the chip at all, then this isn't the problem...
> 
> Peter Hyman wrote:
> > 
> > On Fri, 2003-09-19 at 14:00, Jean Delvare wrote:
> > > > > Now, for the adm1021 problems, I'm puzzled. The option line in
> > > > > /etc/sensors.conf, as suggested by sensors-detect, prevents the
> > > > > driver from using any of the three addresses at which you have
> > > > > chipsets (0x18, 0x4c, 0x4e) so loading it shouldn't have had any
> > > > > effect.
> > >
> > > Now that I come to think of it again, one question: did you actually
> > > edit /etc/modules.conf as sensors-detect told you? Having failed to do
> > > so would explain (but not forgive) how adm1021 could cause trouble on
> > > your system.
> > >
> > Yes, I edited modules.conf exactly as suggested with the exclusions for
> > adm1021 listed.
> > 
> > > > The only possible thing I was thinking was that in my
> > > > kernel config file, while no modules are loaded, there is one line
> > > > that is strange.
> > > >
> > > > CONFIG_I2C_MAINBOARD=y
> > >
> > > I never saw that option anywhere. Grep'ing linux 2.4.22 sources for it
> > > did not return anything. Could it be some Mandrake add-on?
> > >
> > > > is the only thing checked off.
> > >
> > > You mean checked *on*?
> > Yes, sorry.Selected.  As I said, I think that is for a submenu to allow
> > for selecting modules for compilation or to be built in the kernel.
> > Saying N above would skip all the choices if using xconfig or menuconfig
> > to edit .config.  I don't think it's a driver, but simply a group
> > selector.
> > 
> > As I said, I am happy it works, but the failure of adm1021 remains a
> > mystery!
> > 
> > Cheers!
> > --
> > Peter Hyman
> > Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
> > Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
> > 
> > 
> >                        Name: signature.asc
> >    signature.asc       Type: application/pgp-signature
> >                 Description: This is a digitally signed message part
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031003/f5a2e2d5/attachment.bin

I2C crash - ADM1021

[Peter Hyman]

Just a quick FYI update.

Today, I updated all source for I2C and lmsensors from CVS.  When
running sensors-detect, it had slightly different settings for the
OPTIONS line in modules.conf for the adm1021 driver.

Previously, the line read
options adm1021 ignore=0,0x18,0,0x4c

Now, the instructions correctly show
options adm1021 ignore=0,0x4c,0,0x4e

The difference being that the driver was polling a port it had no
business doing and I believe this is what caused my system to crash!

Now, the irony is that the information from port 0x18 is totally useless
as it shows system and cpu temperature at -41C!

/sbin/modprobe adm1021 ignore=0,0x4c,0,0x4e

sensors
----------------
lm84-i2c-0-18
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Non-I2C SMBus adapter
Board:       -41?C  (low =   -1?C, high =  -17?C)
CPU:         -41?C  (low =  +60?C, high =   -1?C)

But thank you anyway for making that minor correction!  I hope it was
only me that had the disk trashing trouble!

One interesting note is that when rebooting, I had to completely do a
cold start.

Let me know if I can provide you with any additional detail.

On Fri, 2003-10-03 at 07:22, Mark Studebaker wrote:
> this could simply be from chip reset or limit setting by the driver
> at initialization. This causes an ALERT output from the chip
> which the BIOS interprets as an overtemp and shuts the
> system down immediately.
> 
> (another reason for init=0 being the default)
> 
> But if the option line prevents the driver from accessing
> the chip at all, then this isn't the problem...
> 
> Peter Hyman wrote:
> > 
> > On Fri, 2003-09-19 at 14:00, Jean Delvare wrote:
> > > > > Now, for the adm1021 problems, I'm puzzled. The option line in
> > > > > /etc/sensors.conf, as suggested by sensors-detect, prevents the
> > > > > driver from using any of the three addresses at which you have
> > > > > chipsets (0x18, 0x4c, 0x4e) so loading it shouldn't have had any
> > > > > effect.
> > >
> > > Now that I come to think of it again, one question: did you actually
> > > edit /etc/modules.conf as sensors-detect told you? Having failed to do
> > > so would explain (but not forgive) how adm1021 could cause trouble on
> > > your system.
> > >
> > Yes, I edited modules.conf exactly as suggested with the exclusions for
> > adm1021 listed.
> > 
> > > > The only possible thing I was thinking was that in my
> > > > kernel config file, while no modules are loaded, there is one line
> > > > that is strange.
> > > >
> > > > CONFIG_I2C_MAINBOARD=y
> > >
> > > I never saw that option anywhere. Grep'ing linux 2.4.22 sources for it
> > > did not return anything. Could it be some Mandrake add-on?
> > >
> > > > is the only thing checked off.
> > >
> > > You mean checked *on*?
> > Yes, sorry.Selected.  As I said, I think that is for a submenu to allow
> > for selecting modules for compilation or to be built in the kernel.
> > Saying N above would skip all the choices if using xconfig or menuconfig
> > to edit .config.  I don't think it's a driver, but simply a group
> > selector.
> > 
> > As I said, I am happy it works, but the failure of adm1021 remains a
> > mystery!
> > 
> > Cheers!
> > --
> > Peter Hyman
> > Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
> > Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
> > 
> > 
> >                        Name: signature.asc
> >    signature.asc       Type: application/pgp-signature
> >                 Description: This is a digitally signed message part
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031009/482965b1/attachment.bin

I2C crash - ADM1021

[Mark Studebaker]

this could simply be from chip reset or limit setting by the driver
at initialization. This causes an ALERT output from the chip
which the BIOS interprets as an overtemp and shuts the
system down immediately.

(another reason for init=0 being the default)

But if the option line prevents the driver from accessing
the chip at all, then this isn't the problem...

Peter Hyman wrote:
> 
> On Fri, 2003-09-19 at 14:00, Jean Delvare wrote:
> > > > Now, for the adm1021 problems, I'm puzzled. The option line in
> > > > /etc/sensors.conf, as suggested by sensors-detect, prevents the
> > > > driver from using any of the three addresses at which you have
> > > > chipsets (0x18, 0x4c, 0x4e) so loading it shouldn't have had any
> > > > effect.
> >
> > Now that I come to think of it again, one question: did you actually
> > edit /etc/modules.conf as sensors-detect told you? Having failed to do
> > so would explain (but not forgive) how adm1021 could cause trouble on
> > your system.
> >
> Yes, I edited modules.conf exactly as suggested with the exclusions for
> adm1021 listed.
> 
> > > The only possible thing I was thinking was that in my
> > > kernel config file, while no modules are loaded, there is one line
> > > that is strange.
> > >
> > > CONFIG_I2C_MAINBOARD=y
> >
> > I never saw that option anywhere. Grep'ing linux 2.4.22 sources for it
> > did not return anything. Could it be some Mandrake add-on?
> >
> > > is the only thing checked off.
> >
> > You mean checked *on*?
> Yes, sorry.Selected.  As I said, I think that is for a submenu to allow
> for selecting modules for compilation or to be built in the kernel.
> Saying N above would skip all the choices if using xconfig or menuconfig
> to edit .config.  I don't think it's a driver, but simply a group
> selector.
> 
> As I said, I am happy it works, but the failure of adm1021 remains a
> mystery!
> 
> Cheers!
> --
> Peter Hyman
> Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
> Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
> 
> 
>                        Name: signature.asc
>    signature.asc       Type: application/pgp-signature
>                 Description: This is a digitally signed message part

I2C crash - ADM1021

[Jean Delvare]

> see attached file.  Not sure what it shows.

It shows why my code was not working. I expected 0x0000s, while these
are 0x3f00s. BTW, this could mean that this unknown chip expects to be
read in word mode, which is rather unusual (still I don't know what it
could be).

Oh, I took a look at the latest 0x18 dump you sent, it is different from
the very first dump you made, which means this chip is alive too - and I
don't know what this one is either.

I've fixed sensors-detect in CVS, it know should ignore your chip at
0x4e. If you have some time left to give it a try (again), that would be
nice :) Now I hope we won't miss real LM75s. I tested on the one I own
and it is still working, so I'm confident.

Thanks.

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

I2C crash - ADM1021

[Jean Delvare]

> One question.  If I do NOT insert the lm90 driver, but decide to use
> adm1021 (gulp), do I still need to ignore ports 0x4c and 0x4e?  I
> would imagine I would ignore 0x18 and 0x4e since lm90 appears to be at
> 0x4c. Maybe I'll back up again and try.....

Each driver will try to grab every address it knows about, and will
succeed if the device at that address meets some conditions (which of
course depend of the devices the driver is supposed to handle). So, if
the lm90 driver isn't loaded, the device at 0x4c is free, and the
adm1021 driver will try to get all three devices (0x18, 0x4c and 0x4e)
unless you explicitely prevent it to do so. In your case, and if you are
willing to try that, I would prevent it to access the devices at 0x18
and 0x4e, and would let it handle the device at 0x4c. I think it will
work (although you'll miss some features from the lm90 driver, such as
critical temperatures, hysteresis and extra accuracy). That said, and as
I know your system... backup first ;)

> I'll keep you informed.  Thanks again!

Thanks. I hope your daughter had a good time for the tournament :)

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

I2C crash - ADM1021

[Peter Hyman]

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031010/5d744600/attachment.bin

I2C crash - ADM1021

[Peter Hyman]

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031012/1eca61fb/attachment.bin

I2C crash - ADM1021

[Peter Hyman]

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031011/b7b42f04/attachment.bin

I2C crash - ADM1021

[Peter Hyman]

On Tue, 2003-10-14 at 16:20, Jean Delvare wrote:
> for that now. Chips like the PCF8591 could also be simply removed from
> sensors-detect (after all, we *can't* detect them so what's the point?).
> That second option is an easy one and would probably make the users
> happier in average.

I agree!
> 
> Thanks a lot for testing my changes :)

My pleasure!
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031014/611dc1cb/attachment.bin

I2C crash - ADM1021

[Jean Delvare]

> Just a quick FYI update.

Nice to you to keep us informed :)

> Today, I updated all source for I2C and lmsensors from CVS.

Which basically means you have 2.8.1 - since almost no changes have been
made since we released it.

> When running sensors-detect, it had slightly different settings
> for the OPTIONS line in modules.conf for the adm1021 driver.
> 
> Previously, the line read
> options adm1021 ignore=0,0x18,0,0x4c
> 
> Now, the instructions correctly show
> options adm1021 ignore=0,0x4c,0,0x4e

In your original mail, you said the line was:
options adm1021 ignore=0,0x18,0,0x4c,0,0x4e
That is, all potential addresses disabled.

Now, if 0x4e wasn't actually disabled, it explains how your system could
possibly crash. (Not that we undestand why it did, but at least it had a
"chance" to.)

> The difference being that the driver was polling a port it had no
> business doing and I believe this is what caused my system to crash!

Makes sense.

> Now, the irony is that the information from port 0x18 is totally
> useless as it shows system and cpu temperature at -41C!
> 
> /sbin/modprobe adm1021 ignore=0,0x4c,0,0x4e
> 
> sensors
> ----------------
> lm84-i2c-0-18
> Adapter: SMBus Via Pro adapter at 5000
> Algorithm: Non-I2C SMBus adapte
> Board:       -41?C  (low =   -1?C, high =  -17?C)
> CPU:         -41?C  (low =  +60?C, high =   -1?C)

The LM84 has a somewhat weak identification method, and is often
misdetected. There's not much we can do about it. Maybe we could decide
that the following conditions make us drop it:
* Board or CPU temp below 0.
* low limit > high limit
* high limits below 0
In your example, the 6 conditions are met, so we could reasonably decide
not to detect it. Even with, say, 3 or 4 conditions, I guess we could
drop it.

I just made these changes to sensors-detect, would you be kind enough,
give it a try and confirm that it now doesn't tell you to load adm1021
anymore? Thanks.

> But thank you anyway for making that minor correction!  I hope it was
> only me that had the disk trashing trouble!

We had no other reports, hopefully because nobody experienced the same.

> One interesting note is that when rebooting, I had to completely do a
> cold start.

The chip as 0x18 is not a LM84. Maybe it is some other chip that did not
like what the adm1021 driver did to him, and had its revendge at
shutdown time ;)

> Let me know if I can provide you with any additional detail.

Great that the changes I made to sensors-detect prevent your system from
crashing.

Thanks for the update :)

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

I2C crash - ADM1021

[Peter Hyman]

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031013/25bbcff9/attachment.bin

I2C crash - ADM1021

[Jean Delvare]

> > for that now. Chips like the PCF8591 could also be simply removed
> > from sensors-detect (after all, we *can't* detect them so what's the
> > point?). That second option is an easy one and would probably make
> > the users happier in average.
> 
> I agree!

OK, done that.

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

I2C crash - ADM1021

[Jean Delvare]

> > I took a look, it used to detect an adm1021 clone for all three
> > addresses (0x18, 0x4c and 0x4e). After my first fix, 0x18 is left
> > apart(great), 0x4c is detected but the lm90 driver if prefered
> > (great too) and 0x4e is still detected (*not* great). I added one
> > extra check in sensors detect for the MAX1617 and the LM84 (and also
> > for the LM75), which should fix the problem. Could you check it out
> > and give it a try? Would be nice.
> 
> File is attached...

Great, no more MAX1617 claimed at 0x4e. Still sensors-detect claims to
have found a LM75 at this address, which should *not* happen after my
latest changes. Very strange... Could you provide the output of the
following command, it may help:
i2cdump 0 0x4e w
Notice the "w" for "word mode". This mode is used while detecting LM75,
maybe the unknown chip you have at 0x4e doesn't answer to this mode as
expected.

> > BTW, I'd be interested in a dump of devices 0x18 and 0x4e. You
> > already sent them once, but they obviously changed (the one at 0x4e
> > at least, or it couldn't be detected as a LM84 - and it is).
>
> File is attached.  I don't know why 4e changed either.

I suspect that this chip has only one readable register, so it doesn't
care about the address and always return the value of that register.
That said, I don't know why this value used to be 0x14 and is now 0x00,
but it's probably a bit vector and not a plain value (well, just
guessing.)

> and I got similar data from the MAX1617.  see file
> sensors-output-20031012.txt for the history.
> About the only difference I can see is that the lm90 driver returns a
> temp with a decimal number and the MAX1617 returns a whole number.

That's what was expected.

> ANYWAY, Jean.  Sorry to have taken up so much of your time --
> especially since it appears it was my error in the first place (not
> adding 0,0x4e in the original modules.conf file.
> 
> However, I learned alot from the experience and have become quite
> comfortable working with lmsensors.

Everyone took benefit I guess. You learned about lm_sensors, we improved
our detection routines, making our product slightly better. That's the
way we like it :)

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

I2C crash - ADM1021

[Jean Delvare]

> > In your original mail, you said the line was:
> > options adm1021 ignore=0,0x18,0,0x4c,0,0x4e
> > That is, all potential addresses disabled.
> 
> If that's the case, I goofed! because in my original modules.conf, I
> had left out the 0x4e! Maybe that is what caused the failure?

Yes, that's what I think too.

> When I ignore all three addresses and type sensors, it says no sensors
> found. I suppose I'm loading the driver and telling it to skip
> everything it would poll?

Yes, that's it.

> I got the latest sensors-detect, and have attached the output.  It
> still prompts me to install the adm1021 driver, and here is the
> probing output.
> 
> Client found at address 0x18
> Probing for `Analog Devices ADM1021'... Failed!
> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> Probing for `Maxim MAX1617'... Failed!
> Probing for `Maxim MAX1617A'... Failed!
> Probing for `TI THMC10'... Failed!
> Probing for `National Semiconductor LM84'... Failed!
> Probing for `Genesys Logic GL523SM'... Failed!
> Probing for `Onsemi MC1066'... Failed!
> Probing for `National Semiconductor LM82'... Failed!
> Probing for `National Semiconductor LM83'... Failed!
> Client found at address 0x37
> Client found at address 0x4c
> Probing for `National Semiconductor LM75'... Failed!
> Probing for `Dallas Semiconductor DS1621'... Failed!
> Probing for `Analog Devices ADM1021'... Failed!
> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> Probing for `Maxim MAX1617'... Success!
>     (confidence 3, driver `adm1021')
> ....clipped

It's better. Now sensors-detect leaves whatever is at 0x18 alone.

> If you notice, the chip Maxim MAX1617 is listed twice.  Near the top,
> the probe fails.  At the bottom where I clipped the listing, it
> succeeds!

This is normal. It isn't probing the same device each time. The first
time, it probes the device at 0x18, which is an unknown device. With my
new code, sensors-detect now knows it can't reasonably be an ADM1021
clone. Good. Next, 0x4c. This is different, because the device here is a
LM90, which is partly compatible with the ADM1021, so it *could* be a
MAX1617, requiring the adm1021 driver. Actually, you could unload the
lm90 driver, load the adm1021 driver instead and it would return
resonable temperatures and limits (better believe me and don't do it, we
know how much your system loves the adm1021 driver).

> I don't recall if this is what occurred previously.  I think I had
> emailed you a sensors-detect listing though, so you can check there if
> you need to.  As of now, the sensors-detect changes are still missing
> something on my config.

I took a look, it used to detect an adm1021 clone for all three
addresses (0x18, 0x4c and 0x4e). After my first fix, 0x18 is left apart
(great), 0x4c is detected but the lm90 driver if prefered (great too)
and 0x4e is still detected (*not* great). I added one extra check in
sensors detect for the MAX1617 and the LM84 (and also for the LM75),
which should fix the problem. Could you check it out and give it a try?
Would be nice.

BTW, I'd be interested in a dump of devices 0x18 and 0x4e. You already
sent them once, but they obviously changed (the one at 0x4e at least, or
it couldn't be detected as a LM84 - and it is).

> Nonetheless, I really do appreciate your taking the time to respond!
> Best wishes, and enjoy the weekend!!!

Thanks a lot. I also appreciate you decided to share your painful
experience with us and the rest of our users, for the benefit of
everyone :)

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

I2C crash - ADM1021

[Peter Hyman]

Jean, I will try the latest sensors-detect and report back to you.  I
won't be able to do it until much later today or tomorrow as my daughter
is in a soccer tournament and I will be away most of today and tomorrow
(if she makes the finals -- on esp?re toujours.).

One question.  If I do NOT insert the lm90 driver, but decide to use
adm1021 (gulp), do I still need to ignore ports 0x4c and 0x4e?  I would
imagine I would ignore 0x18 and 0x4e since lm90 appears to be at 0x4c. 
Maybe I'll back up again and try.....

I'll keep you informed.  Thanks again!

On Sat, 2003-10-11 at 07:48, Jean Delvare wrote:
> > > In your original mail, you said the line was:
> > > options adm1021 ignore=0,0x18,0,0x4c,0,0x4e
> > > That is, all potential addresses disabled.
> > 
> > If that's the case, I goofed! because in my original modules.conf, I
> > had left out the 0x4e! Maybe that is what caused the failure?
> 
> Yes, that's what I think too.
> 
> > When I ignore all three addresses and type sensors, it says no sensors
> > found. I suppose I'm loading the driver and telling it to skip
> > everything it would poll?
> 
> Yes, that's it.
> 
> > I got the latest sensors-detect, and have attached the output.  It
> > still prompts me to install the adm1021 driver, and here is the
> > probing output.
> > 
> > Client found at address 0x18
> > Probing for `Analog Devices ADM1021'... Failed!
> > Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> > Probing for `Maxim MAX1617'... Failed!
> > Probing for `Maxim MAX1617A'... Failed!
> > Probing for `TI THMC10'... Failed!
> > Probing for `National Semiconductor LM84'... Failed!
> > Probing for `Genesys Logic GL523SM'... Failed!
> > Probing for `Onsemi MC1066'... Failed!
> > Probing for `National Semiconductor LM82'... Failed!
> > Probing for `National Semiconductor LM83'... Failed!
> > Client found at address 0x37
> > Client found at address 0x4c
> > Probing for `National Semiconductor LM75'... Failed!
> > Probing for `Dallas Semiconductor DS1621'... Failed!
> > Probing for `Analog Devices ADM1021'... Failed!
> > Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> > Probing for `Maxim MAX1617'... Success!
> >     (confidence 3, driver `adm1021')
> > ....clipped
> 
> It's better. Now sensors-detect leaves whatever is at 0x18 alone.
> 
> > If you notice, the chip Maxim MAX1617 is listed twice.  Near the top,
> > the probe fails.  At the bottom where I clipped the listing, it
> > succeeds!
> 
> This is normal. It isn't probing the same device each time. The first
> time, it probes the device at 0x18, which is an unknown device. With my
> new code, sensors-detect now knows it can't reasonably be an ADM1021
> clone. Good. Next, 0x4c. This is different, because the device here is a
> LM90, which is partly compatible with the ADM1021, so it *could* be a
> MAX1617, requiring the adm1021 driver. Actually, you could unload the
> lm90 driver, load the adm1021 driver instead and it would return
> resonable temperatures and limits (better believe me and don't do it, we
> know how much your system loves the adm1021 driver).
> 
> > I don't recall if this is what occurred previously.  I think I had
> > emailed you a sensors-detect listing though, so you can check there if
> > you need to.  As of now, the sensors-detect changes are still missing
> > something on my config.
> 
> I took a look, it used to detect an adm1021 clone for all three
> addresses (0x18, 0x4c and 0x4e). After my first fix, 0x18 is left apart
> (great), 0x4c is detected but the lm90 driver if prefered (great too)
> and 0x4e is still detected (*not* great). I added one extra check in
> sensors detect for the MAX1617 and the LM84 (and also for the LM75),
> which should fix the problem. Could you check it out and give it a try?
> Would be nice.
> 
> BTW, I'd be interested in a dump of devices 0x18 and 0x4e. You already
> sent them once, but they obviously changed (the one at 0x4e at least, or
> it couldn't be detected as a LM84 - and it is).
> 
> > Nonetheless, I really do appreciate your taking the time to respond!
> > Best wishes, and enjoy the weekend!!!
> 
> Thanks a lot. I also appreciate you decided to share your painful
> experience with us and the rest of our users, for the benefit of
> everyone :)
-- 
Peter Hyman
Home:(609)395-1211 Office: (609)655-1184, Fax:(609)655-0285
Stop Telemarketers.  Sign up for Do Not Call at http://donotcall.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031011/3d5a15b1/attachment.bin

I2C crash - ADM1021

[Jean Delvare]

> Interesting, Jean.
> 
> Now, s-d is recommending I insert pcf8591 but it did not before!

Perfectly normal, that's what I expected.

> What IS it about my system and port 0x4c?

Simply an unknown chip.

> For that matter, can you have
> two drivers trying to access different chips at the same port?

Not at the same time.

> Isn't that what got me into trouble in the first place?

No, it was the adm1021 driver trying to handle an unknown (and obviously
non-adm1021-compatible) chip.

> Driver `pcf8591' (should be inserted but causes problems):
>   Detects correctly:
>   * Bus `SMBus Via Pro adapter at 5000' (Non-I2C SMBus adapter)
>     Busdriver `i2c-viapro', I2C address 0x4e
>     Chip `Philips Semiconductors PCF8591' (confidence: 1)
>   Misdetects:
>   * Bus `SMBus Via Pro adapter at 5000' (Non-I2C SMBus adapter)
>     Busdriver `i2c-viapro', I2C address 0x4c
>     Chip `Philips Semiconductors PCF8591' (confidence: 1)

The PCF8591 is an 8-bit A/D-D/A converter which cannot be detected (it
has no readable registers), so we simply give it a confidence value of 1
(the lowest possible). This means that any other chip that will be
detected at the same address will discard it (that's the case at 0x4c,
where the lm90 discards the pcf8591) but at 0x4e I've been able to
prevent all misdetections (adm1021, lm75) but the pcf8591, so
sensors-detect now concludes that the chip at 0x4e is a PCF8591. I think
we should consider chips with confidence=1 as misdetected, and not add
them to the list of suggested modules. Unfortunately, this option
requires important changes to the code and I don't really have the time
for that now. Chips like the PCF8591 could also be simply removed from
sensors-detect (after all, we *can't* detect them so what's the point?).
That second option is an easy one and would probably make the users
happier in average.

Thanks a lot for testing my changes :)

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