On 04/25/2018 12:55 PM, Tony Camuso wrote:
On 04/25/2018 11:08 AM, Corey Minyard wrote:
On 04/25/2018 08:38 AM, Tony Camuso wrote:
On 04/25/2018 08:29 AM, Corey Minyard wrote:
So this is the SSIF driver? That's where dmi_ipmi_probe() is. That
error
shouldn't be an issue in that code.
But you mention ipmi_si, and platform_ipmi_probe() is what would do
that
for that interface. device_property_read_u8() appears 3 times in that
function, which is failing?
I've bisected to commit 0944d889a237b6107f9ceeee053fe7221cdd1089,
where that
function call only appears twice in dmi_ipmi_probe(), which is
statically
defined in both ipmi_si_intf.c and ipmi_ssif.c at that bisect point.
Ah, so it's an older kernel, at least where the error starts. That
code is significantly
different now.
The systems exhibiting this pathology do not operate above that
commit. One
is x86_64 and one is arm.
The only one that should be fatal is reading ipmi-type, and the only
way that should be fatal in the ipmi_si code is if you have an SSIF
interface.
Consequently the ipmi_si device is not loaded, and there is no
/dev/ipmi0
AFAICT, there are no patches to address this problem.
I've been trying to get to the bottom of it for a couple days, but
have
not had any success.
Can you send me the output of dmidecode?
I have attached dmidecode output for both the x86_64 and the arm
systems.
So I created a system in qemu that has exactly the same dmi table as
yours,
x86_64:
Handle 0x3000, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA2 (I/O)
Register Spacing: Successive Byte Boundaries
I checked out to the commit you specified above, built, and it worked
fine:
root@x86-generic-64:~# insmod ipmi_msghandler.ko
[ 33.918892] ipmi message handler version 39.2
root@x86-generic-64:~# insmod ipmi_si.ko
[ 36.598587] ipmi_si: probing via SMBIOS
[ 36.599685] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
[ 36.601597] ipmi_si: Adding SMBIOS-specified kcs state machine
[ 36.605769] IPMI System Interface driver.
[ 36.608483] ipmi_si: Trying SMBIOS-specified kcs state machine at
i/o addres0
[ 36.618025] ipmi_si dmi-ipmi-si.1: Found new BMC (man_id:
0x000000, prod_id:)
[ 36.620164] ipmi_si dmi-ipmi-si.1: IPMI kcs interface initialized
Are you using unmodified kernel.org?
OK, THAT works on the x86_64, so latest, unmodified kernel.org is good.
This commit introduced the problem on my custom kernel.
0944d88 ipmi: Convert DMI handling over to a platform device
Could it be this commit that fixes it?
95e300c ipmi: Make the DMI probe into a generic platform probe
I'll give that a try and see if it saves me from having to bisect
from 0944d88 up to the present.
That's certainly the problem. It's what puts the information like ipmi-type
into the device.
-corey
Could it be something ancillary to ipmi, like in the
drivers/firmware/dmi*
What is the exact kernel output when you load the module? Or are you
using a module?
-corey
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
