linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Kernel panic in mxs_auart_irq_handle with latest kernel?
@ 2012-10-05 23:58 Subodh Nijsure
  2012-10-08  7:45 ` Uwe Kleine-König
  0 siblings, 1 reply; 5+ messages in thread
From: Subodh Nijsure @ 2012-10-05 23:58 UTC (permalink / raw)
  To: linux-arm-kernel


On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
(I will start bisecting and see if I can find a reason this wknd)

-Subodh

[    9.700000] [00000118] *pgd=00000000
[    9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
[    9.700000] Modules linked in:
[    9.700000] CPU: 0    Not tainted  (3.6.0-11641-gbe4ae13-dirty #1)
[    9.700000] PC is at uart_insert_char+0x38/0x130
[    9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
[    9.700000] pc : [<c025a3e0>]    lr : [<c0261700>]    psr: 40000093
[    9.700000] sp : c0549ea0  ip : 00000000  fp : 00000001
[    9.700000] r10: 00000000  r9 : c057e64e  r8 : 00000020
[    9.700000] r7 : 00000000  r6 : 00080000  r5 : 00000000  r4 : c39566c0
[    9.700000] r3 : 00000020  r2 : 00000000  r1 : 00000000  r0 : 00000000
[    9.700000] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    9.700000] Control: 0005317f  Table: 40004000  DAC: 00000017
[    9.700000] Process swapper (pid: 0, stack limit = 0xc0548270)
[    9.700000] Stack: (0xc0549ea0 to 0xc054a000)
[    9.700000] 9ea0: c0554c00 00200002 00000000 c39566c0 00000000 0052006d 0052006d c0261700
[    9.700000] 9ec0: 00000000 c0548000 c398f980 c0548000 00000000 00000000 000000d3 c057e64e
[    9.700000] 9ee0: c387d700 c0063e74 ffffffff 20000093 00000002 c387d700 c0548000 00000000
[    9.700000] 9f00: c0549f9c 40004000 41069265 40541cd8 00000000 c006403c 427c4747 00000002
[    9.700000] 9f20: c0548000 c0548000 c387d700 c00662dc 000000d3 000000d3 00000000 c00637b0
[    9.700000] 9f40: c0568748 c000ffec f5000000 c0549f68 c0587814 c0008778 c0010144 60000013
[    9.700000] 9f60: ffffffff c000eda0 00000000 0005317f 0005217f 60000013 c0548000 c05875a8
[    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
[    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff 60000093 c0010308 c05500a8 c0587520
[    9.700000] 9fc0: c0543150 c0522700 ffffffff ffffffff c05221d0 00000000 00000000 c0543150
[    9.700000] 9fe0: 00000000 00053175 c055001c c0543120 c05542f4 40008040 00000000 00000000
[    9.700000] [<c025a3e0>] (uart_insert_char+0x38/0x130) from [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0)
[    9.700000] [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0) from [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4)
[    9.700000] [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4) from [<c006403c>] (handle_irq_event+0x54/0x84)
[    9.700000] [<c006403c>] (handle_irq_event+0x54/0x84) from [<c00662dc>] (handle_level_irq+0x98/0x14c)
[    9.700000] [<c00662dc>] (handle_level_irq+0x98/0x14c) from [<c00637b0>] (generic_handle_irq+0x20/0x30)
[    9.700000] [<c00637b0>] (generic_handle_irq+0x20/0x30) from [<c000ffec>] (handle_IRQ+0x30/0x84)
[    9.700000] [<c000ffec>] (handle_IRQ+0x30/0x84) from [<c0008778>] (icoll_handle_irq+0x34/0x48)
[    9.700000] [<c0008778>] (icoll_handle_irq+0x34/0x48) from [<c000eda0>] (__irq_svc+0x40/0x6c)
[    9.700000] Exception stack(0xc0549f68 to 0xc0549fb0)
[    9.700000] 9f60:                   00000000 0005317f 0005217f 60000013 c0548000 c05875a8
[    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
[    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff
[    9.700000] [<c000eda0>] (__irq_svc+0x40/0x6c) from [<c0010144>] (default_idle+0x38/0x40)
[    9.700000] [<c0010144>] (default_idle+0x38/0x40) from [<c0010308>] (cpu_idle+0x9c/0xd4)
[    9.700000] [<c0010308>] (cpu_idle+0x9c/0xd4) from [<c0522700>] (start_kernel+0x264/0x2a4)
[    9.700000] [<c0522700>] (start_kernel+0x264/0x2a4) from [<40008040>] (0x40008040)
[    9.700000] Code: 1a000012 e59d2020 e5cd3006 e5cd2007 (e5973118) 
[    9.700000] ---[ end trace 179ba7640a9ebb7c ]---
[    9.700000] Kernel panic - not syncing: Fatal exception in interrupt

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Kernel panic in mxs_auart_irq_handle with latest kernel?
  2012-10-05 23:58 Kernel panic in mxs_auart_irq_handle with latest kernel? Subodh Nijsure
@ 2012-10-08  7:45 ` Uwe Kleine-König
  2012-10-08  8:07   ` Russell King - ARM Linux
  0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2012-10-08  7:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 05, 2012 at 11:58:26PM +0000, Subodh Nijsure wrote:
> 
> On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
> (I will start bisecting and see if I can find a reason this wknd)
> 
> -Subodh
> 
This dump is not complete, there is at least a line missing that reads

	[   $timestamp] pgd = ....

It's a good habit to always provide the full info.

> [    9.700000] [00000118] *pgd=00000000
> [    9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
> [    9.700000] Modules linked in:
> [    9.700000] CPU: 0    Not tainted  (3.6.0-11641-gbe4ae13-dirty #1)
> [    9.700000] PC is at uart_insert_char+0x38/0x130
> [    9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
> [    9.700000] pc : [<c025a3e0>]    lr : [<c0261700>]    psr: 40000093
> [    9.700000] sp : c0549ea0  ip : 00000000  fp : 00000001
> [    9.700000] r10: 00000000  r9 : c057e64e  r8 : 00000020
> [    9.700000] r7 : 00000000  r6 : 00080000  r5 : 00000000  r4 : c39566c0
> [    9.700000] r3 : 00000020  r2 : 00000000  r1 : 00000000  r0 : 00000000
I don't see what should access the address 0x118 here, can you please
provide the output of

	objdump -d vmlinux | sed -nr '/^[0-9]{8} <uart_insert_char/,/^$/p'

Best regards
Uwe

> [    9.700000] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> [    9.700000] Control: 0005317f  Table: 40004000  DAC: 00000017
> [    9.700000] Process swapper (pid: 0, stack limit = 0xc0548270)
> [    9.700000] Stack: (0xc0549ea0 to 0xc054a000)
> [    9.700000] 9ea0: c0554c00 00200002 00000000 c39566c0 00000000 0052006d 0052006d c0261700
> [    9.700000] 9ec0: 00000000 c0548000 c398f980 c0548000 00000000 00000000 000000d3 c057e64e
> [    9.700000] 9ee0: c387d700 c0063e74 ffffffff 20000093 00000002 c387d700 c0548000 00000000
> [    9.700000] 9f00: c0549f9c 40004000 41069265 40541cd8 00000000 c006403c 427c4747 00000002
> [    9.700000] 9f20: c0548000 c0548000 c387d700 c00662dc 000000d3 000000d3 00000000 c00637b0
> [    9.700000] 9f40: c0568748 c000ffec f5000000 c0549f68 c0587814 c0008778 c0010144 60000013
> [    9.700000] 9f60: ffffffff c000eda0 00000000 0005317f 0005217f 60000013 c0548000 c05875a8
> [    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
> [    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff 60000093 c0010308 c05500a8 c0587520
> [    9.700000] 9fc0: c0543150 c0522700 ffffffff ffffffff c05221d0 00000000 00000000 c0543150
> [    9.700000] 9fe0: 00000000 00053175 c055001c c0543120 c05542f4 40008040 00000000 00000000
> [    9.700000] [<c025a3e0>] (uart_insert_char+0x38/0x130) from [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0)
> [    9.700000] [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0) from [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4)
> [    9.700000] [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4) from [<c006403c>] (handle_irq_event+0x54/0x84)
> [    9.700000] [<c006403c>] (handle_irq_event+0x54/0x84) from [<c00662dc>] (handle_level_irq+0x98/0x14c)
> [    9.700000] [<c00662dc>] (handle_level_irq+0x98/0x14c) from [<c00637b0>] (generic_handle_irq+0x20/0x30)
> [    9.700000] [<c00637b0>] (generic_handle_irq+0x20/0x30) from [<c000ffec>] (handle_IRQ+0x30/0x84)
> [    9.700000] [<c000ffec>] (handle_IRQ+0x30/0x84) from [<c0008778>] (icoll_handle_irq+0x34/0x48)
> [    9.700000] [<c0008778>] (icoll_handle_irq+0x34/0x48) from [<c000eda0>] (__irq_svc+0x40/0x6c)
> [    9.700000] Exception stack(0xc0549f68 to 0xc0549fb0)
> [    9.700000] 9f60:                   00000000 0005317f 0005217f 60000013 c0548000 c05875a8
> [    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
> [    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff
> [    9.700000] [<c000eda0>] (__irq_svc+0x40/0x6c) from [<c0010144>] (default_idle+0x38/0x40)
> [    9.700000] [<c0010144>] (default_idle+0x38/0x40) from [<c0010308>] (cpu_idle+0x9c/0xd4)
> [    9.700000] [<c0010308>] (cpu_idle+0x9c/0xd4) from [<c0522700>] (start_kernel+0x264/0x2a4)
> [    9.700000] [<c0522700>] (start_kernel+0x264/0x2a4) from [<40008040>] (0x40008040)
> [    9.700000] Code: 1a000012 e59d2020 e5cd3006 e5cd2007 (e5973118) 
> [    9.700000] ---[ end trace 179ba7640a9ebb7c ]---
> [    9.700000] Kernel panic - not syncing: Fatal exception in interrupt

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Kernel panic in mxs_auart_irq_handle with latest kernel?
  2012-10-08  7:45 ` Uwe Kleine-König
