ระบบหยุดทำงานอย่างสมบูรณ์ด้วย Intel Bay Trail

ระบบของฉันค้างอย่างสมบูรณ์แบบสุ่มบ่อยครั้ง ฉันเริ่มมีปัญหาเดียวกันใน Ubuntu 14.04 แต่หลังจากอัพเกรดเป็น 16.04 เมื่อไม่นานมานี้ก็ไม่มีการปรับปรุงเลยจริง ๆ แล้วมันแย่กว่า

เมื่อมันเกิดขึ้นมันเป็นไปไม่ได้ที่จะทำอะไร ฉันได้ลองทุกอย่างในหัวข้อนี้: จะทำอย่างไรเมื่อ Ubuntu ค้างแต่ไม่มีอะไรทำงานฉันต้องรีเซ็ตอย่างหนัก ฉันได้อ่านบันทึกของระบบทั้งหมดและjournalctlไม่มีข้อมูลใด ๆ ที่สามารถช่วยวินิจฉัยปัญหาได้

นี่เป็นระบบดูอัลบูตที่มี Windows 10 และไม่มีปัญหาดังนั้นจึงไม่มีฮาร์ดแวร์ที่ชำรุด

แล็ปท็อปของฉันมีโปรเซสเซอร์ Intel Bay Trail (Pentium N3540)

16.04 kernel intel

— แจ็คดิกซ์
แหล่งที่มา

ที่เกี่ยวข้อง: ปัญหา Intel Bay Trail CPU จะได้รับการแก้ไขใน 17.04 หรือไม่

— Zanna

คำตอบ:

โปรเซสเซอร์ของคุณได้รับผลกระทบจากบั๊ก c-state

สิ่งนี้ทำให้เกิดการค้างทั้งหมดเมื่อ CPU พยายามเข้าสู่สถานะสลีปที่ไม่รองรับ มันเป็นปัญหาสำหรับอุปกรณ์ Bay Trail จำนวนมากโดยเฉพาะอย่างยิ่งกับเมล็ดใหม่ (4. *)

โปรเซสเซอร์ที่ได้รับผลกระทบ AFAIK:

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

(โปรด (แนะนำให้) แก้ไขเพื่อเพิ่มอุปกรณ์ของคุณเองหากได้รับผลกระทบ)

รายการตัวประมวลผล Bay Trail ทั้งหมดสามารถดูได้ที่นี่

มีวิธีแก้ไขปัญหาง่าย ๆ สำหรับสิ่งนี้จนกว่าจะได้รับการแก้ไขต้นน้ำอย่างถูกต้อง

คุณเพียงแค่ต้องผ่านพารามิเตอร์การบู๊ตเคอร์เนลและการแช่แข็งแบบสุ่มหยุดอย่างสมบูรณ์ พารามิเตอร์อาจเพิ่มการใช้แบตเตอรี่เล็กน้อย แต่จะให้ระบบที่ใช้งานได้

คุณทำได้โดยแก้ไขไฟล์การกำหนดค่าสำหรับ GRUB:

บูต Ubuntu และเปิดเทอร์มินัลโดยกดCtrl+ Alt+ Tจากนั้นพิมพ์

sudo nano /etc/default/grub

ค้นหาบรรทัดที่เริ่มต้น GRUB_CMDLINE_LINUX_DEFAULT=

สิ่งนี้จะต้องมีการเปลี่ยนแปลงเพื่อรวม intel_idle.max_cstate=1

ดังนั้นหลังจากที่คุณแก้ไขมันจะอ่านสิ่งที่ชอบ

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quietและsplashเป็นพารามิเตอร์เริ่มต้นสำหรับ Ubuntu Desktop - ไม่จำเป็นต้องเปลี่ยนแปลงหรืออื่น ๆ ที่มีอยู่ก่อนพารามิเตอร์

ตอนนี้บันทึกไฟล์โดยกดctrl+ oจากนั้นenterออกจากโดยกดctrl+x

ตอนนี้ทำงาน

sudo update-grub

จากนั้นรีบูท

จะทำอย่างไรถ้าคุณไม่มีเวลาพอที่จะทำสิ่งนี้ก่อนที่ระบบจะหยุดทำงาน

ไม่มีปัญหา. ตามที่อธิบายไว้ในหน้าช่วยเหลือที่ฉันเชื่อมโยงไปก่อนหน้านี้คุณสามารถเพิ่มพารามิเตอร์ลงใน GRUB ก่อนที่จะทำการบูทได้ โปรดทราบว่าสิ่งนี้จะส่งผ่านพารามิเตอร์สำหรับการบู๊ตปัจจุบันเท่านั้นดังนั้นคุณยังคงต้องแก้ไข/etc/default/grubเมื่อคุณบูตเพื่อทำการเปลี่ยนแปลงแบบถาวร

คุณจำเป็นต้องได้รับการเมนูด้วง หากคุณทำการบูทสองครั้งระบบจะปรากฏขึ้นหากคุณไม่จำเป็นต้องกดค้างไว้ (หรือแตะ) shiftหลังจากกดปุ่มเพาเวอร์เพื่อเปิด

เมื่อคุณได้รับไปยังหน้าจอนี้เลือกตัวเลือกขั้นสูงสำหรับอูบุนตู คุณสามารถย้ายเคอร์เซอร์ไปที่เคอร์เนลอื่นหรือปล่อยมันไว้เพื่อแก้ไขตัวเลือกสำหรับการเริ่มต้น แทนการกดenterกดeและคุณจะเข้าสู่โหมดแก้ไขมองคลุมเครือเช่นนี้

เลื่อนเคอร์เซอร์ลงไปยังตำแหน่งที่ระบุquiet splashวางช่องว่างหลังจากสาดและพิมพ์อย่างระมัดระวังintel_idle.max_cstate=1เพื่อให้แน่ใจว่ามีช่องว่างหลังจากนั้นเช่นกัน

ตอนนี้กดF10หรือCtrl+ xเพื่อบูต

— Zanna
แหล่งที่มา

@Arronical hehe ขอบคุณ! ฉันต้องรู้สิ่งนี้ - ระบบของฉันจะอยู่ต่อไปอีกประมาณ 15 นาทีโดยปราศจากมัน แต่ด้วย param มันไม่เคยหยุดนิ่งสักครั้ง :) เครดิตทั้งหมดสำหรับแฮ็กเกอร์ที่น่ากลัวจริง ๆที่คิดออก

— Zanna

ขอขอบคุณ! สิ่งนี้จะหยุดการตอบสนองต่อ Ctrl Alt REISUB หรือไม่? การตอบสนองต่อการแก้ไข GRUB ข้างต้นก็คือหากตั้งค่าการหมดเวลาซ่อนไว้การแก้ไขข้างต้นจะไม่ทำงาน เราจะแก้ไขปัญหานี้ได้อย่างไรถ้าปัญหายังคงมีอยู่?

— clr

@clr การค้าง c-state ไม่ตอบสนองต่อ Magic sysrq REISUB แต่การแก้ไขนี้จะหยุดการค้าง c-state หากระบบของคุณค้างด้วยเหตุผลอื่น REISUB อาจทำงานได้ GRUB_HIDDEN_TIMEOUT ไม่มีผลกับพารามิเตอร์การบู๊ตและคุณควรจะสามารถเข้าถึงเมนูได้โดยกดปุ่ม shift เมื่อเริ่มต้น หากคุณไม่สามารถในกรณีที่ระบบค้างเร็วเกินไปสำหรับคุณที่จะแก้ไข/etc/default/grubที่เจ็บปวด แต่คุณสามารถลองบูตเซสชั่นสดของรุ่นที่มีเคอร์เนลเก่าเพื่อแก้ไขไฟล์ - ติดพาร์ทิชันราก/mntและแก้ไข/mnt/etc/default/grubเพื่อ เพิ่มพารามิเตอร์

— Zanna

ขอบคุณสำหรับคำแนะนำที่ชัดเจน ฉันหวังว่านี่จะเป็นการหลอกลวง ฉันจะรายงานกลับที่นี่ถ้าไม่ ฉันกำลังใช้งาน 16.10 บน Zotac Nano CI320 ก่อนหน้านี้ฉันได้ลอง 16.04 และ Debian 8 แล้วและยังพบปัญหาการค้างแบบสุ่มอีกด้วย ฉันลอง 16.10 หวังว่าปัญหาจะหายไปกับเคอร์เนลที่ใหม่กว่า ที่น่าสนใจครั้งหนึ่งที่ฉันลอง REISUB (ฉันจำไม่ได้ว่าระบบปฏิบัติการใด) ทำงานได้ดังนั้นมันอาจกลายเป็นว่าฉันกำลังเผชิญกับปัญหาที่แตกต่าง

