More Sandpoint woes

Hi,

I've got the Sandpoint/PPMC7400 to boot the kernel, mount the root
filesystem via NFS, and try to execute init. By the way, does anyone
have any idea why if I disable initrd support in the kernel config, it
doesn't succeed booting via BOOTP -- it times out, but the sniffer
doesn't even show that it sends any packets to the cable; while if I
enable initrd support, it just fails to mount the ramdisk, but then
proceeds to do a network boot all right? I tried it countless times,
and there's absolutely nothing else causing this -- it's that kernel
option. Some timing issue perhaps? This really puzzles me, even though
it's not a show-stopper.

In any case, when it tries to execute init it oopses. I've attached
the full bootlog to this mail, but in any case, here's the ksymoops of
the first oops:

quoted

EIP; 00000300 Before first symbol   <=====

Trace; ffffffea <END_OF_CODE+3bf364df/????>
Trace; c004b8c4 <load_elf_interp+28c/2d4>
Trace; c004c148 <load_elf_binary+6e8/950>
Trace; c003c9e4 <search_binary_handler+5c/160>
Trace; c003cc54 <do_execve+16c/1fc>
Trace; c0007218 <sys_execve+70/f0>
Trace; c0004e34 <ret_from_syscall_1+0/a0>
Trace; c0003f14 <init+18/1a8>
Trace; c0009670 <kernel_thread+2c/38>

Here's the ksymoops of the second:

quoted

EIP; 00000300 Before first symbol   <=====

Trace; c0007328 <print_backtrace+90/c8>
Trace; c0005268 <_exception+34/68>
Trace; c00054b8 <ProgramCheckException+4c/5c>
Trace; c0005090 <ret_from_except+0/c>
Trace; ffffffea <END_OF_CODE+3bf299e7/????>
Trace; c004b8c4 <load_elf_interp+28c/2d4>
Trace; c004c148 <load_elf_binary+6e8/950>
Trace; c003c9e4 <search_binary_handler+5c/160>
Trace; c003cc54 <do_execve+16c/1fc>
Trace; c0007218 <sys_execve+70/f0>
Trace; c0004e34 <ret_from_syscall_1+0/a0>
Trace; c0003f14 <init+18/1a8>
Trace; c0009670 <kernel_thread+2c/38>

And then the rest continue in the same vein -- an oops inside an oops
inside an oops.

Any idea what causes this?

I wanted to do some debugging on this, so I tried to enable kgdb in
the kernel config, but then it didn't link, complainig about
unresolved symbols getDebugChar, putDebugChar and
kgdb_uninterruptible.  I saw them defined in 8xx_boot/uart.c; does
this mean that on my board it's not supported? How hard would it be to
add it? (I *do* want to do it myself, perhaps with a little
bootstrapping from you as to *how*.)


--
Alex Shnitman                            | http://www.debian.org
alexsh@hectic.net, alexsh@linux.org.il   +-----------------------
http://alexsh.hectic.net    UIN 188956    PGP key on web page
       E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA

"I think there is a world market for about five computers."
	-- Thomas Watson, chairman of IBM, 1943

Alex, if you're interested, I have a better kernel for you to use.  Its in
ftp://www.mvista.com/pub/Area51/sandpoint-8240/sandpoint.linux.tar.gz

This has IDE support and fixes a bug in the eepro100.c driver for the
sandpoint.

<more comments below>

Mark
--

Alex Shnitman wrote:

Hi,

I've got the Sandpoint/PPMC7400 to boot the kernel, mount the root
filesystem via NFS, and try to execute init. By the way, does anyone
have any idea why if I disable initrd support in the kernel config, it
doesn't succeed booting via BOOTP -- it times out, but the sniffer
doesn't even show that it sends any packets to the cable; while if I
enable initrd support, it just fails to mount the ramdisk, but then
proceeds to do a network boot all right? I tried it countless times,
and there's absolutely nothing else causing this -- it's that kernel
option. Some timing issue perhaps? This really puzzles me, even though
it's not a show-stopper.

I've never had problems with initrd turned off in the kernel--that's my
normal mode.

In any case, when it tries to execute init it oopses. I've attached
the full bootlog to this mail, but in any case, here's the ksymoops of
the first oops:

quoted

quoted

EIP; 00000300 Before first symbol   <=====

Trace; ffffffea <END_OF_CODE+3bf364df/????>
Trace; c004b8c4 <load_elf_interp+28c/2d4>
Trace; c004c148 <load_elf_binary+6e8/950>
Trace; c003c9e4 <search_binary_handler+5c/160>
Trace; c003cc54 <do_execve+16c/1fc>
Trace; c0007218 <sys_execve+70/f0>
Trace; c0004e34 <ret_from_syscall_1+0/a0>
Trace; c0003f14 <init+18/1a8>
Trace; c0009670 <kernel_thread+2c/38>

Here's the ksymoops of the second:

quoted

quoted

EIP; 00000300 Before first symbol   <=====

Trace; c0007328 <print_backtrace+90/c8>
Trace; c0005268 <_exception+34/68>
Trace; c00054b8 <ProgramCheckException+4c/5c>
Trace; c0005090 <ret_from_except+0/c>
Trace; ffffffea <END_OF_CODE+3bf299e7/????>
Trace; c004b8c4 <load_elf_interp+28c/2d4>
Trace; c004c148 <load_elf_binary+6e8/950>
Trace; c003c9e4 <search_binary_handler+5c/160>
Trace; c003cc54 <do_execve+16c/1fc>
Trace; c0007218 <sys_execve+70/f0>
Trace; c0004e34 <ret_from_syscall_1+0/a0>
Trace; c0003f14 <init+18/1a8>
Trace; c0009670 <kernel_thread+2c/38>

And then the rest continue in the same vein -- an oops inside an oops
inside an oops.

Any idea what causes this?

No but I've seen other weird timing problems on this platform running the
2.4.0-test2 kernel.  This may very well be another one of those since you're
using a different processor than I am.

I know, not much help...  :(

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/