Điều này đã hoạt động hoàn hảo vào ngày 17.10 nhưng sau khi nâng cấp lên 18.04 vào ngày hôm qua, khi đóng nắp, màn hình tắt nhưng không treo đúng cách.

Tôi đi du lịch xung quanh rất nhiều và ngay lập tức nhận thấy hơi nóng (và hao pin) khi lấy nó ra khỏi vali du lịch.

Tôi đã cố gắng bỏ ghi chú những dòng này trong /etc/systemd/logind.conf

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

và khởi động lại nhưng không tạo ra sự khác biệt nào.

Tôi nghĩ rằng tôi đã xoay sở để tìm ra điều gì đang xảy ra, nhờ hai nguồn này: Dell XPS 13 (9370) Ghi chú cài đặt ArchLinux và Diễn đàn Arch Linux .

Vì một số lý do, máy tính xách tay sẽ không ngủ sâu nữa mà thay vào s2idleđó là một chế độ chỉ đơn thuần là một loại màn hình tắt.

Chẩn đoán vấn đề

Để xác nhận xem đây có phải là trường hợp của hệ thống của bạn hay không, hãy tạm dừng máy tính xách tay bằng phương pháp yêu thích của bạn (đóng nắp, nhấn Fn+ End, viết pm-suspendvào thiết bị đầu cuối nếu bạn đã pm-utilscài đặt hoặc nhấn Windowsloại phím suspendvà nhấn Enterphím).

Thức dậy từ chế độ treo và gõ vào một thiết bị đầu cuối : sudo journalctl | grep "PM: suspend" | tail -2. Nếu đầu ra là

May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit

Sau đó, bạn không đi vào giấc ngủ sâu. Bạn cũng có thể kiểm tra cat /sys/power/mem_sleepcái nào sẽ trả lại

[s2idle] deep

xác nhận rằng chế độ treo mặc định là s2idle (vì nó được tô sáng bằng dấu ngoặc).

Khắc phục tạm thời

Để thử một sửa chữa tạm thời, làm echo deep > /sys/power/mem_sleepnhư một người dùng root. Kiểm tra xem nó đã thành công hay chưa bằng cách nhìn vào đầu ra của cat /sys/power/mem_sleepnó

s2idle [deep]

sau đó đình chỉ máy tính xách tay và thức dậy một lần nữa. Nếu sudo journalctl | grep "PM: suspend" | tail -2trả lại

May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit

sau đó vấn đề cần được khắc phục. Bạn có thể đặt máy tính của bạn ngủ trong một vài giờ và kiểm tra xem việc tiêu hao pin có được cải thiện hay không.

Sửa chữa vĩnh viễn

Để làm cho nó vĩnh viễn, bạn phải chỉnh sửa cmdline bootloader của bạn. Để làm như vậy, hãy chỉnh sửa như người dùng root tệp / etc / default / grub, bằng cách chạy chẳng hạn sudo -H gedit /etc/default/grub. Thay thế dòng

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

với

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

và tạo lại cấu hình grub của bạn (chạy sudo grub-mkconfig -o /boot/grub/grub.cfg).

Hãy thử tạo /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

Và khởi động lại. Điều này dường như đang làm việc cho tôi, mặc dù tôi không chắc chắn tôi cũng không được cải thiện với /etc/systemd/logind.confthay đổi tôi đã làm trước tiên. Trong mọi trường hợp, không quan sát thấy tiếng ồn của quạt hoặc nhiệt trong khi bị treo với nắp đóng và nó cũng không phản hồi với ping qua wifi, điều mà tôi đã nhận được, không liên tục, trước đây.

Tuổi thọ pin vẫn giảm trong khi bị treo, có lẽ vì phương pháp làm việc tạm ngưng chỉ kém hiệu quả hơn so với phương pháp mặc định, lý tưởng, dường như không hoạt động đúng, nhưng nó xuất hiện tốt hơn so với hành vi mặc định.

Đã thử trên XPS 13 9370 của tôi, tôi không biết về các mẫu cũ hơn, mặc dù có vẻ như chúng sẽ giống nhau.

Tôi đã thử cài đặt pm-utilsvà sử dụng pm-suspendvà điều đó dường như bị đình chỉ khá hiệu quả, vì vậy tôi muốn xem liệu tôi có thể làm systemd-suspendđiều tương tự không.

Tôi đã xem qua các kịch bản pm-utilsđể tìm hiểu xem nó thực sự đang làm gì, và có vẻ như, trong tình huống này, nó đang làm echo -n "mem" > /sys/power/state. Vì vậy, tôi đã tạo /etc/systemd/sleep.conftập tin như hình trên để phù hợp với nó.

