linux-kernel - Re: ipmi_si fails to get BMC ID

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]

Message-ID: <CAB4CAwdTa=A78hr4ZrHNpCwJBo3-kmdK8nq1ZS_k0VanPm0dMw@mail.gmail.com>
Date:   Fri, 9 Feb 2018 11:09:48 +0800
From:   Chris Chiu <chiu@...lessm.com>
To:     Corey Minyard <minyard@....org>
Cc:     Arnd Bergmann <arnd@...db.de>, gregkh@...uxfoundation.org,
        openipmi-developer@...ts.sourceforge.net,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>
Subject: Re: ipmi_si fails to get BMC ID

On Thu, Feb 8, 2018 at 11:53 PM, Corey Minyard <minyard@....org> wrote:
> On 02/07/2018 09:01 PM, Chris Chiu wrote:
>>
>> Hi,
>>      We are working with a new desktop Acer Veriton Z4640G and get
>> stumbled on failing to enter S3 suspend with kernel version 4.14 even
>> the latest 4.15+. Here's the kernel log
>> https://gist.github.com/mschiu77/76888f1fd4eb56aa8959d76759a912bb.
>
>
> This is a little strange, nobody had reported this before.  Can you
> reproduce this
> at will, or was it a one-time thing?

It can be reproduced on each reboot.
>
> Does the IPMI driver always take this long to issue that error, even if you
> are not
> entering sleep state?
>
Yep, it will always print "ipmi_si 0000:02:00.3: There appears to be
no BMC at this
location" few minutes after boot.

> And it started with 4.14, and didn't occur before then, right?
>

I haven't try pre-4.14 kernel. Will do that and update here.

> There's a bug in the PCI utils database, I submitted a report a while ago.
> This is
> a KCS, not a SMIC interface.
>
> It looks like the driver is trying to detect that there is a device out
> there and
> there is something that kind of works, but doesn't work completely. The
> interface
> specific code was all split out into separate files in 4.14.  It is possible
> the
> detection code got messed up in the process.  Nothing jumps out looking at
> the code differences, and I know it works on some PCI machines.
>
> Assuming this is reproducible, can you send the the output of a pre-4.14
> kernel?  If that doesn't make it obvious I may have to have access to the
> machine itself.
>
> -corey
>
>
It's an All-in-One machine so I think it would be difficult for
shipment. I'll see what
I can do. Thanks for help.

Chris

>>      As you see, it is due to "ipmi_probe+0x430/0x430 [ipmi_si]". After
>> the message "ipmi_si 0000:02:00.3: There appears to be no BMC at this
>> location" shows up, then it can really go to suspend w/o problem.
>> Although it took around 3 mins. The IPMI device is probed from PCI and
>> here's the output of lspci
>> https://gist.github.com/mschiu77/33f0372be41670d8a69c97e64f833087. The
>> IPMI device is "02:00.3 IPMI SMIC interface [0c07]". We get stuck here
>> because we don't really know why it took so long in try_get_dev_id() /
>> ipmi_si_intf.c. Any suggestion about this to help us moving forward?
>> Thanks
>>
>>
>> Chris
>
>
>