UntitledDaily

Monday, May 22, 2017

Mac reboot

I still got the "too many open files" message just trying to compile spicy. Except this time I had shutdown mail. Tried various things, but I could not clearly identify which process was the root cause of the problem... Even less so knowing that trying to run lsof gives me the "too many open files" message too.

Ended up rebooting the Mac.

Connecting to Turbo

After that, connecting to Turbo was failing. I finally figured out that the problem was not Turbo itself (easily seen by connecting from another machine), but rather that the VPN had decided to switch back to "full DNS mode", i.e. ignore my local DNS. Apparently, every update to the DNS will cause that problem.

End of Week CleanupDaily

Friday, May 19, 2017

Trying to tie some loose ends and close some gaps.

Machine updates

Shuttle rebooted during a file copy again. It looks like the problem is really related to networking activity, since most other activies, including disk-heavy VM runs, do not cause reboots. But a machine without a network is not that useful

Creating a media image for Fedora26 failed the first time. It turns out that Linux over-optimizes file transfer:

[root@shuttle ddd]# dd if=/data/systems/ISO/Fedora-Workstation-Live-x86_64-26_Alpha/Fedora-Workstation-Live-x86_64-26_Alpha-1.7.iso of=/dev/sdc1 bs=1M
1373+0 records in
1373+0 records out
1439694848 bytes (1.4 GB, 1.3 GiB) copied, 38.5871 s, 37.3 MB/s
[root@shuttle ddd]# dd if=/data/systems/ISO/Fedora-Workstation-Live-x86_64-26_Alpha/Fedora-Workstation-Live-x86_64-26_Alpha-1.7.iso of=/dev/sdc1 bs=1M
1373+0 records in
1373+0 records out
1439694848 bytes (1.4 GB, 1.3 GiB) copied, 0.503722 s, 2.9 GB/s
[root@shuttle ddd]# sync

The problem is this:

1439694848 bytes (1.4 GB, 1.3 GiB) copied, 0.503722 s, 2.9 GB/s

I don't think that my flash drive suddenly became capable of being written to at 2.9GB/s !!! So the most likely explanation is that the file cache somehow applies to /dev/sdc1, which was very surprising to me. But the fact that sync makes the device LED blink, and takes quite a while, gives credence to that theory.

Now, macOS gives /dev/disk and /dev/rdisk devices, where one is cached and the other is raw. HP-UX and I believe other historical Unixen have the same difference. Linux does it differently. A quick Google search led me to this page, which seems to demonstrate that on Linux, you don't have raw devices by default, you must create them.

Lesson learned. That will only bite me once, I guess

By the way, the Fedora installer geo-locates me, and offers French as the first language choice. But what I positively love is that it offers Brezhoneg (Breton) and Catalan as alternative options One day, I'll create a virtual machine with Breizhoneg language.

Enabling streaming VM on Turbo

Still working on this one. It took a few reboots, but blacklisting nouveau seems to do the trick. The problem is to get ahead of the system while it's booting. You have to type the spicy command line (spicy -h turbo -p 5901 in my case, but not run it (since the guest is not up, so not listening). Then start the guest with virsh start f25-turbo. And very quickly, switch to the terminal with the spicy command (which must be a different terminal, since it's a different machine), launch spicy, hope that it connects quickly enogh, and very quickly type e to stop the boot process and edit the command line.

Took me 5 tries to get it Now I can edit my grub configuration to blacklist nouveau, the guest becomes responsive, and I can edit the grub configuration with more refinement from the guest.

But then, I'm not sure how I'm supposed to add custom menu entries in GRUB. Apparently, /etc/grub2.cfg is all automatically generated. For my current specific case (blacklisting nouveau), that's all dandy. I can simply edit /etc/sysconfig/grub. But what if I want to add multiple menu entries for the same kernel with different options (which is exactly what I want for Turbo, the host)?

And by the way, disabling nouveau means lspci no longer hangs. To be added to Uri's documentation.

Installed the drivers. Rebooted. Does not seem to work too well:

         Starting Fallback to nouveau if nvidia did not load...
