Date: Mon, 29 Jul 2013 12:59:12 -0700 From: Sean Bruno <sean_bruno@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, Sean Bruno <sbruno@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r253708 - head/sys/dev/ipmi Message-ID: <1375127952.1479.32.camel@localhost> In-Reply-To: <201307291054.55820.jhb@freebsd.org> References: <201307271632.r6RGWYF8046749@svn.freebsd.org> <201307291054.55820.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. > > Move the check for ipmi_attached out of the ipmi_isa_attach function and into > > the ipmi_isa_identify function. Remove the check of the device tree for > > ipmi devices attached. > > > > This probing appears to make Broadcom management firmware on Dell machines > > crash and emit NMI EISA warnings at various times requiring power cycles > > of the machines to restore. > > This makes no sense. All you are doing is skipping ipmi_smbios_identify() > which just looks at the SMBIOS table in RAM. It doesn't try to probe the > BMC at all (no register accesses, etc.). If just reading a table in memory > causes side effects, then running dmidecode in userland should be hosing your > machines as well. > Probably right. I'm not exactly sure what is making the Broadcom firmware fall over and die. But when I see the console emitting "NMI EISA" error messages, this ususally requires a full reboot as the network interface has crashed. Hopefully, I can dig up more "fact" soon as testing continues. Sean [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJR9smMAAoJEBkJRdwI6BaHSqMH/164tPPSI0guiuAeB9W44gGj o7R6Ti9+EOP1SeDZW5wcMUFPg5VO1WvZ6oYh0e5vxp125ydr2MxkelXhx6lSpKli W9F289GSFhq7MV4I3+YCY3wJ+9yDLrqaba2e2DOw7PBdH4FYwzf8ICN+3JsTxTvV S8YGWWjM/qapZYXKLgBokdif96/HT7saj2NHAE0cl61I4WUTXxY2gSChwAEPMDcV ai+cHOPZAtkHjK1hzS6E6QkeyZi3rkEIxPD4M4x3aX11KEN+3VZqeo0/WM5Ognn1 B7sZsmvRBhPJVxXbKp0M9rzu0m0evmQ2l5v2n7uJjAHp5qd7bTWLiHjnYl0lamI= =Q9AM -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1375127952.1479.32.camel>