From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 01:42:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23AEF16A4CE for ; Sun, 24 Oct 2004 01:42:33 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F6E543D3F for ; Sun, 24 Oct 2004 01:42:32 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from [192.168.0.100] (eiterra.achedra.org [192.168.0.100]) by error404.nls.net (8.12.10/8.12.10) with ESMTP id i9O1gPqP016822; Sat, 23 Oct 2004 21:42:25 -0400 (EDT) (envelope-from ketrien@error404.nls.net) Message-ID: <417B08B5.8080208@error404.nls.net> Date: Sat, 23 Oct 2004 21:43:17 -0400 From: "Ketrien I. Saihr-Kesenchedra" User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: soralx@cydem.org, hackers@freebsd.org References: <200410132110.09915.soralx@cydem.org> <200410220216.54868.soralx@cydem.org> <20041022175311.GA15960@odin.ac.hmc.edu> <200410231047.44788.soralx@cydem.org> In-Reply-To: <200410231047.44788.soralx@cydem.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Linksys PCM200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 01:42:33 -0000 soralx@cydem.org wrote: >I've done a little testing under various loads. The driver switches >chip to store and forward mode soon during initial use after attaching >(I also get few messages about watchdog timeouts together with >"increasing TX threshold"). But it seems to work OK. >I haven't done any serious performance testing (maximum speed it >could reach was ~ 5Mb/s on 100baseTX/FD) nor attach/detach tests. > > That sounds about right. I don't have time to figure out a patch, since I've not figured out if_de's quirk handling, but you may want to try treating this card like a Cobalt Networks. I'm presuming (haven't watched the thread that closely) that it's a straight MII versus Cobalt's MII-on-SIO. > <>I don't see a way how it could break other cards' functionality - > should be no concerns here D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08. >I don't see a real reson not to use more complete description. There are few resons to use it: > >0. More info is _always_ better. In any case, the message will take 2 lines on console, so shortening the description will not gain anything > > Yes, it does. It gains readability. Long descriptions should generally be reserved for pciconf -lv and driver comments. The AL985C as found on the D-Link PCM200 should be identical to the AboCom FE2500MX. (The only difference I've seen between the two is that the FE2500MX has AboCom's VendorID. Also; AboCom makes an AL985C called the PCM200. Draw your own conclusions.) > <>1. the description in `pciconf -lv` does not show card's version and > chipset No, it doesn't, and really shouldn't. The revision is read from card SROM or set in the RevID, e.g. 0x03 or 0xa3, etcetera. > <>2. when PCI IDs for previous card versions will be added, the > description will > need to be changed anyway to include the version number Only because D-Link has a 'change everything except the model name' fetish. Unless D-Link pulled the same crap they did with the DWL-520 and DWL-650, personally I don't see any compelling reason to include chipset and revision in the dev's desc. Now, if D-Link pulled the same crap on this as they did with the DWL-520, I'd say just slap Rev.D in there; there's no need for chipset name, and it's enough to differentiate from Rev.C1 which uses some other chipset. But hey, just my $0.02USD (or ~$0.0158247EUR at current exchange rates.) -ksaihr