Kernel 3.19-rc6 – Good News for NVIDIA..

Updated to Kernel 3.19-rc6 on the test system, and – at last – the problem with NVIDIA driver GPL inconsistency has been fixed, and now driver 346.35 compiles and loads OK..

Details of changes since -rc5 are here:   http://lkml.iu.edu/hypermail/linux/kernel/1501.3/00776.html

And the important change is that /arch/x86/mm/init.c now has EXPORT_SYMBOL(__cachemode2pte_tbl) instead of EXPORT_SYMBOL_GPL(__cachemode2pte_tbl)..etc..

VMware 11 – with the vmnet changes mentioned in a previous post (http://rglinuxtech.com/?p=1281) compiles and loads/runs OK..

Robert Gadsdon.   January 26, 2015.

 

VMware – Backward-Compatible 3.19 Fix..

After the solution to the Kernel 3.19/vmnet problem mentioned in previous posts, I have produced a fix that includes tests for kernel versions, and works with Kernel 3.19 and with earlier kernel versions..

This is probably not the most elegant code, but it works – I have tested it with VMware 11.0 and Kernels 3.19-rc5 and 3.18.3 (from kernel.org)..

In vmnet-only/driver.c – around line 267
change:

if (filp && filp->f_op && filp->f_op->ioctl == VNetFileOpIoctl) {
 ret = VNetFileOpIoctl(filp->f_dentry->d_inode, filp, iocmd, ioarg);
 }
 return ret;
}

to:

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 19, 0)
 if (filp && filp->f_op && filp->f_op->ioctl == VNetFileOpIoctl) {
 ret = VNetFileOpIoctl(filp->f_dentry->d_inode, filp, iocmd, ioarg);
 }
 return ret;
#else 
 if (filp && filp->f_op && filp->f_op->ioctl == VNetFileOpIoctl) {
 ret = VNetFileOpIoctl(filp->f_path.dentry->d_inode, filp, iocmd, ioarg);
 }
 return ret;
#endif
}

And, around line 1194
change:

if (filp && filp->f_dentry) {
 inode = filp->f_dentry->d_inode;
 }
 err = VNetFileOpIoctl(inode, filp, iocmd, ioarg);
 return err;

to:

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 19, 0)
 if (filp && filp->f_dentry) {
 inode = filp->f_dentry->d_inode;
 }
 err = VNetFileOpIoctl(inode, filp, iocmd, ioarg);
 return err;
#else 
 if (filp && filp->f_path.dentry) {
 inode = filp->f_path.dentry->d_inode;
 }
 err = VNetFileOpIoctl(inode, filp, iocmd, ioarg);
 return err;
#endif

In vmnet-only/userif.c – around line 526
change:

return skb_copy_datagram_iovec(skb, 0, &iov, len);

to:

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 19, 0)
 return skb_copy_datagram_iovec(skb, 0, &iov, len);
#else
 struct iov_iter to;
 iov_iter_init(&to, READ, &iov, 1, len);
 return skb_copy_datagram_iter(skb, 0, &to, len);
#endif

Basically, test for kernel version prior to 3.19, and if found, use the ‘old’ code, otherwise, use the ‘new’ code..

Once again, thanks are due to Al Viro and coderus for the fix for skb_copy_datagram_iovec..

Hopefully this makes sense!

Robert Gadsdon   January 23, 2015.

VMware 11 – Fix for vmnet and Kernel 3.19..

Thanks to Al Viro, and to coderus on the VMware forum, we now have a solution for vmnet and Kernel 3.19, as follows:

In vmnet-only/driver.c (lines 269, 1194, and 1195):

Replace instances of f_dentry with f_path.dentry

In vmnet-only/userif.c (line 526):

Replace 
   return skb_copy_datagram_iovec(skb, 0, &iov, len);
with
   struct iov_iter to;
   iov_iter_init(&to, READ, &iov, 1, len);
   return skb_copy_datagram_iter(skb, 0, &to, len);

The VMware forum thread can be found here: https://communities.vmware.com/message/2469395

I have made these changes on my test system with Kernel 3.19-rc5, and VMware 11.0 (including vmnet) now compiles and loads/runs OK..

Note that for a complete solution, backward compatible with kernels prior to 3.19, then if/then/else tests for kernel version, and including the ‘old’ or ‘new’ code, will have to be added..

Robert Gadsdon.    January 22, 2015.

ARM – Odroid U3 to 3.19-rc5

Updated the Odroid U3 to the patched version of 3.19-rc5, from here: https://github.com/tobiasjakobi/linux-odroid/tree/odroid-3.19.y

Fedora release 21 (Twenty One)
Kernel 3.19.0-rc5 on an armv7l (ttySAC1)
....................
[root@rgodroid ~]# uname -a
Linux rgodroid 3.19.0-rc5 #1 SMP PREEMPT Wed Jan 21 17:11:42 EST 2015 armv7l armv7l armv7l GNU/Linux

Fairly stable, but got the occasional BUG:

# [ 123.955111] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
[ 123.957827] in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: mmcqd/0
[ 123.964503] Preemption disabled at:[< (null)>] (null)
[ 123.969794]
[ 123.971273] CPU: 0 PID: 77 Comm: mmcqd/0 Not tainted 3.19.0-rc5 #1
[ 123.977436] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
..etc..............

I had tried the standard kernel.org version, and the boot process started OK, but then ‘tombstoned’, and rebooted:

[ 5.454777] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[ 5.454777]
[ 5.458303] CPU: 2 PID: 1 Comm: init Not tainted 3.19.0-rc5 #1
[ 5.464098] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
........................
(arch_cpu_idle+0x44/0x48)
[ 5.845592] [<c000ac24>] (arch_cpu_idle) from [<c00628bc>] (cpu_startup_entry+0x22c/0x418)
[ 5.853839] [<c00628bc>] (cpu_startup_entry) from [<c000fbd0>] (secondary_start_kernel+0x14c/0x158)
[ 5.862866] [<c000fbd0>] (secondary_start_kernel) from [<40008824>] (0x40008824)
[ 5.870247] Rebooting in 5 seconds..

By contrast, the CuBox-i4 Pro can now boot and run standard kernel.org 3.19-rc kernel versions successfully….

Robert Gadsdon.    January 22, 2015.

 

NVIDIA – New Driver 346.35, Still Fails with 3.19-rc..

Tested the lates NVIDIA driver (346.35) today, and although it fixes the f_dentry error, the compile still fails with Kernel 3.19-rc4, due to the incompatible GPL problem:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__cachemode2pte_tbl'
/usr/src/linux-3.19-rc4/scripts/Makefile.modpost:90: recipe for target '__modpost' failed

It has been pointed out that this can be fixed by simply changing the license type, but this is ‘illegal’, and not recommended..

Robert Gadsdon.  January 17, 2015

Kernel 3.19-rc4 – OK on CuBox-i4 Pro.. No fixes yet for NVIDIA and VMware on x86..

Updated the test system to Kernel 3.19-rc4, and the same comments apply as for -rc3..  Still no fixes for NVIDIA and VMware, yet..

I tried the CuBox-i4 Pro with a ‘standard’ kernel from kernel.org, rather than the ‘patched’ version used previously, and it booted OK..

Fedora release 21 (Twenty One)
Kernel 3.19.0-rc4 on an armv7l (ttymxc0)
.............
$ uname -a
Linux rgcubox 3.19.0-rc4 #2 SMP Sun Jan 11 20:27:21 EST 2015 armv7l armv7l armv7l GNU/Linux

Details of -rc3 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1501.1/02001.html

And -despite what you may have read elsewhere – there is still no real fix for the ‘lockup’ problem…

It may possibly be that not running systems as just ‘preempt’ may help to mitigate the problem, and I have been running 3.18.2 like this on my main system for a couple of days now, with no lockups – so far!

CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set

Robert Gadsdon.   January 11, 2015

Kernel 3.19-rc3, ‘Lockup’ Bug, Latest..

Updated the test system to Kernel 3.19-rc3, and there is still no fix for VMware (11.0) and the latest NVIDIA (340.65 and 346.22) drivers…     The NVIDIA problem will involve getting around a GPL-incompatible module issue..

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

3.19-rc3 installs and runs OK on the CuBox-i4 Pro:

$ uname -a
Linux rgcubox 3.19.0-rc3 #1 SMP PREEMPT Tue Jan 6 10:11:36 EST 2015 armv7l armv7l armv7l GNU/Linux

ARM kernel source (patched) can be found here:   https://github.com/jmontleon/fedora-cubox-i_hb/tree/3.19-rc3

Details of changes from -rc2 are here: http://lkml.iu.edu/hypermail/linux/kernel/1501.0/01665.html

The ‘lockup’ problem with kernels 3.17 and later continues to be diagnosed, and the latest info is here:   http://lkml.iu.edu/hypermail/linux/kernel/1501.0/01675.html

Robert Gadsdon.   January 6, 2015.

 

ARM/Intel – CuBox-i4 Pro to 3.19-rc2, VMware and NVIDIA Still Broken..

Updated the test (Intel) system, and the Cubox-i4 Pro to Kernel 3.19-rc2..

