Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 40149
b: refs/heads/master
c: 73f5e28
h: refs/heads/master
i:
  40147: 07c2cb1
v: v3
  • Loading branch information
Andrew Morton authored and Franc�ois Romieu committed Oct 9, 2006
1 parent b008a59 commit abb6ab9
Show file tree
Hide file tree
Showing 2,520 changed files with 18,596 additions and 52,539 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: af60496f746596fdbc7a9ffa1a96f97e1bc59bcf
refs/heads/master: 73f5e28b336772c4b08ee82e5bf28ab872898ee1
20 changes: 0 additions & 20 deletions trunk/Documentation/HOWTO
View file
Original file line number Diff line number Diff line change
Expand Up @@ -395,26 +395,6 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here)



Managing bug reports
--------------------

One of the best ways to put into practice your hacking skills is by fixing
bugs reported by other people. Not only you will help to make the kernel
more stable, you'll learn to fix real world problems and you will improve
your skills, and other developers will be aware of your presence. Fixing
bugs is one of the best ways to get merits among other developers, because
not many people like wasting time fixing other people's bugs.

To work in the already reported bug reports, go to http://bugzilla.kernel.org.
If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)

http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors



Mailing lists
-------------

Expand Down
63 changes: 1 addition & 62 deletions trunk/Documentation/MSI-HOWTO.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -470,68 +470,7 @@ LOC: 324553 325068
ERR: 0
MIS: 0

6. MSI quirks

Several PCI chipsets or devices are known to not support MSI.
The PCI stack provides 3 possible levels of MSI disabling:
* on a single device
* on all devices behind a specific bridge
* globally

6.1. Disabling MSI on a single device

Under some circumstances, it might be required to disable MSI on a
single device, It may be achived by either not calling pci_enable_msi()
or all, or setting the pci_dev->no_msi flag before (most of the time
in a quirk).

6.2. Disabling MSI below a bridge

The vast majority of MSI quirks are required by PCI bridges not
being able to route MSI between busses. In this case, MSI have to be
disabled on all devices behind this bridge. It is achieves by setting
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
subordinate bus. There is no need to set the same flag on bridges that
are below the broken brigde. When pci_enable_msi() is called to enable
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
flag in all parent busses of the device.

Some bridges actually support dynamic MSI support enabling/disabling
by changing some bits in their PCI configuration space (especially
the Hypertransport chipsets such as the nVidia nForce and Serverworks
HT2000). It may then be required to update the NO_MSI flag on the
corresponding devices in the sysfs hierarchy. To enable MSI support
on device "0000:00:0e", do:

echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus

To disable MSI support, echo 0 instead of 1. Note that it should be
used with caution since changing this value might break interrupts.

6.3. Disabling MSI globally

Some extreme cases may require to disable MSI globally on the system.
For now, the only known case is a Serverworks PCI-X chipsets (MSI are
not supported on several busses that are not all connected to the
chipset in the Linux PCI hierarchy). In the vast majority of other
cases, disabling only behind a specific bridge is enough.

For debugging purpose, the user may also pass pci=nomsi on the kernel
command-line to explicitly disable MSI globally. But, once the appro-
priate quirks are added to the kernel, this option should not be
required anymore.

6.4. Finding why MSI cannot be enabled on a device

Assuming that MSI are not enabled on a device, you should look at
dmesg to find messages that quirks may output when disabling MSI
on some devices, some bridges or even globally.
Then, lspci -t gives the list of bridges above a device. Reading
/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
are enabled (1) or disabled (0). In 0 is found in a single bridge
msi_bus file above the device, MSI cannot be enabled.

7. FAQ
6. FAQ

Q1. Are there any limitations on using the MSI?

Expand Down
148 changes: 74 additions & 74 deletions trunk/Documentation/cpu-hotplug.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
maxcpus=2 will only boot 2. You can choose to bring the
other cpus later online, read FAQ's for more info.

additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
additional_cpus*=n Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus

(*) Option valid only for following architectures
Expand Down Expand Up @@ -101,15 +101,15 @@ cpu_possible_map/for_each_possible_cpu() to iterate.

Never use anything other than cpumask_t to represent bitmap of CPUs.

#include <linux/cpumask.h>
#include <linux/cpumask.h>

for_each_possible_cpu - Iterate over cpu_possible_map
for_each_online_cpu - Iterate over cpu_online_map
for_each_present_cpu - Iterate over cpu_present_map
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
for_each_possible_cpu - Iterate over cpu_possible_map
for_each_online_cpu - Iterate over cpu_online_map
for_each_present_cpu - Iterate over cpu_present_map
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.

#include <linux/cpu.h>
lock_cpu_hotplug() and unlock_cpu_hotplug():
#include <linux/cpu.h>
lock_cpu_hotplug() and unlock_cpu_hotplug():

The above calls are used to inhibit cpu hotplug operations. While holding the
cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid
Expand All @@ -120,7 +120,7 @@ will work as long as stop_machine_run() is used to take a cpu down.

CPU Hotplug - Frequently Asked Questions.

Q: How to enable my kernel to support CPU hotplug?
Q: How to i enable my kernel to support CPU hotplug?
A: When doing make defconfig, Enable CPU hotplug support

