2.4.6.-ac2: Problems with eepro100

2.4.6.-ac2: Problems with eepro100

[Martin Knoblauch]

Hi,

 after going from 2.4.6-ac1 to 2.4.6-ac2 the eepro100 adapter in my IBM
Thinkpad-570 has stopped working. While "ifconfig" shows the expected
info, nothing network related (ping, yp, bind, amd, ...) is working. In
my config, the eepro driver is built directly into the kernel.

 If I look at the interface lights, it seems that the link goes down
early in the boot sequence. The whole thing is reproducible. When
booting -ac1 again, everything is OK.

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: 2.4.6.-ac2: Problems with eepro100

[Martin Knoblauch]

Martin Knoblauch wrote:
> 
> Hi,
> 
>  after going from 2.4.6-ac1 to 2.4.6-ac2 the eepro100 adapter in my IBM
> Thinkpad-570 has stopped working. While "ifconfig" shows the expected
> info, nothing network related (ping, yp, bind, amd, ...) is working. In
> my config, the eepro driver is built directly into the kernel.
> 
>  If I look at the interface lights, it seems that the link goes down
> early in the boot sequence. The whole thing is reproducible. When
> booting -ac1 again, everything is OK.
> 

 additional datapoint: if I use "eepro100.c" from vanilla 2.4.6, the
interface works OK. So, maybe the problems are power-managment related,
as the eepro100 differences in -ac2 seem to concern that area.

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: 2.4.6.-ac2: Problems with eepro100

[Patrick Mochel]

> 
>  additional datapoint: if I use "eepro100.c" from vanilla 2.4.6, the
> interface works OK. So, maybe the problems are power-managment related,
> as the eepro100 differences in -ac2 seem to concern that area.

That is most likely power management related; it sounds like the device
is not in the state it's supposed to be. 

Can you do an 'lspci -vv' on the device? The current device state should
be listed 2 lines after the Power Management Capabilities revision.

	-pat

Re: 2.4.6.-ac2: Problems with eepro100

[Kai Germaschewski]

On Mon, 9 Jul 2001, Patrick Mochel wrote:

> Can you do an 'lspci -vv' on the device? The current device state should
> be listed 2 lines after the Power Management Capabilities revision.

I already talked to Martin off list about this problem (since it's my 
patch which is causing trouble).

To summarize the results: His eepro100 does only survive one
D0-D2-D0 transition, after another D2 transition it's possible to place it 
back in D0, but it won't work.

It comes up in D0, eepro100 module load will place it in D2, first
ifconfig up will switch to D0, works. Another ifconfig down / up cycle 
will kill the network (same happens with the unpatched version).

If someone feels able to find out what's really happening, that'd be great
of course. To the question of what to do about this, the only thing I can
think of is adding a parameter/config option for eepro100 to supply the
power state when inactive (default would be D2, for Martin D0 will work).

Better ideas anyone?

--Kai

Re: 2.4.6.-ac2: Problems with eepro100

[Jeff Garzik]

On Mon, 9 Jul 2001, Kai Germaschewski wrote:

> On Mon, 9 Jul 2001, Patrick Mochel wrote:
> 
> > Can you do an 'lspci -vv' on the device? The current device state should
> > be listed 2 lines after the Power Management Capabilities revision.
> 
> I already talked to Martin off list about this problem (since it's my 
> patch which is causing trouble).
> 
> To summarize the results: His eepro100 does only survive one
> D0-D2-D0 transition, after another D2 transition it's possible to place it 
> back in D0, but it won't work.
> 
> It comes up in D0, eepro100 module load will place it in D2, first
> ifconfig up will switch to D0, works. Another ifconfig down / up cycle 
> will kill the network (same happens with the unpatched version).
> 
> If someone feels able to find out what's really happening, that'd be great
> of course. To the question of what to do about this, the only thing I can
> think of is adding a parameter/config option for eepro100 to supply the
> power state when inactive (default would be D2, for Martin D0 will work).
> 
> Better ideas anyone?

Do a register dump of working and dead-after-PM-transition, including
PCI config registers, and look for differences.  Also look for
differences in your host and PCI-PCI bridge PCI config registers.

Re: 2.4.6.-ac2: Problems with eepro100

[Martin Knoblauch]

Jeff Garzik wrote:
> 
> On Mon, 9 Jul 2001, Kai Germaschewski wrote:
> 
> > On Mon, 9 Jul 2001, Patrick Mochel wrote:
> >
> 
> Do a register dump of working and dead-after-PM-transition, including
> PCI config registers, and look for differences.  Also look for
> differences in your host and PCI-PCI bridge PCI config registers.

 Instructions on how to do the dumps? Sorry, I have not been that deep
