From owner-freebsd-current@FreeBSD.ORG Wed Mar 11 00:34:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83773106566C for ; Wed, 11 Mar 2009 00:34:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2A78FC12 for ; Wed, 11 Mar 2009 00:34:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so2678562rvb.43 for ; Tue, 10 Mar 2009 17:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=1VJTfw6xpFxyn7wCNufF8iDfQm88kiWKAW05GxrJJWU=; b=CusTiv/jjs7yAqPGoGqG++30KvY0fyOWC0HVv08I2Q7XfA7fZA4TfqtD09shnHGeGl QeP0NzVyIoMT3sDK575GhWZGa44v6JO7N4yx09fDiYNDczkKoPbK8ZgC3boih3bzU4eN AP254tOExDSJWNwt8LFXplI4WXAGUb4Qjq360= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=itjqKZDAK7HoYARqM2fiw64esOSsOcMw0bmf6kHyS4mFnkue81u1kis3vzIKohmxmF secEN72zj6KunTJhfcZp3iixdiQa9zkdDMpZEElonqXZPd9BNjbXpYxz4V+es/dSdKXf +8cSXIVIp+GUFQsCqquMYmdfDNJhAf6K4xVZ0= Received: by 10.141.142.15 with SMTP id u15mr4053084rvn.16.1236731652933; Tue, 10 Mar 2009 17:34:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b8sm11326181rvf.8.2009.03.10.17.34.10 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Mar 2009 17:34:11 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Wed, 11 Mar 2009 09:32:44 +0900 From: Pyun YongHyeon Date: Wed, 11 Mar 2009 09:32:44 +0900 To: Robert Noland Message-ID: <20090311003244.GA13527@michelle.cdnetworks.co.kr> References: <200903101425.28608.jhb@freebsd.org> <200903101637.31039.jhb@freebsd.org> <1236728841.2091.5.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236728841.2091.5.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, "Arno J. Klaassen" Subject: Re: msi broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 00:34:13 -0000 On Tue, Mar 10, 2009 at 06:47:21PM -0500, Robert Noland wrote: > On Wed, 2009-03-11 at 00:36 +0100, Arno J. Klaassen wrote: > > John Baldwin writes: > > > > > On Tuesday 10 March 2009 3:00:00 pm Arno J. Klaassen wrote: > > >> John Baldwin writes: > > >> > > >> > On Tuesday 10 March 2009 10:08:59 am Arno J. Klaassen wrote: > > >> >> > > >> >> Hello, > > >> >> > > >> >> when upgrading this morning from a March 1 -current, if_bge > > >> >> stopped working (and irq256: bge0 not showing up in > > >> >> vmstat -i ). Setting hw.pci.enable_msi="0" makes it work again. > > >> > > > >> > Can you get a verbose dmesg (boot -v) with MSI enabled? > > > > > > Ok, so you are getting MSI interrupts assigned and routed ok. Can you try > > > disabling the code that sets the INTx_MASK flag in the PCI command register > > > in sys/dev/pci/pci.c:pci_setup_intr()? > > > > grr : "rid" sure is 1 for the if_bge interrupt. Please tell me which > > lines of code set the INTx_MASK flag. Thanx, more tomorrow. > > if rid is 0, the chip should be using INTx. if rid > 0 then it should > be using MSI. > > > } > mte->mte_handlers++; > } > #if 0 /* Comment this out/* > /* Make sure that INTx is disabled if we are using MSI/MSIX */ > pci_set_command_bit(dev, child, PCIM_CMD_INTxDIS); > #endif > bad: > if (error) { > (void)bus_generic_teardown_intr(dev, child, irq, > cookie); > return (error); > If my memory serve me right, some Broadcom controllers reset PCI configuration registers in bge_reset() so bge(4) restores some important PCI configuration registers. I didn't check bge(4) code but it's possible that bge(4) didn't restore MSI enable bit in bge_reset().