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

Root [ROM][ALPHA] Quattrimus ICS (CM9, AOKP40)

Data pooped out on me on the cm9 build. Tried dirty flashing over it but to no avail. I'll probably flash aokp in the morning to see if it holds out longer.
 
ortrigger said:
Data pooped out on me on the cm9 build. Tried dirty flashing over it but to no avail. I'll probably flash aokp in the morning to see if it holds out longer.
Click to expand...

Get a logcat of the radio and post it on pastebin. You should have wifi off just to make sure it tries to connect. Start the log at boot and let it go for at least 5 min.

adb logcat -b radio > radio.log
 
how did you fix the bluetooth? was it in the kernel? or in the rom itself? cause if its in the rom then i might be able to fix it in mine
 
tdm said:
Get a logcat of the radio and post it on pastebin. You should have wifi off just to make sure it tries to connect. Start the log at boot and let it go for at least 5 min.

adb logcat -b radio > radio.log
Click to expand...


Will do. Should have it for you in the couple hours.
 
  • Like
Reactions: tdm
Can someone running the CM9 build from TDM run GPS test and use the compass feature. I need to know if anyone else is getting reversed readings from north and south (I have 3 real compasses that all say it's backwards).
 
Neph81 said:
Can someone running the CM9 build from TDM run GPS test and use the compass feature. I need to know if anyone else is getting reversed readings from north and south (I have 3 real compasses that all say it's backwards).
Click to expand...

I'm running the CM9 beta 1 and its working right for me. What compass app are you using?
 
TDM, I found another reason why we're having so many issues and it's kernel script related.

init.qcom.sh

line 69 : target=`getprop ro.product.device`

On V4, build.prop called out our device as VS920. On V7, they changed it to i_vzw, but they never updated what their scripts are looking for.

line 74,75:
case $target in
"msm8660_surf" | "msm8660_csfb" | "VS920")

This one is for a something we don't need, but I found the same call in /system/etc/init.qcom.post_boot.sh

line 58,59
case "$target" in
"msm8660_surf" | "msm8660_csfb" | "VS920")

This deals with loading modules for power consumption and cpu settings. I'm sure there are more to be found too, but this is what I have so far.

Just thought you should know about this.
 
Great find neph I'll go through those scripts and replace all instances of VS920 that I find.
 
TDM:

digging thru more logs and came upon this.
[ 01-08 00:10:06.434 468:0x1e8 W/WiredAccessoryObserver ]

This kernel does not have wired headset support

Know anything about why that would be or if it's an easily fixable option?
 
Neph81 said:
TDM:

digging thru more logs and came upon this.
[ 01-08 00:10:06.434 468:0x1e8 W/WiredAccessoryObserver ]

This kernel does not have wired headset support

Know anything about why that would be or if it's an easily fixable option?
Click to expand...

Don't know.. never seen that before. But we should find out what it means. Thanks!
 
tdm, here's the link to the radio log. Sorry I didn't get it sooner. My wife was dragging me all over today and I haven't had time until now. I didn't get it right from bootup but I did start it soon thereafter. From what I can see, it's some kind of error from lteOnCdmaProductType. Of course, I don't really know much about this yet so I'm most likely wrong.
 
  • Like
Reactions: tdm
ortrigger said:
tdm, here's the link to the radio log. Sorry I didn't get it sooner. My wife was dragging me all over today and I haven't had time until now. I didn't get it right from bootup but I did start it soon thereafter. From what I can see, it's some kind of error from lteOnCdmaProductType. Of course, I don't really know much about this yet so I'm most likely wrong.
Click to expand...
Are you set to CDMA only in the network type menu? If it was LTE/CDMA i would expect to see some GSM commands being sent.

Edit: correction. I do see some GSM calls at the beginning, but then it looks like the data stack is crashing.
 
Ok, I'm out for the night. TDM, hopefully you can make some sense of this. It's as far as I seem to be able to get with fixing GPS.

Code: 
[ 12-15 22:53:19.090   438:0x388 E/LocSvc_eng ]

I/===> int loc_eng_set_position_mode(loc_eng_data_s_type&, LocPosMode&) line 583 



[ 12-15 22:53:19.090   438:0x389 D/LocSvc_adapter ]

loc_eng_set_position mode, client = -1234, interval = 1000, mode = 1





[ 12-15 22:53:19.090   438:0x389 E/LocSvc_api_rpc_glue ]

slot not available ioctl_type = RPC_LOC_IOCTL_SET_FIX_CRITERIA



[ 12-15 22:53:19.090   438:0x388 E/LocSvc_eng ]

I/===> int loc_eng_start(loc_eng_data_s_type&) line 444 



[ 12-15 22:53:19.090   438:0x389 E/LocSvc_api_rpc_glue ]

I/---> loc_start_fix line 422 -1234
 
Has anyone else noticed that when you close the notification drawer in an app that the screen flickers? I'm getting this in both CM9 and AOKP. sometimes when this happens the app closes. Not a force close ( or at least I don't get the pop up ) but just closes.
 
Lykarsis said:
Has anyone else noticed that when you close the notification drawer in an app that the screen flickers? I'm getting this in both CM9 and AOKP. sometimes when this happens the app closes. Not a force close ( or at least I don't get the pop up ) but just closes.
Click to expand...

I started having this screen flicker with eclipse alpha 3 and it was getting very bad. Now I only notice it when close the notification window and i too have it on aokp and cm9.

Someone who is having this issue needs to flash the v7 cab and report if it's happening on stock. I would do it but I don't have the internet to do it with right now.
 
Just an idea but I thought it would be awesome if someone could figure out how to get the 4.2 camera zip to work without gallery force closing. I don't really care about it being in cm9 so much as cm10 because I've tried it on both with three different versions and all have fc'd at the beginning
 
So if I understand the posts correctly, AOKP is working great with data, but CM9 has some glitches?
I only as because I need my phone to be 100% for work. I can handle some glitches, but I have to have data to get email 24/7.
 
MrB206 said:
So if I understand the posts correctly, AOKP is working great with data, but CM9 has some glitches?
I only as because I need my phone to be 100% for work. I can handle some glitches, but I have to have data to get email 24/7.
Click to expand...
As far as I can tell, both have data that can be finicky any time you reboot into recovery. I always keep data through regular reboots on both CM9 and AOKP and when I use recovery, cycling the radio on/off a few times always brings it back for me.
 
MrB206 said:
So if I understand the posts correctly, AOKP is working great with data, but CM9 has some glitches?
I only as because I need my phone to be 100% for work. I can handle some glitches, but I have to have data to get email 24/7.
Click to expand...

I've actually had better luck with data on CM9, although 1x seems stronger on AOKP. They're both temperamental with data, I just lose it less and find it easier to get back on CM9 (actually went back to PG's though). Best way to keep it that I've found is to never, never open the Mobile networks menu; just opening it seems to mess up mine! Sounds like you keep it on all the time so you may not have a problem, mine has been fine as long as I leave it on. And if I do lose it, dialing the *#*#4636#*#* and resetting it brings it right back. Sometimes just turning it off and back on (from the toggle, not the menu!) works too.
 
You must log in or register to reply here.
Back
Top Bottom