KERNEL – 4.7 Released – OK with Patched VMware and NVIDIA..

Kernel 4.7 has been released – slightly later than usual – and brief details are here:  http://lkml.iu.edu/hypermail/linux/kernel/1607.3/00150.html

$ uname -a
Linux rglinux-i7 4.7.0 #1 SMP Sun Jul 24 14:34:37 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

Neither VMware nor NVIDIA have drivers that work with this kernel version, but the 4.7-rc patched versions of VMware 12.1.1 and NVIDIA 367.35 both work OK with 4.7-Final..     For details on these patches, see earlier articles on 4.7-rc1..  http://rglinuxtech.com/?p=1746  http://rglinuxtech.com/?p=1750

I had already created a patched version of the NVIDIA installer (see previous article), and applied it to 4.7:

./NVIDIA-Linux-x86_64-367.35-custom.run -s --install-libglvnd --glvnd-glx-client

Robert Gadsdon.  July 24, 2016.

 

NVIDIA – Latest Driver – Still Fails with Kernel 4.7..

Kernel 4.7-rc7 is out, and 4.7 Final should be next, but the latest NVIDIA driver released – 367.35 – still fails to compile with 4.7-rc7..     The patch for 367.xx still works OK…  Details here:  http://rglinuxtech.com/?p=1750

In case you need to create an executable (NVxx.xxx.run) incorporating the patch, details on how to do this are in an older article.. http://rglinuxtech.com/?p=899

Robert Gadsdon.   July 16, 2016.

 

ARM – Next CHIP – Waiting for Hynix NAND Support..

Tested some of the kernel versions possible (or not..) for the Next CHIP ARMv7, with mixed results..     I added an Ethernet/USB device (ax88179-based) on the USB hub, and the network connection works fine..

Linux-Next does not yet have the drivers for the Hynix NAND in the CHIP, although – with the rootfs separate on a USB stick – this was not an issue, except for updating the NAND-located kernel and dtb..

....
Fedora 24 (Twenty Four)
Kernel 4.7.0-rc7-next-20160713 on an armv7l (ttyS0)
.....................
]# uname -a
Linux rgchip 4.7.0-rc7-next-20160713 #2 SMP Wed Jul 13 21:18:40 PDT 2016 armv7l armv7l armv7l GNU/Linux

There are a confusing multitude of patched kernel sources on the Next GitHub site https://github.com/NextThingCo/CHIP-linux , and those I tried did not compile cleanly, or the NAND/UBIFS mount crashed..

......................
CC lib/plist.o
drivers/mtd/ubi/build.c:48:2: error: #error TODO
 #error TODO
 ^~~~~
scripts/Makefile.build:258: recipe for target 'drivers/mtd/ubi/build.o' failed
make[3]: *** [drivers/mtd/ubi/build.o] Error 1
scripts/Makefile.build:403: recipe for target 'drivers/mtd/ubi' failed
make[2]: *** [drivers/mtd/ubi] Error 2
.................................
[ OK ] Started Permit User Sessions.
ubi0: attaching mtd4
ubi0 warning: __ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ OK ] Started Notify NFS peers of a restart.
[ OK ] Started Network Manager Script Dispatcher Service.
ubi0 warning: __ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
ubi0 warning: __ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ OK ] Started Command Scheduler.
[ OK ] Started Job spooling tools.
ubi0 error: __ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
CPU: 0 PID: 255 Comm: ubiattach Not tainted 4.7.0-rc1++ #3
Hardware name: Allwinner sun4i/sun5i Families
Backtrace:
[<c010b228>] (dump_backtrace) from [<c010b424>] (show_stack+0x18/0x1c)
 r7:00000001 r6:00000000 r5:00000040 r4:ffffffb6
[<c010b40c>] (show_stack) from [<c02f1640>] (dump_stack+0x24/0x28)
[<c02f161c>] (dump_stack) from [<c03c3af0>] (__ubi_io_read+0x260/0x500)
[<c03c3890>] (__ubi_io_read) from [<c03c4550>] (ubi_io_read_ec_hdr+0x50/0x20c)
 r10:00000000 r9:00000040 r8:00000000 r7:ded85000 r6:df7a5c00 r5:d93a4000
 r4:00000000 ..... etc....

