Has anyone else been observing issues with the stack walking code in recent kernels? It's kept me from using lockdep, since when I enable it I get stuff like shown below. Infrequently, I'm able to log in and issue a few commands first.
For some reason the top of the stack in these messes always seems to be the atags pointer. Obviously what's happening is that the stackwalk code goes farther than it should, entering an infinite loop ... which looks to lockdep like a really huge stack, so big that it overflows the internal data tables. - Dave Linux version 2.6.30-rc2-davinci1 (d...@rust) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #111 PREEMPT Fri May 1 12:51:43 PDT 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: DaVinci DM644x EVM Memory policy: ECC disabled, Data cache writeback ... Starting periodic command scheduler: crond. Stopping watchdog keepalive daemon: Starting watchdog daemon: watchdog. Debian GNU/Linux 5.0 dm6446 ttyS0 dm6446 login: BUG: MAX_STACK_TRACE_ENTRIES too low! turning off the locking correctness validator. [<c002f910>] (unwind_backtrace+0x0/0xdc) from [<c005f914>] (save_trace+0x88/0xa4) [<c005f914>] (save_trace+0x88/0xa4) from [<c00607c0>] (mark_lock+0x280/0x3d8) [<c00607c0>] (mark_lock+0x280/0x3d8) from [<c0060980>] (mark_irqflags+0x68/0x170) [<c0060980>] (mark_irqflags+0x68/0x170) from [<c0062f04>] (__lock_acquire+0x4f8/0x6cc) [<c0062f04>] (__lock_acquire+0x4f8/0x6cc) from [<c0063134>] (lock_acquire+0x5c/0x6c) [<c0063134>] (lock_acquire+0x5c/0x6c) from [<c02a7718>] (_spin_lock_irqsave+0x4c/0x60) [<c02a7718>] (_spin_lock_irqsave+0x4c/0x60) from [<c018993c>] (tty_buffer_request_room+0x18/0x80) [<c018993c>] (tty_buffer_request_room+0x18/0x80) from [<c0189a74>] (tty_insert_flip_string_flags+0x24/0x88) [<c0189a74>] (tty_insert_flip_string_flags+0x24/0x88) from [<c019c514>] (receive_chars+0x1f4/0x2bc) [<c019c514>] (receive_chars+0x1f4/0x2bc) from [<c019c614>] (serial8250_handle_port+0x38/0x64) [<c019c614>] (serial8250_handle_port+0x38/0x64) from [<c019c68c>] (serial8250_interrupt+0x4c/0xe4) [<c019c68c>] (serial8250_interrupt+0x4c/0xe4) from [<c006c434>] (handle_IRQ_event+0x64/0x118) [<c006c434>] (handle_IRQ_event+0x64/0x118) from [<c006de30>] (handle_edge_irq+0x128/0x178) [<c006de30>] (handle_edge_irq+0x128/0x178) from [<c002904c>] (_text+0x4c/0x64) [<c002904c>] (_text+0x4c/0x64) from [<c0029970>] (__irq_svc+0x50/0x9c) Exception stack(0xc039bf68 to 0xc039bfb0) bf60: 00000001 00000004 c039bfa0 20000013 c002b280 c039a000 bf80: c03a53d0 00000000 8001e1ac 41069265 8001e178 00000000 c03a53d0 c039bfb0 bfa0: c0060e24 c005de14 20000013 ffffffff [<c0029970>] (__irq_svc+0x50/0x9c) from [<c0060e24>] (trace_hardirqs_on_caller+0x158/0x198) [<c0060e24>] (trace_hardirqs_on_caller+0x158/0x198) from [<c002b280>] (default_idle+0x0/0x5c) [<c002b280>] (default_idle+0x0/0x5c) from [<c0020134>] (__atags_pointer+0x0/0x4) [<c0020134>] (__atags_pointer+0x0/0x4) from [<c0020134>] (__atags_pointer+0x0/0x4) [<c0020134>] (__atags_pointer+0x0/0x4) from [<c0020134>] (__atags_pointer+0x0/0x4) ... loops forever ... _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
