Using swap on a PW-3

knc1 · 02-15-2016, 01:08 PM

On a PW-3 (G090 G1 - fw-5.6.1.1), 512Mbyte Ram, 4Gbyte eMMC ::

Using the system feature that /var/local is always mounted; either in 'main' or 'diags'.

Setup to use 1/4 of /var/local for a system swap file.

Over ssh (or telnet or serial port or from kTerm) -

Code:

[root@kindle root]# cd /var/local

[root@kindle local]# df .
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p3           63461     16692     43493  28% /var/local

Note that the PW-3 has a /var/local partition twice the size of what it was on the KT.
The Busybox/Ash command line can do simple math, find number of erase blocks:

Code:

[root@kindle local]# echo $((1024*1024*16/4096))
4096

Linux swap files **must** be initialized to zeros (no sparse files allowed):

Code:

[root@kindle local]# dd if=/dev/zero of=swap bs=4096 count=4096
4096+0 records in
4096+0 records out
16777216 bytes (16.0MB) copied, 0.627486 seconds, 25.5MB/s

Interesting, the 'bulk write' on the PW-3 eMMC is 1/2 the rate as on the KT eMMC. ( ? )
The swap file requires a special format:

Code:

[root@kindle local]# mkswap ./swap
Setting up swapspace version 1, size = 16773 kB
no label, UUID=abd86682-51a1-42f6-aede-228fea736287

The above completes the (one-time) setup of a PW-3 swapfile.
Its use by the system is controlled by the swapon and swapoff commands.

Code:

[root@kindle local]# swapon ./swap
[root@kindle local]# free
             total       used       free     shared    buffers     cached
Mem:        515344     503292      12052          0     291540      54556
-/+ buffers/cache:     157196     358148
Swap:        16016          0      16016

Now open Kindle Paperwhite User's Guide

Code:

[root@kindle local]# free
             total       used       free     shared    buffers     cached
Mem:        515344     500168      15176          0     275520      60604
-/+ buffers/cache:     164044     351300
Swap:        16016       2412      13604

Browse the user's guide.
Then close Kindle Paperwhite User's Guide

Code:

[root@kindle local]# swapon -s
Filename                                Type            Size    Used    Priority
/var/local/swap                         file            16016   1556    -1

[root@kindle local]# df .
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p3           63461     33148     27037  55% /var/local

For users with a lot of books, perhaps using only 8Mbyte (half the above size) for the swap file would be a better choice.
Even using only 2Mbyte of file space for the swap file reduces the kernel's page management workload.

To the end-user, the appearent change is a more responsive Kindle.

Since the above steps do not make an addition to /etc/fstab, the use of the swap file will 'go away' with the next re-boot.

That is: the 'swapon /var/local/swap' command needs to re-issued after each reboot (the normal system shutdown will take care of the 'swapoff' process).

When (IF) I get the spare time, I'll create a KUAL extension button (set) to let the non-technical user deal with all of the above.

Note 1:
If your 'main' system chokes by running out of space on /var/local -
just re-boot into 'diags' and remove the /var/local/swap file.
An easy way to do that, is to have RP (Rescue Pack) installed.
The RP re-enables the recognition of the flag file: ENABLE_DIAGS, previously last seen on the KT.

Note 2:
Other directions you find may say to put the swap file in user storage.
Not a good idea, because the Kernel can't access user storage when it is exported as mass storage over USB.
And the Kernel really, really does not like to have the backing store of its swap file suddenly disappear.

nixkalo · 02-15-2016, 05:07 PM

Is there any risk that constant read/write from eMMC will wear it off and reduce kindle lifetime?

nixkalo · 02-15-2016, 05:15 PM

Quote:

Originally Posted by nixkalo

Is there any risk that constant read/write from eMMC will wear it off and reduce kindle lifetime?

On the other side we are doing also the opposite with /var: taking 32Mb of RAM for use as filesystem.
Maybe /var size can be reduced in /etc/upstart/system.conf?

NiLuJe · 02-15-2016, 05:17 PM

Shrinking /var/local is potentially a terrible (read: softbrick) idea.

knc1 · 02-15-2016, 06:10 PM

Quote:

Originally Posted by nixkalo

Is there any risk that constant read/write from eMMC will wear it off and reduce kindle lifetime?

Of course.
Depending on how you define 'constant' (such as events per unit time).

