Multiple kernels OOPS at boot on Fujitsu pt510 ( AMD DX100 CPU ) - ksymoops output attached

Hi ;
I've been attempting to get Linux to run on a Fujitsu pt510 [1], unfortunatly without much success. The kernels die almost instantly after cpu initialisation. I have tried both a debian woody stock 2.2 kernel and a home built 2.4.17 kernel both built for 386. Attached is the kymoops output for the 2.4.17 kernel.

Id really appreciate some help on this matter. Theres plenty of these 510's on ebay at the moment going very cheapy ( 100$) and they'd make nice wireless 'web pads'.

Many thanks;

Matthew Allum

[1] Morebasic specs on the machine here;
http://www.mobilityconcepts.com/products/hardware/discontinued/point510/

Script started on Sun Feb 24 20:26:12 2002

debian:~# ksymoops -K -L -m /boot/System.map-2.4.17 -o /lib/modules/2.4.17 ~mall 
um/kernel-log.txt
ksymoops 2.4.3 on i686 2.2.20.  Options used
     -V (default)
     -K (specified)
     -L (specified)
     -o /lib/modules/2.4.17 (specified)
     -m /boot/System.map-2.4.17 (specified)

No modules in ksyms, skipping objects

CPU:    0
EIP:    0010:[<c0124e5d>]   Not tainted

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ffffffff ebx: 00000000 ecx: 00000008 edx: ffffffff
esi: c10ff338 edi: 00000000 ebp: c3aef000 esp: c0261eb4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid:0, stackpage=c0261000)

Stack: c10ff340 c10ff338 000001f0 00000246 00000001 c10f8d9c ffffffff c10ff348
       00000000 00000001 c3aef000 c0125229 c10ff338 000001f0 00000000 c10f8044
       c10fa044 00000000 00000008 00000001 c013c52f c10ff338 000001f0 00000000
Call Trace: [<c0125229>] [<c013c52f>] [<c013c6dc>] [<c01404ff>] [<c0130808>]
   [<c0130c22>] [<c0131090>] [<c0105000>] 
Code: c7 00 71 f0 2c 5a 8b 46 18 8b 4c 24 18 c7 44 08 fc 71 f0 2c 

Trace; c0125228 <kmem_cache_alloc+1b0/1c8>
Trace; c013c52e <d_alloc+1a/16c>
Trace; c013c6dc <d_alloc_root+18/3c>
Trace; c01404fe <rootfs_read_super+62/84>
Trace; c0130808 <read_super+90/110>
Trace; c0130c22 <get_sb_nodev+2e/54>
Trace; c0131090 <do_kern_mount+cc/140>
Trace; c0105000 <_stext+0/0>
Code; c0124e5c <kmem_cache_grow+170/300>
00000000 <_EIP>:
Code; c0124e5c <kmem_cache_grow+170/300> <=====
0: c7 00 71 f0 2c 5a movl $0x5a2cf071,(%eax) <=====
Code; c0124e62 <kmem_cache_grow+176/300>
6: 8b 46 18 mov 0x18(%esi),%eax
Code; c0124e64 <kmem_cache_grow+178/300>
9: 8b 4c 24 18 mov 0x18(%esp,1),%ecx
Code; c0124e68 <kmem_cache_grow+17c/300>
d: c7 44 08 fc 71 f0 2c movl $0x2cf071,0xfffffffc(%eax,%ecx,1)
Code; c0124e70 <kmem_cache_grow+184/300>
14: 00

debian:~#
Script done on Sun Feb 24 20:26:21 2002

Turn off CONFIG_X86_WP_WORKS_OK and CONFIG_X86_CMPXCHG. This allows booting using Linux Version 2.4.1.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

        111,111,111 * 111,111,111 = 12,345,678,987,654,321

I'm sure others have asked you before, why do you have an obsession with 2.4.1?

Thanks,
Perplexed.

Later versions, including the current 2.4.18 fail, to mount an initrd. Since I use the same kernel for everything (very small), with different modules as different machines may require, I need a working initrd.

This machine, and several others, require SCSI modules to be installed before the final root file-system is accessible. The last kernels I've tried, 2.2.17 and 2.2.18 find a compressed file-system for initrd, then promptly free it. I end up with a panic can't mount root on 1:0. This is /dev/ram0. I have tried /dev/ram1 (1:1) as well. The kernel recognizes what file-system it should mount, but doesn't. This has been reported on LK several times over the past year. I even provided a script that any interested person can execute to make an 'initrd floppy' to verify that a root file-system can be found and mounted. The only responses I got were things like; "You should use cramfs". I need an ext2 file-system on the RAM Disk. I guess there's no longer any interest in that amongst kernel developers.

Once somebody makes a kernel they has both a working loop device and a working initial RAM Disk, I will use that kernel. In the meantime, I'm stuck at 2.4.1.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

        111,111,111 * 111,111,111 = 12,345,678,987,654,321

Hi

richard> Once somebody makes a kernel they has both a working loop device and richard> a working initial RAM Disk, I will use that kernel. In the meantime, richard> I'm stuck at 2.4.1.

I am not sure what you are doing, and I don't remeber seing your script to reproduce the problem, but I can confirm you that:
- loop device works
- initrd works

We used it for Mandrake kernels, and it works with SCSI without any problems. Could you send me your script to create the intrd to me to take a look?

Later, Juan.

In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

I have a somewhat older beast (Fujitsu Stylistic 1000) which is somewhat older and a little lower spec that I've been playing with a fair bit getting Xfce + scribble etc running on with no problem.

Generally when you get a crash very early you want to check
-CPU type the kernel was built with - your oops isnt an illegal
instruction so thats not it
-Disabling APM support
-Disabling PnpBIOS support (-ac tree only)
-Using mem=fooM where foo is a bit under what is fitted in case
the box lies about memory availability

That generally gets successes. You might also want to do a test boot with mem=6M in case the machine has something funky like a 15-16Mb Vesa local bus magic hole in the address map.

Definitely looks a fun toy

Its booting !!!!

I tried to build a 2.4.1kernel, but it had problems with my newer ld so I tried again with a 2.4.17 following Alans instructions.

I passed mem=6 and it booted. I then expeimented upping this value and it still boots when I pass mem=32m ( the actual amount of ram in the machine ). So I guess it was just a problem of the box lieing about its memory.

Many thanks for all you help, its really appreciated.

-- Matthew Allum