Re: ipmi_si: 90 s delay in system start with 4.14.94, but not 4.18.6

From: Paul Menzel
Date: Wed Jan 23 2019 - 11:25:08 EST


Dear Corey,


On 01/22/19 21:58, Corey Minyard wrote:
> On 1/22/19 10:17 AM, Paul Menzel wrote:

>> Using Linux 4.14.94 on a HP EliteDesk 705 G4 MT desktop system, there
>> is a 100 s delay during boot.
>>
>> ```
>> [ÂÂÂ 0.000000] Linux version 4.14.94.mx64.239 (root@xxxxxxxxxxxxxxx) (gcc version 7.3.0 (GCC)) #1 SMP Mon Jan 21 11:39:45 CET 2019
>> [â]
>> [ÂÂÂ 3.263092] ipmi message handler version 39.2
>> [ÂÂÂ 3.263520] ipmi device interface
>> [ÂÂÂ 3.263893] IPMI System Interface driver.
>> [ÂÂÂ 3.264325] ipmi_si 0000:06:00.3: probing via PCI
>> [ 3.264804] ipmi_si 0000:06:00.3: [io 0x3000-0x30ff] regsize 1 spacing 1 irq 39
>> [ÂÂÂ 3.265496] ipmi_si: Adding PCI-specified kcs state machine
>> [ÂÂÂ 3.266019] ipmi_si: Trying PCI-specified kcs state machine at i/o address 0x3000, slave address 0x0, irq 39
>> [ÂÂÂ 4.255042] tsc: Refined TSC clocksource calibration: 3593.250 MHz
>> [ÂÂÂ 4.255618] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33cb6addeae, max_idle_ns: 440795225061 ns
>> [ÂÂÂ 5.264130] clocksource: Switched to clocksource tsc
>> [Â 104.978023] ipmi_si 0000:06:00.3: There appears to be no BMC at this location
>> [Â 104.978658] IPMI Watchdog: driver initialized
>> [Â 104.979095] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot.
>> [â]
>> ```
>>
>> Testing Linux 4.18.6 and 4.20, there is no such delay.
>>
>> ```
>> [ÂÂÂ 0.000000] Linux version 4.18.6.mx64.221 (root@xxxxxxxxxxxxxxx) (gcc version 7.3.0 (GCC)) #1 SMP Thu Sep 6 07:51:05 CEST 2018
>> [â]
>> [ÂÂÂ 2.951174] ipmi message handler version 39.2
>> [ÂÂÂ 2.951604] ipmi device interface
>> [ÂÂÂ 2.951973] IPMI System Interface driver.
>> [ÂÂÂ 2.952404] ipmi_si: Unable to find any System Interface(s)
>> [ÂÂÂ 2.952909] IPMI Watchdog: driver initialized
>> [ÂÂÂ 2.953339] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot.
>> [ÂÂÂ 2.954053] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
>> [â]
>> ```
>>
>> Do you have a suggestion, what commit might have fixed this? Quickly
>> going through the commit history, it looks like, last year a lot of
>> bug fixes and clean-up was done.
>
> That's really strange. Generally when something like this happens, it
> means that there is sort of an IPMI interface there, but it's not complete.
> This happens when the low-level hardware is there, but there is no
> processor behind it to actually do anything.
>
> But as you can see, in 4.18 it wasn't detecting anything, and in 4.19
> it is seeing an IPMI device on the PCI bus. The discovery here is done
> by the PCI code, it's out of the IPMI drivers hands until the PCI code
> delivers it.
>
> So what I'm guessing is that something changed so that the PCI
> code is now recognising that there is an IPMI device there by the
> PCI class codes. There really isn't a device completely there, so
> it doesn't work.
>
> I don't see anything in the IPMI code that would cause that.
>
> If this is a problem, the device can be blacklisted in
> ipmi_pci_blacklist in ipmi_si_pci.c.

For whatever reason, I didnât read that last paragraph, so bisection
brought me to your commit bc48fa1b9d (ipmi:pci: Blacklist a Realtek
"IPMI" device) doing exactly that, blacklisting the device.

$ lspci -nn -s 06:00.3
06:00.3 IPMI SMIC interface [0c07]: Realtek Semiconductor Co., Ltd. Device [10ec:816c] (rev 0e)

Iâll backported it to Linux 4.14.x, and send the commit to
stable@xxxxxxxxxxxxxxxx

[â]


Kind regards,

Paul


[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc48fa1b9d3b04106055b27078da824cd209865a

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature