1
by Tim Gardner, Colin Ian King, David Henningsson, Seth Forshee, Tim Gardner
[ Colin Ian King ] |
1 |
Linux kernel release 3.x <http://kernel.org/> |
2 |
||
3 |
These are the release notes for Linux version 3. Read them carefully, |
|
4 |
as they tell you what this is all about, explain how to install the |
|
5 |
kernel, and what to do if something goes wrong. |
|
6 |
||
7 |
WHAT IS LINUX? |
|
8 |
||
9 |
Linux is a clone of the operating system Unix, written from scratch by |
|
10 |
Linus Torvalds with assistance from a loosely-knit team of hackers across |
|
11 |
the Net. It aims towards POSIX and Single UNIX Specification compliance. |
|
12 |
||
13 |
It has all the features you would expect in a modern fully-fledged Unix, |
|
14 |
including true multitasking, virtual memory, shared libraries, demand |
|
15 |
loading, shared copy-on-write executables, proper memory management, |
|
16 |
and multistack networking including IPv4 and IPv6. |
|
17 |
||
18 |
It is distributed under the GNU General Public License - see the |
|
19 |
accompanying COPYING file for more details. |
|
20 |
||
21 |
ON WHAT HARDWARE DOES IT RUN? |
|
22 |
||
23 |
Although originally developed first for 32-bit x86-based PCs (386 or higher), |
|
24 |
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and |
|
25 |
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, |
|
26 |
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, |
|
27 |
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures. |
|
28 |
||
29 |
Linux is easily portable to most general-purpose 32- or 64-bit architectures |
|
30 |
as long as they have a paged memory management unit (PMMU) and a port of the |
|
31 |
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has |
|
32 |
also been ported to a number of architectures without a PMMU, although |
|
33 |
functionality is then obviously somewhat limited. |
|
34 |
Linux has also been ported to itself. You can now run the kernel as a |
|
35 |
userspace application - this is called UserMode Linux (UML). |
|
36 |
||
37 |
DOCUMENTATION: |
|
38 |
||
39 |
- There is a lot of documentation available both in electronic form on |
|
40 |
the Internet and in books, both Linux-specific and pertaining to |
|
41 |
general UNIX questions. I'd recommend looking into the documentation |
|
42 |
subdirectories on any Linux FTP site for the LDP (Linux Documentation |
|
43 |
Project) books. This README is not meant to be documentation on the |
|
44 |
system: there are much better sources available. |
|
45 |
||
46 |
- There are various README files in the Documentation/ subdirectory: |
|
47 |
these typically contain kernel-specific installation notes for some |
|
48 |
drivers for example. See Documentation/00-INDEX for a list of what |
|
49 |
is contained in each file. Please read the Changes file, as it |
|
50 |
contains information about the problems, which may result by upgrading |
|
51 |
your kernel. |
|
52 |
||
53 |
- The Documentation/DocBook/ subdirectory contains several guides for |
|
54 |
kernel developers and users. These guides can be rendered in a |
|
55 |
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others. |
|
56 |
After installation, "make psdocs", "make pdfdocs", "make htmldocs", |
|
57 |
or "make mandocs" will render the documentation in the requested format. |
|
58 |
||
59 |
INSTALLING the kernel source: |
|
60 |
||
61 |
- If you install the full sources, put the kernel tarball in a |
|
62 |
directory where you have permissions (eg. your home directory) and |
|
63 |
unpack it: |
|
64 |
||
65 |
gzip -cd linux-3.X.tar.gz | tar xvf - |
|
66 |
||
67 |
or
|
|
68 |
bzip2 -dc linux-3.X.tar.bz2 | tar xvf - |
|
69 |
||
70 |
||
71 |
Replace "XX" with the version number of the latest kernel. |
|
72 |
||
73 |
Do NOT use the /usr/src/linux area! This area has a (usually |
|
74 |
incomplete) set of kernel headers that are used by the library header |
|
75 |
files. They should match the library, and not get messed up by |
|
76 |
whatever the kernel-du-jour happens to be. |
|
77 |
||
78 |
- You can also upgrade between 3.x releases by patching. Patches are |
|
79 |
distributed in the traditional gzip and the newer bzip2 format. To |
|
80 |
install by patching, get all the newer patch files, enter the |
|
81 |
top level directory of the kernel source (linux-3.x) and execute: |
|
82 |
||
83 |
gzip -cd ../patch-3.x.gz | patch -p1 |
|
84 |
||
85 |
or
|
|
86 |
bzip2 -dc ../patch-3.x.bz2 | patch -p1 |
|
87 |
||
88 |
(repeat xx for all versions bigger than the version of your current |
|
89 |
source tree, _in_order_) and you should be ok. You may want to remove |
|
90 |
the backup files (xxx~ or xxx.orig), and make sure that there are no |
|
91 |
failed patches (xxx# or xxx.rej). If there are, either you or me has |
|
92 |
made a mistake. |
|
93 |
||
94 |
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels |
|
95 |
(also known as the -stable kernels) are not incremental but instead apply |
|
96 |
directly to the base 3.x kernel. Please read |
|
97 |
Documentation/applying-patches.txt for more information. |
|
98 |
||
99 |
Alternatively, the script patch-kernel can be used to automate this |
|
100 |
process. It determines the current kernel version and applies any |
|
101 |
patches found. |
|
102 |
||
103 |
linux/scripts/patch-kernel linux |
|
104 |
||
105 |
The first argument in the command above is the location of the |
|
106 |
kernel source. Patches are applied from the current directory, but |
|
107 |
an alternative directory can be specified as the second argument. |
|
108 |
||
109 |
- If you are upgrading between releases using the stable series patches |
|
110 |
(for example, patch-3.x.y), note that these "dot-releases" are |
|
111 |
not incremental and must be applied to the 3.x base tree. For |
|
112 |
example, if your base kernel is 3.0 and you want to apply the |
|
113 |
3.0.3 patch, you do not and indeed must not first apply the |
|
114 |
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel |
|
115 |
version 3.0.2 and want to jump to 3.0.3, you must first |
|
116 |
reverse the 3.0.2 patch (that is, patch -R) _before_ applying |
|
117 |
the 3.0.3 patch. |
|
118 |
You can read more on this in Documentation/applying-patches.txt |
|
119 |
||
120 |
- Make sure you have no stale .o files and dependencies lying around: |
|
121 |
||
122 |
cd linux |
|
123 |
make mrproper |
|
124 |
||
125 |
You should now have the sources correctly installed. |
|
126 |
||
127 |
SOFTWARE REQUIREMENTS |
|
128 |
||
129 |
Compiling and running the 3.x kernels requires up-to-date |
|
130 |
versions of various software packages. Consult |
|
131 |
Documentation/Changes for the minimum version numbers required |
|
132 |
and how to get updates for these packages. Beware that using |
|
133 |
excessively old versions of these packages can cause indirect |
|
134 |
errors that are very difficult to track down, so don't assume that |
|
135 |
you can just update packages when obvious problems arise during |
|
136 |
build or operation. |
|
137 |
||
138 |
BUILD directory for the kernel: |
|
139 |
||
140 |
When compiling the kernel all output files will per default be |
|
141 |
stored together with the kernel source code. |
|
142 |
Using the option "make O=output/dir" allow you to specify an alternate |
|
143 |
place for the output files (including .config). |
|
144 |
Example: |
|
145 |
kernel source code: /usr/src/linux-3.N |
|
146 |
build directory: /home/name/build/kernel |
|
147 |
||
148 |
To configure and build the kernel use: |
|
149 |
cd /usr/src/linux-3.N |
|
150 |
make O=/home/name/build/kernel menuconfig |
|
151 |
make O=/home/name/build/kernel |
|
152 |
sudo make O=/home/name/build/kernel modules_install install |
|
153 |
||
154 |
Please note: If the 'O=output/dir' option is used then it must be |
|
155 |
used for all invocations of make. |
|
156 |
||
157 |
CONFIGURING the kernel: |
|
158 |
||
159 |
Do not skip this step even if you are only upgrading one minor |
|
160 |
version. New configuration options are added in each release, and |
|
161 |
odd problems will turn up if the configuration files are not set up |
|
162 |
as expected. If you want to carry your existing configuration to a |
|
163 |
new version with minimal work, use "make oldconfig", which will |
|
164 |
only ask you for the answers to new questions. |
|
165 |
||
166 |
- Alternate configuration commands are: |
|
167 |
"make config" Plain text interface. |
|
168 |
"make menuconfig" Text based color menus, radiolists & dialogs. |
|
169 |
"make nconfig" Enhanced text based color menus. |
|
170 |
"make xconfig" X windows (Qt) based configuration tool. |
|
171 |
"make gconfig" X windows (Gtk) based configuration tool. |
|
172 |
"make oldconfig" Default all questions based on the contents of |
|
173 |
your existing ./.config file and asking about |
|
174 |
new config symbols. |
|
175 |
"make silentoldconfig"
|
|
176 |
Like above, but avoids cluttering the screen |
|
177 |
with questions already answered. |
|
178 |
Additionally updates the dependencies. |
|
179 |
"make defconfig" Create a ./.config file by using the default |
|
180 |
symbol values from either arch/$ARCH/defconfig |
|
181 |
or arch/$ARCH/configs/${PLATFORM}_defconfig, |
|
182 |
depending on the architecture. |
|
183 |
"make ${PLATFORM}_defconfig"
|
|
184 |
Create a ./.config file by using the default |
|
185 |
symbol values from |
|
186 |
arch/$ARCH/configs/${PLATFORM}_defconfig. |
|
187 |
Use "make help" to get a list of all available |
|
188 |
platforms of your architecture. |
|
189 |
"make allyesconfig"
|
|
190 |
Create a ./.config file by setting symbol |
|
191 |
values to 'y' as much as possible. |
|
192 |
"make allmodconfig"
|
|
193 |
Create a ./.config file by setting symbol |
|
194 |
values to 'm' as much as possible. |
|
195 |
"make allnoconfig" Create a ./.config file by setting symbol |
|
196 |
values to 'n' as much as possible. |
|
197 |
"make randconfig" Create a ./.config file by setting symbol |
|
198 |
values to random values. |
|
199 |
||
200 |
You can find more information on using the Linux kernel config tools |
|
201 |
in Documentation/kbuild/kconfig.txt. |
|
202 |
||
203 |
NOTES on "make config": |
|
204 |
- having unnecessary drivers will make the kernel bigger, and can |
|
205 |
under some circumstances lead to problems: probing for a |
|
206 |
nonexistent controller card may confuse your other controllers |
|
207 |
- compiling the kernel with "Processor type" set higher than 386 |
|
208 |
will result in a kernel that does NOT work on a 386. The |
|
209 |
kernel will detect this on bootup, and give up. |
|
210 |
- A kernel with math-emulation compiled in will still use the |
|
211 |
coprocessor if one is present: the math emulation will just |
|
212 |
never get used in that case. The kernel will be slightly larger, |
|
213 |
but will work on different machines regardless of whether they |
|
214 |
have a math coprocessor or not. |
|
215 |
- the "kernel hacking" configuration details usually result in a |
|
216 |
bigger or slower kernel (or both), and can even make the kernel |
|
217 |
less stable by configuring some routines to actively try to |
|
218 |
break bad code to find kernel problems (kmalloc()). Thus you |
|
219 |
should probably answer 'n' to the questions for |
|
220 |
"development", "experimental", or "debugging" features. |
|
221 |
||
222 |
COMPILING the kernel: |
|
223 |
||
224 |
- Make sure you have at least gcc 3.2 available. |
|
225 |
For more information, refer to Documentation/Changes. |
|
226 |
||
227 |
Please note that you can still run a.out user programs with this kernel. |
|
228 |
||
229 |
- Do a "make" to create a compressed kernel image. It is also |
|
230 |
possible to do "make install" if you have lilo installed to suit the |
|
231 |
kernel makefiles, but you may want to check your particular lilo setup first. |
|
232 |
||
233 |
To do the actual install you have to be root, but none of the normal |
|
234 |
build should require that. Don't take the name of root in vain. |
|
235 |
||
236 |
- If you configured any of the parts of the kernel as `modules', you |
|
237 |
will also have to do "make modules_install". |
|
238 |
||
239 |
- Verbose kernel compile/build output: |
|
240 |
||
241 |
Normally the kernel build system runs in a fairly quiet mode (but not |
|
242 |
totally silent). However, sometimes you or other kernel developers need |
|
243 |
to see compile, link, or other commands exactly as they are executed. |
|
244 |
For this, use "verbose" build mode. This is done by inserting |
|
245 |
"V=1" in the "make" command. E.g.: |
|
246 |
||
247 |
make V=1 all |
|
248 |
||
249 |
To have the build system also tell the reason for the rebuild of each |
|
250 |
target, use "V=2". The default is "V=0". |
|
251 |
||
252 |
- Keep a backup kernel handy in case something goes wrong. This is |
|
253 |
especially true for the development releases, since each new release |
|
254 |
contains new code which has not been debugged. Make sure you keep a |
|
255 |
backup of the modules corresponding to that kernel, as well. If you |
|
256 |
are installing a new kernel with the same version number as your |
|
257 |
working kernel, make a backup of your modules directory before you |
|
258 |
do a "make modules_install". |
|
259 |
Alternatively, before compiling, use the kernel config option |
|
260 |
"LOCALVERSION" to append a unique suffix to the regular kernel version. |
|
261 |
LOCALVERSION can be set in the "General Setup" menu. |
|
262 |
||
263 |
- In order to boot your new kernel, you'll need to copy the kernel |
|
264 |
image (e.g. .../linux/arch/i386/boot/bzImage after compilation) |
|
265 |
to the place where your regular bootable kernel is found. |
|
266 |
||
267 |
- Booting a kernel directly from a floppy without the assistance of a |
|
268 |
bootloader such as LILO, is no longer supported. |
|
269 |
||
270 |
If you boot Linux from the hard drive, chances are you use LILO which |
|
271 |
uses the kernel image as specified in the file /etc/lilo.conf. The |
|
272 |
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or |
|
273 |
/boot/bzImage. To use the new kernel, save a copy of the old image |
|
274 |
and copy the new image over the old one. Then, you MUST RERUN LILO |
|
275 |
to update the loading map!! If you don't, you won't be able to boot |
|
276 |
the new kernel image. |
|
277 |
||
278 |
Reinstalling LILO is usually a matter of running /sbin/lilo. |
|
279 |
You may wish to edit /etc/lilo.conf to specify an entry for your |
|
280 |
old kernel image (say, /vmlinux.old) in case the new one does not |
|
281 |
work. See the LILO docs for more information. |
|
282 |
||
283 |
After reinstalling LILO, you should be all set. Shutdown the system, |
|
284 |
reboot, and enjoy! |
|
285 |
||
286 |
If you ever need to change the default root device, video mode, |
|
287 |
ramdisk size, etc. in the kernel image, use the 'rdev' program (or |
|
288 |
alternatively the LILO boot options when appropriate). No need to |
|
289 |
recompile the kernel to change these parameters. |
|
290 |
||
291 |
- Reboot with the new kernel and enjoy. |
|
292 |
||
293 |
IF SOMETHING GOES WRONG: |
|
294 |
||
295 |
- If you have problems that seem to be due to kernel bugs, please check |
|
296 |
the file MAINTAINERS to see if there is a particular person associated |
|
297 |
with the part of the kernel that you are having trouble with. If there |
|
298 |
isn't anyone listed there, then the second best thing is to mail |
|
299 |
them to me (torvalds@linux-foundation.org), and possibly to any other |
|
300 |
relevant mailing-list or to the newsgroup. |
|
301 |
||
302 |
- In all bug-reports, *please* tell what kernel you are talking about, |
|
303 |
how to duplicate the problem, and what your setup is (use your common |
|
304 |
sense). If the problem is new, tell me so, and if the problem is |
|
305 |
old, please try to tell me when you first noticed it. |
|
306 |
||
307 |
- If the bug results in a message like |
|
308 |
||
309 |
unable to handle kernel paging request at address C0000010 |
|
310 |
Oops: 0002 |
|
311 |
EIP: 0010:XXXXXXXX |
|
312 |
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx |
|
313 |
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx |
|
314 |
ds: xxxx es: xxxx fs: xxxx gs: xxxx |
|
315 |
Pid: xx, process nr: xx |
|
316 |
xx xx xx xx xx xx xx xx xx xx |
|
317 |
||
318 |
or similar kernel debugging information on your screen or in your |
|
319 |
system log, please duplicate it *exactly*. The dump may look |
|
320 |
incomprehensible to you, but it does contain information that may |
|
321 |
help debugging the problem. The text above the dump is also |
|
322 |
important: it tells something about why the kernel dumped code (in |
|
323 |
the above example it's due to a bad kernel pointer). More information |
|
324 |
on making sense of the dump is in Documentation/oops-tracing.txt |
|
325 |
||
326 |
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump |
|
327 |
as is, otherwise you will have to use the "ksymoops" program to make |
|
328 |
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). |
|
329 |
This utility can be downloaded from |
|
330 |
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ . |
|
331 |
Alternately you can do the dump lookup by hand: |
|
332 |
||
333 |
- In debugging dumps like the above, it helps enormously if you can |
|
334 |
look up what the EIP value means. The hex value as such doesn't help |
|
335 |
me or anybody else very much: it will depend on your particular |
|
336 |
kernel setup. What you should do is take the hex value from the EIP |
|
337 |
line (ignore the "0010:"), and look it up in the kernel namelist to |
|
338 |
see which kernel function contains the offending address. |
|
339 |
||
340 |
To find out the kernel function name, you'll need to find the system |
|
341 |
binary associated with the kernel that exhibited the symptom. This is |
|
342 |
the file 'linux/vmlinux'. To extract the namelist and match it against |
|
343 |
the EIP from the kernel crash, do: |
|
344 |
||
345 |
nm vmlinux | sort | less |
|
346 |
||
347 |
This will give you a list of kernel addresses sorted in ascending |
|
348 |
order, from which it is simple to find the function that contains the |
|
349 |
offending address. Note that the address given by the kernel |
|
350 |
debugging messages will not necessarily match exactly with the |
|
351 |
function addresses (in fact, that is very unlikely), so you can't |
|
352 |
just 'grep' the list: the list will, however, give you the starting |
|
353 |
point of each kernel function, so by looking for the function that |
|
354 |
has a starting address lower than the one you are searching for but |
|
355 |
is followed by a function with a higher address you will find the one |
|
356 |
you want. In fact, it may be a good idea to include a bit of |
|
357 |
"context" in your problem report, giving a few lines around the |
|
358 |
interesting one. |
|
359 |
||
360 |
If you for some reason cannot do the above (you have a pre-compiled |
|
361 |
kernel image or similar), telling me as much about your setup as |
|
362 |
possible will help. Please read the REPORTING-BUGS document for details. |
|
363 |
||
364 |
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you |
|
365 |
cannot change values or set break points.) To do this, first compile the |
|
366 |
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make |
|
367 |
clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). |
|
368 |
||
369 |
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore". |
|
370 |
You can now use all the usual gdb commands. The command to look up the |
|
371 |
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes |
|
372 |
with the EIP value.) |
|
373 |
||
374 |
gdb'ing a non-running kernel currently fails because gdb (wrongly) |
|
375 |
disregards the starting offset for which the kernel is compiled. |
|
376 |