Blithe Field – Bible School

Discovered the floaty/glitchy ambient of Spencer Radcliffe (aka Blithe Field) the other day – so after listening to a bunch (it makes for relaxing coding music) I picked up a few albums over on bandcamp today.

It’s pay-what-you-like, so technically you can enter 0 to get them all for free – but that’s not really in the spirit of supporting artists, is it?

Anyhoo – this is definitely one of my current favourites. Lots of nice samples, fun drums, beautiful warbling melodies – it’s got the lot:

Delightful! =D

How To: Connect to a Linux shared drive from a Windows guest in VMware

I always forget how to do this, so I’m writing it down…

1 – Getting and installing VMware Tools

First, we’ll need the VMware Tools installed. If VMware is being a dick and failing to get the tools ISO automatically then you can power down the VM, then in the main VMware Player window before you’ve opened any VM up, go to File | Player Preferences and click [Download All Components Now].

Once done, the iso files will be in a location such as: /usr/lib/vmware/isoimages. In this case (with a Windows 10 guest) I want the windows.iso image – so launch the VM, mount the ISO (from Virtual Machine | Removable Devices | CD/DVD | Settings…) then go to “This PC”, right-click on the mounted drive and select “Open Autoplay…” and let it install.

Update – 2017-03-03

Sometimes VMware tools is also a dick and needs repairing, so do the above but select the “Repair” option to uninstall/re-install it, then power down the VM.

As I found out today, the repair option is rubbish and doesn’t work – to get mapping of network drives working if it isn’t already you need to completely uninstall VMware tools in your guest OS, then reboot, then reinstall VMware tools, then reboot again. On this final reboot (and assuming you have the ‘Map to network drive’ option ticked in your VM settings – see below) then it should all be sorted and if you go to My PC | Network you should see a vmware-host folder which is mapped to Z: (by default – map it to something else if you want to) – from which you can then use Z:\WHATEVER_SHARE_NAME_YOU_GAVE to access your shared folders.

2 – Enabling Shared Folders

With the VM still off, go to the settings for your virtual machine select the Options tab and then the Shared Folders option, then select the “Always Enabled” radio-button. Now add a folder to share and give it a friendly name, I chose “Linux” and pointed it at my linux user’s home folder (so for me that’d be “/home/r3dux”).

I haven’t been able to get the “Map as a network drive in Windows guests” option working for a while, but it shouldn’t be a massive problem as you can access it via the double-backslash notation in the next step.

3 – Access the shared folder from the guest

Boot up your VM (i.e. Windows guest), and from the search bar or URL entry in windows explorer enter:

\\vmware-host\Shared Folders\

So for example, I’d access my shared folder via going to:

\\vmware-host\Shared Folders\Linux

This should work, or at least it works fine for me. However, if I try to map the drive – like if I want to map that location to Z:, and I enter the exact same (known working) path to the shared folder… it doesn’t work. And I have absolutely no idea why. If you let the troubleshooter run it just shrugs at you, which to be fair is basically all any Windows troubleshooter has pretty much ever done in my experience.

To access the network shared folder easily without assigning a drive letter you can just go up one level (i.e. to \\vmware-host\Shared Folders) and then right-click on your shared folder and choose to send a shortcut to the windows desktop, from which you can access it easily enough just like any other folder.

Wrap Up

Hope this gets things working for you, even if it won’t map the drive to a letter for some bizarre reason. If you figure out why that might be I’d love to know!.

Cheers!

How To: Fix Eye of Gnome / Cairo crashes when loading large images

If Eye of Gnome is crashing when attempting to load large images (think 10MB and up), you can typically fix it by modifying the kernel SHM (shared memory) settings – in this case upping the max shared memory to 512MB thus:

Try adding the following to /etc/sysctl.conf and run ‘sysctl -p’ or reboot:

kernel.shmmax=536870912

Source: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1241752/comments/4

This worked for me, so hopefully it’ll work for you also.

Cheers!

How To: Fix Intel 8260 (rev 3a) slow / rubbish wireless issues in Linux

My laptop has an Intel Corporation Wireless 8260 (rev 3a) wireless card. It says so right in the lspci -v output:

02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
	Subsystem: Intel Corporation Dual Band Wireless-AC 8260
	Flags: bus master, fast devsel, latency 0, IRQ 327
	Memory at dc400000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number a4-34-d9-ff-ff-38-91-54
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [154] L1 PM Substates
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

However, in Linux it’s been dropping out and going slow and all sorts of rubbish. Looking in dmesg you can typically see stuff like (edited):

Loaded firmware version: 22.361476.0
iwlwifi 0000:02:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
Lots more red text here...

So can we fix it? Like Bob the Builder, yes we can – but it’s a two-step…

Part 1 – Kernel Modules

The 8260 card uses the iwlwifi kernel module, and the microcode for that is stored in /lib/firmware.

Specifically, you’re looking for the files: iwlwifi-8000C-SOME_NUMBER.ucode.

So for example, I see the following:

r3dux [ /lib/firmware ]$ ls -alh /lib/firmware/iwlwifi-8000C*
-rw-r--r-- 1 root root 1.7M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-13.ucode
-rw-r--r-- 1 root root 2.3M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-16.ucode
-rw-r--r-- 1 root root 2.3M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-21.ucode
-rw-r--r-- 1 root root 2.1M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-22.ucode

The kernel seems to pick the highest number in the 8000C range, so it’ll pick the 8000C-22 variant. Only this is borked. To revert to the previous 21 revision, simply rename the file extension of the 22 version to something different, for example:

sudo mv /lib/firmware/iwlwifi-8000C-22.ucode /lib/firmware/iwlwifi-8000C-22.ucode.BORKED

However, at least in my experience, this isn’t enough to stop the module crash/restart issues – so we need to…

Part 2 – Disable Wireless N

If I just do the above, I still get issues in dmesg where the wireless card’s crashing and resetting itself – so to bypass the failing code, we need to disable wireless N (and only use B/G). Sure, this is going to be slower than N, but it’s going to be faster than a borked version of N – so off we go…

The parameters to the iwlwifi module include one called 11n_disable – and to set that on boot we need to have a /etc/modprobe.d folder (create the directory if necessary), then into that put a file with any name ending in .conf such as iwlwifi.conf (makes sense, right?) with the following contents:

options iwlwifi 11n_disable=1

Once that’s in and saved, reboot and your wireless should work properly again – no dmesg crash data, no slow-downs, no bullshit.

There are actually a few different values that can be used, but “1” works for me. The array of valid values for the 11n_disable property can be seen by entering:

modinfo iwlwifi

And the current settings can be checked by hitting:

systool -v -m iwlwifi

With the 21 revision of the microcode and wireless-N disabled you should find your wireless card now works properly. Huzzah!

Misc

You may want to know that I did this on an Arch Linux system (kernel: 4.8.13-1-ARCH linux-firmware: 20161005.9c71af9-1), and that I also set my regulatory authority code which controls allowable wireless frequencies/channels (via installing the crda package and setting the config to my local country, which is Australia, so “AU” – further reading: https://wiki.archlinux.org/index.php/Wireless_network_configuration#Respecting_the_regulatory_domain) – although I’m not sure if changing the regulatory domain actually did anything to the above fix instructions. Thought I’d mention it all the same.

Cheers!