Kernel – 4.2 Final – Still Breaks NVIDIA…

Tested the 4.2 Final kernel, and the later NVIDIA drivers still fail to install, with the same GPL-only error..

A simple patch to fix this was proposed for 4.2-rc5, some time ago, but – for some reason – has failed to make it into the ‘final’ release..’

Details of the patch are here:  http://lkml.iu.edu/hypermail/linux/kernel/1508.0/02260.html

Maybe this will be fixed in 4.2.1, but maybe we have to wait for 4.3-rc1?

Robert Gadsdon.   August 31, 2015.

VMware – Workstation 12 Pro Released – No Patch Needed..

Just upgraded to VMware Workstation Pro 12.0.0 on the test system, and it compiles and loads/runs OK – with no patches needed – on Kernel 4.2-rc8..

More details are here: http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-12-release-notes.html

Robert Gadsdon.   August 25, 2015.

ARM64 – DragonBoard 410c to Kernel 4.2-rc5..

Just updated the Qualcomm DragonBoard 410c to (patched..) Kernel 4.2-rc5, from here:  https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/shortlog/refs/heads/integration-linux-qcomlt

This time, the boot was successful, and the mmc1 SDcard (rootfs) was recognised correctly..

Fedora release 23 (Twenty Three)
Kernel 4.2.0-rc5 on an aarch64 (ttyMSM0)
.........
]# uname -a
Linux rg410c 4.2.0-rc5 #1 SMP PREEMPT Tue Aug 25 11:38:52 PDT 2015 aarch64 aarch64 aarch64 GNU/Linux

Now, if only this device supported UEFI booting, instead of the android-phone-like fastboot/flash process…!

Robert Gadsdon.  August 25, 2015.

Kernel – 4.2-rc8 – One More Last -rc After All…

Kernel 4.2-rc8 has been released, but does not include the ‘GPL-only’ patch for NVIDIA:  http://lkml.iu.edu/hypermail/linux/kernel/1508.3/00008.html

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'flush_workqueue'

A patch was proposed (for -rc5..) but has still not been incorporated:  http://lkml.iu.edu/hypermail/linux/kernel/1508.2/02297.html

Details of the patch are here:  http://lkml.iu.edu/hypermail/linux/kernel/1508.0/02260.html

Hopefully this patch will be included with 4.2 Final, but there is a possibility that this release will need an additional patch for NVIDIA..

Robert Gadsdon.   August 24, 2015.

ARM – Odroid to 4.2-rc7..

Just updated the Odroid U3 to Kernel 4.2-rc7, from here:  https://github.com/tobiasjakobi/linux-odroid/tree/odroid-4.2.y

Fedora release 23 (Twenty Three)
Kernel 4.2.0-rc7 on an armv7l (ttySAC1)
..................
]# uname -a
Linux rgodroid 4.2.0-rc7 #1 SMP Fri Aug 21 11:30:26 PDT 2015 armv7l armv7l armv7l GNU/Linux

