[U-Boot-Users] Data machine check in kernel mode. Please help!

Jeff Stevens jsteve17 at yahoo.com
Wed Mar 29 03:26:28 CEST 2006


Please help.  I have an AMCC Luan development board,
and I was able to boot the kernel a few days ago, and
then all of a sudden (with a few mods on my part) I
keep get the following:

Bytes transferred = 903632 (dc9d0 hex)
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.14-rc4
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    903568 Bytes = 882.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.6.14-rc4 (root at localhost.localdomain)
(gcc version 4.0.0 (DENX E
LDK 4.0 4.0.0)) #1 Mon Mar 27 21:27:26 EST 2006
Luan port (MontaVista Software, Inc.
<source at mvista.com>)
Built 1 zonelists
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.1.254:/opt/eldk/ppc_4xx ip
=192.168.1.1:192.168.1.254:192.168.1.254:255.255.255.0:luan:eth0:off
panic=1 con
sole=ttyS0,115200
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Memory: 777472k available (1400k kernel code, 432k
data, 108k init, 0k highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
ttyS2 at MMIO 0x0 (irq = 2) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 1 TX channels, 1 RX channels
eth0: emac0, MAC 00:90:00:12:34:56
eth0: found CIS8201 Gigabit Ethernet PHY (0x01)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5,
131072 bytes)
TCP established hash table entries: 131072 (order: 7,
524288 bytes)
Data machine check in kernel mode.
PLB0: BEAR=0x000000000c000000 ACR=  0x00000000 BESR=
0x2fc00000
POB0: BEAR=0x0000000ffffffff8 BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C01C8B04 SP: C091FF70 REGS: c01d1f50
TRAP: 0202    Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c08d0b10[1] 'swapper' THREAD: c091e000
Last syscall: 120
GPR00: 00020000 C091FF70 C08D0B10 EFC00000 000006ED
00010000 C01D0000 00000034
GPR08: 00000000 00000000 00000000 EFC00000 24F81F88
30000000 1FFF5F00 00000001
GPR16: 00800000 1FFFF5E8 FFFFFFFF 00000000 007FFF00
1FFF01A4 00000001 00000007
GPR24: C0160000 C0160000 C01D0000 C0160000 C01D0000
C01B0800 C01B0000 C01B0800
NIP [00000000] 0x0
LR [c01c8b04] tcp_init+0x94/0x32c
Call trace:
 [c01c91e4] inet_init+0x174/0x458
 [c000114c] init+0xc0/0x260
 [c0004534] kernel_thread+0x44/0x60
Data machine check in kernel mode.
PLB0: BEAR=0x000000000c000000 ACR=  0x00000000 BESR=
0x2fc00000
POB0: BEAR=0x0000000ffffffff8 BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C00020F8 SP: C01D1E70 REGS: c01d1f50
TRAP: 0202    Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c08d0b10[1] 'swapper' THREAD: c091e000
Last syscall: 120
GPR00: 08000000 C01D1E70 C08D0B10 C01D1E80 00000ABE
FFFFFFFF C01D0000 00004000
GPR08: C01D0000 C00020F8 00021002 C00036FC C08D0CD8
30000000 1FFF5F00 00000001
GPR16: 00800000 1FFFF5E8 FFFFFFFF 00000000 007FFF00
1FFF01A4 00000001 00000007
GPR24: C0160000 C0160000 C01D0000 C0160000 C01D0000
C01B0800 C01D1F50 00000007
NIP [00000000] 0x0
LR [c00020f8] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
 <0>Rebooting in 1 seconds..


The only thing I have been messing around with is the
DDR2 initialization in luan.c in boards/amcc/luan.  I
am not using the same memory that luan.c is setup for,
and do not have access to it.  So, I tried reverting
to the virgin U-Boot-1.1.4 source, and only made the
changes that I need to make my memory work, and I am
still getting the same output from the kernel.  What
could be causing this?  Could it be my memory
configuration?  Please help!!!!!

Oh, also, I can boot the same kernel using PIBS, and
everything boots fine.  It's only under U-Boot that I
get this issue.

Thanks,
   Jeff Stevens

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




More information about the U-Boot mailing list