Closed Bug 1221228 Opened 8 years ago Closed 8 years ago

Android 6.0 devices (eg Nexus 5X/6P) reboot/restart or hang when playing audio/video

Categories

(Firefox for Android Graveyard :: Audio/Video, defect)

Product:
Firefox for Android Graveyard
Component:
Audio/Video
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox42+ verified, firefox43 verified, firefox44 fixed, firefox45 verified, b2g-v2.5 fixed, fennec42+)

Status:
VERIFIED FIXED
Milestone:
Firefox 45
Tracking Flags:
Tracking Status
firefox42 + verified
firefox43 --- verified
firefox44 --- fixed
firefox45 --- verified
b2g-v2.5 --- fixed
fennec 42+ ---

People

(Reporter: snorp, Assigned: snorp)

References

(
URL
)

Details

Attachments

(7 files, 1 obsolete file)

dmesg output during a hang
63.08 KB, text/plain
Details
nexus5_logs.zip
127.20 KB, application/zip
Details
userspace hang traces
154.05 KB, text/plain
Details
More userspace traces, this time it includes Fennec (org.mozilla.fennec_snorp)
306.64 KB, text/plain
Details
kernel stack traces from fennec + all blocked tasks during hang
288.29 KB, text/plain
Details
Work around busted OpenSL causing hangs/reboots on Android
1.03 KB, patch
padenot
: review+
Sylvestre
: approval-mozilla-aurora+
Sylvestre
: approval-mozilla-beta+
Sylvestre
: approval-mozilla-release+
Details | Diff | Splinter Review
temporary patch - Partially revert AudioTrack to android v5.5.1
2.16 KB, patch
Details | Diff | Splinter Review 
At least it does on mine. Nightly. Seems pretty easy to repro.
So far I have a 100% reproduction rate by playing the video on this page: https://gma.yahoo.com/video-shows-taco-bell-execs-alleged-drunk-attack-061200233--abc-news-topstories.html#

Logcat didn't show anything interesting before the reboot.
With a local build it doesn't crash, but instead freezes the entire device. Logcat shows:

11-03 13:29:32.144 14239 14239 D GeckoBrowserApp: BrowserApp.onTabChanged: 0: AUDIO_PLAYING_CHANGE
11-03 13:29:32.152  3266  5493 D audio_hw_primary: select_devices: out_snd_device(2: speaker) in_snd_device(0: none)
11-03 13:29:32.152  3266  5493 D msm8974_platform: platform_send_audio_calibration: sending audio calibration for snd_device(2) acdb_id(15)
11-03 13:29:32.152  3266  5493 I soundtrigger: audio_extn_sound_trigger_update_device_status: device 0x2 of type 0 for Event 1
11-03 13:29:33.779  4404  9881 D NetlinkSocketObserver: NeighborEvent{elapsedMs=1060170, 192.168.1.1, [AC220B880DCA], RTM_NEWNEIGH, NUD_REACHABLE}
11-03 13:29:36.078 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:37.079 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:38.079 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:39.080 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:40.081 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:41.081 13651 13651 W Atfwd_Sendcmd: AtCmdFwd service not published, waiting... retryCnt : 3
11-03 13:29:56.082 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:57.082 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:58.083 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:59.083 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:29:59.649  4404  5546 D ConnectivityService: notifyType CAP_CHANGED for NetworkAgentInfo [WIFI () - 102]
11-03 13:30:00.084 13651 13651 I ServiceManager: Waiting for service AtCmdFwd...
11-03 13:30:01.023  4404  4430 I ActivityManager: Start proc 14464:com.google.android.deskclock/u0a66 for broadcast com.google.android.deskclock/com.android.alarmclock.DigitalAppWidgetProvider
11-03 13:30:01.084 13651 13651 W Atfwd_Sendcmd: AtCmdFwd service not published, waiting... retryCnt : 4
11-03 13:30:02.659  4404  5546 D ConnectivityService: notifyType CAP_CHANGED for NetworkAgentInfo [WIFI () - 102]
11-03 13:30:04.881  4404  5544 D WifiStateMachine: starting scan for "Willcox"WPA_PSK with 5680,2437
11-03 13:30:05.106  4404  5544 D WifiStateMachine: shouldSwitchNetwork  txSuccessRate=8.08 rxSuccessRate=5.75 delta 999 -> 993
11-03 13:30:05.107  4404  5544 D WifiStateMachine: CMD_AUTO_ROAM sup state CompletedState my state ConnectedState nid=0 config "Willcox"WPA_PSK roam=1 to any targetRoamBSSID any
11-03 13:30:05.107  4404  5544 D WifiStateMachine: AUTO_ROAM nothing to do
11-03 13:30:16.173  8014  8014 I clatd   : Detecting NAT64 prefix from DNS...
11-03 13:30:16.176  8014  8014 E clatd   : plat_prefix/dns(ipv4only.arpa) status = 7/No address associated with hostname
11-03 13:30:16.176  8014  8014 W clatd   : dns64_detection -- error, sleeping for 120 seconds
11-03 13:30:21.490  4404  9881 D NetlinkSocketObserver: NeighborEvent{elapsedMs=1107880, 192.168.1.1, [AC220B880DCA], RTM_NEWNEIGH, NUD_STALE}
11-03 13:30:26.790  4404  9881 D NetlinkSocketObserver: NeighborEvent{elapsedMs=1113180, 192.168.1.1, [AC220B880DCA], RTM_NEWNEIGH, NUD_REACHABLE}
11-03 13:30:41.351  4404  6314 I Process : Sending signal. PID: 4404 SIG: 3
11-03 13:30:41.352  4404  4408 I art     : Thread[2,tid=4408,WaitingInMainSignalCatcherLoop,Thread*=0x7f85d43000,peer=0x12c010a0,"Signal Catcher"]: reacting to signal 3
11-03 13:30:46.419  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:30:46.420  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:30:51.480  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:30:51.480  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:30:56.510  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:30:56.511  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:30:56.603 14239 14256 I GeckoWebappsUpdateTimer: periodic check for webapp updates
11-03 13:30:56.603 14239 14256 D GeckoWebappManager: checkForUpdates
11-03 13:30:56.614 14239 14256 D GeckoWebapps: Saving /data/user/0/org.mozilla.fennec_snorp/files/mozilla/webapps/webapps.json
11-03 13:30:56.623 14239 14256 D GeckoWebapps: Success saving /data/user/0/org.mozilla.fennec_snorp/files/mozilla/webapps/webapps.json
11-03 13:30:56.626 14239 14256 D GeckoWebapps: Saving /data/user/0/org.mozilla.fennec_snorp/files/mozilla/webapps/webapps.json
11-03 13:30:56.633 14239 14256 D GeckoWebapps: Success saving /data/user/0/org.mozilla.fennec_snorp/files/mozilla/webapps/webapps.json
11-03 13:31:01.558  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:31:01.559  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:31:06.996  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:31:06.996  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:31:12.313  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:31:12.313  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:31:17.341  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:31:17.341  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.
11-03 13:31:22.509  4404  4408 W libbacktrace: bool ThreadEntry::Wait(int): pthread_cond_timedwait for value 1 failed: Connection timed out
11-03 13:31:22.509  4404  4408 E libbacktrace: bool BacktraceCurrent::UnwindThread(size_t): Timed out waiting for signal handler to get ucontext data.


