Kindle PW2 battery issues 5.7.2.1

[knc1]

Hmm...
The serial port must not have the correct DISPLAY= setting, at least htop does not like it.
attachment from:

[root@kindle root]# htop -C --sort-key=PERCENT_CPU --pid=`pidof cvm`

"tree view" is even more useless (the attachment IS tree view and cvm itself has not (yet) made an appearance (its pid=20321) ).

But I do see what you meant about CPU%
The bundled 'top' may be summing all of the cvm threads -
of which there is probably over a hundred threads for the one task.

but I'll practice a bit with the utility.

[knc1]

Ah, I forgot, this is a 3.0.x series kernel - we can throttle that cpu hog if we want to:

[root@kindle root]# cat /proc/20321/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             4016                 4016                 processes 
Max open files            1024                 4096                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       4016                 4016                 signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

Hmm...
It (cvm parent thread) is only showing me a screensaver, and:

[root@kindle root]# ls -l /proc/20321/fdinfo | wc -l
741

and it has 741 file descriptors open (almost its soft limited number).

Edit:
If the author of cvm forgot to close any unused file descriptors of the 3 standard file descriptors per thread -
HTOP showed 243 threads, *3 == 729 file descriptors.
I think I see a relationship there.

And if the author of cvm decided to poll that many file descriptors . . . .
Well, see:
https://daniel.haxx.se/docs/poll-vs-select.html
and the reference it links to.

#9600

[knc1]

"Top" also has a 'threads mode' (although not in 'tree' form).

For the command:

[root@kindle root]# top -H -U framework -bn1 >ss.txt

The winner is:
CVM-IndexerThread

It is done when shown in the attachment and the screensaver is being displayed, but it had to index all of four books after I removed the testWrite.txt write blocker.

So much time, so little (new) learned.
The Indexer has been a source of problems for years now.

Note:
The 'search for garbage' in the search bar no longer tells you if the indexer is running.

[knc1]

fixy, fixy, fixy indexer state test - -

Not yet, but going on what we learned yesterday:

[root@kindle root]# lipc-probe -v com.lab126.indexer
        r       Int     numberOfItemsToBeIndexed        [0]
        w       Int     dumpIndexerState
        w       Int     updateIndexerState
        r       Str     pauseIndexerTillTimeMilliseconds        [-1]
        w       Int     pauseIndexerMilliseconds
        rw      Int     debugTextDumpCount      [0]
        w       Str     indexAndSearchContent
        w       Str     pauseIndexerSourceMilliseconds

It looks like the services exist to determine if it is running and some limited control over it.

Rather than a search bar command, perhaps a set of KUAL buttons?

[knc1]

