From owner-freebsd-current@FreeBSD.ORG Wed Mar 11 13:47:26 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F82C106564A; Wed, 11 Mar 2009 13:47:26 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id CE2B98FC1E; Wed, 11 Mar 2009 13:47:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n2BDlMsa038366 ; Wed, 11 Mar 2009 14:47:23 +0100 (CET) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n2BDlL7u002191; Wed, 11 Mar 2009 14:47:21 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n2BDlKZM002188; Wed, 11 Mar 2009 14:47:20 +0100 (CET) (envelope-from arno) To: Scott Long From: "Arno J. Klaassen" References: <200903101425.28608.jhb@freebsd.org> <200903101637.31039.jhb@freebsd.org> <1236728841.2091.5.camel@balrog.2hip.net> <49B700AD.7010500@samsco.org> Date: Wed, 11 Mar 2009 14:47:20 +0100 In-Reply-To: <49B700AD.7010500@samsco.org> (Scott Long's message of "Tue\, 10 Mar 2009 18\:07\:09 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.jussieu.fr [134.157.0.166]); Wed, 11 Mar 2009 14:47:23 +0100 (CET) X-Virus-Scanned: ClamAV 0.94.2/9091/Wed Mar 11 11:50:28 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 49B7C0EA.008 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 49B7C0EA.008/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 49B7C0EA.008 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.005 -> S=0.005 X-j-chkmail-Status: Ham Cc: pyunyh@gmail.com, current@freebsd.org, Robert Noland Subject: Re: msi broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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 13:47:26 -0000 Scott Long writes: > 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); >> >> robert. >> > > If this turns out to help this particular gentleman, yes it does ;) with otherwise clean sources sorry I did not understand directly what you asked me to do > then I'd like to > suggest a further test of having the bge driver explicitly reset the > the INTxDIS bit after calling bus_setup_intr(). If that works, then I > strongly suggest that we treat this as a localized quirk that drivers > will need to manage for themselves, and not something that the PCI layer > should try to control. It might be possible to set up some sort of > hint system for drivers to programatically tell the PCI layer to treat > this bit special for a particular device instance. What I don't want > to see is the PCI layer growing yet another hidden quirk table of > PCI IDs. This kind of quirk knowledge belongs in the driver. iff you'd like I can test things on this board for a while ... Thank you very much, Arno