如何确定系统挂起但未能恢复的原因

Question

我将如何确定为什么我的Chromebook (宏碁CB515-1HT使用SeaBIOS引导MrChromeBox提供的引导)。运行Linux会成功挂起，但不会恢复吗？当它恢复时，它会进入固件屏幕。然后我就可以关掉电源，一切都很好。注意:因为这是在Linux下发生的，所以我在那个论坛上发了帖子.还有。

这在其他基于Ubuntu的发行版中没有发生；例如，使用内核版本5.15.15-75051515、5.13.0-19、5.13.0-19、5.13.0-19和5.13.0-19的Ubuntu21.10、Ubuntu-Budgi21.10、Ubuntu21.10和Ubuntu21.10。LinuxMint20.3肉桂发行版使用的是5.4.0内核。因此，我尝试了版本(内核5.13.0-25)以及MATE和XFCE版本(内核5.4.0)。但那些LM版本也不起作用。

搜索论坛，我发现了其他几个似乎相关的帖子，但没有看到任何与实际解决这个问题相关的东西。

由于其他发行版没有显示这种行为，因此我似乎应该能够比较这些发行版与Linux之间的设置、信任、驱动程序或其他内容，以确定可能的区别。我在Windows系统中有丰富的工作经验，但对Linux相对来说是个新手，所以我希望能得到一些关于从哪里开始的指导。

sudo inxi -verbosity 8 -- filter的更新输出

System:
  Kernel: 5.13.0-28-generic x86_64 bits: 64 compiler: N/A 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.13.0-28-generic 
  root=UUID=7f54ec77-2248-4c41-90d2-2a01cbc34466 ro quiet splash 
  Desktop: Cinnamon 5.2.7 wm: muffin 5.2.0 dm: LightDM 1.30.0 
  Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal 
Machine:
  Type: Laptop System: Google product: Sand v: rev3 serial: <filter> 
  Chassis: type: 9 serial: N/A 
  Mobo: Google model: Sand v: rev3 serial: <filter> BIOS: coreboot v: N/A 
  date: 11/29/2018 
Battery:
  ID-1: BAT0 charge: 32.2 Wh condition: 40.3/50.5 Wh (80%) volts: 7.8/7.6 
  model: SMP-SDI AC16B7K type: Li-ion serial: <filter> status: Discharging 
  cycles: 73 
Memory:
  RAM: total: 3.72 GiB used: 808.0 MiB (21.2%) 
  Array-1: capacity: N/A slots: 0 EC: N/A max module size: N/A 
  Device-1: Channel-0-DIMM-0 size: 1 GiB speed: 2400 MT/s type: Other 
  detail: synchronous bus width: 16 bits total: 16 bits manufacturer: N/A 
  part-no: MT53B256M32D1NP serial: <filter> 
  Device-2: Channel-1-DIMM-0 size: 1 GiB speed: 2400 MT/s type: Other 
  detail: synchronous bus width: 16 bits total: 16 bits manufacturer: N/A 
  part-no: MT53B256M32D1NP serial: <filter> 
  Device-3: Channel-2-DIMM-0 size: 1 GiB speed: 2400 MT/s type: Other 
  detail: synchronous bus width: 16 bits total: 16 bits manufacturer: N/A 
  part-no: MT53B256M32D1NP serial: <filter> 
  Device-4: Channel-3-DIMM-0 size: 1 GiB speed: 2400 MT/s type: Other 
  detail: synchronous bus width: 16 bits total: 16 bits manufacturer: N/A 
  part-no: MT53B256M32D1NP serial: <filter> 
PCI Slots:
  Message: No PCI slot data found. 
