From owner-svn-src-all@FreeBSD.ORG Mon Jul 29 21:23:14 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1D91C49B; Mon, 29 Jul 2013 21:23:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCCE92192; Mon, 29 Jul 2013 21:23:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 96FAAB94A; Mon, 29 Jul 2013 17:23:12 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Subject: Re: svn commit: r253708 - head/sys/dev/ipmi Date: Mon, 29 Jul 2013 17:22:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307271632.r6RGWYF8046749@svn.freebsd.org> <1375127952.1479.32.camel@localhost> <1375129288.1479.36.camel@localhost> In-Reply-To: <1375129288.1479.36.camel@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307291722.27017.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 29 Jul 2013 17:23:12 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:23:14 -0000 On Monday, July 29, 2013 4:21:28 pm Sean Bruno wrote: > On Mon, 2013-07-29 at 12:59 -0700, Sean Bruno wrote: > > On Mon, 2013-07-29 at 10:54 -0400, John Baldwin wrote: > > > On Saturday, July 27, 2013 12:32:34 pm Sean Bruno wrote: > > > > Author: sbruno > > > > Date: Sat Jul 27 16:32:34 2013 > > > > New Revision: 253708 > > > > URL: http://svnweb.freebsd.org/changeset/base/253708 > > > > > > > > Log: > > > > At some point after stable/7 the ACPI and ISA interfaces to the IPMI controller > > > > no longer have the parent in the device tree. This causes the identify > > > > function in ipmi_isa.c to attempt to probe and poke at the ISA IPMI interface > > > > > > They never had a common parent, even in 6.x and 7.x. > > > > > The identify function in isa_ipmi.c shows that there is already an > > ipmi(4) device attached (ACPI) version and aborts on 7.x. in 9.x and > > higher (not testing on 8.x) the identify function does not see an > > attached ipmi interface and attempts to create /dev/ipmi1 > > > > Am I just confused on the bus relationship here? > > > > We've gone over this a couple of times in different emails on different > > lists. I've just never sat down and walked through the code. If you > > see a better way to keep ipmi(4) from erroneously attaching to the ISA > > interface, let me know. > > > Or ... ya know, I could just be 100% wrong? > > stable/7 attaches to an /dev/ipmi1 as well on these Dell R410 units. > *sigh* > > http://people.freebsd.org/~sbruno/ipmi_sean_is_wrong.txt It doesn't attach. Read the second line here: ipmi1: on isa0 device_attach: ipmi1 attach returned 16 Do you have an actual /dev/ipmi1 file if you login to this machine and look in /dev? > so, the modification I made does resolve the "ipmi1" thing alltogether > and is correct (AFAIK), but should be applied to all revisions, not just > 9/head. > > Or, am I wrong again? :-) The change you made is purely cosmetic. It just moves the check slightly earlier to hide the message. If you want to hide the message, put the ipmi_attached check in the ipmi_isa_probe() routine (the other frontend look in probe(), not attach()). However, that is purely a comsetic issue that should just remove the two printfs, it should not have _any_ affect on getting NMI's from your bce(4) adapter. -- John Baldwin