From owner-freebsd-net@FreeBSD.ORG Tue Sep 26 23:15:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD0AF16A51A for ; Tue, 26 Sep 2006 23:15:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF5943D4C for ; Tue, 26 Sep 2006 23:15:01 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3100366pye for ; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ty0irQ7KqdiHn1RSpGpPAYWMCyAqBKRCuIpmf5/Z18Obgc6LrlGzm9sjryUItk4tkiv0TM0InOJWmQx2ualJI0lha2iURT16pJLvxN0g4Vvgn9evX/b7BctKpjiE6cKW2s3Zh6dB4RMyjl38pFirNS6W11CfA/YMzWeNKUf0igE= Received: by 10.35.62.19 with SMTP id p19mr106253pyk; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Tue, 26 Sep 2006 16:15:00 -0700 (PDT) Message-ID: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> Date: Tue, 26 Sep 2006 16:15:00 -0700 From: "Jack Vogel" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Bug or Design limitation?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 23:15:02 -0000 Our test group just ran into something I hadnt noticed before. Take a system and put in two different multiport NIC boards, one older (PCI-X) and one new PCI-E board. Load a driver that only recognizes the first board. It will show em0, em1, em2, em3, the new ports will be none's. Unload that driver and then load a newer one that recognizes both boards. What you'd expect to see is em0....em7. But what you actually see is two sets of em0 - em3! Our test lead noticed this because it broke some scripts of his. Now, 'ifconfig' gets it right and still presents you with 0-7. If you load the newer driver first then of course all is correct. So, the question is, is this a bug? Clearly the enumerated data from the older driver loaded is staying around. I do not know how this kernel data is handled, so could/should it be removed and isnt or what? Cheers, Jack