yashsingh1/xdaforums huggingface dataset:
[LG Optimus 2x] missaellpzchvz:
Amazing work @wkpark. Running great on P999 very stable and functional, a few bugs to mention (sorry if they were already stated): battery calibration is a bit off ex: shows 999% randomly then jumps back to correct measuring, BSOD (aka Black Screen Of Death) when charging, I have experienced this a few times but after a few voltage steaks it seems to be fine, data connectivity during a call or regular use will suddenly stop and this creates call drops ect. Hope this helps, if you need any sort of logs let me know so I can try and re-create the bugs and give you more info so they can be worked out. Overall the kernel works on any ICS build I have run it with and except for the mentions above it runs exceptionally. If you require of any testing for P999 builds I am readily available and am willing to test. :) Hope you don't mind the thread I created in the General forum section of G2x, just thought I would get your work noticed over there ;)

Sent from my LG-P999
[LG Optimus 2x] wkpark:
I just temporary upload merged with linux-stable 3.0.25 revision branch.

https://github.com/wkpark/tegra-linux-3.0.y/tree/p99x-ics-3.0.y

and additionally manually cherry-pick to enable CSCAN and disable WL_IW_USE_ISCAN, ENABLE_ACTIVE_PASSIVE_SCAN_SUPPRESS (by rmcc)

(https://github.com/CyanogenMod/lge-kernel-star/commit/f85a0de9992d2fb747ab74c0fc1697df6c73bdea)

thankyou for your posting at G2X forum :)

USB part is not much changed from original kernel 3.0.x

so it might be something already done by arcee found at the lge-kernel-star.

Please see the following instruction to extract the last kernel log after BSOD if you have some time.

http://xdaforums.com/showpost.php?p=23920142&postcount=131

http://xdaforums.com/showpost.php?p=23923651&postcount=145
[LG Optimus 2x] vadonka:
you need to adjust the cmdline mem and nvmem part because of the changed carveout size. if you do this there is nothing wrong, carveout memory reduced only 32MB, so its brake nothing. everything will work. cm9 kernel also use this reduced carveout memory

mem=415M@0M

nvmem=96M@416M
[LG Optimus 2x] missaellpzchvz:
I will get it to you if I get one. Just one note, BSOD are a known issue on the P999 and although can be caused by the kernel it is mostly caused by the either the phone or the charger so you probably won't find a permanent fix. It happens to some and to others it doesn't. The only way known to prevent it for now would be to raise voltage or set charging settings to "stay awake" but that would be up to the user of the kernel since it risks battery life and maybe even performance. So overall if you find a solution, then great, but again its a known issue on any other kernel already available for the P999. That's also why your SU660 doesn't get the same problem.

Sent from my LG-P999
[LG Optimus 2x] RohanAJoshi:
Environment : CM9 Owain's Kang 27. BB n RIL 218.

k, on this kernel ryt now..

when flashed, i was on 75% battery, after few use for 3 to 4 hrs, i dropper at 60%.

its normal drain though..

.

then i restarted few times.

after gone out for some work, screen was off for half hr.

when i turned screen on my battery was 1%.

of-course, there is problem in reading battery, then i restarted phone, battery gone 18%, again restart battery on 19% and go on.
[LG Optimus 2x] wkpark:
the mach-tegra part of kernel 3.0.8 is almost identical with lge-kernel-star

and the lge-kernel-star repo is well managed and it has already several BSOD fixed.

https://github.com/wkpark/tegra-linux-3.0.y/commits/p99x-ics-3.0.y/

(you can see that all commit history are well preserved and the recent BSOD issue is fixed by Benee)

so I guess the BSOD issue reported again is different issue of different reason
[LG Optimus 2x] wkpark:
that break old behavior of well known ramhack.

you can't increase the nvmem at all.

some games need more memory to run correctly.

that's why i did not have applied the problematic commit.

without this change we can use both nvmem=128M and nvmem=96 by the following ramhack.

