Điểm:2

Không thể tạm ngưng: hệ thống tiếp tục không rõ lý do sau ~40 phút ngủ

lá cờ pl

Tôi đã mua MSI Summit B15 mới được cung cấp không có hệ điều hành và cài đặt vui vẻ trên Ubuntu 21.04 mới. Cho đến nay mọi thứ đều hoạt động khá tốt (ngoại trừ một vài sự cố với bàn di chuột & không có trình điều khiển cho máy quét FP nhưng đó là một câu chuyện khác) ngoại trừ một vấn đề khá khó chịu: khi tôi cố gắng tạm dừng máy, nó đột nhiên thức dậy sau khoảng ~40-60 phút và bắt đầu chạy quạt hết tốc độ. Không chỉ đôi khi nó thức dậy tôi nếu tôi tình cờ ngủ gần đó, nó sẽ làm cạn kiệt pin qua đêm, khiến việc tạm dừng về cơ bản trở nên vô dụng.

Tôi đã cố gắng vô hiệu hóa mọi thứ (xem đây như thế nào) nhưng nút nguồn trong /proc/acpi/đánh thức, vì vậy nó trông như thế này hiện tại:

â ~ mèo /proc/acpi/wakeup | đã bật grep
PWRB S4 *nền tảng hỗ trợ:PNP0C0C:00

Nó không giúp được gì.

Đây là một phần của nhật ký hệ thống (ở đây tôi đã đặt hệ thống tạm dừng lúc 7:48 và nó bắt đầu chạy lúc 8:35 nhưng tôi đã đăng nhập sau, chỉ lúc 10:56):

