Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Robert Love]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "Doug Ledford" <dledford@redhat.com>
To: "Jeff Merkey" <jmerkey@timpanogas.org>
Cc: <arjan@fenrus.demon.nl>; <linux-kernel@vger.kernel.org>
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 <dledford@redhat.com>  http://people.redhat.com/dledford
>        Please check my web site for aic7xxx updates/answers before
>                        e-mailing me about problems

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

Which kernel version?  Neither NWFS or SCI will build against "stock"
installed kernel sources provided with Seawolf.

Jeff


----- Original Message -----
From: "Doug Ledford" <dledford@redhat.com>
To: "Jeff Merkey" <jmerkey@timpanogas.org>
Cc: "Arjan van de Ven" <arjan@fenrus.demon.nl>;
<linux-kernel@vger.kernel.org>
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 <dledford@redhat.com>  http://people.redhat.com/dledford
>        Please check my web site for aic7xxx updates/answers before
>                        e-mailing me about problems

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Doug Ledford]

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 <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Doug Ledford]

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 <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[J Sloan]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "Arjan van de Ven" <arjan@fenrus.demon.nl>
To: "Jeff Merkey" <jmerkey@timpanogas.org>
Cc: <linux-kernel@vger.kernel.org>
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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Arjan van de Ven]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Doug Ledford]

Jeff Merkey wrote:

> ----- Original Message -----
> From: <arjan@fenrus.demon.nl>
> To: "Jeff Merkey" <jmerkey@timpanogas.org>
> Cc: <linux-kernel@vger.kernel.org>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 



-- 

  Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
       Please check my web site for aic7xxx updates/answers before
                       e-mailing me about problems

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: <arjan@fenrus.demon.nl>
To: "Jeff Merkey" <jmerkey@timpanogas.org>
Cc: <linux-kernel@vger.kernel.org>
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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "Kai Henningsen" <kaih@khms.westfalen.de>
To: <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 20, 2001 11:47 PM
Subject: Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid
opcode


> jmerkey@vger.timpanogas.org (Jeff V. Merkey)  wrote on 21.11.01 in
<20011121003304.A683@vger.timpanogas.org>:
>
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: <linux-kernel@vger.kernel.org>; <jmerkey@timpanogas.org>
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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Alan Cox]

> 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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[arjan]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff V. Merkey]

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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Stuart Young]

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      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

[VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff V. Merkey]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]



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