I did manage to flash the NAND with a later kernel version – based on 4.4.11…   The process was relatively painless, as the re-flashing is controlled by an easy-to-use plugin/app for Chromium/Chrome browsers.. http://docs.getchip.com/chip.html#flash-chip-with-an-os  This erases and re-creates the NAND rootfs, which would be an issue normally, but as I have the rootfs on the USB stick, I just needed to re-edit the kernel command line parameter in U-boot to point to the rootfs on /dev/sda1 again..

I had hoped to be able to use the redundant space on the NAND for a swapfile, but the UBIFS filesystem does not support the fallocate command..

After all this, I did find some ‘official’ kernel patches being developed for Hynix NAND support, but these are still work-in-progress…    https://patchwork.kernel.org/patch/9187023/  I will probably wait until these are available on Linux-Next, and update the device then..

Robert Gadsdon.    July 14, 2016.

 

 

ARM – Next CHIP ARMv7 – First Impressions..

After pre-ordering one many months ago, I finally got my Next CHIP ARMv7 system in the post..

Next Chip

Next CHIP

It certainly is fairly small, but seems well-constructed..     Details are at http://docs.getchip.com/chip.html#chip-hardware

After connecting the UART/USB cable, as normal, the system booted into a cut-down version of Debian..   There is no hdmi, or sdcard connector, or Ethernet, but the wi-fi connection works as well as can be expected..   Quite a bargain at only $9..   The on-board storage (only 4GB) is in the UBIFS format, and this needed some more research…

The plan – initially – was to get it to boot onto a rootfs on an USB stick (ext4) and run Fedora 24..     This was relatively easy, involving a change to the u-boot bootargs parameter to point to sda1 – the USB stick.

setenv bootargs “root=/dev/sda1 rootfstype=ext4 rootwait rw”

After this, the device booted into Fedora 24:

...............
(FEL boot)
...........................
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=4", size 8176 MiB) to ubi0
UBI: PEB size: 2097152 bytes (4096 KiB), LEB size: 2064384 bytes
UBI: min./max. I/O unit sizes: 16384/16384, sub-page size 16384
UBI: VID header offset: 16384 (aligned 16384), data offset: 32768
UBI: good PEBs: 2044, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1098611298
UBI: available PEBs: 0, total reserved PEBs: 2044, PEBs reserved for bad PEB handling: 40
Loading file '/boot/sun5i-r8-chip.dtb' to addr 0x43000000 with size 22617 (0x00005859)...
Done
Loading file '/boot/zImage' to addr 0x42000000 with size 5619496 (0x0055bf28)...
Done
Kernel image @ 0x42000000 [ 0x000000 - 0x55bf28 ]
## Flattened Device Tree blob at 43000000
 Booting using the fdt blob at 0x43000000
 Loading Device Tree to 49ff7000, end 49fff858 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
.................
Fedora 24 (Twenty Four)
Kernel 4.3.0-ntc on an armv7l (ttyS0)
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 1001.88
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Allwinner sun4i/sun5i Families
Revision : 0000
Serial : 1625428a0982b662

After that, I configured wireless networking, and everything seemed to be OK, but then the device ‘died’ suddenly…   I had read that the USB port was rather low-powered, and so I attached a powered USB2 hub, reattached to USB stick to that, re-booted, and all is well, now..

I installed the mtd-utils-ubi package to handle the UBIFS mount, and added the commands to do this to rc.local, after creating the nand-root mount point..   I will be changing the pre-configured volume name to something other than ‘rootfs’ to avoid confusion..

# ubiattach /dev/ubi_ctrl -m 4
[ 501.640000] ubi0: attaching mtd4
[ 503.080000] ubi0: scanning is finished
[ 503.120000] ubi0: attached mtd4 (name "rootfs", size 8176 MiB)
[ 503.130000] ubi0: PEB size: 4194304 bytes (2048 KiB), LEB size: 2064384 bytes
[ 503.140000] ubi0: min./max. I/O unit sizes: 16384/16384, sub-page size 16384
[ 503.140000] ubi0: VID header offset: 16384 (aligned 16384), data offset: 32768
[ 503.150000] ubi0: good PEBs: 2044, bad PEBs: 0, corrupted PEBs: 0
[ 503.160000] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 503.160000] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1098611298
[ 503.170000] ubi0: available PEBs: 0, total reserved PEBs: 2044, PEBs reserved for bad PEB handling: 40
[ 503.190000] ubi0: background thread "ubi_bgt0d" started, PID 639
UBI device number 0, total 2044 LEBs (4219600896 bytes, 3.9 GiB), available 0 LEBs (0 bytes), LEB size 2064384 bytes (2.0 MiB)
.....................................
# mount -t ubifs ubi0:rootfs /nand-root
[ 634.770000] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 646
[ 636.570000] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 636.580000] UBIFS (ubi0:0): LEB size: 2064384 bytes (2016 KiB), min./max. I/O unit sizes: 16384 bytes/16384 bytes
[ 636.590000] UBIFS (ubi0:0): FS size: 4108124160 bytes (3917 MiB, 1990 LEBs), journal size 18579457 bytes (17 MiB, 9 LEBs)
[ 636.600000] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[ 636.610000] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 6BCEE06C-CCC9-42CF-B11E-A4A92824F204, small LPT model

