ts72xx: rc4 doesn't boot anymore

DISCUSSION Christian Gagneraud 3 participants 4 messages Oct 13, 2009 – Oct 14, 2009

Share & tools

Christian Gagneraud

author

2009-10-13 23:49 UTC #0 lore raw

Hi all,

I really don't understand what's happenning, nothing has changed on my side (same board, same bootloader), rc2 was booting OK, rc3 didn't boot unless I pass on the command line the config for half of my memory (mem=8M at 0x0 mem=8M at 16M mem=8M at 64M mem=8M at 80M). Now with rc4 it's even worth, the kernel complains about bad configuration page, detects 16MB of memory and ignore any mem= command line params (this board has 8 nodes of 8MB each).

Below is the trace of the crash, I've added some debug printk, especially concerning the atags (attached is my hack of arch/arm/kernel/setup.c and another patch i need to get the board booting (I know it's bad))

Unless I'm missing something, the rc2 was booting OK, I'm sure.

Any help greatly appreciate.

Regards,
Chris

<5>Linux version 2.6.32-rc4 (cgagneraud at archeopterix.techworks.local) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #15 Wed Oct 14 00:16:32 IST 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=40007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Technologic Systems TS-72xx SBC
tags:
c0000100: 0x00000080
c0000104: 0x00000200
c0000108: 0x00000400
c000010c: 0x00000000
c0000110: 0x00000000
c0000114: 0x00000000
c0000118: 0x00000000
c000011c: 0x00000000
c0000120: 0x00000000
c0000124: 0x00000000
c0000128: 0x00000000
c000012c: 0x00000000
c0000130: 0x00000000
c0000134: 0x00000000
c0000138: 0x00000000
c000013c: 0x00000000
c0000140: 0x00000000
c0000144: 0x00000000
c0000148: 0x00000000
c000014c: 0x00000000
c0000150: 0x00000000
<4>Warning: bad configuration page, trying to continue
arm_add_memory: start: 0x0, size: 0x1000000 => bank = { start:0x0 size:0x1000000 node:0 }
tags:
c001fc70: 0x00000005
c001fc74: 0x54410001
c001fc78: 0x00000001
c001fc7c: 0x00001000
c001fc80: 0x000000FF
c001fc84: 0x00000004
c001fc88: 0x54410002
c001fc8c: 0x01000000
c001fc90: 0x00000000
c001fc94: 0x00000000
c001fc98: 0x00000000
c001fc9c: 0x00000000
c001fca0: 0x00000000
c001fca4: 0x00000000
c001fca8: 0x00000000
c001fcac: 0x00000000
c001fcb0: 0x00000000
c001fcb4: 0x00000000
c001fcb8: 0x00000000
c001fcbc: 0x00000000
c001fcc0: 0x00000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 4096