Nó không hoàn toàn rõ ràng hành vi mặc định là gì. Trang hướng dẫn systemd-sleep.confnói rằng bản phân phối phải bao gồm /etc/systemd/sleep.confcác mặc định được biên dịch đã nhận xét, vì vậy bạn có thể xem thông tin này, nhưng trong ubfox tệp này bị thiếu. Tôi nhận thấy rằng nếu cat /sys/power/statebạn nhận được:

freeze mem

Vì vậy, tôi đoán rằng đây là những gì nó đang làm theo mặc định. Tôi đoán là điều đó freezecó thể được chấp nhận, vì nó không gây ra lỗi, điều này sẽ khiến systemd chuyển sang mem, nhưng có thể không thực sự hoạt động đúng, hoặc đáng tin cậy, vì những lý do phức tạp mà chúng ta dường như không thể xác định được. Vì vậy, chỉ gửi memthay vì là một nỗ lực hy vọng để tránh điều đó và chỉ làm những gì pm-suspendlàm.

Tôi nghi ngờ cài đặt SuspendMode thực sự không cần thiết và dù sao cũng không làm gì cả. Tôi nghi ngờ điều này bởi vì cat /sys/power/diskchỉ cần có bạn:

[disabled]

Là người dùng mới, do đó không thể nhận xét bằng một quan sát, buộc phải trình bày nó như một câu trả lời như thể tôi siêu tự tin vào nó! Nhưng tôi nghĩ nó hoạt động.

Các câu trả lời khác ở đây là tuyệt vời, chuyên sâu và nghiên cứu tốt.

