[Q] what is Gsiff_daemon and why is it destroying my battery?

Search This thread
By:
Advanced…
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
Googling has left me empty handed, this thing is using 50%+ battery life always beating screen on time.
I'm rooted running stock and would prefer not to wipe to solve this.
Sent from my SGH-T999 using xda app-developers app
 
id_twin

id_twin

Senior Member
Nov 10, 2009
317
59
Denver, CO
I too have had the same issue with the infamous gsiff_daemon - Unfortunately there isn't a whole lot of information out there regarding this, so a restart and a prayer is all that you have. I will say though, after flashing the latest sonic rom for TMobile, I have yet to notice it, but it still may be to early to tell.

It is also mentioned in this forum here, http://www.neogaf.com/forum/showthread.php?p=39358508 , but from what I can tell, there doesn't appear to be a solution.
 
Last edited:
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
id_twin said:
I too have had the same issue with the infamous gsiff_daemon - Unfortunately there isn't a whole lot of information out there regarding this, so a restart and a prayer is all that you have. I will say though, after flashing the latest sonic rom for TMobile, I have yet to notice it, but it still may be to early to tell.

It is also mentioned in this forum here, http://www.neogaf.com/forum/showthread.php?p=39358508 , but from what I can tell, there doesn't appear to be a solution.
Click to expand...
Click to collapse

Lots of restarts with no luck, I find it hard to believe no one knows what this is.

Sent from my SGH-T999 using xda app-developers app
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
Just an indication of how insane this is, 45 minutes screen on, 52% system 26% screen. I have never seen anything like this.
Sent from my SGH-T999 using xda app-developers app
 
dasfiend

dasfiend

Senior Member
Aug 6, 2010
132
34
Gurnee, IL
I found this googling...not an answer but a start hopefully. (Link to where I found it)

Looking at the URL I wonder if it's something to do with all the tilting samsung seems seems to want us to do. Just spit-balling.



Code: 
+################################
 	 54	
+# Sensor Settings
 	 55	
+################################
 	 56	
+
 	 57	
+# Needs to be set explicitly based on sensor
 	 58	
+# There is no default value.
 	 59	
+#GYRO_BIAS_RANDOM_WALK=
 	 60	
+
 	 61	
+SENSOR_ACCEL_BATCHES_PER_SEC=2
 	 62	
+SENSOR_ACCEL_SAMPLES_PER_BATCH=5
 	 63	
+SENSOR_GYRO_BATCHES_PER_SEC=2
 	 64	
+SENSOR_GYRO_SAMPLES_PER_BATCH=5
 	 65	
+
 	 66	
+# Sensor Control Mode (0=AUTO, 1=FORCE_ON)
 	 67	
+SENSOR_CONTROL_MODE=0
 	 68	
+
 	 69	
+# Enable or Disable Sensors for GPS use (0=Enable, 1=Disable)
 	 70	
+SENSOR_USAGE=0
 	 71	
+
 	 72	
+# Choose GSIFF sensor provider (1=DSPS, 2=Android NDK)
 	 73	
+SENSOR_PROVIDER=1
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
dasfiend said:
I found this googling...not an answer but a start hopefully. (Link to where I found it)

Looking at the URL I wonder if it's something to do with all the tilting samsung seems seems to want us to do. Just spit-balling.



Code: 
+################################
  54
+# Sensor Settings
  55
+################################
  56
+
  57
+# Needs to be set explicitly based on sensor
  58
+# There is no default value.
  59
+#GYRO_BIAS_RANDOM_WALK=
  60
+
  61
+SENSOR_ACCEL_BATCHES_PER_SEC=2
  62
+SENSOR_ACCEL_SAMPLES_PER_BATCH=5
  63
+SENSOR_GYRO_BATCHES_PER_SEC=2
  64
+SENSOR_GYRO_SAMPLES_PER_BATCH=5
  65
+
  66
+# Sensor Control Mode (0=AUTO, 1=FORCE_ON)
  67
+SENSOR_CONTROL_MODE=0
  68
+
  69
+# Enable or Disable Sensors for GPS use (0=Enable, 1=Disable)
  70
+SENSOR_USAGE=0
  71
+
  72
+# Choose GSIFF sensor provider (1=DSPS, 2=Android NDK)
  73
+SENSOR_PROVIDER=1
Click to expand...
Click to collapse

I turned all that crap off trying to find whatever this is.