CPU:
  Topology: Quad Core model: Intel Pentium N4200 bits: 64 type: MCP 
  arch: Goldmont family: 6 model-id: 5C (92) stepping: 9 microcode: 44 
  L2 cache: 1024 KiB bogomips: 8755 
  Speed: 2388 MHz min/max: 800/2500 MHz Core speeds (MHz): 1: 2388 2: 2388 
  3: 2388 4: 2363 
  Flags: 3dnowprefetch acpi aes aperfmperf apic arat arch_capabilities 
  arch_perfmon art bts cat_l2 clflush clflushopt cmov constant_tsc cpuid 
  cpuid_fault cx16 cx8 de ds_cpl dtes64 dtherm dts ept ept_ad erms est 
  flexpriority fpu fsgsbase fxsr ht ibpb ibrs ida intel_pt lahf_lm lm mca 
  mce md_clear mmx movbe mpx msr mtrr nonstop_tsc nopl nx pae pat pbe 
  pclmulqdq pdcm pdpe1gb pebs pge pln pni popcnt pse pse36 pts rdrand rdseed 
  rdt_a rdtscp rep_good sdbg sep sha_ni smap smep ss sse sse2 sse4_1 sse4_2 
  ssse3 stibp syscall tm tm2 tpr_shadow tsc tsc_adjust tsc_deadline_timer 
  tsc_known_freq tsc_reliable vme vmx vnmi vpid x2apic xgetbv1 xsave xsavec 
  xsaveopt xsaves xtopology xtpr 
  Vulnerabilities: Type: itlb_multihit status: Not affected 
  Type: l1tf status: Not affected 
  Type: mds status: Not affected 
  Type: meltdown status: Not affected 
  Type: spec_store_bypass status: Not affected 
  Type: spectre_v1 
  mitigation: usercopy/swapgs barriers and __user pointer sanitization 
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, 
  IBRS_FW, STIBP: disabled, RSB filling 
  Type: srbds status: Not affected 
  Type: tsx_async_abort status: Not affected 

从最初的发布开始，我已经转到了内核5.13.0-28，因为内核确实包含了cr50 TPM芯片的驱动程序。但是现在它挂在暂停上，而不是正确地暂停，然后在恢复时重新设置。因此，虽然5.4.0内核不识别TPM (并且在恢复时失败)，但5.13.0内核识别它(？)但被暂时停职。但是，其他发行版中的5.13.0内核工作正常。这根本没道理。我不明白为什么这在*buntuw5.13内核上运行良好，而在LinuxMintw5.13内核上却失败了。但是也许我需要去一个新的发行版，放弃Linux。

执行一个journalctl -rb -1 (在挂起之后立即重新启动)，它显示它似乎已经进入睡眠状态，但是没有超过"Filesystms同步“。

kernel: Filesystems sync: 0.075 seconds
systemd[1]: Finished GRUB failed boot detection.
systemd[1]: grub-initrd-fallback.service: Succeeded.
kernel: PM: suspend entry (deep)
systemd[1]: Starting GRUB failed boot detection...
systemd-sleep[1589]: Suspending system...
systemd[1]: Finished Record successful boot for GRUB.
systemd[1]: grub-common.service: Succeeded.
systemd[1]: Starting Suspend...
systemd[1]: Starting Record successful boot for GRUB...
systemd[1]: Reached target Sleep.

与成功挂起/恢复的Lubuntu (21.10w51.3内核)的输出相比，Lubuntu继续运行到“冻结用户空间进程”。(“华尔街日报”继续刊登成功的简历，但没有包括这一内容。)

kernel: smpboot: CPU 3 is now offline
kernel: IRQ 125: no longer affine to CPU3
kernel: smpboot: CPU 2 is now offline
kernel: IRQ 121: no longer affine to CPU2
kernel: smpboot: CPU 1 is now offline
kernel: IRQ 122: no longer affine to CPU1
kernel: Disabling non-boot CPUs ...
kernel: PM: Saving platform NVS memory
kernel: ACPI: EC: EC stopped
kernel: ACPI: EC: event blocked
kernel: ACPI: Preparing to enter system sleep state S3
kernel: ACPI: EC: interrupt blocked
kernel: printk: Suspending console(s) (use no_console_suspend to debug)
kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
kernel: OOM killer disabled.
kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
kernel: Filesystems sync: 0.037 seconds
systemd[1]: Finished GRUB failed boot detection.
systemd[1]: grub-initrd-fallback.service: Deactivated successfully.
kernel: PM: suspend entry (deep)
systemd[1]: Starting GRUB failed boot detection...
systemd-sleep[2377]: Suspending system...
systemd[1]: Finished Record successful boot for GRUB.
systemd[1]: grub-common.service: Deactivated successfully.
systemd[1]: Starting Suspend...
systemd[1]: Starting Record successful boot for GRUB...
systemd[1]: Reached target Sleep.

Answer 1

根据对这个r/GalliumOS的答复，这是因为Linux (内核5.4)不带CR50 TPM驱动程序。我还找到了这篇LWN.net文章，这篇文章似乎很贴切。它是在5.13内核(版本)中携带的，但是它挂在挂起的黑屏上。