Thật không may, họ đã không làm việc cho máy cụ thể của tôi :(

Nếu bạn có đồ họa nVidia, dường như có một bản sửa lỗi đang hoạt động cho nhiều người, được cascagrossa cung cấp một cách hữu ích trong câu trả lời cho câu hỏi này: Ubuntu 18.04 gặp sự cố khi tiếp tục tạm dừng

Nó bị nghi ngờ là trình điều khiển lỗi và có thể loại bỏ các vấn đề đình chỉ bằng cách thêm nouveau.modeset = 0 vào grub và đã được xác nhận trong các nhận xét để giúp khắc phục sự cố cho người khác.

Tôi đã có đồ họa Intel trên máy gặp sự cố của mình và thật kỳ lạ là tôi không có vấn đề gì với Ubuntu hoặc Kubfox 18.04 trên ít nhất 3 máy khác (của bạn tôi và của tôi), vậy tại sao máy đặc biệt này lại bị ảnh hưởng như vậy Không rõ ràng.

Tôi khuyên mọi người gặp phải loại vấn đề này nên làm theo các bước sau để giúp xác định vấn đề:

1. Bạn có đồ họa nVidia không? Nếu vậy, hãy thử thủ thuật nouveau.modeset = 0 grub.

2. Kiểm tra rằng đình chỉ hoạt động ở tất cả. Nếu bạn đang đóng nắp và sau đó mở lại và nó không thức dậy, có vẻ như nó không thể 'tiếp tục'.

   • Bạn có thể chọn thủ công treo trên bất kỳ máy tính để bàn nào nhưng nó hơi bị ẩn trong Gnome Shell - bạn có thể nhấn nút nguồn từ menu trên cùng bên phải của màn hình hoặc nhấp vào nút đó trong khi giữ Alt hoặc nhấn phím Super và gõ trong 'đình chỉ'

   • Bằng cách chọn tạm dừng, bạn có thể kiểm tra xem màn hình đã tắt chưa , đèn LED nguồn đang nhấp nháy như mong muốn và bạn hy vọng rằng bất kỳ quạt nào đang chạy cũng sẽ dừng . Nếu tất cả điều này xảy ra nhưng sau đó bạn không thể khiến máy của mình thức dậy thì đó có vẻ là sự cố 'tiếp tục' thay vì vấn đề 'đình chỉ'.

   • Vấn đề của tôi là nó không thực sự bị đình chỉ và Murray, người đã hỏi câu hỏi ban đầu, khi được va chạmTwo để kiểm tra điều này, nhận ra vấn đề đã phát sinh khi đình chỉ thủ công.

   • Trong trường hợp của tôi (trên một máy tính xách tay có vấn đề) , màn hình bị trống nhưng đèn LED vẫn sáng và nếu quạt đang chạy thì nó vẫn tiếp tục chạy. Máy không phản hồi với bất kỳ thao tác nhấn phím, chuyển động trên bàn di chuột hoặc bấm hoặc nhấn nút nguồn. Điều duy nhất có thể được thực hiện là tắt nó đi.

   • Tôi đã thử phát nhạc trong khi tạm dừng (để kiểm tra xem nó không chỉ là màn hình bị trống) mà âm nhạc dừng lại và về cơ bản máy đã bị thu giữ.

3. Hãy thử máy của bạn với USB trực tiếp 18.04 và kiểm tra xem bạn có gặp sự cố đình chỉ tương tự không.

   • Điều này sẽ chỉ xác nhận rằng các vấn đề đình chỉ không liên quan đến bất kỳ chương trình bổ sung nào mà bạn đã cài đặt.

   • Trong trường hợp của tôi, tôi đã nghi ngờ đó là do tôi đã cài đặt tlp có thể đã can thiệp vào chế độ treo bằng cách nào đó, nhưng hành vi tương tự đã xảy ra với USB trực tiếp của cả Ubuntu 18.04 và Kubfox 18.04

4. Hãy thử hai giải pháp được nghiên cứu kỹ lưỡng khác được cung cấp ở đây bởi monty47 và StrangeNoises và xem bạn có nhận được kết quả tốt hay không.

   • Chúng dường như đã giúp một số người bị đình chỉ hoạt động trở lại và chạy đúng vào ngày 18.04 và có thể liên quan nhiều hơn đến việc máy chuyển sang trạng thái s2idle thay vì chế độ ngủ (sâu) thông thường của 'tạm ngưng'.

5. Nếu không có giải pháp nào hoạt động để giải quyết vấn đề đình chỉ của bạn vào ngày 18.04 thì hãy thử câu trả lời được chấp nhận cho vấn đề này: Ubuntu 18.04 gặp sự cố khi tiếp tục tạm dừng

   • Giải pháp được cung cấp bởi Matalak (người cũng đặt câu hỏi) là sử dụng UKUU để thử kernel 4.14 cũ hơn.

   • Máy vấn đề của tôi không có vấn đề đình chỉ với Ubuntu 17.10 và Kubfox 17.10, vì vậy nó có ý nghĩa vì 17.10 sử dụng kernel 4.14. Hiện tại nó bị đình chỉ tốt trong cả Ubuntu 18.04 và Kubfox 18.04 khi sử dụng kernel 4.14.

6. Nếu bạn đã thử các giải pháp khác và chỉ có thể khắc phục sự cố tạm dừng của mình bằng cách quay lại kernel 4.14, bạn có thể quan tâm đến báo cáo lỗi: https://bugs.launchpad.net/ubfox/+source/linux/+orms/ 1774950

   • Nó dường như chỉ ảnh hưởng đến một số máy có sự kết hợp phần cứng cụ thể và có thể khó xác định trong số các vấn đề liên quan khác hoặc các vấn đề s2idle.

   • Nó dường như phổ biến hơn đối với những người chạy Bay Trail Atom Celeron / Pentium nhưng những người khác đã báo cáo một vấn đề tương tự với các máy khác.

   • Nếu bạn có thể kiểm tra kern.log của mình sau khi tạm ngưng không thành công này (tức là một khi bạn phải tắt máy và khởi động lại), bạn có thể thấy nó báo PM: đình chỉ mục nhập (sâu) và sau đó bạn không có mục nào khác ngoài nhiều dòng khởi động lại.

   • Hiện tại có một bản vá dường như để giải quyết vấn đề.

   • Nếu bạn cảm thấy muốn thêm giọng nói của mình vào báo cáo lỗi, sẽ rất thú vị khi xem những máy cụ thể nào bị ảnh hưởng (và kiểm tra xem bản vá có khắc phục được sự cố cho mọi người không).

Cũng cố gắng tập hợp 'Đình chỉ các vấn đề trong 18.04' trong chuỗi này: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Tôi tin rằng lỗi kernel này có liên quan:

https://ormszilla.kernel.org/show_orms.cgi?id=199689

Xem bình luận số 3 nói riêng:

[V]] Thật sự cố ý sử dụng s2idle trên máy này với kernel ngược dòng mới nhất.

Chỉ muốn thêm câu trả lời cho người dùng Thinkpad X1 Carbon 4th Gen có triệu chứng tương tự như hao pin trong khi bị treo cũng là do không vào chế độ ngủ sâu .

