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>