FAQ: [#5992] bfin-mac driver randomly crashing...(2010)

[#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 }

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 }

/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