Ngày 5 tháng 9 07:48:00 rb-base tracker-store[6784]: OK
Ngày 5 tháng 9 07:48:00 rb-base systemd[3246]: tracker-store.service: Thành công.
Ngày 5 tháng 9 07:48:01 rb-base kernel: [ 146.937861] Khóa: systemd-logind: chế độ ngủ đông bị hạn chế; xem man kernel_lockdown.7
Ngày 5 tháng 9 07:48:05 rb-base kernel: [ 150.972633] Khóa: systemd-logind: chế độ ngủ đông bị hạn chế; xem man kernel_lockdown.7
Ngày 5 tháng 9 07:48:05 rb-base kernel: [ 150.977982] Khóa: systemd-logind: chế độ ngủ đông bị hạn chế; xem man kernel_lockdown.7
Ngày 5 tháng 9 07:48:05 rb-base ModemManager[2119]: <thông tin> hệ thống [sleep-monitor] sắp tạm dừng
Ngày 5 tháng 9 07:48:05 rb-base kernel: [ 150.997219] wlo1: hủy xác thực từ b0:4e:26:31:82:b8 theo lựa chọn cục bộ (Lý do: 3=DEAUTH_LEAVING)
Ngày 5 tháng 9 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-DISCONNECTED bssid=b0:4e:26:31:82:b8 reason=3 local_generated=1
Ngày 5 tháng 9 07:48:05 rb-base NetworkManager[1931]: <info> [1630817285.6861] device (wlo1): thay đổi trạng thái: hủy kích hoạt -> bị ngắt kết nối (lý do 'ngủ', sys-ifac
trạng thái điện tử: 'được quản lý')
Ngày 5 tháng 9 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-SIGNAL-CHANGE ở trên=0 tín hiệu=0 nhiễu=9999 txrate=0
Ngày 5 tháng 9 07:48:07 rb-base systemd[1]: Đã đạt mục tiêu Ngủ.
Ngày 5 tháng 9 07:48:07 rb-base systemd[1]: Bắt đầu Tạm dừng...
Ngày 5 tháng 9 07:48:07 rb-base kernel: [ 152.341436] PM: tạm dừng mục nhập (s2idle)
Ngày 5 tháng 9 07:48:07 rb-base systemd-sleep[7072]: Hệ thống treo...
Ngày 5 tháng 9 07:48:07 rb-base systemd[1]: zsysd.service: Thành công.
Ngày 5 tháng 9 07:48:07 rb-base kernel: [ 152.424613] Đồng bộ hóa hệ thống tệp: 0,083 giây
Ngày 5 tháng 9 10:56:42 rb-base kernel: [ 152.426323] Đóng băng các quy trình không gian người dùng ... (đã trôi qua 0,002 giây) đã hoàn tất.
Ngày 5 tháng 9 10:56:42 rb-base kernel: [ 152.428515] OOM killer bị vô hiệu hóa.
Ngày 5 tháng 9 10:56:42 rb-base kernel: [ 152.428516] Đóng băng các tác vụ có thể đóng băng còn lại ... (đã trôi qua 0,001 giây) đã hoàn tất.
Ngày 5 tháng 9 10:56:42 rb-base kernel: [ 152.429676] printk: Tạm dừng (các) bảng điều khiển (sử dụng no_console_suspend để gỡ lỗi)
Ngày 5 tháng 9 10:56:42 rb-base kernel: [ 153.214718] ACPI: EC: ngắt bị chặn
Ngày 5 tháng 9 10:56:42 kernel rb-base: [11468.660690] ACPI: EC: bỏ chặn ngắt
Ngày 5 tháng 9 10:56:42 kernel rb-base: [11469.338032] nvme nvme0: 8/0/0 mặc định/đọc/hàng đợi thăm dò ý kiến
Ngày 5 tháng 9 10:56:42 kernel rb-base: [11469.574414] Đã bật trình diệt OOM.
Ngày 5 tháng 9 10:56:42 rb-base kernel: [11469.574416] Khởi động lại tác vụ ... đã xong.
Ngày 5 tháng 9 10:56:42 kernel rb-base: [11469.584884] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bị ràng buộc 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Ngày 5 tháng 9 10:56:42 rb-base kernel: [11469.586402] thermal thermal_zone6: không đọc được vùng nhiệt (-61)
Ngày 5 tháng 9 10:56:42 rb-base systemd[1]: Kiểm tra điều kiện dẫn đến công việc Run anacron bị bỏ qua.
Ngày 5 tháng 9 10:56:43 rb-base systemd-sleep[7072]: Hệ thống đã hoạt động trở lại.
Ngày 5 tháng 9 10:56:43 rb-base kernel: [11469.846714] PM: tạm dừng thoát
Ngày 5 tháng 9 10:56:43 rb-base systemd[1]: systemd-suspend.service: Thành công.
Ngày 5 tháng 9 10:56:43 rb-base systemd[1]: Đã hoàn tất Đình chỉ.
Ngày 5 tháng 9 10:56:43 rb-base systemd[1]: Đã dừng mục tiêu Ngủ.
Ngày 5 tháng 9 10:56:43 rb-base systemd[1]: Đã đạt mục tiêu Tạm dừng.
Ngày 5 tháng 9 10:56:43 rb-base systemd[1]: Đã dừng mục tiêu Đình chỉ.
Ngày 5 tháng 9 10:56:43 rb-base NetworkManager[1931]: <info> [1630828603.2303] manager: ngủ: yêu cầu đánh thức (ngủ: có bật: có)
Ngày 5 tháng 9 10:56:43 rb-base ModemManager[2119]: <thông tin> hệ thống [sleep-monitor] đang hoạt động trở lại
Ngày 5 tháng 9 10:56:43 rb-base NetworkManager[1931]: <warn> [1630828603.5154] sup-iface[499bce01c63427b3,1,wlo1]: call-p2p-cancel: không thành công với P2P hủy không thành công
Ngày 5 tháng 9 10:56:45 rb-base ModemManager[2119]: <info> [base-manager] không thể kiểm tra hỗ trợ cho thiết bị '/sys/devices/pci0000:00/0000:00:14.3': không được hỗ trợ bởi bất kỳ plugin nào
Ngày 5 tháng 9 10:56:46 rb-base dbus-daemon[1927]: [system] Kích hoạt qua systemd: service name='net.reactivated.Fprint' unit='fprintd.service' được yêu cầu bởi ':1.90' (uid= 1000 pid=3490 comm="/usr/bin/gnome-shell " nhãn="không bị giới hạn")
Ngày 5 tháng 9 10:56:46 rb-base systemd[1]: Bắt đầu Daemon xác thực vân tay...
Ngày 5 tháng 9 10:56:46 rb-base dbus-daemon[1927]: [hệ thống] Đã kích hoạt thành công dịch vụ 'net.reactivated.Fprint'
Ngày 5 tháng 9 10:56:46 rb-base systemd[1]: Bắt đầu Daemon xác thực vân tay.

