NVIDIA – Driver for Kernel 4.7.. Patch for 4.8 Still Works

NVIDIA have released their latest driver – 370.23 – which (finally!) works with Kernel 4.7, without any patches..

The driver fails to compile with Kernel 4.8, but the previous 367.35 patch fixes this (See article here: http://rglinuxtech.com/?p=1788).
Tested with 4.8-rc2:

ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-370.23-patched/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.8-rc2'
make[1]: Leaving directory '/usr/src/linux-4.8-rc2'

Robert Gadsdon.   August 16, 2016.

X86_64 – Up Board – New Pi-Sized System, with Intel Acorn SoC..

Just taken delivery of the Up Board – an Intel Acorn powered SoC system, with the same form factor as a Pi..

UP Board Intel SoC

UP Board Intel SoC

It was quite a novelty to be able to plug a Fedora 24 Live USB stick in, and install directly to the device..      I booted the Live system first, and then used the ‘install to hard drive’ option..     For some reason, the install only worked if I unmounted the main eMMC partition (/dev/mmcblk0p2) first..

When it came to partitioning, the on-board eMMC (32GB) already had a 128MB partition as ‘Microsoft hidden’ and the other 29GB partition as NTFS, so I just changed the 128MB partition to ‘EFI System’ and mounted it as /boot/efi, and made the 29GB partition the standard EXT4-formatted rootfs..

It even has a real bios interface, from another blast-from-the-past – American Megatrends..      In case you were wondering – I left the OS IMAGE ID parameter at ‘Windows 8.1’, as it was working fine, and I didn’t want to mess with anything that worked OK!   Interesting that it had – apparently – detected the Boot Option #1 as ‘Fedora’?



The install completed OK, and even the standard Fedora 24 kernel sort-of worked, although the display was a bit quirky, and attempts to switch out of the HDMI monitor connection caused the system to die..     I decided to try an upgrade to a compiled Kernel 4.8-rc2, and this was much better, with stable display, and ability to operate ‘headless’ if needed..

Fedora 24 (Workstation Edition)
Kernel 4.8.0-rc2 on an x86_64 (tty1)
$ uname -a
Linux rgup 4.8.0-rc2 #1 SMP Mon Aug 15 15:16:23 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

My only real mistake was not ordering the rather proprietary micro-ten-pin UART+USB combo connector at the same time as the rest of the system..   I thought I could modify an existing USB/UART connector, but the on-board connection is really tiny, and the ten-pin connector itself seems very hard to find…   I ended up ordering the combo connector separately, but shipping costs to the USA are rather steep for such an inexpensive item!

The device seems – so far – to be quite powerful, but runs a bit hot, although it is capable of running a full multi-cpu kernel compile onboard, so hopefully the main heatsink – and metal plate attached under the board, will be sufficient..

Robert Gadsdon.    August 15, 2016

KERNEL – 4.8-rc1 Out – Breaks VMware and NVIDIA – and Fixes..

Kernel 4.8-rc1 is out, and brief details are here:   http://lkml.iu.edu/hypermail/linux/kernel/1608.0/04804.html

VMware 12.1.1 – with the previous 4.6/4.7 patches, fails to compile vmmon:

/tmp/modconfig-gfkQLR/vmmon-only/linux/hostif.c: In function ‘HostIF_EstimateLockedPageLimit’:
/tmp/modconfig-gfkQLR/vmmon-only/linux/hostif.c:1597:47: error: ‘NR_ANON_PAGES’ undeclared (first use in this function)

Further research revealed that NR_ANON_PAGES has been changed to NR_ANON_MAPPED in 4.8, and so the fix is quite simple..

In ~/vmmon-only/linux/hostif.c, around line 1594, change
unsigned int anonPages = global_page_state(NR_ANON_PAGES);
unsigned int anonPages = global_page_state(NR_ANON_MAPPED);

With this change, vmmon compiles OK again..

For NVIDIA driver 367.35 – with the 4.7 patches – the compilation fails with 4.8-rc1:

/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.35-patched/kernel/nvidia-drm/nvidia-drm-drv.c: In function ‘nvidia_drm_migrate_modeset_ownership’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.35-patched/kernel/nvidia-drm/nvidia-drm-drv.c:455:26: error: ‘struct drm_minor’ has no member named ‘master’
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.35-patched/kernel/nvidia-drm/nvidia-drm-drv.c:476:5: error: implicit declaration of function ‘drm_master_put’ [-Werror=implicit-function-declaration]
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.35-patched/kernel/nvidia-drm/nvidia-drm-drv.c:476:37: error: ‘struct drm_minor’ has no member named ‘master’

The fix is already documented, thanks to m00ster and andresu on the Devtalk forum, and details are here:  https://devtalk.nvidia.com/default/topic/954279/linux/nvidia-367-35-dkms-build-errors-for-a-4-7-0-kernel/

I have been running driver 367.35 without these particular patches on 4.7 Final, for some time..    I applied the changes – manually – and now 367.35, with the original 4.7 patches plus these patches, compiles OK on 4.8-rc1:

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

Robert Gadsdon.   August 8, 2016.

ARM64 – Hikey to Kernel 4.7 – and Polkitd Fix..

Managed to update the Hikey ARM64 SoC to the latest kernel – 4.7 Final.

Fedora 24 (Twenty Four)
Kernel 4.7.0 on an aarch64 (ttyAMA0)
# uname -a
Linux rghikey 4.7.0 #1 SMP PREEMPT Sun Jul 24 19:53:54 EDT 2016 aarch64 aarch64 aarch64 GNU/Linux

On boot, and when the network initialised, polkitd segfaulted again, the same as when I booted a version of 4.7-next..http://rglinuxtech.com/?p=1767   After a bit of research, I found that this was a userland problem with mozjs17 on ARM64:    https://lists.fedoraproject.org/pipermail/arm/2015-July/009639.html

As this had not been fixed for over a year, I went ahead and applied the patch to the latest mozjs17 source rpm, and rebuilt/updated, and the problem has gone away..

So.. this is (so far..) the only ARM64 device I have that works (headless..) with the mainstream Linux kernel..

Robert Gadsdon.   July 25, 2016.

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
[<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


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)...
Loading file '/boot/zImage' to addr 0x42000000 with size 5619496 (0x0055bf28)...
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)
[ 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.