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

Root [rom] pac-man

Now I'm wondering what if anything I may have messed up to make this thing look for a non-existent file. Nothing I've been playing with should have done that...

I flashed the baseband again in an attempt to remove some modem errors I've been having intermittently. They don't happen every time I boot but they happen pretty often. I'm not going to be home for till tomorrow night though so I won't be able to post the errors till then. But they were kickstart errors trying to attach ttys to modem fills in the firmware partition. I want to say they were errors opening the files... but the files are there.

Sent from my VS920 4G using Tapatalk 2



Sent from my VS920 4G using Tapatalk 2
 
My guess is that it's looking for files that are on the optimus line of phones as they shared the coding between many phones. Case in point is that stock ICS looks for files pertaining to NFC, even though our phone does not support it. Heck, if you look at the original init.rc scripts, you'll see that a good 1/4 of the files it calls out at boot don't actually exist on the stock rom.
 
Trying to download the 5/07 nightly and I keep getting 404 error :(

Anyone else have this issue?

Edit: fixed. Apparently, their link to vs920 changed. My bookmark was to a dead folder.
 
All three ROMs use the same init. And they probably all have the same issue. init.qcom.post_boot.sh is hung off of boot animation stopped, but sometimes it stays in stopping and doesn't get to stopped. I'll bet that's what you see if you run getprop.

The fix is easy: just use dev.bootcomplete instead.

Yeah. init.svc.bootanim is stuck in stopping.

I'm not sure when dev.complete is actually being set, but isn't that after all of the initialization is finished executing?

Might it be better to run off service.bootanim.exit which is being set to 1 even though boot.animation.stopped is stuck at stopping?

TBH, I never realized that just running getprop would give you all of the currently set properties, and what value they're set at. That helps me fix something in what i was working on to run things when the animation stops.

The way that i'm trying to get around this for the time being is by including the following in an init script that has simulated run level sections that I have running during an "oncomplete" stage which is run by init.rc on property:service.bootanim.exit=1. Now that I read into that a little more, I think that seems like a good place to leave it as a safety net, since if the correct init.qcom script runs, these should be running by the time that my event fires off.

if ! ps | grep -v grep | grep mpdecision > /dev/null
then
log -p v -t sysinit "mpdecision not running, starting it now."
start mpdecision
else
log -p v -t sysinit "mpdecision running."
fi
if ! ps | grep -v grep | grep thermald > /dev/null
then
log -p v -t sysinit "thermald not running, starting it now."
start thermald
else
log -p v -t sysinit "thermald running."
fi

However, running mpdecision like this... occasionally reboots my phone. It's no different than the way it's being launched in the init.qcom.post_boot.sh "start mpdecision". So i'm not sure why it reboots. It will also reboot when I issue "start mpdecision" from the command line if it's not running. What I was worried about happened though :(

Trying to start mpdecision manually at "onfinalize" bootlooped me. This is launched from init.rc as "on property:sys.boot_completed=1". I've already reverted to my "oncomplete" portion.

Here's the full portion prior to the reboot after that section was trying to start mpdecision and thermald.

V/sysinit ( 5771): Switching to state 'onfinalize'...
V/sysinit ( 5777): Executing /system/etc/init.d/S90user.rc...
E/VoldConnector( 985): NDC Command {30 asec path com.gameresort.sz2google-1} took too long (769ms)
W/Launcher.Model( 4336): LoaderTask running with no launcher (loadAllAppsByBatch)
V/sysinit ( 5797): mpdecision not running, starting it now.
V/SipBroadcastReceiver( 4349): start auto registration
V/sysinit ( 5846): thermald not running, starting it now.
D/dalvikvm( 4336): GC_CONCURRENT freed 1667K, 49% free 5648K/11056K, paused 9ms+5ms, total 104ms
D/dalvikvm( 4336): WAIT_FOR_CONCURRENT_GC blocked 48ms
D/dalvikvm( 985): GC_FOR_ALLOC freed 2040K, 19% free 14768K/18212K, paused 219ms, total 219ms
E/ThermalDaemon( 5886): Thermal daemon started
E/ThermalDaemon( 5886): Threshold 0 Action[0] : none
E/ThermalDaemon( 5886): Threshold 1 Action[0] : none
E/ThermalDaemon( 5886): Threshold 2 Action[0] : none
E/ThermalDaemon( 5886): Threshold 0 Action Info[0] : 1512000.000000
E/ThermalDaemon( 5886): Threshold 0 Action Info[1] : 255.000000
E/ThermalDaemon( 5886): Threshold 1 Action Info[0] : 1512000.000000
E/ThermalDaemon( 5886): Threshold 1 Action Info[1] : 192.000000
E/ThermalDaemon( 5886): Threshold 2 Action Info[0] : 1242000.000000
E/ThermalDaemon( 5886): Threshold 2 Action Info[1] : 128.000000
E/ThermalDaemon( 5886): Threshold 0 Action[0] : cpu
E/ThermalDaemon( 5886): Threshold 0 Action[1] : lcd
E/ThermalDaemon( 5886): Threshold 1 Action[0] : cpu
E/ThermalDaemon( 5886): Threshold 1 Action[1] : lcd
E/ThermalDaemon( 5886): Threshold 2 Action[0] : cpu
E/ThermalDaemon( 5886): Threshold 2 Action[1] : lcd
E/ThermalDaemon( 5886): Threshold 0 Action Info[0] : 1512000.000000
E/ThermalDaemon( 5886): Threshold 0 Action Info[1] : 255.000000
E/ThermalDaemon( 5886): Threshold 1 Action Info[0] : 1512000.000000
E/ThermalDaemon( 5886): Threshold 1 Action Info[1] : 192.000000
E/ThermalDaemon( 5886): Threshold 2 Action Info[0] : 1242000.000000
E/ThermalDaemon( 5886): Threshold 2 Action Info[1] : 128.000000
E/ThermalDaemon( 5886): Number of cpus :2
E/ThermalDaemon( 5886): Establishing ONCRPC communication.
E/ThermalDaemon( 5886): Modem thermal mitigation available.
E/ThermalDaemon( 5886): Fusion modem thermal mitigation available.
E/ThermalDaemon( 5886): Sensor setup:[pm8058_tz]
E/ThermalDaemon( 5886): Sensor setup:[tsens_tz_sensor0]
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): oncrpc_xdr_call_msg_start: Prog: 300000b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): xdr_std_msg_send_call: Sent Xid: 0, Prog: 300000b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): xdr_std_msg_send_call: Received Reply Xid: 0, Prog: 300000b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): oncrpc_xdr_call_msg_start: Prog: 300000b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): xdr_std_msg_send_call: Sent Xid: 1, Prog: 300000b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): xdr_std_msg_send_call: Received Reply Xid: 1, Prog: 300000b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): oncrpc_xdr_call_msg_start: Prog: 300100b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): xdr_std_msg_send_call: Sent Xid: 2, Prog: 300100b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): rpc_handle_rpc_call: for Xid: 2a9, Prog: 310000b5, Vers: 00020001, Proc: 00000001
I/ONCRPC ( 5886): rpc_handle_rpc_call: Find Status: 0 Xid: 2a9
I/ONCRPC ( 5886): oncrpc_proxy_handle_cmd_rpc_call: Dispatching xid: 2a9
I/ONCRPC ( 5886): xdr_std_msg_send_call: Received Reply Xid: 2, Prog: 300100b5, Ver: 00020001, Proc: 00000000
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): oncrpc_xdr_call_msg_start: Prog: 300100b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): xdr_std_msg_send_call: Sent Xid: 3, Prog: 300100b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): xdr_std_msg_send_call: Received Reply Xid: 3, Prog: 300100b5, Ver: 00020001, Proc: 00000004
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
I/ONCRPC ( 5886): Setup RPC Call for task 40176270
E/ThermalDaemon( 5886): Sensor 'tsens_tz_sensor0' - alarm raised 1 at 55.0 degC
I/ONCRPC ( 5886): rpc_handle_rpc_call: for Xid: 330, Prog: 310100b5, Vers: 00020001, Proc: 00000001
I/ONCRPC ( 5886): rpc_handle_rpc_call: Find Status: 0 Xid: 330
I/ONCRPC ( 5886): oncrpc_proxy_handle_cmd_rpc_call: Dispatching xid: 330
E/MP-Decision( 5884): MPDecision server starting

My guess is that it's looking for files that are on the optimus line of phones as they shared the coding between many phones. Case in point is that stock ICS looks for files pertaining to NFC, even though our phone does not support it. Heck, if you look at the original init.rc scripts, you'll see that a good 1/4 of the files it calls out at boot don't actually exist on the stock rom.

Yeah, I'd just never noticed that error until recently. Even though I look at my logcats pretty often lately while I'm playing around with things. Just seemed odd.



*edit*
I'm guessing that the reason it's rebooting is because the rest of the init.qcom.post_boot script isn't excuting either which is setting some values for power collapse and stuff. I think im just going to force call that script if the processes aren't running yet.



Changed init.iprj-common.rc Lines 155 and 156 to:
on property:service.bootanim.exit=1
start qcom-post-boot

and rebuilt the ramdisk. Looks like it fixed it. Trying a couple more reboots. I can post a clean ramdisk flashable zip with just this change if anyone needs it. At least until the freeze is off and the code can be changed to fix it permanently.
 
@Yoinx: great work, I wish I would have seen that earlier. I already submitted a fix for the issue using dev.bootcomplete:

https://github.com/CyanogenMod/andr...mmit/c72491bff6eaf51c5be13fa4549335e3602eb410

Keep in mind this is all hackery around the core issue, which is that the display driver has a race condition that sometimes won't let the bootanim process stop. But since the hackery works, the urgency to fix the underlying issue goes down far enough that it probably won't ever get fixed ... :/
 
No worries. It's better to be fixed in the source (even if it's a hack) than for it to be a hack in a flashable hack :p

I've included it into the enhanced init.d flash I've got posted as well. Though, that has some other stuff in it... really people can just delete the extra stuff out of the zip if they don't want it.

That should at least give people a way of applying the fix to old roms as well. Like I said, I've noticed a HUGE difference in battery life when mpdecision is running


This may be a dumb question... couldn't you also just kill the bootanim process and set the property from the boot complete event (just in case anything else is looking for that property)?
 
That should at least give people a way of applying the fix to old roms as well. Like I said, I've noticed a HUGE difference in battery life when mpdecision is running

5/07 nightly apparently has mpdecision and thermald running on boot. This is where the confusion of my other post came from. So if you are running PAC 5/07 nightly and later, no need to worry about the zip for mpdecision.

Also about this nightly I didn't have with 5/06: when waking the phone up, it takes a little time for screen to turn on sometimes (3-10secs) and on boot it takes a little longer to acquire data (3G or 4G). Might be because of the dirty flash. Don't think there was any changes to make that happen, no?
 
5/07 nightly apparently has mpdecision and thermald running on boot. This is where the confusion of my other post came from. So if you are running PAC 5/07 nightly and later, no need to worry about the zip for mpdecision

Yeah, didn't realize he had committed it yesterday. That would mean any builds after that would have that fix :p

I still would have had to repack a new ramdisk anyway with init.rc tweaks that I'm using to pass cwm the current date anyway though.
 
No worries. It's better to be fixed in the source (even if it's a hack) than for it to be a hack in a flashable hack :p

I've included it into the enhanced init.d flash I've got posted as well. Though, that has some other stuff in it... really people can just delete the extra stuff out of the zip if they don't want it.

That should at least give people a way of applying the fix to old roms as well. Like I said, I've noticed a HUGE difference in battery life when mpdecision is running