nvmem=128M

mem=383M@0M nvmem=128M@384M ( 1M@383M area reserved for ram console)

nvmem=96M

mem=383M@0M mem=32M@384M nvmem=96M@416M (1M@383M area reserved for ram console)
[LG Optimus 2x] vadonka:
if you dont change the carveout size but reduced the nvmem in the cmdline it will be a problem, right after some heavy program eat a lot of memory the phone will freeze. 96MB gpu memory is enough for every massive game.

the ramhack reboot issue is fixed in the cm kernel. i try many combination already in my cm7 kernel, but changing the nvmem and mem in the cmdline without changing the carveout size=problem

of course 32mb ramhack is small, so probably wont face the freeze problem only who using some massive memory eater app. soon as the system trying to allocate a bank what is reserved for the gpu then will have problems.

and you cant define the mem parameter twice, only the first will be parsed by the kernel.

look at arch/arm/kernel/setup.c at line 475
[LG Optimus 2x] wkpark:
yes I already knew that. but this is not the point.

no. you wrong. it is well known trick at SU660 forum in Korea.

you can even reduce nvmem by same method. its normal behavior of mem parameters.

...
<5>[ 0.000000] Kernel command line: [b]mem=383M@0M mem=32M@384M [/b] nvmem=96M@416M (snip) androidboot.hardware=p990 (snip)
<6>[ 0.000000] muic_state = 1
<6>[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>[ 0.000000] Memory: [b]383MB 32MB = 415MB total[/b]
<5>[ 0.000000] Memory: 411332k/411332k available, 13628k reserved, 0K highmem
<5>[ 0.000000] Virtual kernel memory layout:
<5>[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
<5>[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
<5>[ 0.000000] DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
<5>[ 0.000000] vmalloc : 0xda800000 - 0xfe000000 ( 568 MB)
<5>[ 0.000000] lowmem : 0xc0000000 - 0xda000000 ( 416 MB)
<5>[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
<5>[ 0.000000] .init : 0xc0008000 - 0xc0037000 ( 188 kB)
<5>[ 0.000000] .text : 0xc0037000 - 0xc0688000 (6468 kB)
<5>[ 0.000000] .data : 0xc0688000 - 0xc06cec60 ( 284 kB)
<5>[ 0.000000] .bss : 0xc06cec84 - 0xc0839090 (1450 kB)
...
[LG Optimus 2x] vadonka:
well as i see this: mem=383M@0M mem=32M@384M

equal with this: mem=415M@0M

:)

mem=size@start

starting at 0MB using 383MB size, then starting at 384MB then using more 32MB its equal like starting at 0MB and using 415MB.

but the main problem still exsist, for the gpu still reserved 128MB

try to using a bigger ramhack, the phone wont even boot. but if you reduce the carveout size too, then even the 112mb ramhack can bootable
[LG Optimus 2x] wkpark:
Please see previous comment carefully. that's not the same.

http://xdaforums.com/showpost.php?p=23948315&postcount=195

"without carveout patch" you can use nvmem=96M. that's the point.
[LG Optimus 2x] vadonka:
nvmem is not equal like the carveout memory in the kernel. thats the problem. the kernel still try to allocate the reserved memory bank for the gpu, it doesn't matter that the rom dont want to use it. just try to reduce the nvmem with 96mb for example and raise the memory with that size, and see what happened.

but if you using just 32MB, then probably only a very few people have problems, so its not a big problem after all.

the iconia kernel have a feature that the nvmap can use the system memory (shared with the operating system but not translated through an IOVMM device) for allocations

in that case the this trick will work, but our kernel doesn't have this feature.
[LG Optimus 2x] wkpark:
the "nvmem=" set the real carveouts at "drivers/video/tegra/nvmap.c"

#define NR_CARVEOUTS 2
static unsigned int nvmap_carveout_cmds = 0;
static unsigned long nvmap_carveout_cmd_base[NR_CARVEOUTS];
static unsigned long nvmap_carveout_cmd_size[NR_CARVEOUTS];
...

static int __init nvmap_core_init(void)
{
...
for (i=0; i<nvmap_carveout_cmds; i++) {
char tmp[16];
snprintf(tmp, sizeof(tmp), "generic-%u", i);
nvmap_add_carveout_heap(nvmap_carveout_cmd_base[i],
nvmap_carveout_cmd_size[i], tmp, 0x1);
}

return 0;
}
...
static int __init nvmap_heap_arg(char *options)
{
unsigned long start, size;
char *p = options;

start = -1;
size = memparse(p, &p);
if (*p == '@')
start = memparse(p + 1, &p);

if (nvmap_carveout_cmds < ARRAY_SIZE(nvmap_carveout_cmd_size)) {
nvmap_carveout_cmd_base[nvmap_carveout_cmds] = start;
nvmap_carveout_cmd_size[nvmap_carveout_cmds] = size;
nvmap_carveout_cmds++;
}
return 0;
}
__setup("nvmem=", nvmap_heap_arg);

and...

https://github.com/CyanogenMod/lge-kernel-star/commit/a13bfa4b54a71e102ec3759dd79a53ad3f3cb655

#define CARVEOUT_SIZE XXX just used to set ram_console area (and it make some incompatible ramhack issue)

and NvU32 NvOdmQueryCarveoutSize(void) is not used at all.

so "nvmem=" do real job.
[LG Optimus 2x] kitty's_daddy:
We could adjust nvram size with wkpark's boot tweak. It's real. :)

Also he made a bootlogo changer.
[LG Optimus 2x] vadonka:
NvOdmQueryCarveoutSize used by the nvrm daemon, the carveout size defined the reserved memory bank range for the nvmap.

its ok that the nvmem command line parameter defined the allocated nvmap memory size but the nvmap can write only to the reserved banks. if the system memory is bigger there is a chance that the system and the nvmap try to allocate the same bank at the same time in that "overlapped" area. it happened rarely if you using small ramhack, but if you try to use a bigger value it happened often.

just try to use a bigger ramhack and you will see what happen :)
[LG Optimus 2x] wkpark:
oops! i was wrong. NvOdmQueryCarveoutSize sysmbol is found at System.map

...
c009430c T NvOdmQueryCarveoutSize
...

so then,

"nvmem=" is parsed => "nvmap_core_init() is called

after that the real CarveoutSize is fixed.

NvOdmQueryCarveoutSize() have to return the real CarveoutSize, right?

you don't have to worry about that.

I always using smaller size of the nvmem about ~64M and It is known safe for normal usage.

maybe NvOdmQueryCarveoutSize() effect is less than expected.
[LG Optimus 2x] vadonka:
|------------------------------512MB----------------------------|

|------system reserved 384MB------|----gpu reserved 128MB-----|

|--------system allocated 416MB-------|---gpu allocated 96MB----|

|----------------------------------|32-|-------------------------|

this little part in the middle is overlapped in that case, the nvmap can write to here and the system too. only problem if the system and the nvmap try to allocate at the same time in this block.

the other case:

|------------------------------512MB----------------------------|

|------system reserved 384MB---------|--gpu reserved 96MB-----|

|--------system allocated 416MB-------|---gpu allocated 96MB----|

no overlap, but in that case need to adjust the carveout size too.

but with 32mb ramhack this is not a problem, only if you used a much bigger ramhack size.

the nvmem defined the allocated gpu memory size for the nvmap, the carveout size is the reserved memory bank range size, with an offset.

by the way i try to integrate the overclock feature but the cpufreq driver have a big difference with the 2.6.x kernel.

anybody have any progess about this?
[LG Optimus 2x] RoXeon:
I thought about that, unfortunately it isn't working for me. I've just tryed many other mem/nvmem settings (ofc those which are making sense in that case) and i still can't boot that kernel.

I've checked boot header and everything is ok here. Ramdisk is same as i've used before last commit, so it shouldn't be a problem either.

EDIT1:

How does this -32M shifting work? Why it's -32MB not +32MB? With +32MB or 0MB i can boot kernel easly. With -32MB not really... I've ever tried to allocate gpu mem before cpu (what makes sense if we are shifting cpu mem start by -32MB).

If i understand it correctly, shifting by -32MB makes sense only when: we are shifting gpu memory or when we are shifing cpu memory but assuming that gpu memory is allocated "before" cpu mem.
[LG Optimus 2x] wkpark:
this graph somewhat miss leading.

|------------------------------512MB----------------------------|

|------system reserved 384MB------|----gpu reserved 128MB-------|

|--------system allocated 416MB-------|---gpu allocated 96MB----|

|---------------------------------|32-|-------------------------|

this is wrong because of no "ram_console" area. (slightly fixed)

|------------------------------512MB----------------------------|

|------system reserved 383MB-----|1M|----gpu reserved 128MB-----| (for CM7 lge-kernel-star case)

|-------system allocated 415MB-------|1M|---gpu allocated 96MB--| (for CM9 lge-kernel-star case with "carveout patch")

|--------------------------------|--32--|-----------------------|

this is right. 1MB must be excluded each other areas. and the 1MB area is of ram_console area.
[LG Optimus 2x] vadonka:
yes you re right, i know that just i dont want to bother the graph :) thx for the correction