The workflow is as before ( http://rglinuxtech.com/?p=1297 ), with the exception that  # make exynos4412_defconfig is now just
# make exynos_defconfig
, the same as for the kernel.org tree..

Robert Gadsdon.  August 21, 2015

Kernel – 4.2-rc7 – NVIDIA/GPL Issue – Patch Proposed, Not Included Yet..

A simple patch for the GPL-only issue with NVIDIA drivers was submitted on August 4, 2015, but has still not been included with 4.2-rc7..     http://lkml.iu.edu/hypermail/linux/kernel/1508.0/02260.html

The patch has been put forward for 4.3, but there has been a request for it to be included with the upcoming 4.2 release.. http://lkml.iu.edu/hypermail/linux/kernel/1508.0/02703.html

Robert Gadsdon.   August 16, 2015.

Kernel – 4.2-rc6 Still Breaks NVIDIA…

Updated the test system to Kernel 4.2-rc6, and the NVIDIA ‘GPL-Only’ problem still persists:

 Building modules, stage 2. 
  MODPOST 2 modules 
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'flush_workqueue' 
/usr/src/linux-4.2-rc6/scripts/Makefile.modpost:90: recipe for target '__modpost' failed 
make[3]: *** [__modpost] Error 1 
/usr/src/linux-4.2-rc6/Makefile:1389: recipe for target 'modules' failed 
make[2]: *** [modules] Error 2 
make[2]: Leaving directory '/usr/src/linux-4.2-rc6' 
Makefile:146: recipe for target 'sub-make' failed 
make[1]: *** [sub-make] Error 2 
make[1]: Leaving directory '/usr/src/linux-4.2-rc6' 
Makefile:81: recipe for target 'modules' failed 
make: *** [modules] Error 2
There is a ‘hack’ to get VMware 11.1.2 working (see earlier article: http://rglinuxtech.com/?p=1528 ), but – apart from an ‘illegal‘ change of the licence in the source code – there is still no fix..
From previous articles in the NVIDIA/GEForce Forum, it would appear that Kernel devs were already aware of the issue some time ago ( https://forums.geforce.com/default/topic/849487/linux-v4-2-uses-gpl-only-symbol-flush_workqueue-/  ), so hopefully this will be fixed in another -rc..     Looking at the current status of changes to 4.2, I would expect at least another 2 release candidates before 4.2 Final..
Robert Gadsdon.    April 11, 2015.

VMware – Fix for Kernel 4.2..?

Thanks to craigacgomez on the VMware Forum, there is a hack to fix VMware (vmnet) with Kernel 4.2..  https://communities.vmware.com/thread/516196

I made some more changes, to make it backward-compatible, and it seems to work OK with Kernels 4.1.3 and 4.2-rc4..

I should emphasize that I am an amateur at such things, but if you want to try this, then this is what I did, after expanding vmnet.tar:

In vmnet-only/vmnetInt.h..

Around line 79, change:

#ifdef VMW_NETDEV_HAS_NET
# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto,)
#else
# define compat_sk_alloc(_bri, _pri) sk_alloc(PF_NETLINK, _pri, &vmnet_proto, 1)
#endif

to:

#ifdef VMW_NETDEV_HAS_NET
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 00)
# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto, 1)
#else
# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto)
#endif
#else
# define compat_sk_alloc(_bri, _pri) sk_alloc(PF_NETLINK, _pri, &vmnet_proto, 1)
#endif

I have applied this change, and VMware compiles and runs OK on Kernel 4.1.3, and 4.2-rc4..

YMMV…  Usual disclaimer applies!

Robert Gadsdon.    August 1, 2015.

ARM64 – HiKey – Change to UEFI Boot..

After some more testing, including trying (unsuccessfully) the HiKey version of Kernel 4.1-rc4 # git clone -b hikey-mainline-rebase –single-branch https://github.com/96boards/linux/   I was frustrated by the complete lack of kernel boot info on screen, after the proprietary bootloader had finished.. More research found that this bootloader was described as somewhat deficient in the ‘fit for purpose’ department, and I really ought to update to a more effective one…

There is a pre-release version of U-Boot available, but UEFI/grub is also now an option, which made more sense..     The only drawback to the current version of UEFI is that it can only boot from Emmc, not an SD Card, but as long as the kernel image (Image) and dtb (hi6220-hikey.dtb) and initrd are resident on the Emmc boot partition, then the rootfs can still be on the SD Card..     I also created a SWAP file on the Emmc root partition..

[root@rghikey ~]# cat /etc/fstab
/dev/mmcblk1p2  /           ext4  defaults 1 1
/dev/mmcblk1p1  /boot       vfat  defaults 1 2
/dev/mmcblk0p6  /boot-emmc  vfat  defaults 1 2
/dev/mmcblk0p9  /root-emmc  ext4  defaults 1 2
/root-emmc/SWAP none        swap  defaults 0 0

So.. I have the root filesystem on the SD Card, and mount the Emmc boot and root partitions as /boot-emmc and /root-emmc respectively, and then copy the Image and .dtb files to the /boot-emmc partition after compilation..     This is far more useful, as by editing the grub configuration file in the Emmc boot directory (/boot-emmc/grub/grub.cfg) I can arrange for multiple Kernel versions to be available for booting, to fall-back to a known/good version if the boot fails..

$ cat /boot-emmc/grub/grub.cfg 
set default="0" 
set timeout=10 
 
menuentry 'Fedora Linux' { 
    linux /Image console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 rw roo
twait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb 
} 
 
menuentry 'Fedora Linux OLD' { 
    linux /Image.old console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 rw
 rootwait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb.old 
} 
 
menuentry 'Fedora Linux 4.1-rc4' { 
    linux /Image-41rc4 console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 
rw rootwait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb-41rc4 
}
Apart from the multi-version boot convenience, the resulting console output gives far more early-kernel-boot info than the old bootloader, enabling proper diagnosis of boot failures, rather than an empty screen.
Caveats..    You may need to try different versions of the UEFI binaries, as I found that the July 19 version failed, but an earlier version worked OK..    You will also need to connect  a proper uart/usb console to the circuit board, which may involve some careful soldering.. (see previous article http://rglinuxtech.com/?p=1509)
More to come – including the USB port catch-22, and Bluetooth woes..!
Robert Gadsdon.    July 22, 2015.

ARM64 – DragonBoard to 4.2-rc1 – And Back Again..

Updated the DragonBoard 410c to patched Kernel 4.2-rc1 from https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/refs/heads/integration-linux-qcomlt , and the system booted OK:

Fedora release 22 (Twenty Two)
Kernel 4.2.0-rc1+ on an aarch64 (ttyMSM0)
...........
# uname -a
Linux rg410c 4.2.0-rc1+ #2 SMP PREEMPT Thu Jul 16 15:14:27 PDT 2015 aarch64 aarch64 aarch64 GNU/Linux

– But, on further testing, the SD Card (mmc1) had not been detected/connected:

# dmesg |grep mmc
.............................
[ 1.054080] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using ADMA 64-bit
[ 1.114173] mmc1: SDHCI controller on 7864900.sdhci [7864900.sdhci] using ADMA 64-bit
[ 1.124414] mmc0: MAN_BKOPS_EN bit is not set
[ 1.148855] mmc0: new high speed MMC card at address 0001
[ 1.151959] mmcblk0: mmc0:0001 DS2008 7.28 GiB
[ 1.155796] mmcblk0boot0: mmc0:0001 DS2008 partition 1 4.00 MiB
[ 1.163796] mmcblk0boot1: mmc0:0001 DS2008 partition 2 4.00 MiB
[ 1.166340] mmcblk0rpmb: mmc0:0001 DS2008 partition 3 4.00 MiB
[ 1.192548] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
[ 1.332180] mmc1: Reset 0x1 never completed.
[ 1.515375] mmc1: Reset 0x1 never completed.
[ 1.697062] mmc1: Reset 0x1 never completed.
[ 1.888422] mmc1: Reset 0x1 never completed.
............................

So.. Reverted to the qcom-patched 4.0 kernel, again..

This was an issue with the 4.1 patched kernel, as well..    Hopefully this will get fixed soon, now that some patches are entering the official kernel.org tree..

Robert Gadsdon.   July 16, 2015.