(Đây là nhật ký đầy đủ, trong trường hợp tôi đã xóa nội dung nào đó có liên quan)

Như bạn có thể thấy, không có bản ghi nào tại thời điểm máy thực sự được đánh thức. Vì vậy, giả định tiếp theo của tôi là thứ gì đó bên ngoài hệ điều hành gây ra sự thức dậy. Nhưng hệ thống nhìn không bị đình chỉ: e.g. màn hình sáng lên và màn hình đăng nhập hiển thị ngay khi tôi mở nắp, thường mất một lúc để bắt đầu màn hình đăng nhập khi tôi mở nắp trên hệ thống đang ngủ.

CẬP NHẬT1: Nhờ nhận xét của @David, mặc dù bản thân WOL không liên quan đến hệ thống của tôi (MSI Summit thậm chí không có thẻ Ethernet), nhưng tôi đã nhận ra rằng tôi phải tìm kiếm một số cấu hình trong thiết lập BIOS. Và tôi tìm thấy ở đó mục "Wake on Thunderbolt⢠device" đã được bật. Tôi có 0 thiết bị Thunderbolt⢠nhưng đã vô hiệu hóa mục nhập này để đề phòng. Điều này đã không giúp đỡ mặc dù.

CẬP NHẬT2: Nó đường may mà /proc/acpi/đánh thức chỉ không hoạt động: như tôi đã đề cập trước đó, tôi đã tắt mọi thứ trừ nút nguồn trong đó, tuy nhiên, khi tôi mở nắp, máy tính vẫn hoạt động.

CẬP NHẬT3 Tập lệnh kết xuất trạng thái pin, theo đề xuất của @sancho.s ReinstateMonicaCellio:

#!/bin/bash

TIME="$(ngày +'%y-%m-%d %H:%M:%S')"
NĂNG LỰC = "$ (mèo /sys/class/power_supply/BAT1/dung lượng)"
HIỆN = "$ (mèo /sys/class/power_supply/BAT1/current_now)"
VOLTAGE="$(cat /sys/class/power_supply/BAT1/voltage_now)"

tiếng vang "$TIME\t$CAPACITY\t\t\t$CURRENT\t$VOLTAGE" >> /home/rb/bat_dump
David avatar
lá cờ cn
Điều này có thể là một số trợ giúp. https://superuser.com/questions/86576/how-does-wol-wake-on-lan-work nó đã từng là vấn đề đối với một số người trong quá khứ.
sancho.s ReinstateMonicaCellio avatar
lá cờ pl
Rút chuột/đầu thu BT?
Roman Bekkiev avatar
lá cờ pl
Đã cố rút phích cắm mọi thứ có thể rút được. =)
Nate T avatar
lá cờ it
Không có trình ghi nhật ký nào sẽ hiển thị mọi nhật ký (mà tôi biết, nhưng một trình ghi nhật ký có thể có tùy chọn hiển thị.) Chúng thường tập trung vào một khía cạnh cụ thể của hệ thống (ví dụ: `dmesg` in các nhật ký liên quan đến khởi động.) Tôi sẽ `cd ` đến `/var/log` và `cat` mỗi cái kết thúc bằng `.log` mỗi lần một cái. Tìm kiếm nhật ký có mục nhập vào khoảng 8:00 và đó là thủ phạm. Một số mục nhập (chẳng hạn như `apt`) sẽ là các thư mục có nhật ký bên trong.Hoặc bạn có thể sáng tạo với `grep`. Một cái gì đó như `cat /var/log/**.log | tiếng kêu `.
Roman Bekkiev avatar
lá cờ pl
Tôi đang bỏ phiếu để đóng câu hỏi này vì Sự cố này rất có thể liên quan đến phần cứng và dường như không thể khắc phục được từ hệ điều hành Ubuntu
Điểm:4
lá cờ pl