Have you considered the numbers?

4Gbyte eMMC == 1 million, 4096 byte erase blocks.

With a really good micro-controller in the eMMC - you have to cycle through an erase/program cycle on **each** erase block before you get to the second cycle on the first block you 'wrote'.
(A not-so-good micro-controller will only wear-level over the unused erase blocks - think flash stick.)

So it takes 1 million + 1 'write' operations before you cycle an erase block the second time.

Erase blocks are usually guaranteed for somewhere between 20,000 and 100,000 erase/program cycles.

Hmm...
(1,000,000 * 100,000) + 1 e/p cycles before you exceed the expected lifetime of one (1!) erase block, you still have 999,999 still working.

Take whatever your definition of 'constant' as events per unit time -
divide that into 100,000,000,000
See how many units of time that will take.
(3 per second is about 100 years)

You are much more likely to have the eMMC fail due to a low storage capacity battery than swap usage.

knc1 · 02-15-2016, 06:15 PM

Quote:

Originally Posted by nixkalo

On the other side we are doing also the opposite with /var: taking 32Mb of RAM for use as filesystem.
Maybe /var size can be reduced in /etc/upstart/system.conf?

On the other side of what? Reality?

Have you read the logs of what all the system does to verify the partitioning of the eMMC is 'as expected'?
Read the logs attached to the 'recover ... with fastboot' thread.

PS: only the /var/local sub-tree of /var is on its own partition.
The rest of the /var tree is already in RAM (specifically, the VFS cache blocks):

Code:

[root@kindle /var]# df .
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    32768       696     32072   2% /var

nixkalo · 02-15-2016, 06:51 PM

Quote:

Originally Posted by knc1

Of course.
Depending on how you define 'constant' (such as events per unit time).

(snip: really detailed calculation of the expect number of cycles until a failure appears)

You are much more likely to have the eMMC fail due to a low storage capacity battery than swap usage.

Exactly the answer I was looking for

nixkalo · 02-15-2016, 07:10 PM

Quote:

Originally Posted by knc1

On the other side of what? Reality?

Have you read the logs of what all the system does to verify the partitioning of the eMMC is 'as expected'?
Read the logs attached to the 'recover ... with fastboot' thread.

PS: only the /var/local sub-tree of /var is on its own partition.
The rest of the /var tree is already in RAM (specifically, the VFS cache blocks):

Code:

[root@kindle /var]# df .
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    32768       696     32072   2% /var

Sorry, English is not my mother language. what I meant with "other side" was:

-your proposal is using what we could loosely call "filesystem bytes" (eMMC) in order to have more virtual memory by using swap
-but the /var (NOT /var/local) filesystem is using tmpfs and does exactly the contrary; it steals "virtual memory bytes" from RAM in order to give us more "filesystem bytes"

Hence my idea of just reducing the space occupied by the /var filesystem.Then it wouldn't use as many VFS blocks, more RAM is available for other things and swap is not needed.
It seems like only 3 files in /etc/upstart would need modification. Partitions are NOT touched.

.... but since I know little about internals of Linux memory management, maybe tmpfs is so "smart" that the following

Code:

[root@kindle /etc]# df /var
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    32768      1104     31664   3% /var

means only 1104K (as opposed to 32768) are really used. In which case my proposal is completely useless

BR,
Nix

knc1 · 02-15-2016, 08:03 PM

Quote:

Originally Posted by nixkalo

Sorry, English is not my mother language. what I meant with "other side" was:

-your proposal is using what we could loosely call "filesystem bytes" (eMMC) in order to have more virtual memory by using swap
-but the /var (NOT /var/local) filesystem is using tmpfs and does exactly the contrary; it steals "virtual memory bytes" from RAM in order to give us more "filesystem bytes"

Hence my idea of just reducing the space occupied by the /var filesystem.Then it wouldn't use as many VFS blocks, more RAM is available for other things and swap is not needed.
It seems like only 3 files in /etc/upstart would need modification. Partitions are NOT touched.

.... but since I know little about internals of Linux memory management, maybe tmpfs is so "smart" that the following

Code:

[root@kindle /etc]# df /var
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    32768      1104     31664   3% /var

means only 1104K (as opposed to 32768) are really used. In which case my proposal is completely useless

BR,
Nix

VFS: Virtual File System

I/O in Linux is 'layered'.

