kernel bug

[amc]

after having several bugs in kernel I decided to use b43 and b43-fwcuter to 
get my wifi device working.
I took some pictures the bugs. one crash was my ext3 file system and another 
was the ndiswrapper. I will let you guys know if I have any other problems 
with the kernel crashes. ill be uploading the pictures as soon as I get my 
pictures from the camera.
----- Original Message ----- 
From: "Ben Scott" <dragonhawk at gmail.com>
To: "Greater NH Linux User Group" <gnhlug-discuss at mail.gnhlug.org>
Sent: Thursday, February 21, 2008 11:57 PM
Subject: Re: kernel bug


> 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
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>