Tôi không biết đây có phải là trường hợp của bạn không, nhưng nếu hệ thống của bạn được định cấu hình để ngủ khi đóng nắp và ngủ đông sau 40 phút nói, thì quạt có thể khởi động vào thời điểm đó, khi ngủ đông. Tuy nhiên, điều này sẽ không giải thích được việc tiêu hao pin. Một trường hợp liên quan khác là khi hệ thống được cấu hình để ngủ đông ở một mức pin nhất định. Vì vậy, việc hết pin xảy ra trước (tôi không biết tại sao) và điều đó kích hoạt chế độ ngủ đông. Hoặc, hệ thống có thể không bị treo.

Chẩn đoán trạng thái PC

Kiểm tra các sự kiện có liên quan với

$ tạp chí --no-pager | con mèo -n | grep -A 10 -B 3 systemd-logind

Bạn có thể xác định đình chỉ trong các dòng như

9818455 ngày 08 tháng 9 22:25:57 MyServer systemd-logind[1132]: Đã đóng nắp.
...
9818624 ngày 09 tháng 9 06:43:47 MyServer systemd-logind[1132]: Đã mở nắp.

Hoặc dùng

$ con mèo -n /var/log/syslog | grep -A 10 -B 3 systemd-logind

Của bạn nhật ký hệ thống dường như cho thấy một giấc ngủ hiệu quả, nhưng tôi không chắc chắn. Tôi có PM: tạm dừng nhập cảnh (sâu) (trong Thinkpad) thay vì của bạn PM: tạm dừng nhập cảnh (s2idle). Xem thêm bên dưới.

Chẩn đoán hao pin

Bạn có thể viết một kịch bản, nói dump_bat.sh điều đó kết xuất trạng thái pin để nộp, với một cái gì đó như

#!/bin/bash
upower -i /org/freedesktop/UPower/devices/battery_BAT0 > battery_$(date | tr " " "_").txt

Bạn có thể grep các phần cụ thể của đầu ra như phần trăm, thời gian để trống, cập nhật, và Môn lịch sử mảnh vỡ. Nhớ

$ chmod +x dump_bat.sh

Đặt một công việc định kỳ để thực hiện việc này cứ sau 10 phút sẽ giúp xác định kiểu tiêu hao pin và trạng thái máy tính xách tay (thức/ngủ). cộng

*/10 * * * * <đường dẫn đến dump_bat.sh>

với

$ crontab -e

Tránh hao pin

Hãy thử vô hiệu hóa WOL với cái này

$ ethtool -s <thiết bị> wol d

Kết hợp với chẩn đoán trên.