anyway, integrating the overclock is hard, i still try it, but phone cant boot. too much different between the 2.3.32 and the 3.0 cpufreq driver :mad:

the other part is ok
[LG Optimus 2x] wkpark:
this patch make NvOdmQueryCarveoutSize() dependent on the nvmem boot param.
[LG Optimus 2x] Gabriesu:
Vodonka, when you will release your the kernel 3.0.x?

I've some big problem (BSOD first) with AOKP build -28 and this kernel! :(
[LG Optimus 2x] wkpark:
this is a OC patch based on the famous "FakeShmoo"

Originally made by Cpasjuste (OC/UV) + ratanakvlun(cpufreq) + kiljacken(setcpu support))

GPU/RAM/VDE Overclock by morfic.

Improved by Benee @ https://github.com/VorkTeam/vorkKernel-LGP990

Cleaned up and re-organized by Faux123 @ https://github.com/faux123

and cleaned up by me :)

it works nicely with my SU660 + SelfKANG3
[LG Optimus 2x] spica1234:
Wkpar once again thank you for your real greatwork:)
[LG Optimus 2x] jordantr:
I dont understand why do you need oc for this device? It works great without it. And after oc you complain about battery life :D
[LG Optimus 2x] anubiz03:
I'd agree with jordantr, OC is fine to have as an option, but shouldn't it be low priority compared to fixing crash bugs on normal non-OC use? Of course, it's your work and you can prioritize it any way you wish, and we're all really thankful that you're doing this great work at all :)
[LG Optimus 2x] vadonka:
thx!