This may be a dumb question... couldn't you also just kill the bootanim process and set the property from the boot complete event (just in case anything else is looking for that property)?

Well that's the problem. The process won't die because of the kernel bug.
 
yo tdm. Is the PACMAN team planning on implementing the new Halo feature from PA into PACMAN? I just watch a demo for it and it looks pretty neat.
 
How do I turn off the hard keys?

Sorry for the late reply.

System Settings > System > Hardware Keys >

Click each one and assign "No action" that should disable them. You'll need an init.d script to disable the backlights as typically they still light up even though they have no function. That's the only way that I found to persist the change for the backlight through reboots.

Keep in mind though, once you disable your menu button... unless you have another form of accessing the menus... you won't be able to get back in to the menus to change your setting.
 
Sorry for the late reply.

System Settings > System > Hardware Keys >

Click each one and assign "No action" that should disable them. You'll need an init.d script to disable the backlights as typically they still light up even though they have no function. That's the only way that I found to persist the change for the backlight through reboots.

Keep in mind though, once you disable your menu button... unless you have another form of accessing the menus... you won't be able to get back in to the menus to change your setting.

I meant to say backlight keys. Sorry
 
I meant to say backlight keys. Sorry

Basically you have to execute

echo 0 > /sys/class/leds/button-backlight/max_brightness
chmod 755 /sys/class/leds/button-backlight/max_brightness

On each boot. The only way I got this to persist was with an init.d script. I have a thread with some flashable zips that will do it for you.

Sent from my VS920 4G using Tapatalk 2
 
Forgive me if this has already been asked and answered but how do you change the temperature units on the lock screen weather?

Thanks in advance.
 
It might have been an issue with 5/07 or just flashing issue, but on 5/09 the data connect and delay for screen on hasn't happened yet. Still get system not responding on boot though.

Anyone else get system ANR on boot with these nightlies?
 
So, I noticed a bit of video (ui) lag after I rebooted from flashing today's pac. I'd noticed something similar in one of my other logcats the other day but wasn't really playing with the phone so I didn't correlate any lag with it, so didn't think anything of it.

The only thing that stands out in my logcat is that it looks like it keeps reloading files related to video. Not sure why... Before one set of the reloads, I have an ACRA from my lux app. Not sure if that's causitive or correlative though since it only happened once. Doubt these lines will help. Entire logcat in the spoiler.

