tulip.c 0.91g lockup ...

[Donald Becker]

On Fri, 29 Oct 1999, Gerhard Wiesinger wrote:

> > > I've upgraded to tulip.c 0.91g and one interface can not transmit after
> > > some work (Depends on: from minutes up to hours until this occours)
> > > 
> > > Oct 29 19:06:30 bbs kernel: eth1: 21140 transmit timed out, status
> > > fc6988c5, SIA ffffff0b ffffffff 1c09fdc0 fffffec8, resetting... 
> > ....  So we need to know
> > the driver detection message for your specific cards. 
> >
> 
> Oct 29 11:27:13 bbs kernel: eth1: Digital DS21140 Tulip rev 18 at 0x6200,
> 00:00:
> E8:1F:F6:89, IRQ 12. 
> Oct 29 11:27:13 bbs kernel: eth1: Old format EEPROM on 'Accton EN1207'
> board.  U
> sing substitute media control info. 
> Oct 29 11:27:13 bbs kernel: eth1:  EEPROM default media type Autosense. 
> Oct 29 11:27:13 bbs kernel: eth1:  Index #0 - Media 10base2 (#1) described
> by a 
> 21140 non-MII (0) block. 
> Oct 29 11:27:13 bbs kernel: eth1:  Index #1 - Media 10baseT (#0) described
> by a 
> 21140 non-MII (0) block. 
> Oct 29 11:27:13 bbs kernel: eth1:  Index #2 - Media 10baseT-FD (#4)
> described by
>  a 21140 non-MII (0) block. 
> Oct 29 11:27:13 bbs kernel: eth1:  Index #3 - Media 100baseTx (#3)
> described by 
> a 21140 non-MII (0) block. 
> Oct 29 11:27:13 bbs kernel: eth1:  Index #4 - Media 100baseTx-FD (#5)
> described 
> by a 21140 non-MII (0) block. 

OK, that looks normal for an old Accton card.  Nothing should have changed.

> > It *does* appear that the Tulip chip in the message above was trying to
> > raise an interrupt that wasn't handled.  You should check /proc/interrupts
> > for an increasing count.  I'm guessing that the real problem here is an APIC
> > bug with interrupt line assignment in a new kernel, not a driver media
> > selection problem. 
> 
> But the card doesn't use an APIC chipset :-(

The APIC is on the Advanced Programmable Interrupt Controller on the
motherboard.  Newer Linux kernels try to use it, but something Things Go
Wrong.

> BTW: I've mailed you some days ago for NWAY support for the Accton EN1207.
> On what does it depend if the card supports NWAY autonegotiation?
> (chipset, tranceiver, EEPROM, hardware, software?)

All of the above.

> Does the DEC21140AF support NWAY autonegotiation? And which tranceiver is
> supported?

The 21140 does not do NWay autonegotiation.  If the 21140 is connected to
a MII transceiver, the transceiver usually does NWay, and the driver just
has to set a timer to poll for the current status.
If the 21140 is connected to a SYM transceiver, the board cannot do NWay.

The 21143 does implement NWay.  If connected to a SYM transceiver with extra
'143-specific support, the chip and driver can work together to implement
autonegotiation.  The downside is that the hardware and software have to
Just Right for this to work.  The early tulip drivers and '143 hardware were
not.

A 21143 with MII transceiver is just like the 21140+MII -- NWay is done in
the transceiver, and the extra '143 hardware support is not used.

Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS,   becker@cesdis.gsfc.nasa.gov