[#4564] DCPLB miss kills kernel on BF533
Submitted By: Mike Frysinger
Open Date
2008-10-25 00:45:19 Close Date
2009-08-14 06:31:11
Priority:
Medium Assignee:
Robin Getz
Status:
Closed Fixed In Release:
N/A
Found In Release:
2007R1-RC3 Release:
Category:
N/A Board:
STAMP
Processor:
BF533 Silicon Revision:
Is this bug repeatable?:
Yes Resolution:
Fixed
Uboot version or rev.:
Toolchain version or rev.:
any
App binary format:
N/A
Summary: DCPLB miss kills kernel on BF533
Details:
if the kernel does a dump_stack() as part of a diagnostic message, it may cause an exception (which would then kill the kernel). this is because while get_instruction() does a lot of checking to make the address is valid, it doesnt handle the case of the address being valid but there is no dcplb matching.
for example, do a gpio_request() in kernel space after the pin has been allocated elsewhere ... the code calls dump_stack() from kernel space and then dies.
eth0: SMC91C11xFD (rev 1) at 20300300 IRQ 40 [nowait]
eth0: Ethernet addr: 00:e0:22:fe:05:3f
Hardware Trace:
0 Target : <0x00004818> { _dump_stack + 0x0 }
Source : <0x000060de> { _peripheral_request + 0x9a } CALL pcrel
1 Target : <0x000060c0> { _peripheral_request + 0x7c }
Source : <0x00006076> { _peripheral_request + 0x32 } IF !CC JUMP
2 Target : <0x00006066> { _peripheral_request + 0x22 }
Source : <0x00006060> { _peripheral_request + 0x1c } IF !CC JUMP
3 Target : <0x0000605e> { _peripheral_request + 0x1a }
Source : <0x00006052> { _peripheral_request + 0xe } IF !CC JUMP
4 Target : <0x00006044> { _peripheral_request + 0x0 }
Source : <0x0009e1e0> { _setup + 0x194 } CALL pcrel
5 Target : <0x0009e1c0> { _setup + 0x174 }
Source : <0x0009e1ac> { _setup + 0x160 } IF !CC JUMP
6 Target : <0x0009e146> { _setup + 0xfa }
Source : <0x0009e0f6> { _setup + 0xaa } IF !CC JUMP
7 Target : <0x0009e0d2> { _setup + 0x86 }
Source : <0x0009ddb0> { _hz_to_spi_baud + 0x38 } RTS
8 Target : <0x0009dd9c> { _hz_to_spi_baud + 0x24 }
Source : <0xffa0185c> { ___umodsi3 + 0x2c } RTS
9 Target : <0xffa01852> { ___umodsi3 + 0x22 }
Source : <0xffa017be> { ___udivsi3 + 0xde } RTS
10 Target : <0xffa017b8> { ___udivsi3 + 0xd8 }
Source : <0xffa017a0> { ___udivsi3 + 0xc0 } IF !CC JUMP
11 Target : <0xffa01722> { ___udivsi3 + 0x42 }
Source : <0xffa016f8> { ___udivsi3 + 0x18 } IF !CC JUMP
12 Target : <0xffa016e0> { ___udivsi3 + 0x0 }
Source : <0xffa0184e> { ___umodsi3 + 0x1e } CALL pcrel
13 Target : <0xffa01830> { ___umodsi3 + 0x0 }
Source : <0x0009dd98> { _hz_to_spi_baud + 0x20 } CALL pcrel
14 Target : <0x0009dd90> { _hz_to_spi_baud + 0x18 }
Source : <0xffa017be> { ___udivsi3 + 0xde } RTS
15 Target : <0xffa017b8> { ___udivsi3 + 0xd8 }
Source : <0xffa017a0> { ___udivsi3 + 0xc0 } IF !CC JUMP
Stack info:
SP: [0x00335d88] <0x00335d88> /* kernel dynamic memory */
show_stack:833:here addr=335d80
show_stack:838:here addr=335d80
show_stack:843:here ins_addr=335d86
is_bfin_call:778:here ins_addr=335d86
is_bfin_call:783:here opcode=fd05
show_stack:838:here addr=335d84
show_stack:843:here ins_addr=fd050f7e
is_bfin_call:778:here ins_addr=fd050f7e
show_stack:838:here addr=335d88
show_stack:843:here ins_addr=5eebffe
is_bfin_call:778:here ins_addr=5eebffe
< then the first call to get_instruction() is made and crashes >
Data access CPLB miss
- Used by the MMU to signal a CPLB miss on a data access.
Kernel OOPS in progress
Deferred Exception context
CURRENT PROCESS:
COMM=swapper PID=1
invalid mm
return address: [0x00003fe4]; contents of:
0x00003fc0: 107e 3011 6412 0a11 107a e120 03ff 0a01
0x00003fd0: 1c10 e14a 0012 e10a df58 9110 0a02 1409
0x00003fe0: 3211 6c66 [9550] 3213 9710 0127 6008 0010
0x00003ff0: 63f8 e140 eeff 0a01 1466 63f8 e140 ff7f
SEQUENCER STATUS: Not tainted
SEQSTAT: 00062026 IPEND: 8030 SYSCFG: 0006
EXCAUSE : 0x26
physical IVG15 asserted : <0xffa00db0> { _evt_system_call + 0x0 }
logical irq 6 mapped : <0xffa00370> { _timer_interrupt + 0x0 }
logical irq 20 mapped : <0x0009eb44> { _dma_irq_handler + 0x0 }
logical irq 40 mapped : <0x000988ec> { _smc_interrupt + 0x0 }
RETE: <0x00004328> { _show_stack + 0x48 }
RETN: <0x00335c88> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x0000426a> { _is_bfin_call + 0x32 }
PC : <0x00003fe4> { _get_instruction + 0x2c }
DCPLB_FAULT_ADDR: <0x05eebffe> /* kernel dynamic memory */
ICPLB_FAULT_ADDR: <0x0000001f> /* Maybe null pointer? */
PROCESSOR STATE:
R0 : 08000000 R1 : 05eebffe R2 : 05eec000 R3 : 00335c9c
R4 : 00000002 R5 : 00336000 R6 : 00335c9c R7 : 05eebffe
P0 : 0000000a P1 : 0013dfb4 P2 : 05eebffe P3 : 0000ffff
P4 : 00335d84 P5 : 00335cc0 FP : 00335d58 SP : 00335bac
LB0: ffa0179c LT0: ffa0177c LC0: 00000000
LB1: 0008263a LT1: 0008262e LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 0000000f
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00000000
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 000fcfac
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 0000001b
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 00000000 ASTAT: 00002022
No trace since you do not have CONFIG_DEBUG_BFIN_NO_KERN_HWTRACE enabled
Kernel Stack
Stack info:
SP: [0x00335c9c] <0x00335c9c> /* kernel dynamic memory */
Follow-ups
--- Robin Getz 2008-10-27 11:54:23
Yeah, but...
dump_stack() from kernel space (EVT14/15) - should be able to handle a CPLB
miss. The DCPLB fault address is 0x5eebffe (94Meg) - There isn't a valid CPLB
installed for this on most boards - what platform are you testing on?
It should have failed the (addr + 2) <= physical_mem_end test in
get_instruction().
?
--- Mike Frysinger 2008-10-27 13:35:37
a BF533-STAMP has 128 megs
--- Mike Frysinger 2008-10-27 19:12:45
hmm, maybe it is a matter of DCPLB miss not working on the BF533
if i run crash_test on my BF533-STAMP, the kernel dies when it gets to the
DCPLB miss test ...
Running test 15 for exception 0x26: Data access CPLB miss
...
Running test 15 for exception 0x26: Data access CPLB miss
... External Memory Addressing Error
Kernel OOPS in progress
HW Error context
CURRENT PROCESS:
COMM=traps_test PID=144
......... snip .........
--- Robin Getz 2008-10-28 10:52:43
I will dig up a 533 STAMP, and try it out.
--- Robin Getz 2009-06-25 15:24:06
I think this is a new 533 - 0.3 issue - since I can't reproduce on a 533 - 0.5
--- Robin Getz 2009-08-14 11:31:32
Now, to fix the original issue you pointed out...
Fixed on branch - was fixed on trunk by the addition of
bfin_mem_access_type().
Closing. If you can still reproduce - please re-open.
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found