Sent from my SGH-T999 using xda app-developers app
 
dasfiend

dasfiend

Senior Member
Aug 6, 2010
132
34
Gurnee, IL
Yeah I'm just wondering if it's a bug of some kind in that subsystem.

You might try turning it *on*. You never know what kind of screw up there might be. For example, when it's set to off it might be stuck in a loop wherein it asks "can I use tilt?" "NO" "can I use tilt?" "NO". Vast oversimplification of course, but stuff like that does happen from time to time.

good luck!

edit: what carrier are you on? Maybe we can narrow it down a bit.

murdermonkey9000 said:
I turned all that crap off trying to find whatever this is.

Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
dasfiend said:
Yeah I'm just wondering if it's a bug of some kind in that subsystem.

You might try turning it *on*. You never know what kind of screw up there might be. For example, when it's set to off it might be stuck in a loop wherein it asks "can I use tilt?" "NO" "can I use tilt?" "NO". Vast oversimplification of course, but stuff like that does happen from time to time.

good luck!

edit: what carrier are you on? Maybe we can narrow it down a bit.
Click to expand...
Click to collapse

I'm on tmo. I had screen rotation enabled, I disabled it, then turned off the phone, I realized I had only been restarting it, and pulled the battery and held the power button down for 15 seconds (old laptop trick, don't know if it does the same thing on cells) and it seems to be gone. I'll leave it for a while and turn rotation back on and see if it goes haywire again.

Sent from my SGH-T999 using xda app-developers app
 
dasfiend

dasfiend

Senior Member
Aug 6, 2010
132
34
Gurnee, IL
I'm on AT&T and my GS3 arrives Monday so once I get it and use it for a bit we can compare and hopefully that will help narrow it down.

For example, if the AT&T version doesn't have the issue, maybe we can find you an AT&T rom and a tmo radio to flash or some such combo.



murdermonkey9000 said:
I'm on tmo. I had screen rotation enabled, I disabled it, then turned off the phone, I realized I had only been restarting it, and pulled the battery and held the power button down for 15 seconds (old laptop trick, don't know if it does the same thing on cells) and it seems to be gone. I'll leave it for a while and turn rotation back on and see if it goes haywire again.

Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
Thanks for narrowing it to the motion sensor , it seems to be gone, I saw it in the running apps list but it was at .01% I'm going to re enable screen rotation soon to try to reproduce the bug , then others who run into this issue can know where to start.

Sent from my SGH-T999 using xda app-developers app
 
T

TimeKillr

Member
Jun 29, 2012
14
0
Montreal
I'm the one who had the issue on that other forum, heh. :)

Basically, restarting the phone fixed it. I was able to narrow it down using betterbatterystats and such, and it hasn't come back since I rebooted.

I don't know what else to say.... sorry. It worked for me, but who knows.
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
TimeKillr said:
I'm the one who had the issue on that other forum, heh. :)

Basically, restarting the phone fixed it. I was able to narrow it down using betterbatterystats and such, and it hasn't come back since I rebooted.

I don't know what else to say.... sorry. It worked for me, but who knows.
Click to expand...
Click to collapse

But restarting didn't work for me. That it went away also isn't good enough, we need to reproduce it and find its cause so it can be fixed.

Sent from my SGH-T999 using xda app-developers app
 
G

ghost77

Senior Member
May 23, 2010
382
49
I observerd interesting things here are some.
Under "developer options" toggle -> show cpu usage

Then you can see what process is top most, gsiff will be second from top if it's running. Not sure if it has anything to do with motion sensor. If you restart phone gsiff should be gone, and toggling motion sense options will not bring it back. At least on my stock att rom.

When gsiff is ON, cpu will not toggle off second core, to me it looks like it gets stuck in some kind of mode. Benchmark scores will be lower especially easy to see on linpack multi thread test instead of ~200mflops you get 90ish, possibly indicating single core performance. But some things are better, ui seems more fluid, and media playback I can play HD 60FPS high bit rate videos. This is important as I'm media fanatic.

If gsiff is NOT RUNNING one cpu core will turn off and other clock down to 384mhz entering proper operation I assume, linpack will perform normally, cpu and gpu scores will be higher, but the bad thing is media playback ability will not reach its full potential say goodbye to 60FPS playback (this sucks for me) , my guess is, it is software problem during intense media playback cpu doesn't exit special conservative mode, probably keeps decoder clocked down.

