[#5992] bfin-mac driver randomly crashing...
Submitted By: Robin Getz
Open Date
2010-03-29 13:45:31 Close Date
2010-05-25 08:07:31
Priority:
Medium Assignee:
Nobody
Status:
Closed Fixed In Release:
N/A
Found In Release:
2010R1 Release:
Category:
N/A Board:
N/A
Processor:
ALL Silicon Revision:
Is this bug repeatable?:
No Resolution:
Not reproducible
Uboot version or rev.:
Toolchain version or rev.:
trunk head 4.3
App binary format:
N/A
Summary: bfin-mac driver randomly crashing...
Details:
Data access misaligned address violation
<5> - Attempted misaligned data memory or data cache access.
Kernel OOPS in progress
Deferred Exception context
CURRENT PROCESS:
COMM=sh PID=4433 CPU=0
invalid mm
return address: [0x000b97a4]; contents of:
0x000b9780: 9110 4a38 9310 2fd7 05f3 e14d 0018 e800
0x000b9790: 0003 e10d 07e4 3220 916a e14b 0018 3031
0x000b97a0: e10b 07d0 [9111] 9118 e422 0024 e520 0022
0x000b97b0: 0801 18c7 6018 5402 bc54 0c10 18a9 0000
ADSP-BF537-0.2 500(MHz CCLK) 125(MHz SCLK) (mpu off)
Linux version 2.6.33.1-ADI-2010R1-pre-svn8572 (rgetz@imhotep) (gcc version 4.3.4 (ADI-trunk/svn-3951) ) #627 Mon Mar 29 12:41:03 EDT 2010
SEQUENCER STATUS: Not tainted
SEQSTAT: 00060024 IPEND: 8008 IMASK: ffff SYSCFG: 0006
EXCAUSE : 0x24
physical IVG3 asserted : <0xffa00730> { _trap + 0x0 }
physical IVG15 asserted : <0xffa01014> { _evt_system_call + 0x0 }
logical irq 6 mapped : <0xffa003a0> { _bfin_coretmr_interrupt + 0x0 }
logical irq 10 mapped : <0x000be748> { _bfin_rtc_interrupt + 0x0 }
logical irq 18 mapped : <0x000aa764> { _bfin_serial_dma_rx_int + 0x0 }
logical irq 19 mapped : <0x000aa4c4> { _bfin_serial_dma_tx_int + 0x0 }
logical irq 24 mapped : <0x000b9d94> { _bfin_mac_interrupt + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x02c37bfc> /* kernel dynamic memory (maybe user-space) */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x000d2a20> { _dev_hard_start_xmit + 0x110 }
PC : <0x000b97a4> { _bfin_mac_hard_start_xmit + 0x1c }
DCPLB_FAULT_ADDR: <0x1a2b3c4c> /* unconnected memory */
ICPLB_FAULT_ADDR: <0x000b97a4> { _bfin_mac_hard_start_xmit + 0x1c }
PROCESSOR STATE:
R0 : 02c38ec0 R1 : 02809c00 R2 : 00000002 R3 : 00000000
R4 : 0011f204 R5 : 02c37d50 R6 : 02809c00 R7 : 000016a0
P0 : 0294f8ac P1 : 0011f204 P2 : 1a2b3c4d P3 : 001807d0
P4 : 02c38ec0 P5 : 001807e4 FP : 02c37c08 SP : 02c37b20
LB0: ffa0172a LT0: ffa0172a LC0: 00000000
LB1: 0009c2d2 LT1: 0009c2c8 LC1: 00000000
B0 : 00000137 L0 : 00000000 M0 : fffffffc I0 : 0294f8c0
B1 : 000000c0 L1 : 00000000 M1 : 00000001 I1 : 027ef664
B2 : 7ffff000 L2 : 00000000 M2 : 00001802 I2 : 00000003
B3 : 00000000 L3 : 00000000 M3 : 0000005b I3 : 00000006
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 02d3fc94 ASTAT: 02003004
Hardware Trace:
0 Target : <0x00003ef8> { _trap_c + 0x0 }
Source : <0xffa006c4> { _exception_to_level5 + 0xa4 } JUMP.L
1 Target : <0xffa00620> { _exception_to_level5 + 0x0 }
Source : <0xffa004d4> { _bfin_return_from_exception + 0x20 } RTX
2 Target : <0xffa004b4> { _bfin_return_from_exception + 0x0 }
Source : <0xffa00578> { _ex_trap_c + 0x74 } JUMP.S
3 Target : <0xffa00504> { _ex_trap_c + 0x0 }
Source : <0xffa00798> { _trap + 0x68 } JUMP (P4)
4 Target : <0xffa0074e> { _trap + 0x1e }
Source : <0xffa0074a> { _trap + 0x1a } IF CC JUMP pcrel
5 Target : <0xffa00730> { _trap + 0x0 }
FAULT : <0x000b97a4> { _bfin_mac_hard_start_xmit + 0x1c } R1 = [P2]
Source : <0x000b97a0> { _bfin_mac_hard_start_xmit + 0x18 } 0xe10b07d0
6 Target : <0x000b9788> { _bfin_mac_hard_start_xmit + 0x0 }
Source : <0x000d2a1e> { _dev_hard_start_xmit + 0x10e } CALL (P2)
7 Target : <0x000d2a10> { _dev_hard_start_xmit + 0x100 }
Source : <0x000d2a54> { _dev_hard_start_xmit + 0x144 } JUMP.S
8 Target : <0x000d2a54> { _dev_hard_start_xmit + 0x144 }
Source : <0x000d5efc> { _dst_release + 0x24 } RTS
9 Target : <0x000d5efc> { _dst_release + 0x24 }
Source : <0x000d5f0c> { _dst_release + 0x34 } IF !CC JUMP pcrel (BP)
10 Target : <0x000d5efe> { _dst_release + 0x26 }
Source : <0x000d5ef6> { _dst_release + 0x1e } IF !CC JUMP pcrel (BP)
11 Target : <0x000d5ed8> { _dst_release + 0x0 }
Source : <0x000d2a50> { _dev_hard_start_xmit + 0x140 } JUMP.L
12 Target : <0x000d2a50> { _dev_hard_start_xmit + 0x140 }
Source : <0x000d2a0e> { _dev_hard_start_xmit + 0xfe } IF !CC JUMP pcrel
13 Target : <0x000d29fe> { _dev_hard_start_xmit + 0xee }
Source : <0x000d2940> { _dev_hard_start_xmit + 0x30 } IF CC JUMP pcrel (BP)
14 Target : <0x000d2938> { _dev_hard_start_xmit + 0x28 }
Source : <0x000d2932> { _dev_hard_start_xmit + 0x22 } IF CC JUMP pcrel
15 Target : <0x000d2910> { _dev_hard_start_xmit + 0x0 }
Source : <0x000de282> { _sch_direct_xmit + 0xd2 } CALL pcrel
Kernel Stack
Stack info:
SP: [0x02c37f24] <0x02c37f24> /* kernel dynamic memory (maybe user-space) */
Memory from 0x02c37f20 to 02c38000
[snip]
Return addresses in stack:
Modules linked in:
Kernel panic - not syncing: Kernel exception
Hardware Trace:
Stack info:
SP: [0x02c37a38] <0x02c37a38> /* kernel dynamic memory (maybe user-space) */
FP: (0x02c37cd4)
Memory from 0x02c37a30 to 02c38000
02c37a30: 02c37a38 00000013 [00142e80] 00114a0a 02c37b20 00142e80 001773ce [snip]
Return addresses in stack:
address : <0xffa01caa> { _schedule + 0x162 }
address : <0x000d2a20> { _dev_hard_start_xmit + 0x110 }
address : <0x000d2a20> { _dev_hard_start_xmit + 0x110 }
frame 1 : <0x0000f686> { _try_to_wake_up + 0x5e }
address : <0x000f92aa> { _tcp_transmit_skb + 0x3ae }
address : <0x0010886e> { _inet_release + 0x2e }
address : <0x000c6a90> { _sock_release + 0x14 }
address : <0x0004767c> { ___fput + 0xbc }
address : <0xffa008d2> { _system_call + 0x6a }
address : <0xffa008d2> { _system_call + 0x6a }
/linux-2.6.x> bfin-elf-addr2line -f -e vmlinux 0xb97a4
bfin_mac_hard_start_xmit
drivers/net/bfin_mac.c:988
sed '988!d' drivers/net/bfin_mac.c
if (current_tx_ptr->next == tx_list_head)
?
Follow-ups
--- Sonic Zhang 2010-03-30 02:04:29
It looks that fetching data from current_tx_ptr->next hits misalign
exception.
How to replicate this crash?
--- Robin Getz 2010-03-30 15:20:38
I was just doing lots of rsh/rcp traffic.
So I would assume it would happen on toolchain testing as well...
I only saw it once, so (today), I'm not sure it wasn't a bad userspace (which I
was doing) that corrupted some other memory...
If the toolchains tests are passing without crashing the kernel - I'll close
this.
Grace?
-Robin
--- Robin Getz 2010-05-25 08:05:13
While doing this test - it could have been a bad application writing over kernel
memory...
Closing since no one can replicate.
-Robin
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found