Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Purple Screen Reboot on iOS/iPadOS 15 when using OpenGL graphics #2743

Closed
HenryQuan opened this issue Aug 12, 2021 · 17 comments
Closed

Purple Screen Reboot on iOS/iPadOS 15 when using OpenGL graphics #2743

HenryQuan opened this issue Aug 12, 2021 · 17 comments
Labels
crash Application crashes iOS Issues specific to iOS platform.
Milestone
v3.1

Comments

@HenryQuan
Copy link

HenryQuan commented Aug 12, 2021 •
edited
Loading

Describe the issue
Booting debian-10-4-xfce downloaded from the gallery on iOS 15.0 Beta 5 results in a purple screen and reboot. This is very consistent and happens all the time.

Configuration

  • UTM Version: 2.2.0
  • OS Version: 15.0 Beta 5
  • Device Model: iPad Pro 11 inch 3rd gen
  • Is it jailbroken (name jailbreak used)? No
  • How did you install UTM? iOS App Signer & iosdeploy

Crash log
panic.zip

Debug log
debug.log.zip

Upload VM
https://mac.getutm.app/gallery/debian-10-4-xfce. This one from the gallery is used with no modifications.
@HenryQuan
Copy link
Author

By using https://mac.getutm.app/gallery/debian-10-4-ldxe, I can produce the same issue.

@HenryQuan
Copy link
Author

This seems to be an issue with the beta. Same VM works on 2.1.2.

@HenryQuan HenryQuan changed the title Purple Screen Reboot on iPad M1 iOS 15.0 Beta 5 [2.2.0] Purple Screen Reboot on iPad M1 iOS 15.0 Beta 5 Aug 17, 2021
@coreycusick
Copy link

I have the same issue with Ubuntu arm. It appears to be something to do with UTM taking all the ram due to a possible memory leak when an OS uses OpenGL. Hasn’t yet been fixed

@HubertZhang
Copy link

I adjusted memory from 2GB to 3GB and virtio-rambf works without purple screen. However, UTM crashed later when I tried to open an app in Ubuntu.

qemu logs ends with following lines

qemu-system: spice_iosurface_create: IOSurfaceCreate failed
qemu_spice_gl_scanout_texture: failed to get fd for texture

@conath
Copy link
Contributor

conath commented Aug 29, 2021

This memory issue with the UTM 2.2.0 beta has been addressed, in beta 2.2.1.

@conath conath closed this as completed Aug 29, 2021
@HubertZhang
Copy link

Still encountered such problem in beta 2.2.2, iPadOS 15 beta 8..

@HubertZhang
Copy link

I ran UTM through Xcode and used master branch. Before system crash, RAM didn't increase so much according to Xcode debug session panel...

Please let me know if you need any log or more information.

@conath conath reopened this Sep 4, 2021
@conath
Copy link
Contributor

conath commented Sep 4, 2021

To be clear, @HubertZhang your iPad reboots entirely. Not just UTM?

@HubertZhang
Copy link

Yes, my iPad reboots entirely.

I tried master version on iPadOS 15 and encountered same issue..

@conath conath mentioned this issue Nov 28, 2021
Closed
@conath conath changed the title [2.2.0] Purple Screen Reboot on iPad M1 iOS 15.0 Beta 5 Purple Screen Reboot on iPadOS 15 when using OpenGL graphics Nov 30, 2021
@conath conath mentioned this issue Nov 30, 2021
Closed
@conath conath changed the title Purple Screen Reboot on iPadOS 15 when using OpenGL graphics Purple Screen Reboot on iOS/iPadOS 15 when using OpenGL graphics Dec 2, 2021
@conath conath mentioned this issue Dec 2, 2021
Closed
@osy osy added crash Application crashes iOS Issues specific to iOS platform. labels Dec 30, 2021
@osy
Copy link
Contributor

osy commented Dec 30, 2021

I too am hitting this error on iOS 15 and the kicker is that I google to see if there's any way to get any debug info out of the iPhone and guess what this issue shows up as the top result...

@conath
Copy link
Contributor

conath commented Dec 31, 2021

@osy I might be stating the obvious here but have you tried viewing the iOS system log with Console app on Mac?

@osy
Copy link
Contributor

osy commented Dec 31, 2021

So I updated ANGLE and virglrenderer to the latest commit and some preliminary tests shows that it's no longer crashing.

@osy osy mentioned this issue Dec 31, 2021
Closed
@HubertZhang
Copy link

HubertZhang commented Jan 3, 2022 •
edited
Loading

UTM still crashed when using master version UTM and 3.0.0-beta sysroot image...

UTM version: 4e6a7b4
OS version: iOS 15.1

Panic report is attached:
panic-full-2022-01-04-030054.000.ips.zip

@osy osy mentioned this issue Feb 21, 2022
Closed
@DownBeatGnu7882
Copy link

