ARM64 – 4.14-rc1 Problems..?

Kernel 4.14-rc1 has been stable on the x86_64 test system, but when I tried updating the Odroid C2 (ARM64) I saw a lot of mmc and other errors reported..

..........
[ OK ] Started File System Check on Root Device.
 Starting Remount Root and Kernel File Systems...
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
print_req_error: I/O error, dev mmcblk0, sector 2048
Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write
EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
...................
[ OK ] Started udev Coldplug all Devices.
[FAILED] Failed to start Load/Save Random Seed.
See 'systemctl status systemd-random-seed.service' for details.
...............
phy phy-c0000000.phy.0: USB ID detect failed!
phy phy-c0000000.phy.0: phy poweron failed --> -22
dwc2: probe of c9000000.usb failed with error -22
..............

Once the system was up, I found that the old Ethernet link problem seemed to have reappeared, and although eth0 seemed to be up, network traffic would cease after a short time..       The system had also switched to a ‘read-only filesystem’…..

So.. I reverted to 4.13.2, and everything was OK, again..     I did not even get a chance to test if hdmi etc. worked at all, this time..

Robert Gadsdon.   September 18, 2017.

NVIDIA – More Details on Kernel 4.14-rc1 Problems..

I have found more comprehensive info on the problems with NVIDIA driver 384.69 and Kernel 4.14-rc1 – here:  http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/

The code changes needed are clearly set out, but there is no ‘legal’ solution yet, due to the unresolved GPL licence issues..

Robert Gadsdon.  September 17, 2017.

VMware – Fix for Kernel 4.14-rc1..

Thanks to Niol for reporting this – and thanks to mkubecek for the patch itself – there is a fix for vmmon with Kernel 4.1.-rc1.   Details are here:   https://github.com/mkubecek/vmware-host-modules/commit/770c7ffe611520ac96490d235399554c64e87d9f

I have created this patch, and applied it to vmmon (hostif.c), and VMware 12.5.7 (with this patch, and the 4.13 vmnet patch) now runs OK on Kernel 4.14-rc1..

Robert Gadsdon.   September 17, 2017.

Kernel – 4.14-rc1 Released – Breaks VMware and NVIDIA.. GPL Errors Again..

Kernel 4.14-rc1 has been released – a day early – and brief details are here:   http://lkml.iu.edu/hypermail/linux/kernel/1709.2/00177.html

Tested with the latest NVIDIA (384.69) and VMware (12.5.7 with 4.13-patched vmnet):

NVIDIA compile failed, in several places:

.....
CC [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.o
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:173:6: error: ‘const struct drm_crtc_helper_funcs’ has no member named ‘enable’; did you mean ‘disable’?
 .enable = nvidia_crtc_enable,
 ^~~~~~
 disable
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:173:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
 .enable = nvidia_crtc_enable,
 ^~~~~~~~~~~~~~~~~~
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:173:19: note: (near initialization for ‘nv_crtc_helper_funcs.mode_valid’)
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c: In function ‘nvidia_plane_create’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:226:9: error: incompatible type for argument 7 of ‘drm_universal_plane_init’
 plane_type
 ^~~~~~~~~~
In file included from /usr/src/linux-4.14-rc1/include/drm/drm_crtc.h:45:0,
 from /usr/src/linux-4.14-rc1/include/drm/drmP.h:69,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-priv.h:30,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14-rc1/include/drm/drm_plane.h:548:5: note: expected ‘const uint64_t * {aka const long long unsigned int *}’ but argument is of type ‘enum drm_plane_type’
 int drm_universal_plane_init(struct drm_device *dev,
 ^~~~~~~~~~~~~~~~~~~~~~~~
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:222:11: error: too few arguments to function ‘drm_universal_plane_init’
 ret = drm_universal_plane_init(
 ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/linux-4.14-rc1/include/drm/drm_crtc.h:45:0,
 from /usr/src/linux-4.14-rc1/include/drm/drmP.h:69,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-priv.h:30,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14-rc1/include/drm/drm_plane.h:548:5: note: declared here
 int drm_universal_plane_init(struct drm_device *dev,
 ^~~~~~~~~~~~~~~~~~~~~~~~
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c: In function ‘nvidia_drm_add_crtc’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:353:11: error: too few arguments to function ‘drm_crtc_init_with_planes’
 ret = drm_crtc_init_with_planes(dev,
 ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/linux-4.14-rc1/include/drm/drmP.h:69:0,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-priv.h:30,
 from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.c:27:
/usr/src/linux-4.14-rc1/include/drm/drm_crtc.h:899:5: note: declared here
 int drm_crtc_init_with_planes(struct drm_device *dev,
 ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-4.14-rc1/scripts/Makefile.build:312: /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel/nvidia-drm/nvidia-drm-crtc.o] Error 1
make[2]: *** [/usr/src/linux-4.14-rc1/Makefile:1498: _module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.69/kernel] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14-rc1'
make[1]: *** [Makefile:145: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14-rc1'
make: *** [Makefile:81: modules] Error 2

I found a combo patch already posted, which included some extra (Gentoo-specific?) compiler options, and some code patches..

https://devtalk.nvidia.com/default/topic/1023822/linux/-patch-384-69-kernel-4-13-4-14-staging-/

I applied the code patches, and everything compiled OK, but then failed with (once again..!.) GPL violation errors:

...........
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'acpi_device_fwnode_ops'
make[3]: *** [/usr/src/linux-4.14-rc1/scripts/Makefile.modpost:91: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.14-rc1/Makefile:1502: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14-rc1'
make[1]: *** [Makefile:145: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14-rc1'
make: *** [Makefile:81: modules] Error 2

The combo patch does include license changes, but these are not legal, so I did not test any further…     The previous time these licensing issues arose, then – eventually – the kernel devs relented, and reverted the changes to the kernel code, but there is – so far – no indication of whether this will happen this time..

VMware patched vmnet compiled/loaded OK, but vmmon failed:

/home/rgadsdon/kernel/vmmon-only/linux/hostif.c: In function ‘HostIF_EstimateLockedPageLimit’:
/home/rgadsdon/kernel/vmmon-only/linux/hostif.c:1597:31: error: implicit declaration of function ‘global_page_state’; did you mean ‘global_numa_state’? [-Werror=implicit-function-declaration]
 unsigned int lockedPages = global_page_state(NR_PAGETABLE) +
 ^~~~~~~~~~~~~~~~~
 global_numa_state
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:312: /home/rgadsdon/kernel/vmmon-only/linux/hostif.o] Error 1
make[1]: *** [Makefile:1498: _module_/home/rgadsdon/kernel/vmmon-only] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14-rc1'
make: *** [Makefile:120: vmmon.ko] Error 2

I did try replacing occurrences of ‘‘global_page_state’ with ‘global_numa_state’, and vmmon compiled and loaded OK, but gave the following memory error when attempting to run a correctly-configured VM:
“Not enough physical memory is available to power on this virtual machine with its configured settings……….”     etc..
So – presumably – this is not the correct solution!

Robert Gadsdon.  September 16, 2017.

Kernel – 4.14 – No More Firmware in Tree

Kernel 4.14-rc1 will soon be out, and one change is the removal of the ‘firmware’ portion of the kernel tree..   # make firmware_install will no longer work.

Apparently, this in-kernel-tree firmware has not been updated since 2013 (!) and all appropriate firmware has been supplied by the ‘linux-firmware’ distro packages for some time..

Details here:   http://lkml.iu.edu/hypermail/linux/kernel/1709.1/04650.html

Robert Gadsdon.   September 15, 2017.

Intel – Fix for Atom MMC/GPT warning..

I had been getting a warning on boot with recent kernels on my Intel Atom-based UP system, and found a workaround..    The error flagged is – apparently – harmless, and is due to systemd not being able to recognise some mmc disk partitions at that stage of the boot process..

......
[ 5.124250] systemd-gpt-auto-generator[416]: Failed to dissect: Input/output error
......

More background details here:   https://github.com/systemd/systemd/issues/5806 – and thanks to kwizart for the suggested fix/workaround..

The workaround is to add systemd.gpt_auto=0 to the kernel command line, and I can confirm that this removes the warning with Kernel 4.13.2 (Fedora 27)

Robert Gadsdon    September 15, 2017

VMware – Still waiting for 12.5.8…

Apparently there is ‘no information’ on the possible availability of an update to the 12.5.x version of VMware, to fix the well-known problems with GCC 7 etc…

If you were thinking of trying the ‘technology preview’ version – which came out some months ago – then this version also has a problem with GCC 7 (tested with Fedora 26, GCC version 7.1.1)

Robert Gadsdon.   September 11, 2017.

Kernel – 4.13 Final Released – Still OK with latest NVIDIA, and Patched VMware..

Kernel 4.13 has been released, and is OK with the latest NVIDIA drivers (tested with 384.69) and VMware 12.5.7 (with the vmnet patch – see http://rglinuxtech.com/?p=2012 )

Brief details of changes since -rc7 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1709.0/01021.html

The VMware workarounds for Fedora 26 / GCC7  etc. are needed, as there is still no update from them..

Robert Gadsdon.  September 3, 2017

Kernel – 4.13-rc6 Released – Still OK..

Kernel 4.13-rc6 is out, and brief details of changes are here:  http://lkml.iu.edu/hypermail/linux/kernel/1708.2/03592.html

As the message mentions, if all goes well, then 4.13 Final should be out in about two weeks time from now..

The release is still OK with the latest NVIDIA (tested with 384.59) and (patched) VMware 12.5.7.     Unfortunately, there is still no 12.5.8 release with compatibility with GCC 7 etc., but workarounds and scripts for this are in previous articles, and comments..

Robert Gadsdon.   August 20, 2017.

Hardware – UEFI Bios for Linux ‘Chromebook’

The original ‘SeaBios’ BIOS on my Acer c720p was a little clunky, so I decided to make the plunge and update it to a ‘proper’ Linux-friendly BIOS..    There is a known/good one available, but it is UEFI-only, so will involve changing the filesystem/partition layout on an existing system..

Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 245453FD-909E-4796-8A0E-1ABD9BB499DB
Device    Start  End       Sectors   Size   Type
/dev/sda1 2048   309247    307200    150M   EFI System
/dev/sda2 309248 250066943 249757696 119.1G Linux filesystem

More details are here:    https://www.reddit.com/r/chrultrabook/comments/4t8kd5/flashing_script_for_uefi_available

To be on the safe side, I downloaded the top-level install script onto a usb ‘recovery’ stick beforehand, and made sure that network support was enabled..  The direct link to the script is at:  https://coolstar.org/chromebook/setup-firmware.sh

As usual, this is not for the faint-of-heart, as you can brick your system!     The script does include the option to backup the ‘old’ bios, and this is always recommended..     It recognised my system and model correctly, and everything went smoothly..     I decided to just do a clean (re)install of the KDE Spin of Fedora 26 from a USB stick, and this also went OK..

# uname -a
Linux rg720 4.13.0-rc4 #1 SMP Thu Aug 10 17:45:38 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

Robert Gadsdon.   August 11, 2017.