From owner-freebsd-hardware@FreeBSD.ORG Thu Mar 4 04:44:46 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26B6D16A4CE for ; Thu, 4 Mar 2004 04:44:46 -0800 (PST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE4443D39 for ; Thu, 4 Mar 2004 04:44:45 -0800 (PST) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp190-27.lns1.bne1.internode.on.net [150.101.190.27])i24Cihwn074402; Thu, 4 Mar 2004 23:14:43 +1030 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.12.8p2/8.11.6) with ESMTP id i24CieBN013941; Thu, 4 Mar 2004 22:44:42 +1000 (EST) (envelope-from mckay) Message-Id: <200403041244.i24CieBN013941@dungeon.home> To: freebsd-hardware@freebsd.org Date: Thu, 04 Mar 2004 22:44:40 +1000 From: Stephen McKay cc: Stephen McKay Subject: D-Link DGE-530T NIC X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 12:44:46 -0000 Hi! I've hacked the sk driver to support D-Link's DGE-530T gigabit NIC. Nothing fancy; basically I cloned the 3Com 3C940 case and put in the right PCI IDs for the D-Link. After checking the linux driver, that looks like it was the correct approach. The problem I now have is that my DGE-530T appears to have a completely blank VPD (Vital Product Data) EEPROM. Every byte reads as 0xff. Does anybody know if this is normal? This causes the driver to output: skc0: bad VPD resource id: expected 82 got ff skc0: (null) The driver works just fine after this, and the VPD is only used to print the product name (which is stored there along with other stuff). The 3Com 3C940 which is onboard my Asus P4P800 motherboard has a valid VPD and the product name is printed for it, so at least some clones do it properly. If a blank VPD is a somewhat normal case, I'll put in code to ignore it if it reads as 0xff. I've already put in code to not print "(null)" when reading the VPD fails. After I've got this sorted, I can commit the changes. Well, after I've rebuilt my -current box, which had an undignified death recently (so this was all done on 4.9). By the way, it's too early to tell if this card is the bottleneck or not when I did a quick performance test. A P4 2.8GHz with 3C940 sending to an Athlon 1.2GHz with DGE-530T got about 60MB/s using ttcp. Only 20MB/s when disks were involved (using ftp). Stephen.