Here's really strange one. Building a module against 2.4.15-pre7
seems to generate invalid opcodes (???) from the kernel includes.
THe code looks very strange. Perhaps someone who owns kmem_cache_create
has some idea?
Oops attached.
Jeff
Your code is violating one of the assertions in
kmem_cache_create(), check the BUG(); calls in
mm/slab.c:kmem_cache_create() to try and figure out
which one you are firing off.
Probably either you are trying to send it debug flags
but CONFIG_SLAB_DEBUG is not defined _OR_ you are trying
to create the same SLAB cache twice (forgetting to destroy
it on module unload perhaps)?
Slab if fine, it's your code which is busted :)
On Tue, Nov 20, 2001 at 10:22:03PM -0800, David S. Miller wrote:
>
> Your code is violating one of the assertions in
> kmem_cache_create(), check the BUG(); calls in
> mm/slab.c:kmem_cache_create() to try and figure out
> which one you are firing off.
>
> Probably either you are trying to send it debug flags
> but CONFIG_SLAB_DEBUG is not defined _OR_ you are trying
> to create the same SLAB cache twice (forgetting to destroy
> it on module unload perhaps)?
>
> Slab if fine, it's your code which is busted :)
David,
I need some help here (big surprise). I did nothing other than
download pre7, apply my patch, and do the build. I went back
over how I did the build, and this is the result of the build
if you have unpacked, patched, then run "make oldconfig." If I
do a "make dep" then this problem does not occur, and the build
works fine. If I build the external module (this bug only
shows up when building the external module file system driver,
not the kernel patched version of NWFS).
No. I think the build in linux is broken. The Linux tree should
not generate garbase opcodes from the includes is make dep
has not been run and someone is simply building a module against
the include files.
:-)
Jeff
From: "Jeff V. Merkey" <[email protected]>
Date: Wed, 21 Nov 2001 00:33:04 -0700
No. I think the build in linux is broken. The Linux tree should
not generate garbase opcodes from the includes is make dep
has not been run and someone is simply building a module against
the include files.
It executes a bogus opcode because that is how we signal
an assertion failure, see the BUG() macro define in
include/asm-i386/page.h
If it only fails as a module, then most likely (as I stated in my
original mail, which you decided not to read) you are trying to create
a SLAB cache of the same name twice and it is giving you an OOPS to
let you know about it.
On module unload you have to kmem_cache_destroy or else you'll
hit this assertion failure the next time you load the module.
If you aren't going to look at the things I've asked you to look at to
try and determine the problem, and will merely complain about the
"garbage opcodes" without looking at what put those opcodes there in
the kernel image, then your problem is one that I cannot solve.
I said: "A BUG() assertion is being triggered in slab.c"
You retort: "Nothing should make garbage opcodes execute."
I am now saying: "Go look at the BUG() definition, it is a garbage
opcode and it is on purpose".
Are you now going to say: "Linux is still broken, nothing should make
garbage opcodes, the build in Linux is broken"
???
You are really a fucking pain in the ass to help Jeff.
----- Original Message -----
From: "David S. Miller" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Tuesday, November 20, 2001 11:47 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> From: "Jeff V. Merkey" <[email protected]>
> Date: Wed, 21 Nov 2001 00:33:04 -0700
>
> No. I think the build in linux is broken. The Linux tree should
> not generate garbase opcodes from the includes is make dep
> has not been run and someone is simply building a module against
> the include files.
>
> It executes a bogus opcode because that is how we signal
> an assertion failure, see the BUG() macro define in
> include/asm-i386/page.h
>
> If it only fails as a module, then most likely (as I stated in my
> original mail, which you decided not to read) you are trying to create
> a SLAB cache of the same name twice and it is giving you an OOPS to
> let you know about it.
>
No dave, I read it, and I am not trying to create a slab cache twice. I
only
create it once. I did go look at the code and I got the part of using an
invalid
opcode to generate an exception. Sort of like an int3 embedded in the
code (the old NetWare/NT way). :-)
> On module unload you have to kmem_cache_destroy or else you'll
> hit this assertion failure the next time you load the module.
>
> If you aren't going to look at the things I've asked you to look at to
> try and determine the problem, and will merely complain about the
> "garbage opcodes" without looking at what put those opcodes there in
> the kernel image, then your problem is one that I cannot solve.
>
> I said: "A BUG() assertion is being triggered in slab.c"
> You retort: "Nothing should make garbage opcodes execute."
>
> I am now saying: "Go look at the BUG() definition, it is a garbage
> opcode and it is on purpose".
>
> Are you now going to say: "Linux is still broken, nothing should make
> garbage opcodes, the build in Linux is broken"
>
> ???
>
> You are really a fucking pain in the ass to help Jeff.
Dave, I went and looked at this stuff. I have been running this code for
over a year on 2.4 and I AM NOT CREATING A SLAB CACHE TWICE!!!!
I am building an NWFS module external of the kernel tree, and unless make
dep
has been run, the default behavior of the includes causes me to drop into
the
BUG() trap.
Jeff
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Today, Jeff V. Merkey wrote:
> [...] I went back
> over how I did the build, and this is the result of the build
> if you have unpacked, patched, then run "make oldconfig." If I
> do a "make dep" then this problem does not occur, [....]
umm... lemme see if I understand you correctly, you patched the
kernel and soemthing breaks if you don't run make dep after
patching? Unless you can prove 100% that nothing in that
patch affects the dependency structure of the code, nor any of
the other things that are generated during the make dep stage,
then what we have here is user error. The directions say, quite
clearly, make oldconfig, make dep, make vmlinux, etc. Unless my
memory is totally shot tonight the last thing make oldconfig
spits out is in fact the direction to run make dep.
From: "Jeff Merkey" <[email protected]>
Date: Tue, 20 Nov 2001 23:54:21 -0700
I am building an NWFS module external of the kernel tree, and unless make
dep
has been run, the default behavior of the includes causes me to drop into
the
BUG() trap.
When you change configuration options, you have to run make
dep again, that is a known requirement of the 2.4.x build system
like it or not :-)
> > You are really a fucking pain in the ass to help Jeff.
>
> Dave, I went and looked at this stuff. I have been running this code for
> over a year on 2.4 and I AM NOT CREATING A SLAB CACHE TWICE!!!!
> I am building an NWFS module external of the kernel tree, and unless make
> dep
> has been run, the default behavior of the includes causes me to drop into
> the
> BUG() trap.
This is a bug in how these includes are structured. It may be ok to leave
the damn
thing the way it is, but warn folks who build custom drivers (like the SCI
drivers I
maintain for Dolphin, NWFS, etc.) that their f_cking code will be broken and
generate these garbage errors if they have not run make dep against the tree
they
try to build against.
I would not have expected you or most LKML folks to have seen this, since
you live
in a world where everything is in the kernel tree. I am telling you there
is a problem there,
and it can bite. After I build this module (since the generated code thatr
ends up in
the external module is crap) it will routinely crash over and over gain
until it gets rebuilt
against a kernel that has had make dep (and make bzImage) run against it.
Jeff
>
> Jeff
>
>
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
----- Original Message -----
From: "David S. Miller" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Tuesday, November 20, 2001 11:56 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> From: "Jeff Merkey" <[email protected]>
> Date: Tue, 20 Nov 2001 23:54:21 -0700
>
> I am building an NWFS module external of the kernel tree, and unless
make
> dep
> has been run, the default behavior of the includes causes me to drop
into
> the
> BUG() trap.
>
> When you change configuration options, you have to run make
> dep again, that is a known requirement of the 2.4.x build system
OK. Cool. Now we are making progress. I think this is a nasty problem.
There
are numerous RPMs that will build against the kernel tree and be busted. I
would
expect an rpm -ba on your DEFAULT kernel in Redhat with the sources
contained
in the kernel.rpm files to also be broken unless someone has done this. You
probably should have someone check this out. I just built the SCI drivers
against
2.4.15-pre7 and they blow up as well.
Jeff
> like it or not :-)
This happens as well with the SCI drivers, which are not dependant on any
patches.
Jeff
----- Original Message -----
From: "Chris Abbey" <[email protected]>
To: "Jeff V. Merkey" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, November 20, 2001 11:54 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> Today, Jeff V. Merkey wrote:
> > [...] I went back
> > over how I did the build, and this is the result of the build
> > if you have unpacked, patched, then run "make oldconfig." If I
> > do a "make dep" then this problem does not occur, [....]
>
> umm... lemme see if I understand you correctly, you patched the
> kernel and soemthing breaks if you don't run make dep after
> patching? Unless you can prove 100% that nothing in that
> patch affects the dependency structure of the code, nor any of
> the other things that are generated during the make dep stage,
> then what we have here is user error. The directions say, quite
> clearly, make oldconfig, make dep, make vmlinux, etc. Unless my
> memory is totally shot tonight the last thing make oldconfig
> spits out is in fact the direction to run make dep.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
From: "Jeff Merkey" <[email protected]>
Date: Wed, 21 Nov 2001 00:03:15 -0700
OK. Cool. Now we are making progress. I think this is a nasty problem.
There
are numerous RPMs that will build against the kernel tree and be busted.
If you patch sources files of the main kernel, you have to
rebuild the dependencies.
Why does this seem illogical to you?
>
> Why does this seem illogical to you?
Philisophical. Kind of like Linus hating kernel debuggers or something. If
someone
is building applcations or modules, etc. in a "commerical" software world (I
just opened
the door to get my head bitten off) where I came from, doing stuff like this
was totally
forbidden. There's a sort of "shell shocked" conditioning folks get into
who have been
in software companies like where I came from where anything that makes it
difficult for
a vendor, partner, developer, etc. to build and maintain code is considered
a serious
defect.
This type of a problem could cause a partner or vendor to spend a lot of
time trying to
figure out what was wrong. Even more so since the way I stumbled across the
problem
was building a driver on one system with modversions turned off, then
loading the
module on a target system and watching it crash -- very annoying and
wasteful of
time. It's just a philisophical kind of thing. i.e. the tools and code
shoudl not have
"easter eggs" hidden in it that make it harder to maintain code.
:-)
Jeff
At 11:09 PM 20/11/01 -0800, David S. Miller wrote:
>If you patch sources files of the main kernel, you have to
>rebuild the dependencies.
>
>Why does this seem illogical to you?
Maybe the way to stop this sort of problem is to enforce it in the kernel
build procedure/Makefiles (and/or in the module's build procedure, if it's
separate to the kernel's).
Eg: Anything that produces output code (bzImage, modules, etc) should fail
if .config is newer than any of the dependencies. Maybe even spit out a
"You need to run 'make dep' before using 'make bzImage'" or something like
that. If they really want to get round it, they can play with 'touch'.
This seems perfectly logical to me.
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
In article <003401c1725a$975ad4e0$f5976dcf@nwfs> you wrote:
> OK. Cool. Now we are making progress. I think this is a nasty problem.
> There are numerous RPMs that will build against the kernel tree and be
> busted. I would expect an rpm -ba on your DEFAULT kernel in Redhat with
> the sources contained in the kernel.rpm files to also be broken unless
> someone has done this.
That's why Red Hat ships the kernel-source RPM; you can build external
modules against that and it has the "make dep" information for all kernels
Red Hat ships for that platform (with a smart "if" that selects the
currently running one)........... But note the word "external". You build in
another directory and don't touch the original .config file or tree......
Unless you need core changes, that's perfectly possible for almost all
modules....
Greetings,
Arjan van de Ven
[email protected] (Jeff V. Merkey) wrote on 21.11.01 in <[email protected]>:
> download pre7, apply my patch, and do the build. I went back
> over how I did the build, and this is the result of the build
> if you have unpacked, patched, then run "make oldconfig." If I
> do a "make dep" then this problem does not occur, and the build
Isn't that exactly the FAQ Keith points out every other day or so (usually
because of a modprobe "symbol not found"), one of the design bugs that
kbuild 2.5 fixes (i.e., the kernel does not notice when it needs to make
dep, so kbuild 2.5 handles dependencies differently)?
MfG Kai
> Here's really strange one. Building a module against 2.4.15-pre7
> seems to generate invalid opcodes (???) from the kernel includes.
You hit a BUG(). If you rebuild the kernel with verbose BUG reporting
included you'll get a line and file to work back from
----- Original Message -----
From: "Kai Henningsen" <[email protected]>
To: <[email protected]>
Sent: Tuesday, November 20, 2001 11:47 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> [email protected] (Jeff V. Merkey) wrote on 21.11.01 in
<[email protected]>:
>
> > download pre7, apply my patch, and do the build. I went back
> > over how I did the build, and this is the result of the build
> > if you have unpacked, patched, then run "make oldconfig." If I
> > do a "make dep" then this problem does not occur, and the build
>
> Isn't that exactly the FAQ Keith points out every other day or so (usually
> because of a modprobe "symbol not found"), one of the design bugs that
> kbuild 2.5 fixes (i.e., the kernel does not notice when it needs to make
> dep, so kbuild 2.5 handles dependencies differently)?
>
> MfG Kai
This is good news on the dependency methods.
Jeff
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
----- Original Message -----
From: "Alan Cox" <[email protected]>
To: "Jeff V. Merkey" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Wednesday, November 21, 2001 1:49 AM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> > Here's really strange one. Building a module against 2.4.15-pre7
> > seems to generate invalid opcodes (???) from the kernel includes.
>
> You hit a BUG(). If you rebuild the kernel with verbose BUG reporting
> included you'll get a line and file to work back from
This may help me determine which include file is breaking the tree. I know
I hit a
BUG() but I should not have. Looks like a hole somewhere. I will attempt
to track
this down today.
Jeff
----- Original Message -----
From: <[email protected]>
To: "Jeff Merkey" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 21, 2001 12:49 AM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> In article <003401c1725a$975ad4e0$f5976dcf@nwfs> you wrote:
>
> > OK. Cool. Now we are making progress. I think this is a nasty
problem.
> > There are numerous RPMs that will build against the kernel tree and be
> > busted. I would expect an rpm -ba on your DEFAULT kernel in Redhat with
> > the sources contained in the kernel.rpm files to also be broken unless
> > someone has done this.
>
> That's why Red Hat ships the kernel-source RPM; you can build external
> modules against that and it has the "make dep" information for all kernels
> Red Hat ships for that platform (with a smart "if" that selects the
> currently running one)........... But note the word "external". You build
in
> another directory and don't touch the original .config file or tree......
> Unless you need core changes, that's perfectly possible for almost all
> modules....
>
I would anticipate seeing this problem with their kernel source RPM. In
fact, I do,
you have to do a make distclean before you can use it because of the way
their rpm
script munges all the versioned trees into a tmp area during RPM creation.
There's only
one source tree (usually the last one they built) and lots of binary rpm
versions from the
one tree (i.e. i386, i686, etc.).
Jeff
> Greetings,
> Arjan van de Ven
Jeff Merkey wrote:
> ----- Original Message -----
> From: <[email protected]>
> To: "Jeff Merkey" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, November 21, 2001 12:49 AM
> Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
> opcode
>
>
>
>>In article <003401c1725a$975ad4e0$f5976dcf@nwfs> you wrote:
>>
>>
>>>OK. Cool. Now we are making progress. I think this is a nasty
>>>
> problem.
>
>>>There are numerous RPMs that will build against the kernel tree and be
>>>busted. I would expect an rpm -ba on your DEFAULT kernel in Redhat with
>>>the sources contained in the kernel.rpm files to also be broken unless
>>>someone has done this.
>>>
>>That's why Red Hat ships the kernel-source RPM; you can build external
>>modules against that and it has the "make dep" information for all kernels
>>Red Hat ships for that platform (with a smart "if" that selects the
>>currently running one)........... But note the word "external". You build
>>
> in
>
>>another directory and don't touch the original .config file or tree......
>>Unless you need core changes, that's perfectly possible for almost all
>>modules....
>>
>>
>
> I would anticipate seeing this problem with their kernel source RPM. In
> fact, I do,
> you have to do a make distclean before you can use it because of the way
> their rpm
> script munges all the versioned trees into a tmp area during RPM creation.
This is not true at all. To see what I'm referring to, download the
module build kit from my website (http://people.redhat.com/dledford) and
see how it uses box stock kernel include files from our kernel-source
package to build *all* of the needed modules from one source tree (i386,
i386smp, i386BOOT, i586, i586SMP, i686, i686SMP, i686enterprise).
> There's only
> one source tree (usually the last one they built) and lots of binary rpm
> versions from the
> one tree (i.e. i386, i686, etc.).
If you look in the linux/include/linux/modversions/*.h files, you will
see that the different RPM build package versions have all their symbols
in those files #ifdef'ed so that you get the ones you need to match the
running kernel (or if you trick the rhversion.h file, whichever version
you request, see my Makefile).
> Jeff
>
>
>>Greetings,
>> Arjan van de Ven
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
On Wed, Nov 21, 2001 at 11:31:15AM -0700, Jeff Merkey wrote:
> I would anticipate seeing this problem with their kernel source RPM. In
> fact, I do, you have to do a make distclean before you can use it because
> of the way their rpm script munges all the versioned trees into a tmp area
> during RPM creation. There's only one source tree (usually the last one
> they built) and lots of binary rpm versions from the one tree (i.e. i386,
> i686, etc.).
Yes and during the build the modversions and depenency info etc for each
version is nicely stored in separate directories which is later combined
into one tree with #if's for the proper currently running kernel.
Have you even looked at the kernel-source RPM ?
Greetings,
Arjan van de Ven
Red Hat Linux kernel maintainer
Doug,
I have seen some problems with the rpm build and default install of your
kernel sources.
NWFS and the SCI drivers will **NOT** build against it since you post in a
linux and linux-up kernel for lilo during boot. People using these drivers
who email me always have to do a "make distclean" to get stuff to build. I
am very familiar with the kernel.h
changes you guys put in that are different from stock kernels, but despite
this, it's
far from "plug and play" for a customer building third party kernel modules
on your rpms.
I am not saying this is bad or anything, but it does require that the
customer A) have a
Linux consultant to do the installation or B) be a competent Linux
programmer. Kind of
tough this to expect a secretary to do without a little help.
This is way off topic at this point. This was originally related to BUG()
getting called from builds against a virgin source tree. Alan Cox has asked
me to look into the code and determine just where the BUG() message is
getting generated from. I am pursuing this at present.
Jeff
:-)
Jeff
----- Original Message -----
From: "Arjan van de Ven" <[email protected]>
To: "Jeff Merkey" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 21, 2001 12:16 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> On Wed, Nov 21, 2001 at 11:31:15AM -0700, Jeff Merkey wrote:
>
> > I would anticipate seeing this problem with their kernel source RPM. In
> > fact, I do, you have to do a make distclean before you can use it
because
> > of the way their rpm script munges all the versioned trees into a tmp
area
> > during RPM creation. There's only one source tree (usually the last one
> > they built) and lots of binary rpm versions from the one tree (i.e.
i386,
> > i686, etc.).
>
> Yes and during the build the modversions and depenency info etc for each
> version is nicely stored in separate directories which is later combined
> into one tree with #if's for the proper currently running kernel.
>
> Have you even looked at the kernel-source RPM ?
Yes. I based a Linux distribution on RedHat's 6.2 last year, and I am
**VERY** familiar with your anaconda installer and kernel.src.rpm build
modules. I know the 7.X stuff got a hell of a lot better, but customers
still have to sterilize the build area are your rpm gets installed in order
to build external kernel modules.
Jeff
>
> Greetings,
> Arjan van de Ven
> Red Hat Linux kernel maintainer
Jeff Merkey wrote:
> Kind of
> tough this to expect a secretary to do without a little help.
You have secretaries developing kernel modules?
cu
jjs
Jeff Merkey wrote:
>>Have you even looked at the kernel-source RPM ?
>>
>
> Yes. I based a Linux distribution on RedHat's 6.2 last year, and I am
> **VERY** familiar with your anaconda installer and kernel.src.rpm build
> modules. I know the 7.X stuff got a hell of a lot better, but customers
> still have to sterilize the build area are your rpm gets installed in order
> to build external kernel modules.
<sigh> Again, this isn't true. I build modules against our
kernel-source RPM tree all the time, and I *never* do a make distclean.
If I did, it would screw the tree permanently. If you are basing your
arguments about what you saw with 6.2, then you are sorely out of date
(hell, that was still a 2.2 kernel system). Things have improved a lot
since then. The one overridding rule of working with a tree like we
ship though, is *NEVER* do anything in the tree itself. That tree is
assembled to provide *ALL* the kernel versions and includes for all the
kernels we ship. However, even doing a make dep in the tree will blow
important parts away. Download my module build kit and see what I'm
talking about because you currently obviously *don't* know what I'm
talking about.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Jeff Merkey wrote:
> Doug,
>
> I have seen some problems with the rpm build and default install of your
> kernel sources.
> NWFS and the SCI drivers will **NOT** build against it since you post in a
> linux and linux-up kernel for lilo during boot.
It would if you used my module build kit.
> People using these drivers
> who email me always have to do a "make distclean" to get stuff to build.
They (and you) think they do, but they don't.
> I
> am very familiar with the kernel.h
> changes you guys put in that are different from stock kernels, but despite
> this, it's
> far from "plug and play" for a customer building third party kernel modules
> on your rpms.
See my build kit (which has been available since 6.2 incidentally).
Very plug and play for a kernel developer.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Which kernel version? Neither NWFS or SCI will build against "stock"
installed kernel sources provided with Seawolf.
Jeff
----- Original Message -----
From: "Doug Ledford" <[email protected]>
To: "Jeff Merkey" <[email protected]>
Cc: "Arjan van de Ven" <[email protected]>;
<[email protected]>
Sent: Wednesday, November 21, 2001 1:36 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> Jeff Merkey wrote:
>
> >>Have you even looked at the kernel-source RPM ?
> >>
> >
> > Yes. I based a Linux distribution on RedHat's 6.2 last year, and I am
> > **VERY** familiar with your anaconda installer and kernel.src.rpm build
> > modules. I know the 7.X stuff got a hell of a lot better, but customers
> > still have to sterilize the build area are your rpm gets installed in
order
> > to build external kernel modules.
>
>
> <sigh> Again, this isn't true. I build modules against our
> kernel-source RPM tree all the time, and I *never* do a make distclean.
> If I did, it would screw the tree permanently. If you are basing your
> arguments about what you saw with 6.2, then you are sorely out of date
> (hell, that was still a 2.2 kernel system). Things have improved a lot
> since then. The one overridding rule of working with a tree like we
> ship though, is *NEVER* do anything in the tree itself. That tree is
> assembled to provide *ALL* the kernel versions and includes for all the
> kernels we ship. However, even doing a make dep in the tree will blow
> important parts away. Download my module build kit and see what I'm
> talking about because you currently obviously *don't* know what I'm
> talking about.
>
>
>
>
> --
>
> Doug Ledford <[email protected]> http://people.redhat.com/dledford
> Please check my web site for aic7xxx updates/answers before
> e-mailing me about problems
----- Original Message -----
From: "Doug Ledford" <[email protected]>
To: "Jeff Merkey" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Wednesday, November 21, 2001 1:38 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode
> Jeff Merkey wrote:
>
> > Doug,
> >
> > I have seen some problems with the rpm build and default install of your
> > kernel sources.
> > NWFS and the SCI drivers will **NOT** build against it since you post in
a
> > linux and linux-up kernel for lilo during boot.
>
>
> It would if you used my module build kit.
>
Where is this kit? Is is included in the distribution. This is way OT,
lets take this discussion off line regarding specific red hat issues.
Jeff
> > People using these drivers
> > who email me always have to do a "make distclean" to get stuff to build.
>
>
> They (and you) think they do, but they don't.
>
> > I
> > am very familiar with the kernel.h
> > changes you guys put in that are different from stock kernels, but
despite
> > this, it's
> > far from "plug and play" for a customer building third party kernel
modules
> > on your rpms.
>
>
>
> See my build kit (which has been available since 6.2 incidentally).
> Very plug and play for a kernel developer.
>
>
>
>
>
>
> --
>
> Doug Ledford <[email protected]> http://people.redhat.com/dledford
> Please check my web site for aic7xxx updates/answers before
> e-mailing me about problems
On Wed, 2001-11-21 at 16:16, Jeff Merkey wrote:
> Which kernel version? Neither NWFS or SCI will build against "stock"
> installed kernel sources provided with Seawolf.
You are using the kernel-source RPM and not the kernel SRPM, right?
I've seen that mistake. But, I've never seen a problem compiling
against kernel-source.
Robert Love