search for: ssdt1

...oking \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) That is how I think it should work in theory, but on Ricks laptop running 4.8.4, /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 devices (which I do have on my own laptop for 0000:01:0). The SSDT1 of Rick's Acer laptop shows this structure: If (\_OSI ("Windows 2013")) { Scope (\_SB.PCI0.RP05) { //... Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 { NVP3 }) Name (_PR2, P...

...P05._PR3) > > > > That is how I think it should work in theory, but on Ricks laptop running > > 4.8.4, > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > devices (which I do have on my own laptop for 0000:01:0). > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > If (\_OSI ("Windows 2013")) > > { > > Scope (\_SB.PCI0.RP05) > > { > > //... > > Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 >...

...sewhere), but the output > > is empty. That seems to indicate that flags.power_resources is unset. > > Is it completely empty or is it empty just for RP05? It should print out > all devices with power resources. \NVP2 and \NVP3 are the only power resources under RP05 and defined in SSDT1, there are no others. Kind regards, Peter > > Given that _PS3 exists and is indeed a package with some elements, it > > seems that acpi_extract_power_resources is failing. Note that in the > > SSDT, the power resource NVP3 was referenced before it was defined, > > could th...

...the power resource from \_SB.PCI0.RP05._PR3) > > That is how I think it should work in theory, but on Ricks laptop running > 4.8.4, > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > devices (which I do have on my own laptop for 0000:01:0). > > The SSDT1 of Rick's Acer laptop shows this structure: > > If (\_OSI ("Windows 2013")) > { > Scope (\_SB.PCI0.RP05) > { > //... > Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 > { >...

...> is empty. That seems to indicate that flags.power_resources is unset. > > > > Is it completely empty or is it empty just for RP05? It should print out > > all devices with power resources. > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > SSDT1, there are no others. We should probably add a debug print before checking flags.power_resources just to be sure the patch is correctly applied.

...> That is how I think it should work in theory, but on Ricks laptop running > > > 4.8.4, > > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > > devices (which I do have on my own laptop for 0000:01:0). > > > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > > > If (\_OSI ("Windows 2013")) > > > { > > > Scope (\_SB.PCI0.RP05) > > > { > > > //... > > > Name (_PR0, Package (0x01) //...

...ndicate that flags.power_resources is unset. > > > > > > Is it completely empty or is it empty just for RP05? It should print out > > > all devices with power resources. > > > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > > SSDT1, there are no others. > > We should probably add a debug print before checking > flags.power_resources just to be sure the patch is correctly applied. It was correctly applied. I did some testing with QEMU, it seems that the \_OSI check is problematic. Removing it makes things work again...

Hi guys and gals, I'm working on improving nouveau's support for MXM (Mobile PCI Express Module) chips and need some more data to check my implementation. To see if you can help, the first thing to do is jump over to /sys/firmware/acpi/tables and run "grep MXMS *". [root at nisroch tables]# grep MXMS * Binary file DSDT matches [root at nisroch tables]# If this isn't

On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > No, there are not. Here is the recursive directory listing: > > Are you able to try the following patch and send me dmesg (or attach it > to that bug)? It should show if the ACPI core even tries to add those > power resources. So Rick has

...d work in theory, but on Ricks laptop > running > > > > 4.8.4, > > > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have > power_resources_D0 > > > > devices (which I do have on my own laptop for 0000:01:0). > > > > > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > > > > > If (\_OSI ("Windows 2013")) > > > > { > > > > Scope (\_SB.PCI0.RP05) > > > > { > > > > //... > > > >...

...ENOVO TP-G5 00001070 PTL 00000001) [ 0.000000] ACPI: TCPA 0x00000000BAFFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 0x00000000BAFFB000 000249 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000BAFFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000BAFF9000 000797 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 0x00000000BAFE5000 000038 (v01 LENOVO TP-G5 00001070 PTL 00000002) [ 0.000000] ACPI: APIC 0x00000000BAFE4000 000098 (v01 LENOVO TP-G5 00001070...

...76 (v01 LENOVO TP-G4 00001100 PTL 00000001) [ 0.000000] ACPI: TCPA 00000000dabfc000 00032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 00000000dabfb000 00249 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 00000000dabfa000 00033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 00000000dabf9000 00797 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 00000000dabe5000 00038 (v01 LENOVO TP-G4 00001100 PTL 00000002) [ 0.000000] ACPI: APIC 00000000dabe4000 00098 (v01 LENOVO TP-G4 00001100 PTL 000...

Hello, I am encountering a 30 second hang during boot, in the Xorg process just before the display manager comes up. I have bisected the problem to the following commit: commit 2b700825e7a7702fb862edba1262c98040dc1bf6 Author: Ben Skeggs <bskeggs at redhat.com> Date: Thu Aug 20 14:54:22 2015 +1000 drm/nouveau/mc: move device irq handling to platform-specific code The hang only

...] ACPI: FACS 0x00000000CAF5A000 000040 [ 0.000000] ACPI: TCPA 0x00000000CAFFD000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 0x00000000CAFFC000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000CAFFB000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000CAFFA000 0007A8 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 0x00000000CAFE4000 000038 (v01 LENOVO TP-G2 00002640 PTL 00000002) [ 0.000000] ACPI: APIC 0x00000000CAFE3000 000098 (v01 LENOVO TP-G2 00002640...

Hello, following up on myself, it was suggested on IRC that I better attach a dmesg output. Here's the output of a clean boot & echo 0f > /sys/.../pstate cycle. I can't spot a message that relates to the reclock action, and there's only one weird "nouveau 0000:04:00.0: clk: base: 7 MHz, boost: 7 MHz" message. On the other hand: # cat