Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

S: Freiburg

S: Germany

N: Paul E. McKenney

E: paulmck@us.ibm.com

W: http://www.rdrop.com/users/paulmck/

D: RCU and variants

D: rcutorture module

N: Mike McLagan

E: mike.mclagan@linux.org

W: http://www.invlogic.com/~mmclagan

S: 75013 Paris

S: France

N: Dipankar Sarma

E: dipankar@in.ibm.com

D: RCU

N: Hannu Savolainen

E: hannu@opensound.com

D: Maintainer of the sound drivers until 2.1.x days.

S: MacGregor A.C.T 2615

S: Australia

N: Josh Triplett

E: josh@freedesktop.org

P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87  CA26 189B 9946 D0FE 7AFB

D: rcutorture maintainer

D: lock annotations, finding and fixing lock bugs

N: Winfried Trmper

E: winni@xpilot.org

W: http://www.shop.de/~winni/

S: USA

N: Steven Whitehouse

E: SteveW@ACM.org

E: steve@chygwyn.com

W: http://www.chygwyn.com/~steve

D: Linux DECnet project: http://www.sucs.swan.ac.uk/~rohan/DECnet/index.html

D: Linux DECnet project

D: Minor debugging of other networking protocols.

D: Misc bug fixes and filesystem development

D: Misc bug fixes and GFS2 filesystem development

N: Hans-Joachim Widmaier

E: hjw@zvw.de

!Emm/filemap.c

!Emm/memory.c

!Emm/vmalloc.c

!Imm/page_alloc.c

!Emm/mempool.c

!Emm/page-writeback.c

!Emm/truncate.c

  </authorgroup>

  <copyright>

   <year>2003-2005</year>

   <year>2003-2006</year>

   <holder>Jeff Garzik</holder>

  </copyright>

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

-------------

ERR:          0

MIS:          0

6. FAQ

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

Q1. Are there any limitations on using the MSI?