this is a really good trick :)

i applyed to my cm7 kernel too :)

i need to make a little modification for the carveout patch, because i had impilicit declaration of function error in the nvodm_query.c

with this patch, its working fine.

i extended your patch to the ram console, its needed otherwise the reboot is not working if you use the ramhack. its working perfectly now :) thx for your help!

check out my latest commit in github for the details

hmm, may i have a question? the nvmap_carveout_size return value is byte or Mbyte? as i see you dont multiply the value in the nvodm_query, so you using the byte value?

ahh i see, you using the nvmap_carveout_cmd_size what have byte value
[LG Optimus 2x] Imperticus:
Haven't been on xda for a while and there seems to be a lot of development while I was away. Great work wkpark!! :D

Anyone trying to backport this for CM7?
[LG Optimus 2x] eniux:
Already happening :)

Verstuurd van mijn LG-P990 met Tapatalk
[LG Optimus 2x] chupi_24:
@wkpark

Will you create a CM9 kang with your kernel? :)

After i read this post of yours, been checking openstar2x if theres a Cm9 already
[LG Optimus 2x] wkpark:
sorry. I have only one SU660 device and I have no much time
[LG Optimus 2x] vadonka:
wkpark: are you sure that the carveout patch is right in this way? the reboot is doesn't working with that. i modifyed the ram_console.c too, but the nvmap_carveout_size value is always zero. it seems that cant read the right value from the nvmap.c

