Compile-kernel

Last Update: 10 April 1999

Compiling Your Own Kernel

This section is an overview, not a tutorial

Before proceeding any further, make sure you have completed the steps listed in the Configuring A Kernel section.

Configuring and compiling the Linux kernel is a task that requires a moderate amount of knowledge and experience. You are not required to compile a kernel of your own, but running a customized kernel has many benefits such as reduced size, increased stability, and probable performance increases.

Please note that all kernel configuration and compile operations assume you are logged in as the root user.

Go to your Linux kernel source directory:

cd /usr/src/linux

After completing the configuration process, you must update dependencies and remove old object files. To do this, simply enter:

make dep ; make clean

Make sure there were no errors during the 'make dep' step.

Now compile the kernel with make. This will require an hour or more (on most Amigas), so take some time to reread a few sections of this install FAQ.

make

After the compile finishes (with no errors of course) you can compress the kernel with gzip, which will decrease the amount of time it takes to load Linux into memory (especially from OFS and AFS disks).

gzip vmlinux

Now copy the resulting vmlinux.gz file to your AFFS disk partition, naming it something like vmlinux-test.

cp vmlinux.gz /dh1/redhat-5.1/post-install/vmlinux-test

Note: /dh1/ is my AFFS partition from where I boot Linux from AmigaDos.

Issue the linux reboot command to restart your system under AmigaDos. Linux, Unix, and NT temporarily cache disk contents to memory to increase system performance. NEVER, NEVER power-down your system without performing an orderly shutdown procedure; otherwise you risk corruption of the disk filesystem. The normal method of shutting Linux down is to enter the command shutdown -h now from a root shell.

Once AmigaDos is up, enter the amiboot command shown in the Post-Install Setup section, substituting your freshly-compiled vmlinux-test file instead of the stock kernel.

/utils/amiboot-5.6 -k vmlinux-test root=<desired dev> video=<desired video mode>

With luck your system should restart under Linux, with a smaller, faster, custom kernel.

You are not done yet!!!

During startup you will probably see several warnings concerning .o files. This is because the symbols in the 'stock' modules do not match your freshly-compiled kernel. To resolve the symbol mismatches and to provide reliable system operation you must recompile the modules:

cd /usr/src/linux

make modules

make modules_install

depmod -a

This will go a lot faster than the kernel compile did.

Now reboot your test (vmlinux-test) system again by typing the reboot and running amiboot as shown above. You should see very few, if any module warnings. If you do, you might want to delete the individual (unused) .o files in the subdirectories below /lib/modules/2.0.3x/ causing the warning(s), and re-execute the depmod -a command.

Make sure you take the time to test everything before deleting any module files.

Hint: If you have enough memory (more than 16-meg) and CPU horsepower (68040 or better), there is a way you can speed up your kernel compiles. About 40 lines into the /usr/src/linux Makefile there is an entry that says:

MAKE = make

Change it to:

MAKE = make -j2

This allows make to launch several concurrent compiles (3 in this case). This makes much more efficient use of system memory since all instances of the compiler can share a single codespace, instead of reloading the compiler over and over. Reduce the number of concurrent compiles if your free-memory fall below 512k or swap starts thrashing. Excessive swap usage can result in ridiculously long compile times (even for an Amiga). You can watch jobs being launched, CPU, and swap utilization by using the top -i command in another VCON, just make sure to renice top (using top's r command) to a value of at least 5 or it will steal too many CPU cycles.

NEVER compile a kernel while running X (X-Windows) because X takes so much memory, and leaves little, if any for the compiler which makes kernel builds even slower.

My 16-meg 68040-33 works best with a value of -j2, but my 128-meg K6-233 can handle values high as -j40.

Some common m68k kernel-module issues:

Startup message: modprobe: can't locate module net-pf-4 and modprobe: can't locate module net-pf-5:

These will appear if you disable IPX support in the kernel (which is why the modules can't be found, of course). The simple solution is to add two new lines at the end of the file /etc/conf.modules:

alias net-pf-4 off alias net-pf-5 off

Kernel compile times for several of my machines

2.0 series kernels

Machine	Arch	CPU	Speed	RAM	Makefile '-j'	min:sec	* response	version	remarks
Lurker	m68k	Moto 68040	25Mhz	16Mb	-j2	110:55	69,063	2.0.36	Stock A4000
Sidekick	m68k	Moto 68040	33Mhz	16Mb	-j2	48:06	93,000	2.0.36	A2000, GVP Gforce
Segfault	Alpha	DEC 21164	166Mhz	64Mb	-j6	40:41	170,716	2.0.35	Dec Multia
Glitch	x86	486-DX2	66Mhz	24Mb	-j3	37:41	125,230	2.0.36	Linux 'loaner'
Thingy	x86	486-DX4	100Mhz	32Mb	-j6	26:53	44,950	2.0.36	my brothers system
Retry	x86	P5	70Mhz	40Mb	-j6	8:32	235,255	2.0.33	AST 950N Laptop
Byclops	x86	P5-MMX	200Mhz	96Mb	-j24	4:30	-,-	2.0.35	Dual Pentium
Spareparts	x86	AMD K6-2	350Mhz	128Mb	-j50	3:05	880,000	2.0.36	PC-100

2.2 series kernels

Machine	Arch	CPU	Speed	RAM	Makefile '-j'	min:sec	* response	version	remarks
Lurker	m68k	Moto 68040	25Mhz	16Mb	-j2	2:45:22	69,063	2.2.1pre2	Stock A4000
Spareparts	x86	AMD K6-2	350Mhz	256Mb	-j10	5:52	1,604,000	2.2.5-ac6	PC-100

* Kernel response. I wrote a little C++ program that determines how often I can call the time() kernel-function per second, and calculate the average time for all the samples thus far (for n <= 100). This test provides a comparative performance value of the system and kernel. These values are indicated in the above table. The value listed is the average of at least 120 samples. This program has been updated to calculate tight-loop and network-stack throughput.