lshw:
description: Notebook
product: ZERO (JT0096004)
vendor: THUNDEROBOT
version: Type1Version
serial: JT009600400J0M96822F
width: 64 bits
capabilities: smbios-3.3.0 dmi-3.3.0 smp vsyscall32
configuration: boot=normal chassis=notebook family=911 series sku=JT0096004 uuid=bd71e511-1f97-4e5b-9c5e-c8e04afc58f5
电脑有两个NVMe槽位。当硬盘插在第二个槽位时，在Linux启动时它与NVIDIA显卡会一起被断电，导致进不了系统（如果系统盘是槽位二的NVMe的话），或是进系统后根本读取不到槽位二的盘。
有关此ACPI问题曾有过一份bugzilla，描述了一个regression，5.12是好的，5.13时在启动时会出现NVMe断电问题。此bugzilla还提到问题于5.15被修复，issue关闭。对于我的THUNDEROBOT ZERO，与这个bugzilla中的测试结果一致：5.12 OK，5.13 buggy，以及5.15 OK。但我却在5.16重新遇到了这个问题。不知算不算又是个回归，但至少对我来说是的。
通过在内核中调试打印设备路径名以及查看lspci输出，可以确定此主板的NVMe#2与NVIDIA显卡被绑定在同一个PowerResource下（PXP）。
Workaround主要有两个：一是使用自定义内核，手动注释掉__acpi_power_off或acpi_turn_off_unused_power_resources函数。二是使用SSDT Override，对于我的主板，在ssdt12.dsl中有PXP的定义，把所有它的_OFF函数都直接返回掉就行了。
经过全量编译的bisect，定位到5.15到5.16-rc1之间。后续进一步经过不切换工作区而仅仅是替换drivers/acpi/{scan.c,power.c}这两个文件来bisect，定位到bad commit：a1224f34d72a，首次被合进v5.16-rc1。虽然这个commit跟__acpi_power_off和acpi_turn_off_unused_power_resources函数无关，仅仅是在初始化时读取了设备的状态，而且状态都没被使用，但它就是出问题了。我尝试使用master的最新commit，并revert此bad commit，经过测试也是成功的。
或许是厂商的BIOS固件Bug。说是没遵守好ACPI规范。关于此的新bugzilla链接。