ELKS BUGS

This is a list of reported bugs with ELKS, together with the current status thereof.

As and when you discover new bugs, please report them to the ELKS Bugzilla System on the ELKS website. This file will be updated from there.

CONTENTS

  1. Bugs reported prior to June 2001 that may not still exist.

  2. Latest Bugs.

  1. Bugs reported prior to June 2001 that may or may not still exist.

    The ELKS source tree contained details of the following bugs when the bug reporting system was moved over to HTML format in June 2001:

      This is a list of things I have noticed go wrong. Please submit additions to this file if you find any kernel related bugs.

      Al Riddoch

    1. Sometimes unmounting a non-root filesystem returns EBUSY when nothing is using, and nothing seems to rectify it.

      On 26th March 2001, Thomas McWilliam reported that his bugfix for this bug had finally been committed to the ELKS development tree.

    2. Sometimes for no aparent reason the umount command gives a STACK collided with BSS error without unmounting the filesystem.

    3. Deleting data from the filesystem results almost always with a "Deleting block not in data zone" type error message, and sometimes crashes.

      This seems to be due to the following line in V1_trunc_direct

      	-               p = i + inode->u.minix_i.u.i1_data;
	+               p = inode->i_zone[i];

      The botton version being the ELKS version, the top one is the Linux version. The two don't seem to bear any relation to each other. This has now nearly been fixed by chenging the above line to

      			p = &inode->i_zone[i];

      But blocks are still not freed when the fs is checked later, and neither is the inode! Looking through truncate.c, and minix_free_block, there is heavy use of longs which are just not necessary.

      Fixed excessive use of longs, and got fs to the stage where some blocks are freed, and deleting large files no longer results in a system crash.

    4. Adding register variables to schedule causes the chq wait queue to get corrupted.

      See comments at the top of schedule() in kernel/sched.c. I occasionly get the same wait_queue corruption message when heavily testing the multitasking.

    5. Shell sometimes reports "No such file or directory" when it means "Out of memory".

    6. Long command lines cause programs to crash.

      When copying files from the /bin directory of a floppy onto the harddisk when installing, the cp process often crashes before it has finished and frequently displays unexpected behavoir. This could be because there is a problem dealing with command lines of more than a couple of hundred bytes, or it could be a problem that comes up after copying lots of data between files. The bug occurs irespective of whether the commandline was typed in by hand, or automacally constructed using wildcards.

  2. Recent Bugs

    The following bugs have been reported since 1st June 2001:

    1. 24th June 2001: Signals not checked when needed.

      Currently signals are only checked when returning from system calls. They should also be checked when returning from a context switch.

      Consider an ELKS program containing this infinite loop:

      	for (;;) {
		i++;
	}

      There is no way that this program can be interrupted. Hitting Control-C will not work. No system calls are made, so the signal is never received. The program will run forever.

      What *should* happen is that the kernel *also* checks for signals on return from a context switch, then eventually the signal will be received.

      Thomas McWilliams

This document was last updated on 13th August 2001.