This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 108929 - 2.6.0-0.test9 patch fundamentally breaks vmware
2.6.0-0.test9 patch fundamentally breaks vmware
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
http://groups.google.com/groups?hl=en...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-03 09:53 EST by Ralf Ertzinger
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-19 07:46:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Ertzinger 2003-11-03 09:53:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031027

Description of problem:
(Note: I know that vmware is neither shipped nor supported by RedHat.
Please read on).

It seems that one RedHat patch to the current 2.6.0-test9 kernel makes
it all but impossible to use vmware on these kernels. Since vmware is
a very useful product for a lot of people, I'd be happy if you'd take
a look at it.

The patch in question is "linux-2.6.0-compile.patch", changing the
argument passing to functions.

The usenet tread describing the problem can be found at
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=pan.2003.10.26.05.34.09.229786%40othersdietrying.com&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26selm%3Dpan.2003.10.26.05.34.09.229786%2540othersdietrying.com

An analysis can be found in this article (part of the thread mentioned
above)
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&selm=bo0js3%24ai6%241%40london.vmware.com

Version-Release number of selected component (if applicable):
kernel-2.6.0-0.test9.1.67

How reproducible:
Always

Steps to Reproduce:
1. Try to compile the vmmon driver on 2.6.0-test9
2.
3.
    

Additional info:
Comment 1 Arjan van de Ven 2003-11-03 09:55:54 EST
The problem really is with vmware; their makefile is broken (for 2.6
kernels). If they used a proper makefile it would JustWork(tm).
Comment 2 Ralf Ertzinger 2003-11-04 09:31:01 EST
I am by no means a kernel hacker, but reading the thread above it
seems to me that some of vmware's assembler mumbo-jumbo depends on
-mregparm=0.
Whether this is a good idea in itself is another question.
Comment 3 Arjan van de Ven 2003-11-04 09:42:24 EST
any and all such functions in the kernel have to be marked
"asmlinkage" anyway; if vmware did that correctly it'd just work.
Comment 4 Petr Vandrovec 2003-11-04 12:34:45 EST
And what is correct Makefile? I tried:

====
default:
    (cd /usr/src/linux; make SUBDIRS=$PWD modules)

obj-m += vmmon.o

clean:
    rm -f core *.o *.a *.s
====

and it (1) fails in MODPOST phase, saying that I need all modules 
from stock kernel so MODPOST can turn them from .o to .ko, and (2) 
does not contain rules for C++ sources.

While I can work around missing C++ rules by copying CFLAGS & so on, 
I have no idea how I can change Makefile to build only vmmon.ko, 
without building also floppy.ko, rtc.ko, ... 
Documentation/kbuild/modules.txt says only "The information herein is 
correct but not copmplete", and "Documentation/kbuild/makefiles.txt" 
did not point correct solution to me.

And what about second half of complaint (which is only on newsgroup, 
not here yet): There is /boot/vmlinux-2.6.0-0.test9.1.67smp -
> /usr/lib/debug/lib/modules/2.6.0-0.test9.1.67/smp/vmlinux symlink 
in kernel-smp package, but I was not able to find package which 
contains symlink target so that kernel debugging is really possible...
Comment 5 Arjan van de Ven 2003-11-04 12:39:26 EST
the documented way is to have a file called makefile with
all:
        make V=1 -C /lib/modules/`uname -r`/build SUBDIRS=$$PWD modules
in it and a file called Makefile with
obj-m += vmmon.o

in it.

the vmlinux file is in the kernel-debuginfo package (which isn't
available on my people site since it's too big so that I go over my
quota and would have to drop the i586 kernels instead)
Comment 6 Arjan van de Ven 2003-11-04 12:44:14 EST
oh and btw, using /usr/src/linux-* is REALLY not going to work with
the 2.6 rpms anymore, the fact that it "worked" with the 2.4 rpms is
purely coincidental.
Comment 7 Petr Vandrovec 2003-11-04 12:52:59 EST
No problem with /usr/src/linux-*, we prefer /lib/modules/... for 
years, as long as that directory exists. 

But problem is that 'make ... SUBDIRS=$$PWD modules' does not work 
reliably:

If there is .o file anywhere in source tree, and its .ko is out of 
date (or does not exist), 'make SUBDIRS=XXX modules' will rebuild not 
only .ko in SUBDIRS, but all .ko, in whole kernel source tree. You 
can see that Makefile.modpost is invoked with all modules, not only 
with modules built in this step.

But as this does not happen unless user did something unusual to his 
tree, I think that I'll have to live with it.
Comment 8 Arjan van de Ven 2003-11-04 12:57:32 EST
the /build tree doesn't have .c files nor .o files so it can't be out
of date.
Comment 9 Petr Vandrovec 2003-11-05 10:12:50 EST
Feel free to close this bug, pointing people to the 
http://platan.vc.cvut.cz/ftp/pub/vmware, for vmware-any-any update 44 
or later.

Note You need to log in before you can comment on or make changes to this bug.