DownBeatGnu7882 commented Feb 21, 2022 •
edited
Loading

Kernel panic occurs whenever i choose -gl option for video card.
If it’s on full graphics and its set to console like arch, it doesn’t crash.
If start up dwm by executing “startx” on alpine linux, it crashes with kernel panic.
Hope this issue becomes resolved!!!

UTM/UTM SE version: 3.1.0B
iPados: 15.3.1
This is my log: https://drive.google.com/file/d/1-m7h7nTXo_G-n5bXhFvQycHXAGLXWsJk/view?usp=drivesdk

@osy
Copy link
Contributor

osy commented Feb 21, 2022

I think I might have found the issue. It's a race condition in IOMobileFramebuffer

  1. QEMU calls IOSurfaceCreate -> IOSurface S is created
  2. ... IOSurfaceRootUserClient::s_lookup_surface -> creates a IOSurfaceClient SC
  3. ... IOSurfaceRootUserClient::set_surface_handle -> associates X with IOSurfaceClient SC
  4. QEMU calls IOSurfaceGetID(S) -> returns id X
  5. QEMU passes X to UTM through write on shared FD
  6. QEMU is done with the surface and calls CFRelease(S)
  7. ... IOSurfaceRootUserClient::s_release_surface -> frees IOSurfaceClient SC and id X
  8. QEMU calls IOSurfaceCreate
  9. ... IOSurfaceRootUserClient::s_create_surface -> allocates IOSurface T which reuses id X
  10. ... IOSurfaceRootUserClient::s_create_surface -> waits on a lock on the client
  11. UTM reads X from the shared FD and calls IOSurfaceLookup(X)
  12. ... IOSurfaceRootUserClient::s_lookup_surface -> gets lock on client
  13. ... IOSurfaceRootUserClient::s_lookup_surface -> finds IOSurface T (not S as expected)
  14. ... IOSurfaceRootUserClient::s_lookup_surface -> creates a IOSurfaceClient TC1 for T
  15. ... IOSurfaceRootUserClient::set_surface_handle -> associates X with IOSurfaceClient TC1
  16. ... IOSurfaceRootUserClient::s_lookup_surface -> releases lock on client
  17. QEMU calls IOSurfaceCreate (continued from 10)
  18. ... IOSurfaceRootUserClient::s_create_surface -> gets lock on client
  19. ... IOSurfaceRootUserClient::s_create_surface -> creates a IOSurfaceClient TC2 for T
  20. ... IOSurfaceRootUserClient::set_surface_handle -> associates X with IOSurfaceClient TC2
  21. ... BUT id X is already referencing TC1, panic!

The issue here is that the client lock isn't held by QEMU's thread (calling into IOMFB) between 9 and 18. That means another thread (UTM calling into IOMFB) can use IOSurfaceLookup to grab T and create TC2 and associate it with id X before the first thread (that created T) is able to create TC1 and associate it with id X.

The fix is to ensure we do not ever call IOSurfaceLookup on a stale X by making sure we retain S until after UTM safely retains it.

@osy osy added this to the v3.1 milestone Feb 22, 2022
osy added a commit to utmapp/qemu that referenced this issue Feb 22, 2022
@osy
spice-display: reduce race in sending IOSurface
6409730 
There is a kernel bug detailed in
utmapp/UTM#2743 (comment)
which results in a race whenever IOSurfaceGetID/IOSurfaceLookup is used.
As a result, we need a way to "indicate" to the receiver that the
surface id in the pipe is now stale and should not be used. To do this
we send POLLHUP to poll() by closing the write FD when the surface is
about to be deallocated.

Note this does not fix the race completely as there is still a small
chance that the race happens between the close() and the CFRelease() but
the chance of that is small and the whole FD passing surface ID system
is a hack anyways that should be replaced with a proper set of SPICE
APIs one day...
osy added a commit to utmapp/CocoaSpice that referenced this issue Feb 22, 2022
@osy
display: add stale surface id detection
8beb55a 
This in conjunction with the QEMU patch should workaround the kernel
panic caused by a IOMFB race in most cases.

utmapp/UTM#2743 (comment)
@osy osy closed this as completed in fcc1dea Feb 22, 2022
@HubertZhang
Copy link

Using GPU supported device no longer causes purple screen on fcc1dea version! Hooray!

@dk335
Copy link

dk335 commented Apr 28, 2023

Tuneskit ios system recovery can help reset an iphone. It has a feature for entering and exiting from recovery mode in one click. Maybe this can fix the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
crash Application crashes iOS Issues specific to iOS platform.
Projects
None yet
Milestone
v3.1
Development

No branches or pull requests
7 participants
@HubertZhang @HenryQuan @conath @coreycusick @osy @DownBeatGnu7882 @dk335