its working for you?
[LG Optimus 2x] spica1234:
PluS one for me.

In my case it works for some users including me while for some users it doesnt work:/
[LG Optimus 2x] chupi_24:
sorry my bad but i have an SU660 also...been using your CM7 kang under openstar2x...i was wondering if you will create one for CM9 for SU660...
[LG Optimus 2x] vadonka:
Spica: i push a new revised version of this patch, in that case the nvmap_carveout_size return value is correct, at least what i see in the dmesg, but the reboot is still not work for some reason..
[LG Optimus 2x] wkpark:
nvmap patch works for su660.

but I don't know why the carveout patch make the SU660 not bootable at all :(
[LG Optimus 2x] wkpark:
I think it is strange.

before i read this post I think this is the right memory map.

without carveout patch

|----------383M-------[1M]------128M------|

with 96MB carveout patch

|----------415M---------------[1M]--96M---|

[1M] == [512kB(ram console) + warm boot]​

but your code and armcee's code have the following memory map

without carveout patch

|----------383M-------[1M]------128M------|

with 96MB carveout patch

|----------415M--------[x]----[1M]--96M---|

[1M] == [only 512kB(ram console) + empty space]

[x] == warm boot]​

is it correct ?
[LG Optimus 2x] vadonka:
im using the same like what is in the faux repo, if he is using armcee code, then the answer is yes

even weirder that reboot with ramhack is working with 1-2 times from 10 reboot :)
[LG Optimus 2x] TrymHansen:
aremcee explained this a long time ago. This is a copy of an old post regarding reboot when ramhack is used: According to RC, the bootloader expects the reboot-information to be at 128MB + 11 bytes, while the system writes it to [MB Reserved for Graphics]+11 bytes. As long as no ram-hack is applied, it'll of course be in the right place. Shouldn't it be easy for a kernel to just copy what is at [MB RESERVED]+11 to [128MB]+11 before shutdown?

So there it is, the reboot info can't be moved, different carveout or not.
[LG Optimus 2x] vadonka:
but if im write the carveout memory size by hand to this file, the reboot is working all the time. why not work if the value is parsed from the kernel cmdline? even if this value controlled via the sysfs, and changed at the init process still work.
[LG Optimus 2x] vadonka:
Spica: use the OTF method for the GPURAM change.

Maybe the trick is that, with the first method the gpu ram parameters set in the kernels and booting with that values, but with the otf the kernel booting the default 128MB value and the gpu ram adjusted while in the init process.

anyway, the OTF method is working all the time, so i stick with that :)
[LG Optimus 2x] wkpark:
http://xdaforums.com/showpost.php?p=15731967&postcount=15

"Shouldn't it be easy for a kernel to just copy what is at [MB RESERVED]+11 to [128MB]+11 before shutdown?"

I think it is possible.

and the correct reserved buffer base is [512MB(total memory) - 128MB(carveout) - 1MB(reserved area) + 512kB(ram console)]

[FONT="Courier New"]"arch/arm/mach-tegra/common.c"

STAR_REVERBED_BUFFER_BASE is the original reserved buffer address

in tegra_machine_restart()..
...
+ default_reserved_buffer = phys_to_virt(STAR_RESERVED_BUFFER_BASE);
+ memcpy(default_reserved_buffer, tmpbuf, 3); // copy to original buffer.

write_cmd_reserved_buffer(tmpbuf, 3);
printk("arm_machine_restart : tmpbuf = %s\n", tmpbuf);