I did find one way to trigger gsiff on, with "blade buddy" app from market under advanced settings hitting menu button and selecting apply - yes ui restart.

If anyone wants to experiment.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
ghost77 said:
I observerd interesting things here are some.
Under "developer options" toggle -> show cpu usage

Then you can see what process is top most, gsiff will be second from top if it's running. Not sure if it has anything to do with motion sensor. If you restart phone gsiff should be gone, and toggling motion sense options will not bring it back. At least on my stock att rom.

When gsiff is ON, cpu will not toggle off second core, to me it looks like it gets stuck in some kind of mode. Benchmark scores will be lower especially easy to see on linpack multi thread test instead of ~200mflops you get 90ish, possibly indicating single core performance. But some things are better, ui seems more fluid, and media playback I can play HD 60FPS high bit rate videos. This is important as I'm media fanatic.

If gsiff is NOT RUNNING one cpu core will turn off and other clock down to 384mhz entering proper operation I assume, linpack will perform normally, cpu and gpu scores will be higher, but the bad thing is media playback ability will not reach its full potential say goodbye to 60FPS playback (this sucks for me) , my guess is, it is software problem during intense media playback cpu doesn't exit special conservative mode, probably keeps decoder clocked down.

I did find one way to trigger gsiff on, with "blade buddy" app from market under advanced settings hitting menu button and selecting apply - yes ui restart.

If anyone wants to experiment.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
Click to expand...
Click to collapse
Interesting, although you say media playback is better, I assume you want more than 1 hour of it. This thing is really detrimental to usage when it's stuck on.



Sent from my SGH-T999 using xda app-developers app
 
G

ghost77

Senior Member
May 23, 2010
382
49
To me media playback is top priority,and I didn't notice major battery drain, if you really getting only 1 hour there might be more to it, you have tmobile version of the phone? , and mine is att there could be bigger software changes then people think.
One of them is clear if you reboot phone and still have Gsiff when I loose it, maybe one of tmobile build in apps trigger it?

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
I've noticed that right before gsiff_daemon goes crazy and starts destroying batteries, my launcher seems to die and when it reloads everything has been closed, but if I look at running processes gsiff_daemon is numero uno, every time I get this soft reboot (not sure what to call it) this happens, curious if anyone else has noticed the same thing.
Really hoping a dev can look into this, I bet this goes away on an aosp rom, stock did it and a rom based on stock did it and the adama kernel and the stock kernel both do it. Let me know if you experience the soft reboots or whatever the correct term may be.
Sent from my SGH-T999 using xda app-developers app
 
D

drothenberger

Senior Member
Feb 2, 2011
658
536
Kenmore, WA
In an effort to narrow down what gsiff_daemon actually does, I tried deleting it from /system/bin this evening. So far I have not found anything that doesn't work.

Based on this link I think is has something to do with GPS, but mine locks just fine: http://xdaforums.com/showthread.php?p=27976142

I'll report back if I find something that doesn't work.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 
Last edited:
id_twin

id_twin

Senior Member
Nov 10, 2009
317
59
Denver, CO
drothenberger said:
In an effort to narrow down what gsiff_daemon actually does, I tried deleting it from /system/bin this evening. Sorry far I have not found anything that doesn't work.

Based on this link I think is has something to do with GPS, but mine locks just fine: http://xdaforums.com/showthread.php?p=27976142

I'll report back if I find something that doesn't work.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
Click to expand...
Click to collapse

It's good to see people still working on this issue, as it was a problem for me when I first got my phone. Now, after restarting and flashing custom roms, I haven't had this issue. If it has something to do with the GPS, there may be a chance it has nothing to do with lock, but possibly on how apps call on the GPS for location services. I'm not sure what it does to be honest, but hopefully some of these kinks will be worked out when we start receiving the first round of updates.
 
M

murdermonkey9000

Senior Member
Apr 15, 2010
116
34
tacoma
In an effort to narrow down what gsiff_daemon actually does, I tried deleting it from /system/bin this evening. Sorry far I have not found anything that doesn't work.

Based on this link I think is has something to do with GPS, but mine locks just fine: http://xdaforums.com/showthread.php?p=27976142

I'll report back if I find something that doesn't work.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
Click to expand...
Click to collapse

7-11 06:51:27.881 E/Sensors ( 537): accelHandler 0.637524 9.136102 3.490591
07-11 06:51:28.041 E/Sensors ( 537): gyroHandler 0.014914 0.012783 -0.075634