It looks like the AtCmdFwd service is blocked, or something, and that's hosing system_server.
AtCmdFwd is some kind of qualcomm-specific service. I'm wondering if my device is somehow just hosed.
tracking-fennec: --- → ?
Well this isn't very nice...

#0  0xf6f9e088 in __reboot () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libc.so
#1  0xf71c4134 in systemTime () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libutils.so
#2  0xf6648bd8 in android::AudioTrack::processAudioBuffer() () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libmedia.so
#3  0xf6649a6c in android::AudioTrack::AudioTrackThread::threadLoop() () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libmedia.so
#4  0xf71c4072 in android::Thread::_threadLoop(void*) () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libutils.so
#5  0xf6f9c814 in __pthread_start(void*) () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libc.so
#6  0xf6f76f76 in __start_thread () from /Users/snorp/source/jimdb-arm/lib/84B5T15A15005343/system/lib/libc.so
#7  0x00000000 in ?? ()
Have a similar problem running  beta although its not 100% reproducible with above video
Forgot to mention I am using nexus 5x
I think I might be hitting the same crash on my Nexus 5 (Can't test with the video from comment 1 because of a geo restriction), device just reboots sometimes when playing video.
Apparently AtCmdFwd is some kind of Wifi display forwarding service. Not sure why I seem to get so many messages about it while playing video. If I disable Wifi I don't get any messages, but the Yahoo video still reboots and/or hangs. Red herring.
Nevermind, I do still see the AtCmdFwd messages even with wifi off...might still be related?
Sotaro, do we still have contacts at QC that could help on that?
'adb bugreport' shows some interesting stuff in the last kmsg

[46941.303851] msm_vidc: info: Closed video instance: ffffffc021d34000
[46941.601653] msm_vidc: info: Opening video instance: ffffffc0023be000, 1
[46941.947502] msm8994_quat_mi2s_snd_startup: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b893a410  substream = subdevice #0  stream = 1 bit width =6 sample rate =48000
[46941.951550] afe_get_cal_topology_id: [AFE_TOPOLOGY_CAL] not initialized for this port 4103
[46941.961241] msm8994_quat_mi2s_snd_startup: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b893a410  substream = subdevice #0  stream = 0 bit width =6 sample rate =48000
[46941.962594] afe_get_cal_topology_id: [AFE_TOPOLOGY_CAL] not initialized for this port 4102
[46958.523245] msm_vidc: info: Closed video instance: ffffffc0023be000
[46958.704096] msm8994_quat_mi2s_snd_shutdown: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b893a410  substream = subdevice #0  stream = 0
[46958.718849] msm8994_quat_mi2s_snd_shutdown: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b893a410  substream = subdevice #0  stream = 1
[46958.719758] msm8994_quat_mi2s_snd_shutdown Quaternary MI2S Clock is Disabled
[46958.721100] max98925_left_en_put: spk&rcver switch gpio had pulled down[46958.804060] msm_vidc: info: Opening video instance: ffffffc094fa6000, 1
[46959.023967] msm8994_quat_mi2s_snd_startup: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b893a410  substream = subdevice #0  stream = 1 bit width =6 sample rate =48000
[46965.831599] Watchdog bark! Now = 46965.831593
[46965.831615] Watchdog last pet at 46954.773015
[46965.831623] cpu alive mask from last pet 0-7
[46965.831658] Causing a watchdog bite!
[46965.832668] Wdog - STS: 0x1, CTL: 0x1, BARK TIME: 0x57fdf, BITE TIME: 0x1[46965.832678] Kernel panic - not syncing: Failed to cause a watchdog bite! - Falling back to kernel panic!
[46965.832689] CPU: 0 PID: 17228 Comm: AudioTrack Tainted: G        W    3.10.73-gcf36678 #1
[46965.832694] Call trace:
[46965.832710] [<ffffffc000206b88>] dump_backtrace+0x0/0x250
[46965.832718] [<ffffffc000206de8>] show_stack+0x10/0x1c
[46965.832730] [<ffffffc000c907e4>] dump_stack+0x1c/0x28
[46965.832737] [<ffffffc000c8efec>] panic+0x14c/0x300
[46965.832747] [<ffffffc000505150>] wdog_bark_handler+0xd8/0xdc
[46965.832757] [<ffffffc00026ace8>] handle_irq_event_percpu+0xb4/0x244
[46965.832764] [<ffffffc00026aec0>] handle_irq_event+0x48/0x78
[46965.832773] [<ffffffc00026db8c>] handle_fasteoi_irq+0xc0/0x128
[46965.832780] [<ffffffc00026a530>] generic_handle_irq+0x28/0x3c
[46965.832788] [<ffffffc0002040d8>] handle_IRQ+0x84/0xa8
[46965.832795] [<ffffffc0002006d8>] gic_handle_irq+0x54/0x84
[46965.832801] Exception stack(0xffffffc012d3feb0 to 0xffffffc012d3ffd0)
[46965.832808] fea0:                                     00400000 00000000 00000000 00000000
[46965.832815] fec0: ffffffff ffffffff f757c6aa 00000000 bfd9c6b0 00000000 c0aa7888 00000000
[46965.832823] fee0: 00000002 00000000 bfd9c6b4 00000000 bfd9c6b0 00000000 f6a43910 00000000
[46965.832830] ff00: ffffff92 00000000 00000000 00000000 bf7cacb0 00000000 00000000 00000000
[46965.832838] ff20: c0aa7860 00000000 00000000 00000000 f7587c28 00000000 c0aa7828 00000000
[46965.832845] ff40: f6a02ee1 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[46965.832853] ff60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[46965.832861] ff80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[46965.832868] ffa0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[46965.832874] ffc0: 00000000 00000000 00000000 00000000
[46965.832887] CPU4: stopping
[46965.832905]
[46965.832924] CPU: 4 PID: 16939 Comm: Gecko Tainted: G        W    3.10.73-gcf36678 #1
[46965.832941] task: ffffffc048ad60c0 ti: ffffffc087a74000 task.ti: ffffffc087a74000
[46965.832954] PC is at 0xd77eb2c6
[46965.832967] LR is at 0xf6b
Alright, so I think the watchdog bite means it has detected that the device is hung, so it panics to cause a reboot. I just got it to hang without triggering the watchdog, and there is some interesting stuff. It looks like the kernel gets hung up waiting on the decoder to do some stuff. I'm not sure why we would be triggering this and other apps wouldn't....
comment #10
Flags: needinfo?(sotaro.ikeda.g)
Now in another instance I get some kind of GPU deadlock?

[ 4368.612169] msm_vidc: info: Opening video instance: ffffffc0ba374000, 1
[ 4368.804081] msm8994_quat_mi2s_snd_startup: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b8a33410  substream = subdevice #0  stream = 1 bit width =6 sample rate =48000  
[ 4369.353773] afe_get_cal_topology_id: [AFE_TOPOLOGY_CAL] not initialized for this port 4103
[ 4369.365721] msm8994_quat_mi2s_snd_startup: dai name qcom,msm-dai-q6-mi2s-quat.210 ffffffc0b8a33410  substream = subdevice #0  stream = 0 bit width =6 sample rate =48000  
[ 4369.367352] afe_get_cal_topology_id: [AFE_TOPOLOGY_CAL] not initialized for this port 4102
[ 4391.046292] kgsl kgsl-3d0: kgsl: possible gpu syncpoint deadlock for context 10 timestamp 0
[ 4391.046315] kgsl kgsl-3d0:   context[10]: queue=4700, submit=4699, start=4699, retire=4699
[ 4391.046323] kgsl kgsl-3d0:   possible deadlock. Context 10 might be blocked for itself
[ 4391.046335] kgsl kgsl-3d0:   context[10]: submit times: 5.354 5.392 5.548 5.393 5.345 5.308 5.375 
[ 4391.046343] [ffffffc091f9f700] SurfaceView:0: active
[ 4391.046347] waiters:
[ 4391.046363]  kgsl_sync_callback+0x0/0x38
[ 4391.046368] syncpoints:
[ 4391.046374]   kgsl-3d0_surfaceflinger(380)-surfaceflinger(380)-2_pt signaled@4386.030689: 41 / 41 queued:41 retired:41
[ 4391.046396]   kgsl-3d0_la.fennec_snorp(19650)-Thread-173(19777)-10_pt signaled@4386.030689: 4697 / 4699 queued:4700 retired:4699
[ 4391.046413]   mdss_fb_0_pt active: 13688 / 13687
[ 4391.046428] kgsl kgsl-3d0: --gpu syncpoint deadlock print end--
According to the angler-kernel repo[0] there have been quite a few updates since the one installed on my device (3.10.73-gcf36678). I think I'll try to install a newer kernel.


[0] https://android.googlesource.com/device/huawei/angler-kernel/
I updated my kernel to the latest one in the angler-kernel repo, 3.10.73-g549e459, and I can still reproduce the issue. Ugh.
tracking-fennec: ? → 42+
I just ordered nexus6P yesterday. The phone seems to be in Hongkong now in delivery tracking system.
(In reply to [:fabrice] Fabrice Desré from comment #10)
> Sotaro, do we still have contacts at QC that could help on that?

:diego, might still respond to a question. But they did not spend time if the bug does not related to fxos mobile products and basically we needed to analyze it.
(In reply to Alex from comment #7)
> I think I might be hitting the same crash on my Nexus 5 (Can't test with the
> video from comment 1 because of a geo restriction), device just reboots
> sometimes when playing video.

I also cannot test the video because of geo restriction.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Ka-Hing Cheung from comment #6)
> Forgot to mention I am using nexus 5x

It might be a problem that happen both nexus6p and nexus5x. From it, it might be a problem that commonly happen on new qualcomm 64bit chipset.
  https://en.wikipedia.org/wiki/Nexus_6P
  https://en.wikipedia.org/wiki/Nexus_5X
Yes can confirm that this is an issue for the 5x as well. Snorp ashed me to check Yahoo video on the 5x, the first video I found reboots the device every time. https://screen.yahoo.com/popular/star-wars-lego-destruction-star-140000599.html
My Nexus 5 (not 5x) crashed on that video fairly quickly.

Before it crashed the video was jumpy, started playing a second or so into the video, then froze and jumped back to the start, then crashed.
(In reply to Alex from comment #23)
> My Nexus 5 (not 5x) crashed on that video fairly quickly.
> 
> Before it crashed the video was jumpy, started playing a second or so into
> the video, then froze and jumped back to the start, then crashed.

Alex, can you take logcat and dmesg log?
Attached file nexus5_logs.zip — 
Sure, I'm not sure how useful dmesg will be, since I can't find a way to tail its output, but I did get the output of logcat and last_kmsg, and they give a bit more info (Included everything though)
Thanks Alex! From last_kmsg.log in attachment 8684033 [details], problem seems to happen around SurfaceView fence handling.

[  420.640043] fence timeout on [c3604280] after 10000ms
[  420.640430] objs:
[  420.640433] --------------
>>> snip
[  420.658320] [c3604280] SurfaceView:0: active
[  420.658323]   kgsl-timeline_pt signaled@410.514145
[  420.659780]   kgsl-timeline_pt signaled@410.511896
[  420.659784]   mdss_fb_0_pt active: 2388 / 2387
>>> snip
[  421.190340] Watchdog bark! Now = 421.190336
[  421.190414] Watchdog last pet at 410.190056
[  421.190453] cpu alive mask from last pet 0-3
[  421.190491] Causing a watchdog bite!
Flags: needinfo?(the.decryptor)
I saw the SurfaceView watchdog bite once too. I am not sure if that's the root cause or if the kernel is fouled up from something else. Media playback clearly plays some kind of part...
I thought maybe the per-frame attach/detach that we do on the SurfaceTexture could be responsible for this badness, but disabling that doesn't seem to help here.
In the file I attached, nearly all of the blocked tasks are waiting on the main binder mutex. I don't see anything there which would be holding that mutex, so I guess the owner is not in the blocked state (and therefore does not appear in this list)?
Another thing interesting from that log: All CPUs are in lpm_cpuidle_enter, except CPU 4 which is servicing the SysRq and CPU 0 which is the AudioTrack task. AudioTrack is not listed in set of blocked tasks, but presumably it's holding the binder mutex and then gets stuck somewhere else?
Modifying Fennec to drop the audio track on the floor results in no problems, so audio does indeed some to be part of the problem.
Doing the opposite -- keeping the audio track, but dropping the video track, results in reboot.
We're using OpenSL for audio output, which might be the reason we are a unique snowflake here.
Apparently OpenSL uses AudioTrack on this device, because the AudioTrack thread that is hung on CPU 0 is from fennec. We are definitely not using AudioTrack directly, because that cubeb backend doesn't even work on 6.0 (it's missing a bunch of symbols). In the latest hang, it's stuck at ktime_get_ts+0x74/0x100 in the kernel. This matches the userspace stack I once got above in comment #4.

top shows fennec using 12% CPU, which on this 8 core device equates to one whole CPU. I think we must be spinning in ktime_get_ts for some reason.
Flags: needinfo?(the.decryptor)
I am able to build my own kernels now, so I can debug a little closer. So far, I have determined:

1) The wait_for_completion in msm_mpm_work_fn is probably harmless. I made it timeout, and the behavior was pretty much the same.
2) All of the tasks waiting on the binder mutex do not appear to be deadlocked. After the device is hung I still see successful locks taking place. I guess there is just a lot of contention?
3) I am in the deep end of the pool here and have no idea what I am doing.
Inder, do you know someone that could help us there? thanks!
Flags: needinfo?(ikumar)
I have been assuming the watchdog bite was because it determined there was some hardware badness, but it appears the watchdog is most likely kept satisfied by userspace pings. Consequently, I could be barking up the wrong tree here.
The watchdog daemon source here[0] looks pretty tiny, though, so if that is hosed I would guess there is kernel badness.