VFS is the 'highest' (closest to kernel code) layer.

On the 'other side' of VFS is a cache system.

The backing store of tmpfs is the memory pages in the cache system.

In general:
Lower the tmpfs usage - increase the free cache pages, reduce the need for actual i/o.
Increase the tmpfs usage - decrease the free cache pages, increase the need for actual i/o.

So using tmpfs for a swap file, decreases the free cache pages, increasing the need for i/o, increasing the use of swap.

But as you can imagine, that is a much longer code path than just leaving the cache pages alone in the first place.

= = = =

There is another way that I haven't tried, but may be worth trying -
What ASUS liked to do with their media player systems.

Create a ram disk, reducing the system memory by however much you use.

Keep in mind that Kindles only had 256 Mbytes of ram for years, it is only recently they went to 512 Mbytes in the most recent models.
So reducing that 512 Mbytes by a few Mbytes **should not** have all that great an impact on the overall system.

Linux, unlike some popular operating systems, can use either files or partitions for swap space.
It can also use multiple files and/or partitions in any combination for swap space.

Each of the members of such a combination of swap stores can be assigned a priority, 0 ... 100, 60 is the default.
The larger numbered stores are used first.

So perhaps we can reduce the (slow to write) use of the eMMC swap space with a smaller, much faster, swap file on ram disk.

I'll try such a setup on my PW-3 (512 Mbyte of ram) tomorrow, and see just how crazy ASUS was with their ramdisk swap file idea.

knc1 · 02-16-2016, 11:57 AM

For our two level swap space, we want a relatively small area of RAM as the first choice swap area followed by a larger, and much slower, area in /var/local (/dev/mmcblk0p3).
This will be an enhancement over the ASUS idea of swap in RAM.

Since the Kernel used with the PW-3 does not have the brd module (ramdisk) available we will have to sneak up on this layout in a round-about way.
So round-about you would expect the memory page being written might get lost.

Update: It does, the system deadlocks.
I left the step-by-step here for a reference to one way **not** to do this.

The tmpfs filesystem is implemented in the VFS i/o cache buffers and store backed by swap.
The i/o cache buffers are dynamic in number and occupy all un-used RAM at any moment.

Learn about the temporary sub-tree of the system file tree, located in tmpfs and not subject to the mntroot ro/rw thingy:

Code:

[root@kindle root]# df /var
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    32768       444     32324   1% /var

[root@kindle root]# cd /var
[root@kindle /var]# ls
backups  cache    lib      local    lock     log      run      tmp

We need a directory there to serve as the mount point for a ext2 file system, store backed by tmpfs.

Code:

[root@kindle /var]# mkdir swp
[root@kindle /var]# mount -t tmpfs -o size=4M ext2 /var/swp
[root@kindle /var]# ls /var/swp
- - empty - -

Within that 4 Mbyte file system, make a 2 Mbyte file and lookup some of the things we can learn about it.

Code:

[root@kindle /var]# dd if=/dev/zero of=/var/swp/lvl1 bs=1024 count=2048
2048+0 records in
2048+0 records out
2097152 bytes (2.0MB) copied, 0.013983 seconds, 143.0MB/s

[root@kindle /var]# ls -l swp
-rw-rw-r--    1 root     root       2097152 Feb 16 09:56 lvl1

[root@kindle /var]# df swp
Filesystem           1K-blocks      Used Available Use% Mounted on
ext2                      4096      2056      2040  50% /var/swp

[root@kindle /var]# stat swp/lvl1
  File: swp/lvl1
  Size: 2097152         Blocks: 4112       IO Block: 4096   regular file
Device: 10h/16d Inode: 36085       Links: 1
Access: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-02-16 09:56:30.000000000
Modify: 2016-02-16 09:56:30.000000000
Change: 2016-02-16 09:56:30.000000000

This step is just to show an example that we can't use that file directly for a swap file.

Code:

[root@kindle /var]# mkswap /var/swp/lvl1
Setting up swapspace version 1, size = 2093 kB
no label, UUID=813fd1a8-8936-477d-ad00-554654df4263

[root@kindle /var]# swapon /var/swp/lvl1
[46919.620721] swapon: swapfile has holes
swapon: /var/swp/lvl1: Invalid argument

Is this idea dead at this point?
No, not if we insist.

Turn that file into a block device and format the device as swap:

Code:

[root@kindle /var]# losetup /dev/loop/8 /var/swp/lvl1

[root@kindle /var]# mkswap /dev/loop/8
Setting up swapspace version 1, size = 2093 kB
no label, UUID=c7e292e5-0188-4c08-b7de-ab984f3ec9b7

The swapon/swapoff utility provided does not accept a priority option.
But taking advantage of the fact that the system, if not told otherwise, assigns priorities in the order of assignment.
We will set our fast ram swap area to be used before our slow eMMC swap area created previously in this theard.

Code:

[root@kindle /var]# swapon /dev/loop/8
[root@kindle /var]# swapon /var/local/swap

[root@kindle /var]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/loop/8                             partition       2044    0       -1
/var/local/swap                         file            16016   0       -2
[root@kindle /var]#

Now we will just 'use' the PW-3 and see if it turns into a brick.

At first, it looked like things where working out well:

Code:

[root@kindle root]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/loop/8                             partition       2044    2044    -1
/var/local/swap                         file            16016   380     -2

But opening the third book caused the system to become non-responsive.
I.E: nothing happened when touching the touchscreen.
Serial port is still alive and well, so it looks like it is time for a:
shutdown -r now
command and a complete re-think of this two level deal.

Hmm... now this can't be good:

Code:

[root@kindle root]# shutdown -r now

[root@kindle root]# Broadcast message from root@kindle
        (/dev/ttymxc0) at 10:43 ...

The system is going down for reboot NOW!
info shutdown:begin:level=6,halt=,special=:
info shutdown:closing password dialog::

[root@kindle root]# [49680.325874] INFO: task dbus-daemon:2169 blocked for more than 120 seco.
- - - -

Well, now try turning off the swap usage and see if we can recover this device:

Code:

[root@kindle root]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/loop/8                             partition       2044    2044    -1
/var/local/swap                         file            16016   380     -2
[root@kindle root]# swapoff /var/local/swap
[root@kindle root]# swapon -s
Filename                                Type            Size    Used    Priority
/dev/loop/8                             partition       2044    2044    -1
[root@kindle root]# swapoff /dev/loop/8

At which point now even the serial port is non-responsive.

Two more things to try:
Long press on the power button.
If that doesn't work, open the case and remove battery.
- - - - -
The power button re-boot worked.
And all of the stuff above in tmpfs went away (as intended).

Yup, this is going to take a long, long bit of thought.

irreld · 02-20-2016, 10:49 AM

Any hope for a 4GB PW2? I use cjk font tweaks and that seems to drain my ram.

knc1 · 02-20-2016, 12:11 PM

Quote:

Originally Posted by irreld

Any hope for a 4GB PW2? I use cjk font tweaks and that seems to drain my ram.

Amazon builds (well, built) a 4GB PW-2:
https://wiki.mobileread.com/wiki/Kindle_Serial_Numbers

irreld · 02-20-2016, 01:19 PM

Quote:

Originally Posted by knc1

Amazon builds (well, built) a 4GB PW-2:
https://wiki.mobileread.com/wiki/Kindle_Serial_Numbers

I thought you misunderstood me. I have a B05A 4gb PW-2. Is there any hope to re-partition it so I could have a swap for thouse heavy cjk fonts?