Gsiff_daemon was going crazy and
Logcat captured these two lines hundreds of times, hopefully this is helpful.

Sent from my SGH-T999 using xda app-developers app
 
  • Like
Reactions: drothenberger
J

jmilacek

Member
Dec 26, 2009
37
1
murdermonkey9000 said:
7-11 06:51:27.881 E/Sensors ( 537): accelHandler 0.637524 9.136102 3.490591
07-11 06:51:28.041 E/Sensors ( 537): gyroHandler 0.014914 0.012783 -0.075634

Gsiff_daemon was going crazy and
Logcat captured these two lines hundreds of times, hopefully this is helpful.

Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse

These are gyroscope notifications. So this has something to do with detecting movement of the phone. The three numbers after each are likely spacial coordinates (x, y, z variables).

Like others have said this is likely a bug (or perhaps not a bug) in Samsung's method of detecting how you are moving your phone around. Could have to do with auto-rotation as well.

Either way it seems to only be affecting people intermittently so I would call it an actual, unintended issue that needs to be addressed.
 
You must log in or register to reply here.

Similar threads

TGA_Gunnman
[Tools] Odin Version 3.04 - 3.07 and GS3 Drivers for Windows
Replies
12
Views
718K
L
lonewolf65
M
Sim Unlock - works all *ALL* GSM GS3 and Note 2
Replies
499
Views
324K
S
ShartedMcPants
uoY_redruM
  • Poll
[ROM][GSM]{11.28.2012} Team Sonic Presents FreeGS3 R7.1.1 "Resurrection"
Replies
5K
Views
562K
M
muhammada1257
T
My phone dies while using it while plugged into wall charger? Is this normal?
Replies
8
Views
81K
M
mammai
DocHoliday77
[Baseband] ALL T999, T999L, T999V, T999N Modems! w/ MAP and Data Tweaks!
Replies
975
Views
380K
H
hasan.sy

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 7
    ssewk2x
    ssewk2x
    So, it's been a long time, and I've upgraded my Note 2 to a KitKat ROM.

    And .. gsiff_daemon still goes run-away after a soft-reboot. I did find a way to reliably reproduce the behavior, too. I installed the XPosed framework, and using its "soft reboot" option will make gsiff_daemon lose its sh** every time. I've also found that disabling the service negatively impacts some of the sensors (especially the compass).

    So, I've started trying a little something different. I wrote a script to be placed under /etc/init.d (or under /data/local/userinit.d if your phone is CM based). It starts a background process that checks gsiff_daemon's CPU usage and kills it if it's using more than 10% CPU. The daemon normally always shows 0%, and once killed, the system re-starts it immediately. The net effect is that if gsiff_daemon is over 10% for more than a minute, my script/service will automatically clean it up.

    It would still be draining your batter during that minute, but hey .. a minute is better than hours, right? Plus, now you don't have to think about it.

    The source for the script can be found here: https://github.com/Efpophis/Efpophi...e7796798a31b/data/local/userinit.d/91gsif_mon

    You've got to install it under either /etc/init.d or /data/local/userinit.d and make it executable.

    Code: 
    adb push 91gsif_mon /data/local/userinit.d
