From owner-freebsd-stable@FreeBSD.ORG Mon May 2 16:49:31 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 1E74F1065672; Mon, 2 May 2011 16:49:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A78F18FC14; Mon, 2 May 2011 16:49:30 +0000 (UTC) Received: by vws18 with SMTP id 18so5789696vws.13 for ; Mon, 02 May 2011 09:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TxHeE304kzJAdvU5O+n1fTOTfuqXx6coUcVwMUdxCUo=; b=uc/fNvlvmwqpRXcZSyK/SeR0256dro0hCp83CIZKzbcKIE5RR6KFfCMPrkAZi3M2iR 6H4kHJxwRksRJpmP0ahu52QE58Acd4yXssMbyvZjNwSpZLNVM89ia/Xe6Q1lMCjgoNFk pBMAJqSFwh5nGELSVRF/QxYspgErwDq+aT1dQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MaD3j2oHjMkrhDL1QQoBcs0L/8zRRGi2WRWIOaz0f892//HpdcFwkP3JJcaUT1Tk5U 7waHI42KlUkmdLmDR1c4k6na8Oi02zrddJ3IzvmmiRjBEXL+qXqZWRWtW47soc+z2uZk uvQXTs+f3pndv0Jp0ug3cMG6Fzx8Iv1VMTcJs= MIME-Version: 1.0 Received: by 10.52.180.234 with SMTP id dr10mr3175488vdc.124.1304354969545; Mon, 02 May 2011 09:49:29 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Mon, 2 May 2011 09:49:29 -0700 (PDT) In-Reply-To: <201105021001.05568.jhb@freebsd.org> References: <201105021001.05568.jhb@freebsd.org> Date: Mon, 2 May 2011 09:49:29 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Wiktor Niesiobedzki 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 16:49:31 -0000 Thanks John. Was gonna say... the code has been as it is forever, with everyone else in the world working fine, figured something odd was going on. Jack On Mon, May 2, 2011 at 7:01 AM, John Baldwin wrote: > 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 >