I would contribute with some advances. This is not a final result, just a WIP
on my
intent to fix the problem.
Note: I am not a expert, if you try this, it is under your own risk. This could
break
your operating system installation or make it unstable.
This is how I solve the issue for my particular machine, this couldn't be the
same
for your machine or kernel.
1) First download the source and uncompress
sudo apt-get source blcr-dkms=0.8.4-2ubuntu1
cd blcr-*
2) As minor warning, from Perl to 5.13.5 or beyond Debian bug #650522 suggests
surrounding each use of qw(…) with rounded parenthesis: (qw(…)). There are a
couple on
using on acinclude.m4. So I fixed that for avoid the warning.
Ubuntu shipped on Quantal 5.14.2, so it triggers the warning too:
perl -v | grep "(v"
This is perl 5, version 14, subversion 2 (v5.14.2) built for
i686-linux-gnu-thread-multi-64int
3) I discover that the configure has a problem finding the kernel
version path.
/usr/src/linux-headers-3.5.0-3-generic/include/linux/version.h
But in only search on other diferent paths with "cr_linux_dir" on acinclude.m4
without "linux-headers", so I add:
For the first for:
/usr/src/linux-headers-[$1] \
And for the second:
/usr/src/linux-headers-${cr_tmp_ver} \
That enable the searching on 3.x kernels on ubuntu.
4) Next problem is the instruction:
m4_define([cr_kern_maj_min_patt],[[2\.[46]\.]])[]dnl No SUBLEVEL or
following
As pointed on upstream debian bug, it make fails the build (cause of
this bug)
I changed to:
m4_define([cr_kern_maj_min_patt],[[3\.[0-9]\.]])[]dnl No SUBLEVEL or
following
This enable only for 3.X kernels, it could be improved for allow 2.X and 3.X
kernels,
but cafeful because the var cr_kern_maj_min_patt is concatenated for the third
version number.
That enable the part of:
if ((my $uts) = /=${stamp}->"(3\.[0-9]\.[0-9].*)"<-/o) {
For detect the UTS_RELEASE constant.
This constant is defined on
$ cat /usr/src/linux-headers-3.5.0-3-generic/include/generated/utsrelease.h
#define UTS_RELEASE "3.5.0-3-generic"
sudo nano acinclude.m4
sudo ./autogen.sh
5) With this, you can progress configuring the package, but I don't know if it
is a special configuration on my machine (SMP) or others, but it ends with:
======================================================================
Please review the following configuration information:
Kernel source directory = /usr/src/linux-headers-3.5.0-3-generic
Kernel build directory = /usr/src/linux-headers-3.5.0-3-generic
Kernel symbol table = /boot/System.map-3.5.0-3-generic
Kernel version probed from kernel build = 3.5.0-3-generic
Kernel running currently = 3.5.0-3-generic
======================================================================
configure: error: Kernel source is configured uni-processor but the kernel
symbol table is SMP. Consider specifying a symbol table with --with-system-map
or --with-vmlinux. Or, if using kernel sources that are configured by
/boot/kernel.h, you may try --with-kernel-type=SMP to force an SMP
interpretation of the sources.
$ sudo ./configure --with-system-map
configure: error: Kernel source is configured uni-processor but the kernel
symbol table is SMP. Consider specifying a symbol table with --with-system-map
or --with-vmlinux. Or, if using kernel sources that are configured by
/boot/kernel.h, you may try --with-kernel-type=SMP to force an SMP
interpretation of the sources.
If I use all the options and even install linux-source I cannot get to
pass.
sudo apt-get install linux-source
I discover that the acinclude.m4 is searching on /boot/kernel.h file, but the
file doesn't exist. So I change a little the script for read on the right
location:
/usr/src/linux-headers-3.5.0-3-generic/include/linux/kernel.h
This is a tricky command like:
locate kernel.h | grep `uname -r` | grep linux/kernel.h
This can be improved, but I modify the acinclude.m4 like this:
cr_kernel_type=`echo $1 | tr 'a-z' 'A-Z'`
cr_kernel_version_string = `uname -r`
cr_header=`locate kernel.h | grep $cr_kernel_version_string | grep
linux/kernel.h`
sudo ./configure --with-kernel-type=SMP
But It still fails, so I comment that part, for continue al least seeing
other possible errors.
For example, on kernel 3.X some checks are dirrent:
This:
CR_CHECK_KERNEL_MEMBER([fdtable.next_fd],[
#include <linux/sched.h>
#include <linux/file.h>
#if HAVE_LINUX_FDTABLE_H
#include <linux/fdtable.h>
#endif
],[struct fdtable],[int],[next_fd])
Change for:
CR_CHECK_KERNEL_MEMBER([fdtable.next],[
#include <linux/sched.h>
#include <linux/file.h>
#if HAVE_LINUX_FDTABLE_H
#include <linux/fdtable.h>
#endif
],[struct fdtable],[struct fdtable],[next])
But it still fails, so probably I still doing something wrong.
6) Another bug fail is the failure with autoconf.h.
The required kernel header file autoconf.h no longer lives at
include/linux/autoconf.h; for quite some time, it's been at
include/generated/autoconf.h,
and the relocation of that generated autoconf.h file appears to go back to
december of 2009, according to the git commit:
commit 5a865c0606eb44d5d12cabb429751c83712183de
Merge: 331d9d5 46e75f6
Author: Linus Torvalds <[email protected]>
Date: Thu Dec 17 07:23:42 2009 -0800
The acinclude.m4 generate something like:
#ifdef CR_NEED_AUTOCONF_H
#include <linux/autoconf.h>
#endif
So I change for right detection:
#ifdef CR_NEED_AUTOCONF_H
#include <linux/version.h>
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 33)
#include <linux/autoconf.h>
#else
#include <generated/autoconf.h>
#endif
#endif
It works for some file but it doesn't expand on r_module/cr_module.h,
include/blcr_imports.h and blcr_imports/kbuild/module.c (probably I
forget something)
7) I have to remove this functions:
extern int groups_search(struct group_info *, gid_t);
This it is generated like:
extern struct page * follow_huge_pmd(struct mm_struct *, unsigned long
pmd_t *, int);
But could be:
extern struct page * follow_huge_pmd(struct mm_struct *mm, struct
vm_area_struct *, unsigned long address, pmd_t *pmd, int write);
8) Another conflict it is the removal of function cr_utsname
So I write this on source, no in configure (It should be adapted too):
#include <linux/utsname.h>
#if HAVE_INIT_UTSNAME
#define cr_utsname() init_utsname()
#elif HAVE_SYSTEM_UTSNAME
#define cr_utsname() (&system_utsname)
#else
#include <generated/utsrelease.h>
struct new_utsname system_utsname = {
.release = UTS_RELEASE,
};
EXPORT_SYMBOL(system_utsname);
#define cr_utsname() (&system_utsname)
#endif
9) Another issue no resolved are complains for removal of timeval_to_jiffies and
jiffies_to_timeval.
The old code on other kernels:
/* Same for "timeval"
*
* Well, almost. The problem here is that the real system resolution is
* in nanoseconds and the value being converted is in micro seconds.
* Also for some machines (those that use HZ = 1024, in-particular),
* there is a LARGE error in the tick size in microseconds.
* The solution we use is to do the rounding AFTER we convert the
* microsecond part. Thus the USEC_ROUND, the bits to be shifted off.
* Instruction wise, this should cost only an additional add with carry
* instruction above the way it was done above.
*/
unsigned long
timeval_to_jiffies(const struct timeval *value)
{
unsigned long sec = value->tv_sec;
long usec = value->tv_usec;
if (sec >= MAX_SEC_IN_JIFFIES){
sec = MAX_SEC_IN_JIFFIES;
usec = 0;
}
return (((u64)sec * SEC_CONVERSION) +
(((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
(USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
}
EXPORT_SYMBOL(timeval_to_jiffies);
void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
{
/*
* Convert jiffies to nanoseconds and separate with
* one divide.
*/
u32 rem;
value->tv_sec = div_u64_rem((u64)jiffies * TICK_NSEC,
NSEC_PER_SEC, &rem);
value->tv_usec = rem / NSEC_PER_USEC;
}
EXPORT_SYMBOL(jiffies_to_timeval);
10) smp_lock was dropped for > 2.6.38-9
So I have to change in cr_module/kbuild/vmadump_common.c
#if !HAVE_FILE_F_LOCK
#include <linux/smp_lock.h>
#endif
By:
#if !HAVE_FILE_F_LOCK
#include <linux/version.h>
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 38)
#include <linux/smp_lock.h>
#endif
#endif
11) I comment a lot AC_ERROS more, just for try to run all the configure and
see make errors on
compilation.
I pass all until this:
sudo make
/usr/bin/make all-recursive
make[1]: Entering directory `/home/shakaran/blcr-0.8.4'
Making all in include
make[2]: Entering directory `/home/shakaran/blcr-0.8.4/include'
if test -d ../libcr32/include; then /usr/bin/make -C ../libcr32/include all; fi
make[2]: Leaving directory `/home/shakaran/blcr-0.8.4/include'
Making all in blcr_imports
make[2]: Entering directory `/home/shakaran/blcr-0.8.4/blcr_imports'
Making all in .
make[3]: Entering directory `/home/shakaran/blcr-0.8.4/blcr_imports'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/shakaran/blcr-0.8.4/blcr_imports'
Making all in kbuild
make[3]: Entering directory `/home/shakaran/blcr-0.8.4/blcr_imports/kbuild'
/usr/bin/make -C /usr/src/linux-headers-3.5.0-3-generic
KBUILD_EXTMOD=/home/shakaran/blcr-0.8.4/blcr_imports/kbuild CC="gcc"
make[4]: Entering directory `/usr/src/linux-headers-3.5.0-3-generic'
Building modules, stage 2.
MODPOST 1 modules
make[4]: Leaving directory `/usr/src/linux-headers-3.5.0-3-generic'
make[3]: Leaving directory `/home/shakaran/blcr-0.8.4/blcr_imports/kbuild'
make[2]: Leaving directory `/home/shakaran/blcr-0.8.4/blcr_imports'
Making all in cr_module
make[2]: Entering directory `/home/shakaran/blcr-0.8.4/cr_module'
Making all in kbuild
make[3]: Entering directory `/home/shakaran/blcr-0.8.4/cr_module/kbuild'
/usr/bin/make -C /usr/src/linux-headers-3.5.0-3-generic
KBUILD_EXTMOD=/home/shakaran/blcr-0.8.4/cr_module/kbuild CC="gcc"
make[4]: Entering directory `/usr/src/linux-headers-3.5.0-3-generic'
CC [M] /home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.o
In file included from /home/shakaran/blcr-0.8.4/cr_module/cr_module.h:85:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/../../vmadump4/vmadump.h:151,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:55:
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:89:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:97:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:118:7: warning:
"HAVE_FDTABLE_NEXT_FD" is not defined [-Wundef]
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:121:4: error: #error "no
next_fd"
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:238:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:257:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:260:5: warning:
"HAVE_FIND_TASK_BY_PID_NS" is not defined [-Wundef]
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:266:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:269:5: warning:
"HAVE_FIND_TASK_BY_PID_TYPE_NS" is not defined [-Wundef]
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:368:4: error: #error No
tasklist iterators available
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:386:4: error: #error "Unknown
inode lock type"
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:439:0: warning: "__putname"
redefined [enabled by default]
In file included from include/linux/highmem.h:4:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:44:
include/linux/fs.h:2091:0: note: this is the location of the previous definition
In file included from /home/shakaran/blcr-0.8.4/cr_module/cr_module.h:85:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/../../vmadump4/vmadump.h:151,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:55:
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:444:10: error: redefinition of
‘struct path’
In file included from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:32:0:
include/linux/file.h:19:8: note: originally defined here
In file included from /home/shakaran/blcr-0.8.4/cr_module/cr_module.h:85:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/../../vmadump4/vmadump.h:151,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:55:
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:495:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:509:4: error: #error
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:550:4: error: #error "No
cr_kill_process() definition"
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:554:25: error: redefinition of
‘valid_signal’
In file included from include/linux/sched.h:72:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:29:
include/linux/signal.h:234:19: note: previous definition of ‘valid_signal’ was
here
In file included from /home/shakaran/blcr-0.8.4/cr_module/cr_module.h:85:0,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/../../vmadump4/vmadump.h:151,
from
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:55:
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:575:4: error: #error "no
cr_free_fs_struct() definition"
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:583:4: error: #error "no
cr_do_pipe() definition"
/home/shakaran/blcr-0.8.4/cr_module/cr_kcompat.h:598:4: error: #error
"fs_struct.lock has unknown type"
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c: In function
‘default_map_name’:
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:301:6: error:
#error
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:303:1: warning: no
return statement in function returning non-void [-Wreturn-type]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c: In function
‘directio_start’:
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:575:6: error:
#error
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:597:5: error:
implicit declaration of function ‘lock_kernel’
[-Werror=implicit-function-declaration]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:599:5: error:
implicit declaration of function ‘unlock_kernel’
[-Werror=implicit-function-declaration]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:602:1: warning:
label ‘out’ defined but not used [-Wunused-label]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c: In function
‘vmad_remap’:
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:657:9: error:
implicit declaration of function ‘do_mmap’
[-Werror=implicit-function-declaration]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c: In function
‘vmad_follow_addr’:
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:1326:7: warning:
"HAVE_4_ARG_FOLLOW_HUGE_ADDR" is not defined [-Wundef]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:1332:7: warning:
"HAVE_3_ARG_FOLLOW_HUGE_ADDR" is not defined [-Wundef]
/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.c:1339:6: error:
#error "No way to call follow_huge_addr()"
cc1: some warnings being treated as errors
make[5]: *** [/home/shakaran/blcr-0.8.4/cr_module/kbuild/vmadump_common.o]
Error 1
make[4]: *** [_module_/home/shakaran/blcr-0.8.4/cr_module/kbuild] Error 2
make[4]: Leaving directory `/usr/src/linux-headers-3.5.0-3-generic'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/shakaran/blcr-0.8.4/cr_module/kbuild'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/shakaran/blcr-0.8.4/cr_module'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shakaran/blcr-0.8.4'
make: *** [all] Error 2
So for apply the patch:
sudo patch -p1 < acinclude.m4.patch
sudo patch -p1 < configure.ac.patch
The generate the new configure:
sudo ./autogen.sh
sudo ./configure
Copy the modified sources:
sudo cp blcr_imports.h include/blcr_imports.h
sudo cp cr_module.hcr_module/cr_module.h
sudo cp module.c blcr_imports/kbuild/module.c
sudo cp vmadump_common.c cr_module/kbuild/vmadump_common.c
And compile:
sudo make
My conclusion is that blcr doesn't support very well 3.X kernels and it needs
a lot works making the code compatible. It is not a issue with just kernel
numbers.
As I said, I am not a expert, this research has the only purpose for learn and
contribute,
any comment is welcome.
My 2 cent.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/804943
Title:
blcr kernel module failed to build with kernel 3.0 : configure: error:
--with-linux argument '3.0-x' is neither a kernel version string nor a
full path
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/blcr/+bug/804943/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
