> Von: Jean Delvare <khali at linux-fr.org>
> Gesendet: 17.10.07 23:32:28
>
> On Wed, 17 Oct 2007 12:43:16 -0700, Juerg Haefliger wrote:
> > On 10/17/07, Juergen Bausa <Juergen.Bausa at web.de> wrote:
> > > Here is what I found in /var/log:
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: Found a DME1737 chip at 0x2e (rev 0x8a)
> > >
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x10)
> > > /var/log/debug:Oct 17 09:16:00 lisa kernel: i2c_adapter i2c-1: SMBus Timeout! (0x10)
> >
> > These are all errors that occur when the drivers (i2c and dme1737) get
> > loaded. The dme1737 is not printing any errors so they are not
> > transactions initiated by the dme1737. The 0x10 means "SMBus Device
> > Address Not Acknowledged" according to the ACPI spec. Not sure how
> > this can happen... Signal integrity problems on the board level? In
> > any case, these errors should probably be retried. Not sure at what
> > level though. Jean?
>
> These are not errors at all, it's only i2c-core probing at work. The
> dme1737 driver specifies three possible addresses (0x2c, 0x2d, 0x2e),
> the probes at 0x2c and 0x2d on bus 0 fail, these are the first two
> "SMBus Timeout!" messages above. Then the probe at 0x2e succeeds. Then
> i2c-core goes on with bus 1. There should have been 3 failing probes
> there, but surprisingly, there's only one "SMBus Timeout!" for bus 1. I
> can't explain it.
I greped the mesages. Maybe, there was a 'message repeated xx times' in the log, that wasnt displayed.
>
> Juergen, can you please attach the output of:
>
> modprobe i2c-dev
> i2cdetect -y 0
> i2cdetect -y 1
lisa:/home/jba# modprobe i2c-dev
lisa:/home/jba# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- 0d -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
30: 30 31 -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
lisa:/home/jba# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
lisa:/home/jba#
>
> Either way these 3 log messages can safely be ignored.
>
> > > /var/log/debug:Oct 17 19:35:30 lisa kernel: i2c_adapter i2c-0: SMBus Timeout! (0x1a)
> > >
> > > /var/log/messages:Oct 17 09:16:00 lisa kernel: dme1737 0-002e: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=no, fan4=yes, fan5=no, fan6=no.
> > > /var/log/messages:Oct 17 19:35:30 lisa kernel: dme1737 0-002e: Write to register 0x30 failed (-1)! Please report to the driver maintainer.
> >
> > Aha, this is an error as a result of a dme1737 initiated write. 0x1a
> > means "SMBus Busy". So the dme1737 driver is colliding with something
> > else in the system that tries to talk to a chip on the same bus.
>
> This can only happen on a multi-master I2C bus, which is rather rare on
> consumer PCs. Juergen, do you have detailed technical documentation
> about your system? It would be interesting to find out what chip the
> other master is talking to. If it's the DME1737 chip, this could lead
> to problems.
No. I dont have detailes information. Its an asus barebone.
Asus borads have a feature called 'ASUS Q-Fan Technology'. Its a BIOS-based controller for the
FAN/CPU-temperature. This is turned on in the bios. However, when booting linux, the script
'fancontrol' is started and then controls cpu-temperature. Maybe the Q-fan still tries to access
the fan and this is the reason for the collision?
>
> > That
> > should definitely get retried. I can certainly do that at the dme1737
> > level but I don't think that's the right place. Jean?
>
> Assuming that "busy" means that the nForce chip did not even attempt to
> send the message (or lost arbitration, which is equivalent), this
> specific error could be handled in i2c-nforce2, by retrying. The
> problem is that you have to decide how many times you retry, and how
> much time you wait between retries (there doesn't seem to be a way to
> test if the SMBus is busy before trying, right?)
>
> We have "timeout" and "retries" fields in struct i2c_adapter, which
> could be used for this. The meaning of "retries" is a bit different
> though, it's supposed to be the number of nacks the bus driver accepts
> when attempting to contact a chip before giving up. This doesn't appear
> to be very useful though so I wouldn't mind recycling this field for
> the more interesting usage you need. Most bus drivers don't set nor use
> "timeout".
>
> As a first aid solution, you could simply hardcode the timeout and
> retry values, just to confirm that it solves Juergen's problem. Then
> we can see how to make it cleaner. Error handling is an area where the
> i2c subsystem needs to be improved.
>
Just to make it clear: The messages are no real problem. fancontrol is working very fine.
Maybe its not successful in setting fan speed sometimes (once a day). But it just sets thge
fan speed in the next iteration 5 seconds later. Thats no problem.
However, I am also interested in the solution of this.
Juergen
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
