On 02/08/2018 09:09 PM, Chris Chiu wrote:
On Thu, Feb 8, 2018 at 11:53 PM, Corey Minyard <miny...@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

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




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

Reply via email to