Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Dec 1999 23:01:25 -0600 (CST)
From:      Mohit Aron <aron@cs.rice.edu>
To:        wes@softweyr.com (Wes Peters)
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: new Intel 100Mbps card
Message-ID:  <199912060501.XAA25613@cs.rice.edu>
In-Reply-To: <384B21D1.415FD524@softweyr.com> from "Wes Peters" at Dec 5, 99 07:39:13 pm

next in thread | previous in thread | raw e-mail | index | archive | help

> 
> It's probably an 82558 chip.  Does it support Wake-on-LAN?
> 

Not sure what Wake-on-LAN means. I believe there are some cards out there
now that support some kind of network management. This is not that if that 
helps.

> 
> Add the device IDs to the list in the driver and recompile.  If it works, 
> send me the diffs and I'll commit it for you.  I might even be able to beat 
> one of the cards out of Intel, I used to work for the InBusiness (formerly 
> Dayna Communications) crowd.  ;^)
> 

Like I said in my last mail, I've already done that. It works. Here are the
patches for FreeBSD-4.0-19990827-CURRENT. Please note that I tested it out
on FreeBSD-2.2.6 and ported it to FreeBSD-4.0-19990827-CURRENT (I don't have
root on a FreeBSD-4.0-19990827-CURRENT machine). Also please read the results
of some tests that I've done on the card - they're discussed after the patch
below.
---------------------------  Cut Here -----------------------------------------
diff -ur /sys/pci/if_fxp.c pci/if_fxp.c
--- /sys/pci/if_fxp.c   Tue Jul  6 14:23:25 1999
+++ pci/if_fxp.c        Sun Dec  5 22:33:33 1999
@@ -501,10 +501,20 @@
 static int
 fxp_probe(device_t dev)
 {
-       if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) &&
-           (pci_get_device(dev) == FXP_DEVICEID_i82557)) {
-               device_set_desc(dev, "Intel EtherExpress Pro 10/100B
Ethernet");
-               return 0;
+       if (pci_get_vendor(dev) == FXP_VENDORID_INTEL) {
+               switch (pci_get_device(dev)) {
+               case FXP_DEVICEID_i82557:
+                       device_set_desc(dev,
+                                   "Intel EtherExpress Pro 10/100B Ethernet");
+                       return 0;
+
+               case FXP_DEVICEID_i82558:
+                       device_set_desc(dev,
+                                       "Intel InBusiness 10/100 Ethernet");
+
+                       return 0;
+               }
+               
        }
 
        return ENXIO;
diff -ur /sys/pci/if_fxpreg.h pci/if_fxpreg.h
--- /sys/pci/if_fxpreg.h        Thu Feb 11 17:41:21 1999
+++ pci/if_fxpreg.h     Sun Dec  5 22:29:13 1999
@@ -29,6 +29,7 @@
 
 #define FXP_VENDORID_INTEL     0x8086
 #define FXP_DEVICEID_i82557    0x1229
+#define FXP_DEVICEID_i82558    0x1030
 
 #define FXP_PCI_MMBA   0x10
 #define FXP_PCI_IOBA   0x14
---------------------------  Cut Here -----------------------------------------


I tested out the card by doing some long TCP transfers over it on a LAN.  It
seems to work fine but once in a while (1 in 1000 packets approximately), it
seems to receive truncated IP packets. I have thoroughly tested this out - the
sending host is not sending any truncated packets. The problem only lies on the
receiving host - the one that's using the new card. Also, it seems that the
packet in question is finally received correctly - however the sending host
never transmitted the packet again. It seems the receiving host (the one with
the new card) first gets a truncated packet and then gets the full packet.
I'm attaching a segment of tcpdump trace that demonstrates this problem. The
first and the last packets in this trace are the truncated and full versions
in question. Finally, I must add that I repeated the experiment with two hosts
both having the old 10/100B cards - I didn't see any truncated IP packets. 
However, each time I used the new card, I saw truncated IP packets. I've also
the other Intel InBusiness cards - they all give the same problem (this rules
out the possibility that any one card has a hardware problem).


22:19:26.072982 truncated-ip - 8 bytes missing!192.168.12.103.6500 > 192.168.12.106.1030: . ack 3661249462 win 7920 <nop,nop,timestamp 376766 38388,nop,[|tcp]> (DF)
22:19:26.072995 192.168.12.106.1030 > 192.168.12.103.6500: . 3661250902:3661252342(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073031 192.168.12.106.1030 > 192.168.12.103.6500: . 3661252342:3661253782(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073057 192.168.12.106.1030 > 192.168.12.103.6500: . 3661253782:3661255222(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073082 192.168.12.106.1030 > 192.168.12.103.6500: . 3661255222:3661256662(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073108 192.168.12.106.1030 > 192.168.12.103.6500: . 3661256662:3661258102(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073132 192.168.12.106.1030 > 192.168.12.103.6500: . 3661258102:3661259542(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073158 192.168.12.106.1030 > 192.168.12.103.6500: . 3661259542:3661260982(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073182 192.168.12.106.1030 > 192.168.12.103.6500: . 3661260982:3661262422(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.073206 192.168.12.106.1030 > 192.168.12.103.6500: . 3661262422:3661263862(1440) ack 1511615746 win 17280 <nop,nop,timestamp 38388 376766,nop,nop,eol,[|tcp]> (DF)
22:19:26.074336 192.168.12.103.6500 > 192.168.12.106.1030: . ack 3661249462 win 7920 <nop,nop,timestamp 376766 38388,nop,nop,eol,[|tcp]> (DF)




- Mohit


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912060501.XAA25613>