lkml.org 
[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [bug] CONFIG_I2C_VIAPRO=y breaks skge
Hi Ingo,

On Tue, 27 Jan 2009 16:44:10 +0100, Ingo Molnar wrote:
> * Jean Delvare <khali@linux-fr.org> wrote:
> > Wow. This is hard to believe. The i2c-viapro driver only cares about the
> > SMBus interface of the VIA south bridge. I have a hard time imagining
> > how it could have any effect on networking.
> >
> > Is the skge ethernet an on-board thing or an external adapter? I guess
> > the former. Do you have the detailed hardware specification for that
> > machine? I wonder if the ethernet chip could be somehow connected to the
> > SMBus.
>
> on-board. No specification - it's an old testbox.
>
> > Does the SMBus work on that machine? (Probably easier to test with
> > CONFIG_I2C_VIAPRO=m and CONFIG_I2C_CHARDEV=m.) I would also like to know
> > if there is anything in the logs when loading the i2c-viapro driver.
>
> What's the best way to see whether the SMBus fully works on that machine?

modprobe i2c-viapro # if not built-in
modprobe i2c-dev # if not built-in
i2cdetect -l
i2cdetect <n> # where <n> is the bus number of the VIA SMBus (probably 0
# in your case)

i2cdetect is part of i2c-tools:
http://www.lm-sensors.org/wiki/I2CTools

> > What I2C chip drivers did you include in your kernel? Presumably this is
> > a random config, so I can imagine that there is a chip on the SMBus to
> > which an I2C chip driver would have bound and that is causing the
> > problem, rather than i2c-viapro itself.
>
> Correct, i found it via random config testing. x86 defconfig + VIAPRO
> enabled boots fine so it indeed could be interaction between i2c drivers.

Is there anything like a x86 defconfig? I didn't know. I should
probably take a look and make sure that the defaults for i2c and hwmon
are sane. What is this default configuration meant for? There are so
many different x86 machines out there... Is it supposed to support all
of them, or is it an hardware-neutral base to be extended for every
given machine?

> I've attached:
>
> - the bad config - it does have a good deal of other I2C drivers enabled
> - the good config
> - the bad bootlog
> - the good bootlog

OK, in the bad log I can see a lot of probings for I2C devices from
various drivers (eeprom, pcf8591, w83792d, w83781d, adm1021, etc.) Two
possibilities:
* The probes alone are enough to confuse the network adapter.
* A probe succeeds when it shouldn't and the driver binds to the wrong
device and breaks it.

The easiest way to tell is to get a list of probes that succeeded. For
this, boot the bad kernel and run:

$ ls -l /sys/bus/i2c/devices/*/driver
> Anyway, this bug is not a big deal - i can work it around locally by
> excluding VIAPRO on that box. If you'd like to figure out why this happens
> that would be preferred of course, and i can send any debug info you need.

Well my guess is that you have included an I2C chip driver with a weak
detection routine. More likely this is a typical case of "if it hurts,
don't do it". But maybe we can improve the help text or default, or
even disable probing for these devices.

At this point I am reasonably certain that the i2c-viapro driver is
innocent.

--
Jean Delvare


\
 
 \ /
  Last update: 2009-01-27 18:29    [from the cache]
©2003-2011 Jasper Spaans