[   54.820898] wmi: Mapper loaded
[   55.976167] nouveau 0000:00:0a.0: NVIDIA GM206 (126300a1)
[   56.056475] nouveau 0000:00:0a.0: bios: version 84.06.62.00.01
[   56.059658] nouveau 0000:00:0a.0: disp: dcb 15 type 8 unknown
[     *] (2 of 2) A start job is running for...ia did not load (45s / no limit)[   57.970568] nouveau 0000:00:0a.0: fb: 4096 MiB GDDR5
[   57.974435] nouveau 0000:00:0a.0: bus: MMIO write of 800000fe FAULT at 10eb14 [ IBUS ]
[   57.981248] nouveau 0000:00:0a.0: DRM: VRAM: 4096 MiB
[   57.981721] nouveau 0000:00:0a.0: DRM: GART: 1048576 MiB
[   57.982208] nouveau 0000:00:0a.0: DRM: TMDS table version 2.0
[   57.982717] nouveau 0000:00:0a.0: DRM: DCB version 4.1
[   57.983199] nouveau 0000:00:0a.0: DRM: DCB outp 00: 04800f96 04400020
[   57.983770] nouveau 0000:00:0a.0: DRM: DCB outp 01: 04000f92 00020020
[   57.984359] nouveau 0000:00:0a.0: DRM: DCB outp 02: 04811f86 04400010
[   57.984933] nouveau 0000:00:0a.0: DRM: DCB outp 03: 04011f82 00020010
[   57.985521] nouveau 0000:00:0a.0: DRM: DCB outp 04: 02822f66 04400010
[   57.986100] nouveau 0000:00:0a.0: DRM: DCB outp 05: 02022f62 00020010
[   57.986681] nouveau 0000:00:0a.0: DRM: DCB outp 06: 02833f76 04400020
[   57.987378] nouveau 0000:00:0a.0: DRM: DCB outp 07: 02033f72 00020020
[   57.988099] nouveau 0000:00:0a.0: DRM: DCB outp 15: 01df4ff8 00000000
[   57.988678] nouveau 0000:00:0a.0: DRM: DCB conn 00: 02000046
[   57.989191] nouveau 0000:00:0a.0: DRM: DCB conn 01: 01000146
[   57.989710] nouveau 0000:00:0a.0: DRM: DCB conn 02: 00010246
[   57.990380] nouveau 0000:00:0a.0: DRM: DCB conn 03: 00020346
[   57.991058] nouveau 0000:00:0a.0: DRM: DCB conn 04: 00000470
[   57.992125] nouveau 0000:00:0a.0: DRM: Pointer to flat panel table invalid

Next boot gives me the same thing:

[  OK  ] Started Builds and install new kernel modules through DKMS.
         Starting Fallback to nouveau if nvidia did not load...