Vấn đề này được thảo luận về chủ đề này trên diễn đàn của Lenovo , trong ngắn hạn, X1C6 đã chọn hỗ trợ Windows Modern Standby. Nếu bạn đọc kỹ chủ đề đó, bạn sẽ thấy rằng mặc dù triệu chứng được chia sẻ, nguyên nhân gốc rễ khác nhau rất nhiều giữa XPS 13 9370 và X1C6 . ví dụ: Đầu ra của cat /sys/power/mem_sleepX1C6 sẽ chỉ [s2idle]biểu thị sự thiếu hỗ trợ cho deepgiấc ngủ.

Các giải pháp được đăng cho đến nay cho câu hỏi này chỉ áp dụng cho XPS 13, và không áp dụng cho X1C6. Theo như tôi hiểu thì giải pháp tốt nhất cho vấn đề chế độ tạm dừng của X1C6 là áp dụng DSDTbản vá đầu tiên do Delta Xi đưa ra và sau đó được PombeirP cập nhật . Bài đăng này sẽ đưa bạn qua cách áp dụng bản vá, nhưng hãy chắc chắn rằng bạn đã đọc bài đăng và tất cả các cập nhật của nó trước bất kỳ hành động nào.

Tôi đã viết một tài liệu chính về các vấn đề liên quan đến việc cài đặt Ubuntu 18.04 trên Thinkpad X1 Carbon 6 Gen bao gồm các giải pháp tôi tìm thấy về vấn đề khởi động chậm do LVM cũng như vấn đề giấc ngủ sâu này gây ra .

Tôi đang sử dụng Lenovo ThinkPad Edge E531 và gặp phải sự cố tương tự khi máy không thể vào giấc ngủ sâu. Hành vi không liên tục và đôi khi tiếp tục, đôi khi khiến touchpad ngừng hoạt động trên wifi để ngắt kết nối.

Tôi đã thử hàng tá bản sửa lỗi được đề xuất trực tuyến, nhưng giải pháp duy nhất hiệu quả với tôi là cài đặt UKUU và nâng cấp kernel lên bản 4.19.11-041911.

Chỉ cần kết thúc Câu hỏi này (hy vọng ...), tôi vừa (tháng 7 năm 2019) đã có bản cập nhật cho 18.04 LTS của mình với HWE, tuyên bố sẽ khắc phục sự cố này cụ thể cho Dell XPS 13 (bao gồm cả việc không sử dụng s2idle .)

FWIW, tôi vừa thay pin trên XPS 13 (9350) 2016 bằng Ubuntu 16.04 và kernél 4.14.12-041412-chung (máy được thiết lập vào đầu năm 2016 với 15.10 và nhân tùy chỉnh sau đó được nâng cấp lên 16.04). Trước khi thay thế, nắp đặt Linux ở chế độ treo như bình thường (mặc dù nếu bạn cắm PSU trong khi tạm dừng hoặc cắm nó, ví dụ như thay đổi trạng thái Linux nghĩ rằng nó hoạt động, nó sẽ chạy rất chậm cho đến khi khởi động lại) . Dù sao, sau khi thay thế (pin bị sưng), máy tính xách tay sẽ khởi động lại để xay khi nắp được đóng lại.

Đặt quản lý năng lượng thành "Tiêu chuẩn" (từ "Nâng cao") trong "Cấu hình pin chính" trong BIOS EFI của Dell (mà bạn có thể đưa lên bằng cách giữ Fn-F2 trong khi khởi động) dường như đã giải quyết được vấn đề.

Đã đi qua rất nhiều giải pháp được liệt kê và không có gì hoạt động cho popOS trên xps 9560 :(

Cho đến khi tôi thấy bản sửa lỗi vui nhộn này trên trang web của dell đang lấy từ một bài đăng LTT.

Vì vậy, giải pháp dự kiến ​​của tôi dường như hoạt động cho đến nay là: bật và tắt một số cài đặt BIOS nhất định. Tôi biết nó nghe có vẻ hết sức ngu ngốc, nhưng tôi thề là nó dường như hoạt động từ những gì tôi đã thử nghiệm cho đến nay.

Cụ thể, tôi tắt các cài đặt và / hoặc chọn một tùy chọn khác cho một cài đặt, áp dụng nó, sau đó đặt lại và áp dụng nó. Các cài đặt tôi bật và tắt là:

• Cấu hình hệ thống> Màn hình cảm ứng (Tắt, sau đó bật lại)

• Quản lý năng lượng> Tự động bật thời gian (Chuyển nó sang một tùy chọn khác, sau đó quay lại Tắt)

• Quản lý năng lượng> Wake on Dell USB-C Dock (Đã tắt, sau đó bật)

Hoạt động tuyệt vời bây giờ. . . .