As the wi-fi connection is so slow, here, I am planning to fit a USB/Ethernet adapter for the network connection – similar to the Hikey and 410c, and – of course – I will be compiling my own kernel..

Robert Gadsdon.  July 11, 2016.

ARM64 – Dragonboard 410c – Fail with Linux-Next..

After the – partial – success with the 96Boards Hikey, I tried the Qualcomm Dragonboard 410c, but the June 29 Linux-Next failed to boot successfully, with only one CPU initialising, and MMC errors, and eventual hang….

.............................
psci: failed to boot CPU1 (-95)
CPU1: failed to boot: -95
CPU1: failed in unknown state : 0x0
psci: failed to boot CPU2 (-95)
CPU2: failed to boot: -95
CPU2: failed in unknown state : 0x0
psci: failed to boot CPU3 (-95)
CPU3: failed to boot: -95
CPU3: failed in unknown state : 0x0
Brought up 1 CPUs
SMP: Total of 1 processors activated.
.................................
sdhci_msm 7864900.sdhci: Got CD GPIO
mmc0: Reset 0x1 never completed.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000
sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci: Present: 0x01f80000 | Host ctl: 0x00000000
sdhci: Power: 0x00000000 | Blk gap: 0x00000000
sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
sdhci: Host ctl2: 0x00000000
sdhci: ===========================================
..............................
(repeated) - then Hang..

These 96Boards-based systems have been available for some time now, but ‘mainstream’ kernel development is very sluggish..

Robert Gadsdon.   July 1, 2016.

ARM64 – Hikey Success, with Linux-Next..

After some time, I decided to test the latest ‘Linux-Next’ with the 96Boards HiSilicon Hikey, and – this time – it booted successfully (headless), with networking..

Fedora 24 (Twenty Four)
Kernel 4.7.0-rc5-next-20160628 on an aarch64 (ttyAMA0)
.......................
# uname -a
Linux rghikey 4.7.0-rc5-next-20160628 #1 SMP PREEMPT Tue Jun 28 22:34:10 EDT 2016 aarch64 aarch64 aarch64 GNU/Linux

Still not completely stable, as polkitd kept throwing a translation fault every time I used dnf..

Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24)
Console:..
[ 77.362100] polkitd[1238]: unhandled level 0 translation fault (11) at 0x7fffb010c040, esr 0x92000004
[ 77.371406] pgd = ffff80003a0ef000
[ 77.374885] [7fffb010c040] *pgd=0000000000000000
[ 77.379536]
[ 77.381073] CPU: 7 PID: 1238 Comm: polkitd Not tainted 4.7.0-rc5-next-20160628 #1
[ 77.388616] Hardware name: HiKey Development Board (DT)
[ 77.393886] task: ffff80003af2d400 ti: ffff800039e08000 task.ti: ffff800039e08000
[ 77.401427] PC is at 0xffffb20e7410
[ 77.404926] LR is at 0xffffb207ba74
[ 77.408420] pc : [<0000ffffb20e7410>] lr : [<0000ffffb207ba74>] pstate: 80000000
[ 77.415822] sp : 0000ffffdb6fa3f0
[ 77.419143] x29: 0000ffffdb6fa7f0 x28: 0000aaaadb404a60
[ 77.424504] x27: 0000aaaadb403120 x26: 0000ffffdb6fa4f0
[ 77.429832] x25: 00007fffb010c040 x24: 0000aaaadb4036a8
[ 77.435160] x23: 0000000000000000 x22: 0000000000000000
[ 77.440496] x21: 0000000000000008 x20: 0000ffffb228c000
[ 77.445825] x19: 0000ffffb228c000 x18: 0000000000000014
[ 77.451155] x17: 0000ffffb20aa738 x16: 0000ffffb228c248
[ 77.456529] x15: 0000000000000020 x14: 0000000000000000
[ 77.461858] x13: 0000000000000000 x12: 0000000000000000
[ 77.467190] x11: 0000000000000000 x10: 0000000000000065
[ 77.472528] x9 : 0000ffffb22991c8 x8 : 0000ffffb2298ca0
[ 77.477861] x7 : 000000000000001b x6 : 0000000000000008
[ 77.483194] x5 : 0000aaaadb4049b0 x4 : 0000000000000000
[ 77.488543] x3 : 0000000000000001 x2 : 0000ffffb275ec60
[ 77.493879] x1 : 0000aaaadb3fee70 x0 : 00007fffb010c040
[ 77.499214]
[ 79.945177] ax88179_178a 1-1.2:1.0 eth0: ax88179 - Link status is: 1

