Problem with Accton EN1207D-TX

[Steve Jefferson]

On Sun, 19 Mar 2000, Donald Becker wrote:
> > Symptoms: basically cannot ping laptop from P90 and vice-versa
> > Laptop 100Mbps LED on, both 10 *and* 100Mbps Accton card LEDs on. Have
> > tried Accton card in another PCI slot, no difference. 
> I'm guessing that you have a bus-mastering problem.  It's possible that you
> don't have any valid bus-master slots on a motherboard of that era.
Given the age of the motherboard this is clearly possible; however the
documentation on the NCR 53c810 PCI SCSI card on the same bus suggests that it
is also a bus-master card and that works fine (also I swapped PCI slots
between it and the ethercard and the SCSI system was still okay). 

> > of a D-Link DE-530CT+ (DEC Tulip-based) 10Base2/10BaseT PCI card and tried
> > that - doesn't work either, so it would appear more likely that the P90 is the
> > problem....
> 
> Yup.  Try the Tulip card again and run 'tulip-diag' after trying to send a
> few packets.   The Tulip reports better PCI bus fault info.
>   http://cesdis.gsfc.nasa.gov/linux/diag/index.html
Output of 'tulip-diag -e':

tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Digital DC21041 Tulip adapter at 0xd000.
 Port selection is half-duplex.
 Transmit started, Receive started, half-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit unit is set to store-and-forward.
 Interrupt sources are pending!  CSR5 is fc670055.
   Tx done indication.
   Tx out of buffers indication.
   Link passed indication.
   Rx Done indication.
  The NWay status register is 000001c8.
EEPROM size is 6.
PCI Subsystem IDs, vendor 1186, device 0100.
CardBus Information Structure at offset 00000000.
Ethernet MAC Station Address 00:80:C8:44:18:12.
EEPROM transceiver/media description for the Digital DC21041 Tulip chip.
Leaf node at offset 30, default media type 0800 (Autosense).
 3 transceiver description blocks:
  21041 media index 00 (10baseT).
  21041 media index 04 (10baseT-Full Duplex).
  21041 media index 01 (10base2).
  Internal autonegotiation state is 'Autonegotiation disabled'.

Also get the following repeatedly output to system log after sending a few
packets:
kernel: eth0: 21041 transmit timed out, status fc670055,
CSR12 000001c8, CSR13 ffffef05, CSR14 ffffff3f, resetting... 

>> rtl8139.c:v1.04 9/22/98 Donald Becker
>> http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html
>>
>> eth0: RealTek RTL8139 Fast Ethernet (mislabeled) at 0xd000, IRQ 11,
>> 00:10:b5:3e:e9:8d.
>>    PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks.
>  This is one sign of a BIOS not expecting bus masters.
FWIW boot-up messages from Tulip card are as follows:
tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov
eth0: Digital DC21041 Tulip at 0xd000, 21041 mode, 00 80 c8 44 18 12, IRQ 11.
eth0:21041 Media information at 30, default media 0800 (Autosense).
eth0:  21041 media #0, 10baseT.
eth0:  21041 media #0, 10baseT.
eth0:  21041 media #0, 10baseT.
  PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks.

>>  Interrupt sources are pending.
>>    Rx Complete indication.
>>    Transmit OK indication.
> Hmmm, that is reporting that interrupts are not getting though.
> Check /proc/interrupts to see if this is true.
> >         Interrupt: pin A routed to IRQ 11
It would appear that you are correct about interrupts not getting
through (assuming the integer value in /proc/interrupts is an interrupt count). 
/proc/interrupts:
           CPU0
  0:     166091          XT-PIC  timer
  1:       5395          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:          0          XT-PIC  serial
  4:      10421          XT-PIC  serial
  5:          1          XT-PIC  soundblaster
  8:          2          XT-PIC  rtc
 11:          0          XT-PIC  eth0
 13:          1          XT-PIC  fpu
 14:      10431          XT-PIC  53c7,8xx
NMI:          0

FWIW, BIOS setting for ethercard (PCI slot #3) is:
Slot 3 Using Int #A
    INTA# Connect IRQ: 11, Level

Any suggestions as to why this might be (or indeed what I can do about it)? As
a last resort I could, conceivably, trade the PCI ether card in for an ISA
one, but would that avoid the IRQ problem (assuming that is what I have here)?
-- 
Steve
 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.