— Jeremy Cook

@ JeremyCook ฉันเพิ่งติดตั้ง 16.10 และสิ่งแรกที่ฉันทำคือแก้ไข params การบูตของฉัน - ฉันควรตรวจสอบเคอร์เนลใหม่นี้! โปรดแจ้งให้เราทราบหากใช้งานได้หรือไม่อยู่ที่นี่

— Zanna

ตัวประมวลผล Linux บน Bay Trail และ Braswell หยุดการทำงานแบบสุ่มด้วยอุปกรณ์วิดีโอในตัว

ปัญหาอยู่ที่การควบคุมอุณหภูมิ เพียงลบโมดูล thermald:

sudo apt-get remove thermald

— Genia Li
แหล่งที่มา

ฉันเชื่อว่าข้อผิดพลาดของ Bay Trail อยู่ในไดรเวอร์ i915 (Intel CPU) โปรเซสเซอร์พยายามที่จะเข้าสู่สถานะสลีปที่ไม่ได้รับการสนับสนุนอย่างต่อเนื่อง ปัญหาสำหรับผู้ใช้ Bay Trail เริ่มต้นหลังจากที่ตกลงกับ i915 ดังนั้นจึงถูกตำหนิเสมอ อย่างไรก็ตามอาจมีสาเหตุอื่นสำหรับบางคนและฉันไม่มีความคิดเกี่ยวกับการแช่แข็ง Braswell และมันจะดีที่รู้ว่าพวกเขาได้รับการแก้ไขโดยการกระทำบางอย่าง (ปลอดภัย?) คุณมีการอ้างอิงใด ๆ สำหรับข้อมูลนี้หรือคุณสามารถบอกเราว่าฮาร์ดแวร์นี้ถูกทดสอบและใช้งานได้หรือไม่?

— Zanna

ดูเหมือนว่านี่จะยังคงเป็นปัญหากับ 19.04 เป็นความหวังชนิดหนึ่งที่จะได้รับการแก้ไขในตอนนี้ เกิดขึ้นในแล็ปท็อปของฉันตั้งแต่หลังจาก 14.04 15.10 แทบจะเป็นไปไม่ได้ที่จะแก้ไข

— crip659

สำหรับคนที่ติดตามบั๊กนี้ที่นี่เป็นการอัพเดท ลุยเลย: Bug 109051 - intel_idle.max_cstate = 1 ที่จำเป็นใน baytrail เพื่อป้องกันการล่มและกดEndปุ่ม หากจำเป็นให้กดPage Upที่ข้อความ # 1013

ตามความคิดเห็นที่ # 1013 มันได้รับการแก้ไขแล้วในเมล็ดล่าสุด:

ฉันไม่ได้ตรวจสอบกระทู้นี้มาเป็นเวลานาน แต่ฉันคิดว่าฉันควรโพสต์สิ่งที่ฉันค้นพบในกรณีที่มีประโยชน์กับทุกคน

คอมพิวเตอร์ระดับต่ำที่ขับเคลื่อนด้วย Intel N2807 ซึ่งไม่เคยทำงานมากกว่า 30 ล้านโดยไม่หยุดทำงานเมื่อฉันไม่ได้ตั้งค่า ... max_cstates = 1 ตอนนี้ทำงานได้ดีกับหุ้นเคอร์เนล v. 5.3.1 หรือ 4.19.75 ฉันวิ่งไปสองสามวันกับแต่ละรุ่นโดยไม่มีปัญหาใด ๆ การใช้พลังงานเฉลี่ยก็ลดลงกว่า 10% เล็กน้อย

การแก้ไขข้อผิดพลาดนี้ใช้เวลาประมาณสี่ปีก่อนรายงานเมื่อวันที่ 8 ธันวาคม 2558

— WinEunuuchs2Unix
แหล่งที่มา