adb shell chmod 755 /data/local/userinit.d/91gsif_mon

    Reboot your phone for it to take effect.

    It's still a butt-ugly-hack, so if anyone has anything better, feel free to share.
    View
    4
    J
    J M L
    I tried the experiment of removing gsiff_daemon, and that "solves" the problem. If it isn't running, then it can't run away. I'm an old Unix guy, so I did this at the command line, but feel free to use your favorite root file manager to do this. You will need root. I remounted /system as rw, moved /system/bin/gsiff_daemon to /system/bin/gsiff_daemon.not and then rebooted. gsiff_daemon did not start, but otherwise there weren't any problems or errors. Forcing a hotboot didn't cause any problems. I have no idea if having the daemon not run will cause problems down the road, that will take more time. I moved it back, rebooted, and it started without issue.

    The only obvious effect I saw was a decrease in GPS accuracy. This might just be a coincidence. Without gsiff_daemon, I could only get a GPS lock with a 45ft accuracy. Enabling gsiff_daemon my accuracy improved to 9ft. This is all sitting on the ground floor of my two story house, so the view of the sky isn't exactly clear, and I'm very impressed the S3 can get a GPS lock at all.

    So, if you're having lots of gsiff_daemon problems, then you can try this. As there's no real fix for gsiff_daemon, it is probably best to figure out what is causing frequent hotboot/crashes. I do not know if any log is kept as to what could have caused the crash. I generally get about one per week, and I just make do with watchdog alerting me.
    View
    4
    J
    J M L
    Progress! Well, not in fixing the issue, but in recreating it. After investigating a bit, I found that a "hot boot" can be be forced by killing the system_server process. To do this, the command is:
    Code: 
    pkill -TERM -f system_server
    .
    That sends the a TERM signal to the system_server command, which causes the android shell to restart. At least from how the phone behaves, this appears to be what is happening when the phone "hot boots." The screen resets, the radios reset, the sdcard is rescanned, just as if things had booted normally. With the one important exception, that now gsiff_daemon runs away and uses as much processor as it can get, draining the battery, making the phone hot, screwing up benchmarks, etc. Killing the gsiff_daemon causes it to restart and behave appropriately.

    So, I think all of the talk of adblock, linkedin, root, etc. is just superstition. Something causes system_server to die. Whether that is a watchdog which has found something to be wrong and killed it, or if a bug in system_server itself causes it to die, I don't know. Once it dies, it restarts, which trips a bug in gsiff_daemon (or possibly a chain of bugs) which causes gsiff_daemon to run away. If there is a specific app or behavior on your phone which causes system_server to die (a "hot boot") fixing that behavior will reduce your problems, though the root problem with gsiff_daemon remains.

    This information does give people the ability to test any hypothesis they have about motion settings or anything else causing the problem. Force a hot boot with each of your settings in place, while "Show CPU usage" is enabled, and you should be able to see in 5 minutes or so if the settings has any effect on gsiff_daemon.

    As for long term solutions, that's really beyond me. gsiff_daemon doesn't seem to be part of the open source release from Samsung, so it's up to them to fix it. My plan is to wait for CM10 to become stable enough to be truly usable. At this point I'm stuck with watchdog alerting me to the runaway process, and then manually killing it.

    If anybody is curious, these appear to be the interesting bits from a logcat I captured during a hot boot cycle. I am not qualified to interpret what is happening.
    Code: 
    E/gpsone_dmn(15513): gpsone_glue_pipeget:42] /data/misc/gsiff_ctrl_q, mode = 2
