selinux
Contributor
Contributor

2.6.25 host: 6.0.2 needs some help....

After downloading/installing a 2.6.25rc1 kernel, "vmware-config.pl" fails.

I've localized some issues to the comple of task.c: some changes in the kernel headers seem to break g++.

Looks like <asm/page.h> is being included, as the preprocessor flag: "_I386_PAGE_H" appears renamed to "_ASM_X86_PAGE_H".

Fixing this allows vmmon to compile, but the insmod fails with:

Feb 13 09:04:11 localhost kernel: vmmon: Unknown symbol init_mm

Feb 13 09:04:11 localhost kernel: vmmon: Unknown symbol init_mm

This symbol is now defined in <linux/init_task.h> , but I haven't figured out where/how to include it. A simple "brute force" insert into "linux/driver.c" results in "mismatch" error message at the insmod.

I vaguely remember fiddling with this before: something to do with LINUX_VERSION_CODE or some such.

Anyone remember or have hints?

Anyone already have this working?

thanks,

tom

0 Kudos
17 Replies
ran
Contributor
Contributor

Same problem running vmware-config.pl:

......

In file included from /tmp/vmware-config0/vmmon-only/common/hostKernel.h:56,

from /tmp/vmware-config0/vmmon-only/common/task.c:30:

include/asm/page.h: In function ‘pte_t native_make_pte(pteval_t)’:

include/asm/page.h:128: error: expected primary-expression before ‘)’ token

include/asm/page.h:128: error: expected ‘;’ before ‘{’ token

include/asm/page.h:128: error: expected primary-expression before ‘.’ token

include/asm/page.h:128: error: expected `;' before ‘}’ token

In file included from /tmp/vmware-config0/vmmon-only/common/task.c:1194:

/tmp/vmware-config0/vmmon-only/common/task_compat.h: At global scope:

/tmp/vmware-config0/vmmon-only/common/task_compat.h:9: warning: ‘typedef’ was ignored in this declaration

make[2]: *** Error 1

make[1]: *** Error 2

make[1]: Leaving directory `/usr/src/kernels/2.6.25-0.40.rc1.git2.fc9-x86_64'

make: *** http://vmmon.ko Error 2

Does anybody have solve it?

0 Kudos
Ehud
Contributor
Contributor

The following changes allow vmnet and vmmon to compile and load. I was not able to figure out how to get superoperations.read_inode fixed so vmblock won't build but it's not cruicial.

I also apologize it's not in patch form. I just did it and am posting the info to help others. My "original" tars are actually after vmware-any-any-115 and a private patch to change the version to 167.

vmnet-only/compat_sock.h

old:

#include <net/sock.h>

new:

#include <net/sock.h>

/* http://forum.openvz.org/index.php?t=msg&goto=23299&; */

static inline void sock_valbool_flag(struct sock *sk, int bit, int valbool)

{

if (valbool)

sock_set_flag(sk, bit);

else

sock_reset_flag(sk, bit);

}

filter.c:

old:

#include <linux/netdevice.h>

new:

#include <linux/netdevice.h>

#define NF_IP_LOCAL_OUT NF_INET_LOCAL_OUT

#define NF_IP_LOCAL_IN NF_INET_LOCAL_IN

#define NF_IP_POST_ROUTING NF_INET_POST_ROUTING

vmmon:

common/task.c:

old:

#define I386PAGE_H

new:

#define ASMX86_PAGE_H

# uname -a

Linux egdell.wetwork.net 2.6.25-rc1 #1 SMP Sun Feb 24 08:58:34 MST 2008 x86_64 x86_64 x86_64 GNU/Linux

# service vmware status

At least one instance of VMware Workstation is still running.

Bridged networking on /dev/vmnet0 is running

Host network detection is not running

Host-only networking on /dev/vmnet8 is running

DHCP server on /dev/vmnet8 is running

NAT networking on /dev/vmnet8 is running

Module vmmon loaded

Module vmnet loaded

Ehud

0 Kudos
KevinG
Immortal
Immortal

Hi tom,

Did you try Petr's latest vmware-any-any-update patch?

http://knihovny.cvut.cz/ftp/pub/vmware/

I would put things back as they were before applying the patch

0 Kudos
Ehud
Contributor
Contributor

KevinG the changes I posted are to be applied to a POST vmware-update-any-any-115 to get it to work on 2.6.25.

There is no vmware-update-any-any that covers 2.6.25 (which is only in -rc1 anyway).

Cheers,

Ehud

0 Kudos
KevinG
Immortal
Immortal

Hi Ehud,

To be honest I have not looked at Petr's patches for sometime to see what kernel versions he is supporting, so I will take your word on it for now.

I will have to talk with Petr the next time I see him in the hallways and see what his future plans are for any updates.

- Kevin

0 Kudos
selinux
Contributor
Contributor

Yeah, Petr's patch's do not work for 2.6.25.

Ehud, your patches help, but fail for latest Fedora kernel: 2.6.25-0.69.rc3.git1.fc9

Here is what I get:

&lt;&lt;&lt;&lt;&lt; SNIP &gt;&gt;&gt;&gt;&gt;&gt;

CC /tmp/vmware-config2/vmmon-only/common/vmciResource.o

CC /tmp/vmware-config2/vmmon-only/common/vmciSharedMem.o

CC /tmp/vmware-config2/vmmon-only/common/vmx86.o

CC /tmp/vmware-config2/vmmon-only/vmcore/compat.o

CC /tmp/vmware-config2/vmmon-only/vmcore/moduleloop.o

LD /tmp/vmware-config2/vmmon-only/vmmon.o

Building modules, stage 2.

MODPOST 1 modules

WARNING: "init_mm" undefined!

CC /tmp/vmware-config2/vmmon-only/vmmon.mod.o

LD /tmp/vmware-config2/vmmon-only/vmmon.ko

make[1]: Leaving directory `/usr/src/kernels/2.6.25-0.69.rc3.git1.fc9-i686'

cp -f vmmon.ko ./../vmmon.o

make: Leaving directory `/tmp/vmware-config2/vmmon-only'

Unable to make a vmmon module that can be loaded in the running kernel:

insmod: error inserting '/tmp/vmware-config2/vmmon.o': -1 Unknown symbol in module

There is probably a slight difference in the kernel configuration between the

set of C header files you specified and your running kernel. You may want to

rebuild a kernel based on that directory, or specify another directory.

For more information on how to troubleshoot module-related problems, please

visit our Web site at "http://www.vmware.com/download/modules/modules.html" and

"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

/var/log/messages complains:

vmmon: Unknown symbol init_mm

vmmon: Unknown symbol init_mm

This is what blocked me before. Any help gratefully appreciated!

tom

0 Kudos
Ehud
Contributor
Contributor

Tom I'm suspecting one of three things:

1. Mismatch between your version of kernel-headers, kernel-devel, and the kernel itself

2. vmware-config.pl erroneously chose the wrong directory in which to compile the modules (although it looks correct from the "leaving directory...." message). I'm also assuming your architechture is i686. Mine is x86_64 so I'm not sure if that's a factor.

and

3. That Fedora's Development kernel doesn't have all the upstream changes yet.

What I do is git the wireless-dev kernel:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git

cd wireless-2.6

git checkout -b everything origin/everything

That is where I got 2.6.25-rc1. I've had to apply the public Nvidia patch and vmware-update-any-any-115 and the patches above, but both load and run perfectly.

I have not had success with Fedora's Development kernels. For example 2.6.24-0.133.rc6.git8.fc9 LOOKED fine but right after Nash started it said it couldn't set the real time clock!

The time was then way way off, and ntpd couldn't bind, and I had to service restart ntpd to correct. On shutdown it said it was synching the time and yet... didn't. This didn't happen with any of the 2.6.24's I built (-rc1 through -rc8 through final release) or the Fedora 2.6.23 release kernel or the wireless-dev 2.6.25.

As for init_mm please check out http://www.nvnews.net/vbulletin/showthread.php?t=107144&page=3 ... Again I did not have this issue.

I hope any of this helps...

Ehud

0 Kudos
selinux
Contributor
Contributor

Ehud,

Thanks for this. Here is what is installed on my system:

kernel-headers-2.6.25-0.69.rc3.git1.fc9.i386

kernel-devel-2.6.25-0.69.rc3.git1.fc9.i686

and

kernel-2.6.25-0.69.rc3.git1.fc9.i686

So I don't believe I have a mismatch problem, nor do I believe the script picked to wrong directory.

Fedora is usually quite up to date on their trees, so I suspect it is as described by nv: init_mm is no longer exported in x86 kernels.

I've had good success building to Fedora's packages up until 2.6.25-XX packages.

I'm guessing that the kernel guys have chosen NOT to export this, but I'll post on the fedora site to see.

tom

0 Kudos
Ehud
Contributor
Contributor

Yeah those all look correct. The link I mentioned has the following gem in it, which may correct the problem for you. (I'm unsure why I don't have it unless init_mm is still in -rc1 but isn't later and the Fedora guys have already removed it...

While I used to do lots of virtual memory stuff (back in the old VMS days) I'm not at all up to date on how the Linux kernel does it, so I'm like a blind coder here. Does this even help or am I wasting your time? Smiley Happy

Ehud

For the init_mm-struct, in old kernels (2.0) init_mm wasn't exported

too. So there was a workaround for those modules, which needed it:

Quote:

static struct mm_struct *init_mm_ptr;

#define init_mm (init_mm_ptr) / spaetere ifdefs vermeiden */

static void retrieve_init_mm_ptr(void)

{

struct task_struct *p;

for (p = current ; (p = p-&gt;next_task) != current ; )

if (p-&gt;pid == 0)

break;

init_mm_ptr = p-&gt;mm;

}

</div>

The code is from the german version of "Linux Device Drivers" by

Alessandro Rubini & Jonathan Corbet. It can be found in chapter 13

(Backward Compatibility).

0 Kudos
Ehud
Contributor
Contributor

Short followup: Looks like it's still in 2.6.25-rc3:

See http://www.linuxhq.com/kernel/v2.6/25-rc3/kernel/fork.c

Ehud

selinux
Contributor
Contributor

Ehud,

Thanks for all of this.

My first attempt: insert the quoted code into include/compat_sched.h

that failed:

Using 2.6.x kernel build system.

make -C /lib/modules/2.6.25-0.69.rc3.git1.fc9/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules

make[1]: Entering directory `/usr/src/kernels/2.6.25-0.69.rc3.git1.fc9-i686'

CC /tmp/vmware-config2/vmmon-only/linux/driverLog.o

In file included from /tmp/vmware-config2/vmmon-only/linux/driverLog.c:15:

/tmp/vmware-config2/vmmon-only/./include/compat_sched.h: In function ‘retrieve_init_mm_ptr’:

/tmp/vmware-config2/vmmon-only/./include/compat_sched.h:258: error: ‘struct task_struct’ has no member named ‘next_task’

make[2]: *** Error 1

make[1]: *** Error 2

make[1]: Leaving directory `/usr/src/kernels/2.6.25-0.69.rc3.git1.fc9-i686'

make: *** http://vmmon.ko Error 2

#

So, obivously, I have work here. .... I'll continue first thing in the morning.

Thanks again for the help.

tom

0 Kudos
selinux
Contributor
Contributor

OK, I decided to try the brute force hack: since I couldn't easily avoid the reference to init_mm as an external (in &lt;linux/sched.h&gt;), I inserted a definition of it in linux/driver.c:

#include &lt;linux/sched.h&gt;

struct mm_struct init_mm;

This, along with the changes for vmnet allows the beast to compile and load:

Feb 28 11:11:57 localhost kernel: : VMCI: Driver initialized.

Feb 28 11:11:57 localhost kernel: : Module vmmon: registered with major=10 minor=165

Feb 28 11:11:57 localhost kernel: : Module vmmon: initialized

Feb 28 11:11:58 localhost kernel: /dev/vmnet: open called by PID 13749 (vmnet-bridge)

Feb 28 11:11:58 localhost kernel: /dev/vmnet: hub 0 does not exist, allocating memory.

Feb 28 11:11:58 localhost kernel: /dev/vmnet: port on hub 0 successfully opened

Feb 28 11:11:58 localhost kernel: bridge-eth1: peer interface eth1 not found, will wait for it to come up

Feb 28 11:11:58 localhost kernel: bridge-eth1: attached

Feb 28 11:11:58 localhost kernel: /dev/vmnet: open called by PID 13768 (vmnet-netifup)

Feb 28 11:11:58 localhost kernel: /dev/vmnet: hub 1 does not exist, allocating memory.

Feb 28 11:11:58 localhost kernel: /dev/vmnet: port on hub 1 successfully opened

&lt;&lt;&lt;&lt;SNIP&gt;&gt;&gt;&gt;

Feb 28 11:11:58 localhost vmnet-dhcpd:

Feb 28 11:11:58 localhost vmnet-detect[13755]: NetDetectDaemonInit: No host policy file found. Not initializing filter.

"vmware" starts, but trying to power on a guest produces the following popup:

Unable to change virtual machine power state: Cannot find a valid peer process to connect to.

So, I'm back to square one or two.

Any ideas?

tom

0 Kudos
Ehud
Contributor
Contributor

I wish I knew what it did... I found a web page that uses it and defines it at http://www.ussg.iu.edu/hypermail/linux/kernel/0506.3/2054.html

and his definition is:

static int __init mm_init(void)

I don't think it will help but you might try it. Alternately look for where mm_init is being used, and if you can paste that code perhaps I or someone brighter than me can figure out how to recode it. I realized why I don't have this problem - I'm using VMware Workstation...

E

0 Kudos
selinux
Contributor
Contributor

Hey, I think the kernel-gods may be smiling on us, at least for one more release. Below is in the commit log for

2.6.25-rc3-git3

x86: delay the export removal of init_mm

[commit|http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=757265b8c57bb8fd91785d3d1a87fb483c86c9c2] | commitdiff | tree

</div>

Ingo Molnar


x86: delay the export removal of init_mm

delay the removal of this symbol export by one more kernel release,
giving external modules such as VirtualBox a chance to stop using it.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

0 Kudos
Ehud
Contributor
Contributor

Short term... but very nice! Smiley Happy

Ehud

0 Kudos
selinux
Contributor
Contributor

OK.... I finally have a Fedora i686 kernel for 2.6.25-rc4 that has the patch that "re-exports" init_mm.

This kernel requires that the config option "CONFIG_UNUSED_SYMBOLS" be set to "y", otherwise the export doesn't happen.

With this, and with the above "patches", I finally have a vmmon/vmnet that compiles and inserts; and I have a running vmware VM.

The "re-export" of init_mm will only be for "one more" kernel release, that is for 2.6.25. For 2.6.26 and later, there will need to be accomodation in the module code, I suspect.

The Fedora folks seem willing to enable this through 2.6.25, so I'm happy.

Anyway, thanks again for the help.

tom

0 Kudos
birdie
Expert
Expert

init_mm will be definitely removed really soon, and I have a kernel which is compiled without it. So, is there any solution which doesn't require kernel recompilation?

besides ... where is Petr? His any-any patches used to be really helpful in the past but a lot of time has passed since I last heard of him.

0 Kudos