arm_machine_restart(mode, cmd);[/FONT]
[LG Optimus 2x] vadonka:
this code caused that the phone freeze at the second lg logo.
[LG Optimus 2x] TrymHansen:
The stock CM9 kernel already does it, why not just look there?
[LG Optimus 2x] wkpark:
no it does not.

the memory map of the CM9 kernel is the following (just copied from prev post)

|----------415M--------[x]----[1M]--96M---|

[1M] == [only 512kB(ram console) + empty space]

[x] == warm boot]​
[LG Optimus 2x] wkpark:
at the second logo ?? if so. it is not the code problem.

and the attached patch is works for me.
[LG Optimus 2x] TrymHansen:
Unless I'm misinformed (which is quite likely), that "x" gets copied to 128MB+11 right before shutdown. I'll leave it to you geniuses to find out. (NOT sarcasm, I really mean it. Deep respect for the work you're doing.)
[LG Optimus 2x] wkpark:
this is your idea :)

and i just dig the code of kernel 3.0 to fix possible compatible issue of kernel 3.0 now like as this warm boot issue.
[LG Optimus 2x] vadonka:
still hang at the second logo, but without this patch it is booting, im trying with the cm7
[LG Optimus 2x] wkpark:
Ive got oops before shutdown on CM9, sorry :o

[FONT="Courier New"]
[ 953.279213] [d7f80000] *pgd=17e1140e(bad)
[ 953.279405] Internal error: Oops: 805 [#1] PREEMPT SMP
[ 953.279526] Modules linked in: wireless
[ 953.279721] CPU: 0 Not tainted (3.0.8-cm9-ics+ #127)
[ 953.279858] PC is at [B]memcpy[/B]+0xcc/0x330
[ 953.279935] LR is at [B]tegra_machine_restart[/B]+0xd8/0x128
[ 953.280006] pc : [<c026826c>] lr : [<c00488b0>] psr: a0000013
[ 953.280011] sp : ccf1fe24 ip : 00000063 fp : ccf1fe54
[ 953.280191] r10: 00000000 r9 : ccf1e000 r8 : c003e4a4
[ 953.280310] r7 : c06d94e0 r6 : ccf1fe30 r5 : 00000068 r4 : 00000065
[ 953.280380] r3 : 00000077 r2 : 80000000 r1 : ccf1fe33 r0 : d7f80000
[ 953.280502] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 953.280623] Control: 10c53c7d Table: 11c6404a DAC: 00000015[/FONT]

so.. this patch is not perfect.

EDIT:

this patch may fix this problem.

--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -291,8 +292,9 @@ static void tegra_machine_restart(char mode, const char *cmd)
#define RAM_CONSOLE_RESERVED_SIZE 1
#endif
#define STAR_RESERVED_BUFFER_BASE ((512 - DEFAULT_CARVEOUT_SIZE - RAM_CONSOLE_RESERVED_SIZE)*SZ_1M + 512*SZ_1K)
- default_reserved_buffer = phys_to_virt(STAR_RESERVED_BUFFER_BASE);
+ default_reserved_buffer = ioremap(STAR_RESERVED_BUFFER_BASE, 11);
memcpy(default_reserved_buffer, tmpbuf, 3);
+ iounmap(STAR_RESERVED_BUFFER_BASE);

write_cmd_reserved_buffer(tmpbuf, 3);
[LG Optimus 2x] wkpark:
second LG boot logo means it's kernel booted up.

but you have to remember that this kernel 3.0 have known issue with external SD at init process. just try to reboot after pull out external SD card.
[LG Optimus 2x] RohanAJoshi:
Guys, plz add inline call recording support in this kernel which most htc, Samsung, sony phones allready have.
[LG Optimus 2x] zerocoolriddler:
No Need to post it in every Kernel-Related Thread...;)
[LG Optimus 2x] wkpark:
I think this is not kernel problem.