[0] http://androidxref.com/6.0.0_r1/xref/system/core/init/watchdogd.cpp
Attached file userspace hang traces — 
The userspace watchdog service is what generates the kernel sysrq traces, and it also does a userspace dump on some system services as well. I grabbed this one just now.
This is another set of userspace traces, and I was able to get fennec this time as well. The main thread appears to be stuck in  android.view.DisplayEventReceiver.nativeScheduleVsync, which ends up stuck in binder.
Summary: Nexus 6P crashes (reboots) when playing video in Fennec → Nexus 6P reboots or hangs when playing video in Fennec
Might be getting somewhere. Binder does indeed some to be...bound up.

[  259.317110] SNORP: binder locked! Binder_4
[  259.317135] SNORP: attempting binder lock.. Thread-152
[  259.317141] SNORP: binder locked! Thread-152
[  259.317567] SNORP: attempting binder lock.. Thread-153
[  259.317575] SNORP: binder locked! Thread-153
[  259.317605] SNORP: attempting binder lock.. Thread-153
[  259.317611] SNORP: binder locked! Thread-153
[  259.317622] SNORP: attempting binder lock.. Thread-153
[  259.317627] SNORP: binder locked! Thread-153
[  259.317652] SNORP: attempting binder lock.. Binder_2
[  259.317658] SNORP: binder locked! Binder_2
[  259.317768] SNORP: attempting binder lock.. Binder_2
[  259.317774] SNORP: binder locked! Binder_2
[  259.317792] SNORP: attempting binder lock.. Binder_2
[  259.317798] SNORP: binder locked! Binder_2
[  259.317822] SNORP: attempting binder lock.. Binder_2
[  259.317827] SNORP: binder locked! Binder_2
[  259.317853] SNORP: attempting binder lock.. Thread-153
[  259.317859] SNORP: binder locked! Thread-153
[  259.318313] SNORP: attempting binder lock.. Binder_3
[  259.318350] SNORP: attempting binder lock.. MediaPl~ack #11
[  259.977658] SNORP: attempting binder lock.. system_server
[  260.233574] SNORP: attempting binder lock.. m.android.phone
[  264.617285] SNORP: attempting binder lock.. ActivityManager
[  264.617461] SNORP: attempting binder lock.. ConnectivitySer
[  267.351033] healthd: battery l=77 v=4034 t=37.0 h=2 st=2 c=-318 chg=u 2015-11-09 22:45:37.804400605 UTC
[  267.351096] SNORP: attempting binder lock.. healthd
[  267.634189] SNORP: attempting binder lock.. Gecko
[  273.038252] SNORP: attempting binder lock.. ATFWD-daemon
[  284.436335] SNORP: attempting binder lock.. GCMReader
[  322.738802] SNORP: attempting binder lock.. Binder_1
[  327.761553] SNORP: attempting binder lock.. Binder_2
[  343.445929] SNORP: attempting binder lock.. Binder_3
[  348.469079] SNORP: attempting binder lock.. Binder_4
[  350.513281] SMBCHG: determine_target_input_current: target_current = 500
[  353.711504] SNORP: attempting binder lock.. Binder_5
[  358.732076] SNORP: attempting binder lock.. Binder_6
[  363.857570] SNORP: attempting binder lock.. Binder_7
[  368.920602] SNORP: attempting binder lock.. Binder_8
[  373.942060] SNORP: attempting binder lock.. Binder_9
[  378.981073] SNORP: attempting binder lock.. Binder_A
[  384.002085] SNORP: attempting binder lock.. Binder_B
[  389.147634] SNORP: attempting binder lock.. Binder_C
[  394.171567] SNORP: attempting binder lock.. Binder_D
[  399.207093] SNORP: attempting binder lock.. Binder_E
[  399.221849] SNORP: attempting binder lock.. Binder_1