02-15-2016, 01:08 PM	#1
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Using swap on a PW-3 On a PW-3 (G090 G1 - fw-5.6.1.1), 512Mbyte Ram, 4Gbyte eMMC :: Using the system feature that /var/local is always mounted; either in 'main' or 'diags'. Setup to use 1/4 of /var/local for a system swap file. Over ssh (or telnet or serial port or from kTerm) - Code: [root@kindle root]# cd /var/local [root@kindle local]# df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/mmcblk0p3 63461 16692 43493 28% /var/local Note that the PW-3 has a /var/local partition twice the size of what it was on the KT. The Busybox/Ash command line can do simple math, find number of erase blocks: Code: [root@kindle local]# echo $((1024102416/4096)) 4096 Linux swap files must be initialized to zeros (no sparse files allowed): Code: [root@kindle local]# dd if=/dev/zero of=swap bs=4096 count=4096 4096+0 records in 4096+0 records out 16777216 bytes (16.0MB) copied, 0.627486 seconds, 25.5MB/s Interesting, the 'bulk write' on the PW-3 eMMC is 1/2 the rate as on the KT eMMC. ( ? ) The swap file requires a special format: Code: [root@kindle local]# mkswap ./swap Setting up swapspace version 1, size = 16773 kB no label, UUID=abd86682-51a1-42f6-aede-228fea736287 The above completes the (one-time) setup of a PW-3 swapfile. Its use by the system is controlled by the swapon and swapoff commands. Code: [root@kindle local]# swapon ./swap [root@kindle local]# free total used free shared buffers cached Mem: 515344 503292 12052 0 291540 54556 -/+ buffers/cache: 157196 358148 Swap: 16016 0 16016 Now open Kindle Paperwhite User's Guide Code: [root@kindle local]# free total used free shared buffers cached Mem: 515344 500168 15176 0 275520 60604 -/+ buffers/cache: 164044 351300 Swap: 16016 2412 13604 Browse the user's guide. Then close Kindle Paperwhite User's Guide Code: [root@kindle local]# swapon -s Filename Type Size Used Priority /var/local/swap file 16016 1556 -1 [root@kindle local]# df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/mmcblk0p3 63461 33148 27037 55% /var/local For users with a lot of books, perhaps using only 8Mbyte (half the above size) for the swap file would be a better choice. Even using only 2Mbyte of file space for the swap file reduces the kernel's page management workload. To the end-user, the appearent change is a more responsive Kindle. Since the above steps do not make an addition to /etc/fstab, the use of the swap file will 'go away' with the next re-boot. That is: the 'swapon /var/local/swap' command needs to re-issued after each reboot (the normal system shutdown will take care of the 'swapoff' process). When (IF) I get the spare time, I'll create a KUAL extension button (set) to let the non-technical user deal with all of the above. Note 1: If your 'main' system chokes by running out of space on /var/local - just re-boot into 'diags' and remove the /var/local/swap file. An easy way to do that, is to have RP (Rescue Pack) installed. The RP re-enables the recognition of the flag file: ENABLE_DIAGS, previously last seen on the KT. Note 2: Other directions you find may say to put the swap file in user storage. Not a good idea, because the Kernel can't access user storage when it is exported as mass storage over USB. And the Kernel really, really does not like to have the backing store of its swap file suddenly disappear.