Notepad++ search hits.
[high]
C:\Users\Joe\Desktop\ADB\4.2.2\video_lag.txt (48 hits)
Line 6439: D/libEGL ( 9869): loaded /system/lib/egl/libEGL_adreno200.so
Line 6441: D/libEGL ( 9869): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
Line 6443: D/libEGL ( 9869): loaded /system/lib/egl/libGLESv2_adreno200.so
Line 6445: I/Adreno200-EGL( 9869): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 6447: I/Adreno200-EGL( 9869): Build Date: 11/04/12 Sun
Line 6449: I/Adreno200-EGL( 9869): Local Branch:
Line 6451: I/Adreno200-EGL( 9869): Remote Branch: m/partner-android/jb-mr1-dev
Line 6453: I/Adreno200-EGL( 9869): Local Patches: NONE
Line 6455: I/Adreno200-EGL( 9869): Reconstruct Branch: NOTHING
Line 6733: D/libEGL (10114): loaded /system/lib/egl/libEGL_adreno200.so
Line 6735: D/libEGL (10114): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
Line 6737: D/libEGL (10114): loaded /system/lib/egl/libGLESv2_adreno200.so
Line 6739: I/Adreno200-EGL(10114): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 6741: I/Adreno200-EGL(10114): Build Date: 11/04/12 Sun
Line 6743: I/Adreno200-EGL(10114): Local Branch:
Line 6745: I/Adreno200-EGL(10114): Remote Branch: m/partner-android/jb-mr1-dev
Line 6747: I/Adreno200-EGL(10114): Local Patches: NONE
Line 6749: I/Adreno200-EGL(10114): Reconstruct Branch: NOTHING
Line 6809: I/Adreno200-EGL( 9869): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 6811: I/Adreno200-EGL( 9869): Build Date: 11/04/12 Sun
Line 6813: I/Adreno200-EGL( 9869): Local Branch:
Line 6815: I/Adreno200-EGL( 9869): Remote Branch: m/partner-android/jb-mr1-dev
Line 6817: I/Adreno200-EGL( 9869): Local Patches: NONE
Line 6819: I/Adreno200-EGL( 9869): Reconstruct Branch: NOTHING
Line 6833: I/Adreno200-EGL(10114): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 6835: I/Adreno200-EGL(10114): Build Date: 11/04/12 Sun
Line 6837: I/Adreno200-EGL(10114): Local Branch:
Line 6839: I/Adreno200-EGL(10114): Remote Branch: m/partner-android/jb-mr1-dev
Line 6841: I/Adreno200-EGL(10114): Local Patches: NONE
Line 6843: I/Adreno200-EGL(10114): Reconstruct Branch: NOTHING
Line 8247: D/libEGL (11351): loaded /system/lib/egl/libEGL_adreno200.so
Line 8249: D/libEGL (11351): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
Line 8251: D/libEGL (11351): loaded /system/lib/egl/libGLESv2_adreno200.so
Line 8253: I/Adreno200-EGL(11351): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 8255: I/Adreno200-EGL(11351): Build Date: 11/04/12 Sun
Line 8257: I/Adreno200-EGL(11351): Local Branch:
Line 8259: I/Adreno200-EGL(11351): Remote Branch: m/partner-android/jb-mr1-dev
Line 8261: I/Adreno200-EGL(11351): Local Patches: NONE
Line 8263: I/Adreno200-EGL(11351): Reconstruct Branch: NOTHING
Line 8575: D/libEGL (11624): loaded /system/lib/egl/libEGL_adreno200.so
Line 8577: D/libEGL (11624): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
Line 8579: D/libEGL (11624): loaded /system/lib/egl/libGLESv2_adreno200.so
Line 8581: I/Adreno200-EGL(11624): <eglInitialize:269>: EGL 1.4 QUALCOMM build: Nondeterministic AU_full_mako_PARTNER-ANDROID/JB-MR1-DEV_CL2946718_release_AU (CL2946718)
Line 8583: I/Adreno200-EGL(11624): Build Date: 11/04/12 Sun
Line 8585: I/Adreno200-EGL(11624): Local Branch:
Line 8587: I/Adreno200-EGL(11624): Remote Branch: m/partner-android/jb-mr1-dev
Line 8589: I/Adreno200-EGL(11624): Local Patches: NONE
Line 8591: I/Adreno200-EGL(11624): Reconstruct Branch: NOTHING
[/high]


Full Logcat:
Full Logcat - Pastebin.com

Dmesg:
Dmesg - Pastebin.com


Not really sure it's anything... It'll probably clear up when I reboot
 
It might have been an issue with 5/07 or just flashing issue, but on 5/09 the data connect and delay for screen on hasn't happened yet. Still get system not responding on boot though.

Anyone else get system ANR on boot with these nightlies?

ANR = App not responding? Haven't gotten those on boot on any of them.

You were getting a screen on delay before today's as well? I had thought I was having problems with my power button. Sometimes it would turn on. Sometimes the screen would stay off then turn on like 5 seconds late. Is that what you were experiencing? I haven't seen it yet on this nightly (5/09) but I also haven't been messing with it long yet.
 
ANR = App not responding? Haven't gotten those on boot on any of them.

You were getting a screen on delay before today's as well? I had thought I was having problems with my power button. Sometimes it would turn on. Sometimes the screen would stay off then turn on like 5 seconds late. Is that what you were experiencing?

I did in previous nightlies, but with this one it hasn't happened yet, just system app not responding at boot.
 
Back
Top Bottom