kernel BUG at slab.c:1073!

kernel BUG at slab.c:1073!

[Krishna Kondaka]

Hi,

	My system panics with the following message, when I do insmod of a
	driver.
	
kernel BUG at slab.c:1073!
Unable to handle kernel paging request at virtual address 00000000, epc == 
80131490, ra == 80131490
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 10009f00 0000001b 0000000a
$4 : 80282ab0 00000001 00000001 00000000
$8 : 802a2f42 b0060170 0000001b 0000000d
$12: 00000000 0000001b 10009f00 0000000a
$16: 00000000 000000f0 8fe40600 000000f0
$20: 00000001 1002d948 00000060 8fdd4ec0
$24: 802a2f27 ffffffff
$28: 8f3b6000 8f3b7df8 00000008 80131490
epc    : 0000000080131490
Status : 10009f03
Cause  : 1080000c

BadAddr: 000000008fdd4ec0Process insmod (pid: 67, stackpage=8f3b6000)
Stack: 8022a860 8022a878 00000431 8fe40600 8fe40600 000000f0 ffffffff ffffffea
       8f1b7000 80131988 0000003e 0000003c 00000059 80116110 00000000 00000000
       00000000 c0021538 10009f01 ffffffea 00000008 c001f000 10033338 ffffffea
       00000008 c001f000 10033338 ffffffea c0021b68 c0021b58 c00244b4 c00244a8
       00000043 00000002 00000000 c001f000 80117678 80116f98 80101c00 00030002
       80135e80 ...
Call Trace: [<8022a860>] [<8022a878>] [<80131988>] [<80116110>] [<c0021538>] 
[<c001f000>]
 [<c001f000>] [<c0021b68>] [<c0021b58>] [<c00244b4>] [<c00244a8>] [<c001f000>]
 [<80117678>] [<80116f98>] [<80101c00>] [<80135e80>] [<c0014000>] [<c001f060>]
 [<8010d924>] [<c001f060>]

Code: 24a5a878  0c0457ca  24060431 <ae000000> 24020020  126200c4  24140001  
40056000  34a10001 
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
Rebooting in 5 seconds..swarm_linux_exit called...passing control back to CFE

slab.c : line 1072-1073 is        

if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
                BUG();

The driver being loaded is a small proprietary driver. The init routine of
the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
that I can fix my driver to use GFP_ATOMIC if running in interrupt context.

My question is why is the "insmod" command running in interrupt context?

System Information:
================

# uname -a
Linux system1 2.4.9sb20011031 #1 Tue Mar  5 10:58:57 PST 2002 mips unknown

# cat cpuinfo
cpu                     : MIPS
processor               : 0
cpu model               : SiByte SB1 V0.1
BogoMIPS                : 266.24
system type             : SiByte SWARM
byteorder               : big endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : yes
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

# cat version
Linux version 2.4.9sb20011031 (gcc version 3.0.1 with SiByte modifications) #1 
Tue Mar  5 10:58:57 PST 2002



Thanks,
Krishna Kondaka
Sanera Systems, Inc.

Re: kernel BUG at slab.c:1073!

[Jun Sun]

Krishna Kondaka wrote:
> Hi,
> 
> 	My system panics with the following message, when I do insmod of a
> 	driver.
> 	
> kernel BUG at slab.c:1073!
> Unable to handle kernel paging request at virtual address 00000000, epc == 
> 80131490, ra == 80131490
> Oops in fault.c:do_page_fault, line 172:
> $0 : 00000000 10009f00 0000001b 0000000a
> $4 : 80282ab0 00000001 00000001 00000000
> $8 : 802a2f42 b0060170 0000001b 0000000d
> $12: 00000000 0000001b 10009f00 0000000a
> $16: 00000000 000000f0 8fe40600 000000f0
> $20: 00000001 1002d948 00000060 8fdd4ec0
> $24: 802a2f27 ffffffff
> $28: 8f3b6000 8f3b7df8 00000008 80131490
> epc    : 0000000080131490
> Status : 10009f03
> Cause  : 1080000c
> 
> BadAddr: 000000008fdd4ec0Process insmod (pid: 67, stackpage=8f3b6000)
> Stack: 8022a860 8022a878 00000431 8fe40600 8fe40600 000000f0 ffffffff ffffffea
>        8f1b7000 80131988 0000003e 0000003c 00000059 80116110 00000000 00000000
>        00000000 c0021538 10009f01 ffffffea 00000008 c001f000 10033338 ffffffea
>        00000008 c001f000 10033338 ffffffea c0021b68 c0021b58 c00244b4 c00244a8
>        00000043 00000002 00000000 c001f000 80117678 80116f98 80101c00 00030002
>        80135e80 ...
> Call Trace: [<8022a860>] [<8022a878>] [<80131988>] [<80116110>] [<c0021538>] 
> [<c001f000>]
>  [<c001f000>] [<c0021b68>] [<c0021b58>] [<c00244b4>] [<c00244a8>] [<c001f000>]
>  [<80117678>] [<80116f98>] [<80101c00>] [<80135e80>] [<c0014000>] [<c001f060>]
>  [<8010d924>] [<c001f060>]
> 
> Code: 24a5a878  0c0457ca  24060431 <ae000000> 24020020  126200c4  24140001  
> 40056000  34a10001 
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> Rebooting in 5 seconds..swarm_linux_exit called...passing control back to CFE
> 
> slab.c : line 1072-1073 is        
> 
> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>                 BUG();
> 
> The driver being loaded is a small proprietary driver. The init routine of
> the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
> that I can fix my driver to use GFP_ATOMIC if running in interrupt context.
> 
> My question is why is the "insmod" command running in interrupt context?
> 

I don't think insmod should have interrupt context set.

Do you have preemptible kernel enabled?  This problem often happens if 
preemptible kernel is enabled and there is a missing interrupt path not pre-k 
ready.

Jun

Re: kernel BUG at slab.c:1073!

[Ralf Baechle]

On Wed, Jul 24, 2002 at 11:34:13AM -0700, Krishna Kondaka wrote:

> slab.c : line 1072-1073 is        
> 
> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>                 BUG();
> 
> The driver being loaded is a small proprietary driver. The init routine of
> the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
> that I can fix my driver to use GFP_ATOMIC if running in interrupt context.
> 
> My question is why is the "insmod" command running in interrupt context?

Simple answer: it isn't, normally.  You should try to figure out who was
calling kmalloc or the slab allocator; knowing the function will probably
already solve the miracle.  All the addresses in the call trace that are
in the range from 0xc0000000 and above are potencially modules addresses,
so they're worth some closer examination.

Aside, I urgently recommend an upgrade to a newer kernel.  2.4.9 is lacking
more than half a year worth of bug fixes.  That can ruin your whole day ...

  Ralf

Re: kernel BUG at slab.c:1073!

[Krishna Kondaka]

>> slab.c : line 1072-1073 is        
>> 
>> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>>                 BUG();
>> 
>> The driver being loaded is a small proprietary driver. The init routine of
>> the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
>> that I can fix my driver to use GFP_ATOMIC if running in interrupt context.
>> 
>> My question is why is the "insmod" command running in interrupt context?
>> 
>
>I don't think insmod should have interrupt context set.
>
>Do you have preemptible kernel enabled?  This problem often happens if 
>preemptible kernel is enabled and there is a missing interrupt path not pre-k 
>ready.
>

Thanks for the quick reply jun,

I don't think I am running preemptible kernel. Is there /proc file that shows
if I am running preemptible kernel or not?

Thanks
Krishna

>Jun

Re: kernel BUG at slab.c:1073!

[Ralf Baechle]

On Wed, Jul 24, 2002 at 12:08:34PM -0700, Krishna Kondaka wrote:

> I don't think I am running preemptible kernel. Is there /proc file that shows
> if I am running preemptible kernel or not?

If the kernel you're running is from Broadcom it doesn't contain the
preemption patches.  Just check your kernel .config file for
CONFIG_PREEMPT.

  Ralf

Re: kernel BUG at slab.c:1073!

[Jun Sun]

Ralf Baechle wrote:
> On Wed, Jul 24, 2002 at 12:08:34PM -0700, Krishna Kondaka wrote:
> 
> 
>>I don't think I am running preemptible kernel. Is there /proc file that shows
>>if I am running preemptible kernel or not?
> 
> 
> If the kernel you're running is from Broadcom it doesn't contain the
> preemption patches.  Just check your kernel .config file for
> CONFIG_PREEMPT.
> 

Or at the run-time, do "grep preempt /proc/ksyms" to see if you find any symbols.

Jun

Re: kernel BUG at slab.c:1073!

[Krishna Kondaka]

I just checked my .config file and there is no CONFIG_PREEMPT.

Krishna

>Date: Wed, 24 Jul 2002 21:14:14 +0200
>From: Ralf Baechle <ralf@oss.sgi.com>
>To: Krishna Kondaka <krishna@Sanera.net>
>Cc: jsun@mvista.com, linux-mips@oss.sgi.com
>Subject: Re: kernel BUG at slab.c:1073!
>Mime-Version: 1.0
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5.1i
>X-Accept-Language: de,en,fr
>
>On Wed, Jul 24, 2002 at 12:08:34PM -0700, Krishna Kondaka wrote:
>
>> I don't think I am running preemptible kernel. Is there /proc file that shows
>> if I am running preemptible kernel or not?
>
>If the kernel you're running is from Broadcom it doesn't contain the
>preemption patches.  Just check your kernel .config file for
>CONFIG_PREEMPT.
>
>  Ralf

Re: kernel BUG at slab.c:1073!

[Krishna Kondaka]

>
>> slab.c : line 1072-1073 is        
>> 
>> if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
>>                 BUG();
>> 
>> The driver being loaded is a small proprietary driver. The init routine of
>> the driver is doing kmalloc() with GFP_KERNEL as the second argument. I know
>> that I can fix my driver to use GFP_ATOMIC if running in interrupt context.
>> 
>> My question is why is the "insmod" command running in interrupt context?
>
>Simple answer: it isn't, normally.  You should try to figure out who was
>calling kmalloc or the slab allocator; knowing the function will probably
>already solve the miracle.  All the addresses in the call trace that are
>in the range from 0xc0000000 and above are potencially modules addresses,
>so they're worth some closer examination.

well, my init code is some what like this -

int __init xxx_init(void)
{
	...
	xxx_init_instance();
}

int xxx_init_instance()
{
	...some code containing locks and unlocks()...
	xxx_inst = kmalloc(size, GFP_KERNEL);
}

So from this code, only xxx_init_instance should be calling kmalloc(). I will
check the caller and let you know.

>
>Aside, I urgently recommend an upgrade to a newer kernel.  2.4.9 is lacking
>more than half a year worth of bug fixes.  That can ruin your whole day ...

Unfortunately, it's not that easy. It will ruin more than a single day
for more than one person! We will very soon move to the version supplied by
monta vista based on 2.4.17.

Krishna

>
>  Ralf

RE: kernel BUG at slab.c:1073!

[Steven Seeger]

I had this problem when trying to run a module compiled for kernel version
2.4.18 on the old 2.4.0-test9 VR kernel. Something to do with different flag
values I think. A recompile with links to the proper kernel sources solved
the problem. Kmalloc was causing the issue. The flag value of GFP_KERNEL was
different or something.

Steve

RE: kernel BUG at slab.c:1073!

[Steven Seeger]

I had this problem when trying to run a module compiled for kernel version
2.4.18 on the old 2.4.0-test9 VR kernel. Something to do with different flag
values I think. A recompile with links to the proper kernel sources solved
the problem. Kmalloc was causing the issue. The flag value of GFP_KERNEL was
different or something.

Steve

Re: kernel BUG at slab.c:1073!

[Ralf Baechle]

On Thu, Jul 25, 2002 at 05:06:37AM -0700, Steven Seeger wrote:

> I had this problem when trying to run a module compiled for kernel version
> 2.4.18 on the old 2.4.0-test9 VR kernel. Something to do with different flag
> values I think. A recompile with links to the proper kernel sources solved
> the problem. Kmalloc was causing the issue. The flag value of GFP_KERNEL was
> different or something.

Normally CONFIG_MODVERSIONS is supposed to avoid such accidents.

  Ralf