02-16-2016, 11:57 AM	#10
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	For our two level swap space, we want a relatively small area of RAM as the first choice swap area followed by a larger, and much slower, area in /var/local (/dev/mmcblk0p3). This will be an enhancement over the ASUS idea of swap in RAM. Since the Kernel used with the PW-3 does not have the brd module (ramdisk) available we will have to sneak up on this layout in a round-about way. So round-about you would expect the memory page being written might get lost. Update: It does, the system deadlocks. I left the step-by-step here for a reference to one way not to do this. The tmpfs filesystem is implemented in the VFS i/o cache buffers and store backed by swap. The i/o cache buffers are dynamic in number and occupy all un-used RAM at any moment. Learn about the temporary sub-tree of the system file tree, located in tmpfs and not subject to the mntroot ro/rw thingy: Code: [root@kindle root]# df /var Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 32768 444 32324 1% /var [root@kindle root]# cd /var [root@kindle /var]# ls backups cache lib local lock log run tmp We need a directory there to serve as the mount point for a ext2 file system, store backed by tmpfs. Code: [root@kindle /var]# mkdir swp [root@kindle /var]# mount -t tmpfs -o size=4M ext2 /var/swp [root@kindle /var]# ls /var/swp - - empty - - Within that 4 Mbyte file system, make a 2 Mbyte file and lookup some of the things we can learn about it. Code: [root@kindle /var]# dd if=/dev/zero of=/var/swp/lvl1 bs=1024 count=2048 2048+0 records in 2048+0 records out 2097152 bytes (2.0MB) copied, 0.013983 seconds, 143.0MB/s [root@kindle /var]# ls -l swp -rw-rw-r-- 1 root root 2097152 Feb 16 09:56 lvl1 [root@kindle /var]# df swp Filesystem 1K-blocks Used Available Use% Mounted on ext2 4096 2056 2040 50% /var/swp [root@kindle /var]# stat swp/lvl1 File: swp/lvl1 Size: 2097152 Blocks: 4112 IO Block: 4096 regular file Device: 10h/16d Inode: 36085 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2016-02-16 09:56:30.000000000 Modify: 2016-02-16 09:56:30.000000000 Change: 2016-02-16 09:56:30.000000000 This step is just to show an example that we can't use that file directly for a swap file. Code: [root@kindle /var]# mkswap /var/swp/lvl1 Setting up swapspace version 1, size = 2093 kB no label, UUID=813fd1a8-8936-477d-ad00-554654df4263 [root@kindle /var]# swapon /var/swp/lvl1 [46919.620721] swapon: swapfile has holes swapon: /var/swp/lvl1: Invalid argument Is this idea dead at this point? No, not if we insist. Turn that file into a block device and format the device as swap: Code: [root@kindle /var]# losetup /dev/loop/8 /var/swp/lvl1 [root@kindle /var]# mkswap /dev/loop/8 Setting up swapspace version 1, size = 2093 kB no label, UUID=c7e292e5-0188-4c08-b7de-ab984f3ec9b7 The swapon/swapoff utility provided does not accept a priority option. But taking advantage of the fact that the system, if not told otherwise, assigns priorities in the order of assignment. We will set our fast ram swap area to be used before our slow eMMC swap area created previously in this theard. Code: [root@kindle /var]# swapon /dev/loop/8 [root@kindle /var]# swapon /var/local/swap [root@kindle /var]# swapon -s Filename Type Size Used Priority /dev/loop/8 partition 2044 0 -1 /var/local/swap file 16016 0 -2 [root@kindle /var]# Now we will just 'use' the PW-3 and see if it turns into a brick. At first, it looked like things where working out well: Code: [root@kindle root]# swapon -s Filename Type Size Used Priority /dev/loop/8 partition 2044 2044 -1 /var/local/swap file 16016 380 -2 But opening the third book caused the system to become non-responsive. I.E: nothing happened when touching the touchscreen. Serial port is still alive and well, so it looks like it is time for a: shutdown -r now command and a complete re-think of this two level deal. Hmm... now this can't be good: Code: [root@kindle root]# shutdown -r now [root@kindle root]# Broadcast message from root@kindle (/dev/ttymxc0) at 10:43 ... The system is going down for reboot NOW! info shutdown:begin:level=6,halt=,special=: info shutdown:closing password dialog:: [root@kindle root]# [49680.325874] INFO: task dbus-daemon:2169 blocked for more than 120 seco. - - - - Well, now try turning off the swap usage and see if we can recover this device: Code: [root@kindle root]# swapon -s Filename Type Size Used Priority /dev/loop/8 partition 2044 2044 -1 /var/local/swap file 16016 380 -2 [root@kindle root]# swapoff /var/local/swap [root@kindle root]# swapon -s Filename Type Size Used Priority /dev/loop/8 partition 2044 2044 -1 [root@kindle root]# swapoff /dev/loop/8 At which point now even the serial port is non-responsive. Two more things to try: Long press on the power button. If that doesn't work, open the case and remove battery. - - - - - The power button re-boot worked. And all of the stuff above in tmpfs went away (as intended). Yup, this is going to take a long, long bit of thought. Last edited by knc1; 02-16-2016 at 12:02 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Using swap on a KT	knc1	Kindle Developer's Corner	8	02-16-2016 03:09 AM
Is there a way to swap K3 buttons?	Stingo	Amazon Kindle	3	09-18-2011 09:09 PM
Swap howdies?	durkinrobinson	Introduce Yourself	12	09-06-2010 11:14 PM
DR800 swap out 3G	nprnncbl	iRex	3	06-07-2010 05:45 PM
iLiad SWAP on iLiad	tirsales	iRex Developer's Corner	16	09-01-2008 05:20 PM

02-15-2016, 05:07 PM	#2
nixkalo Member Posts: 21 Karma: 10052 Join Date: Aug 2009 Device: hanlin V3, K4NT, PW3	Is there any risk that constant read/write from eMMC will wear it off and reduce kindle lifetime?

02-15-2016, 05:17 PM	#4
NiLuJe BLAM! Posts: 13,497 Karma: 26047188 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Shrinking /var/local is potentially a terrible (read: softbrick) idea.

02-20-2016, 10:49 AM	#11
irreld Enthusiast Posts: 35 Karma: 10 Join Date: Jan 2016 Device: PW2 PW3 DPT-RP1	Any hope for a 4GB PW2? I use cjk font tweaks and that seems to drain my ram.

Advert

Advert