Still, dnf completed successfully, despite this..

This is – so far – the only SoC system I have that boots using grub, but I should be getting a couple of Intel Atom-based systems soon, and I am assuming that these will do the same..    Delivery dates are ‘uncertain’, at present..

Robert Gadsdon.   June 28, 2016.

ARM64 – Pi3 Still Very Unstable..

I have tried the latest 4.7-next patched kernel, from https://github.com/anholt/linux/tree/bcm2837-64-next

After some trials, I did manage to – just – get it to boot – after falling to an ’emergency console’, but the system is very unstable, with multiple recurring MMC errors..

.....
 Give root password for maintenance
 (or press Control-D to continue):
 Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)
 [ 714.545569] mmc0: Timeout waiting for hardware interrupt.
 [ 715.484762] mmcblk0: error -110 transferring data, sector 1026056, nr 16, cmd response 0x900, card status 0xc00
 .........
 Fedora 24 (Twenty Four)
 Kernel 4.7.0-rc3-next-20160615 on an aarch64 (ttyS0)
 ..................

There appear to be two mmc drivers for the PI3 in the selection..

SDHCI platform support for the BCM2835 SD/MMC Controller
and
SDHCI support for the BCM2835 & iProc SD/MMC Controller

Selecting _both_ results in kernel boot with multiple mmc errors, and completes eventually, but is not stable..

Selecting just ‘SDHCI platform support for the BCM2835 SD/MMC Controller‘ gives boot fail with multiple repeating MMC errors..

........
 [ 21.995425] Waiting for root device /dev/mmcblk0p2...
 [ 22.787918] mmc0: problem reading SD Status register
 [ 22.923726] mmc0: error -84 whilst initialising SD card
 [ 27.649114] mmc0: error -84 whilst initialising SD card
 [ 32.397154] mmc0: error -84 whilst initialising SD card
 [ 37.129422] mmc0: error -84 whilst initialising SD card
 [ 41.861163] mmc0: error -84 whilst initialising SD card
 [ 46.581532] mmc0: error -84 whilst initialising SD card
 [ 51.313549] mmc0: error -84 whilst initialising SD card
 << repeated...>>

Selecting just ‘SDHCI support for the BCM2835 & iProc SD/MMC Controller‘ gives partial boot after an emergency console, but then repeated write failures…

 [ 2314.922231] systemd-journald[925]: Failed to write entry (27 items, 745 bytes), ignoring: Read-only file system
 [ 2315.139570] systemd-journald[925]: Failed to write entry (27 items, 749 bytes), ignoring: Read-only file system
 [ 2315.359321] systemd-journald[925]: Failed to write entry (27 items, 750 bytes), ignoring: Read-only file system
 [ 2315.577424] systemd-journald[925]: Failed to write entry (20 items, 618 bytes), ignoring: Read-only file system
 << repeated...>>

I returned to the relatively-stable 4.5.0+ kernel, but even this tombstones every so often, and usually has to be booted via the emergency console..

So – for the time being – I will wait until a more stable patched kernel is available..

Robert Gadsdon.   June 20, 2016.

NVIDIA – New Driver – Still Broken with Kernel 4.7 – Patch Fix OK..