E/gpsone_dmn(15513): gpsone_glue_pipeget:55] fd = 7, /data/misc/gsiff_ctrl_q
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Initializing Android NDK
E/gsiff_sp_and_ndk(15513): D/sp_and_ndk_init: Found 15 sensors.
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL rotation vector Vendor: Invensense Type: 11 Min Delay: 10000 us handle: 0x01F886A0
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL linear accel Vendor: Invensense Type: 10 Min Delay: 10000 us handle: 0x01F886CC
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL gravity Vendor: Invensense Type: 9 Min Delay: 10000 us handle: 0x01F886F8
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL Gyro Vendor: Invensense Type: 4 Min Delay: 10000 us handle: 0x01F88724
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL accel Vendor: Invensense Type: 1 Min Delay: 10000 us handle: 0x01F88750
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL magnetic field Vendor: Invensense Type: 2 Min Delay: 10000 us handle: 0x01F8877C
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: MPL Orientation (android deprecated format) Vendor: Invensense Type: 3 Min Delay: 10000 us handle: 0x01F887A8
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: GP2A Light Sensor Vendor: Sharp Type: 5 Min Delay: 0 us handle: 0x01F887D4
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: GP2A Proximity Sensor Vendor: Sharp Type: 8 Min Delay: 0 us handle: 0x01F88800
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: BMP180 Pressure Sensor Vendor: Bosch Type: 6 Min Delay: 15000 us handle: 0x01F8882C
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: Rotation Vector Sensor Vendor: Google Inc. Type: 11 Min Delay: 10000 us handle: 0x01F88858
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: Gravity Sensor Vendor: Google Inc. Type: 9 Min Delay: 10000 us handle: 0x01F88884
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: Linear Acceleration Sensor Vendor: Google Inc. Type: 10 Min Delay: 10000 us handle: 0x01F888B0
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: Orientation Sensor Vendor: Google Inc. Type: 3 Min Delay: 10000 us handle: 0x01F888DC
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Found Sensor Name: Corrected Gyroscope Sensor Vendor: Google Inc. Type: 4 Min Delay: 10000 us handle: 0x01F88908
E/gsiff_sp_and_ndk(15513): I/sp_and_ndk_init: Starting sensor polling thread
E/gpsone_dmn(15513): gpsone_launch_thelper:267] 0x1f879d4 call pthread_create
E/gpsone_dmn(15513): gpsone_launch_thelper:276] 0x1f879d4 pthread_create done
E/gsiff_sp_and_ndk(15513): D/sp_and_ndk_polling_task_init: Initializing polling task!
E/gpsone_dmn(15513): thelper_signal_ready:149] 0x1f879d4
E/gpsone_dmn(15513): gpsone_launch_thelper:280] 0x1f879d4 pthread ready
E/gsiff_dmn(15513): I/gsiff_dmn_init: Sensor Provider initialized on attempt 0!
E/LocSvc_api_v02(15513): I/---> locClientOpen line 1594 loc client open
E/QMI_FW  (15513): qmi_qmux_if_pwr_up_init failed! rc=-1
D/QMI_FW  (15513): QCCI: xport_open[13]: max_rx_len=0
D/QMI_FW  (15513): QCCI: Lookup: type=16 instance=2
D/QMI_FW  (15513): QCCI: QMUXD: xport_open[16]: max_rx_len=0
D/QMI_FW  (15513): QCCI: QMUXD: xport_open: qmi_qmux_if_pwr_up_init
D/QMI_FW  (15513): QCCI: reader_thread: wakeup_pipe[0]=1 ch=a
E/LocSvc_api_v02(15513): I/---> locClientSendReq line 1796 QMI_LOC_REG_EVENTS_REQ_V02
E/LocSvc_api_v02(15513): D/locClientOpen:1655]: returning handle = 0x1f89250, user_handle=0x1f89278, status = 0
E/gsiff_dmn(15513): I/gsiff_loc_api_open: locClientOpen 0 33067600
E/gsiff_dmn(15513): I/gsiff_dmn_init: Loc Api initialized on attempt 0!
E/gsiff_dmn(15513): I/main: Mounted state default = 1 and selection = 1
E/gpsone_dmn(15513): gpsone_launch_thelper:267] 0x1f86730 call pthread_create
E/gpsone_dmn(15513): gpsone_launch_thelper:276] 0x1f86730 pthread_create done
E/gpsone_dmn(15513): thelper_signal_ready:149] 0x1f86730
E/gpsone_dmn(15513): gpsone_launch_thelper:280] 0x1f86730 pthread ready
E/gpsone_dmn(15513): gpsone_launch_thelper:267] 0x1f86754 call pthread_create
E/gpsone_dmn(15513): gpsone_launch_thelper:276] 0x1f86754 pthread_create done
E/gpsone_dmn(15513): gpsone_glue_piperead:144] fd = 7, buf = 0x41eebb68, size = 4
E/gpsone_dmn(15513): thelper_signal_ready:149] 0x1f86754
E/gpsone_dmn(15513): gpsone_launch_thelper:280] 0x1f86754 pthread ready
E/gpsone_dmn(15513): gpsone_join_thelper:331] 0x1f86730
D/QMI_FW  (15513): QCCI: reader_thread: wakeup_pipe[0]=1 ch=d
D/QMI_FW  (15513): QCCI: reader_thread exiting
D/QMI_FW  (15513): QCCI: Close[13]
D/QMI_FW  (15513): QCCI: Lookup: type=16 instance=2
D/QMI_FW  (15513): QCCI: QMUXD: xport_lookup: qmi_qmux_if_get_version_list
D/QMI_FW  (15513): QCCI: Lookup: type=16 instance=2
D/QMI_FW  (15513): QCCI: QMUXD: xport_lookup: qmi_qmux_if_get_version_list
D/QMI_FW  (15513): QCCI: xport_open[13]: max_rx_len=2248
D/QMI_FW  (15513): QCCI: Lookup: type=16 instance=2
D/QMI_FW  (15513): QCCI: QMUXD: xport_lookup: qmi_qmux_if_get_version_list
D/QMI_FW  (15513): QCCI: Lookup: type=16 instance=2
D/QMI_FW  (15513): QCCI: QMUXD: xport_lookup: qmi_qmux_if_get_version_list
D/QMI_FW  (15513): QCCI: QMI_CCI_TX: cntl_flag - 00, txn_id - 0001, msg_id - 0021, msg_len - 000b
D/QMI_FW  (15513): QCCI: Sent[13]: 18 bytes to port 3072
D/QMI_FW  (15513): QCCI: reader_thread: Received 14 bytes from 13
D/QMI_FW  (15513): QCCI: QMI_CCI_RX: cntl_flag - 02, txn_id - 0001, msg_id - 0021, msg_len - 0007
D/QMI_FW  (15513): QCCI: reader_thread: wakeup_pipe[0]=1 ch=a


    ---------- Post added at 01:54 PM ---------- Previous post was at 01:52 PM ----------
    J M L said:
    I AM using adfree, and I get this problem. I will revert adfree, reboot, and then see if it comes back.

    If somebody knows of a way to induce a hot boot, then it would be faster to test this. I can often go days between problems...
    Click to expand...
    Click to collapse

    Now that I can recreate the problem at will, gsiff_daemon runs away whether I have adblock (with a hosts file) enabled or not. Perhaps having an adblock hosts file causes more hot boots, but gsiff_daemon does not care about your hosts file one way or another.
    View
    3
    J
    J M L
    I have a theory for working around this problem, but I don't at the moment know how to implement it. Perhaps somebody who is familiar with ROM hacking will know how. I'll have to read some stuff before I can do it, and that might take a while. Anyway:

    When system_server, surfacefinger, etc. die, one of the consequences is that a process called zygote is restarted. When zygote restarts, a bunch of other things also restart. Adding gsiff_daemon to the list of things that restart with zygote might fix the problem. Doing this involves editing init.rc, which should be easy, but the init.rc that is actually used at boot time is extracted from an image to the root directory. I do not know how to extract and repack the image (if ICS works this way).

    gsiff_daemon itself is started from init.sensor.rc and is called the "GNSS/Sensor interface daemon". I suppose it has something to do with positioning http://en.m.wikipedia.org/wiki/GNSS_augmentation#_
    View
    2
    T
    TerraOne
    Gsiff directly spotted on replacement phone

    But still no hotboot or runaway processing and battery drain.

    Today I went back to the area around which the hotboot and runaway gsiff_daemon process happened, leaving on CPU usage so I could glance at it regularly while grocery shopping.

    Mid-way through shopping, I took the sleeping phone out of my pocket, home-buttoned to turn on the screen, and there it was: gsiff_daemon second or third from the top.

    BUT, the phone wasn't hot and the battery wasn't draining at 1% per minute like my last phone. Also, gsiff disappeared about 1-2 seconds after the screen came on and wasn't seen again the rest of the day after leaving the area.

    So far, signs point to this being something that:

    1) Is often triggered while the screen is off
    2) Is often triggered while moving between areas/towers
    2) Is mobile-data-related in some way, rather than wifi-related (as some report having wifi disabled when their gsiff-runaway happens)
    3) The runaway gsiff - different from gsiff merely being present in the CPU stats - is triggered by something app/widget related that we are adding onto the phone that keeps gsiff stuck in a processing loop rather than disengaging.

    Whatever #3 may be, if it is a valid suspicion, I haven't added it onto the phone yet because gsiff_daemon, while activating in the wild when I'm moving between areas with the screen off, is not running-away with the processor nor draining the battery. In fact, I'm getting about 24 hours on my battery now, whereas I was getting about 5 hours on my previous phone thanks to gsiff_runaway.

    I think we should list our addon apps and focus on the ones we all have installed, then methodically experiment with removing them. As the runaway-gsiff isn't happening on my replacement phone, which doesn't have many apps on it yet intentionally, I think it would be worthwhile for me to add them one-by-one, one every couple of days or so, and see after which app a runaway occurs. If it's one we all have on our phones, it'll make a pretty good case for it being the culprit for causing a triggering of the runaway. Everyone removing it and not having gsiff runaways anymore would confirm it.

    That's not to say there isn't a fundamental bug in either Android or the S3 that an app merely exposes. That could be the case, but we won't know until we find the actual instigator and see how it, specifically, is interacting with the phone's OS and components like the mobile data radio or GPS or Motion.

    For starters, does anyone here experiencing gsiff-runaways:

    ~NOT have a clock/weather widget installed on a home screen with or without weather updates active?
    ~NOT have Facebook app installed?

    If there are any other apps that feel suspect to you, that have crashed a lot or that you have been using just before hotboot/runaways, or ones you have seen prominently in Battery/Watchdog/etc monitoring stats, please list them so we can narrow down the most common likenesses between all the runaway-occurring phones.
    View

New posts