[   45.417949] wmi: Mapper loaded
[   46.027370] nouveau 0000:00:0a.0: NVIDIA GM206 (126300a1)
[   46.102917] nouveau 0000:00:0a.0: bios: version 84.06.62.00.01
[   46.103804] nouveau 0000:00:0a.0: disp: dcb 15 type 8 unknown
[   48.216073] nouveau 0000:00:0a.0: fb: 4096 MiB GDDR5
[   48.216572] nouveau 0000:00:0a.0: bus: MMIO write of 80000115 FAULT at 10eb14 [ IBUS ]
[   48.227391] nouveau 0000:00:0a.0: DRM: VRAM: 4096 MiB
[   48.227870] nouveau 0000:00:0a.0: DRM: GART: 1048576 MiB
[   48.228364] nouveau 0000:00:0a.0: DRM: TMDS table version 2.0
[   48.228881] nouveau 0000:00:0a.0: DRM: DCB version 4.1
[   48.229420] nouveau 0000:00:0a.0: DRM: DCB outp 00: 04800f96 04400020
[   48.230200] nouveau 0000:00:0a.0: DRM: DCB outp 01: 04000f92 00020020
[   48.231170] nouveau 0000:00:0a.0: DRM: DCB outp 02: 04811f86 04400010
[   48.231841] nouveau 0000:00:0a.0: DRM: DCB outp 03: 04011f82 00020010
[   48.232532] nouveau 0000:00:0a.0: DRM: DCB outp 04: 02822f66 04400010
[   48.233254] nouveau 0000:00:0a.0: DRM: DCB outp 05: 02022f62 00020010
[   48.238024] nouveau 0000:00:0a.0: DRM: DCB outp 06: 02833f76 04400020
[   48.238700] nouveau 0000:00:0a.0: DRM: DCB outp 07: 02033f72 00020020
[   48.239371] nouveau 0000:00:0a.0: DRM: DCB outp 15: 01df4ff8 00000000
[   48.240042] nouveau 0000:00:0a.0: DRM: DCB conn 00: 02000046
[   48.240640] nouveau 0000:00:0a.0: DRM: DCB conn 01: 01000146
[   48.241221] nouveau 0000:00:0a.0: DRM: DCB conn 02: 00010246
[   48.241807] nouveau 0000:00:0a.0: DRM: DCB conn 03: 00020346
[   48.242394] nouveau 0000:00:0a.0: DRM: DCB conn 04: 00000470
[   48.242985] nouveau 0000:00:0a.0: DRM: Pointer to flat panel table invalid
[   48.523212] nouveau 0000:00:0a.0: DRM: unknown connector type 70

Apparenlty, the "fallback" bypasses the blacklisting entirely. Not good. Will attempt to completely uninstall nouveau.

Uninstalled nouveau. Screen is still entirely black. Starting X manually gives me an error:

[root@f25-turbo ddd]# startx
xauth:  file /root/.serverauth.5187 does not exist
xauth:  file /root/.Xauthority does not exist
xauth:  file /root/.Xauthority does not exist

X.Org X Server 1.19.3 Release Date: 2017-03-15 X Protocol Version 11, Revision 0 Build Operating System: 4.9.3-200.fc25.x86_64 Current Operating System: Linux f25-turbo.dinechin.lan 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-4.10.8-200.fc25.x86_64 root=UUID=7b7d6716-597f-488e-9e4e-53f44b56550b ro rootflags=subvol=root console=ttyS0 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau Build Date: 15 March 2017 06:37:12PM Build ID: xorg-x11-server 1.19.3-1.fc25 Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 16:09:12 2017 (==) Using config file: "/etc/X11/xorg.conf" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) no screens found(EE) (EE) Please consult the Fedora Project support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error

The /var/log/Xorg.0.log complains that no screens were found:

Fatal server error:
[   175.993] (EE) no screens found(EE)
[   175.993] (EE)

The card is clearly detected, and the 381.22 driver does load:

[   175.948] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[   175.948] (II) xfree86: Adding drm device (/dev/dri/card0)
[   175.948] (II) xfree86: Adding drm device (/dev/dri/card1)
[   175.954] (--) PCI:*(0:0:2:0) 1af4:1050:1af4:1100 rev 1, Mem @ 0xf2000000/8388608, 0xf2800000/8388608, 0xfe078000/4096, BIOS @ 0x????????/131072
[   175.954] (--) PCI: (0:0:10:0) 10de:1430:10de:1190 rev 161, Mem @ 0xfd000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, I/O @ 0x0000c000/128, BIOS @ 0x????????/131072
[   175.954] (II) LoadModule: "glx"
[   175.955] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[   175.958] (II) Module glx: vendor="NVIDIA Corporation"
[   175.958] 	compiled for 4.0.2, module version = 1.0.0
[   175.958] 	Module class: X.Org Server Extension
[   175.958] (II) NVIDIA GLX Module  381.22  Thu May  4 00:17:15 PDT 2017
[   175.958] (II) LoadModule: "nvidia"
[   175.958] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
[   175.958] (II) Module nvidia: vendor="NVIDIA Corporation"
[   175.958] 	compiled for 4.0.2, module version = 1.0.0
[   175.959] 	Module class: X.Org Video Driver
[   175.959] (II) NVIDIA dlloader X Driver  381.22  Wed May  3 23:53:41 PDT 2017
[   175.959] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[   175.993] (EE) No devices detected.
[   175.993] (EE)
Fatal server error:
[   175.993] (EE) no screens found(EE)
[   175.993] (EE)
Please consult the Fedora Project support
	 at http://wiki.x.org
 for help.
