From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Fri Nov 06 2009 - 18:42:14 PST
Neal Becker wrote: > On Friday 06 November 2009, Paul H. Hargrove wrote: > >> Alan Woodland wrote: >> >>> 2009/11/2 Alan Woodland <alan.woodland_at_gmail_dot_com>: >>> >>>> The attached patch fixes the cause of the missing modules when >>>> building on 2.6.31. It doesn't however appear to be the only problem >>>> when building for 2.6.31, it's now hitting a #error which I haven't >>>> looked at yet. >>>> >>>> For those that are interested 2.6.31 no longer sets $(TOPDIR) in >>>> kbuild invocations, so trying to work out if we're using kbuild based >>>> on that fails. I switched to $(obj), I couldn't think of anything >>>> better to use, but I'm sure there is a more appropriate variable to >>>> use instead. >>>> >>>> When I've had more of a look I might post another patch here to fix >>>> the remaining problems. >>>> >>> Two problems seem to exist with 2.6.31: >>> - find_task_by_pid_type_ns no longer exists, or isn't visible at all. >>> - find_task_by_pid_ns test passes, with a warning, but dmesg reports >>> find_task_by_pid_ns not found at modprobe time. I think this might be >>> a mistake in the kernel headers, but it's still in System.map, so we >>> can work around this maybe. >>> >>> This is the commit log: >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit >>> ;h=17f98dcf6010a1cfd25d179fd0ce77d3dc2685c3 >>> >>> I'm slightly out of my depth here now, I tried to hack a work around, >>> but didn't succeed yet. >>> >>> Alan >>> >> W/o trying for myself I can't speculate too deeply on >> find_task_by_pid_type_ns(), but the git commit log above seems to >> indicate that some functionality has been removed from the kernel. I >> don't yet know how it relates to what BLCR is actually doing w/ >> find_task_by_pid_type_ns(). >> >> The commit log also says >> "remove the exports for find_task_by_pid_ns...." So, I suggest that the >> following addition to BLCR's configure.in may be the right fix for that >> one (since Alan reports that the symbol is still in System.map): >> >> --- configure.ac 23 Aug 2009 22:58:26 -0000 1.410.2.10 >> +++ configure.ac 7 Nov 2009 00:15:14 -0000 >> @@ -1225,6 +1225,7 @@ CR_CHECK_KERNEL_CALL([find_task_by_pid_n >> if test -z "${HAVE_FIND_TASK_BY_PID}${HAVE_FIND_TASK_BY_PID_NS}"; then >> CR_BAD_KERNEL([unable to determine how to map pid_nr -> struct task]) >> fi >> +CR_FIND_KSYM([find_task_by_pid_ns],[CODE]) >> >> CR_CHECK_KERNEL_CALL([find_task_by_pid_type],[#include <linux/sched.h>]) >> CR_CHECK_KERNEL_CALL([find_task_by_pid_type_ns],[#include >> <linux/sched.h>]) >> >> >> However, it is also possible that BCLR needs to finally move move to the >> vpid interfaces. >> >> -Paul >> >> > > Thanks, but this patch didn't help. > > checking kernel for nameidata.path... no > checking kernel for nameidata.dentry... no > ====================================================================== > Please review the following configuration information: > Kernel source directory = /usr/src/kernels/2.6.31.5-122.fc12.ppc > Kernel build directory = /usr/src/kernels/2.6.31.5-122.fc12.ppc > Kernel symbol table = /usr/src/kernels/2.6.31.5-122.fc12.ppc/System.map > Kernel version probed from kernel build = 2.6.31.5-122.fc12.ppc > Kernel running currently = 2.6.30.9-90.fc11.ppc64 > ====================================================================== > configure: error: Unable to use kernel 2.6.31.5-122.fc12.ppc - unable to > determine composition of struct nameidata > > Build log here: > http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/5496- > blcr-kmod-0.8.1-3.fc12.12/ppc/build.log > > I don't have any local system configured with this kernel, so it's not easy for > me to debug. > I just grabbed the RPMs for the 2.6.31.5-22.fc12.ppc kernel and CANNOT reproduce the problem Neal reports. I am using the 0.8.2 sources (not the rpmfusion pacakges) on an FC10 system and get a successful configure step: $../configure --with-linux=/home/phargrov/kernels/linux-2.6.31.5-122.fc12.ppc/ --enable-debug .... checking kernel for nameidata.path... yes checking kernel for nameidata.dentry... no .... ====================================================================== Please review the following configuration information: Kernel source directory = /home/phargrov/kernels/linux-2.6.31.5-122.fc12.ppc/ Kernel build directory = /home/phargrov/kernels/linux-2.6.31.5-122.fc12.ppc/ Kernel symbol table = /home/phargrov/kernels/linux-2.6.31.5-122.fc12.ppc//System.map-2.6.31.5-122.fc12.ppc Kernel version probed from kernel build = 2.6.31.5-122.fc12.ppc Kernel running currently = 2.6.30 ====================================================================== Neal, If you can get the config.log file generated by the failed configure we might be able to find information in there about the failed configure probes of struct nameidata. It might be something silly like an incompatibility w/ the gcc version being used (which is certainly newer than on my FC10 ppc). -Paul -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory