From owner-freebsd-net@FreeBSD.ORG Sat May 2 23:15:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E09106566C for ; Sat, 2 May 2009 23:15:32 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 136D08FC08 for ; Sat, 2 May 2009 23:15:31 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so2914253ewy.43 for ; Sat, 02 May 2009 16:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=xv/E9JmKhquvzRxiuZhXGpE6BU65qH9EKM73fKJi88U=; b=ctLzIM0Xme8A6/nOey4gMAFnhJxAmF9rstalW+AnYCr4LtSmuunNFuXOCCrs8BtsB3 E8N05OUj7mXRhjcnI+hOgeDNP1eUWf3AFSO7UxTTqSuAyZftNh0IT8NrCLPoOjRvxYoZ kYluNJ1S2giBqHDV/uPqQKTtZQcdXwnSve0sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ilqpobcZ0I1VINzJYVGrUn8hTsAS85IbkiLoMDVAYK/SIP6OX4AIALUzh0EM3gMA3u L27wdiWHRLVYkogp2oMgFeikzL7zGmQRexYSy6tjrS40fcNnzub3xGfGDHCFq8JF0KWM LJGzFw5HszdVLaUvGIOc2bgZKZ5i8b93JdOg0= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.57.3 with SMTP id f3mr4456250eba.12.1241306131082; Sat, 02 May 2009 16:15:31 -0700 (PDT) In-Reply-To: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> From: Ivan Voras Date: Sun, 3 May 2009 01:15:16 +0200 X-Google-Sender-Auth: ca3ab27b44ebad0e Message-ID: <9bbcef730905021615l21ef8a73hf26aca18f3230c3b@mail.gmail.com> To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" 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: Sat, 02 May 2009 23:15:33 -0000 2009/5/2 Jack Vogel : > I'm willing to bet that its in fact the same problem that VMWare is having. > Our method of getting the mac address changed, and the emulations seem > to be unprepared for it. > > This was done for a real customer requirement to allow support of alternate > mac addressing in firmware. What happens now is a warm reset of the hardware > is done, followed by reading the RAR[0] register. In a real Intel NIC the > mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? Here's the information on all three: em0: port 0xc060-0xc067 mem 0xf0820000-0xf083ffff irq 16 at device 8.0 on pci0 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: port 0xc068-0xc06f mem 0xf0840000-0xf085ffff irq 17 at device 9.0 on pci0 em1: Invalid MAC address device_attach: em1 attach returned 5 em2: port 0xc070-0xc077 mem 0xf0860000-0xf087ffff irq 18 at device 10.0 on pci0 em2: Invalid MAC address device_attach: em2 attach returned 5 em0@pci0:0:8:0: class=0x020000 card=0x001e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em1@pci0:0:9:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em2@pci0:0:10:0: class=0x020000 card=0x075015ad chip=0x100f8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82545EM Gigabit Ethernet Controller (copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work on > it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. I think that would be a losing battle wrt future developments of both the driver and the VM environments (too fragile state; anyway, other OSes don't have the issue so why should we?). I don't really know how it works but couldn't you use the information talked about earlier (register is 0 after a warm reset) to detect the general class of the problem and if detected conditionally proceed with the old code / behaviour just for the initialization part? Another possible route is to make use of VM detection present in HEAD and just blindly use the old way if a VM environment is detected. I think this is only slightly less bad than forking the driver since new VM platforms are appearing all the time - is something like the middle option doable?