Why did my Kindle reboot itself? - Page 2

DiapDealer · 01-15-2013, 07:53 AM

Quote:

Originally Posted by HarryT

JavaSCRIPT. Very, very different to Java

.

Yep. I'm just going by what I occasionally yank out to peruse, though... and a whole big bunch of it is Java. There is a lot of Javascript, too, to be fair.

twowheels · 01-15-2013, 05:46 PM

ixtab: I seem to remember the desktop Linux kernel having a fairly aggressive OOM (out of memory) task killer that did away with leaking processes. Does the Kindle's build not have that? Then again, I seem to remember the OOM killer giving root processes the most leeway, so maybe it wouldn't do anything even if it were there...

NullNix · 01-18-2013, 10:18 AM

It's quite possible that the oom killer is involved, but it is clearly not entirely the oom killer's doing: at the very least there has to be a process protected from the oom killer which is watching for oom and triggering a reboot. More likely there is a trivial kernel hack to autoreboot on oom.

I had what a believe is a framework restart on my Paperwhite a couple of days ago, while using X-Ray -- actually laughing at it, this particular book had mixed up three characters into one and missed half the characters in the book out, very useful. I got the reboot screen with the moving progress bar immediately. The no-progress-bar reboot screen (a framebuffer screen covering the Linux kernel's boot messages) which appears before that in a true reboot never appeared. Thus my conclusion that this was the framework and possibly X server restarting. (The X server is never oom-killed -- on hardware with conventional graphics cards that has a tendency to be disastrous and can even lock up the PCI bus and require a power-off! -- so whatever shut that down cannot have been the oom killer.)

As for what can be oom killed (assuming the oom killer is enabled), this changes across kernel versions. Root processes get a bonus against being oom-killed, but if everything is running as root this is irrelevant. They are still oom-killable. init (PID 1) cannot be oom killed. Kernel threads cannot be oom killed. Processes that mark themselves (via /proc/self/oom_adj/oom_score_adj) as un-oom-killable cannot be oom killed. In many kernels, tasks engaging in direct hardware access (e.g. the X server) cannot be oom killed. Everything else is fair game.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Kindle 5.3.2 stuck at reboot	tommytomtom	Kindle Developer's Corner	9	01-12-2013 11:19 AM
Kindle 2 Browser Always Crash and Cause Reboot	kurlez	Amazon Kindle	0	03-18-2011 02:22 AM
Kindle 3 Freeze / Endless Reboot Cycle	ForrestDC	Amazon Kindle	6	01-05-2011 05:56 PM
Troubleshooting Kindle 2 stuck in endless reboot cycle	mowog74	Amazon Kindle	5	12-13-2010 02:35 PM
opf to mobi to kindle freeze/reboot	tjcarter	Kindle Formats	13	07-05-2008 12:24 PM

01-15-2013, 05:46 PM	#17
twowheels Wizard Posts: 1,786 Karma: 13412766 Join Date: Nov 2010 Device: Kobo Clara HD, iPad Pro 10", iPhone 15 Pro	ixtab: I seem to remember the desktop Linux kernel having a fairly aggressive OOM (out of memory) task killer that did away with leaking processes. Does the Kindle's build not have that? Then again, I seem to remember the OOM killer giving root processes the most leeway, so maybe it wouldn't do anything even if it were there...

01-18-2013, 10:18 AM	#18
NullNix Guru Posts: 916 Karma: 13928438 Join Date: Jan 2013 Location: Ely, Cambridgeshire, UK Device: Kindle Oasis 3, Kindle Oasis 1	It's quite possible that the oom killer is involved, but it is clearly not entirely the oom killer's doing: at the very least there has to be a process protected from the oom killer which is watching for oom and triggering a reboot. More likely there is a trivial kernel hack to autoreboot on oom. I had what a believe is a framework restart on my Paperwhite a couple of days ago, while using X-Ray -- actually laughing at it, this particular book had mixed up three characters into one and missed half the characters in the book out, very useful. I got the reboot screen with the moving progress bar immediately. The no-progress-bar reboot screen (a framebuffer screen covering the Linux kernel's boot messages) which appears before that in a true reboot never appeared. Thus my conclusion that this was the framework and possibly X server restarting. (The X server is never oom-killed -- on hardware with conventional graphics cards that has a tendency to be disastrous and can even lock up the PCI bus and require a power-off! -- so whatever shut that down cannot have been the oom killer.) As for what can be oom killed (assuming the oom killer is enabled), this changes across kernel versions. Root processes get a bonus against being oom-killed, but if everything is running as root this is irrelevant. They are still oom-killable. init (PID 1) cannot be oom killed. Kernel threads cannot be oom killed. Processes that mark themselves (via /proc/self/oom_adj/oom_score_adj) as un-oom-killable cannot be oom killed. In many kernels, tasks engaging in direct hardware access (e.g. the X server) cannot be oom killed. Everything else is fair game.

Advert