Thread-153 (whatever that is) is hosing us. Or maybe the target thread is hosing us, not sure.
I am also experiencing this issue. I am able to reproduce it using the following demo: http://www.wothke.ch/websid/ . If you tap on "What's this?" and then repeatedly tap on the next button ">>|" the phone will eventually either hang or reboot. I am on Nexus 6P.
(In reply to rqou from comment #43)
> I am also experiencing this issue. I am able to reproduce it using the
> following demo: http://www.wothke.ch/websid/ . If you tap on "What's this?"
> and then repeatedly tap on the next button ">>|" the phone will eventually
> either hang or reboot. I am on Nexus 6P.

Thanks for the report. I can confirm that I get the same hang if I follow those instructions. There is no decoder activity with this demo, so I think we can narrow this down to something related to sound playback.
(In reply to rqou from comment #43)
> I am also experiencing this issue. I am able to reproduce it using the
> following demo: http://www.wothke.ch/websid/ . If you tap on "What's this?"
> and then repeatedly tap on the next button ">>|" the phone will eventually
> either hang or reboot. I am on Nexus 6P.

I also confirmed system reboot on nexus-5.
I am going to think, the problem might be caused by very high cpu usage of AudioTrack thread. The thread handle callback from AudioFlinger and run very high thread priority.

Before the system reboot on nexus 5, "adb shell top -m 5 -d 3 -t" showed the following result.

----------------------------------------------------
User 68%, System 19%, IOW 0%, IRQ 0%
User 212 + Nice 0 + Sys 60 + Idle 37 + IOW 0 + IRQ 0 + SIRQ 0 = 309

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
 3028  3182  0 126% R 1695784K 404936K  fg u0_a53   AudioTrack      org.mozilla.fennec_sotaro
 3086  3086  0   6% R   3220K   1376K  fg shell    top             top
  201   675  0   2% R 138232K  10480K  fg media    FastMixer       /system/bin/mediaserver
 3028  3141  0   2% S 1695784K 404936K  fg u0_a53   Thread-169      org.mozilla.fennec_sotaro
 3028  3097  0   1% S 1695784K 404936K  fg u0_a53   Gecko           org.mozilla.fennec_sotaro
On fxos nexus-5-l, top command showed very different result. The following showed that Browser main thread was most busy. On android, AudioTrack thread was most busy and its cpu usage was too high.

----------------------------------------------

User 46%, System 9%, IOW 0%, IRQ 0%
User 283 + Nice 0 + Sys 59 + Idle 259 + IOW 2 + IRQ 0 + SIRQ 1 = 604

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
 1808  1808  1  44% R 278148K  68784K unk u0_a1808 Browser         /system/b2g/b2g
  196   790  1   2% S 568660K 138248K  fg root     Compositor      /system/b2g/b2g
  196  1830  1   2% S 573224K 138248K  fg root     BufMgrParent#18 /system/b2g/b2g
 1808  2566  1   1% S 278148K  68784K  fg u0_a1808 AudioTrack      /system/b2g/b2g
 2685  2685  0   1% R  10672K   1264K  fg root     top             top
Both on android and fxos nexus-5, AudioTrack thread seemed to have same thread priority like the following.

> APPLICATION PRIO  NICE  RTPRI SCHED  NAME
> AudioTrack  -3    -16   2     1      AudioTrack

AudioTrack thread is very high priority, if the thread consume almost all cpu resource, another thread could not use cpu. It might cause this problem.
(In reply to Sotaro Ikeda [:sotaro] from comment #47)
> On fxos nexus-5-l, top command showed very different result. The following
> showed that Browser main thread was most busy. On android, AudioTrack thread
> was most busy and its cpu usage was too high.
> 
> ----------------------------------------------
> 
> User 46%, System 9%, IOW 0%, IRQ 0%
> User 283 + Nice 0 + Sys 59 + Idle 259 + IOW 2 + IRQ 0 + SIRQ 1 = 604
> 
>   PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
>  1808  1808  1  44% R 278148K  68784K unk u0_a1808 Browser         /system/b2g/b2g


On fxos nexus-5 case, Browser main thread cpu usage is mainly for rendering. When display is off, cpu usage was the following.

-------------------------------------------------

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
 1688  1688  0  17% S 259240K  66444K unk u0_a1688 Browser         /system/b2g/b2g
 1688  2398  0  12% S 259240K  66444K  fg u0_a1688 AudioTrack      /system/b2g/b2g
  192   732  0   8% S  47136K   9172K  fg media    FastMixer       /system/bin/mediaserver
 2877  2877  0   4% R  10672K   1252K  fg root     top             top
  910   927  0   1% S  20256K    880K  fg root     mpdecision      /system/bin/mpdecision
On android 5.1.1 factory image of nexus-5, http://www.wothke.ch/websid/ showed the following cpu usage by "adb shell top -m 5 -d 3 -t". It seems same to fxos master nexus-5-l.

----------------------------------------------------------

User 51%, System 8%, IOW 0%, IRQ 0%
User 312 + Nice 0 + Sys 54 + Idle 239 + IOW 0 + IRQ 0 + SIRQ 0 = 605

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
 5914  5963  0  46% R 2258460K 391556K  fg u0_a83   Gecko           org.mozilla.fennec_sotaro
 5914  6465  1   3% S 2258460K 391556K  fg u0_a83   AudioTrack      org.mozilla.fennec_sotaro
 6440  6440  1   3% R  10672K   1560K  fg shell    top             top
  171   217  1   2% S  18628K   2740K  fg logd     logd.writer     /system/bin/logd
 5914  6041  0   2% S 2258460K 391556K  fg u0_a83   Thread-530      org.mozilla.fennec_sotaro
Reproducing using comment 43 on Nexus 7 and 5 with Android M. Using the hardware volume buttons seems to be broken in this situation and triggers the hang/reboot for me.
(In reply to Sotaro Ikeda [:sotaro] from comment #48)
> Both on android and fxos nexus-5, AudioTrack thread seemed to have same
> thread priority like the following.
> 
> > APPLICATION PRIO  NICE  RTPRI SCHED  NAME
> > AudioTrack  -3    -16   2     1      AudioTrack
> 
> AudioTrack thread is very high priority, if the thread consume almost all
> cpu resource, another thread could not use cpu. It might cause this problem.

This is interesting, but the 6P has 8 cores. It could easily schedule stuff on one of those, right? Maybe something prevents that?
I modified the kernel to show all of the fennec tasks when the userspace watchdog does the sysrq during the hang. The AudioTrack thread is interesting:

[  995.648185] AudioTrack      R  running task        0  8840    530 0x00400000
[  995.648196] Call trace:
[  995.648202] [<ffffffc000204c88>] __switch_to+0x7c/0x88
[  995.648209] [<ffffffc0002040dc>] handle_IRQ+0x88/0xa8
[  995.648217] [<ffffffc0002006d8>] gic_handle_irq+0x54/0x84
[  995.648222] Exception stack(0xffffffc037cdbd10 to 0xffffffc037cdbe30)
[  995.648230] bd00:                                     37cdbe80 ffffffc0 37cdbec0 ffffffc0
[  995.648238] bd20: 37cdbe50 ffffffc0 0042d308 ffffffc0 00000000 00000000 37cdbe90 ffffffc0
[  995.648246] bd40: ffffffff ffffffff 2625a023 00000000 37cdbed0 ffffffc0 000003e2 00000000
[  995.648254] bd60: 34155555 00000000 00000018 00000000 a9bc78e0 ffffffff 00000000 00000000
[  995.648262] bd80: 00000000 00000000 00000000 00000000 00000000 00000000 c67fb820 00000000
[  995.648271] bda0: f767c135 00000000 00000000 00000000 0028231c ffffffc0 00000000 00000000
[  995.648278] bdc0: 00000000 00000000 37cdbe80 ffffffc0 37cdbec0 ffffffc0 00000001 00000000
[  995.648286] bde0: 37cdbdf0 ffffffc0 00911e28 ffffffc0 37cdbe00 ffffffc0 00272078 ffffffc0
[  995.648295] be00: 37cdbe40 ffffffc0 0023e7ec ffffffc0 37cdbe80 ffffffc0 37cdbec0 ffffffc0
[  995.648301] be20: 00000001 00000000 00000000 00000080
[  995.648308] [<ffffffc0002035a4>] el1_irq+0x64/0xd4
[  995.648316] [<ffffffc00028234c>] compat_sys_clock_gettime+0x30/0x64

I guess clock_gettime() was interrupted by an IRQ, and the handler never returns? I need to add a way to trigger this sysrq whenever I want to see if it's really stuck there, but selinux is being a pain.
Does the presence of the __switch_to in the top frame mean the task was preempted? Is that supposed to be allowed in an interrupt handler? I'm about at my wits end here (probably well past that point, actually).
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #52)
> (In reply to Sotaro Ikeda [:sotaro] from comment #48)
> > Both on android and fxos nexus-5, AudioTrack thread seemed to have same
> > thread priority like the following.
> > 
> > > APPLICATION PRIO  NICE  RTPRI SCHED  NAME
> > > AudioTrack  -3    -16   2     1      AudioTrack
> > 
> > AudioTrack thread is very high priority, if the thread consume almost all
> > cpu resource, another thread could not use cpu. It might cause this problem.
> 
> This is interesting, but the 6P has 8 cores. It could easily schedule stuff
> on one of those, right? Maybe something prevents that?

Yea, on multi core device, on thread's priority should not prevent hole devices. There should be something.
AudioTrack:s sampling rate seems to be related to the problem. At http://www.wothke.ch/websid/, sampleRate was 48000. At youtube.com, sampleRate was 44100. Android normally use 44100 as sample rate.

The followings are AudioTrack params dump.
----------------

- audio track prams at http://www.wothke.ch/websid/
> 11-11 23:54:19.349 14855 14981 V AudioTrack: set(): streamType 3, sampleRate 48000, format 0x1, channelMask 0x3, frameCount 0, flags #4, notificationFrames 0, sessionId 56, transferType 0, uid -1, pid -1

- audio params at youtube.com
> 11-11 23:52:26.975  6681 14713 V AudioTrack: set(): streamType 3, sampleRate 44100, format 0x1, channelMask 0x3, frameCount 0, flags #4, notificationFrames 0, sessionId 50, transferType 0, uid -1, pid -1
Just the following change(hard code 44100 sample rate) seemed to fix the problem, though audio pitch and play speed became slow.

diff --git a/media/libcubeb/src/cubeb_opensl.c b/media/libcubeb/src/cubeb_opensl.c
--- a/media/libcubeb/src/cubeb_opensl.c
+++ b/media/libcubeb/src/cubeb_opensl.c
@@ -475,16 +475,18 @@ opensl_stream_init(cubeb * ctx, cubeb_st
 
   *stream = NULL;
 
   if (stream_params.channels < 1 || stream_params.channels > 32 ||
       latency < 1 || latency > 2000) {
     return CUBEB_ERROR_INVALID_FORMAT;
   }
 
+  stream_params.rate = 44100;
+
   SLDataFormat_PCM format;
When audio sample rate was 48000, audio out seemed to use low-latency-playback.

----------------------------------------------------------------

11-12 01:34:04.856  1686  1938 V AudioTrack: set(): streamType 3, sampleRate 48000, format 0x1, channelMask 0x3, frameCount 0, flags #4, notificationFrames 0, sessionId 22, transferType 0, uid -1, pid -1
11-12 01:34:04.856  1686  1938 V AudioTrack: set() streamType 3 frameCount 0 flags 0004
11-12 01:34:04.856  1686  1938 V AudioTrack: createTrack_l() output 2 afLatency 50
11-12 01:34:04.856   205   856 V AudioFlinger: createTrack() lSessionId: 22
11-12 01:34:04.857  1686  1938 V AudioTrack: AUDIO_OUTPUT_FLAG_FAST successful; frameCount 240
11-12 01:34:04.857   205   781 V AudioFlinger: acquiring 22 from 1686, for 1686
11-12 01:34:04.857   205   781 V AudioFlinger:  added new entry for 22
11-12 01:34:04.868   205   774 D audio_hw_primary: out_set_parameters: enter: usecase(1: low-latency-playback) kvpairs: routing=2
11-12 01:34:04.868  1686  1943 V AudioTrack: timeout 0.008
This patch is a temporary workaround of phone reboot on android M. It seemed to work for http://www.wothke.ch/websid/ phone reboot on master android firefox on nexus-5 of android M.
(In reply to Sotaro Ikeda [:sotaro] from comment #46)
> I am going to think, the problem might be caused by very high cpu usage of
> AudioTrack thread. The thread handle callback from AudioFlinger and run very
> high thread priority.
> 
> Before the system reboot on nexus 5, "adb shell top -m 5 -d 3 -t" showed the
> following result.
> 
> ----------------------------------------------------
> User 68%, System 19%, IOW 0%, IRQ 0%
> User 212 + Nice 0 + Sys 60 + Idle 37 + IOW 0 + IRQ 0 + SIRQ 0 = 309
> 
>   PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
>  3028  3182  0 126% R 1695784K 404936K  fg u0_a53   AudioTrack     
> org.mozilla.fennec_sotaro
>  3086  3086  0   6% R   3220K   1376K  fg shell    top             top
>   201   675  0   2% R 138232K  10480K  fg media    FastMixer      
> /system/bin/mediaserver
>  3028  3141  0   2% S 1695784K 404936K  fg u0_a53   Thread-169     
> org.mozilla.fennec_sotaro
>  3028  3097  0   1% S 1695784K 404936K  fg u0_a53   Gecko          
> org.mozilla.fennec_sotaro

I seems to understand why AudioTrack thread uses a lot of cpu. When the problem happened AudioTrack::setMarkerPosition() was called with very big marker value. It caused the problem. When very bit marker value is set, AudioTrack::processAudioBuffer() does not work correctly.

The following time unit becomes 0. If it happens, AudioTrack::obtainBuffer() is called without timeout wait and AudioTrack thread becomes not to sleep.

------------------------------------

    // Convert frame units to time units
    nsecs_t ns = NS_WHENEVER;
    if (minFrames != (uint32_t) ~0) {
        ns = framesToNanoseconds(minFrames, sampleRate, speed) + kWaitPeriodNs;
        ns -= (timeAfterCallbacks - timeBeforeCallbacks);  // account for callback time
        // TODO: Should we warn if the callback time is too long?
        if (ns < 0) {
           ns = 0;
        }
    }
 
http://androidxref.com/6.0.0_r1/xref/frameworks/av/media/libmedia/AudioTrack.cpp#1925
Comment on attachment 8686386 [details] [diff] [review]
patch - Wrokaround of phone reboot

Set to obsolete.
Attachment #8686386 - Attachment is obsolete: true
(In reply to Sotaro Ikeda [:sotaro] from comment #60)
> (In reply to Sotaro Ikeda [:sotaro] from comment #46)
> > I am going to think, the problem might be caused by very high cpu usage of
> > AudioTrack thread. The thread handle callback from AudioFlinger and run very
> > high thread priority.
> > 
> > Before the system reboot on nexus 5, "adb shell top -m 5 -d 3 -t" showed the
> > following result.
> > 
> > ----------------------------------------------------
> > User 68%, System 19%, IOW 0%, IRQ 0%
> > User 212 + Nice 0 + Sys 60 + Idle 37 + IOW 0 + IRQ 0 + SIRQ 0 = 309
> > 
> >   PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
> >  3028  3182  0 126% R 1695784K 404936K  fg u0_a53   AudioTrack     
> > org.mozilla.fennec_sotaro
> >  3086  3086  0   6% R   3220K   1376K  fg shell    top             top
> >   201   675  0   2% R 138232K  10480K  fg media    FastMixer      
> > /system/bin/mediaserver
> >  3028  3141  0   2% S 1695784K 404936K  fg u0_a53   Thread-169     
> > org.mozilla.fennec_sotaro
> >  3028  3097  0   1% S 1695784K 404936K  fg u0_a53   Gecko          
> > org.mozilla.fennec_sotaro
> 
> I seems to understand why AudioTrack thread uses a lot of cpu. When the
> problem happened AudioTrack::setMarkerPosition() was called with very big
> marker value. It caused the problem. When very bit marker value is set,
> AudioTrack::processAudioBuffer() does not work correctly.
> 
> The following time unit becomes 0. If it happens, AudioTrack::obtainBuffer()
> is called without timeout wait and AudioTrack thread becomes not to sleep.
> 

I tried to prevent the above situation by local modification. The problem of http://www.wothke.ch/websid/ was addressed.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #52)
> > 
> > > APPLICATION PRIO  NICE  RTPRI SCHED  NAME
> > > AudioTrack  -3    -16   2     1      AudioTrack
> > 
> > AudioTrack thread is very high priority, if the thread consume almost all
> > cpu resource, another thread could not use cpu. It might cause this problem.
> 
> This is interesting, but the 6P has 8 cores. It could easily schedule stuff
> on one of those, right? Maybe something prevents that?

AudioTrack is very high priority(RT priority) thread and it continuously called system calls when the problem happened. If system call holds global lock within kernel, it could almost freeze the whole system, I assume.
(In reply to Sotaro Ikeda [:sotaro] from comment #62)
> (In reply to Sotaro Ikeda [:sotaro] from comment #60)
> > (In reply to Sotaro Ikeda [:sotaro] from comment #46)
> > > I am going to think, the problem might be caused by very high cpu usage of
> > > AudioTrack thread. The thread handle callback from AudioFlinger and run very
> > > high thread priority.
> > > 
> > > Before the system reboot on nexus 5, "adb shell top -m 5 -d 3 -t" showed the
> > > following result.
> > > 
> > > ----------------------------------------------------
> > > User 68%, System 19%, IOW 0%, IRQ 0%
> > > User 212 + Nice 0 + Sys 60 + Idle 37 + IOW 0 + IRQ 0 + SIRQ 0 = 309
> > > 
> > >   PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
> > >  3028  3182  0 126% R 1695784K 404936K  fg u0_a53   AudioTrack     
> > > org.mozilla.fennec_sotaro
> > >  3086  3086  0   6% R   3220K   1376K  fg shell    top             top
> > >   201   675  0   2% R 138232K  10480K  fg media    FastMixer      
> > > /system/bin/mediaserver
> > >  3028  3141  0   2% S 1695784K 404936K  fg u0_a53   Thread-169     
> > > org.mozilla.fennec_sotaro
> > >  3028  3097  0   1% S 1695784K 404936K  fg u0_a53   Gecko          
> > > org.mozilla.fennec_sotaro
> > 
> > I seems to understand why AudioTrack thread uses a lot of cpu. When the
> > problem happened AudioTrack::setMarkerPosition() was called with very big
> > marker value. It caused the problem. When very bit marker value is set,
> > AudioTrack::processAudioBuffer() does not work correctly.
> > 
> > The following time unit becomes 0. If it happens, AudioTrack::obtainBuffer()
> > is called without timeout wait and AudioTrack thread becomes not to sleep.
> > 
> 
> I tried to prevent the above situation by local modification. The problem of
> http://www.wothke.ch/websid/ was addressed.

Interesting! I changed opensl_get_preferred_sample() to always return 44100, and things do seem improved. However, I am still able to get a hang on the Yahoo test. I think perhaps the higher iteration frequency made it easier to get into whatever bad state we're hitting.
AFAICT, the only place wilhelm calls AudioTrack::setMarkerPosition() is here[0], which is in response to registering for the SL_PLAYEVENT_HEADATMARKER event. I think the reason the marker value would be huge is because the marker position is initialized[1] to SL_TIME_UNKNOWN, which is 0xFFFFFFFF[2]. Ahem.

Setting the marker position to 0 before setting the event mask seems to avoid the badness. Patch incoming.

[0] http://androidxref.com/6.0.0_r1/xref/frameworks/wilhelm/src/android/AudioPlayer_to_android.cpp#2029
[1] http://androidxref.com/6.0.0_r1/xref/frameworks/wilhelm/src/itf/IPlay.c#466
[2] http://androidxref.com/6.0.0_r1/xref/frameworks/wilhelm/include/SLES/OpenSLES.h#921
Note that the spec[0] does not say the marker must be set before registering for this callback, so I think wilhelm is just busted here. It should check for SL_TIME_UNKNOWN.

[0] https://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf
:esawin asked me why this would only happen on Android M, and I'm not totally sure. It looks like the busted marker position stuff has been in wilhelm for a while. My guess is that they only recently made the AudioTrack thread RT?
On andorid v5.5.1, AudioTrack thread is also RT. I think the following code affect to the problem as in Comment 60. The following was changed from android v5.5.1 to android 6.0.0.

------------------------------------

    // Convert frame units to time units
    nsecs_t ns = NS_WHENEVER;
    if (minFrames != (uint32_t) ~0) {
        ns = framesToNanoseconds(minFrames, sampleRate, speed) + kWaitPeriodNs;
        ns -= (timeAfterCallbacks - timeBeforeCallbacks);  // account for callback time
        // TODO: Should we warn if the callback time is too long?
        if (ns < 0) {
           ns = 0;
        }
    }
attachment 8686942 [details] [diff] [review] revert a part of AudioTrack code that is related to comment 69. By applying the patch to android v6.0.0, I confirmed the problem of http://www.wothke.ch/websid/ was addressed on nexus-5.
From comment 71, the change of attachment 8686942 [details] [diff] [review] that happened from v5.1.1 to v6.0.0 seems to trigger the problem.
diego, do you know if this is a known problem of android 6.0?
Flags: needinfo?(dwilson)
Comment on attachment 8686774 [details] [diff] [review]
Work around busted OpenSL causing hangs/reboots on Android

Review of attachment 8686774 [details] [diff] [review]:
-----------------------------------------------------------------

?!?
Attachment #8686774 - Flags: review?(padenot) → review+
Summary: Nexus 6P reboots or hangs when playing video in Fennec → 6.0 devices reboot or hang when playing audio/video in Fennec
Comment on attachment 8686774 [details] [diff] [review]
Work around busted OpenSL causing hangs/reboots on Android

Approval Request Comment
[Feature/regressing bug #]: Android 6.0
[User impact if declined]: Hangs and reboots when playing media
[Describe test coverage new/current, TreeHerder]: local, and soon on nightly
[Risks and why]: Pretty low, but we should obviously test to make sure the patch doesn't somehow cause problems.
[String/UUID change made/needed]: None
Attachment #8686774 - Flags: approval-mozilla-release?
Attachment #8686774 - Flags: approval-mozilla-beta?
Attachment #8686774 - Flags: approval-mozilla-aurora?
Can confirm with Nexus 5X with FF only. Restarts everytime with videogular example.

http://www.videogular.com/examples/simplest-videogular-player/
I'll check back to make sure this lands and is ok on m-c before we uplift it to beta.  
Let's aim this for the beta 4 build on Monday.
https://hg.mozilla.org/mozilla-central/rev/84c21e328c74
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
rqou, can you please verify that the hang/reboot issue you are experiencing is fixed on the latest Nightly build (date 11/15/2015)? Thanks.
Flags: needinfo?(rqou)
Bug seems fixed in Nightly. I tested on both the videogular example I posted, and, on my own site. Thankyou!
Tested the 11/15/2015 Nightly, bug seems fixed on all the sites/WebAudio demos I tried it on.
Flags: needinfo?(rqou)
Fixed for me, nothing I tried caused a crash (Still played with issues, I was hoping that was down to the CPU being hogged, but it seems to be something else)
Comment on attachment 8686774 [details] [diff] [review]
Work around busted OpenSL causing hangs/reboots on Android

Taking it on all branches as it is an important issue. However, we haven't decided if we do a 42.0.1 or not.
Attachment #8686774 - Flags: approval-mozilla-release?
Attachment #8686774 - Flags: approval-mozilla-release+
Attachment #8686774 - Flags: approval-mozilla-beta?
Attachment #8686774 - Flags: approval-mozilla-beta+
Attachment #8686774 - Flags: approval-mozilla-aurora?
Attachment #8686774 - Flags: approval-mozilla-aurora+
Assignee: nobody → snorp
Based on comment 83, 84 and 85, this is verified on trunk (Nightly45).
Status: RESOLVED → VERIFIED
(In reply to rqou from comment #84)
> Tested the 11/15/2015 Nightly, bug seems fixed on all the sites/WebAudio
> demos I tried it on.

Thanks for the verification! This is very helpful.
(Making summary a bit more keyword rich, since I wasn't able to find this bug prior to filing bug 1225415.)
Summary: 6.0 devices reboot or hang when playing audio/video in Fennec → Android 6.0 devices (eg Nexus 5X/6P) reboot/restart or hang when playing audio/video
Verified as fixed on Nexus 5 (Android 6.0) on Firefox 43 Beta 4.
I was able to reproduce this issue on Firefox 43 Beta 2, on http://www.videogular.com/examples/simplest-videogular-player/
status-firefox43: fixed → verified
[Tracking Requested - why for this release]: We should probably track this as it may be included in a 42.0.1 dot release. 

Snorp can you request uplift to m-r? Sylvestre can decide on this tomorrow, I just want to line up everything for him to do so. Thanks.
tracking-firefox42: --- → ?
Flags: needinfo?(snorp)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #95)
> [Tracking Requested - why for this release]: We should probably track this
> as it may be included in a 42.0.1 dot release. 
> 
> Snorp can you request uplift to m-r? Sylvestre can decide on this tomorrow,
> I just want to line up everything for him to do so. Thanks.

This is done, see comment #86
Flags: needinfo?(snorp)
Verified as fixed on Nexus 5 (Android 6.0) on Firefox 42.0.1.
status-firefox42: fixed → verified
Flags: needinfo?(dwilson)
Flags: needinfo?(ikumar)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.