System freezes completely with Intel Bay Trail
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
22
down vote
favorite
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)
16.04 kernel intel
add a comment |Â
up vote
22
down vote
favorite
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)
16.04 kernel intel
Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
â Zanna
Mar 5 '17 at 6:48
add a comment |Â
up vote
22
down vote
favorite
up vote
22
down vote
favorite
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)
16.04 kernel intel
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)
16.04 kernel intel
edited Apr 13 '17 at 12:24
Communityâ¦
1
1
asked Jul 27 '16 at 15:40
![](https://i.stack.imgur.com/1scfj.png?s=32&g=1)
![](https://i.stack.imgur.com/1scfj.png?s=32&g=1)
Jack Dix
114114
114114
Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
â Zanna
Mar 5 '17 at 6:48
add a comment |Â
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
add a comment |Â
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.
@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
 |Â
show 1 more comment
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
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
add a comment |Â
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.
@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
 |Â
show 1 more comment
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.
@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
 |Â
show 1 more comment
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.
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.
edited Apr 28 at 22:44
answered Jul 27 '16 at 15:53
![](https://i.stack.imgur.com/8CW8e.png?s=32&g=1)
![](https://i.stack.imgur.com/8CW8e.png?s=32&g=1)
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
 |Â
show 1 more comment
@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
 |Â
show 1 more comment
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
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
add a comment |Â
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
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
add a comment |Â
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
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
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
add a comment |Â
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Relevant: Will the Intel Bay Trail CPU problem be fixed in 17.04?
â Zanna
Mar 5 '17 at 6:48