[#4888] fdpic traps test case 18 would make kernel panic on bf533-stamp
Submitted By: Mingquan Pan
Open Date
2009-02-11 02:59:49 Close Date
2009-05-11 16:11:51
Priority:
Medium High Assignee:
Graf Yang
Robin Getz
Status:
Closed Fixed In Release:
N/A
Found In Release:
N/A Release:
Category:
N/A Board:
Processor:
BF533 Silicon Revision:
0.3
Is this bug repeatable?:
Yes Resolution:
Duplicate
Uboot version or rev.:
Toolchain version or rev.:
4.1 of Jan 16
App binary format:
Summary: fdpic traps test case 18 would make kernel panic on bf533-stamp
Details:
traps test built into fdpic format, the 18th case would make kernel panic on bf533-stamp. It is ok on bf537 stamp board.
Running test 18 for exception 0x2c: Instruction fetch CPLB miss
... External Memory Addressing Error
HW Error context
CURRENT PROCESS:
COMM=traps_test PID=168
CPU = 0
TEXT = 0x0056c000-0x0056d844 DATA = 0x037ba844-0x037bb248
BSS = 0x037bb248-0x005a0000 USER-STACK = 0x005bfea0
return address: [0x0056d014]; contents of:
0x0056cff0: b9ea 9151 ac53 0061 e801 0000 0010 0000
0x0056d000: e800 0005 e140 8765 e100 4320 bbf0 b9f0
0x0056d010: bbe0 b9ea [9151] ac53 0061 e801 0000 0010
0x0056d020: e800 0005 6000 bbf0 b9f0 bbe0 b9ea 9151
SEQUENCER STATUS: Not tainted
SEQSTAT: 0000e03f IPEND: 0030 SYSCFG: 0006
HWERRCAUSE: 0x3
EXCAUSE : 0x3f
interrupts disabled
physical IVG5 asserted : <0xffa00bac> { _evt_ivhw + 0x0 }
RETE: <0x00000000> { _do_one_initcall + 0xfffff000 }
RETN: <0x00520000> [ klogd + 0x0 ]
RETX: <0x0018d468> { _start_cpu_timer + 0x20 }
RETS: <0x0056d278> [ /bin/traps_test + 0x1278 ]
PC : <0x0056d014> [ /bin/traps_test + 0x1014 ]
PROCESSOR STATE:
R0 : 87654320 R1 : 00000012 R2 : 037ba928 R3 : 00000002
R4 : 005bfea4 R5 : 005d9be0 R6 : 005bff50 R7 : 005bff9c
P0 : 000000a2 P1 : 0056d000 P2 : 87654320 P3 : 037bb198
P4 : 005dbdc4 P5 : 005bff3c FP : 005bfd64 SP : 0051ff24
LB0: 00656421 LT0: 00656414 LC0: 00000000
LB1: 001b2b0f LT1: 001b2b08 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 005bfb0c
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 001b6928
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 005bfd50 ASTAT: 02002020
Hardware Trace:
0 Target : <0x00004a44> { _trap_c + 0x0 }
Source : <0xffa00c38> { _evt_ivhw + 0x8c } CALL pcrel
1 Target : <0xffa00c1a> { _evt_ivhw + 0x6e }
Source : <0xffa00c16> { _evt_ivhw + 0x6a } IF !CC JUMP
2 Target : <0xffa00bac> { _evt_ivhw + 0x0 }
Source : <0x0056d012> [ /bin/traps_test + 0x1012 ] 0xb9ea
3 Target : <0x0056d000> [ /bin/traps_test + 0x1000 ]
Source : <0x0056d276> [ /bin/traps_test + 0x1276 ] CALL (P1)
4 Target : <0x0056d254> [ /bin/traps_test + 0x1254 ]
Source : <0x001b2af0> [ /lib/libc.so.0 + 0x32af0 ] RTS
5 Target : <0x001b2aea> [ /lib/libc.so.0 + 0x32aea ]
Source : <0x001b2ba8> [ /lib/libc.so.0 + 0x32ba8 ] JUMP.S
6 Target : <0x001b2ba6> [ /lib/libc.so.0 + 0x32ba6 ]
Source : <0x001b2b8c> [ /lib/libc.so.0 + 0x32b8c ] IF !CC JUMP
7 Target : <0x001b2b88> [ /lib/libc.so.0 + 0x32b88 ]
Source : <0x0018d47c> { _start_cpu_timer + 0x34 } RTS
8 Target : <0x0018d468> { _start_cpu_timer + 0x20 }
Source : <0xffa00ba8> { __common_int_entry + 0xd8 } RTI
9 Target : <0xffa00b46> { __common_int_entry + 0x76 }
Source : <0xffa00d6c> { _evt_system_call + 0x64 } JUMP.S
10 Target : <0xffa00d6c> { _evt_system_call + 0x64 }
Source : <0xffa00854> { _system_call + 0xb8 } RTS
11 Target : <0xffa00850> { _system_call + 0xb4 }
Source : <0xffa00840> { _system_call + 0xa4 } IF !CC JUMP
12 Target : <0xffa0083a> { _system_call + 0x9e }
Source : <0xffa0082a> { _system_call + 0x8e } IF !CC JUMP
13 Target : <0xffa00804> { _system_call + 0x68 }
Source : <0x000224e8> { _sys_nanosleep + 0x1c } RTS
14 Target : <0x000224e2> { _sys_nanosleep + 0x16 }
Source : <0x00022524> { _sys_nanosleep + 0x58 } JUMP.S
15 Target : <0x00022524> { _sys_nanosleep + 0x58 }
Source : <0x0002247c> { _hrtimer_nanosleep + 0x80 } RTS
Userspace Stack
Stack info:
SP: [0x005bfd50] <0x005bfd50> [ traps_test + 0x1fd50 ]
FP: (0x005bfd54)
Memory from 0x005bfd50 to 005c0000
005bfd50:[00000000](005bfdd0)<0056d254> 87654320 87654320 005bfdd0 <0056d278> 005d0294
005bfd70: 00000012 0000002c 037bafac <001898d2> 037bb198 005d04b8 00000000 00000000
005bfd90: 005bfd9c 005bff50 00000000 005d03b4 005bfe64 <006563ec> 005bff3c 005bffab
005bfdb0: 00000012 005bff3c 005dbdc4 005bff9c 005bff50 005d9be0 <00653ee8> 00000000
005bfdd0:(005bfe64)<001b3936> 005bff9c 005bff50 00000002 005bfea4 005d1214 00000000
005bfdf0: 00000000 00000000 00000000 00000000 00000000 00000003 0056c034 00000004
005bfe10: 00000020 00000005 00000006 00000006 00001000 00000007 00650000 00000008
005bfe30: 00000000 00000009 0056cbf8 00000000 00000000 0000000b 00000000 0000000c
005bfe50: 00000000 0000000d 00000000 0000000e 00000000 (00000000)<0056cc26> 005d1248
005bfe70: 0056cbf8 005d1240 005bff50 005bff70 <0056cbfc> 005d072c 00000002 005d1240
005bfe90: 005d0830 005d0734 005d1240 005bff7c 00000002 005bff9c 005bffa9 00000000
005bfeb0: 005bffac 005bffb3 005bffc1 005bffe4 00000000 00000010 00000000 00000006
005bfed0: 00001000 00000011 00000064 00000003 0056c034 00000004 00000020 00000005
005bfef0: 00000006 00000007 00650000 00000008 00000000 00000009 0056cbf8 0000000b
005bff10: 00000000 0000000c 00000000 0000000d 00000000 0000000e 00000000 00000017
005bff30: 00000000 0000001f 0001ffef 00000000 00000000 00000000 00000000 00000000
005bff50: 00020000 00650000 00000000 000070ec 005d10ec 0000b0ec 00000450 00000000
005bff70: 00020000 0056c000 00000000 00001844 037ba844 00005844 00000a04 00000000
005bff90: 00000000 00000000 00000000 72742f2e 5f737061 74736574 00383100 454d4f48
005bffb0: 53002f3d 4c4c4548 69622f3d 68732f6e 54415000 622f3d48 2f3a6e69 2f727375
005bffd0: 3a6e6962 6962732f 752f3a6e 732f7273 006e6962 4d524554 6e696c3d 2e007875
005bfff0: 6172742f 745f7370 00747365 00000000 34343831
Return addresses in stack:
frame 1 : <0x0056d254> [ /bin/traps_test + 0x1254 ]
address : <0x0056d278> [ /bin/traps_test + 0x1278 ]
address : <0x001898d2> { _spi_register_board_info + 0x16 }
address : <0x006563ec> [ /lib/ld-uClibc.so.0 + 0x63ec ]
address : <0x00653ee8> [ /lib/ld-uClibc.so.0 + 0x3ee8 ]
frame 2 : <0x001b3936> [ /lib/libc.so.0 + 0x33936 ]
frame 3 : <0x0056cc26> [ /bin/traps_test + 0xc26 ]
address : <0x0056cbfc> [ /bin/traps_test + 0xbfc ]
External Memory Addressing Error
Kernel OOPS in progress
return address: [0x00013c1c]; contents of:
0x00013bf0: 0005 e122 0100 e14b 0016 a111 e10b 08dc
0x00013c00: 5051 911f b111 6054 3220 680f 6000 e14a
0x00013c10: 0016 9318 e10a 93b0 9110 0040 [e14d] 0016
0x00013c20: e10d 0944 6006 2006 4e0f 0c07 6426 1814
Looks like this was a deferred error - sorry
The remaining message may be meaningless
You should enable CONFIG_DEBUG_HWERR to get a better idea where it came from
SEQSTAT: 0000e03f IPEND: 4030 SYSCFG: 0006
physical IVG14 asserted : <0xffa009a8> { _evt14_softirq + 0x0 }
logical irq 6 mapped : <0xffa00384> { _timer_interrupt + 0x0 }
logical irq 14 mapped : <0x000b0604> { _bfin_rtc_interrupt + 0x0 }
logical irq 21 mapped : <0x0009e424> { _bfin_serial_dma_rx_int + 0x0 }
logical irq 22 mapped : <0x0009e740> { _bfin_serial_dma_tx_int + 0x0 }
logical irq 40 mapped : <0x000a65e0> { _smc_interrupt + 0x0 }
RETS: <0xffa00330> { _asm_do_IRQ + 0x64 }
PC : <0x00013c1c> { ___do_softirq + 0x38 }
R0 : 0000ffff R1 : 00000100 R2 : 00000100 R3 : 007a1200
R4 : 0000000a R5 : 005d9be0 R6 : 00000000 R7 : 00000002
P0 : 0051fe60 P1 : 00000094 P2 : 001693b0 P3 : 001608dc
P4 : 0051e000 P5 : 00165008 FP : 00000001 SP : 0051fde8
LB0: ffa01939 LT0: ffa01918 LC0: 00000000
LB1: 0000dcf7 LT1: 0000dce0 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 0015bbe4
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00000000
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : ffffffff
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : ffffffff
A0.w: 00000098 A0.x: 00000000 A1.w: 0000001c A1.x: 00000000
USP : 005bfd50 ASTAT: 02002000
Source : <0x00013c1a> { ___do_softirq + 0x36 } STI R0
3 Target : <0x00013be4> { ___do_softirq + 0x0 }
Source : <0x00013f24> { _irq_exit + 0x30 } JUMP.L
4 Target : <0x00013f24> { _irq_exit + 0x30 }
Source : <0x00013f20> { _irq_exit + 0x2c } IF !CC JUMP
5 Target : <0x00013ef4> { _irq_exit + 0x0 }
Source : <0xffa0032c> { _asm_do_IRQ + 0x60 } CALL pcrel
6 Target : <0xffa0032c> { _asm_do_IRQ + 0x60 }
Source : <0xffa009ae> { _evt14_softirq + 0x6 } RTS
7 Target : <0xffa009a8> { _evt14_softirq + 0x0 }
Source : <0xffa009a6> { _lower_to_irq14 + 0x12 } RTI
8 Target : <0xffa00994> { _lower_to_irq14 + 0x0 }
Source : <0xffa00328> { _asm_do_IRQ + 0x5c } CALL pcrel
9 Target : <0xffa00300> { _asm_do_IRQ + 0x34 }
Source : <0x0002f0ba> { _handle_simple_irq + 0x6a } RTS
10 Target : <0x0002f0ae> { _handle_simple_irq + 0x5e }
Source : <0x0002f0c4> { _handle_simple_irq + 0x74 } JUMP.S
11 Target : <0x0002f0c4> { _handle_simple_irq + 0x74 }
Source : <0x0002e844> { _note_interrupt + 0x80 } RTS
12 Target : <0x0002e82e> { _note_interrupt + 0x6a }
Source : <0x0002e7e0> { _note_interrupt + 0x1c } IF CC JUMP
13 Target : <0x0002e7c4> { _note_interrupt + 0x0 }
Source : <0x0002f0c0> { _handle_simple_irq + 0x70 } CALL pcrel
14 Target : <0x0002f0bc> { _handle_simple_irq + 0x6c }
Source : <0x0002f0a6> { _handle_simple_irq + 0x56 } IF !CC JUMP
15 Target : <0x0002f098> { _handle_simple_irq + 0x48 }
Source : <0x0002db14> { _handle_IRQ_event + 0x5c } RTS
Kernel Stack
SP: [0x0051fde4] <0x0051fde4> /* kernel dynamic memory */
Memory from 0x0051fde0 to 00520000
0051fde0:<0001fade>[004dfed4] 0018d468 00004030 0000e03f 00000000 00520000 0018d468
0051fe00: 00013c1c <ffa00330> 0000ffff 02002000 0000dcf7 ffa01939 0000dce0 ffa01918
0051fe20: 00000000 00000000 0000001c 00000000 00000098 00000000 00000000 00000000
0051fe40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0051fe60: 00000000 00000000 ffffffff ffffffff 00000000 0015bbe4 005bfd50 00000001
0051fe80: 00165008 0051e000 001608dc 001693b0 00000094 0051fe60 00000002 00000000
0051fea0: 005d9be0 0000000a 007a1200 00000100 00000100 0000ffff 0000ffff 0051fe60
0051fec0: 00000006 <0002f0c4> 0016be5c 00000006 037bb198 00000006 005bfd64 <ffa00330>
0051fee0: 00165008 005dbdc4 037bb198 00000006 00000000 005d9be0 005bfea4 <ffa00804>
0051ff00:<ffa00c3c> ffc00014 <ffa00b40> ffc00014 005bff9c 005bff50 00000002 005bfea4
0051ff20: ffa00274 0056d014 00000050 0000e000 00000000 00520000 0018d468 0056d014
0051ff40:<0056d278> 00000006 02002020 001b2b0f 00656421 001b2b08 00656414 00000000
0051ff60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0051ff80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0051ffa0: 00000000 00000000 00000000 001b6928 005bfb0c 005bfd50 005bfd64 005bff3c
0051ffc0: 005dbdc4 037bb198 87654320 0056d000 000000a2 005bff9c 005bff50 005d9be0
0051ffe0: 005bfea4 00000002 037ba928 00000012 87654320 87654320 000000a2 00000006
00520000: 00000000
address : <0x0001fade> { _autoremove_wake_function + 0x12 }
address : <0xffa00330> { _asm_do_IRQ + 0x64 }
address : <0x0002f0c4> { _handle_simple_irq + 0x74 }
address : <0xffa00804> { _system_call + 0x68 }
address : <0xffa00c3c> { _evt_ivhw + 0x90 }
address : <0xffa00b40> { __common_int_entry + 0x70 }
Modules linked in:
Kernel panic - not syncing: Kernel exception
Follow-ups
--- Robin Getz 2009-03-20 11:52:22
The first dump of the error message looks normal.
The 2nd -
The "STI R0" instruction right before the jump to _evt_ivhw, means
that you need to turn on "CONFIG_DEBUG_HWERR" to understand where the
problem is coming from.
Can you turn that on, and recreate?
Thanks
-Robin
--- Graf Yang 2009-04-16 05:13:12
I use trunk and 2009R1-rc5 toolchain, I can't reproduce it.
I need your kernel .config file to retry.
--- Graf Yang 2009-04-20 06:34:20
After tried 3 times, the kernel panic.
--- Graf Yang 2009-04-22 22:19:58
traps_test 18 should cause exception 0x2c icplb_miss, but it caused 0x3f
(hardware error), and the seqstat contains 0xc000(External Memory Addressing
Error). This is because the test app have the code,
P1 = [P2]; /* p2==0x87654320 */
The same code caused 0x26 (dcplb_miss) on BF537.
Who knows why they have this difference?
0x3f error will cause kernel panic after tried several times. So this is indeed
the bug.
--- Graf Yang 2009-04-22 22:51:29
Hi, Robin,
It failed at the 5th time running traps_test 18, would the followed information
be helpful?
The 4th, successful,
root:/> traps_test 18
RExning test ternal Memory Addressing Error
COMM=traps_test1 PID=127
TEXT = 0x03bd4000-0x03bd57ec DATA = 0x03bd67ec-0x03bd71e8
BSS = 0x03bd71e8-0x004c0000 USER-STACK = 0x004dfea0
return address: [0x03bd4fdc]; contents of:
0x03bd4fb0: bbf0 b9f0 6408 bbe0 b9ea 9151 ac53 0061
0x03bd4fc0: e801 0000 0010 0000 e800 0005 e140 8765
0x03bd4fd0: e100 4320 bbf0 b9f0 bbe0 b9ea [9151] ac53
0x03bd4fe0: 0061 e801 0000 0010 e800 0005 6000 bbf0
SEQSTAT: 0000c03f IPEND: 0030 SYSCFG: 0006
physical IVG5 asserted : <0x000099e8> { _evt_ivhw + 0x0 }
RETE: <0x00000000> { _check_bugs + 0xfffff000 }
RETN: <0x00638000> [ klogd + 0x0 ]
RETX: <0x031cec3a> [ /lib/libc.so.0 + 0xec3a ]
RETS: <0x03bd5238> [ /bin/traps_test1 + 0x1238 ]
PC : <0x03bd4fdc> [ /bin/traps_test1 + 0xfdc ]
R0 : 87654320 R1 : 00000012 R2 : 03bd68d0 R3 : 00000002
R4 : 004dfea4 R5 : 004ab99c R6 : 004dff50 R7 : 004dff99
P0 : 00000004 P1 : 03bd4fc8 P2 : 87654320 P3 : 03bd7138
P4 : 004a97b8 P5 : 004dff3c FP : 004dfd68 SP : 00637f24
LB0: 031a6351 LT0: 031a6344 LC0: 00000000
LB1: 031df9dd LT1: 031df996 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 03bd6f54
USP : 004dfd54 ASTAT: 02002000
0 Target : <0x00005048> { _trap_c + 0x0 }
Source : <0x00009a76> { _evt_ivhw + 0x8e } CALL pcrel
1 Target : <0x00009a58> { _evt_ivhw + 0x70 }
Source : <0x00009a54> { _evt_ivhw + 0x6c } IF !CC JUMP
2 Target : <0x000099e8> { _evt_ivhw + 0x0 }
Source : <0x03bd4fda> [ /bin/traps_test1 + 0xfda ] 0xb9ea
3 Target : <0x03bd4fc8> [ /bin/traps_test1 + 0xfc8 ]
Source : <0x03bd5236> [ /bin/traps_test1 + 0x1236 ] CALL (P1)
4 Target : <0x03bd5214> [ /bin/traps_test1 + 0x1214 ]
Source : <0x031dea8c> [ /lib/libc.so.0 + 0x1ea8c ] RTS
5 Target : <0x031dea7e> [ /lib/libc.so.0 + 0x1ea7e ]
Source : <0x031df1e4> [ /lib/libc.so.0 + 0x1f1e4 ] RTS
6 Target : <0x031df1dc> [ /lib/libc.so.0 + 0x1f1dc ]
Source : <0x031df22e> [ /lib/libc.so.0 + 0x1f22e ] JUMP.S
7 Target : <0x031df218> [ /lib/libc.so.0 + 0x1f218 ]
Source : <0x031dc65a> [ /lib/libc.so.0 + 0x1c65a ] RTS
8 Target : <0x031dc652> [ /lib/libc.so.0 + 0x1c652 ]
Source : <0x031dc644> [ /lib/libc.so.0 + 0x1c644 ] IF CC JUMP
9 Target : <0x031dc634> [ /lib/libc.so.0 + 0x1c634 ]
Source : <0x031df214> [ /lib/libc.so.0 + 0x1f214 ] CALL pcrel
10 Target : <0x031df212> [ /lib/libc.so.0 + 0x1f212 ]
Source : <0x031df20a> [ /lib/libc.so.0 + 0x1f20a ] IF !CC JUMP
11 Target : <0x031df1f4> [ /lib/libc.so.0 + 0x1f1f4 ]
Source : <0x031df0be> [ /lib/libc.so.0 + 0x1f0be ] IF !CC JUMP
12 Target : <0x031df0ac> [ /lib/libc.so.0 + 0x1f0ac ]
Source : <0x031dea7a> [ /lib/libc.so.0 + 0x1ea7a ] CALL pcrel
13 Target : <0x031dea54> [ /lib/libc.so.0 + 0x1ea54 ]
Source : <0x031a632e> [ /lib/ld-uClibc.so.0 + 0x632e ] JUMP (P1)
14 Target : <0x031a631c> [ /lib/ld-uClibc.so.0 + 0x631c ]
Source : <0x031a4978> [ /lib/ld-uClibc.so.0 + 0x4978 ] RTS
15 Target : <0x031a496c> [ /lib/ld-uClibc.so.0 + 0x496c ]
Source : <0x031a4930> [ /lib/ld-uClibc.so.0 + 0x4930 ] IF !CC JUMP
User Stack fp 004dfd68
SP: [0x004dfd68] <0x004dfd68> [ traps_test1 + 0x1fd68 ]
FP: (0x004dfd68)
Memory from 0x004dfd60 to 004e0000
004dfd60: 87654320 87654320 [004dfdd0]<03bd5238> 004dfd9c 00000012
0000002c 03bd6f54
004dfd80: 03bd14b4 03bd7138 00000000 004dfd9c 004a97b8 004dff99 00000000
03bd13b0
004dfda0: 004dfe64 <031a631c> 004dff3c 004dffa7 00000012 004dff3c
004a97b8 004dff99
004dfdc0: 004dff50 004ab99c 00000000 00000000 004dfe64 <031f35a8>
004dff99 004dff50
004dfde0: 00000002 004dfea4 0dfd935e 00000000 00000000 00000000 00000000
00000000
004dfe00: 00000000 00000003 03bd4034 00000004 00000020 00000005 00000006
00000006
004dfe20: 00001000 00000007 031a0000 00000008 00000000 00000009 03bd4bc0
004dfe40: 00000000 0000000b 00000000 0000000c 00000000 0000000d 00000000
0000000e
004dfe60: 00000000 00000000 <03bd4bee> 03bd2178 03bd4bc0 03bd2160
004dff50 004dff70
004dfe80:<03bd4bc4> 03bd1728 00000002 004dff70 03bd182c 03bd1730
03bd2160 004dff7c
004dfea0: 00000002 004dff99 004dffa5 00000000 004dffa8 004dffaf 004dffbd
004dffe0
004dfec0: 00000000 00000010 00000000 00000006 00001000 00000011 00000064
00000003
004dfee0: 03bd4034 00000004 00000020 00000005 00000006 00000007 031a0000
00000008
004dff00: 00000000 00000009 03bd4bc0 0000000b 00000000 0000000c 00000000
0000000d
004dff20: 00000000 0000000e 00000000 00000017 00000000 0000001f 0001ffeb
004dff40: 00000000 00000000 00000000 00000000 00020000 031a0000 00000000
0000701c
004dff60: 03bd201c 0000b01c 00000450 00000000 00020000 03bd4000 00000000
000017ec
004dff80: 03bd67ec 000057ec 000009fc 00000000 00000000 00000000 61727400
745f7370
004dffa0: 31747365 00383100 454d4f48 53002f3d 4c4c4548 69622f3d 68732f6e
54415000
004dffc0: 622f3d48 2f3a6e69 2f727375 3a6e6962 6962732f 752f3a6e 732f7273
006e6962
004dffe0: 4d524554 6e696c3d 2f007875 2f6e6962 70617274 65745f73 00317473
004e0000: 0000a2b8
frame 1 : <0x03bd5238> [ /bin/traps_test1 + 0x1238 ]
address : <0x031a631c> [ /lib/ld-uClibc.so.0 + 0x631c ]
frame 2 : <0x031f35a8> [ /lib/libc.so.0 + 0x335a8 ]
frame 3 : <0x03bd4bee> [ /bin/traps_test1 + 0xbee ]
address : <0x03bd4bc4> [ /bin/traps_test1 + 0xbc4 ]
18 for exception 0x2c: Instruction fetch CPLB miss
... Bus error
The 5th, failed,
root:/> traps_test1 18
RunExng test ternal Memory Addressing Error
COMM=traps_test1 PID=128
TEXT = 0x00726000-0x007277ec DATA = 0x03bd47ec-0x03bd51e8
BSS = 0x03bd51e8-0x004c0000 USER-STACK = 0x004dfea0
return address: [0x00726fdc]; contents of:
0x00726fb0: bbf0 b9f0 6408 bbe0 b9ea 9151 ac53 0061
0x00726fc0: e801 0000 0010 0000 e800 0005 e140 8765
0x00726fd0: e100 4320 bbf0 b9f0 bbe0 b9ea [9151] ac53
0x00726fe0: 0061 e801 0000 0010 e800 0005 6000 bbf0
RETS: <0x00727238> [ /bin/traps_test1 + 0x1238 ]
PC : <0x00726fdc> [ /bin/traps_test1 + 0xfdc ]
R0 : 87654320 R1 : 00000012 R2 : 03bd48d0 R3 : 00000002
R4 : 004dfea4 R5 : 004e399c R6 : 004dff50 R7 : 004dff99
P0 : 00000004 P1 : 00726fc8 P2 : 87654320 P3 : 03bd5138
P4 : 004e17b8 P5 : 004dff3c FP : 004dfd68 SP : 00637f24
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 03bd4f54
Source : <0x00726fda> [ /bin/traps_test1 + 0xfda ] 0xb9ea
3 Target : <0x00726fc8> [ /bin/traps_test1 + 0xfc8 ]
Source : <0x00727236> [ /bin/traps_test1 + 0x1236 ] CALL (P1)
4 Target : <0x00727214> [ /bin/traps_test1 + 0x1214 ]
004dfd60: 87654320 87654320 [004dfdd0]<00727238> 004dfd9c 00000012
0000002c 03bd4f54
004dfd80: 03bd34b4 03bd5138 00000000 004dfd9c 004e17b8 004dff99 00000000
03bd33b0
004e17b8 004dff99
004dfdc0: 004dff50 004e399c 00000000 00000000 004dfe64 <031f35a8>
004dfe00: 00000000 00000003 00726034 00000004 00000020 00000005 00000006
004dfe20: 00001000 00000007 031a0000 00000008 00000000 00000009 00726bc0
004dfe60: 00000000 00000000 <00726bee><00724178> 00726bc0
<00724160> 004dff50 004dff70
004dfe80:<00726bc4> 03bd3728 00000002 004dff70 03bd382c 03bd3730
<00724160> 004dff7c
004dfee0: 00726034 00000004 00000020 00000005 00000006 00000007 031a0000
004dff00: 00000000 00000009 00726bc0 0000000b 00000000 0000000c 00000000
004dff60: 0072401c 0000b01c 00000450 00000000 00020000 00726000 00000000
004dff80: 03bd47ec 000057ec 000009fc 00000000 00000000 00000000 61727400
frame 1 : <0x00727238> [ /bin/traps_test1 + 0x1238 ]
frame 3 : <0x00726bee> [ /bin/traps_test1 + 0xbee ]
address : <0x00724178> [ /lib/ld-uClibc.so.0 + 0x7178 ]
address : <0x00724160> [ /lib/ld-uClibc.so.0 + 0x7160 ]
address : <0x00726bc4> [ /bin/traps_test1 + 0xbc4 ]
return address: [0x0000995e]; contents of:
0x00009930: 0162 0163 0170 0173 0171 0174 0172 0175
0x00009940: 0166 0140 0167 31d3 0142 017c 017d 017e
0x00009950: 0179 0141 61f9 0041 017b 6001 3621 [3629]
0x00009960: 3631 3639 6807 083f e14d ffc0 e10d 0014
It might be better to look around here :
-------------------------------------------
SEQSTAT: 0000c000 IPEND: 0050 SYSCFG: 0006
EXCAUSE : 0x0
physical IVG6 asserted : <0x00009adc> { _evt_timer + 0x0 }
logical irq 6 mapped : <0x00007a8c> { _timer_interrupt + 0x0 }
logical irq 21 mapped : <0x0009cf6c> { _bfin_serial_dma_rx_int + 0x0
}
logical irq 22 mapped : <0x0009cc88> { _bfin_serial_dma_tx_int + 0x0
logical irq 40 mapped : <0x000a56fc> { _smc_interrupt + 0x0 }
SEQSTAT: 0000c03f IPEND: 0070 SYSCFG: 0006
PC : <0x0000995e> { __common_int_entry + 0x56 }
R0 : 00000006 R1 : 00000000 R2 : 00726fdc R3 : 00000002
P0 : ffe02108 P1 : 00726fc8 P2 : 87654320 P3 : 03bd5138
P4 : 004e17b8 P5 : 004dff3c FP : 004dfd68 SP : 00637e48
Source : <0x0000995c> { __common_int_entry + 0x54 } 0x3621
3 Target : <0x00009908> { __common_int_entry + 0x0 }
Source : <0x00009af0> { _evt_timer + 0x14 } JUMP.S
4 Target : <0x00009adc> { _evt_timer + 0x0 }
Source : <0x00009ad4> { _evt_ivhw + 0xec } RTI
5 Target : <0x00009a80> { _evt_ivhw + 0x98 }
Source : <0x0000976e> { _ret_from_exception + 0x66 } RTS
6 Target : <0x00009708> { _ret_from_exception + 0x0 }
Source : <0x00009a7c> { _evt_ivhw + 0x94 } CALL pcrel
7 Target : <0x00009a7a> { _evt_ivhw + 0x92 }
Source : <0x0000543a> { _trap_c + 0x3f2 } RTS
SP: [0x00637f24] <0x00637f24> /* kernel dynamic memory */
Memory from 0x00637f20 to 00638000
00637f20: 00000006 [00726fdc] 00000050 0000c000 00000000 00638000 031cec3a
00726fdc
00637f40:<00727238> 00000006 02002000 031df9dd 031a6351 031df996
031a6344 00000000
00637f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00637f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00637fa0: 00000000 00000000 00000000 00000000 03bd4f54 004dfd54 004dfd68
004dff3c
00637fc0: 004e17b8 03bd5138 87654320 00726fc8 00000004 004dff99 004dff50
004e399c
00637fe0: 004dfea4 00000002 03bd48d0 00000012 87654320 87654320 00000004
00638000: 00000000
address : <0x00727238> [ /bin/traps_test1 + 0x1238 ]
--- Robin Getz 2009-04-23 10:22:36
What version of 533 are you testing on?
05000246 (BF533-0.[0-4])- says: When Data CPLBs are enabled, hardware errors
generated as a result of speculative accesses to reserved or undefined memory
should not occur, but they do.
WORKAROUND:
None. Avoid accessing reserved memory as part of a speculative fetch.
If this is the problem - I can add something in traps.c to handle the anomaly.
--- Graf Yang 2009-04-24 07:17:40
I'm using 533 0.3
The trap_c() seems safe, it didn't trigger new hardware error in the first
hardware error handler.
I guess the processor sometimes not clear IPEND bit 5 (Hardware Error) in the
state translation from { _evt_ivhw + 0xec } RTI
to { _evt_timer + 0x0 }.
So once the __common_int_entry opened interrupt, the hardware error comes
again.
After add a ssync before reti, the hardware error trap test becomes very
stable.
Any idea?
--- arch/blackfin/mach-common/interrupt.S (revision 6081)
+++ arch/blackfin/mach-common/interrupt.S (working copy)
@@ -189,6 +189,7 @@
.Lcommon_restore_all_sys:
RESTORE_ALL_SYS
+ ssync;
rti;
ENDPROC(_evt_ivhw)
--- Robin Getz 2009-04-24 08:11:46
Do you get a different result on 0.5 533?
--- Graf Yang 2009-04-28 01:01:21
We have not 0.5 533 here. I tested it on 0.4 533, the ssync( or csync, or two
NOPs) also can fix this issue.
While, there is another issue on 0.4 533. The system will random hang when
testing the hardware error, may hang on the 8th, or the 19th, which I ever saw
on 0.3 533(when doing hardware error testing), and 0.2 537(when doing dcplb miss
testing). But it is frequently on 0.4 533.
RuEnxng test ternal Memory Addressing Error
COMM=traps_test1 PID=142
TEXT = 0x00366000-0x003677ec DATA = 0x003627ec-0x003631e8
BSS = 0x003631e8-0x00340000 USER-STACK = 0x0035fea0
return address: [0x00366fdc]; contents of:
0x00366fb0: bbf0 b9f0 6408 bbe0 b9ea 9151 ac53 0061
0x00366fc0: e801 0000 0010 0000 e800 0005�
(here the system hang, watchdog seems can't reboot it)
--- Graf Yang 2009-04-29 02:23:51
I have fixed it in trunk. The random hang bug is opened at
blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5101
--- Robin Getz 2009-04-29 07:21:12
Adding a random SSYNC/CSYNC so that a problem goes away isn't a "fix"
until someone from design confirms it is the the right thing to do - all that
could be happening is that the problem is less likely to occur - but could still
be there.
I'm following up with the design team.
--- Mike Frysinger 2009-04-29 13:16:41
the PRM/HRM talks about too fast interrupt handlers need to use a sync
instruction, but that's due to the event handler needing to clear a bit in the
system MMR space. i'm not sure that applies (directly) here since on the BF53x,
there is no bit to clear for IVG5 (hardware error) like there is on the BF54x.
--- Robin Getz 2009-04-30 15:37:57
After talking to the design folks, they suggested this (which is required, and
not in the HRM).
===================================================================
--- linux-2.6.x/arch/blackfin/mach-common/interrupt.S (revision 6310)
+++ linux-2.6.x/arch/blackfin/mach-common/interrupt.S (working copy)
@@ -158,6 +158,27 @@
r7.l = W[p5];
1:
#endif
+ /* It is possible that a single transaction, could cause multiple
+ * ivhw5 events, so assume that we didn't cause another one (while
+ * pushing things on the stack) and make sure everything is cleared
+ * properly. We are atomic now, so unprotected SSYNC is OK, which
+ * forces/waits for all transactions which could cause additional
+ * IRQ5 events to be complete.
+ */
+ SSYNC;
+ /* To clear bit N from ILAT, first make sure that IMASK[N] == 0,
+ * and then write ILAT[N] = 1.
+ P2.L = lo(IMASK);
+ P2.H = hi(IMASK);
+ R0 = [P2]; /* read IMASK */
+ R1 = R0;
+ BITCLR(R0, EVT_IVHW_P);
+ [P2] = R0; /* write IMASK */
+ R1 = 0x0020; /* EVT_IVHW_P */
+ [P2 + (ILAT - IMASK)] = R1; /* Write 1 to clear */
+ CSYNC; /* Make sure it completes */
+ [P2] = R1; /* restore IMASK */
# We are going to dump something out, so make sure we print IPEND
properly
p2.l = lo(IPEND);
@@ -189,7 +210,6 @@
- csync;
Since this isn't a fast path - it looks to be the safe thing to do.
I'm trying it out now, and it seems to work OK. (at least the last 30 min of
getting errors, and recovering properly).
If no objections, I'll commit this to trunk tomorrow.
--- Mike Frysinger 2009-04-30 15:49:29
i guess the common irq code cant handle that since IVG5 is a dedicated entry
point rather
why do you do "R1 = R0" ? R1 isnt used before it gets set directly
to 0x0020.
there is already P2 = IPEND below, so you should combine the IPEND loading
there as well
and i see we have '#' comments ... they should all be /*...*/
--- Robin Getz 2009-04-30 16:50:15
> do you do "R1 = R0" ?
That was a mistake. It should be:
@@ -158,11 +158,30 @@
+ R2 = 0x0020; /* EVT_IVHW_P */
+ [P2 + (ILAT - IMASK)] = R2; /* Write 1 to clear */
- # We are going to dump something out, so make sure we print IPEND
- p2.l = lo(IPEND);
- p2.h = hi(IPEND);
- r0 = [p2];
+ /* We are going to dump something out, so make sure we print IPEND
properly */
+ r0 = [P2 + (IPEND - IMASK)];
[sp + PT_IPEND] = r0;
/* set the EXCAUSE to HWERR for trap_c */
@@ -189,7 +208,6 @@
--- Mike Frysinger 2009-04-30 16:57:39
rather than 0x0020, how about EVT_IVHW ?
in terms of what's actually going on, why does mucking with IMASK matter when
clearing bits in ILAT ?
--- Robin Getz 2009-04-30 19:01:42
Since that is what the HRM says to do
I'm running...
root:/> i=0; while [ 1 ] ; do /traps_test 24 > /dev/null ; i=`expr $i +
1`; echo
$i; done
To see how many times it runs without crashing... (Even with the
"fixed" version, it still crashed after 3 or so hours - so I put the
csync back, and am trying again...).
--- Robin Getz 2009-04-30 20:18:15
OK - and the magic number is: 57,247 times before a failure.
0 Target : <0x00004d08> { _trap_c + 0x0 }
Source : <0xffa00c30> { _evt_ivhw + 0x90 } CALL pcrel
1 Target : <0xffa00ba0> { _evt_ivhw + 0x0 }
Source : <0xffa00b24> { __common_int_entry + 0x54 } 0x3621
2 Target : <0xffa00ad0> { __common_int_entry + 0x0 }
Source : <0xffa00cac> { _evt_timer + 0x14 } JUMP.S
3 Target : <0xffa00c98> { _evt_timer + 0x0 }
Source : <0xffa003e6> { _ex_dcplb_miss + 0x5e } RTX
4 Target : <0xffa003ae> { _ex_dcplb_miss + 0x26 }
Source : <0x00009bfe> { _dcplb_miss + 0x16e } RTS
5 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
Source : <0x00009b74> { _dcplb_miss + 0xe4 } IF CC JUMP
6 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
7 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
8 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
9 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
10 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
11 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
12 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
13 Target : <0x00009b64> { _dcplb_miss + 0xd4 }
14 Target : <0x00009b6e> { _dcplb_miss + 0xde }
Source : <0x00009b62> { _dcplb_miss + 0xd2 } JUMP.S
15 Target : <0x00009a90> { _dcplb_miss + 0x0 }
Source : <0x0000a1f8> { _cplb_hdr + 0x28 } JUMP.L
My guess is that the :
(_ex_dcplb_miss + 0x5e } RTX
instruction was pointing to (the value of the RTX) the one that caused the bad
fetch. (which would signal the IRQ5) - but even though it didn't commit, it was
put out on the bus. - when interrupts were re-enabled - it triggered...
I think there is something we can do in __common_int_entry which I'll try out -
the question is - do it unconditionally, or only if debug is enabled... Hmmm...
I guess I need to make sure the concept is sound with design before I start
noodling about making it conditional...
--- Mike Frysinger 2009-04-30 21:29:15
if it's a debug option, people wont enable it, and we'll debug stuff and users
will ask questions
--- Robin Getz 2009-05-01 14:02:24
It is really about making hardware errors less defered - which is the same as
the existing:
config DEBUG_HWERR
bool "Hardware error interrupt debugging"
depends on DEBUG_KERNEL
help
When enabled, the hardware error interrupt is never disabled, and
will happen immediately when an error condition occurs. This comes
at a slight cost in code size, but is necessary if you are getting
hardware error interrupts and need to know where they are coming
from.
How about decouple this from DEBUG_KERNEL - and always turn it on for our
boards?
--- Graf Yang 2009-05-04 04:35:21
I like it always be enabled.
I can't run traps_test 24. Which item are you testing?
I'm running the following command on 0.3 bf533.
i=0; while [ 1 ] ; do traps_test 21 > /dev/null ; i=`expr $i + 1`; echo $i;
done
I use the latest kernel with your patch, it can never run over 100 times.
The hardware trace is,
0 Target : <0x00004af4> { _trap_c + 0x0 }
Source : <0xffa00c86> { _evt_ivhw + 0x8e } CALL pcrel
1 Target : <0xffa00c68> { _evt_ivhw + 0x70 }
Source : <0xffa00c64> { _evt_ivhw + 0x6c } IF !CC JUMP
2 Target : <0xffa00bf8> { _evt_ivhw + 0x0 }
Source : <0x00675078> [ /bin/traps_test + 0x1078 ] 0xb9fa
3 Target : <0x0067506c> [ /bin/traps_test + 0x106c ]
Source : <0x00675276> [ /bin/traps_test + 0x1276 ] CALL (P1)
4 Target : <0x00675254> [ /bin/traps_test + 0x1254 ]
Source : <0x00432784> [ /lib/libc.so.0 + 0x32784 ] RTS
5 Target : <0x0043277e> [ /lib/libc.so.0 + 0x3277e ]
Source : <0x0043283a> [ /lib/libc.so.0 + 0x3283a ] JUMP.S
6 Target : <0x00432838> [ /lib/libc.so.0 + 0x32838 ]
Source : <0x00432820> [ /lib/libc.so.0 + 0x32820 ] IF !CC JUMP
7 Target : <0x0043281c> [ /lib/libc.so.0 + 0x3281c ]
Source : <0x0040d580> [ /lib/libc.so.0 + 0xd580 ] RTS
8 Target : <0x0040d56c> [ /lib/libc.so.0 + 0xd56c ]
Source : <0xffa00bf4> { __common_int_entry + 0xdc } RTI
9 Target : <0xffa00b92> { __common_int_entry + 0x7a }
Source : <0xffa00dbe> { _evt_system_call + 0x66 } JUMP.S
10 Target : <0xffa00dbe> { _evt_system_call + 0x66 }
Source : <0xffa0089c> { _system_call + 0xb8 } RTS
11 Target : <0xffa00898> { _system_call + 0xb4 }
Source : <0xffa00888> { _system_call + 0xa4 } IF !CC JUMP
12 Target : <0xffa00882> { _system_call + 0x9e }
Source : <0xffa00872> { _system_call + 0x8e } IF !CC JUMP
13 Target : <0xffa0084c> { _system_call + 0x68 }
Source : <0x00022f78> { _sys_nanosleep + 0x1c } RTS
14 Target : <0x00022f72> { _sys_nanosleep + 0x16 }
Source : <0x00022fb4> { _sys_nanosleep + 0x58 } JUMP.S
15 Target : <0x00022fb4> { _sys_nanosleep + 0x58 }
Source : <0x00022f0a> { _hrtimer_nanosleep + 0x7a } RTS
It is the bug [#5101] which I'm tracking.
Are you using 0.5 bf533?
--- Mike Frysinger 2009-05-04 13:35:16
i thought DEBUG_HWERR was about better error messages, not correctly
functioning. this is about hardware errors being correctly handled.
--- Graf Yang 2009-05-04 23:24:02
Robin is working on this bug.
--- Robin Getz 2009-05-11 16:11:50
So, I think I will revert this change, and marked closed -- as I think the
corrections in bug 5120 are the right ones, and the csync masks things a bit..
blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5120
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found