• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

[ROM][BETA] CyanogenMod 10 for the LG Lucid

JJPR97 said:
Yeah it's very irretating, my phone is going to overheat soon haha damn screencast, I failed at a video 3 or 4 times, with full overclock settings it strains the phone and makes it so hot, no crash and yet the SoD happens over nothing -_-.
Click to expand...

the phone cant handle the full overclock, i underclock to 918 mhz for battery life but still get smooth performance
 
filipino808 said:
the phone cant handle the full overclock, i underclock to 918 mhz for battery life but still get smooth performance
Click to expand...

It handles it for CM10, for a few minutes set on performance with the Min/Max both set to 1512, the thing is it changes the Min/Max automatically to 1242 or 1296 (Can't remember, I think it was 1242) and stays there, either way useful.
 
Yo JJ, does the SoD occur even when not plugged in? mines frozen twice on me since i reflashed. I'm about to go back to stock.
 
xxwhynotxx said:
Yo JJ, does the SoD occur even when not plugged in? mines frozen twice on me since i reflashed. I'm about to go back to stock.
Click to expand...

It occured once while on my pocket in school, I checked it, trying to check the time while in the Office and I had to take out my battery put it in and boot, I was scared that it was bricked haha, but it rarely happens out of the charger for me and during school my CPU stays locked at 486 and mine doesn't freeze.
 
JJPR97 said:
It occured once while on my pocket in school, I checked it, trying to check the time while in the Office and I had to take out my battery put it in and boot, I was scared that it was bricked haha, but it rarely happens out of the charger for me and during school my CPU stays locked at 486 and mine doesn't freeze.
Click to expand...

For all users having sleep-of-death problems, try flashing this kernel over an otherwise working CM10 and seeing if it makes the issue occur less often. No wiping is required, but the standard drill about backups still applies. This fix adds voltage and thus decreases the maximum overclock frequency to 1.404 GHz; do not flash if you are not experiencing sleep of death as battery life is reduced.
 
I'm not touching anything that makes my battery any worse lol. Maybe once I buy a new one but this thing is pitiful.

I just want to be sure its ok when unplugged. Repaired permissions, wiped cache, reflashed gapps, we'll see how that goes. If it doesn't work a complete wipe will occur late wednesday, and if that doesn't help its back to stock.
 
stcarlso said:
For all users having sleep-of-death problems, try flashing this kernel over an otherwise working CM10 and seeing if it makes the issue occur less often. No wiping is required, but the standard drill about backups still applies. This fix adds voltage and thus decreases the maximum overclock frequency to 1.404 GHz; do not flash if you are not experiencing sleep of death as battery life is reduced.
Click to expand...

Thanks for making something as a sort of fix, but my battery is crappy enough haha. All I need to do is keep my screen off while charging, no big deal for me, but still thanks.
 
JJPR97 said:
Thanks for making something as a sort of fix, but my battery is crappy enough haha. All I need to do is keep my screen off while charging, no big deal for me, but still thanks.
Click to expand...

It won't be worse (and will be better) than stock. I just added 50-75 mV on the lowest frequencies to try and alleviate sleep of death. The difference will be almost unnoticeable if the data or WiFi radios are on. Just giving full and complete disclosure of what changed.
 
How will that be better? I understand keeping alive but how does that not use more power? Although that small probably won't matter, so if I encounter this I will try it out, thanks!
 
xxwhynotxx said:
How will that be better? I understand keeping alive but how does that not use more power? Although that small probably won't matter, so if I encounter this I will try it out, thanks!
Click to expand...

The kernel since A1 is undervolted. In some cases, it is significantly so, up to 125 mV below the stock voltages at some frequencies. While this has made for excellent battery life, evidently not all Lucid CPUs can handle such a low voltage without instability. In some cases, the CPU will hang up and not resume due to insufficient voltage, leading to the so-called "Sleep of Death". More voltage per Hz (V/Hz) at low frequencies may help if the SoD occurs at idle due to this reason.

If there is no effect, other reasons can still cause SoD, but such a finding would eliminate a likely cause to narrow down a true solution.
 
Hey stcarlso got a quick question for you if I was to take and put my phone back stock and take and copy the GPS fine n put it in CM10 file using file manager could it possibly fix my GPS?
 
Def Logics said:
Hey stcarlso got a quick question for you if I was to take and put my phone back stock and take and copy the GPS fine n put it in CM10 file using file manager could it possibly fix my GPS?
Click to expand...

I have the GPS blobs from ZV6. I'll put those in once I fix either EGL or SoD for B3 and see if they improve GPS (it worked for the spectrum). If you want to put those in and try it yourself it would be greatly appreciated. The files you want are listed in this post.
 
stcarlso said:
I have the GPS blobs from ZV6. I'll put those in once I fix either EGL or SoD for B3 and see if they improve GPS (it worked for the spectrum). If you want to put those in and try it yourself it would be greatly appreciated. The files you want are listed in this post.
Click to expand...

Thank you sir I'll try it and let you know if it helps me
 
Okay, I'm finally getting to the bottom of the EGL problem. It turns out that the CM/Linux kernel itself is running out of memory at the error point, since kmalloc can't find a contiguous 128K block to use. That points to something in the kernel code (probably in the lge/ folder or other LG mods) leaking memory, not the GL subsystem/drivers. It might be a slow leak that occurs while the phone is on or a leak triggered by video intensive operations. Since this also afflicts iproj, any ideas from tdm, Neph81, or any other dev regarding where to start looking?
 
stcarlso said:
Okay, I'm finally getting to the bottom of the EGL problem. It turns out that the CM/Linux kernel itself is running out of memory at the error point, since kmalloc can't find a contiguous 128K block to use. That points to something in the kernel code (probably in the lge/ folder or other LG mods) leaking memory, not the GL subsystem/drivers. It might be a slow leak that occurs while the phone is on or a leak triggered by video intensive operations. Since this also afflicts iproj, any ideas from tdm, Neph81, or any other dev regarding where to start looking?
Click to expand...

tried looking at the stock src for clues?
 
xxwhynotxx said:
Just had another SoD but it could be the egl problem since I had a game on, although its not too intensive...
Click to expand...

Sleep of death only occurs when the phone is idling with the screen off, possibly on the charger. Chances are good that if there was anything running that it was EGL. Did it reboot immediately or just lock up? And was the screen on or off?
 
PlayfulGod said:
tried looking at the stock src for clues?
Click to expand...

I haven't quite done that yet, but given that stock ICS supposedly was fine, that exonerates most of the vibrator, bluetooth, touchpad, camera, and power management stuff from LG (direct cut-and-paste). If iproj had the exact same issue that probably disqualifies the display drivers.

EDIT:
Given that it's a leaker, I grepped the "lge" folder for "malloc". We can toss the hits in "felica" and "broadcast" since those are disabled in the config. The two hits in "eta" were easy to check. "input" had hits in initialize functions that I hope are only running once. That leaves maybe "factory", or more likely something else LG or an iproj developer changed in the rest of the kernel.

What else has iproj changed from the (supposedly bug free) base CM kernel source?
 
stcarlso said:
I haven't quite done that yet, but given that stock ICS supposedly was fine, that exonerates most of the vibrator, bluetooth, touchpad, camera, and power management stuff from LG (direct cut-and-paste). If iproj had the exact same issue that probably disqualifies the display drivers.

EDIT:
Given that it's a leaker, I grepped the "lge" folder for "malloc". We can toss the hits in "felica" and "broadcast" since those are disabled in the config. The two hits in "eta" were easy to check. "input" had hits in initialize functions that I hope are only running once. That leaves maybe "factory", or more likely something else LG or an iproj developer changed in the rest of the kernel.

What else has iproj changed from the (supposedly bug free) base CM kernel source?
Click to expand...

The stock ICS source is far from bug free on the spectrum. The stock GB source was much much better. There are only a couple crashing bugs in ICS sources but the phone seems to be driven harder making weak phones unstable.

That said, I don't recall exactly what cm changed, since I wasn't involved in the project. Look through the commits for the best information.

By the way lge is just now starting to release lu6200/su640 kernel sources for jb. I haven't looked at them yet so I don't even know if it's 4.1 or 4.2. But it's there and you can bet rmcc and I will be looking at it.
 
stcarlso said:
Sleep of death only occurs when the phone is idling with the screen off, possibly on the charger. Chances are good that if there was anything running that it was EGL. Did it reboot immediately or just lock up? And was the screen on or off?
Click to expand...

I had a game running non graphics intensive. (Or shouldn't seem to be)

Its a game with a bazaar in it, so I had put something up, locked my phone, unlocked it about 15 seconds later, repeated about 3 times.

Not sure which point the problem was, if it turned black when it was on or stayed black once I turned it off. Regardless it required a battery pull to reboot.
 
xxwhynotxx said:
I had a game running non graphics intensive. (Or shouldn't seem to be)

Its a game with a bazaar in it, so I had put something up, locked my phone, unlocked it about 15 seconds later, repeated about 3 times.

Not sure which point the problem was, if it turned black when it was on or stayed black once I turned it off. Regardless it required a battery pull to reboot.
Click to expand...

Strange.
 
tdm said:
The stock ICS source is far from bug free on the spectrum. The stock GB source was much much better. There are only a couple crashing bugs in ICS sources but the phone seems to be driven harder making weak phones unstable.

That said, I don't recall exactly what cm changed, since I wasn't involved in the project. Look through the commits for the best information.

By the way lge is just now starting to release lu6200/su640 kernel sources for jb. I haven't looked at them yet so I don't even know if it's 4.1 or 4.2. But it's there and you can bet rmcc and I will be looking at it.
Click to expand...

It can't be one of the stock LG drivers I put in for Lucid since I went through those and they came up clean. It's something copied from iproj. If the kernel is leaking, how can you identify how much is lost?
 
stcarlso said:
It can't be one of the stock LG drivers I put in for Lucid since I went through those and they came up clean. It's something copied from iproj. If the kernel is leaking, how can you identify how much is lost?
Click to expand...

It's almost surely the kgsl/adreno stuff.

There is no easy way to debug kernel memory leaks.
 
You must log in or register to reply here.
Back
Top Bottom