Wednesday, December 13, 2017

Working on the SPICE server crash analysis.

SPICE server crash

Checked that it crashes with any VM, so I don't have to kill my Win10 guest. I can crash before the boot menu in my Fedora27 guest, which much lowers the chances of modifying the disk and leaving it in a damaged / unbootable state.

macOS SPICE performance issue

Since the Win10 guest does not have the streaming agent at the moment, I can compare the performance of the macOS SPICE client, the macOS Microsoft Remote Desktop viewer and the Linux SPICE client. And indeed, I believe that David was right, there is a performance issue with the macOS client. The screen updates from left to right, very slowly. This is particularly visible during the update animations, which change the color of the whole screen.

Win10 guest on Turbo

Still trying to setup the Win10 VM on Windows. It feels sluggish, whether I use SPICE or Microsoft Remote Desktop to access it. I bumped it to 8 CPUs and 8G of memory, but still not feeling fast. I think that the network is somewhat problematic, but there are also tons of disk I/Os, as evidenced by the hard disk noises.

Unfortunately, I triggered the SPICE server crash by mistake on the Windows 10 VM while I was installing stuff in MSYS2 with pacman. (As an aside, finally a convenient package manager on Windows.) After that, it somehow refused to let me login. It was presenting my regular user name, but I was in the "Other user" box, and until I clicked on my user name, I could not login. Weird.

Pacman apparently recovered quite well from being interrupted, I just had to remove a lock file. Installed git, gcc, make, cmake, llvm (3.8.0svn).

Meanwhile, I'm also setting up a backup VM on Muse with similar setup, i.e. MSYS2 and development tools.

ssh for Windows 10

Activated ssh server on Windows 10. Typing ssh and ending with a Windows command prompt... Aaaargh!!!

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.


C:Usersdinec>
C:Usersdinec>ls

Of cours, ls does not work

LLVM versions

Installed multiple variants of LLVM on Muse to see if it's possible to have multiple versions coexist on the same system. Apparently, that works. Muse now has the following:

Installed:
  llvm3.7-devel.x86_64 3.7.1-7.fc27
  llvm3.9-devel.x86_64 3.9.1-11.fc27
  llvm34-devel.x86_64 3.4.2-10.fc26
  llvm35-devel.x86_64 3.5.2-4.fc26
  llvm3.7.x86_64 3.7.1-7.fc27
  llvm3.7-libs.x86_64 3.7.1-7.fc27
  llvm3.9.x86_64 3.9.1-11.fc27
  llvm3.9-libs.x86_64 3.9.1-11.fc27
  llvm34.x86_64 3.4.2-10.fc26
  llvm34-libs.x86_64 3.4.2-10.fc26
  llvm35.x86_64 3.5.2-4.fc26
  llvm35-libs.x86_64 3.5.2-4.fc26

Also installed multiple variants of LLVM on Ptitpuce, using brew. I now have LLVM 3.7.1, 3.8.1, 3.9.1, 4.0.1, 5.0.0 and 6.0.0svn installed in parallel.

On the Win10 guest, I have 3.8.0svn. An old, but nonofficial build? It has the trailing svn, indicating it was taken "somewhere along the way" during the 3.8.0 development. That might be annoying, we'll see.

Having multiple variants like this will help me fine-tune my llvm-crap.h compatibility file, and hopefully understand a bit better how LLVM interacts with software such as Gallium LLVMpipe. Gallium is for later, though. For now, it's much easier to try to understand with code I already know, using the ELFE and XL compilers.