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: > > >>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: > > >>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 at 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/
