Wednesday, May 31, 2017

2

Power outage

Something went wrong at home during the night. There was a power outage, the 30mA differential protection disconnected most of the home, including all the computers.

Some annoying damage as a result. Loss so far:

• The power supply for the Red Hat MacBook Pro. I suspect this is the thing that actually caused the outage. I had noticed that it was "leaky" in the sense that I was feeling tingles if I touched the body of the MacBook Pro while barefoot on the floor.
• The ability to boot Fedora 26 on Shuttle. Actually, the boot disk itself looks fine, I can mount it allright from the Live install USB stick. But the Fedora boot entry is gone, and the machine always boots in Windows even if I select the Fedora disk from the BIOS boot menu.
• At least two virtual machines on Big, which was running them in Virtual Box under Windows. During reboot, Windows did a massive NTFS disk check, showing thousands of errors. It ultimately recovered, but the macOS.vdi disk image for the macOS Sierra VM has a zero size. Not good. And the Windows 7 disk took some damage too. I could restore from an older backup, but that means I lost a lot of what was installed in that VM, notably what I think was my last known good Windows build environment for Tao3D. One that I planned to replicate in a KVM Windows guest, but never finished. Aaargh.

That last one is probably the most time-wasting loss. The Tao3D build environment is annoyingly complex. It requires Qt, a valid GL build environment, MinGW tools that I can no longer find nowadays, a specifically patched version of VLC (they never took Jerome's patches fixing the playback of multi-stream video files, saying our fix wasn't right but never actually fixing it the right way).

Repairing Shuttle

I spent a couple of hours trying to understand how to restore the boot proces for Shuttle, before realizing the problem was that I was assuming a BIOS-based boot, when Fedora was actually booting in UEFI.

Another round on macOS spice patches

Yet another round (#6) of patches for the macOS spice client. Yet another set of valid and less valid remarks on how to improve this further. This time, I "fixed" something that should not be fixed, I misunderstood the g_array_set_size documentation to mean that it was the size in bytes and not the size in items. Will need to issue round #7.

Latency build up with nvidia streaming

The mac Spice client does not read the stream fast enough, and latency builds up. Illustration:

A good example of the kind of testing you can easily do with Tao3D

It is possible to reproduce a similar problem with the native Linux client, but that requires the system to be under load (I ran a VM with pending builds from my Jenkins system).

The test program for this is:

import BlackAndWhiteThemes


theme "BlackOnWhite"

picture_slide "Empty",
    false

picture_slide "Speed test",
    box 0, 0, 800, 600,
        vertical_align 0.5 + 0.5 * sin time
        align 0.5 + 0.5 * sin (0.3 * time)
        text "Time: " & page_time * 1000
    locally
        color_hsv 20 * time, 0.3, 1, 60%
        rotate_z 6 * page_time
        ellipse_sector 0, 0, 500, 500, 0, 60 * page_time mod 360


picture_slide "Clock",
    locally
        color "darkblue"
        dots with 0..59
        dots N ->
            locally
                rotate_z -6 * N
                translate_y 222
                if N mod 5 = 0 then
                    rectangle 10, 10
                else
                    circle 3
    locally
        color "red"
        rotate_z -360 * time
        rectangle 0, 120, 2, 240
    locally
        rotate_z -6 * seconds
        rectangle 0, 60, 5, 120
    locally
        color "darkgrey"
        rotate_z -6 * minutes - 0.1 * seconds
        rectangle 0, 80, 8, 160
    locally
        color "darkgrey"
        rotate_z -30 * hours - 0.5 * minutes
        rectangle 0, 60, 10, 120

Muse page table issues

One surprising and unfortunate side effect of running the spicy client on Linux with was a couple of bizarre behaviors after a few tries, forcing me to reboot Muse. Basically:

• The spicy client freezes completely
• The system becomes very unresponsive, windows are hard to kill, etc.
• The journalctl shows a number of really worrying messages about bad page state. To be investigated.

macOS Spice client has audio

Victor Toso helped me verify that gstreamer audio works on the Mac with the following command:

gst-launch-1.0 audiotestsrc ! autoaudiosink

So the mac Spice client was supposed to give audio, but did not. After a little bit of experimentation and log analysis, it turns out that the problem is with the "volume sync" of Spice, which mutes the audio on the Linux host (server-side) each time I start mac Spice.

Once I restore the audio level on the Linux machine, I get sound. But it's not really good, there's a lot of stuttering. Granted, both the host and target machines where quite loaded.