System freezes completely with Intel Bay Trail

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
22
down vote

favorite
15












My system freezes completely at random, frequent intervals. I started to have the same problem in Ubuntu 14.04 but after recent upgrade to 16.04 there is no improvement, in fact it seems worse.



When it happens, it's impossible to do anything. I've tried everything in this thread: What to do when Ubuntu freezes but nothing works, I have to hard reset. I have read all the system logs and journalctl but there is never any information that could help diagnose the problem.



This is a dual-boot system with Windows 10 and there's no problem there, so it's not defective hardware.



My laptop has an Intel Bay Trail processor (Pentium N3540)







share|improve this question






















  • Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
    – Zanna
    Mar 5 '17 at 6:48














up vote
22
down vote

favorite
15












My system freezes completely at random, frequent intervals. I started to have the same problem in Ubuntu 14.04 but after recent upgrade to 16.04 there is no improvement, in fact it seems worse.



When it happens, it's impossible to do anything. I've tried everything in this thread: What to do when Ubuntu freezes but nothing works, I have to hard reset. I have read all the system logs and journalctl but there is never any information that could help diagnose the problem.



This is a dual-boot system with Windows 10 and there's no problem there, so it's not defective hardware.



My laptop has an Intel Bay Trail processor (Pentium N3540)







share|improve this question






















  • Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
    – Zanna
    Mar 5 '17 at 6:48












up vote
22
down vote

favorite
15









up vote
22
down vote

favorite
15






15





My system freezes completely at random, frequent intervals. I started to have the same problem in Ubuntu 14.04 but after recent upgrade to 16.04 there is no improvement, in fact it seems worse.



When it happens, it's impossible to do anything. I've tried everything in this thread: What to do when Ubuntu freezes but nothing works, I have to hard reset. I have read all the system logs and journalctl but there is never any information that could help diagnose the problem.



This is a dual-boot system with Windows 10 and there's no problem there, so it's not defective hardware.



My laptop has an Intel Bay Trail processor (Pentium N3540)







share|improve this question














My system freezes completely at random, frequent intervals. I started to have the same problem in Ubuntu 14.04 but after recent upgrade to 16.04 there is no improvement, in fact it seems worse.



When it happens, it's impossible to do anything. I've tried everything in this thread: What to do when Ubuntu freezes but nothing works, I have to hard reset. I have read all the system logs and journalctl but there is never any information that could help diagnose the problem.



This is a dual-boot system with Windows 10 and there's no problem there, so it's not defective hardware.



My laptop has an Intel Bay Trail processor (Pentium N3540)









share|improve this question













share|improve this question




share|improve this question








edited Apr 13 '17 at 12:24









Community♦

1




1










asked Jul 27 '16 at 15:40









Jack Dix

114114




114114











  • Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
    – Zanna
    Mar 5 '17 at 6:48
















  • Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
    – Zanna
    Mar 5 '17 at 6:48















Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
– Zanna
Mar 5 '17 at 6:48




Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
– Zanna
Mar 5 '17 at 6:48










2 Answers
2






active

oldest

votes

















up vote
27
down vote













Your processor is affected by the c-state bug



This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.



Affected processors 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)


(please (suggest an) edit to add your own device if affected)



Complete list of Bay Trail processors may be found here



There is a simple workaround for this until it gets properly fixed upstream.



You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.



You do this by editing the configuration file for GRUB:



Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type



sudo nano /etc/default/grub


Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=



This needs to be changed to include intel_idle.max_cstate=1



So after your edit it reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"


quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters



Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x



Now run



sudo update-grub


Then reboot.




What to do if you don't have enough time to do this before the system hangs



No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.



You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.



When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.



Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.



Now press F10 or Ctrl+x to boot.






share|improve this answer






















  • @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27 '16 at 16:39










  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14 '16 at 12:21










  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28 '16 at 21:12










  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
    – Jeremy Cook
    Oct 21 '16 at 19:23











  • @JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
    – Zanna
    Oct 21 '16 at 19:28

















up vote
0
down vote













Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.



The problem is with temperature control. Just remove the thermald module:



sudo apt-get remove thermald 





share|improve this answer


















  • 2




    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7 at 15:42











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f803640%2fsystem-freezes-completely-with-intel-bay-trail%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
27
down vote













Your processor is affected by the c-state bug



This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.



Affected processors 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)


(please (suggest an) edit to add your own device if affected)



Complete list of Bay Trail processors may be found here



There is a simple workaround for this until it gets properly fixed upstream.



You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.



You do this by editing the configuration file for GRUB:



Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type



sudo nano /etc/default/grub


Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=



This needs to be changed to include intel_idle.max_cstate=1



So after your edit it reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"


quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters



Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x



Now run



sudo update-grub


Then reboot.




What to do if you don't have enough time to do this before the system hangs



No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.



You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.



When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.



Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.



Now press F10 or Ctrl+x to boot.