<7>  Normal zone: 32 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 4064 pages, LIFO batch:0

Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 <5>Kernel command line: debug
<6>PID hash table entries: 64 (order: -4, 256 bytes)
<6>Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) <6>Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) <6>Memory: 16MB = 16MB total
<5>Memory: 11988KB available (3636K code, 388K data, 104K init, 0K highmem)
<6>Hierarchical RCU implementation.
<6>NR_IRQS:120
<6>VIC @fefb0000: id 0x00041190, vendor 0x41
<6>VIC @fefc0000: id 0x00041190, vendor 0x41
Console: colour dummy device 80x30
<6>console [tty0] enabled
<6>Calibrating delay loop... <1>Unable to handle kernel NULL pointer dereference at virtual address 00000040
<1>pgd = c0004000
<1>[00000040] *pgd=00000000
<0>Internal error: Oops: 5 [#1]
<0>last sysfs file:
<d>Modules linked in:

CPU: 0    Not tainted  (2.6.32-rc4 #15)
PC is at update_wall_time+0xa4/0x960
LR is at do_timer+0x24/0x30
pc : [<c005bc54>]    lr : [<c004baa0>]    psr: a00000d3

sp : c03c3e70 ip : c0407f50 fp : 00000000
r10: 0001d9bc r9 : 41129200 r8 : 00000000
r7 : 3b9aca00 r6 : 00000000 r5 : 3b9aca00 r4 : 00000040
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 4000717f Table: 00004000 DAC: 00000017
<0>Process swapper (pid: 0, stack limit = 0xc03c2270) <0>Stack: (0xc03c3e70 to 0xc03c4000)
<0>3e60: 00000000 33300000
00000000 000200d0
<0>3e80: 00000000 00000000 00000000 00000010 000000d0 00000000 c0c02630 c0c02628
<0>3ea0: 00000000 c0c08000 a0000053 00000000 00000000 00000000 c0c00300 c040bec0
<0>3ec0: 00000000 00000000 00000000 00000000 00000000 c03e6a04 c03c7cd4 c035986c
<0>3ee0: c0359889 ffff8ad1 00000000 fed10fff 00000004 0001d9f0 41129200 0001d9bc
<0>3f00: 00000000 c004baa0 c0407f78 00002665 fed10fff c0026800 c03e600c 00002665
<0>3f20: fed10fff c002cca4 c03c6260 00000000 00000000 c00680e4 c03c9d5c 00000004
<0>3f40: 00000000 c03c8f10 0001d9f0 c0069c7c 00000004 c03d893c 00000000 c002203c
<0>3f60: ffffffff fefb0001 40000000 c0022ae4 00002000 00000000 ffff8ad0 ffff8ad0
<0>3f80: c040b384 c03c59c0 c03c8f10 c03c8f10 0001d9f0 41129200 0001d9bc 00000000
<0>3fa0: 00000000 c03c3fb8 c001c71c c001c738 60000053 ffffffff c040b384 c03e5c40
<0>3fc0: c001fc9c c03c5b58 0001d9f0 41129200 0001d9bc c0008a5c c0008608 00000000
<0>3fe0: 00000000 c001fca0 00000000 40007175 c03e5f50 00008038 00000000 00000000
[<c005bc54>] (update_wall_time+0xa4/0x960) from [<c004baa0>] (do_timer+0x24/0x30)
[<c004baa0>] (do_timer+0x24/0x30) from [<c0026800>] (timer_tick+0xb4/0xfc) [<c0026800>] (timer_tick+0xb4/0xfc) from [<c002cca4>] (ep93xx_timer_interrupt+0x44/0x6c)
[<c002cca4>] (ep93xx_timer_interrupt+0x44/0x6c) from [<c00680e4>] (handle_IRQ_event+0x58/0x128)
[<c00680e4>] (handle_IRQ_event+0x58/0x128) from [<c0069c7c>] (handle_level_irq+0x70/0xfc)
[<c0069c7c>] (handle_level_irq+0x70/0xfc) from [<c002203c>] (asm_do_IRQ+0x3c/0x84)
[<c002203c>] (asm_do_IRQ+0x3c/0x84) from [<c0022ae4>] (__irq_svc+0x24/0xc0)

Exception stack(0xc03c3f70 to 0xc03c3fb8)

3f60: 00002000 00000000 ffff8ad0
ffff8ad0
3f80: c040b384 c03c59c0 c03c8f10 c03c8f10 0001d9f0 41129200 0001d9bc 00000000
3fa0: 00000000 c03c3fb8 c001c71c c001c738 60000053 ffffffff [<c0022ae4>] (__irq_svc+0x24/0xc0) from [<c001c738>] (calibrate_delay+0x58/0x160)
[<c001c738>] (calibrate_delay+0x58/0x160) from [<c0008a5c>] (start_kernel+0x1a8/0x25c)
[<c0008a5c>] (start_kernel+0x1a8/0x25c) from [<00008038>] (0x8038) <0>Code: e8920006 e59d003c e1a05817 e2804040 (e8940018) <4>---[ end trace 1b75b31a2719ed1c ]---
<0>Kernel panic - not syncing: Fatal exception in interrupt

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ts72xx-minimum-fixes-needed-to
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091014/0bc0e85e/attachment-0001.el>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-setup-hack.diff
Type: text/x-patch
Size: 1432 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091014/0bc0e85e/attachment-0001.bin>

Ryan Mallon

2009-10-14 00:02 UTC #1 lore raw

Quoted 10 lines · Christian Gagneraud

Hi all,
I really don't understand what's happenning, nothing has changed on my side (same board, same bootloader), rc2 was booting OK, rc3 didn't boot unless I pass on the command line the config for half of my memory (mem=8M at 0x0 mem=8M at 16M mem=8M at 64M mem=8M at 80M). Now with rc4 it's even worth, the kernel complains about bad configuration page, detects 16MB of memory and ignore any mem= command line params (this board has 8 nodes of 8MB each).

Quoted 9 lines

Below is the trace of the crash, I've added some debug printk, especially concerning the atags (attached is my hack of arch/arm/kernel/setup.c and another patch i need to get the board booting (I know it's bad))
Unless I'm missing something, the rc2 was booting OK, I'm sure.
Any help greatly appreciate.

