Monkey boy needs help! Transmit timed out:...

[Gisli Ottarsson]

Gerhard:

In response to your comments, I have migrated the eepro100 in question
to my ASUS P2B-D based machine where it worked with v1.09t, right off
the bat.  Unfortunately, the Netgear card (Tulip) that used to live in
on the ASUS board is now refusing to play ball in the 486.  Symptoms
are different than with eepro100.  No timeout messages but a dead ping.

Although I am aware that this is the wrong forum for Tulip
discussions, (besides, this is probably an Intel Saturn issue), I feel
that I should not depart without providing some additional info, in
case it might help someone help me or be useful in some other way.

Before I start spewing diagnostics, a couple of questions.

  1) Could the more experienced of you please tell me if you think
     this 486 is a lost cause?  Have better men than me fought battles
     with old PCI busses and lost?  It sounds like Gerhard did.

  2) Am I stupid, overlooking something simple?

  3) Is there any sense in taking this to the Tulip list?

Diagnostics below, thanks for any help.  

  Gisli

Here are the diagnostics from the Netgear/Saturn combo.

Netgear board is recognized at boot time:

 tulip.c:v0.89H 5/23/98 becker@...
 eth0: Lite-On 82c168 PNIC at 0xd00, 00 a0 cc 3d 7d c0, IRQ 11
 eth0:  MII tranceiver found at MDIO address, config 1000 status 782d.
 eth0:  Advertising 01e1 on PHY 1, previously advertising 01e1  

Upon login I try to ping network peers and get no response.

Tulip-diag says:

tulip-diag.c:v1.19 10/2/99 Donald Becker
 Port selection is MII, 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 02678056.
  Tx complete indication.
  Tx out of buffers indication.
  Linx passed indication.
  Rx Done indication.
 MII PHY ound at address 1, status 0x782d.
 MII PHY #1 transceiver registers:
   1000 782d 7810 0000 01e1 0081 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 4000 0000 28c8 0010 0000 0002
   0081 0000 0000 0000 0000 0000 0000 0000.

Meanwhile, ifconfig tells me:

eth0    Link encap:Ethernet  HWaddr ...
        inet addr:10.0.0.3 Bcast:10.255.255.255  Mask:255:255:255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
        Interrupt:11 Base address:0xd000



>>>>> On Sun, 24 Oct 1999 10:06:25 +0200, you said:
 
  GS> On Sat, Oct 23, 1999 at 14:14 -0400, Gisli Ottarsson wrote:
  >> 
  >> Please help me solve my eepro100 problem which I outline below.
  >> 
  >> Hardware:
  >> 
  >> Doorstop 486 PCI, Intel Saturn motherboard, 16Mb RAM :-(
  >> Intel 82557 EtherExpressPro100B 

  GS> Did the card EVER work in this computer?  I used to have a
  GS> similar problem with an ASUS SP3 (not G!) which I reported here
  GS> almost two years ago and couldn't find any solution for.  This
  GS> machine even refused to boot as soon as any 3com PCI card was in
  GS> it (3c590, 3c900, 3c905).  With the eepro100b (82557) it booted
  GS> and the DOS diag worked great (i.e. transmitted more than one
  GS> million packets with only one error for the first packet which
  GS> established the test).  But as soon as I started to USE this
  GS> interface under Linux I got these "transmit timed out"s which
  GS> there was NO cure for.  PCI bridge optimization, multicast
  GS> filter, several driver versions, different kernel -- nothing made
  GS> the card work (I had two of them and swapped them and both are
  GS> doing great in other machines now).

  GS> There must be some bug either in the hardware of the mobo or the
  GS> BIOS (which I updated to the latest available version 2.07).
  GS> Back in 1994 I had problems, too, with the graphics board:  model
  GS> SPEA mirage (S3 864 and DRAM) made the machine go extremely slow,
  GS> model mercury (S3 964 and VRAM) worked and still workes.  The
  GS> onboard NCR scsi controller never caused any problems.


  GS> I'm sorry if that's not the answer you wanted to hear, but I felt
  GS> this is a point to clear up at first:  did you ever see the card
  GS> work in THIS environment?


  GS> virtually yours - Gerhard Sittig
  GS> -- 
  GS> If you don't understand or are scared by any of the above
  GS>         ask your parents or an adult to help you.