* ipmi_si fails to get BMC ID @ 2018-02-08 3:01 Chris Chiu 2018-02-08 15:53 ` Corey Minyard 0 siblings, 1 reply; 12+ messages in thread From: Chris Chiu @ 2018-02-08 3:01 UTC (permalink / raw) To: minyard, arnd, gregkh, openipmi-developer, Linux Kernel, Linux Upstreaming Team 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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-08 3:01 ipmi_si fails to get BMC ID Chris Chiu @ 2018-02-08 15:53 ` Corey Minyard 2018-02-09 3:09 ` Chris Chiu 0 siblings, 1 reply; 12+ messages in thread From: Corey Minyard @ 2018-02-08 15:53 UTC (permalink / raw) To: Chris Chiu, arnd, gregkh, openipmi-developer, Linux Kernel, Linux Upstreaming Team 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? Does the IPMI driver always take this long to issue that error, even if you are not entering sleep state? And it started with 4.14, and didn't occur before then, right? 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 > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-08 15:53 ` Corey Minyard @ 2018-02-09 3:09 ` Chris Chiu 2018-02-09 13:34 ` Corey Minyard 0 siblings, 1 reply; 12+ messages in thread From: Chris Chiu @ 2018-02-09 3:09 UTC (permalink / raw) To: Corey Minyard Cc: Arnd Bergmann, gregkh, openipmi-developer, Linux Kernel, Linux Upstreaming Team 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. > 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-09 3:09 ` Chris Chiu @ 2018-02-09 13:34 ` Corey Minyard 2018-02-14 2:44 ` Chris Chiu 0 siblings, 1 reply; 12+ messages in thread From: Corey Minyard @ 2018-02-09 13:34 UTC (permalink / raw) To: Chris Chiu Cc: Arnd Bergmann, gregkh, openipmi-developer, Linux Kernel, Linux Upstreaming Team 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 >> 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 >> >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-09 13:34 ` Corey Minyard @ 2018-02-14 2:44 ` Chris Chiu 2018-02-14 17:17 ` Corey Minyard 0 siblings, 1 reply; 12+ messages in thread From: Chris Chiu @ 2018-02-14 2:44 UTC (permalink / raw) To: Corey Minyard Cc: Arnd Bergmann, gregkh, openipmi-developer, Linux Kernel, Linux Upstreaming Team 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 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 >>> >>> >>> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-14 2:44 ` Chris Chiu @ 2018-02-14 17:17 ` Corey Minyard 2018-02-20 17:52 ` Chris Chiu 0 siblings, 1 reply; 12+ messages in thread From: Corey Minyard @ 2018-02-14 17:17 UTC (permalink / raw) To: Chris Chiu; +Cc: openipmi-developer, Linux Kernel, Linux Upstreaming Team 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 >>>> >>>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ipmi_si fails to get BMC ID 2018-02-14 17:17 ` Corey Minyard @ 2018-02-20 17:52 ` Chris Chiu 2018-02-26 2:50 ` [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device minyard 0 siblings, 1 reply; 12+ messages in thread From: Chris Chiu @ 2018-02-20 17:52 UTC (permalink / raw) To: Corey Minyard; +Cc: Linux Kernel, Linux Upstreaming Team On Thu, Feb 15, 2018 at 1:17 AM, Corey Minyard <minyard@acm.org> 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 <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 > > 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 >>>>> >>>>> >>>>> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device 2018-02-20 17:52 ` Chris Chiu @ 2018-02-26 2:50 ` minyard 2018-02-26 14:34 ` Andy Shevchenko 2018-03-13 7:27 ` Daniel Drake 0 siblings, 2 replies; 12+ messages in thread From: minyard @ 2018-02-26 2:50 UTC (permalink / raw) To: Chris Chiu Cc: linux-kernel, Linux Upstreaming Team, openipmi-developer, Corey Minyard From: Corey Minyard <cminyard@mvista.com> Realtek has some sort of "Virtual" IPMI device on the PCI bus as a KCS controller, but whatever it is, it's not one. Ignore it if seen. Reported-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> --- I haven't heard anything from you on this. Here is a patch that should blacklist that device, though I don't have a way to easily test it. If you would prefer this, could you test it? drivers/char/ipmi/ipmi_si_pci.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/char/ipmi/ipmi_si_pci.c b/drivers/char/ipmi/ipmi_si_pci.c index 27dd11c..d24990b 100644 --- a/drivers/char/ipmi/ipmi_si_pci.c +++ b/drivers/char/ipmi/ipmi_si_pci.c @@ -65,6 +65,15 @@ static int ipmi_pci_probe_regspacing(struct si_sm_io *io) return DEFAULT_REGSPACING; } +static struct pci_device_id ipmi_pci_blacklist[] = { + /* + * This is a "Virtual IPMI device", whatever that is. It appears + * as a KCS device by the class, but it is not one. + */ + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x816c) }, + { 0, } +}; + static int ipmi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -72,6 +81,9 @@ static int ipmi_pci_probe(struct pci_dev *pdev, int class_type = pdev->class & PCI_ERMC_CLASSCODE_TYPE_MASK; struct si_sm_io io; + if (pci_match_id(ipmi_pci_blacklist, pdev)) + return -ENODEV; + memset(&io, 0, sizeof(io)); io.addr_source = SI_PCI; dev_info(&pdev->dev, "probing via PCI"); -- 2.7.4 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device 2018-02-26 2:50 ` [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device minyard @ 2018-02-26 14:34 ` Andy Shevchenko 2018-02-26 14:48 ` Corey Minyard 2018-03-13 7:27 ` Daniel Drake 1 sibling, 1 reply; 12+ messages in thread From: Andy Shevchenko @ 2018-02-26 14:34 UTC (permalink / raw) To: Corey Minyard Cc: Chris Chiu, Linux Kernel Mailing List, Linux Upstreaming Team, openipmi-developer, Corey Minyard On Mon, Feb 26, 2018 at 4:50 AM, <minyard@acm.org> wrote: > Realtek has some sort of "Virtual" IPMI device on the PCI bus as a > KCS controller, but whatever it is, it's not one. Ignore it if seen. > +static struct pci_device_id ipmi_pci_blacklist[] = { > + /* > + * This is a "Virtual IPMI device", whatever that is. It appears > + * as a KCS device by the class, but it is not one. > + */ > + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x816c) }, > + { 0, } { PCI_VDEVICE(REALTEK, 0x816c) }, { } ? > +}; > + if (pci_match_id(ipmi_pci_blacklist, pdev)) > + return -ENODEV; -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device 2018-02-26 14:34 ` Andy Shevchenko @ 2018-02-26 14:48 ` Corey Minyard 0 siblings, 0 replies; 12+ messages in thread From: Corey Minyard @ 2018-02-26 14:48 UTC (permalink / raw) To: Andy Shevchenko Cc: Chris Chiu, Linux Kernel Mailing List, Linux Upstreaming Team, openipmi-developer, Corey Minyard On 02/26/2018 08:34 AM, Andy Shevchenko wrote: > On Mon, Feb 26, 2018 at 4:50 AM, <minyard@acm.org> wrote: > >> Realtek has some sort of "Virtual" IPMI device on the PCI bus as a >> KCS controller, but whatever it is, it's not one. Ignore it if seen. >> +static struct pci_device_id ipmi_pci_blacklist[] = { >> + /* >> + * This is a "Virtual IPMI device", whatever that is. It appears >> + * as a KCS device by the class, but it is not one. >> + */ >> + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x816c) }, >> + { 0, } > { PCI_VDEVICE(REALTEK, 0x816c) }, > { } > > ? That's better, thanks. -corey > >> +}; >> + if (pci_match_id(ipmi_pci_blacklist, pdev)) >> + return -ENODEV; > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device 2018-02-26 2:50 ` [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device minyard 2018-02-26 14:34 ` Andy Shevchenko @ 2018-03-13 7:27 ` Daniel Drake 2018-03-13 11:59 ` Corey Minyard 1 sibling, 1 reply; 12+ messages in thread From: Daniel Drake @ 2018-03-13 7:27 UTC (permalink / raw) To: minyard Cc: Chris Chiu, Linux Kernel, Linux Upstreaming Team, openipmi-developer, Corey Minyard Hi, On Mon, Feb 26, 2018 at 10:50 AM, <minyard@acm.org> wrote: > From: Corey Minyard <cminyard@mvista.com> > > Realtek has some sort of "Virtual" IPMI device on the PCI bus as a > KCS controller, but whatever it is, it's not one. Ignore it if seen. > > Reported-by: Chris Chiu <chiu@endlessm.com> > Signed-off-by: Corey Minyard <cminyard@mvista.com> > --- > > I haven't heard anything from you on this. Here is a patch that should > blacklist that device, though I don't have a way to easily test it. > If you would prefer this, could you test it? Sorry for the slow response, and thanks for the patch! We have tested it here and it seems to be working fine now - the IPMI stuff no longer initializes system interfaces, and hence doesn't get in the way when going into suspend or reboot later. This is a consumer desktop platform, so if some kind of IPMI functionality is really present in the hardware then it is not really going to be relevant for the ordinary user. So it should be fine to just ignore the hardware as you have done. Thanks Daniel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device 2018-03-13 7:27 ` Daniel Drake @ 2018-03-13 11:59 ` Corey Minyard 0 siblings, 0 replies; 12+ messages in thread From: Corey Minyard @ 2018-03-13 11:59 UTC (permalink / raw) To: Daniel Drake Cc: Chris Chiu, Linux Kernel, Linux Upstreaming Team, openipmi-developer, Corey Minyard On 03/13/2018 02:27 AM, Daniel Drake wrote: > Hi, > > On Mon, Feb 26, 2018 at 10:50 AM, <minyard@acm.org> wrote: >> From: Corey Minyard <cminyard@mvista.com> >> >> Realtek has some sort of "Virtual" IPMI device on the PCI bus as a >> KCS controller, but whatever it is, it's not one. Ignore it if seen. >> >> Reported-by: Chris Chiu <chiu@endlessm.com> >> Signed-off-by: Corey Minyard <cminyard@mvista.com> >> --- >> >> I haven't heard anything from you on this. Here is a patch that should >> blacklist that device, though I don't have a way to easily test it. >> If you would prefer this, could you test it? > Sorry for the slow response, and thanks for the patch! > > We have tested it here and it seems to be working fine now - the IPMI > stuff no longer initializes system interfaces, and hence doesn't get > in the way when going into suspend or reboot later. Ok, thanks, I will add it with a "Tested-by" from you, if that is ok. -corey > > This is a consumer desktop platform, so if some kind of IPMI > functionality is really present in the hardware then it is not really > going to be relevant for the ordinary user. So it should be fine to > just ignore the hardware as you have done. > > Thanks > Daniel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-03-13 11:59 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-08 3:01 ipmi_si fails to get BMC ID Chris Chiu 2018-02-08 15:53 ` Corey Minyard 2018-02-09 3:09 ` Chris Chiu 2018-02-09 13:34 ` Corey Minyard 2018-02-14 2:44 ` Chris Chiu 2018-02-14 17:17 ` Corey Minyard 2018-02-20 17:52 ` Chris Chiu 2018-02-26 2:50 ` [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device minyard 2018-02-26 14:34 ` Andy Shevchenko 2018-02-26 14:48 ` Corey Minyard 2018-03-13 7:27 ` Daniel Drake 2018-03-13 11:59 ` Corey Minyard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.