diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/SubmittingPatches | 17 | ||||
-rw-r--r-- | Documentation/cdrom/sbpcd | 16 | ||||
-rw-r--r-- | Documentation/cpu-freq/governors.txt | 14 | ||||
-rw-r--r-- | Documentation/cpusets.txt | 16 | ||||
-rw-r--r-- | Documentation/devices.txt | 1 | ||||
-rw-r--r-- | Documentation/dvb/bt8xx.txt | 25 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 8 | ||||
-rw-r--r-- | Documentation/kdump/gdbmacros.txt | 179 | ||||
-rw-r--r-- | Documentation/kdump/kdump.txt | 141 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 11 | ||||
-rw-r--r-- | Documentation/networking/00-INDEX | 4 | ||||
-rw-r--r-- | Documentation/networking/wanpipe.txt | 622 | ||||
-rw-r--r-- | Documentation/power/kernel_threads.txt | 3 | ||||
-rw-r--r-- | Documentation/power/pci.txt | 38 | ||||
-rw-r--r-- | Documentation/power/swsusp.txt | 84 | ||||
-rw-r--r-- | Documentation/power/video.txt | 3 | ||||
-rw-r--r-- | Documentation/power/video_extension.txt | 19 | ||||
-rw-r--r-- | Documentation/s390/s390dbf.txt | 79 | ||||
-rw-r--r-- | Documentation/sysrq.txt | 5 |
20 files changed, 578 insertions, 709 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 8de8a01a2474..f28a24e0279b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -138,6 +138,8 @@ java.txt | |||
138 | - info on the in-kernel binary support for Java(tm). | 138 | - info on the in-kernel binary support for Java(tm). |
139 | kbuild/ | 139 | kbuild/ |
140 | - directory with info about the kernel build process. | 140 | - directory with info about the kernel build process. |
141 | kdumpt.txt | ||
142 | - mini HowTo on getting the crash dump code to work. | ||
141 | kernel-doc-nano-HOWTO.txt | 143 | kernel-doc-nano-HOWTO.txt |
142 | - mini HowTo on generation and location of kernel documentation files. | 144 | - mini HowTo on generation and location of kernel documentation files. |
143 | kernel-docs.txt | 145 | kernel-docs.txt |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 4d35562b1cf9..4d1f41b84ebc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -132,21 +132,6 @@ which require discussion or do not have a clear advantage should | |||
132 | usually be sent first to linux-kernel. Only after the patch is | 132 | usually be sent first to linux-kernel. Only after the patch is |
133 | discussed should the patch then be submitted to Linus. | 133 | discussed should the patch then be submitted to Linus. |
134 | 134 | ||
135 | For small patches you may want to CC the Trivial Patch Monkey | ||
136 | trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial" | ||
137 | patches. Trivial patches must qualify for one of the following rules: | ||
138 | Spelling fixes in documentation | ||
139 | Spelling fixes which could break grep(1). | ||
140 | Warning fixes (cluttering with useless warnings is bad) | ||
141 | Compilation fixes (only if they are actually correct) | ||
142 | Runtime fixes (only if they actually fix things) | ||
143 | Removing use of deprecated functions/macros (eg. check_region). | ||
144 | Contact detail and documentation fixes | ||
145 | Non-portable code replaced by portable code (even in arch-specific, | ||
146 | since people copy, as long as it's trivial) | ||
147 | Any fix by the author/maintainer of the file. (ie. patch monkey | ||
148 | in re-transmission mode) | ||
149 | |||
150 | 135 | ||
151 | 136 | ||
152 | 5) Select your CC (e-mail carbon copy) list. | 137 | 5) Select your CC (e-mail carbon copy) list. |
@@ -299,7 +284,7 @@ can certify the below: | |||
299 | 284 | ||
300 | then you just add a line saying | 285 | then you just add a line saying |
301 | 286 | ||
302 | Signed-off-by: Random J Developer <random@developer.org> | 287 | Signed-off-by: Random J Developer <random@developer.example.org> |
303 | 288 | ||
304 | Some people also put extra tags at the end. They'll just be ignored for | 289 | Some people also put extra tags at the end. They'll just be ignored for |
305 | now, but you can do this to mark internal company procedures or just | 290 | now, but you can do this to mark internal company procedures or just |
diff --git a/Documentation/cdrom/sbpcd b/Documentation/cdrom/sbpcd index d1825dffca34..b3ba63f4ce3e 100644 --- a/Documentation/cdrom/sbpcd +++ b/Documentation/cdrom/sbpcd | |||
@@ -419,6 +419,7 @@ into the file "track01": | |||
419 | */ | 419 | */ |
420 | #include <stdio.h> | 420 | #include <stdio.h> |
421 | #include <sys/ioctl.h> | 421 | #include <sys/ioctl.h> |
422 | #include <sys/types.h> | ||
422 | #include <linux/cdrom.h> | 423 | #include <linux/cdrom.h> |
423 | 424 | ||
424 | static struct cdrom_tochdr hdr; | 425 | static struct cdrom_tochdr hdr; |
@@ -429,7 +430,7 @@ static int datafile, drive; | |||
429 | static int i, j, limit, track, err; | 430 | static int i, j, limit, track, err; |
430 | static char filename[32]; | 431 | static char filename[32]; |
431 | 432 | ||
432 | main(int argc, char *argv[]) | 433 | int main(int argc, char *argv[]) |
433 | { | 434 | { |
434 | /* | 435 | /* |
435 | * open /dev/cdrom | 436 | * open /dev/cdrom |
@@ -516,6 +517,7 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300; | |||
516 | } | 517 | } |
517 | arg.addr.lba++; | 518 | arg.addr.lba++; |
518 | } | 519 | } |
520 | return 0; | ||
519 | } | 521 | } |
520 | /*===================== end program ========================================*/ | 522 | /*===================== end program ========================================*/ |
521 | 523 | ||
@@ -564,15 +566,16 @@ Appendix -- the "cdtester" utility: | |||
564 | #include <stdio.h> | 566 | #include <stdio.h> |
565 | #include <malloc.h> | 567 | #include <malloc.h> |
566 | #include <sys/ioctl.h> | 568 | #include <sys/ioctl.h> |
569 | #include <sys/types.h> | ||
567 | #include <linux/cdrom.h> | 570 | #include <linux/cdrom.h> |
568 | 571 | ||
569 | #ifdef AZT_PRIVATE_IOCTLS | 572 | #ifdef AZT_PRIVATE_IOCTLS |
570 | #include <linux/../../drivers/cdrom/aztcd.h> | 573 | #include <linux/../../drivers/cdrom/aztcd.h> |
571 | #endif AZT_PRIVATE_IOCTLS | 574 | #endif /* AZT_PRIVATE_IOCTLS */ |
572 | #ifdef SBP_PRIVATE_IOCTLS | 575 | #ifdef SBP_PRIVATE_IOCTLS |
573 | #include <linux/../../drivers/cdrom/sbpcd.h> | 576 | #include <linux/../../drivers/cdrom/sbpcd.h> |
574 | #include <linux/fs.h> | 577 | #include <linux/fs.h> |
575 | #endif SBP_PRIVATE_IOCTLS | 578 | #endif /* SBP_PRIVATE_IOCTLS */ |
576 | 579 | ||
577 | struct cdrom_tochdr hdr; | 580 | struct cdrom_tochdr hdr; |
578 | struct cdrom_tochdr tocHdr; | 581 | struct cdrom_tochdr tocHdr; |
@@ -590,7 +593,7 @@ union | |||
590 | struct cdrom_msf msf; | 593 | struct cdrom_msf msf; |
591 | unsigned char buf[CD_FRAMESIZE_RAW]; | 594 | unsigned char buf[CD_FRAMESIZE_RAW]; |
592 | } azt; | 595 | } azt; |
593 | #endif AZT_PRIVATE_IOCTLS | 596 | #endif /* AZT_PRIVATE_IOCTLS */ |
594 | int i, i1, i2, i3, j, k; | 597 | int i, i1, i2, i3, j, k; |
595 | unsigned char sequence=0; | 598 | unsigned char sequence=0; |
596 | unsigned char command[80]; | 599 | unsigned char command[80]; |
@@ -738,7 +741,7 @@ void display(int size,unsigned char *buffer) | |||
738 | } | 741 | } |
739 | } | 742 | } |
740 | 743 | ||
741 | main(int argc, char *argv[]) | 744 | int main(int argc, char *argv[]) |
742 | { | 745 | { |
743 | printf("\nTesting tool for a CDROM driver's audio functions V0.1\n"); | 746 | printf("\nTesting tool for a CDROM driver's audio functions V0.1\n"); |
744 | printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n"); | 747 | printf("(C) 1995 Eberhard Moenkeberg <emoenke@gwdg.de>\n"); |
@@ -1046,12 +1049,13 @@ main(int argc, char *argv[]) | |||
1046 | rc=ioctl(drive,CDROMAUDIOBUFSIZ,j); | 1049 | rc=ioctl(drive,CDROMAUDIOBUFSIZ,j); |
1047 | printf("%d frames granted.\n",rc); | 1050 | printf("%d frames granted.\n",rc); |
1048 | break; | 1051 | break; |
1049 | #endif SBP_PRIVATE_IOCTLS | 1052 | #endif /* SBP_PRIVATE_IOCTLS */ |
1050 | default: | 1053 | default: |
1051 | printf("unknown command: \"%s\".\n",command); | 1054 | printf("unknown command: \"%s\".\n",command); |
1052 | break; | 1055 | break; |
1053 | } | 1056 | } |
1054 | } | 1057 | } |
1058 | return 0; | ||
1055 | } | 1059 | } |
1056 | /*==========================================================================*/ | 1060 | /*==========================================================================*/ |
1057 | 1061 | ||
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index b85481acd0ca..933fae74c337 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt | |||
@@ -9,6 +9,7 @@ | |||
9 | 9 | ||
10 | 10 | ||
11 | Dominik Brodowski <linux@brodo.de> | 11 | Dominik Brodowski <linux@brodo.de> |
12 | some additions and corrections by Nico Golde <nico@ngolde.de> | ||
12 | 13 | ||
13 | 14 | ||
14 | 15 | ||
@@ -25,6 +26,7 @@ Contents: | |||
25 | 2.1 Performance | 26 | 2.1 Performance |
26 | 2.2 Powersave | 27 | 2.2 Powersave |
27 | 2.3 Userspace | 28 | 2.3 Userspace |
29 | 2.4 Ondemand | ||
28 | 30 | ||
29 | 3. The Governor Interface in the CPUfreq Core | 31 | 3. The Governor Interface in the CPUfreq Core |
30 | 32 | ||
@@ -86,7 +88,7 @@ highest frequency within the borders of scaling_min_freq and | |||
86 | scaling_max_freq. | 88 | scaling_max_freq. |
87 | 89 | ||
88 | 90 | ||
89 | 2.1 Powersave | 91 | 2.2 Powersave |
90 | ------------- | 92 | ------------- |
91 | 93 | ||
92 | The CPUfreq governor "powersave" sets the CPU statically to the | 94 | The CPUfreq governor "powersave" sets the CPU statically to the |
@@ -94,7 +96,7 @@ lowest frequency within the borders of scaling_min_freq and | |||
94 | scaling_max_freq. | 96 | scaling_max_freq. |
95 | 97 | ||
96 | 98 | ||
97 | 2.2 Userspace | 99 | 2.3 Userspace |
98 | ------------- | 100 | ------------- |
99 | 101 | ||
100 | The CPUfreq governor "userspace" allows the user, or any userspace | 102 | The CPUfreq governor "userspace" allows the user, or any userspace |
@@ -103,6 +105,14 @@ by making a sysfs file "scaling_setspeed" available in the CPU-device | |||
103 | directory. | 105 | directory. |
104 | 106 | ||
105 | 107 | ||
108 | 2.4 Ondemand | ||
109 | ------------ | ||
110 | |||
111 | The CPUfreq govenor "ondemand" sets the CPU depending on the | ||
112 | current usage. To do this the CPU must have the capability to | ||
113 | switch the frequency very fast. | ||
114 | |||
115 | |||
106 | 116 | ||
107 | 3. The Governor Interface in the CPUfreq Core | 117 | 3. The Governor Interface in the CPUfreq Core |
108 | ============================================= | 118 | ============================================= |
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 2f8f24eaefd9..ad944c060312 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt | |||
@@ -51,6 +51,14 @@ mems_allowed vector. | |||
51 | 51 | ||
52 | If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct | 52 | If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct |
53 | ancestor or descendent, may share any of the same CPUs or Memory Nodes. | 53 | ancestor or descendent, may share any of the same CPUs or Memory Nodes. |
54 | A cpuset that is cpu exclusive has a sched domain associated with it. | ||
55 | The sched domain consists of all cpus in the current cpuset that are not | ||
56 | part of any exclusive child cpusets. | ||
57 | This ensures that the scheduler load balacing code only balances | ||
58 | against the cpus that are in the sched domain as defined above and not | ||
59 | all of the cpus in the system. This removes any overhead due to | ||
60 | load balancing code trying to pull tasks outside of the cpu exclusive | ||
61 | cpuset only to be prevented by the tasks' cpus_allowed mask. | ||
54 | 62 | ||
55 | User level code may create and destroy cpusets by name in the cpuset | 63 | User level code may create and destroy cpusets by name in the cpuset |
56 | virtual file system, manage the attributes and permissions of these | 64 | virtual file system, manage the attributes and permissions of these |
@@ -84,6 +92,9 @@ This can be especially valuable on: | |||
84 | and a database), or | 92 | and a database), or |
85 | * NUMA systems running large HPC applications with demanding | 93 | * NUMA systems running large HPC applications with demanding |
86 | performance characteristics. | 94 | performance characteristics. |
95 | * Also cpu_exclusive cpusets are useful for servers running orthogonal | ||
96 | workloads such as RT applications requiring low latency and HPC | ||
97 | applications that are throughput sensitive | ||
87 | 98 | ||
88 | These subsets, or "soft partitions" must be able to be dynamically | 99 | These subsets, or "soft partitions" must be able to be dynamically |
89 | adjusted, as the job mix changes, without impacting other concurrently | 100 | adjusted, as the job mix changes, without impacting other concurrently |
@@ -125,6 +136,8 @@ Cpusets extends these two mechanisms as follows: | |||
125 | - A cpuset may be marked exclusive, which ensures that no other | 136 | - A cpuset may be marked exclusive, which ensures that no other |
126 | cpuset (except direct ancestors and descendents) may contain | 137 | cpuset (except direct ancestors and descendents) may contain |
127 | any overlapping CPUs or Memory Nodes. | 138 | any overlapping CPUs or Memory Nodes. |
139 | Also a cpu_exclusive cpuset would be associated with a sched | ||
140 | domain. | ||
128 | - You can list all the tasks (by pid) attached to any cpuset. | 141 | - You can list all the tasks (by pid) attached to any cpuset. |
129 | 142 | ||
130 | The implementation of cpusets requires a few, simple hooks | 143 | The implementation of cpusets requires a few, simple hooks |
@@ -136,6 +149,9 @@ into the rest of the kernel, none in performance critical paths: | |||
136 | allowed in that tasks cpuset. | 149 | allowed in that tasks cpuset. |
137 | - in sched.c migrate_all_tasks(), to keep migrating tasks within | 150 | - in sched.c migrate_all_tasks(), to keep migrating tasks within |
138 | the CPUs allowed by their cpuset, if possible. | 151 | the CPUs allowed by their cpuset, if possible. |
152 | - in sched.c, a new API partition_sched_domains for handling | ||
153 | sched domain changes associated with cpu_exclusive cpusets | ||
154 | and related changes in both sched.c and arch/ia64/kernel/domain.c | ||
139 | - in the mbind and set_mempolicy system calls, to mask the requested | 155 | - in the mbind and set_mempolicy system calls, to mask the requested |
140 | Memory Nodes by what's allowed in that tasks cpuset. | 156 | Memory Nodes by what's allowed in that tasks cpuset. |
141 | - in page_alloc, to restrict memory to allowed nodes. | 157 | - in page_alloc, to restrict memory to allowed nodes. |
diff --git a/Documentation/devices.txt b/Documentation/devices.txt index bb67cf25010e..0f515175c72a 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt | |||
@@ -94,6 +94,7 @@ Your cooperation is appreciated. | |||
94 | 9 = /dev/urandom Faster, less secure random number gen. | 94 | 9 = /dev/urandom Faster, less secure random number gen. |
95 | 10 = /dev/aio Asyncronous I/O notification interface | 95 | 10 = /dev/aio Asyncronous I/O notification interface |
96 | 11 = /dev/kmsg Writes to this come out as printk's | 96 | 11 = /dev/kmsg Writes to this come out as printk's |
97 | 12 = /dev/oldmem Access to crash dump from kexec kernel | ||
97 | 1 block RAM disk | 98 | 1 block RAM disk |
98 | 0 = /dev/ram0 First RAM disk | 99 | 0 = /dev/ram0 First RAM disk |
99 | 1 = /dev/ram1 Second RAM disk | 100 | 1 = /dev/ram1 Second RAM disk |
diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index d64430bf4bb6..3a3260794758 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt | |||
@@ -44,26 +44,23 @@ TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. | |||
44 | $ modprobe dst | 44 | $ modprobe dst |
45 | 45 | ||
46 | The value 0x71 will override the PCI type detection for dvb-bt8xx, | 46 | The value 0x71 will override the PCI type detection for dvb-bt8xx, |
47 | which is necessary for TwinHan cards. | 47 | which is necessary for TwinHan cards. |
48 | 48 | ||
49 | If you're having an older card (blue color circuit) and card=0x71 locks | 49 | If you're having an older card (blue color circuit) and card=0x71 locks |
50 | your machine, try using 0x68, too. If that does not work, ask on the | 50 | your machine, try using 0x68, too. If that does not work, ask on the |
51 | mailing list. | 51 | mailing list. |
52 | 52 | ||
53 | The DST module takes a couple of useful parameters. | 53 | The DST module takes a couple of useful parameters: |
54 | 54 | ||
55 | verbose takes values 0 to 5. These values control the verbosity level. | 55 | a. verbose takes values 0 to 5. These values control the verbosity level. |
56 | 56 | b. debug takes values 0 and 1. You can either disable or enable debugging. | |
57 | debug takes values 0 and 1. You can either disable or enable debugging. | 57 | c. dst_addons takes values 0 and 0x20: |
58 | 58 | - A value of 0 means it is a FTA card. | |
59 | dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. | 59 | - A value of 0x20 means it has a Conditional Access slot. |
60 | 0x20 means it has a Conditional Access slot. | ||
61 | |||
62 | The autodected values are determined bythe cards 'response | ||
63 | string' which you can see in your logs e.g. | ||
64 | |||
65 | dst_get_device_id: Recognise [DSTMCI] | ||
66 | 60 | ||
61 | The autodetected values are determined by the "response string" | ||
62 | of the card, which you can see in your logs: | ||
63 | e.g.: dst_get_device_id: Recognize [DSTMCI] | ||
67 | 64 | ||
68 | -- | 65 | -- |
69 | Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham | 66 | Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham, Uwe Bugla |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 77511af45362..1d227ee3792a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -43,6 +43,14 @@ Who: Randy Dunlap <rddunlap@osdl.org> | |||
43 | 43 | ||
44 | --------------------------- | 44 | --------------------------- |
45 | 45 | ||
46 | What: RAW driver (CONFIG_RAW_DRIVER) | ||
47 | When: December 2005 | ||
48 | Why: declared obsolete since kernel 2.6.3 | ||
49 | O_DIRECT can be used instead | ||
50 | Who: Adrian Bunk <bunk@stusta.de> | ||
51 | |||
52 | --------------------------- | ||
53 | |||
46 | What: register_ioctl32_conversion() / unregister_ioctl32_conversion() | 54 | What: register_ioctl32_conversion() / unregister_ioctl32_conversion() |
47 | When: April 2005 | 55 | When: April 2005 |
48 | Why: Replaced by ->compat_ioctl in file_operations and other method | 56 | Why: Replaced by ->compat_ioctl in file_operations and other method |
diff --git a/Documentation/kdump/gdbmacros.txt b/Documentation/kdump/gdbmacros.txt new file mode 100644 index 000000000000..bc1b9eb92ae1 --- /dev/null +++ b/Documentation/kdump/gdbmacros.txt | |||
@@ -0,0 +1,179 @@ | |||
1 | # | ||
2 | # This file contains a few gdb macros (user defined commands) to extract | ||
3 | # useful information from kernel crashdump (kdump) like stack traces of | ||
4 | # all the processes or a particular process and trapinfo. | ||
5 | # | ||
6 | # These macros can be used by copying this file in .gdbinit (put in home | ||
7 | # directory or current directory) or by invoking gdb command with | ||
8 | # --command=<command-file-name> option | ||
9 | # | ||
10 | # Credits: | ||
11 | # Alexander Nyberg <alexn@telia.com> | ||
12 | # V Srivatsa <vatsa@in.ibm.com> | ||
13 | # Maneesh Soni <maneesh@in.ibm.com> | ||
14 | # | ||
15 | |||
16 | define bttnobp | ||
17 | set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) | ||
18 | set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next) | ||
19 | set $init_t=&init_task | ||
20 | set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) | ||
21 | while ($next_t != $init_t) | ||
22 | set $next_t=(struct task_struct *)$next_t | ||
23 | printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm | ||
24 | printf "===================\n" | ||
25 | set var $stackp = $next_t.thread.esp | ||
26 | set var $stack_top = ($stackp & ~4095) + 4096 | ||
27 | |||
28 | while ($stackp < $stack_top) | ||
29 | if (*($stackp) > _stext && *($stackp) < _sinittext) | ||
30 | info symbol *($stackp) | ||
31 | end | ||
32 | set $stackp += 4 | ||
33 | end | ||
34 | set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off) | ||
35 | while ($next_th != $next_t) | ||
36 | set $next_th=(struct task_struct *)$next_th | ||
37 | printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm | ||
38 | printf "===================\n" | ||
39 | set var $stackp = $next_t.thread.esp | ||
40 | set var $stack_top = ($stackp & ~4095) + 4096 | ||
41 | |||
42 | while ($stackp < $stack_top) | ||
43 | if (*($stackp) > _stext && *($stackp) < _sinittext) | ||
44 | info symbol *($stackp) | ||
45 | end | ||
46 | set $stackp += 4 | ||
47 | end | ||
48 | set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off) | ||
49 | end | ||
50 | set $next_t=(char *)($next_t->tasks.next) - $tasks_off | ||
51 | end | ||
52 | end | ||
53 | document bttnobp | ||
54 | dump all thread stack traces on a kernel compiled with !CONFIG_FRAME_POINTER | ||
55 | end | ||
56 | |||
57 | define btt | ||
58 | set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) | ||
59 | set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next) | ||
60 | set $init_t=&init_task | ||
61 | set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) | ||
62 | while ($next_t != $init_t) | ||
63 | set $next_t=(struct task_struct *)$next_t | ||
64 | printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm | ||
65 | printf "===================\n" | ||
66 | set var $stackp = $next_t.thread.esp | ||
67 | set var $stack_top = ($stackp & ~4095) + 4096 | ||
68 | set var $stack_bot = ($stackp & ~4095) | ||
69 | |||
70 | set $stackp = *($stackp) | ||
71 | while (($stackp < $stack_top) && ($stackp > $stack_bot)) | ||
72 | set var $addr = *($stackp + 4) | ||
73 | info symbol $addr | ||
74 | set $stackp = *($stackp) | ||
75 | end | ||
76 | |||
77 | set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off) | ||
78 | while ($next_th != $next_t) | ||
79 | set $next_th=(struct task_struct *)$next_th | ||
80 | printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm | ||
81 | printf "===================\n" | ||
82 | set var $stackp = $next_t.thread.esp | ||
83 | set var $stack_top = ($stackp & ~4095) + 4096 | ||
84 | set var $stack_bot = ($stackp & ~4095) | ||
85 | |||
86 | set $stackp = *($stackp) | ||
87 | while (($stackp < $stack_top) && ($stackp > $stack_bot)) | ||
88 | set var $addr = *($stackp + 4) | ||
89 | info symbol $addr | ||
90 | set $stackp = *($stackp) | ||
91 | end | ||
92 | set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off) | ||
93 | end | ||
94 | set $next_t=(char *)($next_t->tasks.next) - $tasks_off | ||
95 | end | ||
96 | end | ||
97 | document btt | ||
98 | dump all thread stack traces on a kernel compiled with CONFIG_FRAME_POINTER | ||
99 | end | ||
100 | |||
101 | define btpid | ||
102 | set var $pid = $arg0 | ||
103 | set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) | ||
104 | set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next) | ||
105 | set $init_t=&init_task | ||
106 | set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) | ||
107 | set var $pid_task = 0 | ||
108 | |||
109 | while ($next_t != $init_t) | ||
110 | set $next_t=(struct task_struct *)$next_t | ||
111 | |||
112 | if ($next_t.pid == $pid) | ||
113 | set $pid_task = $next_t | ||
114 | end | ||
115 | |||
116 | set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off) | ||
117 | while ($next_th != $next_t) | ||
118 | set $next_th=(struct task_struct *)$next_th | ||
119 | if ($next_th.pid == $pid) | ||
120 | set $pid_task = $next_th | ||
121 | end | ||
122 | set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off) | ||
123 | end | ||
124 | set $next_t=(char *)($next_t->tasks.next) - $tasks_off | ||
125 | end | ||
126 | |||
127 | printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm | ||
128 | printf "===================\n" | ||
129 | set var $stackp = $pid_task.thread.esp | ||
130 | set var $stack_top = ($stackp & ~4095) + 4096 | ||
131 | set var $stack_bot = ($stackp & ~4095) | ||
132 | |||
133 | set $stackp = *($stackp) | ||
134 | while (($stackp < $stack_top) && ($stackp > $stack_bot)) | ||
135 | set var $addr = *($stackp + 4) | ||
136 | info symbol $addr | ||
137 | set $stackp = *($stackp) | ||
138 | end | ||
139 | end | ||
140 | document btpid | ||
141 | backtrace of pid | ||
142 | end | ||
143 | |||
144 | |||
145 | define trapinfo | ||
146 | set var $pid = $arg0 | ||
147 | set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) | ||
148 | set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next) | ||
149 | set $init_t=&init_task | ||
150 | set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) | ||
151 | set var $pid_task = 0 | ||
152 | |||
153 | while ($next_t != $init_t) | ||
154 | set $next_t=(struct task_struct *)$next_t | ||
155 | |||
156 | if ($next_t.pid == $pid) | ||
157 | set $pid_task = $next_t | ||
158 | end | ||
159 | |||
160 | set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off) | ||
161 | while ($next_th != $next_t) | ||
162 | set $next_th=(struct task_struct *)$next_th | ||
163 | if ($next_th.pid == $pid) | ||
164 | set $pid_task = $next_th | ||
165 | end | ||
166 | set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off) | ||
167 | end | ||
168 | set $next_t=(char *)($next_t->tasks.next) - $tasks_off | ||
169 | end | ||
170 | |||
171 | printf "Trapno %ld, cr2 0x%lx, error_code %ld\n", $pid_task.thread.trap_no, \ | ||
172 | $pid_task.thread.cr2, $pid_task.thread.error_code | ||
173 | |||
174 | end | ||
175 | document trapinfo | ||
176 | Run info threads and lookup pid of thread #1 | ||
177 | 'trapinfo <pid>' will tell you by which trap & possibly | ||
178 | addresthe kernel paniced. | ||
179 | end | ||
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt new file mode 100644 index 000000000000..7ff213f4becd --- /dev/null +++ b/Documentation/kdump/kdump.txt | |||
@@ -0,0 +1,141 @@ | |||
1 | Documentation for kdump - the kexec-based crash dumping solution | ||
2 | ================================================================ | ||
3 | |||
4 | DESIGN | ||
5 | ====== | ||
6 | |||
7 | Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken. | ||
8 | This second kernel is booted with very little memory. The first kernel reserves | ||
9 | the section of memory that the second kernel uses. This ensures that on-going | ||
10 | DMA from the first kernel does not corrupt the second kernel. | ||
11 | |||
12 | All the necessary information about Core image is encoded in ELF format and | ||
13 | stored in reserved area of memory before crash. Physical address of start of | ||
14 | ELF header is passed to new kernel through command line parameter elfcorehdr=. | ||
15 | |||
16 | On i386, the first 640 KB of physical memory is needed to boot, irrespective | ||
17 | of where the kernel loads. Hence, this region is backed up by kexec just before | ||
18 | rebooting into the new kernel. | ||
19 | |||
20 | In the second kernel, "old memory" can be accessed in two ways. | ||
21 | |||
22 | - The first one is through a /dev/oldmem device interface. A capture utility | ||
23 | can read the device file and write out the memory in raw format. This is raw | ||
24 | dump of memory and analysis/capture tool should be intelligent enough to | ||
25 | determine where to look for the right information. ELF headers (elfcorehdr=) | ||
26 | can become handy here. | ||
27 | |||
28 | - The second interface is through /proc/vmcore. This exports the dump as an ELF | ||
29 | format file which can be written out using any file copy command | ||
30 | (cp, scp, etc). Further, gdb can be used to perform limited debugging on | ||
31 | the dump file. This method ensures methods ensure that there is correct | ||
32 | ordering of the dump pages (corresponding to the first 640 KB that has been | ||
33 | relocated). | ||
34 | |||
35 | SETUP | ||
36 | ===== | ||
37 | |||
38 | 1) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz | ||
39 | and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch | ||
40 | and after that build the source. | ||
41 | |||
42 | 2) Download and build the appropriate (latest) kexec/kdump (-mm) kernel | ||
43 | patchset and apply it to the vanilla kernel tree. | ||
44 | |||
45 | Two kernels need to be built in order to get this feature working. | ||
46 | |||
47 | A) First kernel: | ||
48 | a) Enable "kexec system call" feature (in Processor type and features). | ||
49 | CONFIG_KEXEC=y | ||
50 | b) This kernel's physical load address should be the default value of | ||
51 | 0x100000 (0x100000, 1 MB) (in Processor type and features). | ||
52 | CONFIG_PHYSICAL_START=0x100000 | ||
53 | c) Enable "sysfs file system support" (in Pseudo filesystems). | ||
54 | CONFIG_SYSFS=y | ||
55 | d) Boot into first kernel with the command line parameter "crashkernel=Y@X". | ||
56 | Use appropriate values for X and Y. Y denotes how much memory to reserve | ||
57 | for the second kernel, and X denotes at what physical address the reserved | ||
58 | memory section starts. For example: "crashkernel=64M@16M". | ||
59 | |||
60 | B) Second kernel: | ||
61 | a) Enable "kernel crash dumps" feature (in Processor type and features). | ||
62 | CONFIG_CRASH_DUMP=y | ||
63 | b) Specify a suitable value for "Physical address where the kernel is | ||
64 | loaded" (in Processor type and features). Typically this value | ||
65 | should be same as X (See option d) above, e.g., 16 MB or 0x1000000. | ||
66 | CONFIG_PHYSICAL_START=0x1000000 | ||
67 | c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). | ||
68 | CONFIG_PROC_VMCORE=y | ||
69 | d) Disable SMP support and build a UP kernel (Until it is fixed). | ||
70 | CONFIG_SMP=n | ||
71 | e) Enable "Local APIC support on uniprocessors". | ||
72 | CONFIG_X86_UP_APIC=y | ||
73 | f) Enable "IO-APIC support on uniprocessors" | ||
74 | CONFIG_X86_UP_IOAPIC=y | ||
75 | |||
76 | Note: i) Options a) and b) depend upon "Configure standard kernel features | ||
77 | (for small systems)" (under General setup). | ||
78 | ii) Option a) also depends on CONFIG_HIGHMEM (under Processor | ||
79 | type and features). | ||
80 | iii) Both option a) and b) are under "Processor type and features". | ||
81 | |||
82 | 3) Boot into the first kernel. You are now ready to try out kexec-based crash | ||
83 | dumps. | ||
84 | |||
85 | 4) Load the second kernel to be booted using: | ||
86 | |||
87 | kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> | ||
88 | init 1 irqpoll" | ||
89 | |||
90 | Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work, | ||
91 | as of now. | ||
92 | ii) By default ELF headers are stored in ELF32 format (for i386). This | ||
93 | is sufficient to represent the physical memory up to 4GB. To store | ||
94 | headers in ELF64 format, specifiy "--elf64-core-headers" on the | ||
95 | kexec command line additionally. | ||
96 | iii) Specify "irqpoll" as command line parameter. This reduces driver | ||
97 | initialization failures in second kernel due to shared interrupts. | ||
98 | |||
99 | 5) System reboots into the second kernel when a panic occurs. A module can be | ||
100 | written to force the panic or "ALT-SysRq-c" can be used initiate a crash | ||
101 | dump for testing purposes. | ||
102 | |||
103 | 6) Write out the dump file using | ||
104 | |||
105 | cp /proc/vmcore <dump-file> | ||
106 | |||
107 | Dump memory can also be accessed as a /dev/oldmem device for a linear/raw | ||
108 | view. To create the device, type: | ||
109 | |||
110 | mknod /dev/oldmem c 1 12 | ||
111 | |||
112 | Use "dd" with suitable options for count, bs and skip to access specific | ||
113 | portions of the dump. | ||
114 | |||
115 | Entire memory: dd if=/dev/oldmem of=oldmem.001 | ||
116 | |||
117 | ANALYSIS | ||
118 | ======== | ||
119 | |||
120 | Limited analysis can be done using gdb on the dump file copied out of | ||
121 | /proc/vmcore. Use vmlinux built with -g and run | ||
122 | |||
123 | gdb vmlinux <dump-file> | ||
124 | |||
125 | Stack trace for the task on processor 0, register display, memory display | ||
126 | work fine. | ||
127 | |||
128 | Note: gdb cannot analyse core files generated in ELF64 format for i386. | ||
129 | |||
130 | TODO | ||
131 | ==== | ||
132 | |||
133 | 1) Provide a kernel pages filtering mechanism so that core file size is not | ||
134 | insane on systems having huge memory banks. | ||
135 | 2) Modify "crash" tool to make it recognize this dump. | ||
136 | |||
137 | CONTACT | ||
138 | ======= | ||
139 | |||
140 | Vivek Goyal (vgoyal@in.ibm.com) | ||
141 | Maneesh Soni (maneesh@in.ibm.com) | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4924d387a657..f44bb5567c5b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -358,6 +358,10 @@ running once the system is up. | |||
358 | cpia_pp= [HW,PPT] | 358 | cpia_pp= [HW,PPT] |
359 | Format: { parport<nr> | auto | none } | 359 | Format: { parport<nr> | auto | none } |
360 | 360 | ||
361 | crashkernel=nn[KMG]@ss[KMG] | ||
362 | [KNL] Reserve a chunk of physical memory to | ||
363 | hold a kernel to switch to with kexec on panic. | ||
364 | |||
361 | cs4232= [HW,OSS] | 365 | cs4232= [HW,OSS] |
362 | Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq> | 366 | Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq> |
363 | 367 | ||
@@ -447,6 +451,10 @@ running once the system is up. | |||
447 | Format: {"as"|"cfq"|"deadline"|"noop"} | 451 | Format: {"as"|"cfq"|"deadline"|"noop"} |
448 | See Documentation/block/as-iosched.txt | 452 | See Documentation/block/as-iosched.txt |
449 | and Documentation/block/deadline-iosched.txt for details. | 453 | and Documentation/block/deadline-iosched.txt for details. |
454 | elfcorehdr= [IA-32] | ||
455 | Specifies physical address of start of kernel core image | ||
456 | elf header. | ||
457 | See Documentation/kdump.txt for details. | ||
450 | 458 | ||
451 | enforcing [SELINUX] Set initial enforcing status. | 459 | enforcing [SELINUX] Set initial enforcing status. |
452 | Format: {"0" | "1"} | 460 | Format: {"0" | "1"} |
@@ -548,6 +556,9 @@ running once the system is up. | |||
548 | 556 | ||
549 | i810= [HW,DRM] | 557 | i810= [HW,DRM] |
550 | 558 | ||
559 | i8k.ignore_dmi [HW] Continue probing hardware even if DMI data | ||
560 | indicates that the driver is running on unsupported | ||
561 | hardware. | ||
551 | i8k.force [HW] Activate i8k driver even if SMM BIOS signature | 562 | i8k.force [HW] Activate i8k driver even if SMM BIOS signature |
552 | does not match list of supported models. | 563 | does not match list of supported models. |
553 | i8k.power_status | 564 | i8k.power_status |
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 834993d26730..5b01d5cc4e95 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX | |||
@@ -114,9 +114,7 @@ tuntap.txt | |||
114 | vortex.txt | 114 | vortex.txt |
115 | - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. | 115 | - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. |
116 | wan-router.txt | 116 | wan-router.txt |
117 | - Wan router documentation | 117 | - WAN router documentation |
118 | wanpipe.txt | ||
119 | - WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router | ||
120 | wavelan.txt | 118 | wavelan.txt |
121 | - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver | 119 | - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver |
122 | x25.txt | 120 | x25.txt |
diff --git a/Documentation/networking/wanpipe.txt b/Documentation/networking/wanpipe.txt deleted file mode 100644 index aea20cd2a56e..000000000000 --- a/Documentation/networking/wanpipe.txt +++ /dev/null | |||
@@ -1,622 +0,0 @@ | |||
1 | ------------------------------------------------------------------------------ | ||
2 | Linux WAN Router Utilities Package | ||
3 | ------------------------------------------------------------------------------ | ||
4 | Version 2.2.1 | ||
5 | Mar 28, 2001 | ||
6 | Author: Nenad Corbic <ncorbic@sangoma.com> | ||
7 | Copyright (c) 1995-2001 Sangoma Technologies Inc. | ||
8 | ------------------------------------------------------------------------------ | ||
9 | |||
10 | INTRODUCTION | ||
11 | |||
12 | Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs) | ||
13 | and/or stand-alone hosts over vast distances with data transfer rates | ||
14 | significantly higher than those achievable with commonly used dial-up | ||
15 | connections. | ||
16 | |||
17 | Usually an external device called `WAN router' sitting on your local network | ||
18 | or connected to your machine's serial port provides physical connection to | ||
19 | WAN. Although router's job may be as simple as taking your local network | ||
20 | traffic, converting it to WAN format and piping it through the WAN link, these | ||
21 | devices are notoriously expensive, with prices as much as 2 - 5 times higher | ||
22 | then the price of a typical PC box. | ||
23 | |||
24 | Alternatively, considering robustness and multitasking capabilities of Linux, | ||
25 | an internal router can be built (most routers use some sort of stripped down | ||
26 | Unix-like operating system anyway). With a number of relatively inexpensive WAN | ||
27 | interface cards available on the market, a perfectly usable router can be | ||
28 | built for less than half a price of an external router. Yet a Linux box | ||
29 | acting as a router can still be used for other purposes, such as fire-walling, | ||
30 | running FTP, WWW or DNS server, etc. | ||
31 | |||
32 | This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux | ||
33 | operating system and provides generic hardware-independent services for such | ||
34 | drivers. Why can existing Linux network device interface not be used for | ||
35 | this purpose? Well, it can. However, there are a few key differences between | ||
36 | a typical network interface (e.g. Ethernet) and a WAN link. | ||
37 | |||
38 | Many WAN protocols, such as X.25 and frame relay, allow for multiple logical | ||
39 | connections (known as `virtual circuits' in X.25 terminology) over a single | ||
40 | physical link. Each such virtual circuit may (and almost always does) lead | ||
41 | to a different geographical location and, therefore, different network. As a | ||
42 | result, it is the virtual circuit, not the physical link, that represents a | ||
43 | route and, therefore, a network interface in Linux terms. | ||
44 | |||
45 | To further complicate things, virtual circuits are usually volatile in nature | ||
46 | (excluding so called `permanent' virtual circuits or PVCs). With almost no | ||
47 | time required to set up and tear down a virtual circuit, it is highly desirable | ||
48 | to implement on-demand connections in order to minimize network charges. So | ||
49 | unlike a typical network driver, the WAN driver must be able to handle multiple | ||
50 | network interfaces and cope as multiple virtual circuits come into existence | ||
51 | and go away dynamically. | ||
52 | |||
53 | Last, but not least, WAN configuration is much more complex than that of say | ||
54 | Ethernet and may well amount to several dozens of parameters. Some of them | ||
55 | are "link-wide" while others are virtual circuit-specific. The same holds | ||
56 | true for WAN statistics which is by far more extensive and extremely useful | ||
57 | when troubleshooting WAN connections. Extending the ifconfig utility to suit | ||
58 | these needs may be possible, but does not seem quite reasonable. Therefore, a | ||
59 | WAN configuration utility and corresponding application programmer's interface | ||
60 | is needed for this purpose. | ||
61 | |||
62 | Most of these problems are taken care of by this module. Its goal is to | ||
63 | provide a user with more-or-less standard look and feel for all WAN devices and | ||
64 | assist a WAN device driver writer by providing common services, such as: | ||
65 | |||
66 | o User-level interface via /proc file system | ||
67 | o Centralized configuration | ||
68 | o Device management (setup, shutdown, etc.) | ||
69 | o Network interface management (dynamic creation/destruction) | ||
70 | o Protocol encapsulation/decapsulation | ||
71 | |||
72 | To ba able to use the Linux WAN Router you will also need a WAN Tools package | ||
73 | available from | ||
74 | |||
75 | ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz | ||
76 | |||
77 | where vX.Y.Z represent the wanpipe version number. | ||
78 | |||
79 | For technical questions and/or comments please e-mail to ncorbic@sangoma.com. | ||
80 | For general inquiries please contact Sangoma Technologies Inc. by | ||
81 | |||
82 | Hotline: 1-800-388-2475 (USA and Canada, toll free) | ||
83 | Phone: (905) 474-1990 ext: 106 | ||
84 | Fax: (905) 474-9223 | ||
85 | E-mail: dm@sangoma.com (David Mandelstam) | ||
86 | WWW: http://www.sangoma.com | ||
87 | |||
88 | |||
89 | INSTALLATION | ||
90 | |||
91 | Please read the WanpipeForLinux.pdf manual on how to | ||
92 | install the WANPIPE tools and drivers properly. | ||
93 | |||
94 | |||
95 | After installing wanpipe package: /usr/local/wanrouter/doc. | ||
96 | On the ftp.sangoma.com : /linux/current_wanpipe/doc | ||
97 | |||
98 | |||
99 | COPYRIGHT AND LICENSING INFORMATION | ||
100 | |||
101 | This program is free software; you can redistribute it and/or modify it under | ||
102 | the terms of the GNU General Public License as published by the Free Software | ||
103 | Foundation; either version 2, or (at your option) any later version. | ||
104 | |||
105 | This program is distributed in the hope that it will be useful, but WITHOUT | ||
106 | ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS | ||
107 | FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. | ||
108 | |||
109 | You should have received a copy of the GNU General Public License along with | ||
110 | this program; if not, write to the Free Software Foundation, Inc., 675 Mass | ||
111 | Ave, Cambridge, MA 02139, USA. | ||
112 | |||
113 | |||
114 | |||
115 | ACKNOWLEDGEMENTS | ||
116 | |||
117 | This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed | ||
118 | by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x. Success of the WANPIPE | ||
119 | together with the next major release of Linux kernel in summer 1996 commanded | ||
120 | adequate changes to the WANPIPE code to take full advantage of new Linux | ||
121 | features. | ||
122 | |||
123 | Instead of continuing developing proprietary interface tied to Sangoma WAN | ||
124 | cards, we decided to separate all hardware-independent code into a separate | ||
125 | module and defined two levels of interfaces - one for user-level applications | ||
126 | and another for kernel-level WAN drivers. WANPIPE is now implemented as a | ||
127 | WAN driver compliant with the WAN Link Driver interface. Also a general | ||
128 | purpose WAN configuration utility and a set of shell scripts was developed to | ||
129 | support WAN router at the user level. | ||
130 | |||
131 | Many useful ideas concerning hardware-independent interface implementation | ||
132 | were given by Mike McLagan <mike.mclagan@linux.org> and his implementation | ||
133 | of the Frame Relay router and drivers for Sangoma cards (dlci/sdla). | ||
134 | |||
135 | With the new implementation of the APIs being incorporated into the WANPIPE, | ||
136 | a special thank goes to Alan Cox in providing insight into BSD sockets. | ||
137 | |||
138 | Special thanks to all the WANPIPE users who performed field-testing, reported | ||
139 | bugs and made valuable comments and suggestions that help us to improve this | ||
140 | product. | ||
141 | |||
142 | |||
143 | |||
144 | NEW IN THIS RELEASE | ||
145 | |||
146 | o Updated the WANCFG utility | ||
147 | Calls the pppconfig to configure the PPPD | ||
148 | for async connections. | ||
149 | |||
150 | o Added the PPPCONFIG utility | ||
151 | Used to configure the PPPD dameon for the | ||
152 | WANPIPE Async PPP and standard serial port. | ||
153 | The wancfg calls the pppconfig to configure | ||
154 | the pppd. | ||
155 | |||
156 | o Fixed the PCI autodetect feature. | ||
157 | The SLOT 0 was used as an autodetect option | ||
158 | however, some high end PC's slot numbers start | ||
159 | from 0. | ||
160 | |||
161 | o This release has been tested with the new backupd | ||
162 | daemon release. | ||
163 | |||
164 | |||
165 | PRODUCT COMPONENTS AND RELATED FILES | ||
166 | |||
167 | /etc: (or user defined) | ||
168 | wanpipe1.conf default router configuration file | ||
169 | |||
170 | /lib/modules/X.Y.Z/misc: | ||
171 | wanrouter.o router kernel loadable module | ||
172 | af_wanpipe.o wanpipe api socket module | ||
173 | |||
174 | /lib/modules/X.Y.Z/net: | ||
175 | sdladrv.o Sangoma SDLA support module | ||
176 | wanpipe.o Sangoma WANPIPE(tm) driver module | ||
177 | |||
178 | /proc/net/wanrouter | ||
179 | Config reads current router configuration | ||
180 | Status reads current router status | ||
181 | {name} reads WAN driver statistics | ||
182 | |||
183 | /usr/sbin: | ||
184 | wanrouter wanrouter start-up script | ||
185 | wanconfig wanrouter configuration utility | ||
186 | sdladump WANPIPE adapter memory dump utility | ||
187 | fpipemon Monitor for Frame Relay | ||
188 | cpipemon Monitor for Cisco HDLC | ||
189 | ppipemon Monitor for PPP | ||
190 | xpipemon Monitor for X25 | ||
191 | wpkbdmon WANPIPE keyboard led monitor/debugger | ||
192 | |||
193 | /usr/local/wanrouter: | ||
194 | README this file | ||
195 | COPYING GNU General Public License | ||
196 | Setup installation script | ||
197 | Filelist distribution definition file | ||
198 | wanrouter.rc meta-configuration file | ||
199 | (used by the Setup and wanrouter script) | ||
200 | |||
201 | /usr/local/wanrouter/doc: | ||
202 | wanpipeForLinux.pdf WAN Router User's Manual | ||
203 | |||
204 | /usr/local/wanrouter/patches: | ||
205 | wanrouter-v2213.gz patch for Linux kernels 2.2.11 up to 2.2.13. | ||
206 | wanrouter-v2214.gz patch for Linux kernel 2.2.14. | ||
207 | wanrouter-v2215.gz patch for Linux kernels 2.2.15 to 2.2.17. | ||
208 | wanrouter-v2218.gz patch for Linux kernels 2.2.18 and up. | ||
209 | wanrouter-v240.gz patch for Linux kernel 2.4.0. | ||
210 | wanrouter-v242.gz patch for Linux kernel 2.4.2 and up. | ||
211 | wanrouter-v2034.gz patch for Linux kernel 2.0.34 | ||
212 | wanrouter-v2036.gz patch for Linux kernel 2.0.36 and up. | ||
213 | |||
214 | /usr/local/wanrouter/patches/kdrivers: | ||
215 | Sources of the latest WANPIPE device drivers. | ||
216 | These are used to UPGRADE the linux kernel to the newest | ||
217 | version if the kernel source has already been pathced with | ||
218 | WANPIPE drivers. | ||
219 | |||
220 | /usr/local/wanrouter/samples: | ||
221 | interface sample interface configuration file | ||
222 | wanpipe1.cpri CHDLC primary port | ||
223 | wanpipe2.csec CHDLC secondary port | ||
224 | wanpipe1.fr Frame Relay protocol | ||
225 | wanpipe1.ppp PPP protocol ) | ||
226 | wanpipe1.asy CHDLC ASYNC protocol | ||
227 | wanpipe1.x25 X25 protocol | ||
228 | wanpipe1.stty Sync TTY driver (Used by Kernel PPPD daemon) | ||
229 | wanpipe1.atty Async TTY driver (Used by Kernel PPPD daemon) | ||
230 | wanrouter.rc sample meta-configuration file | ||
231 | |||
232 | /usr/local/wanrouter/util: | ||
233 | * wan-tools utilities source code | ||
234 | |||
235 | /usr/local/wanrouter/api/x25: | ||
236 | * x25 api sample programs. | ||
237 | /usr/local/wanrouter/api/chdlc: | ||
238 | * chdlc api sample programs. | ||
239 | /usr/local/wanrouter/api/fr: | ||
240 | * fr api sample programs. | ||
241 | /usr/local/wanrouter/config/wancfg: | ||
242 | wancfg WANPIPE GUI configuration program. | ||
243 | Creates wanpipe#.conf files. | ||
244 | /usr/local/wanrouter/config/cfgft1: | ||
245 | cfgft1 GUI CSU/DSU configuration program. | ||
246 | |||
247 | /usr/include/linux: | ||
248 | wanrouter.h router API definitions | ||
249 | wanpipe.h WANPIPE API definitions | ||
250 | sdladrv.h SDLA support module API definitions | ||
251 | sdlasfm.h SDLA firmware module definitions | ||
252 | if_wanpipe.h WANPIPE Socket definitions | ||
253 | if_wanpipe_common.h WANPIPE Socket/Driver common definitions. | ||
254 | sdlapci.h WANPIPE PCI definitions | ||
255 | |||
256 | |||
257 | /usr/src/linux/net/wanrouter: | ||
258 | * wanrouter source code | ||
259 | |||
260 | /var/log: | ||
261 | wanrouter wanrouter start-up log (created by the Setup script) | ||
262 | |||
263 | /var/lock: (or /var/lock/subsys for RedHat) | ||
264 | wanrouter wanrouter lock file (created by the Setup script) | ||
265 | |||
266 | /usr/local/wanrouter/firmware: | ||
267 | fr514.sfm Frame relay firmware for Sangoma S508/S514 card | ||
268 | cdual514.sfm Dual Port Cisco HDLC firmware for Sangoma S508/S514 card | ||
269 | ppp514.sfm PPP Firmware for Sangoma S508 and S514 cards | ||
270 | x25_508.sfm X25 Firmware for Sangoma S508 card. | ||
271 | |||
272 | |||
273 | REVISION HISTORY | ||
274 | |||
275 | 1.0.0 December 31, 1996 Initial version | ||
276 | |||
277 | 1.0.1 January 30, 1997 Status and statistics can be read via /proc | ||
278 | filesystem entries. | ||
279 | |||
280 | 1.0.2 April 30, 1997 Added UDP management via monitors. | ||
281 | |||
282 | 1.0.3 June 3, 1997 UDP management for multiple boards using Frame | ||
283 | Relay and PPP | ||
284 | Enabled continuous transmission of Configure | ||
285 | Request Packet for PPP (for 508 only) | ||
286 | Connection Timeout for PPP changed from 900 to 0 | ||
287 | Flow Control Problem fixed for Frame Relay | ||
288 | |||
289 | 1.0.4 July 10, 1997 S508/FT1 monitoring capability in fpipemon and | ||
290 | ppipemon utilities. | ||
291 | Configurable TTL for UDP packets. | ||
292 | Multicast and Broadcast IP source addresses are | ||
293 | silently discarded. | ||
294 | |||
295 | 1.0.5 July 28, 1997 Configurable T391,T392,N391,N392,N393 for Frame | ||
296 | Relay in router.conf. | ||
297 | Configurable Memory Address through router.conf | ||
298 | for Frame Relay, PPP and X.25. (commenting this | ||
299 | out enables auto-detection). | ||
300 | Fixed freeing up received buffers using kfree() | ||
301 | for Frame Relay and X.25. | ||
302 | Protect sdla_peek() by calling save_flags(), | ||
303 | cli() and restore_flags(). | ||
304 | Changed number of Trace elements from 32 to 20 | ||
305 | Added DLCI specific data monitoring in FPIPEMON. | ||
306 | 2.0.0 Nov 07, 1997 Implemented protection of RACE conditions by | ||
307 | critical flags for FRAME RELAY and PPP. | ||
308 | DLCI List interrupt mode implemented. | ||
309 | IPX support in FRAME RELAY and PPP. | ||
310 | IPX Server Support (MARS) | ||
311 | More driver specific stats included in FPIPEMON | ||
312 | and PIPEMON. | ||
313 | |||
314 | 2.0.1 Nov 28, 1997 Bug Fixes for version 2.0.0. | ||
315 | Protection of "enable_irq()" while | ||
316 | "disable_irq()" has been enabled from any other | ||
317 | routine (for Frame Relay, PPP and X25). | ||
318 | Added additional Stats for Fpipemon and Ppipemon | ||
319 | Improved Load Sharing for multiple boards | ||
320 | |||
321 | 2.0.2 Dec 09, 1997 Support for PAP and CHAP for ppp has been | ||
322 | implemented. | ||
323 | |||
324 | 2.0.3 Aug 15, 1998 New release supporting Cisco HDLC, CIR for Frame | ||
325 | relay, Dynamic IP assignment for PPP and Inverse | ||
326 | Arp support for Frame-relay. Man Pages are | ||
327 | included for better support and a new utility | ||
328 | for configuring FT1 cards. | ||
329 | |||
330 | 2.0.4 Dec 09, 1998 Dual Port support for Cisco HDLC. | ||
331 | Support for HDLC (LAPB) API. | ||
332 | Supports BiSync Streaming code for S502E | ||
333 | and S503 cards. | ||
334 | Support for Streaming HDLC API. | ||
335 | Provides a BSD socket interface for | ||
336 | creating applications using BiSync | ||
337 | streaming. | ||
338 | |||
339 | 2.0.5 Aug 04, 1999 CHDLC initializatin bug fix. | ||
340 | PPP interrupt driven driver: | ||
341 | Fix to the PPP line hangup problem. | ||
342 | New PPP firmware | ||
343 | Added comments to the startup SYSTEM ERROR messages | ||
344 | Xpipemon debugging application for the X25 protocol | ||
345 | New USER_MANUAL.txt | ||
346 | Fixed the odd boundary 4byte writes to the board. | ||
347 | BiSync Streaming code has been taken out. | ||
348 | Available as a patch. | ||
349 | Streaming HDLC API has been taken out. | ||
350 | Available as a patch. | ||
351 | |||
352 | 2.0.6 Aug 17, 1999 Increased debugging in statup scripts | ||
353 | Fixed insallation bugs from 2.0.5 | ||
354 | Kernel patch works for both 2.2.10 and 2.2.11 kernels. | ||
355 | There is no functional difference between the two packages | ||
356 | |||
357 | 2.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE. | ||
358 | o Fixed a memeory leak for X25API | ||
359 | o Updated the X25API code for 2.2.X kernels. | ||
360 | o Improved NEM handling. | ||
361 | |||
362 | 2.1.0 Oct 25, 1999 o New code for S514 PCI Card | ||
363 | o New CHDLC and Frame Relay drivers | ||
364 | o PPP and X25 are not supported in this release | ||
365 | |||
366 | 2.1.1 Nov 30, 1999 o PPP support for S514 PCI Cards | ||
367 | |||
368 | 2.1.3 Apr 06, 2000 o Socket based x25api | ||
369 | o Socket based chdlc api | ||
370 | o Socket based fr api | ||
371 | o Dual Port Receive only CHDLC support. | ||
372 | o Asynchronous CHDLC support (Secondary Port) | ||
373 | o cfgft1 GUI csu/dsu configurator | ||
374 | o wancfg GUI configuration file | ||
375 | configurator. | ||
376 | o Architectual directory changes. | ||
377 | |||
378 | beta-2.1.4 Jul 2000 o Dynamic interface configuration: | ||
379 | Network interfaces reflect the state | ||
380 | of protocol layer. If the protocol becomes | ||
381 | disconnected, driver will bring down | ||
382 | the interface. Once the protocol reconnects | ||
383 | the interface will be brought up. | ||
384 | |||
385 | Note: This option is turned off by default. | ||
386 | |||
387 | o Dynamic wanrouter setup using 'wanconfig': | ||
388 | wanconfig utility can be used to | ||
389 | shutdown,restart,start or reconfigure | ||
390 | a virtual circuit dynamically. | ||
391 | |||
392 | Frame Relay: Each DLCI can be: | ||
393 | created,stopped,restarted and reconfigured | ||
394 | dynamically using wanconfig. | ||
395 | |||
396 | ex: wanconfig card wanpipe1 dev wp1_fr16 up | ||
397 | |||
398 | o Wanrouter startup via command line arguments: | ||
399 | wanconfig also supports wanrouter startup via command line | ||
400 | arguments. Thus, there is no need to create a wanpipe#.conf | ||
401 | configuration file. | ||
402 | |||
403 | o Socket based x25api update/bug fixes. | ||
404 | Added support for LCN numbers greater than 255. | ||
405 | Option to pass up modem messages. | ||
406 | Provided a PCI IRQ check, so a single S514 | ||
407 | card is guaranteed to have a non-sharing interrupt. | ||
408 | |||
409 | o Fixes to the wancfg utility. | ||
410 | o New FT1 debugging support via *pipemon utilities. | ||
411 | o Frame Relay ARP support Enabled. | ||
412 | |||
413 | beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix. | ||
414 | o Added the Multi-Port PPP | ||
415 | Updated utilites for the Multi-Port PPP. | ||
416 | |||
417 | 2.1.4 Aut 2000 | ||
418 | o In X25API: | ||
419 | Maximum packet an application can send | ||
420 | to the driver has been extended to 4096 bytes. | ||
421 | |||
422 | Fixed the x25 startup bug. Enable | ||
423 | communications only after all interfaces | ||
424 | come up. HIGH SVC/PVC is used to calculate | ||
425 | the number of channels. | ||
426 | Enable protocol only after all interfaces | ||
427 | are enabled. | ||
428 | |||
429 | o Added an extra state to the FT1 config, kernel module. | ||
430 | o Updated the pipemon debuggers. | ||
431 | |||
432 | o Blocked the Multi-Port PPP from running on kernels | ||
433 | 2.2.16 or greater, due to syncppp kernel module | ||
434 | change. | ||
435 | |||
436 | beta1-2.1.5 Nov 15 2000 | ||
437 | o Fixed the MulitPort PPP Support for kernels 2.2.16 and above. | ||
438 | 2.2.X kernels only | ||
439 | |||
440 | o Secured the driver UDP debugging calls | ||
441 | - All illegal netowrk debugging calls are reported to | ||
442 | the log. | ||
443 | - Defined a set of allowed commands, all other denied. | ||
444 | |||
445 | o Cpipemon | ||
446 | - Added set FT1 commands to the cpipemon. Thus CSU/DSU | ||
447 | configuraiton can be performed using cpipemon. | ||
448 | All systems that cannot run cfgft1 GUI utility should | ||
449 | use cpipemon to configure the on board CSU/DSU. | ||
450 | |||
451 | |||
452 | o Keyboard Led Monitor/Debugger | ||
453 | - A new utilty /usr/sbin/wpkbdmon uses keyboard leds | ||
454 | to convey operatinal statistic information of the | ||
455 | Sangoma WANPIPE cards. | ||
456 | NUM_LOCK = Line State (On=connected, Off=disconnected) | ||
457 | CAPS_LOCK = Tx data (On=transmitting, Off=no tx data) | ||
458 | SCROLL_LOCK = Rx data (On=receiving, Off=no rx data | ||
459 | |||
460 | o Hardware probe on module load and dynamic device allocation | ||
461 | - During WANPIPE module load, all Sangoma cards are probed | ||
462 | and found information is printed in the /var/log/messages. | ||
463 | - If no cards are found, the module load fails. | ||
464 | - Appropriate number of devices are dynamically loaded | ||
465 | based on the number of Sangoma cards found. | ||
466 | |||
467 | Note: The kernel configuraiton option | ||
468 | CONFIG_WANPIPE_CARDS has been taken out. | ||
469 | |||
470 | o Fixed the Frame Relay and Chdlc network interfaces so they are | ||
471 | compatible with libpcap libraries. Meaning, tcpdump, snort, | ||
472 | ethereal, and all other packet sniffers and debuggers work on | ||
473 | all WANPIPE netowrk interfaces. | ||
474 | - Set the network interface encoding type to ARPHRD_PPP. | ||
475 | This tell the sniffers that data obtained from the | ||
476 | network interface is in pure IP format. | ||
477 | Fix for 2.2.X kernels only. | ||
478 | |||
479 | o True interface encoding option for Frame Relay and CHDLC | ||
480 | - The above fix sets the network interface encoding | ||
481 | type to ARPHRD_PPP, however some customers use | ||
482 | the encoding interface type to determine the | ||
483 | protocol running. Therefore, the TURE ENCODING | ||
484 | option will set the interface type back to the | ||
485 | original value. | ||
486 | |||
487 | NOTE: If this option is used with Frame Relay and CHDLC | ||
488 | libpcap library support will be broken. | ||
489 | i.e. tcpdump will not work. | ||
490 | Fix for 2.2.x Kernels only. | ||
491 | |||
492 | o Ethernet Bridgind over Frame Relay | ||
493 | - The Frame Relay bridging has been developed by | ||
494 | Kristian Hoffmann and Mark Wells. | ||
495 | - The Linux kernel bridge is used to send ethernet | ||
496 | data over the frame relay links. | ||
497 | For 2.2.X Kernels only. | ||
498 | |||
499 | o Added extensive 2.0.X support. Most new features of | ||
500 | 2.1.5 for protocols Frame Relay, PPP and CHDLC are | ||
501 | supported under 2.0.X kernels. | ||
502 | |||
503 | beta1-2.2.0 Dec 30 2000 | ||
504 | o Updated drivers for 2.4.X kernels. | ||
505 | o Updated drivers for SMP support. | ||
506 | o X25API is now able to share PCI interrupts. | ||
507 | o Took out a general polling routine that was used | ||
508 | only by X25API. | ||
509 | o Added appropriate locks to the dynamic reconfiguration | ||
510 | code. | ||
511 | o Fixed a bug in the keyboard debug monitor. | ||
512 | |||
513 | beta2-2.2.0 Jan 8 2001 | ||
514 | o Patches for 2.4.0 kernel | ||
515 | o Patches for 2.2.18 kernel | ||
516 | o Minor updates to PPP and CHLDC drivers. | ||
517 | Note: No functinal difference. | ||
518 | |||
519 | beta3-2.2.9 Jan 10 2001 | ||
520 | o I missed the 2.2.18 kernel patches in beta2-2.2.0 | ||
521 | release. They are included in this release. | ||
522 | |||
523 | Stable Release | ||
524 | 2.2.0 Feb 01 2001 | ||
525 | o Bug fix in wancfg GUI configurator. | ||
526 | The edit function didn't work properly. | ||
527 | |||
528 | |||
529 | bata1-2.2.1 Feb 09 2001 | ||
530 | o WANPIPE TTY Driver emulation. | ||
531 | Two modes of operation Sync and Async. | ||
532 | Sync: Using the PPPD daemon, kernel SyncPPP layer | ||
533 | and the Wanpipe sync TTY driver: a PPP protocol | ||
534 | connection can be established via Sangoma adapter, over | ||
535 | a T1 leased line. | ||
536 | |||
537 | The 2.4.0 kernel PPP layer supports MULTILINK | ||
538 | protocol, that can be used to bundle any number of Sangoma | ||
539 | adapters (T1 lines) into one, under a single IP address. | ||
540 | Thus, efficiently obtaining multiple T1 throughput. | ||
541 | |||
542 | NOTE: The remote side must also implement MULTILINK PPP | ||
543 | protocol. | ||
544 | |||
545 | Async:Using the PPPD daemon, kernel AsyncPPP layer | ||
546 | and the WANPIPE async TTY driver: a PPP protocol | ||
547 | connection can be established via Sangoma adapter and | ||
548 | a modem, over a telephone line. | ||
549 | |||
550 | Thus, the WANPIPE async TTY driver simulates a serial | ||
551 | TTY driver that would normally be used to interface the | ||
552 | MODEM to the linux kernel. | ||
553 | |||
554 | o WANPIPE PPP Backup Utility | ||
555 | This utility will monitor the state of the PPP T1 line. | ||
556 | In case of failure, a dial up connection will be established | ||
557 | via pppd daemon, ether via a serial tty driver (serial port), | ||
558 | or a WANPIPE async TTY driver (in case serial port is unavailable). | ||
559 | |||
560 | Furthermore, while in dial up mode, the primary PPP T1 link | ||
561 | will be monitored for signs of life. | ||
562 | |||
563 | If the PPP T1 link comes back to life, the dial up connection | ||
564 | will be shutdown and T1 line re-established. | ||
565 | |||
566 | |||
567 | o New Setup installation script. | ||
568 | Option to UPGRADE device drivers if the kernel source has | ||
569 | already been patched with WANPIPE. | ||
570 | |||
571 | Option to COMPILE WANPIPE modules against the currently | ||
572 | running kernel, thus no need for manual kernel and module | ||
573 | re-compilatin. | ||
574 | |||
575 | o Updates and Bug Fixes to wancfg utility. | ||
576 | |||
577 | bata2-2.2.1 Feb 20 2001 | ||
578 | |||
579 | o Bug fixes to the CHDLC device drivers. | ||
580 | The driver had compilation problems under kernels | ||
581 | 2.2.14 or lower. | ||
582 | |||
583 | o Bug fixes to the Setup installation script. | ||
584 | The device drivers compilation options didn't work | ||
585 | properly. | ||
586 | |||
587 | o Update to the wpbackupd daemon. | ||
588 | Optimized the cross-over times, between the primary | ||
589 | link and the backup dialup. | ||
590 | |||
591 | beta3-2.2.1 Mar 02 2001 | ||
592 | o Patches for 2.4.2 kernel. | ||
593 | |||
594 | o Bug fixes to util/ make files. | ||
595 | o Bug fixes to the Setup installation script. | ||
596 | |||
597 | o Took out the backupd support and made it into | ||
598 | as separate package. | ||
599 | |||
600 | beta4-2.2.1 Mar 12 2001 | ||
601 | |||
602 | o Fix to the Frame Relay Device driver. | ||
603 | IPSAC sends a packet of zero length | ||
604 | header to the frame relay driver. The | ||
605 | driver tries to push its own 2 byte header | ||
606 | into the packet, which causes the driver to | ||
607 | crash. | ||
608 | |||
609 | o Fix the WANPIPE re-configuration code. | ||
610 | Bug was found by trying to run the cfgft1 while the | ||
611 | interface was already running. | ||
612 | |||
613 | o Updates to cfgft1. | ||
614 | Writes a wanpipe#.cfgft1 configuration file | ||
615 | once the CSU/DSU is configured. This file can | ||
616 | holds the current CSU/DSU configuration. | ||
617 | |||
618 | |||
619 | |||
620 | >>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | ||
621 | |||
622 | |||
diff --git a/Documentation/power/kernel_threads.txt b/Documentation/power/kernel_threads.txt index 60b548105edf..fb57784986b1 100644 --- a/Documentation/power/kernel_threads.txt +++ b/Documentation/power/kernel_threads.txt | |||
@@ -12,8 +12,7 @@ refrigerator. Code to do this looks like this: | |||
12 | do { | 12 | do { |
13 | hub_events(); | 13 | hub_events(); |
14 | wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list)); | 14 | wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list)); |
15 | if (current->flags & PF_FREEZE) | 15 | try_to_freeze(); |
16 | refrigerator(PF_FREEZE); | ||
17 | } while (!signal_pending(current)); | 16 | } while (!signal_pending(current)); |
18 | 17 | ||
19 | from drivers/usb/core/hub.c::hub_thread() | 18 | from drivers/usb/core/hub.c::hub_thread() |
diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index 35b1a7dae342..6fc9d511fc39 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt | |||
@@ -291,6 +291,44 @@ a request to enable wake events from D3, two calls should be made to | |||
291 | pci_enable_wake (one for both D3hot and D3cold). | 291 | pci_enable_wake (one for both D3hot and D3cold). |
292 | 292 | ||
293 | 293 | ||
294 | A reference implementation | ||
295 | ------------------------- | ||
296 | .suspend() | ||
297 | { | ||
298 | /* driver specific operations */ | ||
299 | |||
300 | /* Disable IRQ */ | ||
301 | free_irq(); | ||
302 | /* If using MSI */ | ||
303 | pci_disable_msi(); | ||
304 | |||
305 | pci_save_state(); | ||
306 | pci_enable_wake(); | ||
307 | /* Disable IO/bus master/irq router */ | ||
308 | pci_disable_device(); | ||
309 | pci_set_power_state(pci_choose_state()); | ||
310 | } | ||
311 | |||
312 | .resume() | ||
313 | { | ||
314 | pci_set_power_state(PCI_D0); | ||
315 | pci_restore_state(); | ||
316 | /* device's irq possibly is changed, driver should take care */ | ||
317 | pci_enable_device(); | ||
318 | pci_set_master(); | ||
319 | |||
320 | /* if using MSI, device's vector possibly is changed */ | ||
321 | pci_enable_msi(); | ||
322 | |||
323 | request_irq(); | ||
324 | /* driver specific operations; */ | ||
325 | } | ||
326 | |||
327 | This is a typical implementation. Drivers can slightly change the order | ||
328 | of the operations in the implementation, ignore some operations or add | ||
329 | more deriver specific operations in it, but drivers should do something like | ||
330 | this on the whole. | ||
331 | |||
294 | 5. Resources | 332 | 5. Resources |
295 | ~~~~~~~~~~~~ | 333 | ~~~~~~~~~~~~ |
296 | 334 | ||
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index c7c3459fde43..7a6b78966459 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt | |||
@@ -164,11 +164,11 @@ place where the thread is safe to be frozen (no kernel semaphores | |||
164 | should be held at that point and it must be safe to sleep there), and | 164 | should be held at that point and it must be safe to sleep there), and |
165 | add: | 165 | add: |
166 | 166 | ||
167 | if (current->flags & PF_FREEZE) | 167 | try_to_freeze(); |
168 | refrigerator(PF_FREEZE); | ||
169 | 168 | ||
170 | If the thread is needed for writing the image to storage, you should | 169 | If the thread is needed for writing the image to storage, you should |
171 | instead set the PF_NOFREEZE process flag when creating the thread. | 170 | instead set the PF_NOFREEZE process flag when creating the thread (and |
171 | be very carefull). | ||
172 | 172 | ||
173 | 173 | ||
174 | Q: What is the difference between between "platform", "shutdown" and | 174 | Q: What is the difference between between "platform", "shutdown" and |
@@ -233,3 +233,81 @@ A: Try running | |||
233 | cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null | 233 | cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null |
234 | 234 | ||
235 | after resume. swapoff -a; swapon -a may also be usefull. | 235 | after resume. swapoff -a; swapon -a may also be usefull. |
236 | |||
237 | Q: What happens to devices during swsusp? They seem to be resumed | ||
238 | during system suspend? | ||
239 | |||
240 | A: That's correct. We need to resume them if we want to write image to | ||
241 | disk. Whole sequence goes like | ||
242 | |||
243 | Suspend part | ||
244 | ~~~~~~~~~~~~ | ||
245 | running system, user asks for suspend-to-disk | ||
246 | |||
247 | user processes are stopped | ||
248 | |||
249 | suspend(PMSG_FREEZE): devices are frozen so that they don't interfere | ||
250 | with state snapshot | ||
251 | |||
252 | state snapshot: copy of whole used memory is taken with interrupts disabled | ||
253 | |||
254 | resume(): devices are woken up so that we can write image to swap | ||
255 | |||
256 | write image to swap | ||
257 | |||
258 | suspend(PMSG_SUSPEND): suspend devices so that we can power off | ||
259 | |||
260 | turn the power off | ||
261 | |||
262 | Resume part | ||
263 | ~~~~~~~~~~~ | ||
264 | (is actually pretty similar) | ||
265 | |||
266 | running system, user asks for suspend-to-disk | ||
267 | |||
268 | user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows) | ||
269 | |||
270 | read image from disk | ||
271 | |||
272 | suspend(PMSG_FREEZE): devices are frozen so that they don't interfere | ||
273 | with image restoration | ||
274 | |||
275 | image restoration: rewrite memory with image | ||
276 | |||
277 | resume(): devices are woken up so that system can continue | ||
278 | |||
279 | thaw all user processes | ||
280 | |||
281 | Q: What is this 'Encrypt suspend image' for? | ||
282 | |||
283 | A: First of all: it is not a replacement for dm-crypt encrypted swap. | ||
284 | It cannot protect your computer while it is suspended. Instead it does | ||
285 | protect from leaking sensitive data after resume from suspend. | ||
286 | |||
287 | Think of the following: you suspend while an application is running | ||
288 | that keeps sensitive data in memory. The application itself prevents | ||
289 | the data from being swapped out. Suspend, however, must write these | ||
290 | data to swap to be able to resume later on. Without suspend encryption | ||
291 | your sensitive data are then stored in plaintext on disk. This means | ||
292 | that after resume your sensitive data are accessible to all | ||
293 | applications having direct access to the swap device which was used | ||
294 | for suspend. If you don't need swap after resume these data can remain | ||
295 | on disk virtually forever. Thus it can happen that your system gets | ||
296 | broken in weeks later and sensitive data which you thought were | ||
297 | encrypted and protected are retrieved and stolen from the swap device. | ||
298 | To prevent this situation you should use 'Encrypt suspend image'. | ||
299 | |||
300 | During suspend a temporary key is created and this key is used to | ||
301 | encrypt the data written to disk. When, during resume, the data was | ||
302 | read back into memory the temporary key is destroyed which simply | ||
303 | means that all data written to disk during suspend are then | ||
304 | inaccessible so they can't be stolen later on. The only thing that | ||
305 | you must then take care of is that you call 'mkswap' for the swap | ||
306 | partition used for suspend as early as possible during regular | ||
307 | boot. This asserts that any temporary key from an oopsed suspend or | ||
308 | from a failed or aborted resume is erased from the swap device. | ||
309 | |||
310 | As a rule of thumb use encrypted swap to protect your data while your | ||
311 | system is shut down or suspended. Additionally use the encrypted | ||
312 | suspend image to prevent sensitive data from being stolen after | ||
313 | resume. | ||
diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt index 68734355d7cf..881a37e3eeb0 100644 --- a/Documentation/power/video.txt +++ b/Documentation/power/video.txt | |||
@@ -83,8 +83,10 @@ Compaq Armada E500 - P3-700 none (1) (S1 also works OK) | |||
83 | Compaq Evo N620c vga=normal, s3_bios (2) | 83 | Compaq Evo N620c vga=normal, s3_bios (2) |
84 | Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1 | 84 | Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1 |
85 | Dell D600, ATI RV250 vga=normal and X, or try vbestate (6) | 85 | Dell D600, ATI RV250 vga=normal and X, or try vbestate (6) |
86 | Dell D610 vga=normal and X (possibly vbestate (6) too, but not tested) | ||
86 | Dell Inspiron 4000 ??? (*) | 87 | Dell Inspiron 4000 ??? (*) |
87 | Dell Inspiron 500m ??? (*) | 88 | Dell Inspiron 500m ??? (*) |
89 | Dell Inspiron 510m ??? | ||
88 | Dell Inspiron 600m ??? (*) | 90 | Dell Inspiron 600m ??? (*) |
89 | Dell Inspiron 8200 ??? (*) | 91 | Dell Inspiron 8200 ??? (*) |
90 | Dell Inspiron 8500 ??? (*) | 92 | Dell Inspiron 8500 ??? (*) |
@@ -123,6 +125,7 @@ Toshiba Satellite 4030CDT s3_mode (3) | |||
123 | Toshiba Satellite 4080XCDT s3_mode (3) | 125 | Toshiba Satellite 4080XCDT s3_mode (3) |
124 | Toshiba Satellite 4090XCDT ??? (*) | 126 | Toshiba Satellite 4090XCDT ??? (*) |
125 | Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****) | 127 | Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****) |
128 | Toshiba M30 (2) xor X with nvidia driver using internal AGP | ||
126 | Uniwill 244IIO ??? (*) | 129 | Uniwill 244IIO ??? (*) |
127 | 130 | ||
128 | 131 | ||
diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt index 8e33d7c82c49..b2f9b1598ac2 100644 --- a/Documentation/power/video_extension.txt +++ b/Documentation/power/video_extension.txt | |||
@@ -1,13 +1,16 @@ | |||
1 | This driver implement the ACPI Extensions For Display Adapters | 1 | ACPI video extensions |
2 | for integrated graphics devices on motherboard, as specified in | 2 | ~~~~~~~~~~~~~~~~~~~~~ |
3 | ACPI 2.0 Specification, Appendix B, allowing to perform some basic | 3 | |
4 | control like defining the video POST device, retrieving EDID information | 4 | This driver implement the ACPI Extensions For Display Adapters for |
5 | or to setup a video output, etc. Note that this is an ref. implementation only. | 5 | integrated graphics devices on motherboard, as specified in ACPI 2.0 |
6 | It may or may not work for your integrated video device. | 6 | Specification, Appendix B, allowing to perform some basic control like |
7 | defining the video POST device, retrieving EDID information or to | ||
8 | setup a video output, etc. Note that this is an ref. implementation | ||
9 | only. It may or may not work for your integrated video device. | ||
7 | 10 | ||
8 | Interfaces exposed to userland through /proc/acpi/video: | 11 | Interfaces exposed to userland through /proc/acpi/video: |
9 | 12 | ||
10 | VGA/info : display the supported video bus device capability like ,Video ROM, CRT/LCD/TV. | 13 | VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV. |
11 | VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). | 14 | VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). |
12 | VGA/POST_info : Used to determine what options are implemented. | 15 | VGA/POST_info : Used to determine what options are implemented. |
13 | VGA/POST : Used to get/set POST device. | 16 | VGA/POST : Used to get/set POST device. |
@@ -15,7 +18,7 @@ VGA/DOS : Used to get/set ownership of output switching: | |||
15 | Please refer ACPI spec B.4.1 _DOS | 18 | Please refer ACPI spec B.4.1 _DOS |
16 | VGA/CRT : CRT output | 19 | VGA/CRT : CRT output |
17 | VGA/LCD : LCD output | 20 | VGA/LCD : LCD output |
18 | VGA/TV : TV output | 21 | VGA/TVO : TV output |
19 | VGA/*/brightness : Used to get/set brightness of output device | 22 | VGA/*/brightness : Used to get/set brightness of output device |
20 | 23 | ||
21 | Notify event through /proc/acpi/event: | 24 | Notify event through /proc/acpi/event: |
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index 2d1cd939b4df..e24fdeada970 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt | |||
@@ -12,8 +12,8 @@ where log records can be stored efficiently in memory, where each component | |||
12 | One purpose of this is to inspect the debug logs after a production system crash | 12 | One purpose of this is to inspect the debug logs after a production system crash |
13 | in order to analyze the reason for the crash. | 13 | in order to analyze the reason for the crash. |
14 | If the system still runs but only a subcomponent which uses dbf failes, | 14 | If the system still runs but only a subcomponent which uses dbf failes, |
15 | it is possible to look at the debug logs on a live system via the Linux proc | 15 | it is possible to look at the debug logs on a live system via the Linux |
16 | filesystem. | 16 | debugfs filesystem. |
17 | The debug feature may also very useful for kernel and driver development. | 17 | The debug feature may also very useful for kernel and driver development. |
18 | 18 | ||
19 | Design: | 19 | Design: |
@@ -52,16 +52,18 @@ Each debug entry contains the following data: | |||
52 | - Flag, if entry is an exception or not | 52 | - Flag, if entry is an exception or not |
53 | 53 | ||
54 | The debug logs can be inspected in a live system through entries in | 54 | The debug logs can be inspected in a live system through entries in |
55 | the proc-filesystem. Under the path /proc/s390dbf there is | 55 | the debugfs-filesystem. Under the toplevel directory "s390dbf" there is |
56 | a directory for each registered component, which is named like the | 56 | a directory for each registered component, which is named like the |
57 | corresponding component. | 57 | corresponding component. The debugfs normally should be mounted to |
58 | /sys/kernel/debug therefore the debug feature can be accessed unter | ||
59 | /sys/kernel/debug/s390dbf. | ||
58 | 60 | ||
59 | The content of the directories are files which represent different views | 61 | The content of the directories are files which represent different views |
60 | to the debug log. Each component can decide which views should be | 62 | to the debug log. Each component can decide which views should be |
61 | used through registering them with the function debug_register_view(). | 63 | used through registering them with the function debug_register_view(). |
62 | Predefined views for hex/ascii, sprintf and raw binary data are provided. | 64 | Predefined views for hex/ascii, sprintf and raw binary data are provided. |
63 | It is also possible to define other views. The content of | 65 | It is also possible to define other views. The content of |
64 | a view can be inspected simply by reading the corresponding proc file. | 66 | a view can be inspected simply by reading the corresponding debugfs file. |
65 | 67 | ||
66 | All debug logs have an an actual debug level (range from 0 to 6). | 68 | All debug logs have an an actual debug level (range from 0 to 6). |
67 | The default level is 3. Event and Exception functions have a 'level' | 69 | The default level is 3. Event and Exception functions have a 'level' |
@@ -69,14 +71,14 @@ parameter. Only debug entries with a level that is lower or equal | |||
69 | than the actual level are written to the log. This means, when | 71 | than the actual level are written to the log. This means, when |
70 | writing events, high priority log entries should have a low level | 72 | writing events, high priority log entries should have a low level |
71 | value whereas low priority entries should have a high one. | 73 | value whereas low priority entries should have a high one. |
72 | The actual debug level can be changed with the help of the proc-filesystem | 74 | The actual debug level can be changed with the help of the debugfs-filesystem |
73 | through writing a number string "x" to the 'level' proc file which is | 75 | through writing a number string "x" to the 'level' debugfs file which is |
74 | provided for every debug log. Debugging can be switched off completely | 76 | provided for every debug log. Debugging can be switched off completely |
75 | by using "-" on the 'level' proc file. | 77 | by using "-" on the 'level' debugfs file. |
76 | 78 | ||
77 | Example: | 79 | Example: |
78 | 80 | ||
79 | > echo "-" > /proc/s390dbf/dasd/level | 81 | > echo "-" > /sys/kernel/debug/s390dbf/dasd/level |
80 | 82 | ||
81 | It is also possible to deactivate the debug feature globally for every | 83 | It is also possible to deactivate the debug feature globally for every |
82 | debug log. You can change the behavior using 2 sysctl parameters in | 84 | debug log. You can change the behavior using 2 sysctl parameters in |
@@ -99,11 +101,11 @@ Kernel Interfaces: | |||
99 | ------------------ | 101 | ------------------ |
100 | 102 | ||
101 | ---------------------------------------------------------------------------- | 103 | ---------------------------------------------------------------------------- |
102 | debug_info_t *debug_register(char *name, int pages_index, int nr_areas, | 104 | debug_info_t *debug_register(char *name, int pages, int nr_areas, |
103 | int buf_size); | 105 | int buf_size); |
104 | 106 | ||
105 | Parameter: name: Name of debug log (e.g. used for proc entry) | 107 | Parameter: name: Name of debug log (e.g. used for debugfs entry) |
106 | pages_index: 2^pages_index pages will be allocated per area | 108 | pages: number of pages, which will be allocated per area |
107 | nr_areas: number of debug areas | 109 | nr_areas: number of debug areas |
108 | buf_size: size of data area in each debug entry | 110 | buf_size: size of data area in each debug entry |
109 | 111 | ||
@@ -134,7 +136,7 @@ Return Value: none | |||
134 | Description: Sets new actual debug level if new_level is valid. | 136 | Description: Sets new actual debug level if new_level is valid. |
135 | 137 | ||
136 | --------------------------------------------------------------------------- | 138 | --------------------------------------------------------------------------- |
137 | +void debug_stop_all(void); | 139 | void debug_stop_all(void); |
138 | 140 | ||
139 | Parameter: none | 141 | Parameter: none |
140 | 142 | ||
@@ -270,7 +272,7 @@ Parameter: id: handle for debug log | |||
270 | Return Value: 0 : ok | 272 | Return Value: 0 : ok |
271 | < 0: Error | 273 | < 0: Error |
272 | 274 | ||
273 | Description: registers new debug view and creates proc dir entry | 275 | Description: registers new debug view and creates debugfs dir entry |
274 | 276 | ||
275 | --------------------------------------------------------------------------- | 277 | --------------------------------------------------------------------------- |
276 | int debug_unregister_view (debug_info_t * id, struct debug_view *view); | 278 | int debug_unregister_view (debug_info_t * id, struct debug_view *view); |
@@ -281,7 +283,7 @@ Parameter: id: handle for debug log | |||
281 | Return Value: 0 : ok | 283 | Return Value: 0 : ok |
282 | < 0: Error | 284 | < 0: Error |
283 | 285 | ||
284 | Description: unregisters debug view and removes proc dir entry | 286 | Description: unregisters debug view and removes debugfs dir entry |
285 | 287 | ||
286 | 288 | ||
287 | 289 | ||
@@ -308,7 +310,7 @@ static int init(void) | |||
308 | { | 310 | { |
309 | /* register 4 debug areas with one page each and 4 byte data field */ | 311 | /* register 4 debug areas with one page each and 4 byte data field */ |
310 | 312 | ||
311 | debug_info = debug_register ("test", 0, 4, 4 ); | 313 | debug_info = debug_register ("test", 1, 4, 4 ); |
312 | debug_register_view(debug_info,&debug_hex_ascii_view); | 314 | debug_register_view(debug_info,&debug_hex_ascii_view); |
313 | debug_register_view(debug_info,&debug_raw_view); | 315 | debug_register_view(debug_info,&debug_raw_view); |
314 | 316 | ||
@@ -343,7 +345,7 @@ static int init(void) | |||
343 | /* register 4 debug areas with one page each and data field for */ | 345 | /* register 4 debug areas with one page each and data field for */ |
344 | /* format string pointer + 2 varargs (= 3 * sizeof(long)) */ | 346 | /* format string pointer + 2 varargs (= 3 * sizeof(long)) */ |
345 | 347 | ||
346 | debug_info = debug_register ("test", 0, 4, sizeof(long) * 3); | 348 | debug_info = debug_register ("test", 1, 4, sizeof(long) * 3); |
347 | debug_register_view(debug_info,&debug_sprintf_view); | 349 | debug_register_view(debug_info,&debug_sprintf_view); |
348 | 350 | ||
349 | debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__); | 351 | debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__); |
@@ -362,16 +364,16 @@ module_exit(cleanup); | |||
362 | 364 | ||
363 | 365 | ||
364 | 366 | ||
365 | ProcFS Interface | 367 | Debugfs Interface |
366 | ---------------- | 368 | ---------------- |
367 | Views to the debug logs can be investigated through reading the corresponding | 369 | Views to the debug logs can be investigated through reading the corresponding |
368 | proc-files: | 370 | debugfs-files: |
369 | 371 | ||
370 | Example: | 372 | Example: |
371 | 373 | ||
372 | > ls /proc/s390dbf/dasd | 374 | > ls /sys/kernel/debug/s390dbf/dasd |
373 | flush hex_ascii level raw | 375 | flush hex_ascii level pages raw |
374 | > cat /proc/s390dbf/dasd/hex_ascii | sort +1 | 376 | > cat /sys/kernel/debug/s390dbf/dasd/hex_ascii | sort +1 |
375 | 00 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | .... | 377 | 00 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | .... |
376 | 00 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE | 378 | 00 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE |
377 | 00 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | .... | 379 | 00 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | .... |
@@ -391,25 +393,36 @@ Changing the debug level | |||
391 | Example: | 393 | Example: |
392 | 394 | ||
393 | 395 | ||
394 | > cat /proc/s390dbf/dasd/level | 396 | > cat /sys/kernel/debug/s390dbf/dasd/level |
395 | 3 | 397 | 3 |
396 | > echo "5" > /proc/s390dbf/dasd/level | 398 | > echo "5" > /sys/kernel/debug/s390dbf/dasd/level |
397 | > cat /proc/s390dbf/dasd/level | 399 | > cat /sys/kernel/debug/s390dbf/dasd/level |
398 | 5 | 400 | 5 |
399 | 401 | ||
400 | Flushing debug areas | 402 | Flushing debug areas |
401 | -------------------- | 403 | -------------------- |
402 | Debug areas can be flushed with piping the number of the desired | 404 | Debug areas can be flushed with piping the number of the desired |
403 | area (0...n) to the proc file "flush". When using "-" all debug areas | 405 | area (0...n) to the debugfs file "flush". When using "-" all debug areas |
404 | are flushed. | 406 | are flushed. |
405 | 407 | ||
406 | Examples: | 408 | Examples: |
407 | 409 | ||
408 | 1. Flush debug area 0: | 410 | 1. Flush debug area 0: |
409 | > echo "0" > /proc/s390dbf/dasd/flush | 411 | > echo "0" > /sys/kernel/debug/s390dbf/dasd/flush |
410 | 412 | ||
411 | 2. Flush all debug areas: | 413 | 2. Flush all debug areas: |
412 | > echo "-" > /proc/s390dbf/dasd/flush | 414 | > echo "-" > /sys/kernel/debug/s390dbf/dasd/flush |
415 | |||
416 | Changing the size of debug areas | ||
417 | ------------------------------------ | ||
418 | It is possible the change the size of debug areas through piping | ||
419 | the number of pages to the debugfs file "pages". The resize request will | ||
420 | also flush the debug areas. | ||
421 | |||
422 | Example: | ||
423 | |||
424 | Define 4 pages for the debug areas of debug feature "dasd": | ||
425 | > echo "4" > /sys/kernel/debug/s390dbf/dasd/pages | ||
413 | 426 | ||
414 | Stooping the debug feature | 427 | Stooping the debug feature |
415 | -------------------------- | 428 | -------------------------- |
@@ -491,7 +504,7 @@ Defining views | |||
491 | -------------- | 504 | -------------- |
492 | 505 | ||
493 | Views are specified with the 'debug_view' structure. There are defined | 506 | Views are specified with the 'debug_view' structure. There are defined |
494 | callback functions which are used for reading and writing the proc files: | 507 | callback functions which are used for reading and writing the debugfs files: |
495 | 508 | ||
496 | struct debug_view { | 509 | struct debug_view { |
497 | char name[DEBUG_MAX_PROCF_LEN]; | 510 | char name[DEBUG_MAX_PROCF_LEN]; |
@@ -525,7 +538,7 @@ typedef int (debug_input_proc_t) (debug_info_t* id, | |||
525 | The "private_data" member can be used as pointer to view specific data. | 538 | The "private_data" member can be used as pointer to view specific data. |
526 | It is not used by the debug feature itself. | 539 | It is not used by the debug feature itself. |
527 | 540 | ||
528 | The output when reading a debug-proc file is structured like this: | 541 | The output when reading a debugfs file is structured like this: |
529 | 542 | ||
530 | "prolog_proc output" | 543 | "prolog_proc output" |
531 | 544 | ||
@@ -534,13 +547,13 @@ The output when reading a debug-proc file is structured like this: | |||
534 | "header_proc output 3" "format_proc output 3" | 547 | "header_proc output 3" "format_proc output 3" |
535 | ... | 548 | ... |
536 | 549 | ||
537 | When a view is read from the proc fs, the Debug Feature calls the | 550 | When a view is read from the debugfs, the Debug Feature calls the |
538 | 'prolog_proc' once for writing the prolog. | 551 | 'prolog_proc' once for writing the prolog. |
539 | Then 'header_proc' and 'format_proc' are called for each | 552 | Then 'header_proc' and 'format_proc' are called for each |
540 | existing debug entry. | 553 | existing debug entry. |
541 | 554 | ||
542 | The input_proc can be used to implement functionality when it is written to | 555 | The input_proc can be used to implement functionality when it is written to |
543 | the view (e.g. like with 'echo "0" > /proc/s390dbf/dasd/level). | 556 | the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level). |
544 | 557 | ||
545 | For header_proc there can be used the default function | 558 | For header_proc there can be used the default function |
546 | debug_dflt_header_fn() which is defined in in debug.h. | 559 | debug_dflt_header_fn() which is defined in in debug.h. |
@@ -602,7 +615,7 @@ debug_info = debug_register ("test", 0, 4, 4 )); | |||
602 | debug_register_view(debug_info, &debug_test_view); | 615 | debug_register_view(debug_info, &debug_test_view); |
603 | for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i); | 616 | for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i); |
604 | 617 | ||
605 | > cat /proc/s390dbf/test/myview | 618 | > cat /sys/kernel/debug/s390dbf/test/myview |
606 | 00 00964419734:611402 1 - 00 88042ca This error........... | 619 | 00 00964419734:611402 1 - 00 88042ca This error........... |
607 | 00 00964419734:611405 1 - 00 88042ca That error........... | 620 | 00 00964419734:611405 1 - 00 88042ca That error........... |
608 | 00 00964419734:611408 1 - 00 88042ca Problem.............. | 621 | 00 00964419734:611408 1 - 00 88042ca Problem.............. |
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index f98c2e31c143..136d817c01ba 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt | |||
@@ -72,6 +72,8 @@ On all - write a character to /proc/sysrq-trigger. eg: | |||
72 | 'b' - Will immediately reboot the system without syncing or unmounting | 72 | 'b' - Will immediately reboot the system without syncing or unmounting |
73 | your disks. | 73 | your disks. |
74 | 74 | ||
75 | 'c' - Will perform a kexec reboot in order to take a crashdump. | ||
76 | |||
75 | 'o' - Will shut your system off (if configured and supported). | 77 | 'o' - Will shut your system off (if configured and supported). |
76 | 78 | ||
77 | 's' - Will attempt to sync all mounted filesystems. | 79 | 's' - Will attempt to sync all mounted filesystems. |
@@ -122,6 +124,9 @@ useful when you want to exit a program that will not let you switch consoles. | |||
122 | re'B'oot is good when you're unable to shut down. But you should also 'S'ync | 124 | re'B'oot is good when you're unable to shut down. But you should also 'S'ync |
123 | and 'U'mount first. | 125 | and 'U'mount first. |
124 | 126 | ||
127 | 'C'rashdump can be used to manually trigger a crashdump when the system is hung. | ||
128 | The kernel needs to have been built with CONFIG_KEXEC enabled. | ||
129 | |||
125 | 'S'ync is great when your system is locked up, it allows you to sync your | 130 | 'S'ync is great when your system is locked up, it allows you to sync your |
126 | disks and will certainly lessen the chance of data loss and fscking. Note | 131 | disks and will certainly lessen the chance of data loss and fscking. Note |
127 | that the sync hasn't taken place until you see the "OK" and "Done" appear | 132 | that the sync hasn't taken place until you see the "OK" and "Done" appear |