Can you do a bisect between rc4 and rc2 (or rc3 with the command line arguments you gave) to see if you can track down a specific commit which is breaking your setup.

Thanks,
~Ryan

Signature · 7 lines

Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

H Hartley Sweeten

2009-10-14 00:51 UTC #2 lore raw

In reply to Christian Gagneraud

Quoted 15 lines · Christian Gagneraud

Hi all,
I really don't understand what's happenning, nothing has changed on my side (same board, same bootloader), rc2 was booting OK, rc3 didn't boot unless I pass on the command line the config for half of my memory (mem=8M at 0x0 mem=8M at 16M mem=8M at 64M mem=8M at 80M). Now with rc4 it's even worth, the kernel complains about bad configuration page, detects 16MB of memory and ignore any mem= command line params (this board has 8 nodes of 8MB each).
Below is the trace of the crash, I've added some debug printk, especially concerning the atags (attached is my hack of arch/arm/kernel/setup.c and another patch i need to get the board booting (I know it's bad))

Quoted 6 lines

Unless I'm missing something, the rc2 was booting OK, I'm sure.
Any help greatly appreciate.
Regards,
Chris

If these are actually your ATAGS they don't make a lot of sense.

Quoted 24 lines

<5>Linux version 2.6.32-rc4 (cgagneraud at archeopterix.techworks.local) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #15 Wed Oct 14 00:16:32 IST 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=40007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Technologic Systems TS-72xx SBC
tags:
c0000100: 0x00000080 <- this indicates that the next tag is 0x80 dwords
c0000104: 0x00000200 <- this should be a ATAG_* value but it's not valid
c0000108: 0x00000400 <- this and the next 0x78 dwords should be the data for the tag
c000010c: 0x00000000
c0000110: 0x00000000
c0000114: 0x00000000
c0000118: 0x00000000
c000011c: 0x00000000
c0000120: 0x00000000
c0000124: 0x00000000
c0000128: 0x00000000
c000012c: 0x00000000
c0000130: 0x00000000
c0000134: 0x00000000
c0000138: 0x00000000
c000013c: 0x00000000
c0000140: 0x00000000

Quoted 8 lines

c0000144: 0x00000000
c0000148: 0x00000000
c000014c: 0x00000000
c0000150: 0x00000000
<4>Warning: bad configuration page, trying to continue
arm_add_memory: start: 0x0, size: 0x1000000 => bank = { start:0x0 size:0x1000000 node:0 }
tags:

These tags look ok but they are not at the correct location (.boot_params). They also only indicate that your system has 1 16MB node.

Quoted 13 lines

c001fc70: 0x00000005 <- size = 0x05
c001fc74: 0x54410001 <- tag = ATAG_CORE
c001fc78: 0x00000001 <- flags /* bit 0 = read-only */
c001fc7c: 0x00001000 <- pagesize
c001fc80: 0x000000FF <- rootdev
c001fc84: 0x00000004 <- size = 0x04
c001fc88: 0x54410002 <- tag = ATAG_MEM
c001fc8c: 0x01000000 <- size = 0x01000000 (16MB)
c001fc90: 0x00000000 <- start = 0x00000000
c001fc94: 0x00000000 <- end of the tag list
c001fc98: 0x00000000
c001fc9c: 0x00000000
c001fca0: 0x00000000

Quoted 8 lines

c001fca4: 0x00000000
c001fca8: 0x00000000
c001fcac: 0x00000000
c001fcb0: 0x00000000
c001fcb4: 0x00000000
c001fcb8: 0x00000000
c001fcbc: 0x00000000
c001fcc0: 0x00000000

On my system the tags look like:

c0000100: 0x00000005 <- size = 0x5
c0000104: 0x54410001 <- tag = ATAG_CORE
c0000108: 0x00000000
c000010c: 0x00000000
c0000110: 0x00000000
c0000114: 0x00000004 <- size = 0x4
c0000118: 0x54410002 <- tag = ATAG_MEM
c000011c: 0x02000000 <- size = 0x02000000 (32MB)
c0000120: 0xc0000000 <- start = 0xc0000000
c0000124: 0x00000004 <- size = 0x4
c0000128: 0x54410002 <- tag = ATAG_MEM
c000012c: 0x02000000 <- size = 0x02000000 (32MB)
c0000130: 0xc4000000 <- start = 0xc4000000
c0000134: 0x00000004 <- size = 0x4
c0000138: 0x54420005 <- tag = ATAG_INITRD2
c000013c: 0xc1000000
c0000140: 0x01000000
c0000144: 0x00000011 <- size = 0x11
c0000148: 0x54410009 <- tag = ATAG_CMDLINE
c000014c: 0x746f6f72
c0000150: 0x65642f3d
c0000154: 0x61722f76
c0000158: 0x6f63206d
c000015c: 0x6c6f736e
c0000160: 0x74743d65
c0000164: 0x324d4179
c0000168: 0x64697620
c000016c: 0x653d6f65
c0000170: 0x78333970
c0000174: 0x62662d78
c0000178: 0x3034363a
c000017c: 0x30383478
c0000180: 0x4036312d
c0000184: 0x00003036
c0000188: 0x00000004 <- size = 0x4
c000018c: 0x54410006 <- tag = ATAG_SERIAL
c0000190: 0x27260017
c0000194: 0x49434100
c0000198: 0x00000003 <- size = 0x3
c000019c: 0x54410007 <- tag = ATAG_REVISION
c00001a0: 0x00000001
c00001a4: 0x00000000 <- end of list

Quoted 5 lines

Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 4096
<7>  Normal zone: 32 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 4064 pages, LIFO batch:0

Quoted 7 lines

Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 <5>Kernel command line: debug
<6>PID hash table entries: 64 (order: -4, 256 bytes)
<6>Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) <6>Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) <6>Memory: 16MB = 16MB total
<5>Memory: 11988KB available (3636K code, 388K data, 104K init, 0K

This correctly identifies your memory based on the ATAGS. Something is really screwed up in your system. Can you go back to 2.6.32-rc1 or -rc2 and verify that they boot correctly?

Regards,
Hartley

Christian Gagneraud

author

2009-10-14 19:45 UTC #3 lore raw

In reply to Christian Gagneraud

Quoted 10 lines · Christian Gagneraud

Hi all,
I really don't understand what's happenning, nothing has changed on my side (same board, same bootloader), rc2 was booting OK, rc3 didn't boot unless I pass on the command line the config for half of my memory (mem=8M at 0x0 mem=8M at 16M mem=8M at 64M mem=8M at 80M). Now with rc4 it's even worth, the kernel complains about bad configuration page, detects 16MB of memory and ignore any mem= command line params (this board has 8 nodes of 8MB each).

Quoted 6 lines

Below is the trace of the crash, I've added some debug printk, especially concerning the atags (attached is my hack of arch/arm/kernel/setup.c and another patch i need to get the board booting (I know it's bad))
Unless I'm missing something, the rc2 was booting OK, I'm sure.