Even better yet - Lab126 shipped us a sample reporting script -
see: /usr/bin/dmcc.sh
I.E: search bar ;dmcc
You will have to comment (#) out the top test which is disabling it on production devices.

Make it look like this:

# verify we are on a pre GM device 
#if ! [ -e "/PRE_GM_DEBUGGING_FEATURES_ENABLED__REMOVE_AT_GMC" ]; then
#    exit 0
#fi

tl;dr: only for the adventurous with command line access at the moment.

Here we go, an example of the script's output (which is .html, not the .txt of the filename used):
http://kaynine.info/pw3/Mar_11_14.36.19_2016.html
(I wish ixtab was here to tell us what all those java thread frames dump'd meant.)

(The Kindle reader displays html, only if it has the extension .txt, which is why the script generates an html file with a .txt filename extension.)

[NiLuJe]

@knc1: Does htop throw any specific error over serial, or was is just an issue with the colorscheme? (in which case, there are a few to chose from in the settings).

[knc1]

Originally Posted by NiLuJe

@knc1: Does htop throw any specific error over serial, or was is just an issue with the colorscheme? (in which case, there are a few to chose from in the settings).

I turned off color in htop with a command line option.

It was the positioning -
And I have since learned that it isn't limited to htop.
Both the nano you built and the nano I built show the same problem.

And I know all three work over ssh just fine.

So it must have something to do with the kernel end of the serial port.
I haven't taken the time to look into that minor problem.

If you look at the KDK crash logs in:
http://kaynine.info/pw3/Mar_11_14.36.19_2016.html
you can see that KUAL is running into permission problems with one of its temporary files.

I haven't looked into that minor problem yet either -
but I'll bet the user name that KUAL runs under has changed -
and since KUAL survives the problem, nobody noticed.

OR

Our Kindlet Jailbreak is missing a read permission over-ride somewhere.

= = = =

The Java thread dump shows a number of things waiting on java.util.LinkedList or java.util.TaskQueue (which probably extends java.util.LinkedList).

If ixtab was here, he could probably tell us if that looks abnormal.
It looks strange to me, but I only drink Java, not write it.

(Things waiting, should be all waiting on an event signal, not for an internal support routine to complete. It almost looks like a "soft" deadlock in other languages.)

= = = =

I am going to post a KUAL button the re-enables those debugging routines available in the search bar shortcuts.
There are quite a few of them and this forum has more eyes than lab126 does.

[NiLuJe]

@knc1:

What's TERMINAL set to? (linux, I imagine? See if forcing it to xterm helps).
I assume you're in main and have /mnt/us available? (Because the terminfo db is stored there ;p).

As for the KDK crash logs, yup, that's the good old JB race condition, I'm afraid .

[knc1]

Originally Posted by NiLuJe

@knc1:

What's TERMINAL set to? (linux, I imagine? See if forcing it to xterm helps).
I assume you're in main and have /mnt/us available? (Because the terminfo db is stored there ;p).

As for the KDK crash logs, yup, that's the good old JB race condition, I'm afraid .

A local attack of PEBCAK -

The serial port is the default operator's console for the kernel
and the kernel uses a very dumb, can barely print a character by itself, serial port driver for 'console'.

[n1kk00]

Originally Posted by knc1

The Java thread dump shows a number of things waiting on java.util.LinkedList or java.util.TaskQueue (which probably extends java.util.LinkedList).

If ixtab was here, he could probably tell us if that looks abnormal.
It looks strange to me, but I only drink Java, not write it.

(Things waiting, should be all waiting on an event signal, not for an internal support routine to complete. It almost looks like a "soft" deadlock in other languages.)

wait/notify(All) is the standard Java mechanism to coordinate multiple theads, i.e. those things are waiting to acquire a lock to access a shared resource or complete some action - doesn't look abnormal to me

edit: of course, I've no idea what each thread is waiting on or when it will be able to make progress - just saying that waiting is not a problem per se

[knc1]

Originally Posted by n1kk00

wait/notify(All) is the standard Java mechanism to coordinate multiple theads, i.e. those things are waiting to acquire a lock to access a shared resource or complete some action - doesn't look abnormal to me

OK - I'll go with that.
I have heard that Java has its own idea of thread handling, so if what we see in the listing is just its own normal way of doing things . . . .

[knc1]

Originally Posted by hardeepthind

Hello,

I recently upgraded my PW2 (not jailbroken) to the latest firmware 5.7.2.1. Now my battery life has suddenly become quite poor! Has anyone else experienced this?

Being relatively new to kindle/firmware, I looked into downgrading to an earlier version of the firmware but the device doesn't allow that....

Any suggestions or thoughts will be appreciated!

Thanks

There is now a set of KUAL buttons that will report the information on the CPU Control(s) in-use.
https://www.mobileread.com/forums/sho...d.php?t=271929

This report includes information that may be helpful to us in finding out the cause for this poor battery run-time problem.

The button-set also includes buttons that allow some control over the CPU speed (and hence, its power consumption).

# 97 97

[knc1]

Updated cpuControl button set (v-1.2) with a (now) 'fixed' CPU Report function.
See:
https://www.mobileread.com/forums/sho...d.php?t=271929

Note: Older softwares had the 'conservative' governor included in the kernel's build.

Although strange as strange can be 5.3.7.3 (K5) boots to using the 'performance' governor by default (which is just locked to max cpu freq and max power usage).

[HarryT]

Is it only some people who are experiencing battery issues? I upgraded my Voyage from 5.6.5 to first 5.7.2.x and now 5.7.3 and haven't seen any noticeable change in battery life.

[knc1]

Originally Posted by HarryT

Is it only some people who are experiencing battery issues? I upgraded my Voyage from 5.6.5 to first 5.7.2.x and now 5.7.3 and haven't seen any noticeable change in battery life.

I am trying to find out.

If folks will post the report on the current cpu controls, I might stand a chance of guessing what is happening.

It is really hard to answer that question -
Most people may not be reporting the problem because they just think that is the way it is supposed to be.