Linux kernel release 0.99 patchlevel 11 These are the release notes for linux version 0.99.11. Read them carefully, as they explain how to install the kernel, and what to do if something goes wrong. CHANGES since 0.99 patchlevel 10 and earlier: - The keyboard is dynamically changeable (this is true of pl10 as well), and you need to get the "keytables.tar.z" archive to set the keyboard to suit your taske unless you want to live with the default US keymaps. Use the "loadkeys map/xxx.map" command to load the keyboard map: you can edit the maps to suit yourself if you can't find a suitable one. The syntax of the keyboard maps should be obvious after looking at the examples. - The memory manager has been cleaned up substantially, and mmap() works for MAP_PRIVATE. MAP_SHARED is still not supported for anything else than /dev/mem, but even so it actually is usable for a lot of applications. The shared library routines have been rewritten to use mmap() instead of the old hardcoded behaviour. - The kernel is now compiled with C++ instead of plain C. Very few actual C++ features are used, but even so C++ allows for more type-checking and type-safe linkage. - The filesystem routines have been cleaned up for multiple block sizes. None of the filesystems use it yet, but people are working on it. - named pipes and normal pipes should hopefully have the right select() semantics in the presense/absense of writers. - QIC-02 tape driver by Hennus Bergman - selection patches in the default kernel - fixed a bug in the pty code which led to busy waiting in some circumstances instead of sleeping. - Compressed SLIP support (Charles Hedrick). See net/inet/CONFIG INTERNAL kernel changes: - the 'clear_bit()' function was changed to return the previous setting of the bit instead of the old "error-code". This makes use of the bit operations more logical. - udelay() function for short delays (busy-waiting) added. Used currently only by the QIC driver. - fork() and sheduler changes to make task switches happen only from kernel mode to kernel mode. Cleaner and more portable than the old code which counted on being able to task-switch directly into user mode. - debugging malloc code. INSTALLING the kernel: - if you install by patching, you need a *clean* 0.99.10 source tree, which presumably exists in /usr/src/linux. If so, to get the kernel patched, just do a cd /usr/src patch -p0 < linux-0.99.patch11 and you should be ok. You may want to remove the backup files (xxx~ or xxx.orig), and make sure that there are no failed patches (xxx# or xxx.rej). - If you install the full sources, do a cd /usr/src tar xvf linux-0.99.11.tar to get it all put in place. - make sure your /usr/include/linux and /usr/include/asm directories are just symlinks to the kernel sources: cd /usr/include rm -rf linux rm -rf asm ln -s /usr/src/linux/include/linux . ln -s /usr/src/linux/include/asm . - make sure you have no stale .o files and dependencies lying around: cd /usr/src/linux make mrproper make dep You should now have the sources correctly installed. CONFIGURING the kernel: - do a "make config" to configure the basic kernel. "make config" needs bash to work: it will search for bash in $BASH, /bin/bash and /bin/sh (in that order), so hopefully one of those is correct. - edit net/inet/CONFIG to configure the networking parts of the kernel. The comments should hopefully clarify it all. - Check the top Makefile for further site-dependent configuration (default SVGA mode etc). COMPILING the kernel: - make sure you have gcc-2.4.3 or newer available with g++. It seems older gcc versions can have problems compiling linux 0.99.10 and newer versions. If you upgrade, remember to get the new binutils package too (for as/ld/nm and company) - do a "make zImage" to create a compressed kernel image. If you want to make a bootdisk (without root filesystem or lilo), insert a floppy in your A: drive, and do a "make zdisk". It is also possible to do "make zlilo" if you have lilo installed to suit the kernel makefiles, but you may want to check your particular lilo setup first. - keep a backup kernel handy in case something goes wrong. - reboot with the new kernel. IF SOMETHING GOES WRONG: - if you have problems that seem to be due to kernel bugs, please mail them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other relevant mailing-list or to the newsgroup. The mailing-lists are useful especially for SCSI and NETworking problems, as I can't test either of those personally anyway. - In all bug-reports, *please* tell what kernel you are talking about, how to duplicate the problem, and what your setup is (use your common sense). If the problem is new, tell me so, and if the problem is old, please try to tell me when you first noticed it. - if the bug results in a message like unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:xxxxxxxx eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx or similar kernel debugging information on your screen or in your system log, please duplicate it *exactly*. The dump may look incomprehensible to you, but it does contain information that may help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in the above example it's due to a bad kernel pointer) - in debugging dumps like the above, it helps enourmously if you can look up what the EIP value means. The hex value as such doesn't help me or anybody else very much: it will depend on your particular kernel setup. What you should do is take the hex value from the EIP line (ignore the "0010:"), and look it up in the kernel namelist to see which kernel function contains the offending address. To find out the kernel function name, you'll need to find the system binary associated with the kernel that exhibited the symptom. In the case of compressed kernels, this will be 'linux/tools/zSystem', while uncompressed kernels use the file 'tools/system'. To extract the namelist and match it against the EIP from the kernel crash, do: nm tools/zSystem | sort | less This will give you a list of kernel addresses sorted in ascending order, from which it is simple to find the function that contains the offending address. Note that the address given by the kernel debugging messages will not necessarily match exactly with the function addresses (in fact, that is very unlikely), so you can't just 'grep' the list: the list will, however, give you the starting point of each kernel function, so by looking for the function that has a starting address lower than the one you are searching for but is followed by a function with a higher address you will find the one you want. In fact, it may be a good idea to include a bit of "context" in your problem report, giving a few lines around the interesting one. If you for some reason cannot do the above (you have a pre-compiled kernel image or similar), telling me as much about your setup as possible will help.