* kernel BUG at kernel/posix-cpu-timers.c:1389!
@ 2009-10-30 16:53 E Robertson
2009-10-31 14:32 ` Eric Miao
0 siblings, 1 reply; 7+ messages in thread
From: E Robertson @ 2009-10-30 16:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi, I've recently migrated some code to 2.6.31 on a sam9263 board and
notice this on
several occasions. I thought it might be a serial driver port issue
since I haven't seen anyone with
this problem before, but that doesn't seem to be the culprit.
Is this is known kernel bug?
kernel BUG at kernel/posix-cpu-timers.c:1389!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1d34000
[00000000] *pgd=21fad031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
CPU: 0 Not tainted (2.6.31.5 #5)
PC is at __bug+0x20/0x2c
LR is at release_console_sem+0x1b0/0x1e4
pc : [<c00da2a0>] lr : [<c00ece48>] psr: 60000013
sp : c1d2be7c ip : c1d2bdb4 fp : c1d2be88
r10: 4004e108 r9 : c1d2a000 r8 : c030a904
r7 : c031f8fc r6 : c031f900 r5 : c1c89380 r4 : 00000001
r3 : 00000000 r2 : c030c0fc r1 : 00016348 r0 : 00000034
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 21d34000 DAC: 00000015
Process TEST (pid: 386, stack limit = 0xc1d2a260)
Stack: (0xc1d2be7c to 0xc1d2c000)
be60: c1d2bed0
be80: c1d2be8c c0100738 c00da290 c1d2beb4 c1d2be9c c00e9c58 c00e6ca0 c030bbf0
bea0: c1d2bea0 c1d2bea0 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000
bec0: 4004e108 c1d2bee8 c1d2bed4 c00f5cdc c0100710 0000000a c0325890 c1d2bf00
bee0: c1d2beec c0108e84 c00f5c94 00000001 c030a904 c1d2bf38 c1d2bf04 c0108ec0
bf00: c0108e00 c1c884c0 beb8fa54 c1d2bf80 00000001 c030a904 c031f900 c031f8fc
bf20: 00000000 c1d2a000 4004e108 c1d2bf58 c1d2bf3c c00df16c c0108eb4 c030a8d8
bf40: 00000001 00000001 00000000 c1d2bf7c c1d2bf5c c010df28 c00df120 c030ddec
bf60: 00000001 00000001 000007f0 ffffffff c1d2bf94 c1d2bf80 c010fdd4 c010def0
bf80: 00000001 00000000 c1d2bfac c1d2bf98 c00d6070 c010fd10 ffffffff fefff000
bfa0: 00000000 c1d2bfb0 c00d6be4 c00d6010 ffffffff 0003fa10 00000000 0000000b
bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff f507a7b8 c87e873f
Backtrace:
[<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
c)
[<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
_times+0x58/0x5c)
[<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
x94/0xb4)
r5:c0325890 r4:0000000a
[<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
x1c/0xf4)
r5:c030a904 r4:00000001
[<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
_interrupt+0x5c/0x80)
[<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
_event+0x48/0x114)
r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
[<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
xd4/0xec)
r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
[<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
8)
r5:00000000 r4:00000001
[<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
bfa0: ffffffff 0003fa10 00000000 0000000b
bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
r5:fefff000 r4:ffffffff
Code: e1a01000 e59f000c eb004c80 e3a03000 (e5833000)
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace:
[<c00da54c>] (dump_backtrace+0x0/0x10c) from [<c00da68c>] (dump_stack+0x18/0x1c
)
r6:c1d2be34 r5:c031fa70 r4:c1c89380
[<c00da674>] (dump_stack+0x0/0x1c) from [<c00ec678>] (panic+0x4c/0x12c)
[<c00ec62c>] (panic+0x0/0x12c) from [<c00da7dc>] (die+0x12c/0x158)
r3:00010000 r2:00000080 r1:c031fe98 r0:c02e0e08
[<c00da6b0>] (die+0x0/0x158) from [<c00dbd54>] (__do_kernel_fault+0x6c/0x7c)
[<c00dbce8>] (__do_kernel_fault+0x0/0x7c) from [<c00dbf88>] (do_page_fault+0x22
4/0x244)
r7:c1d2be34 r6:c1c89380 r5:c0309d10 r4:ffffffff
[<c00dbd64>] (do_page_fault+0x0/0x244) from [<c00d623c>] (do_DataAbort+0x3c/0xa
0)
[<c00d6200>] (do_DataAbort+0x0/0xa0) from [<c00d69e0>] (__dabt_svc+0x40/0x60)
Exception stack(0xc1d2be34 to 0xc1d2be7c)
be20: 00000034 00016348 c030c0fc
be40: 00000000 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000 4004e108
be60: c1d2be88 c1d2bdb4 c1d2be7c c00ece48 c00da2a0 60000013 ffffffff
r8:c030a904 r7:c031f8fc r6:c031f900 r5:c1d2be68 r4:ffffffff
[<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
c)
[<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
_times+0x58/0x5c)
[<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
x94/0xb4)
r5:c0325890 r4:0000000a
[<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
x1c/0xf4)
r5:c030a904 r4:00000001
[<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
_interrupt+0x5c/0x80)
[<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
_event+0x48/0x114)
r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
[<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
xd4/0xec)
r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
[<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
8)
r5:00000000 r4:00000001
[<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
bfa0: ffffffff 0003fa10 00000000 0000000b
bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
r5:fefff000 r4:ffffffff
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-10-30 16:53 kernel BUG at kernel/posix-cpu-timers.c:1389! E Robertson
@ 2009-10-31 14:32 ` Eric Miao
2009-11-02 16:47 ` Nicolas Ferre
0 siblings, 1 reply; 7+ messages in thread
From: Eric Miao @ 2009-10-31 14:32 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Oct 31, 2009 at 12:53 AM, E Robertson <e.robertson.svg@gmail.com> wrote:
> Hi, I've recently migrated some code to 2.6.31 on a sam9263 board and
> notice this on
> several occasions. I thought it might be a serial driver port issue
> since I haven't seen anyone with
> this problem before, but ?that doesn't seem to be the culprit.
> Is this is known kernel bug?
Looks like this run_posix_cpu_timers() is called with IRQ enabled, I'd
suggest you take a look into your arch/arm/mach-xxx/time.c to see if
your timer irq_action->flags is written with IRQF_DISABLED there.
>
> kernel BUG at kernel/posix-cpu-timers.c:1389!
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c1d34000
> [00000000] *pgd=21fad031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1]
> CPU: 0 ? ?Not tainted ?(2.6.31.5 #5)
> PC is at __bug+0x20/0x2c
> LR is at release_console_sem+0x1b0/0x1e4
> pc : [<c00da2a0>] ? ?lr : [<c00ece48>] ? ?psr: 60000013
> sp : c1d2be7c ?ip : c1d2bdb4 ?fp : c1d2be88
> r10: 4004e108 ?r9 : c1d2a000 ?r8 : c030a904
> r7 : c031f8fc ?r6 : c031f900 ?r5 : c1c89380 ?r4 : 00000001
> r3 : 00000000 ?r2 : c030c0fc ?r1 : 00016348 ?r0 : 00000034
> Flags: nZCv ?IRQs on ?FIQs on ?Mode SVC_32 ?ISA ARM ?Segment user
> Control: 0005317f ?Table: 21d34000 ?DAC: 00000015
> Process TEST (pid: 386, stack limit = 0xc1d2a260)
> Stack: (0xc1d2be7c to 0xc1d2c000)
> be60: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?c1d2bed0
> be80: c1d2be8c c0100738 c00da290 c1d2beb4 c1d2be9c c00e9c58 c00e6ca0 c030bbf0
> bea0: c1d2bea0 c1d2bea0 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000
> bec0: 4004e108 c1d2bee8 c1d2bed4 c00f5cdc c0100710 0000000a c0325890 c1d2bf00
> bee0: c1d2beec c0108e84 c00f5c94 00000001 c030a904 c1d2bf38 c1d2bf04 c0108ec0
> bf00: c0108e00 c1c884c0 beb8fa54 c1d2bf80 00000001 c030a904 c031f900 c031f8fc
> bf20: 00000000 c1d2a000 4004e108 c1d2bf58 c1d2bf3c c00df16c c0108eb4 c030a8d8
> bf40: 00000001 00000001 00000000 c1d2bf7c c1d2bf5c c010df28 c00df120 c030ddec
> bf60: 00000001 00000001 000007f0 ffffffff c1d2bf94 c1d2bf80 c010fdd4 c010def0
> bf80: 00000001 00000000 c1d2bfac c1d2bf98 c00d6070 c010fd10 ffffffff fefff000
> bfa0: 00000000 c1d2bfb0 c00d6be4 c00d6010 ffffffff 0003fa10 00000000 0000000b
> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff f507a7b8 c87e873f
> Backtrace:
> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
> c)
> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
> _times+0x58/0x5c)
> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
> x94/0xb4)
> ?r5:c0325890 r4:0000000a
> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
> x1c/0xf4)
> ?r5:c030a904 r4:00000001
> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
> _interrupt+0x5c/0x80)
> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
> _event+0x48/0x114)
> ?r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
> xd4/0xec)
> ?r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
> 8)
> ?r5:00000000 r4:00000001
> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
> bfa0: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ffffffff 0003fa10 00000000 0000000b
> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
> ?r5:fefff000 r4:ffffffff
> Code: e1a01000 e59f000c eb004c80 e3a03000 (e5833000)
> Kernel panic - not syncing: Fatal exception in interrupt
> Backtrace:
> [<c00da54c>] (dump_backtrace+0x0/0x10c) from [<c00da68c>] (dump_stack+0x18/0x1c
> )
> ?r6:c1d2be34 r5:c031fa70 r4:c1c89380
> [<c00da674>] (dump_stack+0x0/0x1c) from [<c00ec678>] (panic+0x4c/0x12c)
> [<c00ec62c>] (panic+0x0/0x12c) from [<c00da7dc>] (die+0x12c/0x158)
> ?r3:00010000 r2:00000080 r1:c031fe98 r0:c02e0e08
> [<c00da6b0>] (die+0x0/0x158) from [<c00dbd54>] (__do_kernel_fault+0x6c/0x7c)
> [<c00dbce8>] (__do_kernel_fault+0x0/0x7c) from [<c00dbf88>] (do_page_fault+0x22
> 4/0x244)
> ?r7:c1d2be34 r6:c1c89380 r5:c0309d10 r4:ffffffff
> [<c00dbd64>] (do_page_fault+0x0/0x244) from [<c00d623c>] (do_DataAbort+0x3c/0xa
> 0)
> [<c00d6200>] (do_DataAbort+0x0/0xa0) from [<c00d69e0>] (__dabt_svc+0x40/0x60)
> Exception stack(0xc1d2be34 to 0xc1d2be7c)
> be20: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?00000034 00016348 c030c0fc
> be40: 00000000 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000 4004e108
> be60: c1d2be88 c1d2bdb4 c1d2be7c c00ece48 c00da2a0 60000013 ffffffff
> ?r8:c030a904 r7:c031f8fc r6:c031f900 r5:c1d2be68 r4:ffffffff
> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
> c)
> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
> _times+0x58/0x5c)
> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
> x94/0xb4)
> ?r5:c0325890 r4:0000000a
> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
> x1c/0xf4)
> ?r5:c030a904 r4:00000001
> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
> _interrupt+0x5c/0x80)
> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
> _event+0x48/0x114)
> ?r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
> xd4/0xec)
> ?r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
> 8)
> ?r5:00000000 r4:00000001
> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
> bfa0: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ffffffff 0003fa10 00000000 0000000b
> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
> ?r5:fefff000 r4:ffffffff
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-10-31 14:32 ` Eric Miao
@ 2009-11-02 16:47 ` Nicolas Ferre
2009-11-02 16:54 ` Russell King - ARM Linux
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Ferre @ 2009-11-02 16:47 UTC (permalink / raw)
To: linux-arm-kernel
Eric Miao :
> On Sat, Oct 31, 2009 at 12:53 AM, E Robertson <e.robertson.svg@gmail.com> wrote:
>> Hi, I've recently migrated some code to 2.6.31 on a sam9263 board and
>> notice this on
>> several occasions. I thought it might be a serial driver port issue
>> since I haven't seen anyone with
>> this problem before, but that doesn't seem to be the culprit.
>> Is this is known kernel bug?
>
> Looks like this run_posix_cpu_timers() is called with IRQ enabled, I'd
> suggest you take a look into your arch/arm/mach-xxx/time.c to see if
> your timer irq_action->flags is written with IRQF_DISABLED there.
in arch/arm/mach-at91/at91sam926x_time.c +125
.flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
booting messages that:
"IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
What does this mean ? what is the difference with former way of managing
shared interrupts ?
And above all, what is the proper way to set an IRQ on a shared
interrupt line ?
>> kernel BUG at kernel/posix-cpu-timers.c:1389!
>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> pgd = c1d34000
>> [00000000] *pgd=21fad031, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 817 [#1]
>> CPU: 0 Not tainted (2.6.31.5 #5)
>> PC is at __bug+0x20/0x2c
>> LR is at release_console_sem+0x1b0/0x1e4
>> pc : [<c00da2a0>] lr : [<c00ece48>] psr: 60000013
>> sp : c1d2be7c ip : c1d2bdb4 fp : c1d2be88
>> r10: 4004e108 r9 : c1d2a000 r8 : c030a904
>> r7 : c031f8fc r6 : c031f900 r5 : c1c89380 r4 : 00000001
>> r3 : 00000000 r2 : c030c0fc r1 : 00016348 r0 : 00000034
>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>> Control: 0005317f Table: 21d34000 DAC: 00000015
>> Process TEST (pid: 386, stack limit = 0xc1d2a260)
>> Stack: (0xc1d2be7c to 0xc1d2c000)
>> be60: c1d2bed0
>> be80: c1d2be8c c0100738 c00da290 c1d2beb4 c1d2be9c c00e9c58 c00e6ca0 c030bbf0
>> bea0: c1d2bea0 c1d2bea0 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000
>> bec0: 4004e108 c1d2bee8 c1d2bed4 c00f5cdc c0100710 0000000a c0325890 c1d2bf00
>> bee0: c1d2beec c0108e84 c00f5c94 00000001 c030a904 c1d2bf38 c1d2bf04 c0108ec0
>> bf00: c0108e00 c1c884c0 beb8fa54 c1d2bf80 00000001 c030a904 c031f900 c031f8fc
>> bf20: 00000000 c1d2a000 4004e108 c1d2bf58 c1d2bf3c c00df16c c0108eb4 c030a8d8
>> bf40: 00000001 00000001 00000000 c1d2bf7c c1d2bf5c c010df28 c00df120 c030ddec
>> bf60: 00000001 00000001 000007f0 ffffffff c1d2bf94 c1d2bf80 c010fdd4 c010def0
>> bf80: 00000001 00000000 c1d2bfac c1d2bf98 c00d6070 c010fd10 ffffffff fefff000
>> bfa0: 00000000 c1d2bfb0 c00d6be4 c00d6010 ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff f507a7b8 c87e873f
>> Backtrace:
>> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
>> c)
>> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
>> _times+0x58/0x5c)
>> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
>> x94/0xb4)
>> r5:c0325890 r4:0000000a
>> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
>> x1c/0xf4)
>> r5:c030a904 r4:00000001
>> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
>> _interrupt+0x5c/0x80)
>> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
>> _event+0x48/0x114)
>> r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
>> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
>> xd4/0xec)
>> r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
>> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
>> 8)
>> r5:00000000 r4:00000001
>> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
>> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
>> bfa0: ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
>> r5:fefff000 r4:ffffffff
>> Code: e1a01000 e59f000c eb004c80 e3a03000 (e5833000)
>> Kernel panic - not syncing: Fatal exception in interrupt
>> Backtrace:
>> [<c00da54c>] (dump_backtrace+0x0/0x10c) from [<c00da68c>] (dump_stack+0x18/0x1c
>> )
>> r6:c1d2be34 r5:c031fa70 r4:c1c89380
>> [<c00da674>] (dump_stack+0x0/0x1c) from [<c00ec678>] (panic+0x4c/0x12c)
>> [<c00ec62c>] (panic+0x0/0x12c) from [<c00da7dc>] (die+0x12c/0x158)
>> r3:00010000 r2:00000080 r1:c031fe98 r0:c02e0e08
>> [<c00da6b0>] (die+0x0/0x158) from [<c00dbd54>] (__do_kernel_fault+0x6c/0x7c)
>> [<c00dbce8>] (__do_kernel_fault+0x0/0x7c) from [<c00dbf88>] (do_page_fault+0x22
>> 4/0x244)
>> r7:c1d2be34 r6:c1c89380 r5:c0309d10 r4:ffffffff
>> [<c00dbd64>] (do_page_fault+0x0/0x244) from [<c00d623c>] (do_DataAbort+0x3c/0xa
>> 0)
>> [<c00d6200>] (do_DataAbort+0x0/0xa0) from [<c00d69e0>] (__dabt_svc+0x40/0x60)
>> Exception stack(0xc1d2be34 to 0xc1d2be7c)
>> be20: 00000034 00016348 c030c0fc
>> be40: 00000000 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000 4004e108
>> be60: c1d2be88 c1d2bdb4 c1d2be7c c00ece48 c00da2a0 60000013 ffffffff
>> r8:c030a904 r7:c031f8fc r6:c031f900 r5:c1d2be68 r4:ffffffff
>> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
>> c)
>> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
>> _times+0x58/0x5c)
>> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
>> x94/0xb4)
>> r5:c0325890 r4:0000000a
>> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
>> x1c/0xf4)
>> r5:c030a904 r4:00000001
>> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
>> _interrupt+0x5c/0x80)
>> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
>> _event+0x48/0x114)
>> r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
>> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
>> xd4/0xec)
>> r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
>> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
>> 8)
>> r5:00000000 r4:00000001
>> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
>> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
>> bfa0: ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
>> r5:fefff000 r4:ffffffff
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Nicolas Ferre
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-11-02 16:47 ` Nicolas Ferre
@ 2009-11-02 16:54 ` Russell King - ARM Linux
2009-11-05 17:07 ` E Robertson
2009-11-30 13:21 ` Uwe Kleine-König
0 siblings, 2 replies; 7+ messages in thread
From: Russell King - ARM Linux @ 2009-11-02 16:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
> in arch/arm/mach-at91/at91sam926x_time.c +125
> .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
>
> IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
> booting messages that:
> "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
>
> What does this mean ? what is the difference with former way of managing
> shared interrupts ?
If the first IRQ action which is run was registered without IRQF_DISABLED
the entire set will be run without interrupts disabled.
> And above all, what is the proper way to set an IRQ on a shared
> interrupt line ?
The only real solution is to ensure that all requesters use IRQF_DISABLED.
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-11-02 16:54 ` Russell King - ARM Linux
@ 2009-11-05 17:07 ` E Robertson
2009-11-05 17:29 ` Russell King - ARM Linux
2009-11-30 13:21 ` Uwe Kleine-König
1 sibling, 1 reply; 7+ messages in thread
From: E Robertson @ 2009-11-05 17:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Nov 2, 2009 at 10:54 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
>> in arch/arm/mach-at91/at91sam926x_time.c +125
>> ?.flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
>>
>> IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
>> booting messages that:
>> "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
>>
>> What does this mean ? what is the difference with former way of managing
>> shared interrupts ?
>
> If the first IRQ action which is run was registered without IRQF_DISABLED
> the entire set will be run without interrupts disabled.
>
>> And above all, what is the proper way to set an IRQ on a shared
>> interrupt line ?
>
> The only real solution is to ensure that all requesters use IRQF_DISABLED.
>
I don't see where this could be the cause of this problem. The bug
happens after the system is running and I attempt to use the select
method for polling (serial port & uevents). Without this the bug [
BUG_ON(!irqs_disabled()); ] did not occur. I added the flag to the
requesters but that did not help, maybe I overlooked something.
I notice this change from 2.6.18 but didn't follow why the change.
--- linux-2.6.31/arch/arm/mach-at91/at91sam926x_time.c 2009-11-05
09:34:49.000000000 -0600
+++ linux-2.6.28/arch/arm/mach-at91/at91sam926x_time.c 2009-02-06
15:47:45.000000000 -0600
@@ -31,7 +31,7 @@
* Clocksource: just a monotonic counter of MCK/16 cycles.
* We don't care whether or not PIT irqs are enabled.
*/
-static cycle_t read_pit_clk(struct clocksource *cs)
+static cycle_t read_pit_clk(void)
{
unsigned long flags;
u32 elapsed;
@@ -91,6 +91,7 @@
.features = CLOCK_EVT_FEAT_PERIODIC,
.shift = 32,
.rating = 100,
+ .cpumask = CPU_MASK_CPU0,
.set_mode = pit_clkevt_mode,
};
@@ -172,7 +173,6 @@
/* Set up and register clockevents */
pit_clkevt.mult = div_sc(pit_rate, NSEC_PER_SEC, pit_clkevt.shift);
- pit_clkevt.cpumask = cpumask_of(0);
clockevents_register_device(&pit_clkevt);
}
kernel BUG at kernel/posix-cpu-timers.c:1389!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1d60000
[00000000] *pgd=21c81031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
CPU: 0 Not tainted (2.6.31.5 #17)
PC is at __bug+0x20/0x2c
LR is at release_console_sem+0x1a4/0x1d8
pc : [<c00da230>] lr : [<c00edc1c>] psr: 60000013
sp : c1de3e54 ip : c1de3d94 fp : c1de3e60
r10: c1de3e78 r9 : c1de2000 r8 : c0312954
r7 : 00000000 r6 : c1c506a0 r5 : c1c506a0 r4 : 00000001
r3 : 00000000 r2 : 60000013 r1 : 0001c1b0 r0 : 00000034
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 21d60000 DAC: 00000015
...
[<c00da3a8>] (__bug+0x0/0x2c) from [<c0105444>] (run_posix_cpu_timers+0x34/0x88
4)
[<c0105410>] (run_posix_cpu_timers+0x0/0x884) from [<c00f8a24>] (update_process
_times+0x5c/0x60)
[<c00f89c8>] (update_process_times+0x0/0x60) from [<c010dafc>] (tick_periodic+0
xb8/0xdc)
r6:00000001 r5:c0345790 r4:00000000
[<c010da44>] (tick_periodic+0x0/0xdc) from [<c010db40>] (tick_handle_periodic+0
x20/0xd0)
r5:c032a954 r4:00000001
[<c010db20>] (tick_handle_periodic+0x0/0xd0) from [<c00dfaf0>] (at91sam926x_pit
_interrupt+0x60/0x90)
[<c00dfa90>] (at91sam926x_pit_interrupt+0x0/0x90) from [<c0113ba8>] (handle_IRQ
_event+0x44/0x10c)
r5:00000001 r4:c032a99c
[<c0113b64>] (handle_IRQ_event+0x0/0x10c) from [<c011582c>] (handle_level_irq+0
xc4/0x13c)
r8:00000000 r7:c032a99c r6:00000000 r5:00000001 r4:c032e034
[<c0115768>] (handle_level_irq+0x0/0x13c) from [<c00d606c>] (asm_do_IRQ+0x6c/0x
9c)
r7:00000001 r6:00000000 r5:c0333e58 r4:00000001
[<c00d6000>] (asm_do_IRQ+0x0/0x9c) from [<c00d6a5c>] (__irq_svc+0x3c/0x80)
Exception stack(0xc1ce5f60 to 0xc1ce5fa8)
5f60: 00000006 beebaaa8 00000000 00000000 beebaaa0 beebaaa8 00000005 0000008e
5f80: c00d6fe4 c1ce4000 4004e108 00000000 00000000 c1ce5fa8 c00d6e40 c014bc68
5fa0: 80000013 ffffffff
r6:00000001 r5:fefff000 r4:ffffffff
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-11-05 17:07 ` E Robertson
@ 2009-11-05 17:29 ` Russell King - ARM Linux
0 siblings, 0 replies; 7+ messages in thread
From: Russell King - ARM Linux @ 2009-11-05 17:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Nov 05, 2009 at 11:07:41AM -0600, E Robertson wrote:
> On Mon, Nov 2, 2009 at 10:54 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
> >> in arch/arm/mach-at91/at91sam926x_time.c +125
> >> ?.flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> >>
> >> IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
> >> booting messages that:
> >> "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
> >>
> >> What does this mean ? what is the difference with former way of managing
> >> shared interrupts ?
> >
> > If the first IRQ action which is run was registered without IRQF_DISABLED
> > the entire set will be run without interrupts disabled.
> >
> >> And above all, what is the proper way to set an IRQ on a shared
> >> interrupt line ?
> >
> > The only real solution is to ensure that all requesters use IRQF_DISABLED.
> >
>
> I don't see where this could be the cause of this problem. The bug
> happens after the system is running and I attempt to use the select
> method for polling (serial port & uevents). Without this the bug [
> BUG_ON(!irqs_disabled()); ] did not occur. I added the flag to the
> requesters but that did not help, maybe I overlooked something.
Well, run_posix_cpu_timers() must be called with interrupts disabled.
This bug indicates that this has been violated.
Since we know that the timer stuff works on virtually every other
platform which makes use of the generic time infrastructure, I doubt
you've found a bug in it - so that tends to eliminate tick_handle_periodic()
and below in the call chain. (Oh how I absolutely detest how genirq is
completely undocumented with respect to details like this, and people
are left to guess.)
So, the only thing that leaves is that tick_handle_periodic() was called
with IRQs enabled.
You could try putting a BUG_ON(!irqs_disabled()) in parent functions to
trace where interrupts are being re-enabled, but I think you'll find that
at91sam926x_pit_interrupt() was called with IRQs enabled.
Now, for any shared interrupt, where some handlers are registered with
IRQF_DISABLED and non-IRQF_DISABLED can lead to IRQF_DISABLED handlers
being called with IRQs enabled (hence the "IRQF_SHARED is not guaranteed
on shared IRQs" warning). So... the solution is as I said above.
> [<c00da3a8>] (__bug+0x0/0x2c) from [<c0105444>] (run_posix_cpu_timers+0x34/0x88
> 4)
> [<c0105410>] (run_posix_cpu_timers+0x0/0x884) from [<c00f8a24>] (update_process
> _times+0x5c/0x60)
> [<c00f89c8>] (update_process_times+0x0/0x60) from [<c010dafc>] (tick_periodic+0
> xb8/0xdc)
> r6:00000001 r5:c0345790 r4:00000000
> [<c010da44>] (tick_periodic+0x0/0xdc) from [<c010db40>] (tick_handle_periodic+0
> x20/0xd0)
> r5:c032a954 r4:00000001
> [<c010db20>] (tick_handle_periodic+0x0/0xd0) from [<c00dfaf0>] (at91sam926x_pit
> _interrupt+0x60/0x90)
> [<c00dfa90>] (at91sam926x_pit_interrupt+0x0/0x90) from [<c0113ba8>] (handle_IRQ
> _event+0x44/0x10c)
> r5:00000001 r4:c032a99c
> [<c0113b64>] (handle_IRQ_event+0x0/0x10c) from [<c011582c>] (handle_level_irq+0
> xc4/0x13c)
> r8:00000000 r7:c032a99c r6:00000000 r5:00000001 r4:c032e034
> [<c0115768>] (handle_level_irq+0x0/0x13c) from [<c00d606c>] (asm_do_IRQ+0x6c/0x
> 9c)
> r7:00000001 r6:00000000 r5:c0333e58 r4:00000001
> [<c00d6000>] (asm_do_IRQ+0x0/0x9c) from [<c00d6a5c>] (__irq_svc+0x3c/0x80)
> Exception stack(0xc1ce5f60 to 0xc1ce5fa8)
> 5f60: 00000006 beebaaa8 00000000 00000000 beebaaa0 beebaaa8 00000005 0000008e
> 5f80: c00d6fe4 c1ce4000 4004e108 00000000 00000000 c1ce5fa8 c00d6e40 c014bc68
> 5fa0: 80000013 ffffffff
> r6:00000001 r5:fefff000 r4:ffffffff
^ permalink raw reply [flat|nested] 7+ messages in thread
* kernel BUG at kernel/posix-cpu-timers.c:1389!
2009-11-02 16:54 ` Russell King - ARM Linux
2009-11-05 17:07 ` E Robertson
@ 2009-11-30 13:21 ` Uwe Kleine-König
1 sibling, 0 replies; 7+ messages in thread
From: Uwe Kleine-König @ 2009-11-30 13:21 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Nov 02, 2009 at 04:54:41PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
> > in arch/arm/mach-at91/at91sam926x_time.c +125
> > .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> >
> > IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
> > booting messages that:
> > "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
> >
> > What does this mean ? what is the difference with former way of managing
> > shared interrupts ?
>
> If the first IRQ action which is run was registered without IRQF_DISABLED
> the entire set will be run without interrupts disabled.
... unless one of the handlers enables irqs, so all bets are off for all
but the first handler.
> > And above all, what is the proper way to set an IRQ on a shared
> > interrupt line ?
>
> The only real solution is to ensure that all requesters use IRQF_DISABLED.
Back to the original problem: can you provide the contents of
/proc/interrupts and the output of dmesg?
I once saw that an oops containing the last time and location when irqs
where enabled and disabled. That would be great here. I don't know
off-hand where to find a patch and it doesn't seem to be supported in
mainline. I will come back on this.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-11-30 13:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-30 16:53 kernel BUG at kernel/posix-cpu-timers.c:1389! E Robertson
2009-10-31 14:32 ` Eric Miao
2009-11-02 16:47 ` Nicolas Ferre
2009-11-02 16:54 ` Russell King - ARM Linux
2009-11-05 17:07 ` E Robertson
2009-11-05 17:29 ` Russell King - ARM Linux
2009-11-30 13:21 ` Uwe Kleine-König
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.