Closed Bug 1732677 Opened 4 months ago Closed 4 months ago

[M1] OS crashes (kernel panic) upon toggling full screen for software-decoded video

Categories

(Core :: Graphics, defect, P1)

ARM64
macOS
defect

Tracking

()

VERIFIED FIXED
94 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox92 --- unaffected
firefox93 - unaffected
firefox94 blocking verified

People

(Reporter: tbabos, Assigned: bradwerth)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 obsolete file)

Affected Version:

  • latest Nightly 94.0a1 (2021-09-26) (64-bit)

Reproducible on:

  • MacBook Air M1 - MacOS Big Sur

Steps to reproduce:

  1. Go to Youtube and select any video (or any other site with videos)
  2. Click on the FullScreen button

Expected Result:
The video is played back without any issues

Actual Result:
The whole OS crashes and the device is restarted

Regression-range:
Not reproducible if the following pref is disabled: gfx.core-animation.specialize-video
Regression of: Bug 1653417

Which exact macOS version are you using?

This does not happen for me on macOS 11.6 (20G165) on an M1 MacBook Pro 13". But it was happening on this machine with an earlier version of macOS when I was running a test build with these patches, two or three weeks ago.

Flags: needinfo?(timea.babos)

Hey Markus, I am on MacOS Big Sur (Version 11.2.2) - MacBook Air (M1, 2020). Please be aware that this is only reproducible on the M1 device (Apple chip).

Flags: needinfo?(timea.babos)

I'm on macOS Big Sur 11.6, also a Macbook Air M1.

Flags: needinfo?(rtestard)
Duplicate of this bug: 1732814
Assignee: nobody → bwerth

I have filed FB9662075 about this.

We have about 350k DAU on aarch64 on macOS (https://sql.telemetry.mozilla.org/queries/76596/source#191266) so an acceptable option for 94 could be to pref off bug 1653417 for these clients if no fix can be made in time for beta merge?

Flags: needinfo?(rtestard)
Depends on: 1733148

Since the M1 Macs panic only after the video layer has been isolated, that
means that the AVSampleBufferDisplayLayer has been successfully enqueueing
buffers up to that point. It's possible that our manipulation of the layer
tree is the source of the panic.

(In reply to Romain Testard [:RT] from comment #6)

We have about 350k DAU on aarch64 on macOS (https://sql.telemetry.mozilla.org/queries/76596/source#191266) so an acceptable option for 94 could be to pref off bug 1653417 for these clients if no fix can be made in time for beta merge?

Yes, I have opened Bug 1733148 to do that.

I can reproduce this 100% of the time on the following software-decoded video, if I have no external screen and no power cable connected: https://upload.wikimedia.org/wikipedia/commons/2/22/Volcano_Lava_Sample.webm

I cannot reproduce this at all on the following hardware-decoded video: https://chromanomicon.com/TestPatterns/chip-chart-1080-untagged.mp4

Summary: [M1] OS crashes upon toggling full screen for a video → [M1] OS crashes (kernel panic) upon toggling full screen for software-decoded video
Attachment #9243502 - Attachment is obsolete: true
Assignee: bwerth → mstange.moz
Status: NEW → ASSIGNED

I am seeing the same thing when loading https://firebase.google.com/docs/firestore/data-model and trying to watch the video full screen.

macOS Big Sur Version 11.6
Hardware Overview:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro17,1
  Chip:	Apple M1
  Total Number of Cores:	8 (4 performance and 4 efficiency)
  Memory:	16 GB
  System Firmware Version:	6723.140.2
  OS Loader Version:	6723.140.2
  Activation Lock Status:	Disabled

Please also note that turning off gfx.core-animation.specialize-video fixes the issue

We've landed the patch to turn off the pref on M1 machines in bug 1733148, so this should be fixed in the next Nightly.

We'll use this bug to find a way to get low-power software-decoded video on M1 machines without kernel panicking.

Duplicate of this bug: 1733372

Using NV12 instead of YUV422 (by partially reverting bug 1657107) gets rid of the kernel panic, but doesn't hit detached mode. So it probably doesn't kernel panic because it doesn't hit detached mode.

We don't yet have a good idea of the set of surface formats that let us hit detached mode with software-decoded video. Adding a software-decoded video path to the test app would help us gain a better understanding.

Blocks: 1733499
Blocks: 1733500

Actually let's close this bug, so that the tracking flags etc make sense. I've filed two bugs to re-enable the power-efficient path on M1 machines:

Assignee: mstange.moz → bwerth

Fixed by bug 1733148.

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

Verified-fixed on the latest Firefox Nightly 94.0a1 (2021-09-30) ( 20210930215026) on MacOS 11.2.2 - M1 Apple. There were no kernel panics encountered since the preference that caused it is now disabled by default.

Status: RESOLVED → VERIFIED
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.