First of all, this is not another lame post about why vodafone's magic has less ram than htc one. This is just... another thing about partly the same issues.
Second, this is also not about rosie. If you're going to say if this will make rosie work better, don't post. I really don't give a **** about rosie. I'm just trying to get more of this hardware.
Now for the topic. As you will already know, there are two variants of the Sapphire. One, supposedly has 192 Mb of RAM (Vodafone) and the other one has 288 (HTC). So far OK.
BUT, Vodafone Magic kernel reports 98Mb of available RAM. Wait, what? Even if the radio firmware eats part of the memory (about 20mb on msm7200 SoC), the kernel should report more than half of the memory the ram ic supposedly has. Furthermore, looking at the kernel source I found this on the memory fixup code (wich I assume is where it reserves the baseband ram area, like on other phones):
Code:
mi->nr_banks = 1;
mi->bank[0].start = PHYS_OFFSET;
mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
if (smi_sz == 32) {
mi->bank[0].size = (84*1024*1024);
} else if (smi_sz == 64) {
mi->bank[0].size = (101*1024*1024);
} else {
printk(KERN_ERR "can not get smi size\n");
/*Give a default value when not get smi size*/
smi_sz = 64;
mi->bank[0].size = (101*1024*1024);
printk(KERN_ERR "use default : smisize=%d\n", smi_sz);
}
As I stated before, qualcomm phones seem to use part of the ram for the baseband firmware, and, at least on Kaiser and Nikes (wich are the ones I know better, at least on the code side), have splitted the ram banks so the kernel doesn't try to write to the baseband memory corrupting it all, for example, kaiser:
Code:
mi->nr_banks=2;
mi->bank[0].start = 0x10000000;
mi->bank[0].node = 0;
mi->bank[0].size = 0x03800000;
mi->bank[1].start = 0x14000000;
mi->bank[1].node = 0;
mi->bank[1].size = 0x02d00000;
But on the Magic, there's no splitting. If it detects smi_size=32 (htc, though it's not really working) it throws 101 mb of RAM. if it detects smi_size=64( vodafone), it throws 88 mb
I might be completely wrong, and maybe there's another routine that I haven't seen or something like that, but it feels to me like they ran out of time while coding it and they left the fixup so it did boot, but didn't bother debugging to get the maximum ram amount, so they coded the minimal and left the rest for the modem "just in case". I'm going to do a few tests, but if someone knows something I don't please feel free to enlighten me
I was partially right
First test, first success
Before tricking:
/proc # cat meminfo
MemTotal: 97876 kB
MemFree: 3324 kB
Buffers: 384 kB
Cached: 22788 kB
SwapCached: 0 kB
Active: 37820 kB
Inactive: 40320 kB
Active(anon): 26548 kB
Inactive(anon): 29000 kB
Active(file): 11272 kB
Inactive(file): 11320 kB
Unevictable: 256 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 55248 kB
Mapped: 13360 kB
Slab: 6592 kB
SReclaimable: 1136 kB
SUnreclaim: 5456 kB
PageTables: 5108 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 48936 kB
Committed_AS: 1487028 kB
VmallocTotal: 155648 kB
VmallocUsed: 70820 kB
VmallocChunk: 33788 kB
After first attempt:
MemTotal: 102004 kB
MemFree: 4420 kB
Buffers: 2384 kB
Cached: 51580 kB
SwapCached: 0 kB
Active: 53508 kB
Inactive: 33744 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 33312 kB
EDIT: Okay, definitely, we can get more free ram than what it's actually available. After a few test, I'm getting 106mb of total RAM. This is only tricking the first memory bank, without telling the kernel there's a hole (wich by the way there is as I have already trashed it twice ) in the middle of the memory space. More proof:
Fourth attempt:
# cat proc/meminfo
MemTotal: 106068 kB
MemFree: 25916 kB
Buffers: 20 kB
Cached: 45920 kB
SwapCached: 0 kB
Active: 41660 kB
Inactive: 30048 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 25812 kB
Mapped: 21176 kB
Slab: 3596 kB
SReclaimable: 964 kB
SUnreclaim: 2632 kB
PageTables: 2528 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 53032 kB
Committed_AS: 693744 kB
VmallocTotal: 147456 kB
VmallocUsed: 61148 kB
VmallocChunk: 65532 kB
Regards!
Impressive!
32B owners : prepare yourself for a whole new experience
Could this be related to the fact that 32A kernels are not working on a 32B radio?
I think so, yes. As memory sizes are different, memory addresses change, that could be one of the reasons why 32a and 32b kernels aren't compatible between devices. Though I don't know if there'll be something else I don't know (wich probably there is).
So far, I found that on the beginning of the memory space, I can get up to 108 Mb of RAM without corruption (or reboots, or strange things) on my 32B magic. I have splitted the memory in two banks on the code, and trying to get some more free space at the end of the memory, but with no luck yet (working on this for an hour or two, I don't expect to be THAT fast )
But, it's a quite nice start. Even if we can't get the full 192 mb (wich we can't because of the radio), maybe we can get up to 150 or 160Mb, wich would be quite better than what we have. What I have to find is where the radio memory ends so I don't screw it, and then get to the last writable address. Trial and error
Amon_RA said:
32B owners : prepare yourself for a whole new experience
Could this be related to the fact that 32A kernels are not working on a 32B radio?
Click to expand...
Click to collapse
Do you mean that this may help track down why when 32a owners flash the 32b radio we lose all of our RAM?
Good luck man! I wish I can help with this technical stuff
biktor_gj said:
Trial and error
Click to expand...
Click to collapse
Hmm, perhaps not quite. Your approach seems a bit "unscientific". You might get the impression that you're not overwriting anything, but what if some seldom used part of the memory is overwritten. You might not notice until the baseband gets in a special situation.
(Sorry, "unscientific" sounds rude, but it's not meant that way. I think you're making great progress!)
Is it possible to map part of the memory as read-only?
If that is the case, couldn't we build a test kernel that maps 64mb of the first memory as accessible, and the rest as readonly. Then do a custom recovery initrd that just dumps all memory to the PC and analyse the layout there?
@wire103: The way I see it, and the way it behaves so far, If I take a single byte reserved for the baseband, the kernel doesn't finish booting. It's easy to understand why, the kernel writes to a reserved address, then the baseband or a) gets corrupt and reboots or b) writes to the reserved address corrupting the data the kernel has written, so the kernel gets corrupt and reboots. In the end, if the phone ends up booting it means it all worked quite well. At the end of the reserved memory space, on other msm's at least, resides the audio tables (audioparam*.csv) the baseband uses to change between profiles (headset, earcouple and speaker). If I overwrite that, boom! the phone reboots, and start over again, or, in the best case scenario, it will break audio and reboot just the baseband losing phone connectivity, wich is obvious to see and to debug
On the kernel side, I can't mark anything as read only, I'm telling it that there IS more RAM so it can handle it, and that it's work in the end. And as I cannot get access to /dev/mem (since it's not there) I haven't found an easy fix to dump the entire memory.
@bcrook: I think it's not the radio what makes you loose ram, but the kernel itself. But without the HTC patches I cannot be sure until I see it. Although I can try to prepare some custom kernel with a little declared Ram to see if it helps booting a 32b kernel with a 32A radio.
In any case, 32A's original radio is version 3.22.20.17 and 32B radio is 2.22.19.26I so there might be some other things we don't know about.
And, so you all know what I know so far, 32A's kernel reports not 288 Mb of RAM as HTC Specification's page shows, but 198 Mb:
<6>[ 0.020000] Memory: 198MB = 198MB total
<5>[ 0.020000] Memory: 196608KB available (2824K code, 941K data, 104K init)
(taken from a dmesg some collaborative user posted on another thread)
So it seems in both cases, there's only one mapped bank, and it's eating about 80 mb of ram in both cases. Maybe these msm basebands need more ram to operate than previous models (I'm talking here about msm7201 vs msm7200). That's something I still don't know and I still have to test, but what I do know is that radios designed for both msm7200 and 7201 take more or less the same amount of space on flash (about 20mb), and on 7200 the needed ram for the baseband is 30mb, wich is way less than 80 mb wich is what this thing is eating.
EDIT: hmmm... I think I found the hole... shared memory (for gpu, camera...)
After looking at the code for the Diamond, Raphael and Blackstone, and after checking again the header files for the sapphire, I've seen that, apart from the baseband memory, wich will probably be 30 Mb more or less, other things are eating the ram. The most usable memory without corruption I can get is 109 Mb (11 mb more than stock kernels) without noticeable changes or problems (not that I've done a lot of debugging, but using the phone functions and opengl didn't give any problems of any kind)
So, we can take a little more RAM but not nearly as much as I thought.
For the code, in case anyone is interested, here you have:
Code:
if (smi_sz == 32) {
mi->bank[0].size = (84*1024*1024);
} else if (smi_sz == 64) {
mi->bank[0].size = (108*1024*1024);
} else {
printk(KERN_ERR "can not get smi size\n");
Or, if you want to tune it to the most you can get:
Code:
if (smi_sz == 32) {
mi->bank[0].size = (84*1024*1024);
} else if (smi_sz == 64) {
mi->bank[0].size = 0x06d00000;
} else {
printk(KERN_ERR "can not get smi size\n");
Almost anything above 0x06d00000 will make the phone reboot endlessly, and this will give you 109Mb of RAM. You can tune it further by altering the reserved memory addresses for the SMI, but I don't think that's a good idea (if they have those values it's for a reason, and you might end up seeing green lines on the screen, lockups, or other kind of errors by reducing the space for the framebuffer, adsp etc)
biktor_gj said:
@bcrook: I think it's not the radio what makes you loose ram, but the kernel itself. But without the HTC patches I cannot be sure until I see it. Although I can try to prepare some custom kernel with a little declared Ram to see if it helps booting a 32b kernel with a 32A radio.
In any case, 32A's original radio is version 3.22.20.17 and 32B radio is 2.22.19.26I so there might be some other things we don't know about.
Click to expand...
Click to collapse
I would be willing to test this on my 32A if you want to put something together. It would be superb if we could get 32B ROM's working on the 32A using the full available RAM, or even more available RAM than a default 32A ROM.
PM me if you want to use me as a mule.
This looks very interesting the outcome could be of huge benefit to all.
Just wish I could add some tech knowledge but I cant.
Will continue to read with interest well done great work so far
EDIT: nm, it is in the kernel source.
I can try something for 32A users, if you don't mind risking your phone.,.
Let's see if I get it right.
Given a 32A board, can you pick a 32b boot.img, radio and rom, flash it, and boot all the way to the home screen, and the only thing you'd loose is the upper memory? (making the phone think it has 100mb of ram)?
If that's the case, and 32b kernels CAN boot on 32A boards given the right Radio version, it's a matter of patching the memory bank sizes so the kernel knows it has more ram than what it's declared...
biktor_gj said:
I can try something for 32A users, if you don't mind risking your phone.,.
Let's see if I get it right.
Given a 32A board, can you pick a 32b boot.img, radio and rom, flash it, and boot all the way to the home screen, and the only thing you'd loose is the upper memory? (making the phone think it has 100mb of ram)?
If that's the case, and 32b kernels CAN boot on 32A boards given the right Radio version, it's a matter of patching the memory bank sizes so the kernel knows it has more ram than what it's declared...
Click to expand...
Click to collapse
That's exactly right. Using a 32B radio I can boot any 32B ROM but am down 100mb. If you can compile a 32B kernel for me that uses more RAM I will try it out.
For reference, here is what my meminfo looks like currently:
MemTotal: 197144 kB
MemFree: 15380 kB
Buffers: 264 kB
Cached: 36244 kB
SwapCached: 0 kB
Active: 104564 kB
Inactive: 18568 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 86648 kB
Mapped: 17496 kB
Slab: 48268 kB
SReclaimable: 41132 kB
SUnreclaim: 7136 kB
PageTables: 6244 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 98572 kB
Committed_AS: 1669088 kB
VmallocTotal: 319488 kB
VmallocUsed: 65884 kB
VmallocChunk: 201724 kB
Aweome if it works...
1 Lab Rat signing up for 32A!
There's a value that seems to change between boards. That's the SMI size. On 32B boards its value is 64, and on 32A boards is 32. Can you flash it all with 32b rom and radio, and post some info elsewhere?
What I need is the kernel messages log. You can get it by getting a root shell (adb shell), and running the command:
dmesg > /sdcard/dmesg.txt
Then uploading that file somewhere to pick up (the easiest, pastebin.com)
I need to see if even if it's running a 32b kernel, it detects the correct smi size, or if it picks the generic one. If it detects the correct size, we may have a chance of autodetecting the board revision on boot.
biktor_gj said:
There's a value that seems to change between boards. That's the SMI size. On 32B boards its value is 64, and on 32A boards is 32. Can you flash it all with 32b rom and radio, and post some info elsewhere?
What I need is the kernel messages log. You can get it by getting a root shell (adb shell), and running the command:
dmesg > /sdcard/dmesg.txt
Then uploading that file somewhere to pick up (the easiest, pastebin.com)
I need to see if even if it's running a 32b kernel, it detects the correct smi size, or if it picks the generic one. If it detects the correct size, we may have a chance of autodetecting the board revision on boot.
Click to expand...
Click to collapse
Doing it now, standby
biktor_gj said:
There's a value that seems to change between boards. That's the SMI size. On 32B boards its value is 64, and on 32A boards is 32. Can you flash it all with 32b rom and radio, and post some info elsewhere?
What I need is the kernel messages log. You can get it by getting a root shell (adb shell), and running the command:
dmesg > /sdcard/dmesg.txt
Then uploading that file somewhere to pick up (the easiest, pastebin.com)
I need to see if even if it's running a 32b kernel, it detects the correct smi size, or if it picks the generic one. If it detects the correct size, we may have a chance of autodetecting the board revision on boot.
Click to expand...
Click to collapse
so you want some one with a 32A to flash a 32B rom and then get the dmesg? or the origanal 32A?
Killadude said:
so you want some one with a 32A to flash a 32B rom and then get the dmesg? or the origanal 32A?
Click to expand...
Click to collapse
I need the 32B kernel dmesg when running on a 32A board
Sorry for my english...
Ok, attached is dmesg-32A and dmesg-32B.
dmesg-32A is using a 32A ROM (from Amon_RA) and dmesg-32B is using cyanogens 3.9.7 (32B) ROM, both running on my Rogers 32A.
http://www.mediafire.com/?sharekey=87a195e0707967d00f83d91f6dff7c385048c6f0b06623c55621d66e282a0ee8
Resultant meminfo:
MemTotal: 80724 kB
MemFree: 1356 kB
Buffers: 316 kB
Cached: 24352 kB
SwapCached: 0 kB
Active: 30156 kB
Inactive: 38332 kB
Active(anon): 21284 kB
Inactive(anon): 23068 kB
Active(file): 8872 kB
Inactive(file): 15264 kB
Unevictable: 248 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 44080 kB
Mapped: 14460 kB
Slab: 5244 kB
SReclaimable: 812 kB
SUnreclaim: 4432 kB
PageTables: 2808 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 40360 kB
Committed_AS: 727200 kB
VmallocTotal: 172032 kB
VmallocUsed: 44404 kB
VmallocChunk: 82940 kB
hmmm... cool! it detects the SMI Size!
If this works, you will have about 150 or 160 mb of ram and no wifi (but the wifi thing is because of the wlan.ko)
Let's see what it does!
http://rapidshare.com/files/267026365/bootnew.img
do a fastboot boot bootnew.img, don't even bother flashing for now
If it doesn't work, it will either get stucked, or show the bootlogo, and after a while, it will reboot, then start booting the firmware stored on flash, but it won't break anything.
If it boots all the way, get a shell and do a
cat /proc/meminfo to see how much ram you get, or take a look at the dmesg
Related
Fatal1ty made me think about the fact that the two versions of HTC Magic sold in Italy come with a different RAM amount:
adb shell cat /proc/meminfo gives these results:
Vodafone: about 98436 KB
TIM: about 192000KB
HOW COULD IT BE???
If it'll be confirmed, would it be legal to sell the same device with different characteristics without informing consumers?
asci said:
Fatal1ty made me think about the fact that the two versions of HTC Magic sold in Italy come with a different RAM amount:
adb shell cat /proc/meminfo gives these results:
Vodafone: about 98436 KB
TIM: about 192000KB
HOW COULD IT BE???
If is it confirmed, would it be legal to sell the same device with different characteristics without informing consumers?
Click to expand...
Click to collapse
if u look at the htc site u will see the original htc magic is listet with 288 mb ram
and the htc brandet witz 192mb ram
so why should this be not legale
kingchris said:
if u look at the htc site u will see the original htc magic is listet with 288 mb ram
and the htc brandet witz 192mb ram
so why should this be not legale
Click to expand...
Click to collapse
Well because to the most of people (consumers) is not asked to be PPC expert and informations should be done clearly, without doubts. So when I go to buy my Magic to Vodafone shop rather than to HTC or TIM shop I should know exactly what I am buying and what are the technical differences...and I also dare to exepct a different price. People generally know that HTC Magic is ONE and it is sold with two different brand (TIM - Vodafone), or no brand, and not that they are different devices technically speaking. Don't you think that if I should know it in advance I would buy the one with more ram at the same price???
EDIT:
and YES, I have checked it and it reports a different RAM amount between HTC and Vodafone...BUT once again, don't you think that this specific has been a little hidden in commercial comunication???
I've been wondering how to find the ram of an Android phone. I just opened /proc/meminfo and found this on my Google Ion:
MemTotal: 98328 kB
MemFree: 3260 kB
Buffers: 8 kB
Cached: 21776 kB
SwapCached: 0 kB
Active: 38508 kB
Inactive: 43660 kB
Active(anon): 30124 kB
Inactive(anon): 31568 kB
Active(file): 8384 kB
Inactive(file): 12092 kB
Unevictable: 1008 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 61416 kB
Mapped: 15660 kB
Slab: 3804 kB
SReclaimable: 760 kB
SUnreclaim: 3044 kB
PageTables: 4092 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49164 kB
Committed_AS: 1114796 kB
VmallocTotal: 155648 kB
VmallocUsed: 65680 kB
VmallocChunk: 44028 kB
Click to expand...
Click to collapse
So it looks like my Ion has 192MB RAM (96MB for the OS, and the rest is shared with hardware). That's lame, especially for a second-generation, developer-targeted phone.
This is my Vodafone ITA with ION ROM.
MemTotal: 98356 kB
MemFree: 3288 kB
Buffers: 36 kB
Cached: 20996 kB
SwapCached: 0 kB
Active: 37936 kB
Inactive: 43640 kB
Active(anon): 26956 kB
Inactive(anon): 34864 kB
Active(file): 10980 kB
Inactive(file): 8776 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 61532 kB
Mapped: 16248 kB
Slab: 4180 kB
SReclaimable: 876 kB
SUnreclaim: 3304 kB
PageTables: 4044 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1137064 kB
VmallocTotal: 155648 kB
VmallocUsed: 66660 kB
VmallocChunk: 21500 kB
Click to expand...
Click to collapse
Fatal1ty points out that:
- If the the first value is around 100MB it means it has 192 MB (baseband included)
- If the the first value is around 190 MB it means it has 288 MB (baseband included)
MemTotal: 98356 kB
MemFree: 4164 kB
Buffers: 36 kB
Cached: 23480 kB
SwapCached: 0 kB
Active: 38528 kB
Inactive: 43712 kB
Active(anon): 27148 kB
Inactive(anon): 32828 kB
Active(file): 11380 kB
Inactive(file): 10884 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 59712 kB
Mapped: 13048 kB
Slab: 3684 kB
SReclaimable: 844 kB
SUnreclaim: 2840 kB
PageTables: 4020 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1059424 kB
VmallocTotal: 155648 kB
VmallocUsed: 65260 kB
VmallocChunk: 33788 kB
Italian Magic Vodafone with Noverca Rom
cat /proc/meminfo gives me the following results:
MemTotal: 98328 kB
MemFree: 3908 kB
Buffers: 112 kB
Cached: 19228 kB
SwapCached: 0 kB
Active: 36896 kB
Inactive: 44348 kB
Active(anon): 29336 kB
Inactive(anon): 33984 kB
Active(file): 7560 kB
Inactive(file): 10364 kB
Unevictable: 1008 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 62936 kB
Mapped: 11304 kB
Slab: 3900 kB
SReclaimable: 808 kB
SUnreclaim: 3092 kB
PageTables: 4028 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49164 kB
Committed_AS: 1034044 kB
VmallocTotal: 155648 kB
VmallocUsed: 64652 kB
VmallocChunk: 21500 kB
Click to expand...
Click to collapse
Australian Magic Vodafone with SuperHeroV2 port by Fatal1ty2787 & NK02
I feel so duped, especially considering I am now, somewhat 'stuck' with this phone for the next two years. The reduced memory size on the Vodafone HTC Magic must be what is causing such huge slow downs whilst running the SuperheroV2 ROM...
my-demise said:
cat /proc/meminfo gives me the following results:
Australian Magic Vodafone with SuperHeroV2 port by Fatal1ty2787 & NK02
I feel so duped, especially considering I am now, somewhat 'stuck' with this phone for the next two years. The reduced memory size on the Vodafone HTC Magic must be what is causing such huge slow downs whilst running the SuperheroV2 ROM...
Click to expand...
Click to collapse
Same here.
But i dont think it should cause slowdowns?
If we're sure it does, i might go back to vodafone and claim false advertising. :-/
Ooops. I think, we're buggered.
HTC webpage has 2 magics one for vodafone one not.
clearly states in the specs of the VF has 192MB and on the regular 288MB
I bought my device from Vodafone Germany with Sapphire Rogers Rom:
MemTotal: 98356 kB
MemFree: 1904 kB
Buffers: 1940 kB
Cached: 18832 kB
SwapCached: 0 kB
Active: 39144 kB
Inactive: 43948 kB
Active(anon): 31844 kB
Inactive(anon): 31940 kB
Active(file): 7300 kB
Inactive(file): 12008 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 63308 kB
Mapped: 13612 kB
Slab: 4340 kB
SReclaimable: 1052 kB
SUnreclaim: 3288 kB
PageTables: 4492 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1235236 kB
VmallocTotal: 155648 kB
VmallocUsed: 67316 kB
VmallocChunk: 19452 kB
Qualcomm® MSM7200A™ in HTC magic
Qualcomm® MSM7201a™ in the HTC magic from vodaphone
is there some difference?
looks like its manufacturing process. MSM7201A is 65nm chipset while the MSM7200A is manufactured on the 90nm process.
can anyone confirm?
So htc magic from vodaphone should drain less battery right? =)
You're correct in that it (Vodafone HTC Magic w/ Qualcomm® MSM7201a) will draw less power. In fact I was just about to post those finding now.
I guess in the future it'll be best to read the fine print haha!!
OT:
I suppose the lack of RAM isn't a HUGE deal as thankfully we can move all apps and dalvik-cache to the SDcard to free up what little RAM we already have. In fact I have seen great performance gains by moving all apps, cache and Rosie to my SD card.
192 and 288mb of RAM has nothing to do with the 512mb ROM.
moving apps and caches to your SD card isn't going to free RAM... it will free ROM space, which the Magic has plenty of (unlike the G1).
RAM is for apps that are currently running, and if you open too many it just saves their state and shuts them down until you switch back.
ROM is where everything is stored or "saved". So when you install an app its on your ROM, and when you launch the app it is STILL on your ROM, but is loaded into your RAM while running. I hope that helps the less savvy peeps.
That said, it is unfortunate that we have the 192mb models, as it will have to shut down apps and relaunch them more often... Down the road it might be limiting if we are porting ROMs from the Hero and the fancy interface needs more RAM than we have and things get sluggish. I will likely pickup a Hero as soon as one is available with US 3G bands.
Oh of course! Thanks for clearing that up. Everyone can disregard my previous post - well, except the part about the better power consumption of MSM7201a > MSM7200A
I don't know how to copy/ paste from the terminal emulator, but my HTC Magic with Rogers in Canada has:
Memtotal: 197144
Memfree: 5416
Active: 157248
I guess I should be happy... but at least you guys can root your phones!
Agggh. I created an account just to vent about this after reading this thread.
I cant believe I got so shafted by vodafone. I thought I was getting a phone with roughly the same performance specs as the hero, but instead I've got a dream without a keyboard!
This sucks.
Do you think its possible to upgrade the ram in the phone? Seriously.
diggyz said:
looks like its manufacturing process. MSM7201A is 65nm chipset while the MSM7200A is manufactured on the 90nm process.
can anyone confirm?
So htc magic from vodaphone should drain less battery right? =)
Click to expand...
Click to collapse
The MSM7200a is the 65nm version of the MSM7200 (90nm)
I couldn't find link from manufacturer to proof this, may be someone could.
So there is no difference in power consumption!
But i'm hear, that MSM7201A lacks ability to records vga with 30 fps due qualcomm patent problems.
Maybe it's part of the whole "with Google" initiative and not just Vodaphone. T-Mobile's going to have a "with Google" version, and it's only got 192 megs of ram. :-\ Well, guess this is a non-buyer for me.
http://www.engadget.com/photos/t-mobile-mytouch-3g-user-guide/2102338/
Here are the difference between the HTC and Vodaphone(T-Mobile?):
HTC Magic
Qualcomm® MSM7200A™, 528 MHz
ROM: 512 MB
RAM: 288 MB
Vodaphone
Qualcomm® MSM7201a™, 528 MHz
ROM: 512 MB
RAM: 192 MB
(According to the leaked manual, the MyTouch still has the Qualcomm® MSM7200A™, which tells me that there's actually 3 versions of the phone? If that's correct, then the specs for the T-Mobile version are as follows:
Qualcomm® MSM7200a™, 528 MHz
ROM: 512 MB
RAM: 192 MB
For reference, here's the HTC Dream (G1) and Hero Specs:
HTC Dream or T-Mobile G1
Qualcomm® MSM7201A™, 528 MHz
ROM: 256 MB
RAM: 192 MB
HTC Hero
Qualcomm® MSM7200A™, 528 MHz
ROM: 512 MB
RAM: 288 MB
Ps. Shouldn't this be in the regular section and out of the Dev area?
hmm, so I guess this is why the phone gets sluggish while using the media player, and actually closing down the download of the podcast app if switching to other apps.
I'm sure there is some way to make sdcard work as virtual ram? class 6?
bufodill said:
hmm, so I guess this is why the phone gets sluggish while using the media player, and actually closing down the download of the podcast app if switching to other apps.
I'm sure there is some way to make sdcard work as virtual ram? class 6?
Click to expand...
Click to collapse
If it's rooted, you could use swapper. It's an app that allows for a swapfile.
I suspect that compcache is not interacting properly with android but I need some stats to really analyze it. This should be standardized so please answer as I request and avoid any "me too" type answers.
Here's what you need:
Compcache running or a linux swap partition or file (swapper counts).
The default browser bound to a shortcut (search-b) and set to load www.cnn.com as your homepage. Close extra windows before starting and go there at least once. Make sure you're blocking popups.
A homescreen where you have icons and widgets that you have noticed in the past have taken time to load.
Music player to run in the background if you need to increase the system load.
Optionally: Gmail bound to a keyboard shortcut. (search-g for me)
Adb shell and knowledge to run these tests.
Here's what you're doing:
adb shell into your phone
Grab following stats (you can copy and paste in on one line):
Code:
uname -r;uptime;cat /proc/sys/vm/swappiness;cat /proc/swaps;cat /proc/ramzswap;free
Hit home button and go to homescreen. Take note of whether the homescreen needed to reload everything or if it was snappy. After completely done loading, run 'free' and record.
Keyboard shortcut to browser. Take note of whether the browser had to download and reload everything. After completely done loading, run 'free' and record.
Repeat 3-4 until either:
switching is always snappy,
the value of 'free' for swap ceases to change significantly while apps are reloading (like +-100 over 2-3 slow reloads),
or the value of 'free' for swap maxes out (note if you start getting lots of force closes).
Code:
total used free shared buffers
Mem: 97876 95492 2384 0 644
Swap: 43880 [B] 404[/B] 43476
Total: 141756 95896 45860
If its always snappy, put more load on the system by setting the music player in the background. If that still doesn't stress the system, throw in Gmail in the mix randomly. Note if snappy, and record 'free' stats.
If you're using both compcache and a linux swap, try to get information at the point where you've crossed over from compcache to linux swap. So if you're compcache is only 8 megs, seeing the difference as your swap fills over the 8 meg boundary is useful.
Finally, here's what you should report, either by putting it into a text file and attaching, or by placing it into a
Code:
block.
[list=1][*]Mod used. e.g. Cyanogen 3.9
[*]Info from step 2) above. [code]2.6.29-cm
12:47:45 up 3:43, load average: 2.13, 2.05, 2.09
15
Filename Type Size Used Priority
/dev/ramzswap0 partition 12284 408 -1
/system/sd/swapfile.swp file 31596 0 -2
DiskSize: 12288 kB
NumReads: 33
NumWrites: 102
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 3
GoodCompress: 77 %
NoCompress: 9 %
PagesStored: 99
PagesUsed: 31
OrigDataSize: 396 kB
ComprDataSize: 118 kB
MemUsedTotal: 124 kB
total used free shared buffers
Mem: 97876 95720 2156 0 632
Swap: 43880 408 43472
Total: 141756 96128 45628
[*]Results from repeating 3-4. If it ended up being too responsive and you couldn't stress it just include one cycle. Mark what you swapped to and whether it reloaded (Y for yes). e.g.
Code:
home
total used free shared buffers
Mem: 97876 95824 2052 0 292
Swap: 24464 2268 22196
Total: 122340 98092 24248
browser Y
total used free shared buffers
Mem: 97876 96032 1844 0 252
Swap: 24464 2540 21924
Total: 122340 98572 23768
home
total used free shared buffers
Mem: 97876 94436 3440 0 264
Swap: 24464 2940 21524
Total: 122340 97376 24964
browser Y
total used free shared buffers
Mem: 97876 95960 1916 0 280
Swap: 24464 5292 19172
Total: 122340 101252 21088
home Y
total used free shared buffers
Mem: 97876 92868 5008 0 272
Swap: 24464 6484 17980
Total: 122340 99352 22988
[/list]
Thanks!
Reserved for my test results.
Another good test is iMeem. This app is a memory whore and really puts pressure on the system.
Code:
Cyanogen 3.6.8.1
2.6.29-cm
15:19:09 up 5:28, load average: 7.58, 5.31, 4.33
20
Filename Type Size Used Priority
/dev/ramzswap0 partition 24464 15968 -1
DiskSize: 24468 kB
NumReads: 7817
NumWrites: 8908
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 241
GoodCompress: 65 %
NoCompress: 12 %
PagesStored: 5871
PagesUsed: 2370
OrigDataSize: 23484 kB
ComprDataSize: 9323 kB
MemUsedTotal: 9480 kB
total used free shared buffers
Mem: 97876 95852 2024 0 560
Swap: 24464 15968 8496
Total: 122340 111820 10520
home Y
total used free shared buffers
Mem: 97876 96348 1528 0 776
Swap: 24464 14600 9864
Total: 122340 110948 11392
browser Y
total used free shared buffers
Mem: 97876 96528 1348 0 420
Swap: 24464 14844 9620
Total: 122340 111372 10968
home Y
total used free shared buffers
Mem: 97876 96432 1444 0 752
Swap: 24464 14792 9672
Total: 122340 111224 11116
browser Y
total used free shared buffers
Mem: 97876 96484 1392 0 404
Swap: 24464 14844 9620
Total: 122340 111328 11012
home Y
total used free shared buffers
Mem: 97876 96464 1412 0 668
Swap: 24464 15048 9416
Total: 122340 111512 10828
No other posts? C'mon everyone, these statistics will help YOU get a faster, better configured phone.
**********
sha.goyjo said:
I'm going to be the first to say it. Doing tests on compcache .5 is somewhat pointless atm. If you follow Cyanogens, you'll see that he's currently working with the compcache people on an arm revision of .6, which uses a VERY different code base. I'd contribute to your thread if it wasn't trying to fiddle with a version that was just an arm patch on the existing compcache branch. You'd be better off waiting till the .6 goes stable on the trunk. All that being said, if you want to try and rewrite kernel modules that are in the process of being re-re-written, be my guest.
Not trying to be an ass, just trying to save us all some time by working towards things efficiently.
That being said, .6 could REALLY use some people working on it. Once it gets working we'll be able to use backing swap files instead of a partition, which would be great. No more Linux-swap on an sdcard.
Click to expand...
Click to collapse
Hmm. So what you are saying is that we should find no significance in the fact the cyanogen already posted in this thread with supportive info for the tests.
Also, in regards to your work on .6, what benchmarking plan did you have to prove:
1) that .6 performs better than .5 on our phones
2) that .6 performs better than a linux swap on our phones
3) that .6 performs better than .5 with a backing swap on our phones
Please note that any answers to this thread could help build these benchmarks for you.
Running CM 3.8
Browser only reloaded once...even with music playing, and running wisepilot! Even the one reload was a quick one.
Code:
2.6.29-cm
18:05:17 up 1:13, load average: 2.75, 3.69, 4.14
60
Filename Type Size Used Priorit
/dev/ramzswap0 partition 31996 21264 -1
DiskSize: 32000 kB
NumReads: 15024
NumWrites: 16558
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 246
ZeroPages: 196
GoodCompress: 75 %
NoCompress: 4 %
PagesStored: 7804
PagesUsed: 2977
OrigDataSize: 31216 kB
ComprDataSize: 11516 kB
MemUsedTotal: 11908 kB
total used free shared buffers
Mem: 97876 96376 1500 0 576
Swap: 31996 21264 10732
Total: 129872 117640 12232
#
From CNN to Home
**snappy
total used free shared buffers
Mem: 97876 95752 2124 0 588
Swap: 31996 22040 9956
Total: 129872 117792 12080
From Home to CNN
**snappy no reload
total used free shared buffers
Mem: 97876 96032 1844 0 520
Swap: 31996 22020 9976
Total: 129872 118052 11820
#
ADDED MUSIC PLAYER BACKGROUND And checked mem
total used free shared buffers
Mem: 97876 95964 1912 0 624
Swap: 31996 17516 14480
Total: 129872 113480 16392
FROM HOME TO CNN
**Reload
total used free shared buffers
Mem: 97876 96120 1756 0 448
Swap: 31996 24780 7216
Total: 129872 120900 8972
CNN to Home
**Snappy...no redraw
total used free shared buffers
Mem: 97876 96400 1476 0 492
Swap: 31996 29248 2748
Total: 129872 125648 4224
Home to Browser
***Snappy NO RELOAD WITH MUSIC RUNNING!!!
total used free shared buffers
Mem: 97876 96288 1588 0 464
Swap: 31996 26660 5336
Total: 129872 122948 6924
ADDED WISEPILOT NAVIGATION mUSIC STILL RUNNING
total used free shared buffers
Mem: 97876 96532 1344 0 396
Swap: 31996 27592 4404
Total: 129872 124124 5748
WISEPILOT RUNNING, MUSIC RUNNING, SWITCHED TO CNN from within wisepilot (search b)
***NO RELOAD, NO LAG....
total used free shared buffers
Mem: 97876 95988 1888 0 492
Swap: 31996 27208 4788
Total: 129872 123196 6676
#
double posted
by the way, in case everyone missed it:
I have two G1's. Both have brand new installs of CM 3.9. One has compcache (with swapiness set to 20 and 24mb of space allocated) and one does not. After a reboot on both devices and waiting a five minutes for everything to settle, I filmed the opening of the camera app. The one without compcache is noticeably quicker. Is compcache slowing our machines down, at least in certain instances?
By the way, cat /proc/ramzswap confirms compcache is enabled.
http://www.youtube.com/watch?v=gNYv-5WLDVA
edit:swappiness for the above tests was at 60....
Running Cyanogen 3.8.1 with the Palm Pre theme ( dunno if it made a diff.) and HTC Music app running.
Code:
2.6.29-cm
03:53:53 up 3 min, load average: 2.22, 1.47, 0.60
60
Filename Type Size Used Priority
/dev/ramzswap0 partition 31996 11612 -1
DiskSize: 32000 kB
NumReads: 1902
NumWrites: 3415
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 137
GoodCompress: 72 %
NoCompress: 4 %
PagesStored: 3278
PagesUsed: 1128
OrigDataSize: 13112 kB
ComprDataSize: 4461 kB
MemUsedTotal: 4512 kB
total used free shared buffers
Mem: 97876 96488 1388 0 652
Swap: 31996 11612 20384
Total: 129872 108100 21772
Home Y
total used free shared buffers
Mem: 97876 95704 2172 0 668
Swap: 31996 11612 20384
Total: 129872 107316 22556
Browser Y
total used free shared buffers
Mem: 97876 96308 1568 0 432
Swap: 31996 15528 16468
Total: 129872 111836 18036
Home N
total used free shared buffers
Mem: 97876 86336 11540 0 468
Swap: 31996 14936 17060
Total: 129872 101272 28600
Browser Y
total used free shared buffers
Mem: 97876 95196 2680 0 520
Swap: 31996 14932 17064
Total: 129872 110128 19744
Home N
total used free shared buffers
Mem: 97876 96176 1700 0 460
Swap: 31996 15056 16940
Total: 129872 111232 18640
Browser (Opened up really quick) N
total used free shared buffers
Mem: 97876 96432 1444 0 540
Swap: 31996 15200 16796
Total: 129872 111632 18240
Home N
total used free shared buffers
Mem: 97876 96096 1780 0 540
Swap: 31996 15208 16788
Total: 129872 111304 18568
pinetreehater said:
by the way, in case everyone missed it:
I have two G1's. Both have brand new installs of CM 3.9. One has compcache (with swapiness set to 20 and 24mb of space allocated) and one does not. After a reboot on both devices and waiting a five minutes for everything to settle, I filmed the opening of the camera app. The one without compcache is noticeably quicker. Is compcache slowing our machines down, at least in certain instances?
By the way, cat /proc/ramzswap confirms compcache is enabled.
http://www.youtube.com/watch?v=gNYv-5WLDVA
edit:swappiness for the above tests was at 60....
Click to expand...
Click to collapse
I'm not surprised it was.
Without compcache : Start camera app, realize your out of memory, kill another application (meaning it will start slower the next time, going through full initialization).
With compcache : Start camera, push inactive application into compcache.
I'd like to see some similar tests with more tests run. I think I might actually write a little app for this.
derfolo said:
Hmm. So what you are saying is that we should find no significance in the fact the cyanogen already posted in this thread with supportive info for the tests.
Also, in regards to your work on .6, what benchmarking plan did you have to prove:
1) that .6 performs better than .5 on our phones
2) that .6 performs better than a linux swap on our phones
3) that .6 performs better than .5 with a backing swap on our phones
Please note that any answers to this thread could help build these benchmarks for you.
Click to expand...
Click to collapse
No, I apologize for being offensive. Part of my reasoning has more to do with the fact that, as far as I have seen, regardless of what works best people tend to move to the latest version. It wasn't a utility prediction. In that respect, you are going in the right direction. I do think that the plans to implement dynamic swapping between backing and ramz in the future really make a big difference, however, in any kind of work we are trying to do here. Also, from what I've looked at the difference in the modules, they look significantly different now.
I didn't mean to press your buttons, but what I'm saying does have merit.
I say this because it's not about benchmarking the current version vs. the new version. That kind of a benchmark doesn't work, because the new version has an improved feature set. Software with a larger feature set rarely performs better than software with a smaller feature set. However, the features inherent in compcache .6 are VERY compelling for android phones, specifically the ability to use backing_swap from a FILE instead of a partition. The fewer partitions on your sdcard, the better. Less wasted space, and less time spend confusing the kernel as to which /dev/ it should be writing to at the time.
As to cyanogen having "supported" your tests, there are a lot of good reasons for it. You could discover a kernel interfacing problem. You could discover a problem in the arm patch that would be relevant to the new version or upgraded versions of CM.
All I think is that the compcache project could use all the help it can get rolling out .6 for android, and that if more people helped them with that, maybe we could try and find ways to fix the version of compcache we'll be using, instead of the one we'll be moving away from.
One thing people need to realize is that there is no free lunch. Swap (whether the partition or compcache) is not for speeding up the system but for allowing you to run many big apps together at the same time.
swap will slow you down a bit, whether its compcache (cpu overhead for compression) or partition (I/O overhead). So, stop fooling yourself. If you want a fast phone, just use basic things and leave swap out of picture. if you want a fast phone AND want to run tonnes of stuff like touchflo, get a phone with more RAM.
test results
devsk said:
One thing people need to realize is that there is no free lunch. Swap (whether the partition or compcache) is not for speeding up the system but for allowing you to run many big apps together at the same time.
swap will slow you down a bit, whether its compcache (cpu overhead for compression) or partition (I/O overhead). So, stop fooling yourself. If you want a fast phone, just use basic things and leave swap out of picture. if you want a fast phone AND want to run tonnes of stuff like touchflo, get a phone with more RAM.
Click to expand...
Click to collapse
Correct me if I'm wrong, but it sounds rather like you're saying, "Stop trying to make things better." Rather an odd sentiment for a Development forum, no?
I ran this test with just Calendar and Weather widgets running on the home screen and, although I have occasionally found the entire home screen slow to reload during regular use, during this test the home screen never seemed to reload at all, even with Music playing and an occasional jump to Gmail.
I'm running CM 3.9 with a simple Compcache script (no backing swap) initiated from Gscript for default disk size and 20 swappiness:
Code:
2.6.29-cm
12:23:08 up 36 min, load average: 3.37, 3.65, 2.79
20
Filename Type Size Used Priority
/dev/ramzswap0 partition 24464 6992 -1
DiskSize: 24468 kB
NumReads: 587
NumWrites: 1761
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 126
GoodCompress: 66 %
NoCompress: 5 %
PagesStored: 1635
PagesUsed: 602
OrigDataSize: 6540 kB
ComprDataSize: 2338 kB
MemUsedTotal: 2408 kB
total used free shared buffers
Mem: 97876 92880 4996 0 552
Swap: 24464 6992 17472
Total: 122340 99872 22468
Browser: N
total used free shared buffers
Mem: 97876 92856 5020 0 552
Swap: 24464 6992 17472
Total: 122340 99848 22492
Home: N
total used free shared buffers
Mem: 97876 92856 5020 0 552
Swap: 24464 6992 17472
Total: 122340 99848 22492
(after stressing with Music playing AND switching to Gmail)
Browser: Y
total used free shared buffers
Mem: 97876 95752 2124 0 452
Swap: 24464 7892 16572
Total: 122340 103644 18696
Home: N
total used free shared buffers
Mem: 97876 96496 1380 0 444
Swap: 24464 8276 16188
Total: 122340 104772 17568
ei8htohms said:
I ran this test with just Calendar and Weather widgets running on the home screen and, although I have occasionally found the entire home screen slow to reload during regular use, during this test the home screen never seemed to reload at all, even with Music playing and an occasional jump to Gmail.
Click to expand...
Click to collapse
And it probably doesn't, with compcache you have enough memory to keep it in, while without it needs to go through the whole onCreate and xml inflation.
I am not saying don't make it better. What I am saying is your expectations should be correct.
I use compcache myself. I use it with memlimit_kb=32000 disksize_kb=48000 backing_swap=/dev/block/mmcblk0p3 and a swappiness of 20. But I don't expect it to make my system fly. I just expect that more of my apps will stick around rather than killed and reloaded later. So, I am paying a little swapping cost upfront for payback later.
any lag once compcache fills up?
devsk said:
I am not saying don't make it better. What I am saying is your expectations should be correct.
I use compcache myself. I use it with memlimit_kb=32000 disksize_kb=48000 backing_swap=/dev/block/mmcblk0p3 and a swappiness of 20. But I don't expect it to make my system fly. I just expect that more of my apps will stick around rather than killed and reloaded later. So, I am paying a little swapping cost upfront for payback later.
Click to expand...
Click to collapse
Understood about managing expectations. I'm still considering the potential negative impact on battery life as well, since this is one notorious weak spot on the G1 (when it came out you didn't hear huge numbers of people complaining about how SLOW it was, but everyone complained about battery life...).
Do you mind explaining a little about your memlimit and disksize settings? I read a little about those options in the Google Code page, but I can't say I fully grokked the significance or difference.
I also can't seem to find a good explanation of how compcache and backing-swap work together. Most reports on XDA point to massive lag after compcache maxes out, but is it only then that backing-swap kicks in (and maybe a lot of those folks were using the 60 or 100 swappiness settings)? Can Linux-swap and compcache be run in parallel or separately from each other in some way (I'm guessing no)?
ei8htohms said:
Understood about managing expectations. I'm still considering the potential negative impact on battery life as well, since this is one notorious weak spot on the G1 (when it came out you didn't hear huge numbers of people complaining about how SLOW it was, but everyone complained about battery life...).
Do you mind explaining a little about your memlimit and disksize settings? I read a little about those options in the Google Code page, but I can't say I fully grokked the significance or difference.
I also can't seem to find a good explanation of how compcache and backing-swap work together. Most reports on XDA point to massive lag after compcache maxes out, but is it only then that backing-swap kicks in (and maybe a lot of those folks were using the 60 or 100 swappiness settings)? Can Linux-swap and compcache be run in parallel or separately from each other in some way (I'm guessing no)?
Click to expand...
Click to collapse
According to the Dev:
**********************************************************
Usage:
- modprobe ramzswap [memlimit_kb=<val>|disksize_kb=<val>] [backing_swap=<dev>]
memlimit_kb: This param is applicable only when backing_swap is given.
It is limit on amount compressed data stored in memory. Any
additional data is forwarded to backing_swap. It cannot be greater
than backing device size. If missing or 0, default value is used:
15% of RAM or backing device size, whichever is smaller.
disksize_kb: This param is applicable only when backing_swap is not given.
It is limit on amount of *uncompressed* worth of data stored in
memory. For e.g. disksize_kb=1024 means it can hold 1024kb worth of
uncompressed data even if this data compresses to just, say, 100kb.
If missing or 0, default value is used: 25% of RAM.
backing_swap: This is block device to be used as backing store for ramzswap.
It must be a valid swap partition. We move data to this device when we
encounter incompressible page or memlimit is reached. TODO: we may also
move some pages from ramzswap to this device in case system is really
low on memory.
This device is not directly visible to kernel as a swap device
(/proc/swaps will only show /dev/ramzswap0 and not this device).
Managing this backing device is the job of ramzswap module.
Examples:
1) modprobe ramzswap memlimit_kb=10240 backing_swap=/dev/sda2
sets ramzswap limit as 10MB and /dev/sda2 as backing swap device.
NOTE: here /dev/sda2 is a valid swap partition.
2) modprobe ramzswap backing_swap=/dev/sda2
same as (1) but memlimit is set to default: 15% of RAM or size of
backing swap device, whichever is smaller.
3) modprobe ramzswap disksize_kb=10240
sets ramzswap disk size as 10MB.
4) modprobe ramzswap.ko
same as (3) but ramzswap disk size will be set to default:
25% of RAM size.
Once module is loaded, activate this swap with highest priority:
swapon /dev/ramzswap0 -p 100
(-p param set swap priority)
Notes:
- ramzswap stats are exported via /proc/ramzswap
- If you give non-swap partition as backing_swap, nothing bad will happen -
swapon will simply fail to recognize /dev/ramzswap0 as swap partition.
So, in this case, unload the module and reload with correct backing_swap.
**********************************************************
thanks! very interesting
uwonsum said:
According to the Dev:
memlimit_kb: applicable only when backing_swap is given...limit on amount compressed data stored...additional data is forwarded to backing_swap.
disksize_kb: applicable only when backing_swap is not given...limit on amount of *uncompressed* worth of data stored.
Click to expand...
Click to collapse
So if I'm reading this right, memlimit and disksize would never be used together, right? And when backing_swap is NOT used, compcache is using the disksize allocation for uncompressed data, like virtual swap within RAM? Huh?
Once module is loaded, activate this swap with highest priority:
swapon /dev/ramzswap0 -p 100
(-p param set swap priority)
Click to expand...
Click to collapse
This swap priority info seems to directly conflict the info on the CompilingAndUsing page of the Google code project page:
Add ramzswap as swap device
swapon /dev/ramzswap0 -p 1 (give this swap device the highest priority).
Click to expand...
Click to collapse
Is 1 the highest priority or is 100 the highest priority? Is this the same as setting the swappiness? There must be a typo somewhere. Any help?
[EDIT]NVM, "-p 1" seems to be an invalid parameter.[/EDIT]
BTW, I started playing with your (rather more exotic) script from the CM Wheel of Death thread:
http://forum.xda-developers.com/showpost.php?p=4205132&postcount=518
Have you had any further findings about the various settings employed?
Thanks again!
i am looking for a guru here to give me a straight answer. how does backing swap really work with compcache. i have 32MB swap. does this mean i have a 32MB ramdisk, backed by a 32MB swap partition?
if that's true, what does the memlimit=8 param mean? it seems like i'd want to set it to 32 ... to allow compcache is use all of my swap partition as backing swap.
various config / output below, if that helps. thanks.
compcache{
compcache_en=1
cc_disksize=0
cc_memlimit=8
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
cc_swappiness=30 # default 60
}
total used free shared buffers
Mem: 97880 96404 1476 0 860
Swap: 31440 18504 12936
Total: 129320 114908 14412
BackingSwap: /dev/block/mmcblk0p3
DiskSize: 31451 kB
MemLimit: 8192 kB
NumReads: 6110
NumWrites: 14550
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 7622
PagesDiscard: 0
ZeroPages: 427
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 2439
PagesUsed: 638
OrigDataSize: 9756 kB
ComprDataSize: 2064 kB
MemUsedTotal: 2552 kB
BDevNumReads: 1517
BDevNumWrites: 4003
Hi,
I want to find out below information at any given point of time from android phone, can you please help me understand how I shall do it?
1. Total Available RAM (user space + kernel space)
2. How much RAM is being used by Kernel
3. How much RAM is used by user space (Framework + RIL + Apps etc)
4. How much free RAM is available
I tried with /proc/meminfo , I do get free and total ram but however I am not understanding what all I need to add to get the total mem displayed in /proc/meminfo.
Ex:
MemTotal: 405328 kB
MemFree: 51400 kB
Buffers: 1060 kB
Cached: 163008 kB
SwapCached: 4036 kB
.....
Committed_AS: 13577876 kB
VmallocTotal: 499712 kB
VmallocUsed: 72164 kB
VmallocChunk: 231812 kB
MemTotal = x + y + z etc ?? //From above what all I need to add to match total value to MemTotal?
Thanks
Chidambar
Show this
http://android-developers.blogspot.com.co/2014/01/process-stats-understanding-how-your.html?m=1
Apps not get defined ram memory to use, they are using the RAM as needed. If u have many apps in background, use of RAM will be higher
If someone could please look this over and help me put an end to this I would be eternally grateful. I am also offering a reward, in BTC or cash or whatever payment you prefer, to whoever can decipher it and give me a rundown of what has been done, and possibly a way to fix it. This is not a troll post and the text file is safe to open. I am literally begging for help, I am not attempting to ruin anybodies ****. Verizon, Suddenlink, and Spectrum have all verified the breach but nobody will give me and details as to exactly what they did to my devices. I will pay anyone that can give me a rundown as I am unabke to decipher wtf is going on. It is just a text file. Please, please help me.
dumpstate
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
Lol, that's one attachment I'm not opening.
Try in safe mode. If still misbehaving and you believe it's malware, takes more then an hour or two to fully delete, factory reset (delete Google account before doing so). Backup all critical although this should've already been done.
In running on Android 9 or higher this will purge it.
After factory reset change Google account password (copy it down) and all other sensitive account passwords.
Load no social media apps on the device; they are malware.
Load all 3rd party apps with caution and do not side load unless the app/source are known good.
Try to determine the origin of the infection, likely either an app you installed or a download. Do not repeat the mistake.
blackhawk said:
Lol, that's one attachment I'm not opening.
Try in safe mode. If still misbehaving and you believe it's malware, takes more then an hour or two to fully delete, factory reset (delete Google account before doing so). Backup all critical although this should've already been done.
In running on Android 9 or higher this will purge it.
After factory reset change Google account password (copy it down) and all other sensitive account passwords.
Load no social media apps on the device; they are malware.
Load all 3rd party apps with caution and do not side load unless the app/source are known good.
Try to determine the origin of the infection, likely either an app you installed or a download. Do not repeat the mistake.
Click to expand...
Click to collapse
It's much more complicated than that. I had a neighbor living downstairs that acessed my devices and used them for nefarious purposes. The man has known gang connections, and, due to the large amount of DHL packages being dropped on my door step, I believe he may have been using the access he had to my devices to order illegal items. I will try to create a .txt file with the main portion of the code I received so nobody has to unzip it. Just give me a few minutes. You will see some ****ed up ****. Please just take a look when I get it converted.
Also, no amount of reformats will cure the problem as the recovery partition has been deleted. They used some sort of Apache open source files that essentially "clones" the device, giving others access to them without my knowledge. There is currently a federal investigation going on in regards to this but, since nobody will give me any answers, I have to depend of the internet to read the code. I am no coding master, unfortunately. The verizon rep I spoke with did, however, tell me that the breach seemed "personal" and that the perpetrator had access to view, make calls, and send texts without my knowledge. You'll see once I get this text file up.
Reflash the device. Rethink your security and roommates in the future...
Here is the main dumpstate.txt. You won't have to unzip. If there are any other files from the dumpstate, please let me know and I will up them in a non zipped format
blackhawk said:
Lol, that's one attachment I'm not opening.
Try in safe mode. If still misbehaving and you believe it's malware, takes more then an hour or two to fully delete, factory reset (delete Google account before doing so). Backup all critical although this should've already been done.
In running on Android 9 or higher this will purge it.
After factory reset change Google account password (copy it down) and all other sensitive account passwords.
Load no social media apps on the device; they are malware.
Load all 3rd party apps with caution and do not side load unless the app/source are known good.
Try to determine the origin of the infection, likely either an app you installed or a download. Do not repeat the mistake.
Click to expand...
Click to collapse
https://www.mediafire.com/file/2x70i1awl23eb91/dumpstate.txt/file please take a look, it is just a .txt file. Nothing to extract
If you do not feel comfortable downloading the .txt, here is a link to the text. It takes forever to load as the file is around 70mb, but all the info is there https://ghostbin.com/ibMHH/xda
blackhawk said:
Reflash the device. Rethink your security and roommates in the future...
Click to expand...
Click to collapse
I have reflashed the device countless times. If you look at the code, the efs/recovery partition has been deleted. I have a friend that's a cop, and he told me they are able to "clone" (his words, not mine) anybodies device rendering them beyond repair. Here is Samsungs response after sending the device in for repairs.
Also, it was not a roommate, it was a man living beneath me that is a known gang member from the Doat/Bailey area in Buffalo. A quick Google search will show countless shootings in the area.
I'm literally begging for help. I promise to pay up to anyone that can help me. I've been dealing with this for almost a year and nobody will do anything to help.
blackhawk said:
Reflash the device. Rethink your security and roommates in the future...
Click to expand...
Click to collapse
It has nothing to do with security. we all know how easy it is to access somebody elses router using Kali.
Thanks everyone, just a quick look at the text file is all i need
Can someone please look at the text file, all of my stuff has been ruined for over a year and I can't code. I am in desperate need of help
jonny_fresh said:
https://www.mediafire.com/file/2x70i1awl23eb91/dumpstate.txt/file please take a look, it is just a .txt file. Nothing to extract
If you do not feel comfortable downloading the .txt, here is a link to the text. It takes forever to load as the file is around 70mb, but all the info is there https://ghostbin.com/ibMHH/xda
Click to expand...
Click to collapse
thats a big a** text file
jonny_fresh said:
I have reflashed the device countless times. If you look at the code, the efs/recovery partition has been deleted. I have a friend that's a cop, and he told me they are able to "clone" (his words, not mine) anybodies device rendering them beyond repair. Here is Samsungs response after sending the device in for repairs.
Also, it was not a roommate, it was a man living beneath me that is a known gang member from the Doat/Bailey area in Buffalo. A quick Google search will show countless shootings in the area.
I'm literally begging for help. I promise to pay up to anyone that can help me. I've been dealing with this for almost a year and nobody will do anything to help.
Click to expand...
Click to collapse
You are on Galaxy S9+ with Verizon carrier, yes?
jonny_fresh said:
It has nothing to do with security. we all know how easy it is to access somebody elses router using Kali.
Click to expand...
Click to collapse
Using Kali does not magically make you a hacker. Download the original firmware and flash it using Odin3. Your phone should work now.
1) toss that phone if you are unable to do a full factory image flash on it. This will reflash the recovery partition So if you still have no recovery after a year then a new phone is a better option for you.
2) cloning a phone is pretty low as far as usefulness to a scammer versus a single malware app installed in system or well hidden in plain sight (internet service(s),network settings name combined with a gear icon and its default click action just opens the settings menu is enough to go unnoticed by most people not looking for it)
3) Get a new phone and if thats still your neighbor move if you cant control your mail access etc.
edit: I went hard off topic so I removed the blah blah blah and simplified my post.
The text file is humungous. I wish I had the ability to read it.
This didn't just happen to one phone, it is all of my computers, multiple phones, laptops, android car radio etc.
I am currently using a Librem mini and it is the only thing that has not been altered.
I believe it has something to do with the processors. A few years back there was a widely reported backdoor in both AMD and Intel chips and, from what I can tell, the architecture of the CPU is being written.
Here is some of the top lines from the Galaxy s9+:
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 5713080 kB
MemFree: 716700 kB
MemAvailable: 2664684 kB
Buffers: 128612 kB
Cached: 1835988 kB
SwapCached: 78272 kB
Active: 2002424 kB
Inactive: 1461928 kB
Active(anon): 979180 kB
Inactive(anon): 541668 kB
Active(file): 1023244 kB
Inactive(file): 920260 kB
Unevictable: 3292 kB
Mlocked: 3292 kB
RbinTotal: 593920 kB
RbinAlloced: 0 kB
RbinPool: 0 kB
RbinFree: 355812 kB
SwapTotal: 2621436 kB
SwapFree: 2004904 kB
Dirty: 80 kB
Writeback: 0 kB
AnonPages: 1495048 kB
Mapped: 935336 kB
Shmem: 18468 kB
Slab: 310684 kB
SReclaimable: 102060 kB
SUnreclaim: 208624 kB
KernelStack: 56160 kB
PageTables: 97716 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 5477976 kB
Committed_AS: 122731980 kB
VmallocTotal: 263061440 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
CmaTotal: 237568 kB
CmaFree: 62632 kB
------ MEMORY INFO (/proc/meminfo_extra) ------
SystemHeap: 145712 kB
SystemHeapPool: 160436 kB
VmallocAPIsize: 20364 kB
KgslSharedmem: 195292 kB
ZSwapDevice: 125644 kB
------ MEMSIZE INFO (/proc/memsize/kernel) ------
Kernel : 47332 KB
.text : 22016 KB
.rodata : 11500 KB
.data : 2983 KB
.BSS : 7973 KB
.ETC : 2862 KB
paging : 100021 KB
log_buffer : 2048 KB
pid_hash : 32 KB
vfs_hash : 12288 KB
mm_init : 4152 KB
others : 4326 KB
Total : 170199 KB
------ MEMSIZE INFO (/proc/memsize/reserved) ------
v1
0x000000000-0x000000000 0x02a40000 ( 43264 KB ) xxxxx unusable unknown
0x000000000-0x000000000 0x02400000 ( 36864 KB ) xxxxx reusable mem_dump
0x000000000-0x000000000 0x01000000 ( 16384 KB ) xxxxx unusable qseecom_ta
0x000000000-0x000000000 0x02000000 ( 32768 KB ) xxxxx reusable linux,cma
0x000000000-0x000000000 0x08c00000 ( 143360 KB ) xxxxx reusable secure_displa
0x000000000-0x000000000 0x00800000 ( 8192 KB ) xxxxx reusable secure_sp
0x000000000-0x000000000 0x00200000 ( 2048 KB ) xxxxx unusable pil_mdata_buf
0x000000000-0x000000000 0x01000000 ( 16384 KB ) xxxxx reusable adsp
0x000000000-0x000000000 0x24400000 ( 593920 KB ) xxxxx reusable camera_mem
0x000000000-0x000000000 0x00000000 ( 0 KB ) xxxxx unusable initrd
0x000000000-0x000000000 0x00001000 ( 4 KB ) xxxxx unusable sec_debug_aut
0x000000000-0x000000000 0x00400000 ( 4096 KB ) xxxxx unusable sec_debug_low
0x000000000-0x000000000 0x00100000 ( 1024 KB ) xxxxx unusable ramoops
0x000000000-0x000000000 0x00200000 ( 2048 KB ) xxxxx unusable ss_plog
0x000000000-0x000000000 0x00100000 ( 1024 KB ) xxxxx unusable ipa_fw_ld
0x000000000-0x000000000 0x00f00000 ( 15360 KB ) xxxxx unusable rkp
0x000000000-0x000000000 0x00200000 ( 2048 KB ) xxxxx unusable tima
0x000000000-0x000000000 0x00000000 ( 0 KB ) xxxxx unusable cont_splash
0x000000000-0x000000000 0x02000000 ( 32768 KB ) xxxxx unusable qseecom
0x000000000-0x000000000 0x02000000 ( 32768 KB ) xxxxx unusable pil_adsp
0x000000000-0x000000000 0x00100000 ( 1024 KB ) xxxxx unusable pil_spss
0x000000000-0x000000000 0x01000000 ( 16384 KB ) xxxxx unusable pil_slpi
0x000000000-0x000000000 0x00200000 ( 2048 KB ) xxxxx unusable pil_mba
0x000000000-0x000000000 0x00800000 ( 8192 KB ) xxxxx unusable cdsp
0x000000000-0x000000000 0x00500000 ( 5120 KB ) xxxxx unusable pil_video
0x000000000-0x000000000 0x07800000 ( 122880 KB ) xxxxx unusable modem
0x000000000-0x000000000 0x00500000 ( 5120 KB ) xxxxx unusable camera
0x000000000-0x000000000 0x00002000 ( 8 KB ) xxxxx unusable gpu
0x000000000-0x000000000 0x00005000 ( 20 KB ) xxxxx unusable ipa_gsi
0x000000000-0x000000000 0x00010000 ( 64 KB ) xxxxx unusable ipa_fw
0x000000000-0x000000000 0x05540000 ( 87296 KB ) xxxxx unusable removed
0x000000000-0x000000000 0x00100000 ( 1024 KB ) xxxxx unusable xbl
0x000000000-0x000000000 0x00600000 ( 6144 KB ) xxxxx unusable hyp
0x000000000-0x000000000 0x00000000 ( 0 KB ) xxxxx unusable initmem
0x000000000-0x000000000 0x0a6358b2 ( 170199 KB ) xxxxx unusable kernel
Reserved : 578359 KB
.kernel : 170199 KB
.DT&EPARAM : 408160 KB
System : 5713080 KB
.common : 4881592 KB
.reusable : 831488 KB
Total : 6291439 KB ( 6143.98 MB )
*** Error dumping /sys/kernel/mm/rbincache/stats (RBIN STAT): No such file or directory
------ SWAP INFO (/proc/swaps) ------
Filename Type Size Used Priority
/dev/block/vnswap0 partition 2621436 616532 -1
*** Error dumping /dev/memcg/midgard/cgroup.procs (HEIMDALL INFO): No such file or directory
*** Error dumping /dev/memcg/midgard/memory.swapfile (HEIMDALL INFO): No such file or directory
*** Error dumping /dev/memcg/midgard/memory.swapquota (HEIMDALL INFO): No such file or directory
*** Error dumping /dev/memcg/midgard/memory.swappiness (HEIMDALL INFO): No such file or directory
*** Error dumping /dev/memcg/midgard/memory.stat (HEIMDALL INFO): No such file or directory
------ compressed core&heap dump in /data/log/core (gzip -1 -f /data/log/core/..) ------
*** command 'gzip -1 -f /data/log/core/..' failed: exit code 1
------ compressed core&heap dump in /data/log/core (gzip -1 -f /data/log/core/.) ------
------ DUMPSYS CRITICAL (/system/bin/dumpsys) ------
When I view the logs in the recovery menu it shows the architecture, if that's what you'd call it (the 0x00000000), it says 'moving blocks' and changing the digits to others that don't match. There is a very long and complicated story behind all of this that originates from my illegal immigrant Chinese landlord and about 30 sign in attempts on my accounts from China.
I may have been hit with Digital Wu-Flu.
I am currently using a Note 20 Ultra and have flashed it counltess times. One of the most obvious signs is when I insert an SD card, it writes multiple folders to it, and being "Android". It says there is 15 items in the folder but when I open it there is nothing there, even with hidden files checked. There is one empty folder in it, i think called data, but when I go to delete that it says it does not exist. I'm not a noob by any means, I'm just not good with coding, and I know for a fact all of my devices have been utterly destroyed.
How do you know this was the gang member living below you doing this? What did they purchase illegally online? What does your Chinese landlord have to do with any of this?
This is such a complicated mess!
also, https://files.catbox.moe/0mu4za.jpg
If Samsung can't fix it, neither can I. I don't know what they did, or how they did it, but every single device I own is beyond reair. Verizon, Samsung, Spectrum, Suddenlink have all verified the breach but not a single company will give any specifics or do anything to help. Likely because they don't want to be held liable for whatever security flaw allowed this to happen.
jonny_fresh said:
also, https://files.catbox.moe/0mu4za.jpg
If Samsung can't fix it, neither can I. I don't know what they did, or how they did it, but every single device I own is beyond reair. Verizon, Samsung, Spectrum, Suddenlink have all verified the breach but not a single company will give any specifics or do anything to help. Likely because they don't want to be held liable for whatever security flaw allowed this to happen.
Click to expand...
Click to collapse
What even happened? So far all I understand that your accounts online have been accessed.
FoorKob said:
How do you know this was the gang member living below you doing this? What did they purchase illegally online? What does your Chinese landlord have to do with any of this?
This is such a complicated mess!
Click to expand...
Click to collapse
He had some dude staying downstairs with him for like 3 weeks prior to this all happening. Dude never made a sound, the only reason we knew he was there was because there was a random pair of shoes in the hallway. The day I got the Critical Security Alert from Google, the downstairs neighbor came outside and started screaming at me, trying to fight me, nervous as **** and just literally flipping the fk out. When I woke up the next day my phone had been reset, all my themes and icons were back to stock. Then the guy started repeatedlyt calling the cops on me for no reason.
The Chinese landlord lady used an alias to purchase the property. I believe it was just used as a shell property to ship the illicit items to the house. There was a non stop flow of DHL packages coming to the house, and the dude would pull up (always in strangers cars) grab the package, and leave. We regularly heard him talking on the phone about drug deals, picking up the 'bag', order came in, etc. I knew the guy had gang affiliations but hadno idea he was using my devices to order his supply.
Also, the Chinese lady had hidden spy cameras hidden throughout the house and was spying on us for YEARS. I never understood why until I figured out what they were doing with my devices. Makes sense that they would want to know when and if I was home/asleep so they could push **** to the PC, place orders, drop packages, etc. It is such a long and ****ed up story I could go on all day but the last day I was there, I unplugged one of the cameras as they had microphones on them, so I was being illegally eavsdropped on. The cops showed up and clearly were connected to this gang banger. See for yourself, it's ****ed up. Please understand that I had to be very careful what I said because I KNEW they were just going to say hE'S CraZy.
The girl mentioned filed multipl false reorts against us. This was right around the time all this went down. The police knew she was filing false reports and, rather than do anything about it, they added it to their massive stack of years of bull**** reports, attempting to set me up. The girl ended up getting stabbed in the face.
FoorKob said:
What even happened? So far all I understand that your accounts online have been accessed.
Click to expand...
Click to collapse
It wasn't just the accoutns, it was the devices themselves. A cop friend of mine told me there is a method cops can use called 'cloning' which basically makes your phone look normal but others can be doing whatever they want in the background. Every device and OS was effected, which leads me to believe it is a CPU exploit. I think the accounts were just the access point.