Roman Bekkiev avatar
lá cờ pl
sancho.s ReinstateMonicaCellio, cảm ơn câu trả lời của bạn! Bản thân việc hao pin không phải là vấn đề: người ta cho rằng quạt chạy suốt đêm sẽ làm hao pin. Về WOL: Tôi không nghĩ điều này có liên quan, như tôi đã nói, máy tính xách tay của tôi thậm chí không có ethernet (chỉ `lo` và `wlo1` hiển thị trong `ip a`), do đó, không có `ethtool`.
Roman Bekkiev avatar
lá cờ pl
Tuy nhiên, liên quan đến `hibernate`, có một điều kỳ lạ: `systemctl hibernate` cho biết `Không thể chuyển sang chế độ ngủ đông thông qua đăng nhập: Động từ ngủ "ngủ đông" không được hỗ trợ`, vì vậy, tôi không nghĩ rằng nó thậm chí còn được hỗ trợ. Tuy nhiên, trong `syslog` có các bản ghi giống như `Lockdown: systemd-logind: hibernation bị hạn chế; xem man kernel_lockdown.7`. Tuy nhiên, đó không phải là những sự kiện gần đình chỉ.
sancho.s ReinstateMonicaCellio avatar
lá cờ pl
@RomanBekkiev - Ý tưởng đằng sau đề xuất của tôi không phải là tránh hao pin, mà như đã nêu là tìm hiểu mô hình hao pin và trạng thái máy tính xách tay (thức/ngủ). Vui lòng thử đề xuất và đăng kết quả.
Roman Bekkiev avatar
lá cờ pl
Chà, đúng như tôi dự đoán, có vẻ như một phần của hệ thống chứa cron không hoạt động, như nó xảy ra với các bản ghi.Đây là kết xuất: https://Gist.github.com/RB-Lab/b2246e7dc47b16d603b943d1a4a17be9 Ở đây máy tính xách tay đang sạc đến 22:30 thì tôi ngắt kết nối bộ sạc và đặt nó ở chế độ treo. Và kỷ lục tiếp theo chỉ xảy ra vào sáng hôm sau, khi tôi mở nắp và đăng nhập, 20% đã được sử dụng. Có vẻ như hệ thống không thực sự thức dậy vào ban đêm mà chỉ là một giấc ngủ không ngon...
sancho.s ReinstateMonicaCellio avatar
lá cờ pl
@RomanBekkiev - Nhận xét của tôi: 1) Ý của bạn là "phần của hệ thống nơi cron cư trú không hoạt động"? Nó dường như đã hoàn thành công việc của mình. Trừ khi bạn đã làm nó một số cách khác. 2) Ý bạn là gì khi "điều đó xảy ra với nhật ký"? 3) "Nhật ký pin" của bạn trông hoàn toàn bình thường. 4) Vấn đề bạn mô tả xuất hiện thường xuyên như thế nào? Nó đã không xảy ra ngày hôm qua.
Roman Bekkiev avatar
lá cờ pl
Có vẻ như chính hệ điều hành ** đang ** ở chế độ treo, do đó, cron không chạy các công việc của nó và không có gì được ghi trong nhật ký. Thứ chạy quạt có thể ở đâu đó trong lớp trừu tượng thấp hơn (ví dụ: BIOS ??). Tôi không nghĩ rằng việc giảm 20% công suất sau 8 giờ là ổn: ví dụ: Máy Mac sử dụng tối đa 3-5% dung lượng pin mỗi đêm, khi chúng ở chế độ ngủ và chiếc Lenovo ThinkPad trước đây của tôi có mức sử dụng pin tương đương. Tuy nhiên, vấn đề có thể không liên quan đến Ubuntu/Linux.
sancho.s ReinstateMonicaCellio avatar
lá cờ pl
@RomanBekkiev - Ok, bây giờ tôi hiểu ý của bạn. Những lời bình luận của tôi: 1) Khoảng trống trong báo cáo pin hoàn toàn có thể xảy ra và nó xác nhận rằng PC bị treo. Điều đó không có nghĩa là có bất cứ điều gì sai với cron hoặc nhật ký, đó chính xác là cách tôi phải làm việc. 2) Đối với việc giảm 20% trong một đêm, điều đó cũng không có nghĩa là có gì sai. Từ OP ban đầu, tôi hiểu rằng pin đã cạn kiệt hoàn toàn qua đêm. Điều đó thật kỳ lạ.
sancho.s ReinstateMonicaCellio avatar
lá cờ pl
3) Liệu 20% có thể được cải thiện hay không, bạn có thể thử một vài điều. a) Kiểm tra với Windows, nếu bạn đã cài đặt. b) Hãy thử bỏ chế độ treo Sx và sử dụng một chế độ khác nếu có thể. c) Kích hoạt chế độ ngủ đông nếu có thể trong hệ thống của bạn. Tất cả điều này có giá trị câu hỏi khác / s. 4) Tôi khuyên bạn nên tiếp tục sử dụng tập lệnh để xem PC của bạn hoạt động như thế nào. 5) Nếu bạn không nắm bắt được trường hợp khi người hâm mộ bắt đầu, đó có thể là một vấn đề khác.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.