lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 May 2014 16:28:41 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	Kevin Hilman <khilman@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>, linaro-kernel@...ts.linaro.org,
	Corey Minyard <minyard@....org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	Andrew Lunn <andrew@...n.ch>,
	kernel-build-reports@...ts.linaro.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...glemail.com>,
	linux-kernel@...r.kernel.org,
	openipmi-developer@...ts.sourceforge.net
Subject: Re: IPMI misbehaving on ARM defconfigs, was [Re: stable boot: 18
 pass, 4 fail (v3.10.39)]

On Wed, May 07, 2014 at 12:36:20PM -0700, Kevin Hilman wrote:
> Jason Cooper <jason@...edaemon.net> writes:
> 
> > On Wed, May 07, 2014 at 04:44:42PM +0200, Arnd Bergmann wrote:
> >> On Wednesday 07 May 2014 10:20:56 Jason Cooper wrote:
> >> > > ipmi message handler version 39.2
> >> > > IPMI System Interface driver.
> >> > > ipmi_si: Adding default-specified kcs state machine
> >> > > ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
> >> > > ipmi_si: Could not set up I/O space
> >> > > Trying to free nonexistent resource <0000000000000ca2-0000000000000ca2>
> >> > > Trying to free nonexistent resource <0000000000000ca3-0000000000000ca3>
> >> > > ipmi_si: Adding default-specified smic state machine
> >> > > ipmi_si: Trying default-specified smic state machine at i/o address 0xca9, slave address 0x0, irq 0
> >> > > ipmi_si: Could not set up I/O space
> >> > > Trying to free nonexistent resource <0000000000000ca9-0000000000000ca9>
> >> > > Trying to free nonexistent resource <0000000000000caa-0000000000000caa>
> >> > > Trying to free nonexistent resource <0000000000000cab-0000000000000cab>
> >> > > ipmi_si: Adding default-specified bt state machine
> >> > > ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, slave address 0x0, irq 0
> >> > > ipmi_si: Could not set up I/O space
> >> > > Trying to free nonexistent resource <00000000000000e4-00000000000000e4>
> >> > > Trying to free nonexistent resource <00000000000000e5-00000000000000e5>
> >> > > Trying to free nonexistent resource <00000000000000e6-00000000000000e6>
> >> > > ipmi_si: Unable to find any System Interface(s)
> >> > > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> >> > ...
> >> > 
> >> > It appears to be unrelated to the failure this original message was
> >> > about.  However, the failure brought the above to our attention. 
> >> > 
> >> > Is the IPMI driver used on ARM?  Documentation/IPMI.txt indicates a
> >> > dependency on ACPI, but that isn't reflected in the Kconfig.  At any
> >> > rate, it seems rather unhappy.  :(
> >> 
> >> It certainly can be used, and it can be probed through a known PC-style
> >> port number or through the DT binding.
> >> 
> >> However, we don't normally want it to try the PC style addresses, which
> >> appear to be used in this case. This should only happen if
> >> CONFIG_IPMI_SI_PROBE_DEFAULTS is set, as far as I can tell. Is that
> >> set in your configuration?
> >
> > It's not set in multi_v7_defconfig, which is the config this failed
> > under.  At least not on linux-3.10.y.

Oops, I was wrong.  Not sure what happened to my grep-fu, but it is
clearly set in multi_v7_defconfig in linux-3.10.y.

> > Kevin, do you still have the full config from this build?  Could you
> > send us the IPMI related settings?
> 
> Below is the .config used for the multi_v7_defconfig build of v3.10.39

Awesome, thanks.  That confirms I was wrong :)

On a broader topic, if we have users in the field running v3.10.y on ARM
systems, then I think it's worth backporting the defconfig changes to
boot-test those systems.

I'll see if I can generate a list of patches.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