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
>>EIP; c0124e5c <kmem_cache_grow+170/300> <=====
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
On Fri, 1 Mar 2002, Matthew Allum wrote:
> 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;
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
On Fri, 1 Mar 2002, Richard B. Johnson wrote:
> Turn off CONFIG_X86_WP_WORKS_OK and CONFIG_X86_CMPXCHG. This allows
> booting using Linux Version 2.4.1.
I'm sure others have asked you before, why do you have an obsession with 2.4.1?
Thanks,
Perplexed.
> 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'.
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
On Fri, 1 Mar 2002, Zwane Mwaikambo wrote:
> On Fri, 1 Mar 2002, Richard B. Johnson wrote:
>
> > Turn off CONFIG_X86_WP_WORKS_OK and CONFIG_X86_CMPXCHG. This allows
> > booting using Linux Version 2.4.1.
>
> 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
Richard B. Johnson [mailto:[email protected]] wrote:
[... snipped: using 2.4.1 because... ]
> Later versions, including the current 2.4.18 fail, to mount an initrd.
I have successfully used ext2-formatted initrd's with a variety of recent
kernels between 2.4.16 and 2.4.18. The only problem I've ever had is that
when _building_ an initrd, kernels between 2.4.10 and 2.4.18-pre-something
had a bug in the ramdisk driver. This has been fixed in later kernels,
and there is also a workaround for it.
> 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,
My workstation is running a 2.4.18-pre? which successfully mounts CDROM
ISO images on loopback and successfully creates and boots initrd's.
Are you sure this is not something specific to your setup or config?
Torrey Hoffman
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
Alan Cox wrote:
>>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'.
>>
>
>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
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
#!/bin/sh
#
#
export VER=$1
RAMDISK_IMAGE=/tmp/RamImage-${VER}
RAMDISK=/tmp/Ramdisk
TMPC=/tmp/Temp.c
TMPF=/tmp/TmpExe
DISKSIZE=2048
SYS=/usr/src/linux-${VER}/arch/i386/boot/bzImage
if [ "$1" = "" ] ;
then
echo "Usage:"
echo "test_ramdisk <version>"
exit 1
fi
if [ ! -f ${SYS} ] ;
then
echo "File not found, ${SYS}"
exit 1
fi
if ! dd if=/dev/fd0 of=/dev/null bs=1k count=1 2>/dev/null ;
then
echo "Floppy drive error!"
echo "Maybe no diskette in the drive?"
exit 1
fi
#
# Make a little program called modprobe. This just returns 0.
#
echo "int main(){">${TMPC}
echo "return 0;}">>${TMPC}
gcc -O2 -o modprobe ${TMPC} -static
strip modprobe
rm ${TMPC}
#
# Make a little program called init. This just prints a moving message and
# waits forever.
#
echo "#include <stdio.h>">${TMPC}
echo "main(){">>${TMPC}
echo "int r, c;">>${TMPC}
echo "for(;;){">>${TMPC}
echo "r=rand()%25;c=rand()%68;printf(\"\033[%d;%dH Working! \", r, c);">>${TMPC}
echo "fflush(stdout);usleep(500000);">>${TMPC}
echo "printf(\"\033[%d;%dH \",r,c);fflush(stdout);">>${TMPC}
echo "}}">>${TMPC}
gcc -O2 -o init ${TMPC} -static
strip init
rm ${TMPC}
#
# Make a RAM Disk file and mount it using the loop device.
# Remove the lost+found directory to save space.
#
umount ${RAMDISK} 2>/dev/null
rm -rf ${RAMDISK} 2>/dev/null
mkdir ${RAMDISK} 2>/dev/null
dd if=/dev/zero of=${RAMDISK_IMAGE} bs=1k count=${DISKSIZE}
/sbin/mke2fs -Fq ${RAMDISK_IMAGE} ${DISKSIZE}
mount -o loop -t ext2 ${RAMDISK_IMAGE} ${RAMDISK}
rmdir ${RAMDISK}/lost+found
#
# Make the required directories in the RAM Disk.
#
mkdir -m 777 ${RAMDISK}/dev
mkdir -m 777 ${RAMDISK}/etc
mkdir -m 777 ${RAMDISK}/lib
mkdir -m 777 ${RAMDISK}/usr
mkdir -m 777 ${RAMDISK}/usr/local
mkdir -m 777 ${RAMDISK}/bin
mkdir -m 777 ${RAMDISK}/sbin
mkdir -m 777 ${RAMDISK}/tmp
mkdir -m 777 ${RAMDISK}/proc
#
# Make the required devices.
#
mknod ${RAMDISK}/dev/null c 1 3
mknod ${RAMDISK}/dev/ram0 b 1 0
mknod ${RAMDISK}/dev/ram1 b 1 1
mknod ${RAMDISK}/dev/mem c 1 1
mknod ${RAMDISK}/dev/ttyS0 c 4 64
mknod ${RAMDISK}/dev/tty0 c 4 0
mknod ${RAMDISK}/dev/tty1 c 4 1
mknod ${RAMDISK}/dev/tty2 c 4 2
mknod ${RAMDISK}/dev/tty3 c 4 3
mknod ${RAMDISK}/dev/tty4 c 4 4
mknod ${RAMDISK}/dev/tty c 5 0
mknod ${RAMDISK}/dev/ttyp0 c 3 0
mknod ${RAMDISK}/dev/ttyp1 c 3 1
mknod ${RAMDISK}/dev/ttyp2 c 3 2
mknod ${RAMDISK}/dev/ttyp3 c 3 3
mknod ${RAMDISK}/dev/ttyp4 c 3 4
mknod ${RAMDISK}/dev/ttyp5 c 3 5
mknod ${RAMDISK}/dev/ptyp0 c 2 0
mknod ${RAMDISK}/dev/ptyp1 c 2 1
mknod ${RAMDISK}/dev/ptyp2 c 2 2
mknod ${RAMDISK}/dev/ptyp3 c 2 3
mknod ${RAMDISK}/dev/ptyp4 c 2 4
mknod ${RAMDISK}/dev/ptyp5 c 2 5
mknod ${RAMDISK}/dev/zero c 1 5
#
# Set some compatibility links.
#
ln -s /dev/tty0 ${RAMDISK}/dev/systty
ln -s /dev/tty0 ${RAMDISK}/dev/console
ln -s /dev/ram1 ${RAMDISK}/dev/ram
ln -s /lib ${RAMDISK}/usr/lib
ln -s /lib ${RAMDISK}/usr/local/lib
#
#
# Copy the files and libraries. All of the files are stripped
# to save space.
#
cp modprobe ${RAMDISK}/sbin/modprobe
cp init ${RAMDISK}/sbin/init
#
#
# Unmount the RAM Disk. Remove its mount-point but save the file itself.
#
sync
df ${RAMDISK}
umount ${RAMDISK}
rmdir ${RAMDISK}
sync
#
# Make an ext2 file-system on a floppy and mount it. Remove the
# lost+found directory to save space.
#
umount /mnt 2>/dev/null
/sbin/mke2fs -q /dev/fd0
mount -t ext2 /dev/fd0 /mnt
rmdir /mnt/lost+found
#
# Compress the RAM Disk image into a file on the mounted file-system.
# Remove the original RAM Disk image, then copy the required boot
# files to the mounted file-system also.
#
gzip < ${RAMDISK_IMAGE} >/mnt/initrd-${VER}
rm ${RAMDISK_IMAGE}
cp ${SYS} /mnt/vmlinuz-${VER}
cp /boot/boot.b /mnt/boot.b
#
# Now execute lilo to install the boot-loader onto the mounted file-
# system. Lilo allows its configuration to be taken from standard input.
#
/sbin/lilo -C - <<EOF
#
# Lilo boot-configuration script.
#
boot = /dev/fd0
map = /mnt/map
backup = /dev/null
compact
vga = normal # force sane state
install = /mnt/boot.b
image = /mnt/vmlinuz-${VER}
initrd = /mnt/initrd-${VER}
root = /dev/ram0
label = Test-RAMDISK
EOF
#
# Show the results and unmount the file-system.
#
df /dev/fd0
umount /dev/fd0
#
Richard B. Johnson [mailto:[email protected]] wrote:
>This is on 2.4.17. Once I am up, I can build an ext2 file-system ramdisk-
>image. I can mount it though the loop device and I can read/write to
Beware of ramdisks on 2.4.17! This kernel has the bug I mentioned.
It appeared with the new VM in 2.4.10 and was fixed in 2.4.18-pre4.
(I will try out your script on whatever I'm running at the moment.)
The bug has to do with the difference in how the ramdisk driver
allocated (or failed to allocate) pages when accessed directly as
a block device, or indirectly through a filesystem.
For much more detail, search in the archives for a subject line:
"ramdisk corruption problems - was: RE: pivot_root and initrd".
If you must use 2.4.17, the workaround is to dd from /dev/zero to
/dev/ram0 before running mke2fs, thereby "initializing" all the
blocks of the device.
The following is a test script which tickled the bug, with the
workaround.
- - - - - -
#!/bin/bash
# this script assumes /mnt/ramdisk is a valid mountpoint
# ./testdir should have 3-4 MB of reasonably large files.
# freeramdisk is a program that sends the ioctl to deallocate
# the ramdisk. Not needed unless you are running this test
# after already using the ramdisk.
../rootfs/sbin/freeramdisk /dev/ram0
# this dd is the workaround. Leave it out to check for the bug
#dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
mke2fs -m0 /dev/ram0 4000
mount -t ext2 /dev/ram0 /mnt/ramdisk
rm -rf /mnt/ramdisk/*
cp -a ./testdir /mnt/ramdisk
umount /dev/ram0
dd if=/dev/ram0 of=ram0.img bs=1k count=4000
dd if=ram0.img of=/dev/ram0 bs=1k count=4000
mount -t ext2 /dev/ram0 /mnt/ramdisk
# if this diff returns anything, your kernel has the bug.
diff -q -r ./testdir /mnt/ramdisk/testdir
umount /dev/ram0
- - - - - -
Torrey Hoffman
>>>>> "richard" == Richard B Johnson <[email protected]> writes:
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