I finally manage to find what was the problem, it's all about my .config. I'm using 2 kind of config, a minimal one that just allow me to boot, mount root and do the tests I want to do, and a fat config with lot of stuff.

So it came that when I activate CONFIG_KEXEC even without CONFIG_ATAGS_PROC, my atags are overwritten, if I disable CONFIG_KEXEC, then everything _seems_ to be fine (ATAGS should be OK as I get my RAM correctly detected).

I first started to look at the kexec code hoping to spot the bug! :) But to be honnest, I quickly gave up. What's surprising is that the kexec code is not spread all around the place and that kexec is actually a system call, so there shouldn't be so much code executed at boot time.

Other interesting stuff:
- using my fat config with KEXEC: ATAGS screwed up
- using my fat config without KEXEC: ATAGS OK
- using my minimal config with KEXEC: ATAGS OK
- using my minimal config without KEXEC: ATAGS OK

If some people are interesting in chasing this bug and want other people to run tests, I'm willing to help.

Chris.

Quoted 156 lines

Any help greatly appreciate.
Regards,
Chris
<5>Linux version 2.6.32-rc4 (cgagneraud at archeopterix.techworks.local) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #15 Wed Oct 14 00:16:32 IST 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=40007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Technologic Systems TS-72xx SBC
tags:
c0000100: 0x00000080
c0000104: 0x00000200
c0000108: 0x00000400
c000010c: 0x00000000
c0000110: 0x00000000
c0000114: 0x00000000
c0000118: 0x00000000
c000011c: 0x00000000
c0000120: 0x00000000
c0000124: 0x00000000
c0000128: 0x00000000
c000012c: 0x00000000
c0000130: 0x00000000
c0000134: 0x00000000
c0000138: 0x00000000
c000013c: 0x00000000
c0000140: 0x00000000
c0000144: 0x00000000
c0000148: 0x00000000
c000014c: 0x00000000
c0000150: 0x00000000
<4>Warning: bad configuration page, trying to continue
arm_add_memory: start: 0x0, size: 0x1000000 => bank = { start:0x0 size:0x1000000 node:0 }
tags:
c001fc70: 0x00000005
c001fc74: 0x54410001
c001fc78: 0x00000001
c001fc7c: 0x00001000
c001fc80: 0x000000FF
c001fc84: 0x00000004
c001fc88: 0x54410002
c001fc8c: 0x01000000
c001fc90: 0x00000000
c001fc94: 0x00000000
c001fc98: 0x00000000
c001fc9c: 0x00000000
c001fca0: 0x00000000
c001fca4: 0x00000000
c001fca8: 0x00000000
c001fcac: 0x00000000
c001fcb0: 0x00000000
c001fcb4: 0x00000000
c001fcb8: 0x00000000
c001fcbc: 0x00000000
c001fcc0: 0x00000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 4096
<7>  Normal zone: 32 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 4064 pages, LIFO batch:0
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 <5>Kernel command line: debug
<6>PID hash table entries: 64 (order: -4, 256 bytes)
<6>Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) <6>Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) <6>Memory: 16MB = 16MB total
<5>Memory: 11988KB available (3636K code, 388K data, 104K init, 0K highmem) <6>Hierarchical RCU implementation.
<6>NR_IRQS:120
<6>VIC @fefb0000: id 0x00041190, vendor 0x41
<6>VIC @fefc0000: id 0x00041190, vendor 0x41
Console: colour dummy device 80x30
<6>console [tty0] enabled
<6>Calibrating delay loop... <1>Unable to handle kernel NULL pointer dereference at virtual address 00000040
<1>pgd = c0004000
<1>[00000040] *pgd=00000000
<0>Internal error: Oops: 5 [#1]
<0>last sysfs file:
<d>Modules linked in:
CPU: 0    Not tainted  (2.6.32-rc4 #15)
PC is at update_wall_time+0xa4/0x960
LR is at do_timer+0x24/0x30
pc : [<c005bc54>]    lr : [<c004baa0>]    psr: a00000d3
sp : c03c3e70 ip : c0407f50 fp : 00000000
r10: 0001d9bc r9 : 41129200 r8 : 00000000
r7 : 3b9aca00 r6 : 00000000 r5 : 3b9aca00 r4 : 00000040
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 4000717f Table: 00004000 DAC: 00000017
<0>Process swapper (pid: 0, stack limit = 0xc03c2270)
<0>Stack: (0xc03c3e70 to 0xc03c4000)
<0>3e60: 00000000 33300000 00000000
000200d0
<0>3e80: 00000000 00000000 00000000 00000010 000000d0 00000000 c0c02630 c0c02628
<0>3ea0: 00000000 c0c08000 a0000053 00000000 00000000 00000000 c0c00300 c040bec0
<0>3ec0: 00000000 00000000 00000000 00000000 00000000 c03e6a04 c03c7cd4 c035986c
<0>3ee0: c0359889 ffff8ad1 00000000 fed10fff 00000004 0001d9f0 41129200 0001d9bc
<0>3f00: 00000000 c004baa0 c0407f78 00002665 fed10fff c0026800 c03e600c 00002665
<0>3f20: fed10fff c002cca4 c03c6260 00000000 00000000 c00680e4 c03c9d5c 00000004
<0>3f40: 00000000 c03c8f10 0001d9f0 c0069c7c 00000004 c03d893c 00000000 c002203c
<0>3f60: ffffffff fefb0001 40000000 c0022ae4 00002000 00000000 ffff8ad0 ffff8ad0
<0>3f80: c040b384 c03c59c0 c03c8f10 c03c8f10 0001d9f0 41129200 0001d9bc 00000000
<0>3fa0: 00000000 c03c3fb8 c001c71c c001c738 60000053 ffffffff c040b384 c03e5c40
<0>3fc0: c001fc9c c03c5b58 0001d9f0 41129200 0001d9bc c0008a5c c0008608 00000000
<0>3fe0: 00000000 c001fca0 00000000 40007175 c03e5f50 00008038 00000000 00000000
[<c005bc54>] (update_wall_time+0xa4/0x960) from [<c004baa0>] (do_timer+0x24/0x30)
[<c004baa0>] (do_timer+0x24/0x30) from [<c0026800>] (timer_tick+0xb4/0xfc) [<c0026800>] (timer_tick+0xb4/0xfc) from [<c002cca4>] (ep93xx_timer_interrupt+0x44/0x6c)
[<c002cca4>] (ep93xx_timer_interrupt+0x44/0x6c) from [<c00680e4>] (handle_IRQ_event+0x58/0x128)
[<c00680e4>] (handle_IRQ_event+0x58/0x128) from [<c0069c7c>] (handle_level_irq+0x70/0xfc)
[<c0069c7c>] (handle_level_irq+0x70/0xfc) from [<c002203c>] (asm_do_IRQ+0x3c/0x84)
[<c002203c>] (asm_do_IRQ+0x3c/0x84) from [<c0022ae4>] (__irq_svc+0x24/0xc0)
Exception stack(0xc03c3f70 to 0xc03c3fb8)
3f60: 00002000 00000000 ffff8ad0
ffff8ad0
3f80: c040b384 c03c59c0 c03c8f10 c03c8f10 0001d9f0 41129200 0001d9bc 00000000
3fa0: 00000000 c03c3fb8 c001c71c c001c738 60000053 ffffffff [<c0022ae4>] (__irq_svc+0x24/0xc0) from [<c001c738>] (calibrate_delay+0x58/0x160)
[<c001c738>] (calibrate_delay+0x58/0x160) from [<c0008a5c>] (start_kernel+0x1a8/0x25c)
[<c0008a5c>] (start_kernel+0x1a8/0x25c) from [<00008038>] (0x8038) <0>Code: e8920006 e59d003c e1a05817 e2804040 (e8940018) <4>---[ end trace 1b75b31a2719ed1c ]---
<0>Kernel panic - not syncing: Fatal exception in interrupt
------------------------------------------------------------------------
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel