search for: acpi_rev_overrid

...work? If > > > > > anybody has any idea on how we could dig into this and figure it out > > > > > on this level, this would probably allow us to get closer to the root > > > > > cause? no? > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > does it have any effect? > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > should hopefully reveal something. > > > > > > > > > > I think I d...

...rk on windows? So do I ;-) > Or what are we doing differently on Linux so that it doesn't work? If > anybody has any idea on how we could dig into this and figure it out > on this level, this would probably allow us to get closer to the root > cause? no? Have you tried to use the acpi_rev_override parameter in your system and does it have any effect? Also did you try to trace the ACPI _ON/_OFF() methods? I think that should hopefully reveal something.

overall, what I really want to know is, _why_ does it work on windows? Or what are we doing differently on Linux so that it doesn't work? If anybody has any idea on how we could dig into this and figure it out on this level, this would probably allow us to get closer to the root cause? no? On Wed, Nov 20, 2019 at 12:54 PM Karol Herbst <kherbst at redhat.com> wrote: > > for newer

...doing differently on Linux so that it doesn't work? If > > > anybody has any idea on how we could dig into this and figure it out > > > on this level, this would probably allow us to get closer to the root > > > cause? no? > > > > Have you tried to use the acpi_rev_override parameter in your system and > > does it have any effect? > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > should hopefully reveal something. > > > > I think I did in the past and it seemed to have worked, there is just > one b...

...Linux. Not sure if you were aware of this already, though. The power resource PGOF() method has this: If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) { ... } If I read it right, the later condition tries to detect Linux which fails nowadays but if you have acpi_rev_override in the command line (or the machine is listed in acpi_rev_dmi_table) this check passes and does some magic which is not clear to me. There is similar in PGON() side which is used to turn the device back on. You can check what actually happens when _ON()/_OFF() is called by passing something like...

...y has any idea on how we could dig into this and figure it out > > > > > > > on this level, this would probably allow us to get closer to the root > > > > > > > cause? no? > > > > > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > > > does it have any effect? > > > > > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > > > should hopefully reveal something. > > > > &...

...t; happens inside PGOF(). Did you have time to try it? It may provide more > > > > information about that is happening inside those methods and hopefully > > > > point us to the root cause. > > > > > > > > Also if you haven't tried already passing acpi_rev_override in the > > > > command line makes the _REV to return 5 so it should go into the "Linux" > > > > path in PGOF(). > > > > > > Oh, so does it look like we are trying to work around AML that tried > > > to work around some problematic behavi...

...ACPI method tracing to see what > > happens inside PGOF(). Did you have time to try it? It may provide more > > information about that is happening inside those methods and hopefully > > point us to the root cause. > > > > Also if you haven't tried already passing acpi_rev_override in the > > command line makes the _REV to return 5 so it should go into the "Linux" > > path in PGOF(). > > Oh, so does it look like we are trying to work around AML that tried > to work around some problematic behavior in Linux at one point? Yes, it looks like so...

...). Maybe I remember incorrectly and have to read the code again... okay, the fallback path uses P0LD indeed. That's actually the only register of those being documented by Intel afaik. > If I read it right, the later condition tries to detect Linux which > fails nowadays but if you have acpi_rev_override in the command line (or > the machine is listed in acpi_rev_dmi_table) this check passes and does > some magic which is not clear to me. There is similar in PGON() side > which is used to turn the device back on. > > You can check what actually happens when _ON()/_OFF() is called by...

...> > Or what are we doing differently on Linux so that it doesn't work? If > > anybody has any idea on how we could dig into this and figure it out > > on this level, this would probably allow us to get closer to the root > > cause? no? > > Have you tried to use the acpi_rev_override parameter in your system and > does it have any effect? > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > should hopefully reveal something. > I think I did in the past and it seemed to have worked, there is just one big issue with this: it's a Dell spec...

...gt; > > anybody has any idea on how we could dig into this and figure it out > > > > > > on this level, this would probably allow us to get closer to the root > > > > > > cause? no? > > > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > > does it have any effect? > > > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > > should hopefully reveal something. > > > > > > > > &...

...x so that it doesn't work? If > > > > anybody has any idea on how we could dig into this and figure it out > > > > on this level, this would probably allow us to get closer to the root > > > > cause? no? > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > does it have any effect? > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > should hopefully reveal something. > > > > > > > I think I did in the past and it seemed to hav...

...w we could dig into this and figure it out > > > > > > > > on this level, this would probably allow us to get closer to the root > > > > > > > > cause? no? > > > > > > > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > > > > does it have any effect? > > > > > > > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > > > > should hopefully reveal something. &...

On Mon, Oct 21, 2019 at 5:46 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > > I

...y has any idea on how we could dig into this and figure it out > > > > > > > on this level, this would probably allow us to get closer to the root > > > > > > > cause? no? > > > > > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > > > does it have any effect? > > > > > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > > > should hopefully reveal something. > > > > &...

...suggested you to try the ACPI method tracing to see what > happens inside PGOF(). Did you have time to try it? It may provide more > information about that is happening inside those methods and hopefully > point us to the root cause. > > Also if you haven't tried already passing acpi_rev_override in the > command line makes the _REV to return 5 so it should go into the "Linux" > path in PGOF(). Oh, so does it look like we are trying to work around AML that tried to work around some problematic behavior in Linux at one point? > [1] https://www.kernel.org/doc/html/latest...

...gt; > > anybody has any idea on how we could dig into this and figure it out > > > > > > on this level, this would probably allow us to get closer to the root > > > > > > cause? no? > > > > > > > > > > Have you tried to use the acpi_rev_override parameter in your system and > > > > > does it have any effect? > > > > > > > > > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > > > > > should hopefully reveal something. > > > > > > > > &...

...ee what > > > happens inside PGOF(). Did you have time to try it? It may provide more > > > information about that is happening inside those methods and hopefully > > > point us to the root cause. > > > > > > Also if you haven't tried already passing acpi_rev_override in the > > > command line makes the _REV to return 5 so it should go into the "Linux" > > > path in PGOF(). > > > > Oh, so does it look like we are trying to work around AML that tried > > to work around some problematic behavior in Linux at one point?...

https://bugs.freedesktop.org/show_bug.cgi?id=101665 Bug ID: 101665 Summary: lspci blocks forever with a GP107M Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > > <mika.westerberg