kernel bug

[Ben Scott]

On Thu, Feb 21, 2008 at 9:15 PM, amc <acrossonlnx at comcast.net> wrote:
> yes ndiswrapper is patched the /usr/src/linux from the gentoo ebuild.
>  when you emerge ndiswrapper it looks at the kernel source and patchs it to
>  the kernel.
>  then you can load the ndiswrapper as a module

  As far as I know, ndiswrapper is *always* a module.  And if it's
being compiled as a module, then it's being loaded either by an
initrd, or after /sbin/init is started.  Since you're not using an
initrd, that means ndiswrapper is being loaded by some userspace
program started by /sbin/init -- probably the sysinit script specified
in /etc/inittab.  This is really academic -- we have no reason to
believe exactly how ndiswrapper is being invoked has any bearing on
the problem.

>yes ndiswraper does work

  Sometimes.  Sometimes it crashes the system.  Inconsistent behavior
is not uncommon with ndiswrapper.  ndiswrapper is really an
abomination, just one that happens to work in many cases.  :)

  Probabbly the most useful things you can provide us at this point
are (1) the top few entries from the kernel call stack trace, and (2)
the console message(s) from immediately prior to the crash.  You don't
have to transcribe things verbatim.  Addresses and punctuation are
less important at this point.  But the function and module names from
the stack will tell us what the kernel was doing when it crashed.  And
the console messages will tell us what the system was attempting to do
immediately before it crashed.

  There's a good example of a kernel oops message here:

http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01199.html

  Look about 20 lines in, and you'll see a label "Call Trace:".
Following that are entries from the kernel's call stack.  Addresses
are given in square and angle brackets, and then module and function
names, and then some memory offsets.  If this was your message, we'd
be most interested in the fact that the top few calls were:

ext3 htree store dirent
ext3 htree dirblock to tree
ext3 htree fill tree
cfq next request

  In that sample, it looks like the kernel crashed trying to store a
hash-tree directory entry in the ext3 filesystem code, which would
give us an idea of where to start looking.

  Assuming the problem is with ndiswrapper: Aside from the APIC stuff
I mentioned, Is your kernel patched to use the extra-large stacks that
Jarod Wilson mentioned?  Google results lead me to believe that stack
overflows with ndiswrapper can definitely result in kernel crashes.

-- Ben