[T-Mobile, Samsung Galaxy SIII] 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:

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.

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 ----------

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.