From owner-freebsd-stable@FreeBSD.ORG Sat Apr 30 06:42:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1874E106564A; Sat, 30 Apr 2011 06:42:13 +0000 (UTC) (envelope-from bsd@vink.pl) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB0038FC08; Sat, 30 Apr 2011 06:42:12 +0000 (UTC) Received: by pwj8 with SMTP id 8so2698045pwj.13 for ; Fri, 29 Apr 2011 23:42:12 -0700 (PDT) Received: by 10.68.7.41 with SMTP id g9mr6367331pba.148.1304145732122; Fri, 29 Apr 2011 23:42:12 -0700 (PDT) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx.google.com with ESMTPS id u1sm2399145pbm.41.2011.04.29.23.42.11 (version=SSLv3 cipher=OTHER); Fri, 29 Apr 2011 23:42:12 -0700 (PDT) Received: by pvg11 with SMTP id 11so3399305pvg.13 for ; Fri, 29 Apr 2011 23:42:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.40.65 with SMTP id v1mr6356392pbk.154.1304145731232; Fri, 29 Apr 2011 23:42:11 -0700 (PDT) Received: by 10.68.42.40 with HTTP; Fri, 29 Apr 2011 23:42:11 -0700 (PDT) In-Reply-To: References: <201104281728.37497.jhb@freebsd.org> Date: Sat, 30 Apr 2011 08:42:11 +0200 Message-ID: From: Wiktor Niesiobedzki To: Jack Vogel , John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 06:42:13 -0000 2011/4/29 Wiktor Niesiobedzki : > 2011/4/28 Jack Vogel : >> On Thu, Apr 28, 2011 at 2:28 PM, John Baldwin wrote: >>> >>> On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: >>> > Though they mention that HT MSI windows is disabled. I'm not sure, >>> > whether this matters. >>> >>> Yes, that is probably what breaks this. >>> >>> -- >>> John Baldwin >> >> Opps, missed that, thanks John.=C2=A0 So, disable MSIX and MSI using sys= ctl, >> then the driver should use legacy when it loads. >> >> Still, I'd get a different motherboard, sucks to not have MSIX :( >> > > Thanks for hints. I've disabled MSIX and MSI: > kadlubek# sysctl hw.pci | grep msi > hw.pci.honor_msi_blacklist: 1 > hw.pci.enable_msix: 0 > hw.pci.enable_msi: 0 > Ok, I found other way round about this. I've did some source code reading and found following tunable: hw.em.enable_msix=3D0 When set in loader.conf to 0, then the card magically starts to work properly. The only thing in our code in em_setup_msix(), that raises my doubts, is the following code path: int rid =3D PCIR_BAR(EM_MSIX_BAR); adapter->msix_mem =3D bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); ... bus_release_resource(dev, SYS_RES_MEMORY, PCIR_BAR(EM_MSIX_BAR), adapter->msix_mem); Though manpage for bus_release_resource specifies, that rid needs to be exactly the same, as this returned by bus_alloc_resource. Changing the bus_release_resource to use rid instead of PCIR_BAR(EM_MSIX_BAR) makes the card working, with sysctl settings: hw.pci.enable_msix: 0 hw.pci.enable_msi: 0 instead of hw.em.enable_msix=3D0 The only thing that worries me, that when I don't have MSIX disabled (anyway), then driver succeeds with the MSI-X allocation. Shouldn't we in em_setup_msix check, how many vectors we have allocated with pci_alloc_msix and if this is 0, then fallback to MSI/Legacy? Or maybe pci_alloc_msix should report an error, when no PCIB_ALLOC_MSIX succeded? Cheers, Wiktor Niesiobedzki