[eepro100] sgi 320 visws and eepro100

Jim Edwards jedwards@inmet.gov.br
Tue, 22 May 2001 13:39:42 +0000


Hi again,

I've updated to the v1.15 driver and compiled using -DUSE_IO_OPS,   I'm not getting the same messages (see the previous
posting below) from the driver any longer but I still have some very strange network problems happening.  For example
here is a little output from a ping of our local nameserver.   Note the sequence in which things are returned.

PING modelo.inmet.gov.br (192.168.99.22) from 192.168.99.91 : 56(84) bytes of data.
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=0 ttl=64 time=224 usec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=18 ttl=64 time=141 usec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=19 ttl=64 time=135 usec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=20 ttl=64 time=187 usec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=1 ttl=64 time=18.987 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=2 ttl=64 time=17.990 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=3 ttl=64 time=16.982 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=4 ttl=64 time=15.985 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=5 ttl=64 time=14.988 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=6 ttl=64 time=13.991 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=7 ttl=64 time=12.994 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=8 ttl=64 time=11.986 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=9 ttl=64 time=10.989 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=10 ttl=64 time=9.992 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=11 ttl=64 time=8.995 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=12 ttl=64 time=7.988 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=13 ttl=64 time=6.990 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=14 ttl=64 time=5.993 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=15 ttl=64 time=4.996 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=16 ttl=64 time=3.989 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=17 ttl=64 time=2.991 sec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=40 ttl=64 time=142 usec
64 bytes from modelo.inmet.gov.br (192.168.99.22): icmp_seq=21 ttl=64 time=19.424 sec

This is what I get when I install the module.   Any ideas where I should look next?


May 22 10:33:12 capre kernel: eepro100.c:v1.15 5/18/2001 Donald Becker <becker@scyld.com>
May 22 10:33:12 capre kernel:   http://www.scyld.com/network/eepro100.html
May 22 10:33:12 capre kernel: eth0: Intel PCI EtherExpress Pro100 at 0xa100, 08:00:69:12:DE:3F, IRQ 19.
May 22 10:33:12 capre kernel:   Board assembly 123456-120, Physical connectors present: RJ45
May 22 10:33:12 capre kernel:   Primary interface chip DP83840 PHY #1.
May 22 10:33:12 capre kernel:   DP83840 specific setup, setting register 23 to ffff.
May 22 10:33:12 capre kernel:   General self-test: passed.
May 22 10:33:12 capre kernel:   Serial sub-system self-test: passed.
May 22 10:33:12 capre kernel:   Internal registers self-test: passed.
May 22 10:33:12 capre kernel:   ROM checksum self-test: passed (0x49caa8d6).
May 22 10:33:12 capre kernel:   Receiver lock-up workaround activated.
May 22 10:33:19 capre sysctl: net.ipv4.ip_forward = 0
May 22 10:33:19 capre sysctl: net.ipv4.conf.all.rp_filter = 1
May 22 10:33:19 capre sysctl: net.ipv4.ip_always_defrag = 0
May 22 10:33:19 capre sysctl: error: 'kernel.sysrq' is an unknown key
May 22 10:33:19 capre network: Setting network parameters:  succeeded
May 22 10:33:20 capre network: Bringing up interface lo:  succeeded
May 22 10:33:20 capre kernel: IRQ 19, Cobalt APIC Entry 3, IDT Vector e9: enabling
May 22 10:33:20 capre network: Bringing up interface eth0:  succeeded



Jim Edwards wrote:

> Hi,
>
> I've been fighting this battle on my own for a couple of weeks now and
> it's time to ask for help.  I have an sgi320 visual workstation platform
> - it is an unusual machine in that it runs a pentium chip but most of
> the other components are more typical of sgi architectures.  I am
> running linux kernel 2.2.10 with patchs provided by sgi and a few bug
> fixes that came in kernel patchs up to 2.2.17.  This machine is not
> supported in newer kernels because sgi pulled their support and no-one
> in the kernel development community has one to work with.   It's also a
> 2 proc SMP.
>
> With the original eepro100 driver (from kernel 2.2.17) under heavy usage
> (such as serving X or running multiple ftps) I get the following
> message:
>
> > kernel: eth0: card reports no resources.
> >
> With the latest driver from  http://www.scyld.com/network/eepro100.html
> loaded as a module I get
>
> > May 16 11:12:37 ndpndes kernel: eepro100.c:v1.13 1/9/2001 Donald Becker
> > May 16 11:12:37 ndpndes kernel:   http://www.scyld.com/network/eepro100.html
> > May 16 11:12:37 ndpndes kernel: eth0: Invalid EEPROM checksum 0x423c, check settings before activating this device!
> > May 16 11:12:37 ndpndes kernel: eth0: OEM i82557/i82558 10/100 Ethernet at 0xe9834000, FD:C7:3F:C8:7B:05, IRQ 19.
> > May 16 11:12:37 ndpndes kernel:   Receiver lock-up bug exists -- enabling work-around.
> > May 16 11:12:37 ndpndes kernel:   Board assembly 96f6fe-099, Physical connectors present: RJ45 MII
> > May 16 11:12:37 ndpndes kernel:   Primary interface chip i82553-A/B PHY #16.
> > May 16 11:12:37 ndpndes kernel:     Secondary interface chip i82553-A/B.
> > May 16 11:12:37 ndpndes kernel: Self test failed, status ffffffff:
> > May 16 11:12:37 ndpndes kernel:  Failure to initialize the i82557.
> > May 16 11:12:37 ndpndes kernel:  Verify that the card is a bus-master capable slot.
> > May 16 11:12:37 ndpndes kernel:   Receiver lock-up workaround activated.
> >
> >
> But the eepro100-diag program run with -ee suggests that the eeprom
> checksum is okay:
>
> > ./eepro100-diag -ee
> > eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
> >  http://www.scyld.com/diag/index.html
> > Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xa100.
> > EEPROM contents, size 64x16:
> >     00: 0008 1369 693c 0000 0000 0101 4401 0000
> >   0x08: 1234 5678 0000 0004 8086 0000 0000 0000
> >       ...
> >   0x38: 0000 0000 0000 0000 0000 0000 0000 0fd5
> >  The EEPROM checksum is correct.
> > Intel EtherExpress Pro 10/100 EEPROM contents:
> >   Station address 08:00:69:13:3C:69.
> >   Receiver lock-up bug exists. (The driver work-around *is* implemented.)
> >   Board assembly 123456-120, Physical connectors present: RJ45
> >   Primary interface chip DP83840 PHY #1.
> >   Transceiver-specific setup is required for the DP83840 transceiver.
> >
> Finally one more piece of info:
>
> > ./eepro100-diag -aa
> > eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
> >  http://www.scyld.com/diag/index.html
> > Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xa100.
> > i82557 chip registers at 0xa100:
> >   00000000 00000000 00000000 00080002 1821782d 00000000
> >   No interrupt sources are pending.
> >    The transmit unit state is 'Idle'.
> >    The receive unit state is 'Idle'.
> >   This status is unusual for an activated interface.
> >
>
> Can anyone help me figure this out?
>
> thanks,
> Jim
>
> _______________________________________________
> eepro100 mailing list
> eepro100@scyld.com
> http://www.scyld.com/mailman/listinfo/eepro100