"Processor type and Features" -> Support for Hotpluggable CPUs
Expand All @@ -141,57 +141,57 @@ A: You should now notice an entry in sysfs.
Check if sysfs is mounted, using the "mount" command. You should notice
an entry as shown below in the output.

....
none on /sys type sysfs (rw)
....
....
none on /sys type sysfs (rw)
....

If this is not mounted, do the following.
if this is not mounted, do the following.

#mkdir /sysfs
#mount -t sysfs sys /sys
#mkdir /sysfs
#mount -t sysfs sys /sys

Now you should see entries for all present cpu, the following is an example
now you should see entries for all present cpu, the following is an example
in a 8-way system.

#pwd
#/sys/devices/system/cpu
#ls -l
total 0
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
drwxr-xr-x 13 root root 0 Sep 19 07:45 ..
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7
#pwd
#/sys/devices/system/cpu
#ls -l
total 0
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
drwxr-xr-x 13 root root 0 Sep 19 07:45 ..
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7

Under each directory you would find an "online" file which is the control
file to logically online/offline a processor.

Q: Does hot-add/hot-remove refer to physical add/remove of cpus?
A: The usage of hot-add/remove may not be very consistently used in the code.
CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel.
CONFIG_CPU_HOTPLUG enables logical online/offline capability in the kernel.
To support physical addition/removal, one would need some BIOS hooks and
the platform should have something like an attention button in PCI hotplug.
CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.

Q: How do i logically offline a CPU?
A: Do the following.

#echo 0 > /sys/devices/system/cpu/cpuX/online
#echo 0 > /sys/devices/system/cpu/cpuX/online

Once the logical offline is successful, check
once the logical offline is successful, check

#cat /proc/interrupts
#cat /proc/interrupts

You should now not see the CPU that you removed. Also online file will report
you should now not see the CPU that you removed. Also online file will report
the state as 0 when a cpu if offline and 1 when its online.

#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online
#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online

Q: Why cant i remove CPU0 on some systems?
A: Some architectures may have some special dependency on a certain CPU.
Expand Down Expand Up @@ -234,8 +234,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and
departure, how to i arrange for proper notification?
A: This is what you would need in your kernel code to receive notifications.

#include <linux/cpu.h>
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
#include <linux/cpu.h>
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
Expand Down Expand Up @@ -279,10 +279,10 @@ Q: I don't see my action being called for all CPUs already up and running?
A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
If you need to perform some action for each cpu already in the system, then

for_each_online_cpu(i) {
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
}
foobar_cpu_callback(&foobar-cpu_notifier, CPU_ONLINE, i);
}

Q: If i would like to develop cpu hotplug support for a new architecture,
what do i need at a minimum?
Expand All @@ -307,38 +307,38 @@ Q: I need to ensure that a particular cpu is not removed when there is some
work specific to this cpu is in progress.
A: First switch the current thread context to preferred cpu

int my_func_on_cpu(int cpu)
{
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
int curr_cpu, err = 0;

saved_mask = current->cpus_allowed;
cpu_set(cpu, new_mask);
err = set_cpus_allowed(current, new_mask);

if (err)
return err;

/*
* If we got scheduled out just after the return from
* set_cpus_allowed() before running the work, this ensures
* we stay locked.
*/
curr_cpu = get_cpu();

if (curr_cpu != cpu) {
err = -EAGAIN;
goto ret;
} else {
/*
* Do work : But cant sleep, since get_cpu() disables preempt
*/
}
ret:
put_cpu();
set_cpus_allowed(current, saved_mask);
return err;
}
int my_func_on_cpu(int cpu)
{
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
int curr_cpu, err = 0;

saved_mask = current->cpus_allowed;
cpu_set(cpu, new_mask);
err = set_cpus_allowed(current, new_mask);

if (err)
return err;

/*
* If we got scheduled out just after the return from
* set_cpus_allowed() before running the work, this ensures
* we stay locked.
*/
curr_cpu = get_cpu();

if (curr_cpu != cpu) {
err = -EAGAIN;
goto ret;
} else {
/*
* Do work : But cant sleep, since get_cpu() disables preempt
*/
}
ret:
put_cpu();
set_cpus_allowed(current, saved_mask);
return err;
}


Q: How do we determine how many CPUs are available for hotplug.
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/feature-removal-schedule.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -255,7 +255,7 @@ Who: Stephen Hemminger <shemminger@osdl.org>


What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
When: October 2008
When: Oktober 2008
Why: The stacking of class devices makes these values misleading and
inconsistent.
Class devices should not carry any of these properties, and bus
Expand Down
2 changes: 0 additions & 2 deletions trunk/Documentation/filesystems/00-INDEX
View file
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,6 @@ ext2.txt
- info, mount options and specifications for the Ext2 filesystem.
ext3.txt
- info, mount options and specifications for the Ext3 filesystem.
ext4.txt
- info, mount options and specifications for the Ext4 filesystem.
files.txt
- info on file management in the Linux kernel.
fuse.txt
Expand Down
Loading

0 comments on commit abb6ab9

Please sign in to comment.