NVIDIA and VMware still do not compile (see 3.19-rc1 article for details http://rglinuxtech.com/?p=1258) and – so far – there does not seem to be a patch for either.   The NVIDIA GPL code incompatibility issue may be more convoluted to fix ‘legally’..

I tried more code changes for the VMware problem (replacing skb_copy_datagram_iovec with skb_copy_datagram_msg in userif.c, and got VMware (vmnet) to compile, but it crashed/tombstoned when starting up…

[ 854.004621] general protection fault: 0000 [#2] PREEMPT SMP 
[ 854.004662] Modules linked in: vmnet(O) vmmon(O) fuse vmw_vsock_vmci_transport vsock vmw_vmci cfg80211 nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables uvcvideo videobuf2_vmalloc videobuf2_core videobuf2_memops v4l2_common videodev media hp_wmi sparse_keymap coretemp kvm_intel rfkill kvm iTCO_wdt iTCO_vendor_support pcspkr joydev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_codec_generic lpc_ich snd_hda_intel snd_hda_controller hp_accel snd_hda_codec snd_hwdep mfd_core lis3lv02d snd_seq snd_seq_device video input_polldev snd_pcm wmi shpchp acpi_cpufreq snd_timer snd soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc ax88179_178a usbnet mii radeon i2c_algo_bit
[ 854.005006] drm_kms_helper ttm drm
................................ (cut) ........................
[ 854.005006] Call Trace:
[ 854.005006] [<ffffffff814e8b27>] ? skb_copy_datagram_iter+0x47/0x210
[ 854.005006] [<ffffffffa06df1fd>] ? VNetUserIfRead+0x1bd/0x320 [vmnet]
[ 854.005006] [<ffffffff8109e8a0>] ? wake_up_process+0x50/0x50
[ 854.005006] [<ffffffffa06dc10b>] ? VNetFileOpRead+0x2b/0x60 [vmnet]
[ 854.005006] [<ffffffff81178f4c>] ? vfs_read+0x7c/0x130
[ 854.005006] [<ffffffff8117904d>] ? SyS_read+0x4d/0xc0
[ 854.005006] [<ffffffff815e75a9>] ? system_call_fastpath+0x12/0x17
[ 854.005006] Code: 46 c6 48 85 c0 48 89 c3 0f 84 f0 00 00 00 8b 02 49 89 fe 4c 8b 62 08 a8 04 0f 85 f7 00 00 00 a8 02 0f 85 5f 01 00 00 4c 8b 6a 18 <4d> 8b 7d 08 4d 29 e7 4c 39 fb 4c 0f 46 fb 4d 85 ff 0f 84 94 01 
[ 854.005006] RIP [<ffffffff81137295>] copy_to_iter+0x45/0x280
[ 854.005006] RSP <ffff8800bb853da8>
[ 854.047263] ---[ end trace 9ae51d0fedad2b60 ]---

Obviously, more code changes are needed, and I am not an expert on such details!

At least 3.19-rc2 on the CuBox-i4 Pro runs OK:

$ uname -a
Linux rgcubox 3.19.0-rc2 #1 SMP PREEMPT Mon Dec 29 21:17:00 EST 2014 armv7l armv7l armv7l GNU/Linux

After all the continuing issues with the Odroid U2, the CuBox-i4 Pro has proved very reliable, and relatively easy to keep up-to-date..

Robert Gadsdon.   January 4, 2015

More Fun with Audacity…

This article relates to compilation on the latest Fedora (21) but can also apply to other Distros…

The Distro-supplied version of Audacity is typically functionality-challenged, and does not allow working with some of the more up-to-date audio formats, due to US Patent law concerns..

The necessary functionality can be achieved by compiling it yourself, and this is where the fun starts, as (in)compatibility issues with various versions of ffmpeg arise..

With version 2.0.5, these could be relatively easily fixed by referencing the headers in ffmpeg-compat, but the latest released version (2.0.6) fails with this, as well as with the latest distro-supplied version of ffmpeg..

One workaround mentioned is to configure with --disable-dynamic-loading, but this tends to restrict certain functionality as well..

I finally found an effective patch for Audacity, in the following Forum thread:  http://forum.audacityteam.org/viewtopic.php?f=19&t=82134

The patch file attachment can be found if you scroll down (FFmpeg.patch) and thanks are due to Hains for producing this..

After this patch is applied, Audacity 2.0.6 compiled cleanly on my system with ffmpeg 2.4.5, and now accepts m4a and other formats..

Robert Gadsdon.   December 24, 2014.

ARM – Cubox-i4Pro to Kernel 3.19-rc1..

Just updated the Cubox-i4Pro to 3.19-rc1, after disabling the kernel options for ‘power management’, as the current patch does not compile cleanly..

Fedora release 21 (Twenty One)
Kernel 3.19.0-rc1 on an armv7l (ttymxc0)
...........
[root@rgcubox ~]# uname -a
Linux rgcubox 3.19.0-rc1 #1 SMP PREEMPT Mon Dec 22 15:22:15 EST 2014 armv7l armv7l armv7l GNU/Linux

Details of Kernel 3.19-rc1 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1412.2/02480.html

The (patched) code is available here: https://github.com/jmontleon/fedora-20-cubox-i_hb/tree/3.19-rc1

As limited support seems to be in the mainline kernel.org code, now, I will try that soon..

Robert Gadsdon.   December 21, 2014.