On Fri, Feb 9, 2018 at 9:34 PM, Corey Minyard <miny...@acm.org> wrote: > 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 > >
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 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. 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 >>> >>> >>> >
