Linux Kernel Panic on 547x System

SteveJoiner — Fri, 01 Feb 2008 23:26:22 GMT

I'm using the latest ltib on a custom 5474 board. I've got an external interrupt (IRQ7) that I have written a driver to support. The driver is complied as a kernel module and loaded at boot time. My problem is that I'm getting occasional kernel panics as a result of this driver. I thought the problem may be related to the fact that the coldfire external interrupts are non-maskable so there may be some reentrancy problems in the kernel. I wrote a custom interrupt handler in the kernel for that interrupt that just triggers a software interrupt and then exits, then my driver waited for the software interrupt instead. Unfortunately, that didn't solve the problem. Now, I don't know where to look next. I'm including the kernel panic below. Can anyone decipher it and point me in the right direction?

Thanks,
Steve

*** ADDRESS ERROR ***   FORMAT=4
Current process id is 715
BAD KERNEL TRAP: 00000000
Modules linked in: habanero
PC: [<c488c050>] hab_int_handler+0x0/0x3e [habanero]

SR: 2500 SP: c02e9ee8 a2: c3e3af90
d0: 00000001    d1: 400980a1    d2: 00000048    d3: c02e9f4c
d4: 00000000    d5: 00000013    a0: c488c050    a1: c3fdc878
Process syslogd (pid: 715, stackpage=c3e3cf90)
Stack from c02e9ee8:
        400980a1 00000048 c02e9f4c 00000000 00000013 c488c050 c3fdc878 c3e3af90
        00000001 ffffffff 00000000 40132360 00000000 440c2500 c488c050 c0006bb2
        00000048 00000000 c02e9f4c 40098001 40132004 c02e9fc4 c0002646 00000048
        c02e9f4c 400980a1 40098001 40132004 00000000 00000013 c02e6130 c3fdc878
        c3e3af90 00000000 ffffffff 00000000 40132360 00000000 41202004 c0005f80
        00000005 40132360 00000000 80074fc7 c000354e c02e9fc4 00000000 00000000
Call Trace: [<c000242a>] buserr+0x42/0x4c

Badness in local_bh_enable at kernel/softirq.c:140
Call Trace: [<c0010128>] local_bh_enable+0x74/0x96
[<c01cdd3f>] __func__.12977+0x1add/0x197c0
[<c01b6a49>] __func__.10886+0x0/0x10
[<c01ce082>] __func__.12977+0x1e20/0x197c0
[<c0128586>] lock_sock+0xd2/0x10c
[<c0003534>] buserr_c+0x10e/0x156
[<c0127072>] sock_fasync+0x36/0x1b0
[<c0127202>] sock_close+0x16/0x3a
[<c00448e6>] __fput+0x42/0xc4
[<c00d7b1c>] __up_read+0x0/0x78
[<c0044a56>] fput+0x18/0x1c
[<c0042128>] filp_close+0x56/0x7a
[<c000cd7c>] put_files_struct+0xbc/0xf6
[<c000e006>] do_exit+0x136/0xc62
[<c000b7c4>] printk+0x0/0x1e
[<c01e2147>] __func__.12977+0x15ee5/0x197c0
[<c0002ed4>] bad_super_trap+0x0/0x6a
[<c01cceba>] __func__.12977+0xc58/0x197c0
[<c000b7c4>] printk+0x0/0x1e
[<c0002f34>] bad_super_trap+0x60/0x6a
[<c01ccf13>] __func__.12977+0xcb1/0x197c0
[<c01ccef9>] __func__.12977+0xc97/0x197c0
[<c01ccee1>] __func__.12977+0xc7f/0x197c0
[<c01cd0b8>] __func__.12977+0xe56/0x197c0
[<c0002f6e>] trap_c+0x30/0x23e
[<c000242a>] buserr+0x42/0x4c
[<c000354e>] buserr_c+0x128/0x156
[<c0002466>] trap+0x32/0x3c
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c0006bb2>] process_int+0x36/0x78
[<c0002646>] inthandler+0x42/0x44
[<c0005f80>] cf_tlb_miss+0x15e/0x182
[<c000354e>] buserr_c+0x128/0x156
[<c000242a>] buserr+0x42/0x4c