[   175.993] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   175.993] (EE)
[   176.031] (EE) Server terminated with error (1). Closing log file.
1

Here are the things I tried:

  • Add modprobe.blacklist=nouveau and rd.driver.blacklist=nouveau to the Linux command line.
  • Add blacklist nouveau to /etc/modprobe.d/blacklist.conf
  • Add nomodeset to command line, as it is said to make the NVIDIA driver fail.
  • Uninstall nouveau with dnf remove xorg-x11-drv-nouveau-1:1.0.13-1.fc25.x86_64
  • Rebuild the GRUB configuration with grub2-mkconfig -o /etc/grub2.conf
  • Rebuild the initramfs with dracut -f --kver `uname -r`
  • Reboot in 4.8 kernel
  • Reinstall NVIDIA driver 381.22 on top of 4.8 kernel

That last step apparently did the trick. FINALLY!!!!

Published projects

Tried to update both GitHub and GitLab with the projects I made some contributions to recently (BTRFS, Mesa, autoconf). It looks like there is absolutely no reaction to my autoconf patch (GNU Bug 25740).

vGPU video

The vGPU demo that was given at Red Hat Summit is here:

I learned several things by watching this video. One of them was the existence of the command watch.

Star Trek: Discovery Trailer?

Seen on Slashdot, but does not work for me? Not accessible from France, or taken down?

Found one that works, though:

SharingDaily

Thursday, May 18, 2017

Trying to spend more time sharing the stuff I did.

Gitlab

On GitLab, projects are private by default. So I imported tons of projects from GitHub, but they are all marked Private by default. I did not find a good way to batch-mark projects as public. So today, I went ahead and marked them public one by one. It's quite tedious, and the interface takes a couple of seconds per project.xx

Spice macOS enablement

Yet another iteration on this one. I'm spending more time on this than I thought I would, but that's part of the learning process I guess.

Old machines repair

Since I can't connect with virt-manager from Muse for whatever reason (it keeps asking for software), I thought I'd try to reinstall Shuttle. Since I moved its primary disk to Turbo, I needed to add an old disk in it. Hopefully, one of my old disks will be good enough

Turbo enablement

The reason for trying to bring up one other machine is to get virt-manager to connect to Turbo and create my new VM. But I keep running into another problem, that virt-manager seems to be crashing.

Filed it as rhzb1452211.

I rebooted the f25-turbo guest several times, and after changing the grub command line to make it more verbose (I added console=ttyS0 to GRUB_CMDLINE_LINUX in my /etc/sysconfig/grub then ran grub2-mkconfig -o /etc/grub2.cfg), I finally got the capability to type in the login window. I don't think the two were related. I was attempting multiple things. One of them probably worked.

With the console=ttyS0 option, I can now virsh console f25-turbo and get my console output. Easier for copy-paste.

The verbose output from my guest is interesting:

[   49.972137] nouveau 0000:00:0a.0: fifo: SCHED_ERROR 08 []

[ 49.973820] nouveau 0000:00:0a.0: fifo: SCHED_ERROR 08 [] [ 49.975501] nouveau 0000:00:0a.0: fifo: SCHED_ERROR 08 []

So maybe I should disable nouveau in the guest too. Right now I suspect this may be the root cause of my issues with that guest. I need to install the NVIDIA driver anyway, so I might as well do that.

3D in the darkDaily

Wednesday, May 17, 2017

Turbo in text-only mode

Turbo is now booting in text-only mode, with a guest that has exclusive access to the NVIDIA M2000 card.

Refining patches

Refining my macOS enablement patches for spicy.

Dedicated NVIDIA card mapping on Turbo