share|improve this answer






















  • @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27 '16 at 16:39










  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14 '16 at 12:21










  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28 '16 at 21:12










  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
    – Jeremy Cook
    Oct 21 '16 at 19:23











  • @JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
    – Zanna
    Oct 21 '16 at 19:28














up vote
27
down vote













Your processor is affected by the c-state bug



This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.



Affected processors 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)


(please (suggest an) edit to add your own device if affected)



Complete list of Bay Trail processors may be found here



There is a simple workaround for this until it gets properly fixed upstream.



You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.



You do this by editing the configuration file for GRUB:



Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type



sudo nano /etc/default/grub


Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=



This needs to be changed to include intel_idle.max_cstate=1



So after your edit it reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"


quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters



Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x



Now run



sudo update-grub


Then reboot.




What to do if you don't have enough time to do this before the system hangs



No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.



You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.



When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.



Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.



Now press F10 or Ctrl+x to boot.






share|improve this answer






















  • @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27 '16 at 16:39










  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14 '16 at 12:21










  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28 '16 at 21:12










  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
    – Jeremy Cook
    Oct 21 '16 at 19:23











  • @JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
    – Zanna
    Oct 21 '16 at 19:28












up vote
27
down vote










up vote
27
down vote









Your processor is affected by the c-state bug



This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.



Affected processors 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)


(please (suggest an) edit to add your own device if affected)



Complete list of Bay Trail processors may be found here



There is a simple workaround for this until it gets properly fixed upstream.



You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.



You do this by editing the configuration file for GRUB:



Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type



sudo nano /etc/default/grub


Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=



This needs to be changed to include intel_idle.max_cstate=1



So after your edit it reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"


quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters



Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x



Now run



sudo update-grub


Then reboot.




What to do if you don't have enough time to do this before the system hangs



No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.



You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.



When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.



Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.



Now press F10 or Ctrl+x to boot.






share|improve this answer














Your processor is affected by the c-state bug



This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.



Affected processors 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)


(please (suggest an) edit to add your own device if affected)



Complete list of Bay Trail processors may be found here



There is a simple workaround for this until it gets properly fixed upstream.



You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.



You do this by editing the configuration file for GRUB:



Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type



sudo nano /etc/default/grub


Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=



This needs to be changed to include intel_idle.max_cstate=1



So after your edit it reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"


quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters



Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x



Now run



sudo update-grub


Then reboot.




What to do if you don't have enough time to do this before the system hangs



No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.



You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.



When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.



Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.



Now press F10 or Ctrl+x to boot.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 28 at 22:44

























answered Jul 27 '16 at 15:53









Zanna

48k13119227




48k13119227











  • @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27 '16 at 16:39










  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14 '16 at 12:21










  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28 '16 at 21:12










  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
    – Jeremy Cook
    Oct 21 '16 at 19:23











  • @JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
    – Zanna
    Oct 21 '16 at 19:28
















  • @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27 '16 at 16:39










  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14 '16 at 12:21










  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28 '16 at 21:12










  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
    – Jeremy Cook
    Oct 21 '16 at 19:23











  • @JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
    – Zanna
    Oct 21 '16 at 19:28















@Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
– Zanna
Jul 27 '16 at 16:39




@Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
– Zanna
Jul 27 '16 at 16:39












Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
– clr
Sep 14 '16 at 12:21




Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
– clr
Sep 14 '16 at 12:21












@clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
– Zanna
Sep 28 '16 at 21:12




@clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
– Zanna
Sep 28 '16 at 21:12












Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
– Jeremy Cook
Oct 21 '16 at 19:23





Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem.
– Jeremy Cook
Oct 21 '16 at 19:23













@JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
– Zanna
Oct 21 '16 at 19:28




@JeremyCook I just installed 16.10 and the first thing I did was edit my boot params - I should really check out this new kernel! Please do let me know if it works or not here.
– Zanna
Oct 21 '16 at 19:28












up vote
0
down vote













Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.



The problem is with temperature control. Just remove the thermald module:



sudo apt-get remove thermald 





share|improve this answer


















  • 2




    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7 at 15:42















up vote
0
down vote













Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.



The problem is with temperature control. Just remove the thermald module:



sudo apt-get remove thermald 





share|improve this answer


















  • 2




    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7 at 15:42













up vote
0
down vote










up vote
0
down vote









Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.



The problem is with temperature control. Just remove the thermald module:



sudo apt-get remove thermald 





share|improve this answer














Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.



The problem is with temperature control. Just remove the thermald module:



sudo apt-get remove thermald 






share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 7 at 15:32









Eliah Kagan

79.5k20221359




79.5k20221359










answered Apr 7 at 15:28









Genia Li

1




1







  • 2




    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7 at 15:42













  • 2




    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7 at 15:42








2




2




I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
– Zanna
Apr 7 at 15:42





I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
– Zanna
Apr 7 at 15:42


















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f803640%2fsystem-freezes-completely-with-intel-bay-trail%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

pylint3 and pip3 broken

Missing snmpget and snmpwalk

How to enroll fingerprints to Ubuntu 17.10 with VFS491