lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Jan 2009 18:26:31 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

Hi Ingo,

On Tue, 27 Jan 2009 16:44:10 +0100, Ingo Molnar wrote:
> * Jean Delvare <khali@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