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.

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

cpuinfo poorly emulated on M1 Macs #6047

Closed
3 tasks done
clemens-holleis opened this issue Nov 15, 2021 · 7 comments
Closed
3 tasks done

cpuinfo poorly emulated on M1 Macs #6047

clemens-holleis opened this issue Nov 15, 2021 · 7 comments

Comments

@clemens-holleis
Copy link

  • I have tried with the latest version of Docker Desktop
  • I have tried disabling enabled experimental features
  • I have uploaded Diagnostics

I tried to start Blender inside an amd docker container, emulated on M1 Mac, running noVNC to access the the GUI via Chrome.
From Blender versions 2.8 and higher I get the following error message:

 ArchError: Could not find 'cpu MHz' in /proc/cpuinfo
  Function: Arch_InitTickTimer
      File: /home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/build/usd/src/external_usd/pxr/base/arch/timing.cpp
      Line: 133
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

I posted the problem to Blender here and the issue seems to be the emulation of the container, not Blender.

What I found out so far

  • The /proc/cpuinfo file looks quite different on x86 and ARM machines – among other things ARM seems not to provide a cpu MHz information
  • Inside the container the /proc/cpuinfo reflects the host system not the emulated system inside the container – to verify this theory I tried:
    • Running different Linux x86_64 versions on M1 to check that this behavior is not unique to one distro
    • Running emulated aarch64 Alpine on Intel Windows machine to exclude the possibility of a Mac-only issue with qemu ==> Inside the ARM emulation on Windows arch says aarch64 but the in neofetch the CPU says Intel i7 and the /proc/cpuinfo is also x86 like

Blender (or rather the Pixar USD library inside Blender... see comments) needs the cpuMHz not provided by the emulated system properly, and therefore most likely other projects using this lib as well.

It would be great if you could fix the /proc/cpuinfo to match the emulated system architecture rather than the host system architecture. On the original bug report I also provided a zip file with the docker setup I used.

Information

  • macOS Version: macOS 11.5.1 20G80 arm64
  • Intel chip or Apple chip: Apple M1
  • Docker Desktop Version: 4.2.0 (70708)

Steps to reproduce the behavior

  1. Do this on M1 Mac
  2. Download the zip from this post and extract it
  3. In a terminal go to the unzipped folder
  4. run source build-and-launch.sh to build the image and spin up a container
  5. open a browser and go to http://localhost:6901
  6. login using password pass
  7. see the README.txt on the Desktop you just logged into
  8. ==> Follow the README instructions <==
@arjantop-cai
Copy link

Same issue when running cadvisor images, arch detected as amd64 but no MHz/GHz info is in the cpuinfo

@StefanScherer
Copy link
Member

Thanks for the report. We rely on QEMU on a best effort basis.
Maybe it's better to try to use an arm64 base image and put a linux/arm64 version of Blender into an image?
I don't know that project and whether they provide linux/arm64 builds. But in general if problems arise this would be the next best option to avoid emulation at all.

@clemens-holleis
Copy link
Author

Thank you for the reply. Emulation is currently necessary for two reasons. First the ARM versions of Blender are far behind the latest (besides the one for Mac M1). Second the container should be hosted in the cloud on x86.
I posted the issue to QEMU here.

@docker-robot
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@marcelbeumer
Copy link

Also have this issue when running cadvisor images

@marcelbeumer
Copy link

I don't mean to be rude, but I'd hope to see Docker Desktop taking more ownership of this issue as QEMU is an implementation detail of a now commercial product?

@docker-robot
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators May 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants