CONFIG_DEBUG_SLAB=y prevents kernel panic

CONFIG_DEBUG_SLAB=y prevents kernel panic

[Ian Pilcher]

I'm hoping someone can provide me with some pointers to help debug this
problem.

My system is an Abit VP6 with two 1GHz Pentium III processors, running
Red Hat Linux/Fedora Core.  One of the kernel updates to Red Hat 9
messed up APIC-based interrupt routing on this board, causing USB
devices to not be recognized.

(See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=92417.)

So I was pretty happy when one of the Fedora core test releases was able
to boot with ACPI turned on and recognize USB devices.  Fedora Core 1,
however, panics when I boot with 'acpi=on'.  I have traced this
regression to the fact that CONFIG_DEBUG_SLAB was turned on in the test
release kernel, but it's off in the "production" kernel.

The question is, where do I go from here?  The help for
CONFIG_DEBUG_SLAB makes it seem unlikely that this is the root cause,
but I don't have any idea how I can debug this further.

TIA for any help.
-- 
========================================================================
Ian Pilcher                                        i.pilcher-Wuw85uim5zDR7s880joybQ@public.gmane.org
========================================================================



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: CONFIG_DEBUG_SLAB=y prevents kernel panic

[Janek Kozicki]

Ian Pilcher said:     (by the date of Fri, 05 Dec 2003 14:55:58 -0600)

> I'm hoping someone can provide me with some pointers to help debug this
> problem.
> 
> My system is an Abit VP6 with two 1GHz Pentium III processors, running
> Red Hat Linux/Fedora Core.  One of the kernel updates to Red Hat 9
> messed up APIC-based interrupt routing on this board, causing USB
> devices to not be recognized.

hello, I have abit VP6 with two 600 MHz P3, 

I have been fighting with usb for two weeks. And I discovered the
solution is: set MPS in BIOS to 1.1. anyway, my reports on this fight are here:

http://sourceforge.net/mailarchive/message.php?msg_id=6652068

I'm currently using 2.4.23 unpatched. and here is my config:

http://absurd.kozicki.pl:8435/pub/config-2.4.23.debug

I'm debugging kernel right now, because I had a lockup a week ago. But
now it now doesn't repeat. Will see...


-- 
# Janek Kozicki


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: CONFIG_DEBUG_SLAB=y prevents kernel panic

[Alan Cox]

On Gwe, 2003-12-05 at 20:55, Ian Pilcher wrote:
> The question is, where do I go from here?  The help for
> CONFIG_DEBUG_SLAB makes it seem unlikely that this is the root cause,
> but I don't have any idea how I can debug this further.

If that is really what makes the difference then 99 times out of 100 you
are looking for code that kmallocs memory and then relies on its content
without clearing it.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: CONFIG_DEBUG_SLAB=y prevents kernel panic

[Ian Pilcher]

Alan Cox wrote:
> On Gwe, 2003-12-05 at 20:55, Ian Pilcher wrote:
> 
>>The question is, where do I go from here?  The help for
>>CONFIG_DEBUG_SLAB makes it seem unlikely that this is the root cause,
>>but I don't have any idea how I can debug this further.
> 
> 
> If that is really what makes the difference then 99 times out of 100 you
> are looking for code that kmallocs memory and then relies on its content
> without clearing it.
> 
> 

Setting CONFIG_DEBUG_SLAB is definitely the deciding factor.  (I editted
the i686-smp config file and rebuilt the SRPM; voila!, it boots with
ACPI turned on.)

Any suggestions on how I can find the offending code?

-- 
========================================================================
Ian Pilcher                                        i.pilcher-Wuw85uim5zDR7s880joybQ@public.gmane.org
========================================================================




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/