Contents of /alx-src/trunk/kernel26-alx/linux/README
Parent Directory | Revision Log
Revision 628 -
(show annotations)
(download)
Wed Mar 4 10:48:58 2009 UTC (15 years, 6 months ago) by niro
File size: 13970 byte(s)
Wed Mar 4 10:48:58 2009 UTC (15 years, 6 months ago) by niro
File size: 13970 byte(s)
import linux sources based on 2.6.12-alx-r9: -using linux-2.6.12.6 -using 2.6.12-ck6 patch set -using fbsplash-0.9.2-r3 -using vesafb-tng-0.9-rc7 -using squashfs-2.2 -added cddvd-cmdfilter-drop.patch as ck dropped it -added via-epia-dri (cle266) patch -added zd1211-svn-32 wlan driver (http://zd1211.ath.cx/download/) -added debian patches to zd1211 for wep256 etc
1 | Linux kernel release 2.6.xx |
2 | |
3 | These are the release notes for Linux version 2.6. 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 Unix clone written from scratch by Linus Torvalds with |
10 | assistance from a loosely-knit team of hackers across the Net. |
11 | It aims towards POSIX compliance. |
12 | |
13 | It has all the features you would expect in a modern fully-fledged |
14 | Unix, including true multitasking, virtual memory, shared libraries, |
15 | demand loading, shared copy-on-write executables, proper memory |
16 | management and TCP/IP networking. |
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 | Linux was first developed for 386/486-based PCs. These days it also |
24 | runs on ARMs, DEC Alphas, SUN Sparcs, M68000 machines (like Atari and |
25 | Amiga), MIPS and PowerPC, and others. |
26 | |
27 | DOCUMENTATION: |
28 | |
29 | - There is a lot of documentation available both in electronic form on |
30 | the Internet and in books, both Linux-specific and pertaining to |
31 | general UNIX questions. I'd recommend looking into the documentation |
32 | subdirectories on any Linux FTP site for the LDP (Linux Documentation |
33 | Project) books. This README is not meant to be documentation on the |
34 | system: there are much better sources available. |
35 | |
36 | - There are various README files in the Documentation/ subdirectory: |
37 | these typically contain kernel-specific installation notes for some |
38 | drivers for example. See Documentation/00-INDEX for a list of what |
39 | is contained in each file. Please read the Changes file, as it |
40 | contains information about the problems, which may result by upgrading |
41 | your kernel. |
42 | |
43 | - The Documentation/DocBook/ subdirectory contains several guides for |
44 | kernel developers and users. These guides can be rendered in a |
45 | number of formats: PostScript (.ps), PDF, and HTML, among others. |
46 | After installation, "make psdocs", "make pdfdocs", or "make htmldocs" |
47 | will render the documentation in the requested format. |
48 | |
49 | INSTALLING the kernel: |
50 | |
51 | - If you install the full sources, put the kernel tarball in a |
52 | directory where you have permissions (eg. your home directory) and |
53 | unpack it: |
54 | |
55 | gzip -cd linux-2.6.XX.tar.gz | tar xvf - |
56 | |
57 | Replace "XX" with the version number of the latest kernel. |
58 | |
59 | Do NOT use the /usr/src/linux area! This area has a (usually |
60 | incomplete) set of kernel headers that are used by the library header |
61 | files. They should match the library, and not get messed up by |
62 | whatever the kernel-du-jour happens to be. |
63 | |
64 | - You can also upgrade between 2.6.xx releases by patching. Patches are |
65 | distributed in the traditional gzip and the new bzip2 format. To |
66 | install by patching, get all the newer patch files, enter the |
67 | top level directory of the kernel source (linux-2.6.xx) and execute: |
68 | |
69 | gzip -cd ../patch-2.6.xx.gz | patch -p1 |
70 | |
71 | or |
72 | bzip2 -dc ../patch-2.6.xx.bz2 | patch -p1 |
73 | |
74 | (repeat xx for all versions bigger than the version of your current |
75 | source tree, _in_order_) and you should be ok. You may want to remove |
76 | the backup files (xxx~ or xxx.orig), and make sure that there are no |
77 | failed patches (xxx# or xxx.rej). If there are, either you or me has |
78 | made a mistake. |
79 | |
80 | Alternatively, the script patch-kernel can be used to automate this |
81 | process. It determines the current kernel version and applies any |
82 | patches found. |
83 | |
84 | linux/scripts/patch-kernel linux |
85 | |
86 | The first argument in the command above is the location of the |
87 | kernel source. Patches are applied from the current directory, but |
88 | an alternative directory can be specified as the second argument. |
89 | |
90 | - Make sure you have no stale .o files and dependencies lying around: |
91 | |
92 | cd linux |
93 | make mrproper |
94 | |
95 | You should now have the sources correctly installed. |
96 | |
97 | SOFTWARE REQUIREMENTS |
98 | |
99 | Compiling and running the 2.6.xx kernels requires up-to-date |
100 | versions of various software packages. Consult |
101 | Documentation/Changes for the minimum version numbers required |
102 | and how to get updates for these packages. Beware that using |
103 | excessively old versions of these packages can cause indirect |
104 | errors that are very difficult to track down, so don't assume that |
105 | you can just update packages when obvious problems arise during |
106 | build or operation. |
107 | |
108 | BUILD directory for the kernel: |
109 | |
110 | When compiling the kernel all output files will per default be |
111 | stored together with the kernel source code. |
112 | Using the option "make O=output/dir" allow you to specify an alternate |
113 | place for the output files (including .config). |
114 | Example: |
115 | kernel source code: /usr/src/linux-2.6.N |
116 | build directory: /home/name/build/kernel |
117 | |
118 | To configure and build the kernel use: |
119 | cd /usr/src/linux-2.6.N |
120 | make O=/home/name/build/kernel menuconfig |
121 | make O=/home/name/build/kernel |
122 | sudo make O=/home/name/build/kernel modules_install install |
123 | |
124 | Please note: If the 'O=output/dir' option is used then it must be |
125 | used for all invocations of make. |
126 | |
127 | CONFIGURING the kernel: |
128 | |
129 | Do not skip this step even if you are only upgrading one minor |
130 | version. New configuration options are added in each release, and |
131 | odd problems will turn up if the configuration files are not set up |
132 | as expected. If you want to carry your existing configuration to a |
133 | new version with minimal work, use "make oldconfig", which will |
134 | only ask you for the answers to new questions. |
135 | |
136 | - Alternate configuration commands are: |
137 | "make menuconfig" Text based color menus, radiolists & dialogs. |
138 | "make xconfig" X windows (Qt) based configuration tool. |
139 | "make gconfig" X windows (Gtk) based configuration tool. |
140 | "make oldconfig" Default all questions based on the contents of |
141 | your existing ./.config file. |
142 | |
143 | NOTES on "make config": |
144 | - having unnecessary drivers will make the kernel bigger, and can |
145 | under some circumstances lead to problems: probing for a |
146 | nonexistent controller card may confuse your other controllers |
147 | - compiling the kernel with "Processor type" set higher than 386 |
148 | will result in a kernel that does NOT work on a 386. The |
149 | kernel will detect this on bootup, and give up. |
150 | - A kernel with math-emulation compiled in will still use the |
151 | coprocessor if one is present: the math emulation will just |
152 | never get used in that case. The kernel will be slightly larger, |
153 | but will work on different machines regardless of whether they |
154 | have a math coprocessor or not. |
155 | - the "kernel hacking" configuration details usually result in a |
156 | bigger or slower kernel (or both), and can even make the kernel |
157 | less stable by configuring some routines to actively try to |
158 | break bad code to find kernel problems (kmalloc()). Thus you |
159 | should probably answer 'n' to the questions for |
160 | "development", "experimental", or "debugging" features. |
161 | |
162 | - Check the top Makefile for further site-dependent configuration |
163 | (default SVGA mode etc). |
164 | |
165 | COMPILING the kernel: |
166 | |
167 | - Make sure you have gcc 2.95.3 available. |
168 | gcc 2.91.66 (egcs-1.1.2), and gcc 2.7.2.3 are known to miscompile |
169 | some parts of the kernel, and are *no longer supported*. |
170 | Also remember to upgrade your binutils package (for as/ld/nm and company) |
171 | if necessary. For more information, refer to Documentation/Changes. |
172 | |
173 | Please note that you can still run a.out user programs with this kernel. |
174 | |
175 | - Do a "make" to create a compressed kernel image. It is also |
176 | possible to do "make install" if you have lilo installed to suit the |
177 | kernel makefiles, but you may want to check your particular lilo setup first. |
178 | |
179 | To do the actual install you have to be root, but none of the normal |
180 | build should require that. Don't take the name of root in vain. |
181 | |
182 | - If you configured any of the parts of the kernel as `modules', you |
183 | will also have to do "make modules_install". |
184 | |
185 | - Keep a backup kernel handy in case something goes wrong. This is |
186 | especially true for the development releases, since each new release |
187 | contains new code which has not been debugged. Make sure you keep a |
188 | backup of the modules corresponding to that kernel, as well. If you |
189 | are installing a new kernel with the same version number as your |
190 | working kernel, make a backup of your modules directory before you |
191 | do a "make modules_install". |
192 | |
193 | - In order to boot your new kernel, you'll need to copy the kernel |
194 | image (e.g. .../linux/arch/i386/boot/bzImage after compilation) |
195 | to the place where your regular bootable kernel is found. |
196 | |
197 | - Booting a kernel directly from a floppy without the assistance of a |
198 | bootloader such as LILO, is no longer supported. |
199 | |
200 | If you boot Linux from the hard drive, chances are you use LILO which |
201 | uses the kernel image as specified in the file /etc/lilo.conf. The |
202 | kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or |
203 | /boot/bzImage. To use the new kernel, save a copy of the old image |
204 | and copy the new image over the old one. Then, you MUST RERUN LILO |
205 | to update the loading map!! If you don't, you won't be able to boot |
206 | the new kernel image. |
207 | |
208 | Reinstalling LILO is usually a matter of running /sbin/lilo. |
209 | You may wish to edit /etc/lilo.conf to specify an entry for your |
210 | old kernel image (say, /vmlinux.old) in case the new one does not |
211 | work. See the LILO docs for more information. |
212 | |
213 | After reinstalling LILO, you should be all set. Shutdown the system, |
214 | reboot, and enjoy! |
215 | |
216 | If you ever need to change the default root device, video mode, |
217 | ramdisk size, etc. in the kernel image, use the 'rdev' program (or |
218 | alternatively the LILO boot options when appropriate). No need to |
219 | recompile the kernel to change these parameters. |
220 | |
221 | - Reboot with the new kernel and enjoy. |
222 | |
223 | IF SOMETHING GOES WRONG: |
224 | |
225 | - If you have problems that seem to be due to kernel bugs, please check |
226 | the file MAINTAINERS to see if there is a particular person associated |
227 | with the part of the kernel that you are having trouble with. If there |
228 | isn't anyone listed there, then the second best thing is to mail |
229 | them to me (torvalds@osdl.org), and possibly to any other relevant |
230 | mailing-list or to the newsgroup. |
231 | |
232 | - In all bug-reports, *please* tell what kernel you are talking about, |
233 | how to duplicate the problem, and what your setup is (use your common |
234 | sense). If the problem is new, tell me so, and if the problem is |
235 | old, please try to tell me when you first noticed it. |
236 | |
237 | - If the bug results in a message like |
238 | |
239 | unable to handle kernel paging request at address C0000010 |
240 | Oops: 0002 |
241 | EIP: 0010:XXXXXXXX |
242 | eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx |
243 | esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx |
244 | ds: xxxx es: xxxx fs: xxxx gs: xxxx |
245 | Pid: xx, process nr: xx |
246 | xx xx xx xx xx xx xx xx xx xx |
247 | |
248 | or similar kernel debugging information on your screen or in your |
249 | system log, please duplicate it *exactly*. The dump may look |
250 | incomprehensible to you, but it does contain information that may |
251 | help debugging the problem. The text above the dump is also |
252 | important: it tells something about why the kernel dumped code (in |
253 | the above example it's due to a bad kernel pointer). More information |
254 | on making sense of the dump is in Documentation/oops-tracing.txt |
255 | |
256 | - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump |
257 | as is, otherwise you will have to use the "ksymoops" program to make |
258 | sense of the dump. This utility can be downloaded from |
259 | ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops. |
260 | Alternately you can do the dump lookup by hand: |
261 | |
262 | - In debugging dumps like the above, it helps enormously if you can |
263 | look up what the EIP value means. The hex value as such doesn't help |
264 | me or anybody else very much: it will depend on your particular |
265 | kernel setup. What you should do is take the hex value from the EIP |
266 | line (ignore the "0010:"), and look it up in the kernel namelist to |
267 | see which kernel function contains the offending address. |
268 | |
269 | To find out the kernel function name, you'll need to find the system |
270 | binary associated with the kernel that exhibited the symptom. This is |
271 | the file 'linux/vmlinux'. To extract the namelist and match it against |
272 | the EIP from the kernel crash, do: |
273 | |
274 | nm vmlinux | sort | less |
275 | |
276 | This will give you a list of kernel addresses sorted in ascending |
277 | order, from which it is simple to find the function that contains the |
278 | offending address. Note that the address given by the kernel |
279 | debugging messages will not necessarily match exactly with the |
280 | function addresses (in fact, that is very unlikely), so you can't |
281 | just 'grep' the list: the list will, however, give you the starting |
282 | point of each kernel function, so by looking for the function that |
283 | has a starting address lower than the one you are searching for but |
284 | is followed by a function with a higher address you will find the one |
285 | you want. In fact, it may be a good idea to include a bit of |
286 | "context" in your problem report, giving a few lines around the |
287 | interesting one. |
288 | |
289 | If you for some reason cannot do the above (you have a pre-compiled |
290 | kernel image or similar), telling me as much about your setup as |
291 | possible will help. |
292 | |
293 | - Alternately, you can use gdb on a running kernel. (read-only; i.e. you |
294 | cannot change values or set break points.) To do this, first compile the |
295 | kernel with -g; edit arch/i386/Makefile appropriately, then do a "make |
296 | clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). |
297 | |
298 | After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore". |
299 | You can now use all the usual gdb commands. The command to look up the |
300 | point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes |
301 | with the EIP value.) |
302 | |
303 | gdb'ing a non-running kernel currently fails because gdb (wrongly) |
304 | disregards the starting offset for which the kernel is compiled. |
305 |