lkml.org 
[lkml]   [2018]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: ipmi_si fails to get BMC ID
    From
    Date
    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 <minyard@acm.org> wrote:
    >> On 02/08/2018 09:09 PM, Chris Chiu wrote:
    >>> On Thu, Feb 8, 2018 at 11:53 PM, Corey Minyard <minyard@acm.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.
    >>
    >> 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

    >
    > 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
    >>>>
    >>>>

    \
     
     \ /
      Last update: 2018-02-14 18:18    [W:2.833 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site