[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Kernel oops on Etrax MCM
Inside the MCM there is an ETRAX 100LX Revision 2. The
address space, MMU, external DMAs etc is all the same
as for ETRAX 100LX. But there may be a difference in
memory configuration between your two boards. How much
memory is on the two boards? Do you only use the internal
MCM RAM or have you added any external RAM?
We can't do much with just a kernel oops trace. Please run
it through ksymoops. From os/linux:
ksymoops -v vmlinux -K -L -O -m System.map
copy paste everything from "Oops" until "Code" to ksymoops.
ksymoops will then print a call trace.
Behalf Of Stefano Vicenzetto
Sent: Thursday, November 14, 2002 10:23 AM
Cc: Sergio Ruocco; Luigi Faverzani
Subject: Kernel oops on Etrax MCM
We are experiencing Kernel oops in an application+driver running on Etrax
MCM (final board).
The very same combination otherwise works perfectly on Etrax 100 LX
Prototype board and final board architectures are substantially identical,
so the Kernel oops seems not due to our hardware bug.
Our application uses external DMA and Ethernet and our prototype board
streams up to 1 Mbyte/sec.
The prototype board can indifferently select and use DMA0 or DMA1, while the
current final board could be checked only on DMA1 (we are modifying the PCB
to enable also DMA0 - and this is the only real circuit difference between
the prototype and the final board).
The final board starts, initializes all the external devices, allocates the
memory and crashes after some DMA transfers, as you can verify in the
Anything substantial changed between 100LX and MCM ?
Esp. regarding memory (maps, MMU, addressing) and/or external DMA?
Before we dive in our (otherwise working) code, anyone experienced a similar
Our 2 systems setup:
Etrax 100 LX
Etrax development 2_1_0
Etrax 100 LX MCM
Etrax development 2_1_0 + MCM patch
Both the driver and the application source are the same for the 2 systems.
We attach the kernel Oops log.
<1>Unable to handle kernel NULL pointer dereference at virtual address
<4>IRP: 00000030 SRP: c00740f2 DCCR: 00000428 USP: afffe19c MOF: 00000000
<4> r0: c00ea716 r1: c00ea738 r2: c0546038 r3: 00004000
<4> r4: c0006b00 r5: affffbb9 r6: fffffff7 r7: 00080870
<4> r8: 00000001 r9: 00894000 r10: 8f98ae6f r11: 00000001
<4>r12: ffffffff r13: b0000018 oR10: 8f98ae6f
<4>Process bus (pid: 71, stackpage=c0598000)
<4>Stack from afffe19c:
<4> 00080c8c 00028000 00000003 00000000 affffe6c affff851 00000001
<4> 00080870 affffe3d 00080794 affffbbd 000818f2 affff7c9 00000000
<4> 3ab91c10 00080ed6 00000001 0008074c 3aabec30 affffea4 3ab92fec
<4>Stack from c0599dd4:
<4> c0006b00 c0599f14 c005a854 c005aa18 00000001 00000000 00000000
<4> c00c4690 00000002 c0599ed0 c005aabe c0599ed0 c0612a34 c0006b00
<4> 00000001 00080870 fffffff7 affffbb9 c0006b00 00004000 c0599ed0
<4>Call Trace: [<c0006b00>] [<c005a854>] [<c005aa18>] [<c005aabe>]
<4> [<c0053831>] [<c005c728>] [<c005a74a>] [<c0006b00>] [<c00740f2>]
[<c0006b00>] [<c0073f40>] [<c00723bc>]
<4> [<c007262c>] [<c0073186>] [<c00281be>] [<c005a64e>]
<4>Code: Bad IP value.