@ 2012-10-08  8:07   ` Russell King - ARM Linux
  2012-10-08  8:24     ` Uwe Kleine-König
  0 siblings, 1 reply; 5+ messages in thread
From: Russell King - ARM Linux @ 2012-10-08  8:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Oct 08, 2012 at 09:45:47AM +0200, Uwe Kleine-K?nig wrote:
> On Fri, Oct 05, 2012 at 11:58:26PM +0000, Subodh Nijsure wrote:
> > 
> > On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
> > (I will start bisecting and see if I can find a reason this wknd)
> > 
> > -Subodh
> > 
> This dump is not complete, there is at least a line missing that reads
> 
> 	[   $timestamp] pgd = ....
> 
> It's a good habit to always provide the full info.
> 
> > [    9.700000] [00000118] *pgd=00000000

Uwe, yes it is, it is the line above.  It's saying that there is no
pgd entry at address 0x118 (which is correct.)

> > [    9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
> > [    9.700000] Modules linked in:
> > [    9.700000] CPU: 0    Not tainted  (3.6.0-11641-gbe4ae13-dirty #1)
> > [    9.700000] PC is at uart_insert_char+0x38/0x130
> > [    9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
> > [    9.700000] pc : [<c025a3e0>]    lr : [<c0261700>]    psr: 40000093
> > [    9.700000] sp : c0549ea0  ip : 00000000  fp : 00000001
> > [    9.700000] r10: 00000000  r9 : c057e64e  r8 : 00000020
> > [    9.700000] r7 : 00000000  r6 : 00080000  r5 : 00000000  r4 : c39566c0
> > [    9.700000] r3 : 00000020  r2 : 00000000  r1 : 00000000  r0 : 00000000
> I don't see what should access the address 0x118 here, can you please
> provide the output of
> 
> 	objdump -d vmlinux | sed -nr '/^[0-9]{8} <uart_insert_char/,/^$/p'

	objdump -d vmlinux --start-addr=0xc025a3a8 | less

will give you the disassembly starting@uart_insert_char().

The faulting instruction is (which is below in the Code: line of the oops
dump):

	e5973118

It's an "ldr r3, [r7, #280]  ; 0x118" instruction.  r7 is zero, and the
instruction has an pre-indexed offset of 0x118.  _That_ is where 0x118
is coming from.

The full code line is:

  28:   1a000012        bne     0x78
  2c:   e59d2020        ldr     r2, [sp, #32]
  30:   e5cd3006        strb    r3, [sp, #6]
  34:   e5cd2007        strb    r2, [sp, #7]
  38:   e5973118        ldr     r3, [r7, #280]  ; 0x118

I suspect the problem is that the mxs serial driver is calling
uart_insert_char() when the port has been closed by userland, which
means there's no tty associated with it.

> Best regards
> Uwe
> 
> > [    9.700000] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> > [    9.700000] Control: 0005317f  Table: 40004000  DAC: 00000017
> > [    9.700000] Process swapper (pid: 0, stack limit = 0xc0548270)
> > [    9.700000] Stack: (0xc0549ea0 to 0xc054a000)
> > [    9.700000] 9ea0: c0554c00 00200002 00000000 c39566c0 00000000 0052006d 0052006d c0261700
> > [    9.700000] 9ec0: 00000000 c0548000 c398f980 c0548000 00000000 00000000 000000d3 c057e64e
> > [    9.700000] 9ee0: c387d700 c0063e74 ffffffff 20000093 00000002 c387d700 c0548000 00000000
> > [    9.700000] 9f00: c0549f9c 40004000 41069265 40541cd8 00000000 c006403c 427c4747 00000002
> > [    9.700000] 9f20: c0548000 c0548000 c387d700 c00662dc 000000d3 000000d3 00000000 c00637b0
> > [    9.700000] 9f40: c0568748 c000ffec f5000000 c0549f68 c0587814 c0008778 c0010144 60000013
> > [    9.700000] 9f60: ffffffff c000eda0 00000000 0005317f 0005217f 60000013 c0548000 c05875a8
> > [    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
> > [    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff 60000093 c0010308 c05500a8 c0587520
> > [    9.700000] 9fc0: c0543150 c0522700 ffffffff ffffffff c05221d0 00000000 00000000 c0543150
> > [    9.700000] 9fe0: 00000000 00053175 c055001c c0543120 c05542f4 40008040 00000000 00000000
> > [    9.700000] [<c025a3e0>] (uart_insert_char+0x38/0x130) from [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0)
> > [    9.700000] [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0) from [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4)
> > [    9.700000] [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4) from [<c006403c>] (handle_irq_event+0x54/0x84)
> > [    9.700000] [<c006403c>] (handle_irq_event+0x54/0x84) from [<c00662dc>] (handle_level_irq+0x98/0x14c)
> > [    9.700000] [<c00662dc>] (handle_level_irq+0x98/0x14c) from [<c00637b0>] (generic_handle_irq+0x20/0x30)
> > [    9.700000] [<c00637b0>] (generic_handle_irq+0x20/0x30) from [<c000ffec>] (handle_IRQ+0x30/0x84)
> > [    9.700000] [<c000ffec>] (handle_IRQ+0x30/0x84) from [<c0008778>] (icoll_handle_irq+0x34/0x48)
> > [    9.700000] [<c0008778>] (icoll_handle_irq+0x34/0x48) from [<c000eda0>] (__irq_svc+0x40/0x6c)
> > [    9.700000] Exception stack(0xc0549f68 to 0xc0549fb0)
> > [    9.700000] 9f60:                   00000000 0005317f 0005217f 60000013 c0548000 c05875a8
> > [    9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
> > [    9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff
> > [    9.700000] [<c000eda0>] (__irq_svc+0x40/0x6c) from [<c0010144>] (default_idle+0x38/0x40)
> > [    9.700000] [<c0010144>] (default_idle+0x38/0x40) from [<c0010308>] (cpu_idle+0x9c/0xd4)
> > [    9.700000] [<c0010308>] (cpu_idle+0x9c/0xd4) from [<c0522700>] (start_kernel+0x264/0x2a4)
> > [    9.700000] [<c0522700>] (start_kernel+0x264/0x2a4) from [<40008040>] (0x40008040)
> > [    9.700000] Code: 1a000012 e59d2020 e5cd3006 e5cd2007 (e5973118) 
> > [    9.700000] ---[ end trace 179ba7640a9ebb7c ]---
> > [    9.700000] Kernel panic - not syncing: Fatal exception in interrupt
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 
> _______________________________________________
> 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] 5+ messages in thread

* Kernel panic in mxs_auart_irq_handle with latest kernel?
  2012-10-08  8:07   ` Russell King - ARM Linux
@ 2012-10-08  8:24     ` Uwe Kleine-König
  2012-10-08 20:55       ` Subodh Nijsure
  0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2012-10-08  8:24 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Russell,

On Mon, Oct 08, 2012 at 09:07:54AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 08, 2012 at 09:45:47AM +0200, Uwe Kleine-K?nig wrote:
> > On Fri, Oct 05, 2012 at 11:58:26PM +0000, Subodh Nijsure wrote:
> > > 
> > > On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
> > > (I will start bisecting and see if I can find a reason this wknd)
> > > 
> > > -Subodh
> > > 
> > This dump is not complete, there is at least a line missing that reads
> > 
> > 	[   $timestamp] pgd = ....
> > 
> > It's a good habit to always provide the full info.
> > 
> > > [    9.700000] [00000118] *pgd=00000000
> 
> Uwe, yes it is, it is the line above.  It's saying that there is no
> pgd entry at address 0x118 (which is correct.)
I'm not sure I got you right, but show_pte() has:

        printk(KERN_ALERT "pgd = %p\n", mm->pgd);
        pgd = pgd_offset(mm, addr);
        printk(KERN_ALERT "[%08lx] *pgd=%08llx",
                        addr, (long long)pgd_val(*pgd));

So there is indeed missing a line. I don't think it's essential here,
still I think in general it's advisable to let people know not to
shorten the output. Probably even let them post the complete kernel log.
(Isn't there an oops marker, too?)
 
> > > [    9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
> > > [    9.700000] Modules linked in:
> > > [    9.700000] CPU: 0    Not tainted  (3.6.0-11641-gbe4ae13-dirty #1)
> > > [    9.700000] PC is at uart_insert_char+0x38/0x130
> > > [    9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
> > > [    9.700000] pc : [<c025a3e0>]    lr : [<c0261700>]    psr: 40000093
> > > [    9.700000] sp : c0549ea0  ip : 00000000  fp : 00000001
> > > [    9.700000] r10: 00000000  r9 : c057e64e  r8 : 00000020
> > > [    9.700000] r7 : 00000000  r6 : 00080000  r5 : 00000000  r4 : c39566c0
> > > [    9.700000] r3 : 00000020  r2 : 00000000  r1 : 00000000  r0 : 00000000
> > I don't see what should access the address 0x118 here, can you please
> > provide the output of
> > 
> > 	objdump -d vmlinux | sed -nr '/^[0-9]{8} <uart_insert_char/,/^$/p'
> 
> 	objdump -d vmlinux --start-addr=0xc025a3a8 | less
> 
> will give you the disassembly starting at uart_insert_char().
> 
> The faulting instruction is (which is below in the Code: line of the oops
> dump):
Ah, I already knew some time ago that the code is included in the dump,
I just did miss it because there are no address infos included there.

> 
> 	e5973118
> 
> It's an "ldr r3, [r7, #280]  ; 0x118" instruction.  r7 is zero, and the
> instruction has an pre-indexed offset of 0x118.  _That_ is where 0x118
> is coming from.
obviously.

> The full code line is:
> 
>   28:   1a000012        bne     0x78
>   2c:   e59d2020        ldr     r2, [sp, #32]
>   30:   e5cd3006        strb    r3, [sp, #6]
>   34:   e5cd2007        strb    r2, [sp, #7]
>   38:   e5973118        ldr     r3, [r7, #280]  ; 0x118
> 
> I suspect the problem is that the mxs serial driver is calling
> uart_insert_char() when the port has been closed by userland, which
> means there's no tty associated with it.
Thanks for your insights. At least my mail wasn't for nothing because I
learned again something about oopses.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Kernel panic in mxs_auart_irq_handle with latest kernel?
  2012-10-08  8:24     ` Uwe Kleine-König
@ 2012-10-08 20:55       ` Subodh Nijsure
  0 siblings, 0 replies; 5+ messages in thread
From: Subodh Nijsure @ 2012-10-08 20:55 UTC (permalink / raw)
  To: linux-arm-kernel

On 10/08/2012 01:24 AM, Uwe Kleine-K?nig wrote:
> Hello Russell,
>
> On Mon, Oct 08, 2012 at 09:07:54AM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 08, 2012 at 09:45:47AM +0200, Uwe Kleine-K?nig wrote:
>>> On Fri, Oct 05, 2012 at 11:58:26PM +0000, Subodh Nijsure wrote:
>>>> On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
>>>> (I will start bisecting and see if I can find a reason this wknd)
>>>>
>>>> -Subodh
>>>>
>>> This dump is not complete, there is at least a line missing that reads
>>>
>>> 	[   $timestamp] pgd = ....
>>>
>>> It's a good habit to always provide the full info.
>>>
>>>> [    9.700000] [00000118] *pgd=00000000
>> Uwe, yes it is, it is the line above.  It's saying that there is no
>> pgd entry at address 0x118 (which is correct.)
> I'm not sure I got you right, but show_pte() has:
>
>          printk(KERN_ALERT "pgd = %p\n", mm->pgd);
>          pgd = pgd_offset(mm, addr);
>          printk(KERN_ALERT "[%08lx] *pgd=%08llx",
>                          addr, (long long)pgd_val(*pgd));
>
> So there is indeed missing a line. I don't think it's essential here,
> still I think in general it's advisable to let people know not to
> shorten the output. Probably even let them post the complete kernel log.
> (Isn't there an oops marker, too?)
>   
>>>> [    9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
>>>> [    9.700000] Modules linked in:
>>>> [    9.700000] CPU: 0    Not tainted  (3.6.0-11641-gbe4ae13-dirty #1)
>>>> [    9.700000] PC is at uart_insert_char+0x38/0x130
>>>> [    9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
>>>> [    9.700000] pc : [<c025a3e0>]    lr : [<c0261700>]    psr: 40000093
>>>> [    9.700000] sp : c0549ea0  ip : 00000000  fp : 00000001
>>>> [    9.700000] r10: 00000000  r9 : c057e64e  r8 : 00000020
>>>> [    9.700000] r7 : 00000000  r6 : 00080000  r5 : 00000000  r4 : c39566c0
>>>> [    9.700000] r3 : 00000020  r2 : 00000000  r1 : 00000000  r0 : 00000000
>>> I don't see what should access the address 0x118 here, can you please
>>> provide the output of
>>>
>>> 	objdump -d vmlinux | sed -nr '/^[0-9]{8} <uart_insert_char/,/^$/p'
>> 	objdump -d vmlinux --start-addr=0xc025a3a8 | less
>>
>> will give you the disassembly starting at uart_insert_char().
>>
>> The faulting instruction is (which is below in the Code: line of the oops
>> dump):
> Ah, I already knew some time ago that the code is included in the dump,
> I just did miss it because there are no address infos included there.
>
>> 	e5973118
>>
>> It's an "ldr r3, [r7, #280]  ; 0x118" instruction.  r7 is zero, and the
>> instruction has an pre-indexed offset of 0x118.  _That_ is where 0x118
>> is coming from.
> obviously.
>
>> The full code line is:
>>
>>    28:   1a000012        bne     0x78
>>    2c:   e59d2020        ldr     r2, [sp, #32]
>>    30:   e5cd3006        strb    r3, [sp, #6]
>>    34:   e5cd2007        strb    r2, [sp, #7]
>>    38:   e5973118        ldr     r3, [r7, #280]  ; 0x118
>>
>> I suspect the problem is that the mxs serial driver is calling
>> uart_insert_char() when the port has been closed by userland, which
>> means there's no tty associated with it.
> Thanks for your insights. At least my mail wasn't for nothing because I
> learned again something about oopses.
My apologies.  Problem that I came across was caused by some other 
vendor driver for a wireless device that is on this board.
As soon as I disable that driver I don't see this kernel panic.

-Subodh

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-10-08 20:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-05 23:58 Kernel panic in mxs_auart_irq_handle with latest kernel? Subodh Nijsure
2012-10-08  7:45 ` Uwe Kleine-König
2012-10-08  8:07   ` Russell King - ARM Linux
2012-10-08  8:24     ` Uwe Kleine-König
2012-10-08 20:55       ` Subodh Nijsure

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).