From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752446AbeBTRw5 (ORCPT ); Tue, 20 Feb 2018 12:52:57 -0500 Received: from mail-wr0-f171.google.com ([209.85.128.171]:44352 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751344AbeBTRw4 (ORCPT ); Tue, 20 Feb 2018 12:52:56 -0500 X-Google-Smtp-Source: AH8x2279KRWUU2u40FJ2popKzEKR3Mk4hT2+GayYePUjvfv1pc1Jx7nxRhp9KQtMM/pqJDHs7muw1XrOO2fuqIlcsKw= MIME-Version: 1.0 In-Reply-To: <78761f14-acc1-dc00-64d1-97aee4e42c02@acm.org> References: <3b812894-46a0-3c87-1b9f-468fc63ea5bd@acm.org> <78761f14-acc1-dc00-64d1-97aee4e42c02@acm.org> From: Chris Chiu Date: Wed, 21 Feb 2018 01:52:54 +0800 Message-ID: Subject: Re: ipmi_si fails to get BMC ID To: Corey Minyard Cc: Linux Kernel , Linux Upstreaming Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 15, 2018 at 1:17 AM, Corey Minyard wrote: > I'm removing Greg and Arnd from the email, I don't think this requires their > participation. > > > > > On 02/13/2018 08:44 PM, Chris Chiu wrote: >> >> On Fri, Feb 9, 2018 at 9:34 PM, Corey Minyard wrote: >>> >>> On 02/08/2018 09:09 PM, Chris Chiu wrote: >>>> >>>> On Thu, Feb 8, 2018 at 11:53 PM, Corey Minyard 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. >>> >>> >>> Ah. It's probably still worth trying, but I doubt it will make any >>> difference. >>> >>> Are you sure there is actually an IPMI BMC installed in this system? It >>> might >>> be a plug-in card that is not installed, but the interface still appears >>> on >>> the >>> PCI bus. So there is enough hardware to go part-way through the motions >>> of being an IPMI interface, but not enough to actually work. >>> >>> If there is a BMC there, do you know the register layout? The IPMI spec >>> has >>> an algorithm to go through to discover some of the parameters, and the >>> driver follows it, but IMHO it's not really very good. I'll need to know >>> the >>> size of the registers, and the spacing between the registers. >>> >>> -corey >>> >>> >> Sorry for late response because it's close to Chinese New Year. >> I can get the IPMI working with the driver here on Windows. >> >> https://www.drivermax.com/Realtek-Virtual-IPMI-Realtek-PCI-VEN-10EC-DEV-816C-1_0_0718_2013-2013-07-18-509795-driver.htm >> Then you will see the device (hightlighted) on the control panel as >> follows >> https://pasteboard.co/H7xm3fJ.png > > > Hmm, Windows has a built-in IPMI driver. I wonder why the aren't using > that. > And I don't know what "Virtual IPMI" means. > >> I don't know how to get the register layout you need. I can only take a >> picture of the content of the PCI resources. >> https://pasteboard.co/H7xnhz0.png >> >> The contents of BAR1, BAR3, BAR5 are all 0xff. Can you point me out >> where the useful information might be and I can try to dump FYI. > > > This whole thing sounds like they have created a non-standard IPMI interface > and put it on the PCI bus like a standard one. Unless we can get > documentation > for this, there's not much I can do but blacklist it. > > Do you have any ties with Realtek? I can't find anything on their web site > related > to IPMI. > > -corey > > I see. I'll try to reach the contact window for this in Realtek to see if there's any datasheet or document and get back here. Chris >> >> Chris >> >>>>> 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 >>>>> >>>>> >>>>> >