Badness in local_bh_enable at kernel/softirq.c:140
Call Trace: [<c0010128>] local_bh_enable+0x74/0x96
[<c01cdd3f>] __func__.12977+0x1add/0x197c0
[<c01b6a49>] __func__.10886+0x0/0x10
[<c01ce082>] __func__.12977+0x1e20/0x197c0
[<c0128484>] release_sock+0xa2/0xd2
[<c01270da>] sock_fasync+0x9e/0x1b0
[<c0127202>] sock_close+0x16/0x3a
[<c00448e6>] __fput+0x42/0xc4
[<c00d7b1c>] __up_read+0x0/0x78
[<c0044a56>] fput+0x18/0x1c
[<c0042128>] filp_close+0x56/0x7a
[<c000cd7c>] put_files_struct+0xbc/0xf6
[<c000e006>] do_exit+0x136/0xc62
[<c000b7c4>] printk+0x0/0x1e
[<c01e2147>] __func__.12977+0x15ee5/0x197c0
[<c0002ed4>] bad_super_trap+0x0/0x6a
[<c01cceba>] __func__.12977+0xc58/0x197c0
[<c000b7c4>] printk+0x0/0x1e
[<c0002f34>] bad_super_trap+0x60/0x6a
[<c01ccf13>] __func__.12977+0xcb1/0x197c0
[<c01ccef9>] __func__.12977+0xc97/0x197c0
[<c01ccee1>] __func__.12977+0xc7f/0x197c0
[<c01cd0b8>] __func__.12977+0xe56/0x197c0
[<c0002f6e>] trap_c+0x30/0x23e
[<c000242a>] buserr+0x42/0x4c
[<c000354e>] buserr_c+0x128/0x156
[<c0002466>] trap+0x32/0x3c
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c0006bb2>] process_int+0x36/0x78
[<c0002646>] inthandler+0x42/0x44
[<c0005f80>] cf_tlb_miss+0x15e/0x182
[<c000354e>] buserr_c+0x128/0x156
[<c000242a>] buserr+0x42/0x4c

Badness in local_bh_enable at kernel/softirq.c:140
Call Trace: [<c0010128>] local_bh_enable+0x74/0x96
[<c01cdd3f>] __func__.12977+0x1add/0x197c0
[<c01b6a49>] __func__.10886+0x0/0x10
[<c01ce082>] __func__.12977+0x1e20/0x197c0
[<c017a83c>] unix_release_sock+0x6a/0x2fe
[<c017aae6>] unix_release+0x16/0x1a
[<c012682e>] sock_release+0x16/0x74
[<c012720c>] sock_close+0x20/0x3a
[<c00448e6>] __fput+0x42/0xc4
[<c00d7b1c>] __up_read+0x0/0x78
[<c0044a56>] fput+0x18/0x1c
[<c0042128>] filp_close+0x56/0x7a
[<c000cd7c>] put_files_struct+0xbc/0xf6
[<c000e006>] do_exit+0x136/0xc62
[<c000b7c4>] printk+0x0/0x1e
[<c01e2147>] __func__.12977+0x15ee5/0x197c0
[<c0002ed4>] bad_super_trap+0x0/0x6a
[<c01cceba>] __func__.12977+0xc58/0x197c0
[<c000b7c4>] printk+0x0/0x1e
[<c0002f34>] bad_super_trap+0x60/0x6a
[<c01ccf13>] __func__.12977+0xcb1/0x197c0
[<c01ccef9>] __func__.12977+0xc97/0x197c0
[<c01ccee1>] __func__.12977+0xc7f/0x197c0
[<c01cd0b8>] __func__.12977+0xe56/0x197c0
[<c0002f6e>] trap_c+0x30/0x23e
[<c000242a>] buserr+0x42/0x4c
[<c000354e>] buserr_c+0x128/0x156
[<c0002466>] trap+0x32/0x3c
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c488c050>] hab_int_handler+0x0/0x3e [habanero]
[<c0006bb2>] process_int+0x36/0x78
[<c0002646>] inthandler+0x42/0x44
[<c0005f80>] cf_tlb_miss+0x15e/0x182
[<c000354e>] buserr_c+0x128/0x156
[<c000242a>] buserr+0x42/0x4c

Re: Linux Kernel Panic on 547x System

SteveJoiner — Sat, 02 Feb 2008 06:53:34 GMT

For what it's worth, here's the custom interrupt handler I wrote for the non maskable interrupt IRQ7. I modified the vector table so that this routine is called for IRQ7 instead of the kernel's inthandler. Maybe someone can detect a problem with it?

asm(".text\n"
    "hab_nmihandler:\n"
    "movel %a0,%sp@-\n"
    "movel %d0,%sp@-\n"

    /* MCF_INTFRCL |= 0x100 --> force maskable int */
    "moveal #(0xe0000000+0x714),%a0\n"
    "movel %a0@,%d0\n"
    "bset #8,%d0\n"
    "movel %d0,%a0@\n"

    /* MCF_EPFR = 0x80 --> clear edge port */
    "moveq #-128,%d0\n"
    "moveb %d0,0xe0000000+0xF0C\n"

    "movel %sp@+,%d0\n"
    "movel %sp@+,%a0\n"
    "rte");

Re: Linux Kernel Panic on 547x System

SteveJoiner — Wed, 06 Feb 2008 03:29:51 GMT

I made a hardware mod to use IRQ6 instead of IRQ7. When I do that, everything works fine. No kernel panics. Unfortunately, we already have units in the field, so a software fix is preferred. Something is definitely going on with the fact that IRQ7 is non-maskable. Can anyone offer any advice?

Thanks,
Steve

ColdFire/68K Microcontrollers and ProcessorsのトピックLinux Kernel Panic on 547x System

Linux Kernel Panic on 547x System

Re: Linux Kernel Panic on 547x System

Re: Linux Kernel Panic on 547x System