Just tested the latest NVIDIA driver – 367.27 – and it fails to compile with Kernel 4.7-rc3.     To fix this, the patch for 367.18 still works ( details at http://rglinuxtech.com/?p=1750 ).

 ....................
 Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-drm.ko
 CC /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/Desktop/kernel/NVIDIA-Linux-x86_64-367.27.patched/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.7-rc3'
make[1]: Leaving directory '/usr/src/linux-4.7-rc3'

Robert Gadsdon.  June 13, 2016

ARM64 – Pine64 – Not Exactly ‘Compact’..

I recently obtained one of the newly-released (- to the ‘public’..) Pine64 ARM64 systems…    My first reaction, was that it is a bit on the large side..  The board is over twice the size of the Odroid C2..

Pine64 ARM64.

Pine64 ARM64.

As usual, the ‘standard’ U-Boot was a heavily-customised old version, that only mounted Android-format Kernel ‘blob’s, but a hacked version of this – which loads standard ARM64 ‘Image’ kernels, is available, and I used the one from the Debian/Longsleep image referenced on the Wiki:  http://wiki.pine64.org/index.php/Main_Page.

I substituted a Fedora 24 aarch64 root filesystem, and everything worked OK.

Fedora 24 (Twenty Four)
Kernel 3.10.65-7-pine64-longsleep on an aarch64 (ttyS0)

I then tried the patched 4.7-rc1 kernel from here:  https://github.com/apritzel/linux/tree/a64-v5.    I found that this did boot, if the Kernel config was left unchanged after ‘make defconfig’..

Fedora 24 (Twenty Four)
Kernel 4.7.0-rc1+ on an aarch64 (ttyS0)
.............................
# uname -a
Linux rgpine 4.7.0-rc1+ #1 SMP PREEMPT Tue Jun 7 05:01:18 EDT 2016 aarch64 aarch64 aarch64 GNU/Linux

I found that the networking did not work, and so had to select this (ST Microelectronics / STMMAC / Allwinner GMAC), and this is still being tested, along with other deselections of ‘unwanted’ options..    I had originally just selected ‘Allwinner..sunxi..’ under the ‘Platform selection’ option, but this did not boot…      The aprinzel kernel is still very much work-in-progress, and there should be later versions soon..

I did try a patched version of the mainline U-Boot, from here:  https://github.com/apritzel/u-boot/tree/pine64 , and I did get it to load (boot0 plus u-boot image) and run, but the resulting kernel boot (using a known/good kernel) was unsuccessful…

...................
[ 160.236247] platform reg-81x-cs-rtc: Driver reg-81x-cs-rtc requests probe deferral
[ 160.245014] platform reg-81x-cs-aldo1: Driver reg-81x-cs-aldo1 requests probe deferral
[ 160.254129] platform reg-81x-cs-aldo2: Driver reg-81x-cs-aldo2 requests probe deferral
[ 160.263626] platform reg-81x-cs-aldo3: Driver reg-81x-cs-aldo3 requests probe deferral
[ 160.272743] platform reg-81x-cs-dldo1: Driver reg-81x-cs-dldo1 requests probe deferral
[ 160.281947] platform reg-81x-cs-dldo2: Driver reg-81x-cs-dldo2 requests probe deferral
[ 160.291064] platform reg-81x-cs-dldo3: Driver reg-81x-cs-dldo3 requests probe deferral
[ 160.300165] platform reg-81x-cs-dldo4: Driver reg-81x-cs-dldo4 requests probe deferral
[ 160.309310] platform reg-81x-cs-eldo1: Driver reg-81x-cs-eldo1 requests probe deferral
[ 160.318427] platform reg-81x-cs-eldo2: Driver reg-81x-cs-eldo2 requests probe deferral
................. etc...........etc................

One other thing to watch..   I did get the wifi/bluetooth plug-on daughter board, but this became extremely hot, after a short while, and I removed it..

Robert Gadsdon.   January 7, 2016.

Kernel – 4.7-rc2 Released – rc1 Patches Still Work.

Kernel 4.7-rc2 is out and brief details of changes from -rc1 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1606.0/03592.html

After all the later-rc breakage with 4.6, I tested the latest patched NVIDIA drivers, and VMware, with this version, and all the previous 4.6/4.7 patches for VMware 12.1.1, and the 4.7 patches for NVIDIA 367.18 and 361.45.11 still work.   See http://rglinuxtech.com/?p=1748 and http://rglinuxtech.com/?p=1750 for details..

Robert Gadsdon.  June 5, 2016.