into these matters until now :-)

 Just as an experiment, I modified the 246-ac2 eepro100.c driver to
never set the devive into D2 mode. As a result, I can now ifconfig
down/up as much as I want without killing the network. So I guess it is
really PM related.

*** eepro100.c-ac2      Mon Jul  9 12:30:53 2001
--- eepro100.c  Wed Jul 11 12:47:07 2001
***************
*** 780,782 ****
        /* Put chip into power state D2 until we open() it. */
!       pci_set_power_state(pdev, 2);
 
--- 780,782 ----
        /* Put chip into power state D2 until we open() it. */
!       pci_set_power_state(pdev, 0); /*MKN*/
 
***************
*** 1835,1837 ****
 
!       pci_set_power_state(sp->pdev, 2);
 
--- 1835,1837 ----
 
!       pci_set_power_state(sp->pdev, 0); /* MKN */


Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: 2.4.6.-ac2: Problems with eepro100

[Kai Germaschewski]

On Wed, 11 Jul 2001, Martin Knoblauch wrote:

> > Do a register dump of working and dead-after-PM-transition, including
> > PCI config registers, and look for differences.  Also look for
> > differences in your host and PCI-PCI bridge PCI config registers.
> 
>  Instructions on how to do the dumps? Sorry, I have not been that deep
> into these matters until now :-)

For the PCI things: Do a lspci -vvxxx at the various stages of working / 
not working and diff them. For the chip registers - well, I didn't look 
into this yet, but it'll be a bit harder, I suppose. (Maybe the maintainer 
has some hints?)

--Kai

Re: 2.4.6.-ac2: Problems with eepro100

[Jeff Garzik]

Kai Germaschewski wrote:
> 
> On Wed, 11 Jul 2001, Martin Knoblauch wrote:
> 
> > > Do a register dump of working and dead-after-PM-transition, including
> > > PCI config registers, and look for differences.  Also look for
> > > differences in your host and PCI-PCI bridge PCI config registers.
> >
> >  Instructions on how to do the dumps? Sorry, I have not been that deep
> > into these matters until now :-)
> 
> For the PCI things: Do a lspci -vvxxx at the various stages of working /
> not working and diff them. For the chip registers - well, I didn't look
> into this yet, but it'll be a bit harder, I suppose. (Maybe the maintainer
> has some hints?)

download eepro-diag.c from ftp://www.scyld.com/diag/

-- 
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |

Re: 2.4.6.-ac2: Problems with eepro100

[Martin Knoblauch]

Kai Germaschewski wrote:
> 
> On Wed, 11 Jul 2001, Martin Knoblauch wrote:
> 
> > > Do a register dump of working and dead-after-PM-transition, including
> > > PCI config registers, and look for differences.  Also look for
> > > differences in your host and PCI-PCI bridge PCI config registers.
> >
> >  Instructions on how to do the dumps? Sorry, I have not been that deep
> > into these matters until now :-)
> 
> For the PCI things: Do a lspci -vvxxx at the various stages of working /
> not working and diff them. For the chip registers - well, I didn't look
> into this yet, but it'll be a bit harder, I suppose. (Maybe the maintainer
> has some hints?)
> 
> --Kai

 So, I tested  2.4.7pre6 with eepro100 build as a module and the problem
(network broken after ifconfig down/up cycle) persists.

 "lspci -vvxxx" output between the good "D0" state and the bad one is
identical. Output for the D2 state just differs in the "e0:" line, which
seems to be OK.

martink@laplin22:/boot > diff eep-D0-1 eep-D2-4
13c13
<               Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
>               Status: D2 PME-Enable- DSel=0 DScale=0 PME-
28c28
< e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
---
> e0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
martink@laplin22:/boot > more eep-D2-4
02:01.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100]
(rev 05)
        Subsystem: IBM: Unknown device 00d8
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 66 (2000ns min, 14000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fc000000 (32-bit, prefetchable) [size=4K]
        Region 1: I/O ports at 3000 [size=32]
        Region 2: Memory at dc600000 (32-bit, non-prefetchable)
[size=1M]
        Expansion ROM at <unassigned> [disabled] [size=1M]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D2 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 29 12 17 00 90 02 05 00 00 02 08 42 00 00
10: 08 00 00 fc 01 30 00 00 00 00 60 dc 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 d8 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 08 38
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 31 fe
e0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 I will see that I can make the "eepro-diag" working.

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759