[-- Attachment #2: kmem.oops --]
[-- Type: text/plain, Size: 3533 bytes --]

ksymoops 2.4.0 on i686 2.4.15-pre7.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.15-pre7/ (default)
     -m /boot/System.map-2.4.15-pre7 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Nov 21 00:11:14 vger kernel: invalid operand: 0000
Nov 21 00:11:14 vger kernel: CPU:    0
Nov 21 00:11:14 vger kernel: EIP:    0010:[<c012b0eb>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Nov 21 00:11:14 vger kernel: EFLAGS: 00010246
Nov 21 00:11:14 vger kernel: eax: 00000000   ebx: c13da430   ecx: c13da590   edx: c13da684
Nov 21 00:11:14 vger kernel: esi: c13da58d   edi: cc9d8a40   ebp: c13da590   esp: c90e9ef8
Nov 21 00:11:14 vger kernel: ds: 0018   es: 0018   ss: 0018
Nov 21 00:11:14 vger kernel: Process nwfs-async0 (pid: 657, stackpage=c90e9000)
Nov 21 00:11:14 vger kernel: Stack: c90e9efc 00000040 c9265a90 cc9ed5c0 00000000 00000000 cc9b8f17 cc9d8a2f 
Nov 21 00:11:14 vger kernel:        00000060 00000020 00002000 00000000 00000000 00000000 00000000 00000000 
Nov 21 00:11:14 vger kernel:        00000000 00000000 cc9b97c5 00000008 00000200 00000008 c1242bc0 c930c818 
Nov 21 00:11:14 vger kernel: Call Trace: [<cc9ed5c0>] [<cc9b8f17>] [<cc9d8a2f>] [<cc9b97c5>] [<cc9ed5c0>] 
Nov 21 00:11:14 vger kernel:    [<cc9b6314>] [<cc9b6241>] [<cc9ddea0>] [<c0105bdc>] [<cc9ac4e7>] [<cc9d4f69>] 
Nov 21 00:11:14 vger kernel:    [<c0105616>] [<cc9ac478>] 
Nov 21 00:11:14 vger kernel: Code: 0f 0b 89 d1 8b 01 89 c2 0f 18 02 81 f9 4c 2b 2e c0 75 d2 8d 

>>EIP; c012b0eb <kmem_cache_create+2fb/340>   <=====
Trace; cc9ed5c0 <[nwfs]__module_using_checksums+9772/1c771>
Trace; cc9b8f17 <[nwfs]nwfs_get_bh+27/64>
Trace; cc9d8a2f <[nwfs].rodata.start+398f/8d3f>
Trace; cc9b97c5 <[nwfs]aReadDiskSectors+c9/210>
Trace; cc9ed5c0 <[nwfs]__module_using_checksums+9772/1c771>
Trace; cc9b6314 <[nwfs]process_asynch_io+174/274>
Trace; cc9b6241 <[nwfs]process_asynch_io+a1/274>
Trace; cc9ddea0 <[nwfs]asynch_io_sem0+8/14>
Trace; c0105bdc <__down+bc/d0>
Trace; cc9ac4e7 <[nwfs]nwfs_asynch_io_process+6f/cc>
Trace; cc9d4f69 <[nwfs].text.end+2e/165>
Trace; c0105616 <kernel_thread+26/30>
Trace; cc9ac478 <[nwfs]nwfs_asynch_io_process+0/cc>
Code;  c012b0eb <kmem_cache_create+2fb/340>
00000000 <_EIP>:
Code;  c012b0eb <kmem_cache_create+2fb/340>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c012b0ed <kmem_cache_create+2fd/340>
   2:   89 d1                     mov    %edx,%ecx
Code;  c012b0ef <kmem_cache_create+2ff/340>
   4:   8b 01                     mov    (%ecx),%eax
Code;  c012b0f1 <kmem_cache_create+301/340>
   6:   89 c2                     mov    %eax,%edx
Code;  c012b0f3 <kmem_cache_create+303/340>
   8:   0f 18 02                  prefetchnta (%edx)
Code;  c012b0f6 <kmem_cache_create+306/340>
   b:   81 f9 4c 2b 2e c0         cmp    $0xc02e2b4c,%ecx
Code;  c012b0fc <kmem_cache_create+30c/340>
  11:   75 d2                     jne    ffffffe5 <_EIP+0xffffffe5> c012b0d0 <kmem_cache_create+2e0/340>
Code;  c012b0fe <kmem_cache_create+30e/340>
  13:   8d 00                     lea    (%eax),%eax


1 warning issued.  Results may not be reliable.

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

>
> 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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[David S. Miller]

   From: "Jeff Merkey" <jmerkey@timpanogas.org>
   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?

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

This happens as well with the SCI drivers, which are not dependant on any
patches.

Jeff

----- Original Message -----
From: "Chris Abbey" <linux@cabbey.net>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: <linux-kernel@vger.kernel.org>
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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "David S. Miller" <davem@redhat.com>
To: <jmerkey@timpanogas.org>
Cc: <jmerkey@vger.timpanogas.org>; <linux-kernel@vger.kernel.org>
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" <jmerkey@timpanogas.org>
>    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 :-)

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[David S. Miller]

   From: "Jeff Merkey" <jmerkey@timpanogas.org>
   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 :-)

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Jeff Merkey]

----- Original Message -----
From: "David S. Miller" <davem@redhat.com>
To: <jmerkey@vger.timpanogas.org>
Cc: <linux-kernel@vger.kernel.org>; <jmerkey@timpanogas.org>
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" <jmerkey@vger.timpanogas.org>
>    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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Chris Abbey]

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.

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[David S. Miller]

   From: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
   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.

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[Kai Henningsen]

jmerkey@vger.timpanogas.org (Jeff V. Merkey)  wrote on 21.11.01 in <20011121003304.A683@vger.timpanogas.org>:

> 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

Re: [VM/MEMORY-SICKNESS] 2.4.15-pre7 kmem_cache_create invalid opcode

[David S. Miller]

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 :)