I can connect to my f25-turbo guest with spice, and I see a graphic display. But I cannot login. It does not seem to take keyboard or mouse input.

Apparently, it successfully mapped the NVIDIA card. Here is dmesg on the host:

[May17 11:01] VFIO - User Level meta-driver version: 0.3
[  +0.014174] vfio-pci 0000:03:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.011820] vfio_pci: add [10de:1430[ffff:ffff]] class 0x000000/00000000
[  +0.000084] vfio_pci: add [10de:0fba[ffff:ffff]] class 0x000000/00000000
[  +0.539013] vfio_ecap_init: 0000:03:00.0 hiding ecap 0x1e@0x258
[  +0.000085] vfio_ecap_init: 0000:03:00.0 hiding ecap 0x19@0x900
[  +0.001086] pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override.

The 10de:1430 PCI ID is the M2000 card.

I can ssh into the guest too. But lspci seems to hang.

There are appropriate entries under /sys:

# echo /sys/bus/pci/devices/*/vendor
/sys/bus/pci/devices/0000:00:00.0/vendor
/sys/bus/pci/devices/0000:00:01.0/vendor
/sys/bus/pci/devices/0000:00:01.1/vendor
/sys/bus/pci/devices/0000:00:01.3/vendor
/sys/bus/pci/devices/0000:00:02.0/vendor
/sys/bus/pci/devices/0000:00:03.0/vendor
/sys/bus/pci/devices/0000:00:04.0/vendor
/sys/bus/pci/devices/0000:00:05.0/vendor
/sys/bus/pci/devices/0000:00:06.0/vendor
/sys/bus/pci/devices/0000:00:06.1/vendor
/sys/bus/pci/devices/0000:00:06.2/vendor
/sys/bus/pci/devices/0000:00:06.7/vendor
/sys/bus/pci/devices/0000:00:07.0/vendor
/sys/bus/pci/devices/0000:00:08.0/vendor
/sys/bus/pci/devices/0000:00:09.0/vendor
/sys/bus/pci/devices/0000:00:0a.0/vendor
/sys/bus/pci/devices/0000:00:0b.0/vendor

It seems to have initialized somewhat properly too:

# cat /sys/bus/pci/devices/0000:00:0b.0/driver/module/initstate
live

Managing the system remotely proves difficult.

  • When I run virt-manager over X11, the virt-manager window opens, but it complains that it can't find a polkit agent to authenticate.
  • If I do a ssh -Y root@turbo, then the virt-manager window does not open. It's a behavior that I had already observed: when I had a graphical console, it ignored the DISPLAY variable and went straight to the local display (another "security" feature? presumably).
  • So I restarted Muse and tried to connect from it using a remote session. But then I hit another bug that I had not seen before: it shows a very rapid loop with a notification that virt-manager requires another software. The notification is dismissed as soon as it appears. So there is no way to know which software is missing.

I love it when multiple bugs combine perfectly to get in the way. So many ways to achieve my objective, none of them work, most of them fail due to some inane sense of "increased security because we know better than you do".

Happy Birthday GregoireDaily

Tuesday, May 16, 2017

Today is Gregoire's birthday. Happy Birthday, and thanks for being in the world!

M2000 enablement

I keep going, step by step, to get

I had to ask Frediano for help to know which branch exactly was the right one. It turns out that he's rebasing his work all the time, so my heuristic for finding the most recent branches (git show on the remote branches) totally failed.

Everything is in Frediano's repository. The correct branch to pick is nvidia for spice-server and steam for spice-protocol.

Uri's documentation for setting up M2000 needs one extra step:

[root@turbo ddd]# dracut -f --kver `uname -r`

dracut: Can't write to /boot/8eaac32951164615ada69ba680c64466/4.10.14-200.fc25.x86_64: Directory /boot/8eaac32951164615ada69ba680c64466/4.10.14-200.fc25.x86_64 does not exist or is not accessible.

Also, the documentation refers to virsh enable, I think it means virsh start (the virsh enable command does not seem to exist).

Tried to start f25-turbo guest. It worked. I can connect to it with Spice, but I don't get any keyboard input. I tried both with the macOS spicy and with the Linux version. Both apparently have the same problem.

x11spice display issue

I've been trying to use x11spice as my primary display server, and frankly, it's practically unusable. So I need to fix that first, before I attack sound and most acceleration for macSpice.

Current default: graphical.target

Lunch with Jerome and Francois

Had a very nice lunch with Jerome Forissier and Francois Donze at the Open Ditch restaurant, which I visited for the first time. Quite nice.

Francois Donze once more astonished me with his mastery of various advanced topics, like non-volatile memories, high-performance benchmarking, etc. This reminded me of just how much his insight on how customers would actually use our stuff was critical to the success of HPVM.

Undocumented thingsDaily

Monday, May 15, 2017

Attempted to setup the M2000 as indicated in Uri's notes. Ran into issues very early, with the step about building the spice-server. I get various compilation failures, that make me wonder which branch is the correct one.

Spent some time rebasing and re-testing the recorder branch. I'm still tring to figure out how to record dynamically allocated C strings efficiently. The whole point of the recorder is to avoid doing the formatting as we go.

Yet another case of Mac reboot, this time to get BlueJeans working. The symptoms were similar to what I saw with Mail.app, i.e. compilations in bash dying with "resource temporarily unavailable" and applications misbehaving at random. Trying to start BlueJeans did not even show the icon bouncing in the Dock, even if the process showed up in the process list. Weird.

SpiceDaily

Friday, May 12, 2017

Spice for macOS

Some testing of this setup.

I figured out what the problem had been all along. While preparing the macOS patches for submission to the spice-devel mailing list, I naturally tested them on Linux. And at some point, I noticed that I had introduced a bug in the patch dealing with cast warnings. I did not immediately realize because I was not testing the same way, but this was the same bug that had blocked me all along on the Mac side. And even if the symptoms were practically similar on Linux, for some reason I did not immediately realize that.

This vastly simplifies my test setup, because now I can have the Spice server and client in the same room, connected to nearby screens. The server is also physically connected to the same screen I typically use for client testing, which will allow me to check things like color fidelity. Not an immediate concern, but useful until I devise a setup with two identical screens.

There is a small issue that I can't get sound in the Mac version.

So I thought I'd immediately replace VNC with Spice to connect to my remote desktop. And I hit a a small snag.

x11spice: can't connect anymore

For some reason, I can no longer connect to the Spice server opened by x11spice. I can connect locally, i.e. running Spice over X11 locally works. But I can't connect remotely anymore. If it's a firewall issue, it is not an entirely simple one because:

  • I can connect to a VM with spice on the Mac (i.e. port 5902 works, but the ports 5909 or 5944 I used for my x11spice server don't)
  • It worked yesterday.

This is not the first time I notice something like this happening. It's like the firewall / iptable rules were somehow messed up over time.

After investigating with lsof -i -P | grep -i listen, I noticed something odd:

x11spice  24332  ddd   13u  IPv6 351003      0t0  TCP localhost:5944 (LISTEN)
vino-serv 25073  ddd   12u  IPv6 357961      0t0  TCP *:5900 (LISTEN)
vino-serv 25073  ddd   13u  IPv4 357962      0t0  TCP *:5900 (LISTEN)

So the problem is on the server side. I had launched x11spice with the following command yesterday too:

x11spice --password-file=- localhost:5944

Why it worked yesterday and no longer today is a bit of a mystery to me. But if I launche x11spice with the following command, it works:

x11spice --password-file=- '*:5944' --allow-control

It's a good thing. Now I can test Spice for real. On a YouTube video, I have some serious glitches with an x11spice server which I don't see when connecting to a guest. I also see them (although way more slowly) if I connect with the Linux version of Spice over X11.

Turbo setup: sound

Got sound working on Turbo, mostly a matter of drawing the right cables from my amplifier to the PC. Which involved a little bit of furniture shuffling, as the cable is just long enough. So now I can switch sound input between the Mac and the PC, which will allow me to compare sound if I get the mac Spice client to do sound.