From owner-freebsd-net@FreeBSD.ORG Fri Jun 26 18:36:40 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 08F19106567E for ; Fri, 26 Jun 2009 18:36:40 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAD18FC24 for ; Fri, 26 Jun 2009 18:36:38 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MKGHt-0001UQ-Cp for freebsd-net@freebsd.org; Fri, 26 Jun 2009 18:36:37 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jun 2009 18:36:37 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jun 2009 18:36:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.devel.net Date: Fri, 26 Jun 2009 11:36:26 -0700 Lines: 64 Message-ID: References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.99.01 Sender: news 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: Fri, 26 Jun 2009 18:36:40 -0000 Jack Vogel wrote: > 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? > > 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. > > In any case, I intend to have this problem resolved for 8's release. Stay > tuned. Just FYI. this is a real machine with real cards. Older fiber cards. em0: mem 0xdb000000-0xdb01ffff irq 28 at device 4.0 on pci19 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: mem 0xdb020000-0xdb03ffff irq 29 at device 9.0 on pci19 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 em1: Invalid MAC address device_attach: em1 attach returned 5 $ pciconf -v -l |grep -A4 -e "^em" em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired);