From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:36:35 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 10B2E1065678 for ; Mon, 2 May 2011 14:36:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D90788FC18 for ; Mon, 2 May 2011 14:36:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8F23246B49; Mon, 2 May 2011 10:36:34 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2AECC8A02E; Mon, 2 May 2011 10:36:34 -0400 (EDT) From: John Baldwin To: Wiktor Niesiobedzki Date: Mon, 2 May 2011 10:01:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105021001.05568.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 02 May 2011 10:36:34 -0400 (EDT) Cc: freebsd-stable@freebsd.org, Jack Vogel 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: Mon, 02 May 2011 14:36:35 -0000 On Saturday, April 30, 2011 2:42:11 am Wiktor Niesiobedzki wrote: > 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. So, disable MSIX and MSI using sysctl, > >> 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=0 > > 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 = PCIR_BAR(EM_MSIX_BAR); > adapter->msix_mem = 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. In practice the rid is not changed for PCI resources, so the code is fine. > 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=0 > > 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? Well, the problem here is that PCIB_ALLOC_MSIX() worked fine. There is another bug that is breaking MSI in your system that I need to finish the fix for in 9 before it can be MFC'd. -- John Baldwin