[bug] CONFIG_I2C_VIAPRO=y breaks skge

[bug] CONFIG_I2C_VIAPRO=y breaks skge

[Ingo Molnar]

hi,

A -tip testsystem triggered this stuck eth0/skge bug today:

 [   24.787761] skge eth0: enabling interface
 [   24.793177] skge eth0: phy write timeout
 [   24.797035] skge eth0: phy write timeout
 [   24.801019] skge eth0: phy write timeout
 [   24.808325] skge eth0: phy write timeout
 [   24.813019] skge eth0: phy write timeout
 [   24.817019] skge eth0: phy write timeout
 [   24.821131] skge eth0: phy write timeout
 [   24.828610] skge eth0: phy write timeout
 [   24.832834] ADDRCONF(NETDEV_UP): eth0: link is not ready

 [root@centauri ~]# ifconfig 
 eth0     Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
          inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12884901885 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12884901885 errors:0 dropped:0 overruns:0 carrier:4294967295
          collisions:4294967295 txqueuelen:1000 
          RX bytes:18446744073709551615 (1.5 EiB)  TX bytes:18446744073709551615 (1.5 EiB)
          Interrupt:17 

(see the weird stats as well)

after a lengthy .config-bisection session i tracked it down to:

   CONFIG_I2C_VIAPRO=y

if that is disabled, the skge driver works fine and the stats look 
healthy:

eth0      Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
          inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:6eff:feb3:3dc6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:837 errors:0 dropped:0 overruns:0 frame:0
          TX packets:767 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:128098 (125.0 KiB)  TX bytes:130996 (127.9 KiB)
          Interrupt:17 

Find below the lspci output - it's a pretty old system. I have not tested 
this system for a long time so the bug might have been there forever.

	Ingo

-------------------->
00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
00:0a.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
00:0d.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
00:0d.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Jean Delvare]

Hi Ingo,

On Tue, 27 Jan 2009 16:13:59 +0100, Ingo Molnar wrote:
> A -tip testsystem triggered this stuck eth0/skge bug today:
> 
>  [   24.787761] skge eth0: enabling interface
>  [   24.793177] skge eth0: phy write timeout
>  [   24.797035] skge eth0: phy write timeout
>  [   24.801019] skge eth0: phy write timeout
>  [   24.808325] skge eth0: phy write timeout
>  [   24.813019] skge eth0: phy write timeout
>  [   24.817019] skge eth0: phy write timeout
>  [   24.821131] skge eth0: phy write timeout
>  [   24.828610] skge eth0: phy write timeout
>  [   24.832834] ADDRCONF(NETDEV_UP): eth0: link is not ready
> 
>  [root@centauri ~]# ifconfig 
>  eth0     Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
>           inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:12884901885 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:12884901885 errors:0 dropped:0 overruns:0 carrier:4294967295
>           collisions:4294967295 txqueuelen:1000 
>           RX bytes:18446744073709551615 (1.5 EiB)  TX bytes:18446744073709551615 (1.5 EiB)
>           Interrupt:17 
> 
> (see the weird stats as well)
> 
> after a lengthy .config-bisection session i tracked it down to:
> 
>    CONFIG_I2C_VIAPRO=y
> 
> if that is disabled, the skge driver works fine and the stats look 
> healthy:
> 
> eth0      Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
>           inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
>           inet6 addr: fe80::20c:6eff:feb3:3dc6/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:837 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:767 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:128098 (125.0 KiB)  TX bytes:130996 (127.9 KiB)
>           Interrupt:17 

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.

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 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.

> Find below the lspci output - it's a pretty old system. I have not tested 
> this system for a long time so the bug might have been there forever.
> 
> 	Ingo
> 
> -------------------->
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
> 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
> 00:0a.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
> 00:0d.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> 00:0d.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
> 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
> 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)

Can we please also have the output of lspci -nn?

Thanks,
-- 
Jean Delvare

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 6154 bytes --]


* Jean Delvare <khali@linux-fr.org> wrote:

> Hi Ingo,
> 
> On Tue, 27 Jan 2009 16:13:59 +0100, Ingo Molnar wrote:
> > A -tip testsystem triggered this stuck eth0/skge bug today:
> > 
> >  [   24.787761] skge eth0: enabling interface
> >  [   24.793177] skge eth0: phy write timeout
> >  [   24.797035] skge eth0: phy write timeout
> >  [   24.801019] skge eth0: phy write timeout
> >  [   24.808325] skge eth0: phy write timeout
> >  [   24.813019] skge eth0: phy write timeout
> >  [   24.817019] skge eth0: phy write timeout
> >  [   24.821131] skge eth0: phy write timeout
> >  [   24.828610] skge eth0: phy write timeout
> >  [   24.832834] ADDRCONF(NETDEV_UP): eth0: link is not ready
> > 
> >  [root@centauri ~]# ifconfig 
> >  eth0     Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
> >           inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:12884901885 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:12884901885 errors:0 dropped:0 overruns:0 carrier:4294967295
> >           collisions:4294967295 txqueuelen:1000 
> >           RX bytes:18446744073709551615 (1.5 EiB)  TX bytes:18446744073709551615 (1.5 EiB)
> >           Interrupt:17 
> > 
> > (see the weird stats as well)
> > 
> > after a lengthy .config-bisection session i tracked it down to:
> > 
> >    CONFIG_I2C_VIAPRO=y
> > 
> > if that is disabled, the skge driver works fine and the stats look 
> > healthy:
> > 
> > eth0      Link encap:Ethernet  HWaddr 00:0C:6E:B3:3D:C6  
> >           inet addr:10.0.1.22  Bcast:10.0.1.255  Mask:255.255.255.0
> >           inet6 addr: fe80::20c:6eff:feb3:3dc6/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:837 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:767 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000 
> >           RX bytes:128098 (125.0 KiB)  TX bytes:130996 (127.9 KiB)
> >           Interrupt:17 
> 
> 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?

> 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.

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

> Can we please also have the output of lspci -nn?

Sure, find it below. [ Hm, why doesnt lspci default to -nn? ]

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.

	Ingo

---------------->
00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge [1106:3188] (rev 01)
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] [1106:b188]
00:07.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. IEEE 1394 Host Controller [1106:3044] (rev 80)
00:0a.0 Ethernet controller [0200]: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] [10b7:1700] (rev 12)
00:0d.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
00:0d.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
00:0f.0 RAID bus controller [0104]: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller [1106:3149] (rev 80)
00:0f.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06)
00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 81)
00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 81)
00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 81)
00:10.3 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 81)
00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 86)
00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] [1106:3227]
00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 60)
00:11.6 Communication controller [0780]: VIA Technologies, Inc. AC'97 Modem Controller [1106:3068] (rev 80)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200 SE] [1002:5964] (rev 01)
01:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) [1002:5d44] (rev 01)

[-- Attachment #2: config.bad.bz2 --]
[-- Type: application/x-bzip2, Size: 14825 bytes --]

[-- Attachment #3: config.good.bz2 --]
[-- Type: application/x-bzip2, Size: 14831 bytes --]

[-- Attachment #4: boot.log.bad.bz2 --]
[-- Type: application/x-bzip2, Size: 41211 bytes --]

[-- Attachment #5: boot.log.good.bz2 --]
[-- Type: application/x-bzip2, Size: 39496 bytes --]

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Jean Delvare]

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

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Ingo Molnar]

* Jean Delvare <khali@linux-fr.org> wrote:

> > > 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. [...]

Yes. Type "make defconfig" in the kernel source top directory, on an x86 
box.

> > 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.

i've excluded the VIAPRO driver on that box (and only the VIAPRO driver - 
i.e. all those other I2C drivers still run frequently) - and the problem 
has not reoccured in about ~1000 bootups.

Combined with the fact that this box has a VIA chipset, does that not 
implicate the viapro driver, at least to a certain degree?

	Ingo

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Jean Delvare]

On Thu, 29 Jan 2009 14:49:16 +0100, Ingo Molnar wrote:
> 
> * Jean Delvare <khali@linux-fr.org> wrote:
> > 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.
> 
> i've excluded the VIAPRO driver on that box (and only the VIAPRO driver - 
> i.e. all those other I2C drivers still run frequently) - and the problem 
> has not reoccured in about ~1000 bootups.
> 
> Combined with the fact that this box has a VIA chipset, does that not 
> implicate the viapro driver, at least to a certain degree?

This VIA chipset is the bridge over which the bugs run. Blaming on it
for the problem you've hit would be similar to blaming the USB host
controller driver for a bug that is in the USB keyboard or mouse driver.

The "other I2C drivers" don't run frequently at all now that you've
disabled i2c-viapro. Without an I2C bus to probe on the machine, these
drivers don't do anything.

So, again, if you are still willing to help me solve the problem,
please boot the bad kernel and run:

$ ls -l /sys/bus/i2c/devices/*/driver

Then we'll know which drivers attached to I2C devices on your SMBus.
Figuring out which one shouldn't have will likely be straightforward.

Thanks,
-- 
Jean Delvare

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Ingo Molnar]

* Jean Delvare <khali@linux-fr.org> wrote:

> On Thu, 29 Jan 2009 14:49:16 +0100, Ingo Molnar wrote:
> > 
> > * Jean Delvare <khali@linux-fr.org> wrote:
> > > 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.
> > 
> > i've excluded the VIAPRO driver on that box (and only the VIAPRO driver - 
> > i.e. all those other I2C drivers still run frequently) - and the problem 
> > has not reoccured in about ~1000 bootups.
> > 
> > Combined with the fact that this box has a VIA chipset, does that not 
> > implicate the viapro driver, at least to a certain degree?
> 
> This VIA chipset is the bridge over which the bugs run. Blaming on it 
> for the problem you've hit would be similar to blaming the USB host 
> controller driver for a bug that is in the USB keyboard or mouse driver.
> 
> The "other I2C drivers" don't run frequently at all now that you've 
> disabled i2c-viapro. Without an I2C bus to probe on the machine, these 
> drivers don't do anything.

ah, okay - i see - what i thought to be a surgical workaround has cut off 
the whole leg. Will go back to find the ailing muscle instead.

> So, again, if you are still willing to help me solve the problem, please 
> boot the bad kernel and run:
> 
> $ ls -l /sys/bus/i2c/devices/*/driver
> 
> Then we'll know which drivers attached to I2C devices on your SMBus. 
> Figuring out which one shouldn't have will likely be straightforward.

will take some time - but i'll revisit it.

Could you give me a short list of I2C driver .config options i should 
disable one by one (instead of viapro) ?

	Ingo

Re: [bug] CONFIG_I2C_VIAPRO=y breaks skge

[Jean Delvare]

On Thu, 29 Jan 2009 15:27:59 +0100, Ingo Molnar wrote:
> 
> * Jean Delvare <khali@linux-fr.org> wrote:
> > This VIA chipset is the bridge over which the bugs run. Blaming on it 
> > for the problem you've hit would be similar to blaming the USB host 
> > controller driver for a bug that is in the USB keyboard or mouse driver.
> > 
> > The "other I2C drivers" don't run frequently at all now that you've 
> > disabled i2c-viapro. Without an I2C bus to probe on the machine, these 
> > drivers don't do anything.
> 
> ah, okay - i see - what i thought to be a surgical workaround has cut off 
> the whole leg. Will go back to find the ailing muscle instead.

Exactly.

> > So, again, if you are still willing to help me solve the problem, please 
> > boot the bad kernel and run:
> > 
> > $ ls -l /sys/bus/i2c/devices/*/driver
> > 
> > Then we'll know which drivers attached to I2C devices on your SMBus. 
> > Figuring out which one shouldn't have will likely be straightforward.
> 
> will take some time - but i'll revisit it.
> 
> Could you give me a short list of I2C driver .config options i should 
> disable one by one (instead of viapro) ?

I can't tell you before you give me the output of
  ls -l /sys/bus/i2c/devices/*/driver
for the broken system.

-- 
Jean Delvare