Merge ../linux-2.6/
authorJames Bottomley <jejb@mulgrave.il.steeleye.com>
Wed, 28 Jun 2006 18:06:39 +0000 (14:06 -0400)
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>
Wed, 28 Jun 2006 18:06:39 +0000 (14:06 -0400)
Conflicts:

drivers/scsi/aacraid/comminit.c

Fixed up by removing the now renamed CONFIG_IOMMU option from
aacraid

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
1119 files changed:
CREDITS
Documentation/DocBook/kernel-locking.tmpl
Documentation/RCU/torture.txt
Documentation/arm/Samsung-S3C24XX/Overview.txt
Documentation/arm/Samsung-S3C24XX/S3C2412.txt [new file with mode: 0644]
Documentation/arm/Samsung-S3C24XX/S3C2413.txt [new file with mode: 0644]
Documentation/atomic_ops.txt
Documentation/console/console.txt [new file with mode: 0644]
Documentation/driver-model/overview.txt
Documentation/fb/fbcon.txt
Documentation/filesystems/ext3.txt
Documentation/kbuild/makefiles.txt
Documentation/kdump/gdbmacros.txt
Documentation/kernel-parameters.txt
Documentation/keys.txt
Documentation/md.txt
Documentation/pi-futex.txt [new file with mode: 0644]
Documentation/robust-futexes.txt
Documentation/rt-mutex-design.txt [new file with mode: 0644]
Documentation/rt-mutex.txt [new file with mode: 0644]
Documentation/scsi/ppa.txt
Documentation/tty.txt
Documentation/video4linux/README.pvrusb2 [new file with mode: 0644]
Documentation/x86_64/boot-options.txt
MAINTAINERS
Makefile
arch/alpha/kernel/setup.c
arch/alpha/oprofile/common.c
arch/arm/Kconfig
arch/arm/Makefile
arch/arm/boot/compressed/head-at91rm9200.S
arch/arm/boot/compressed/ll_char_wr.S
arch/arm/common/locomo.c
arch/arm/configs/onearm_defconfig [new file with mode: 0644]
arch/arm/configs/s3c2410_defconfig
arch/arm/kernel/entry-common.S
arch/arm/kernel/head-nommu.S
arch/arm/kernel/head.S
arch/arm/kernel/setup.c
arch/arm/lib/backtrace.S
arch/arm/lib/clear_user.S
arch/arm/lib/copy_page.S
arch/arm/lib/csumipv6.S
arch/arm/lib/delay.S
arch/arm/lib/ecard.S
arch/arm/lib/findbit.S
arch/arm/lib/io-readsb.S
arch/arm/lib/io-readsw-armv3.S
arch/arm/lib/io-writesb.S
arch/arm/lib/io-writesw-armv3.S
arch/arm/lib/memchr.S
arch/arm/lib/memset.S
arch/arm/lib/memzero.S
arch/arm/lib/strchr.S
arch/arm/lib/strncpy_from_user.S
arch/arm/lib/strnlen_user.S
arch/arm/lib/strrchr.S
arch/arm/lib/uaccess.S
arch/arm/mach-at91rm9200/Kconfig
arch/arm/mach-at91rm9200/Makefile
arch/arm/mach-at91rm9200/board-1arm.c [new file with mode: 0644]
arch/arm/mach-ixp4xx/Kconfig
arch/arm/mach-ixp4xx/Makefile
arch/arm/mach-pxa/sleep.S
arch/arm/mach-s3c2410/Kconfig
arch/arm/mach-s3c2410/sleep.S
arch/arm/mach-sa1100/sleep.S
arch/arm/mm/copypage-v3.S
arch/arm/mm/proc-v6.S
arch/arm/nwfpe/entry26.S
arch/arm/tools/mach-types
arch/i386/Kconfig
arch/i386/Kconfig.cpu
arch/i386/boot/Makefile
arch/i386/boot/compressed/misc.c
arch/i386/boot/video.S
arch/i386/crypto/aes-i586-asm.S
arch/i386/crypto/aes.c
arch/i386/kernel/Makefile
arch/i386/kernel/alternative.c
arch/i386/kernel/apic.c
arch/i386/kernel/apm.c
arch/i386/kernel/asm-offsets.c
arch/i386/kernel/cpu/amd.c
arch/i386/kernel/cpu/common.c
arch/i386/kernel/cpu/cyrix.c
arch/i386/kernel/cpu/intel.c
arch/i386/kernel/cpu/intel_cacheinfo.c
arch/i386/kernel/cpu/proc.c
arch/i386/kernel/cpuid.c
arch/i386/kernel/crash.c
arch/i386/kernel/entry.S
arch/i386/kernel/hpet.c [new file with mode: 0644]
arch/i386/kernel/i8253.c [new file with mode: 0644]
arch/i386/kernel/i8259.c
arch/i386/kernel/io_apic.c
arch/i386/kernel/irq.c
arch/i386/kernel/kprobes.c
arch/i386/kernel/machine_kexec.c
arch/i386/kernel/msr.c
arch/i386/kernel/nmi.c
arch/i386/kernel/numaq.c
arch/i386/kernel/process.c
arch/i386/kernel/scx200.c
arch/i386/kernel/setup.c
arch/i386/kernel/signal.c
arch/i386/kernel/smp.c
arch/i386/kernel/smpboot.c
arch/i386/kernel/sysenter.c
arch/i386/kernel/time.c
arch/i386/kernel/timers/Makefile [deleted file]
arch/i386/kernel/timers/common.c [deleted file]
arch/i386/kernel/timers/timer.c [deleted file]
arch/i386/kernel/timers/timer_cyclone.c [deleted file]
arch/i386/kernel/timers/timer_hpet.c [deleted file]
arch/i386/kernel/timers/timer_none.c [deleted file]
arch/i386/kernel/timers/timer_pit.c [deleted file]
arch/i386/kernel/timers/timer_pm.c [deleted file]
arch/i386/kernel/timers/timer_tsc.c [deleted file]
arch/i386/kernel/topology.c
arch/i386/kernel/traps.c
arch/i386/kernel/tsc.c [new file with mode: 0644]
arch/i386/kernel/vmlinux.lds.S
arch/i386/kernel/vsyscall-sysenter.S
arch/i386/kernel/vsyscall.lds.S
arch/i386/lib/delay.c
arch/i386/mach-voyager/setup.c
arch/i386/mach-voyager/voyager_smp.c
arch/i386/mm/fault.c
arch/i386/mm/init.c
arch/i386/mm/pageattr.c
arch/i386/oprofile/nmi_int.c
arch/i386/oprofile/op_model_athlon.c
arch/i386/oprofile/op_model_p4.c
arch/i386/oprofile/op_model_ppro.c
arch/i386/pci/pcbios.c
arch/ia64/Kconfig
arch/ia64/kernel/palinfo.c
arch/ia64/kernel/process.c
arch/ia64/kernel/salinfo.c
arch/ia64/kernel/topology.c
arch/ia64/mm/discontig.c
arch/ia64/mm/fault.c
arch/ia64/mm/init.c
arch/ia64/sn/kernel/irq.c
arch/m32r/kernel/setup.c
arch/m68k/mm/memory.c
arch/m68k/sun3/sun3dvma.c
arch/m68knommu/Kconfig
arch/m68knommu/Makefile
arch/m68knommu/defconfig
arch/m68knommu/kernel/vmlinux.lds.S
arch/m68knommu/platform/5307/head.S
arch/m68knommu/platform/68328/head-pilot.S
arch/m68knommu/platform/68328/head-ram.S
arch/m68knommu/platform/68328/head-rom.S
arch/m68knommu/platform/68360/head-ram.S
arch/m68knommu/platform/68360/head-rom.S
arch/mips/kernel/smp.c
arch/mips/kernel/smtc.c
arch/mips/momentum/ocelot_g/gt-irq.c
arch/mips/oprofile/common.c
arch/mips/sgi-ip22/ip22-reset.c
arch/mips/sgi-ip32/ip32-reset.c
arch/parisc/kernel/topology.c
arch/powerpc/kernel/crash.c
arch/powerpc/kernel/machine_kexec_32.c
arch/powerpc/kernel/setup_32.c
arch/powerpc/kernel/sysfs.c
arch/powerpc/kernel/time.c
arch/powerpc/mm/fault.c
arch/powerpc/mm/init_64.c
arch/powerpc/mm/mem.c
arch/powerpc/mm/numa.c
arch/powerpc/oprofile/common.c
arch/powerpc/platforms/cell/spufs/switch.c
arch/powerpc/platforms/powermac/pfunc_core.c
arch/powerpc/platforms/pseries/eeh_cache.c
arch/powerpc/platforms/pseries/eeh_event.c
arch/powerpc/sysdev/mmio_nvram.c
arch/ppc/kernel/machine_kexec.c
arch/ppc/kernel/setup.c
arch/s390/appldata/appldata_base.c
arch/s390/crypto/aes_s390.c
arch/s390/crypto/des_s390.c
arch/s390/crypto/sha1_s390.c
arch/s390/crypto/sha256_s390.c
arch/s390/kernel/machine_kexec.c
arch/s390/kernel/smp.c
arch/s390/kernel/vtime.c
arch/sh/Makefile
arch/sh/kernel/machine_kexec.c
arch/sh/kernel/setup.c
arch/sh/oprofile/op_model_sh7750.c
arch/sh64/kernel/setup.c
arch/sparc/kernel/of_device.c
arch/sparc/kernel/prom.c
arch/sparc/lib/Makefile
arch/sparc/lib/iomap.c [new file with mode: 0644]
arch/sparc64/kernel/auxio.c
arch/sparc64/kernel/irq.c
arch/sparc64/kernel/of_device.c
arch/sparc64/kernel/prom.c
arch/sparc64/kernel/setup.c
arch/sparc64/mm/fault.c
arch/sparc64/mm/init.c
arch/um/drivers/ubd_kern.c
arch/x86_64/Kconfig
arch/x86_64/Kconfig.debug
arch/x86_64/Makefile
arch/x86_64/boot/Makefile
arch/x86_64/boot/compressed/misc.c
arch/x86_64/boot/tools/build.c
arch/x86_64/boot/video.S
arch/x86_64/crypto/aes-x86_64-asm.S
arch/x86_64/crypto/aes.c
arch/x86_64/defconfig
arch/x86_64/ia32/fpu32.c
arch/x86_64/ia32/ia32_signal.c
arch/x86_64/ia32/ia32entry.S
arch/x86_64/ia32/ptrace32.c
arch/x86_64/ia32/sys_ia32.c
arch/x86_64/kernel/Makefile
arch/x86_64/kernel/aperture.c
arch/x86_64/kernel/apic.c
arch/x86_64/kernel/asm-offsets.c
arch/x86_64/kernel/crash.c
arch/x86_64/kernel/e820.c
arch/x86_64/kernel/entry.S
arch/x86_64/kernel/genapic_flat.c
arch/x86_64/kernel/head64.c
arch/x86_64/kernel/i8259.c
arch/x86_64/kernel/io_apic.c
arch/x86_64/kernel/irq.c
arch/x86_64/kernel/k8.c [new file with mode: 0644]
arch/x86_64/kernel/machine_kexec.c
arch/x86_64/kernel/mce.c
arch/x86_64/kernel/mce_amd.c
arch/x86_64/kernel/module.c
arch/x86_64/kernel/nmi.c
arch/x86_64/kernel/pci-calgary.c [new file with mode: 0644]
arch/x86_64/kernel/pci-dma.c
arch/x86_64/kernel/pci-gart.c
arch/x86_64/kernel/pci-nommu.c
arch/x86_64/kernel/pci-swiotlb.c
arch/x86_64/kernel/pmtimer.c
arch/x86_64/kernel/process.c
arch/x86_64/kernel/reboot.c
arch/x86_64/kernel/setup.c
arch/x86_64/kernel/setup64.c
arch/x86_64/kernel/signal.c
arch/x86_64/kernel/smp.c
arch/x86_64/kernel/smpboot.c
arch/x86_64/kernel/tce.c [new file with mode: 0644]
arch/x86_64/kernel/time.c
arch/x86_64/kernel/traps.c
arch/x86_64/kernel/vmlinux.lds.S
arch/x86_64/kernel/vsyscall.c
arch/x86_64/kernel/x8664_ksyms.c
arch/x86_64/lib/csum-partial.c
arch/x86_64/lib/csum-wrappers.c
arch/x86_64/lib/delay.c
arch/x86_64/lib/memmove.c
arch/x86_64/lib/usercopy.c
arch/x86_64/mm/fault.c
arch/x86_64/mm/init.c
arch/x86_64/mm/ioremap.c
arch/x86_64/pci/k8-bus.c
arch/xtensa/Makefile
arch/xtensa/kernel/time.c
arch/xtensa/kernel/traps.c
block/as-iosched.c
block/ll_rw_blk.c
crypto/Kconfig
crypto/aes.c
crypto/anubis.c
crypto/api.c
crypto/arc4.c
crypto/blowfish.c
crypto/cast5.c
crypto/cast6.c
crypto/cipher.c
crypto/compress.c
crypto/crc32c.c
crypto/crypto_null.c
crypto/deflate.c
crypto/des.c
crypto/digest.c
crypto/khazad.c
crypto/md4.c
crypto/md5.c
crypto/michael_mic.c
crypto/serpent.c
crypto/sha1.c
crypto/sha256.c
crypto/sha512.c
crypto/tcrypt.c
crypto/tcrypt.h
crypto/tea.c
crypto/tgr192.c
crypto/twofish.c
crypto/wp512.c
drivers/Makefile
drivers/acpi/Kconfig
drivers/acpi/acpi_memhotplug.c
drivers/acpi/numa.c
drivers/acpi/processor_idle.c
drivers/atm/firestream.c
drivers/base/cpu.c
drivers/base/dmapool.c
drivers/base/memory.c
drivers/base/node.c
drivers/base/power/resume.c
drivers/base/power/suspend.c
drivers/base/topology.c
drivers/block/loop.c
drivers/bluetooth/dtl1_cs.c
drivers/char/Kconfig
drivers/char/Makefile
drivers/char/agp/Kconfig
drivers/char/agp/amd-k7-agp.c
drivers/char/agp/amd64-agp.c
drivers/char/agp/ati-agp.c
drivers/char/agp/efficeon-agp.c
drivers/char/agp/sgi-agp.c
drivers/char/drm/drm_memory_debug.h
drivers/char/drm/via_dmablit.c
drivers/char/epca.c
drivers/char/hangcheck-timer.c
drivers/char/hvcs.c
drivers/char/hw_random.c [deleted file]
drivers/char/hw_random/Kconfig [new file with mode: 0644]
drivers/char/hw_random/Makefile [new file with mode: 0644]
drivers/char/hw_random/amd-rng.c [new file with mode: 0644]
drivers/char/hw_random/core.c [new file with mode: 0644]
drivers/char/hw_random/geode-rng.c [new file with mode: 0644]
drivers/char/hw_random/intel-rng.c [new file with mode: 0644]
drivers/char/hw_random/ixp4xx-rng.c [new file with mode: 0644]
drivers/char/hw_random/omap-rng.c [new file with mode: 0644]
drivers/char/hw_random/via-rng.c [new file with mode: 0644]
drivers/char/ipmi/ipmi_msghandler.c
drivers/char/ipmi/ipmi_si_intf.c
drivers/char/keyboard.c
drivers/char/moxa.c
drivers/char/nsc_gpio.c [new file with mode: 0644]
drivers/char/pc8736x_gpio.c [new file with mode: 0644]
drivers/char/rio/riointr.c
drivers/char/scx200_gpio.c
drivers/char/specialix.c
drivers/char/stallion.c
drivers/char/sx.c
drivers/char/tlclk.c
drivers/char/tty_io.c
drivers/char/vt.c
drivers/clocksource/Makefile [new file with mode: 0644]
drivers/clocksource/acpi_pm.c [new file with mode: 0644]
drivers/clocksource/cyclone.c [new file with mode: 0644]
drivers/clocksource/scx200_hrt.c [new file with mode: 0644]
drivers/cpufreq/cpufreq.c
drivers/cpufreq/cpufreq_stats.c
drivers/crypto/padlock-aes.c
drivers/dma/ioatdma.c
drivers/hwmon/asb100.c
drivers/hwmon/lm78.c
drivers/hwmon/lm80.c
drivers/hwmon/lm87.c
drivers/hwmon/sis5595.c
drivers/hwmon/smsc47m1.c
drivers/hwmon/w83627hf.c
drivers/hwmon/w83781d.c
drivers/hwmon/w83792d.c
drivers/i2c/busses/i2c-i801.c
drivers/ide/ide-disk.c
drivers/ide/ide-io.c
drivers/ide/ide-lib.c
drivers/ide/ide-timing.h
drivers/ide/pci/amd74xx.c
drivers/ide/pci/pdc202xx_old.c
drivers/ide/pci/piix.c
drivers/ieee1394/eth1394.c
drivers/ieee1394/hosts.c
drivers/ieee1394/ieee1394_core.h
drivers/ieee1394/raw1394.c
drivers/infiniband/core/cma.c
drivers/infiniband/core/mad.c
drivers/infiniband/core/mad_rmpp.c
drivers/infiniband/ulp/ipoib/ipoib_multicast.c
drivers/input/evdev.c
drivers/input/input.c
drivers/input/joydev.c
drivers/input/joystick/a3d.c
drivers/input/joystick/analog.c
drivers/input/joystick/cobra.c
drivers/input/joystick/db9.c
drivers/input/joystick/gamecon.c
drivers/input/joystick/gf2k.c
drivers/input/joystick/grip.c
drivers/input/joystick/guillemot.c
drivers/input/joystick/iforce/iforce-ff.c
drivers/input/joystick/iforce/iforce-main.c
drivers/input/joystick/interact.c
drivers/input/joystick/magellan.c
drivers/input/joystick/sidewinder.c
drivers/input/joystick/spaceball.c
drivers/input/joystick/spaceorb.c
drivers/input/joystick/stinger.c
drivers/input/joystick/twidjoy.c
drivers/input/joystick/warrior.c
drivers/input/keyboard/atkbd.c
drivers/input/keyboard/lkkbd.c
drivers/input/keyboard/newtonkbd.c
drivers/input/keyboard/sunkbd.c
drivers/input/keyboard/xtkbd.c
drivers/input/mouse/alps.c
drivers/input/mouse/psmouse-base.c
drivers/input/mouse/sermouse.c
drivers/input/mouse/vsxxxaa.c
drivers/input/mousedev.c
drivers/input/touchscreen/gunze.c
drivers/input/touchscreen/h3600_ts_input.c
drivers/input/touchscreen/mtouch.c
drivers/input/tsdev.c
drivers/isdn/capi/capi.c
drivers/isdn/divert/isdn_divert.c
drivers/isdn/gigaset/bas-gigaset.c
drivers/isdn/gigaset/common.c
drivers/isdn/gigaset/ev-layer.c
drivers/isdn/hisax/q931.c
drivers/isdn/i4l/isdn_common.c
drivers/isdn/i4l/isdn_tty.c
drivers/leds/led-core.c
drivers/leds/led-triggers.c
drivers/macintosh/Makefile
drivers/macintosh/adbhid.c
drivers/macintosh/via-pmu-event.c [new file with mode: 0644]
drivers/macintosh/via-pmu-event.h [new file with mode: 0644]
drivers/macintosh/via-pmu.c
drivers/md/Kconfig
drivers/md/Makefile
drivers/md/bitmap.c
drivers/md/dm-crypt.c
drivers/md/dm-emc.c
drivers/md/dm-exception-store.c
drivers/md/dm-ioctl.c
drivers/md/dm-linear.c
drivers/md/dm-log.c
drivers/md/dm-mpath.c
drivers/md/dm-raid1.c
drivers/md/dm-round-robin.c
drivers/md/dm-snap.c
drivers/md/dm-stripe.c
drivers/md/dm-table.c
drivers/md/dm-target.c
drivers/md/dm-zero.c
drivers/md/dm.c
drivers/md/dm.h
drivers/md/kcopyd.c
drivers/md/linear.c
drivers/md/md.c
drivers/md/raid1.c
drivers/md/raid10.c
drivers/md/raid5.c
drivers/md/raid6main.c [deleted file]
drivers/media/Kconfig
drivers/media/dvb/dvb-core/dvb_frontend.c
drivers/media/dvb/ttpci/av7110.c
drivers/media/dvb/ttpci/av7110_av.c
drivers/media/dvb/ttpci/av7110_v4l.c
drivers/media/video/Kconfig
drivers/media/video/Makefile
drivers/media/video/bt8xx/bttv-cards.c
drivers/media/video/cx2341x.c
drivers/media/video/cx88/Kconfig
drivers/media/video/cx88/Makefile
drivers/media/video/cx88/cx88-blackbird.c
drivers/media/video/cx88/cx88-cards.c
drivers/media/video/cx88/cx88-core.c
drivers/media/video/cx88/cx88-i2c.c
drivers/media/video/cx88/cx88-tvaudio.c
drivers/media/video/cx88/cx88-video.c
drivers/media/video/cx88/cx88.h
drivers/media/video/pvrusb2/Kconfig [new file with mode: 0644]
drivers/media/video/pvrusb2/Makefile [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-audio.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-audio.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-context.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-context.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-ctrl.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-ctrl.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-debug.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-debugifc.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-debugifc.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-demod.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-demod.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-eeprom.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-eeprom.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-encoder.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-encoder.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-hdw.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-hdw.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-i2c-chips-v4l2.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-i2c-core.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-i2c-core.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-io.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-io.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-ioread.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-ioread.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-main.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-std.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-std.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-sysfs.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-sysfs.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-tuner.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-tuner.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-util.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-v4l2.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-v4l2.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-video-v4l.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-video-v4l.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-wm8775.c [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2-wm8775.h [new file with mode: 0644]
drivers/media/video/pvrusb2/pvrusb2.h [new file with mode: 0644]
drivers/media/video/saa7134/saa6752hs.c
drivers/media/video/stradis.c
drivers/media/video/tda9887.c
drivers/media/video/tuner-core.c
drivers/media/video/usbvideo/quickcam_messenger.c
drivers/media/video/v4l2-common.c
drivers/message/fusion/mptfc.c
drivers/message/i2o/iop.c
drivers/mfd/ucb1x00-core.c
drivers/misc/ibmasm/module.c
drivers/mtd/Kconfig
drivers/mtd/chips/cfi_cmdset_0001.c
drivers/mtd/chips/jedec.c
drivers/mtd/chips/map_absent.c
drivers/mtd/chips/map_ram.c
drivers/mtd/chips/map_rom.c
drivers/mtd/devices/block2mtd.c
drivers/mtd/devices/ms02-nv.c
drivers/mtd/devices/mtd_dataflash.c
drivers/mtd/devices/phram.c
drivers/mtd/devices/pmc551.c
drivers/mtd/devices/slram.c
drivers/mtd/maps/Kconfig
drivers/mtd/maps/ixp2000.c
drivers/mtd/maps/physmap.c
drivers/mtd/maps/sun_uflash.c
drivers/mtd/mtdchar.c
drivers/mtd/nand/nand_base.c
drivers/mtd/nand/ndfc.c
drivers/mtd/nand/s3c2410.c
drivers/mtd/nand/ts7250.c
drivers/net/3c501.c
drivers/net/3c59x.c
drivers/net/dl2k.h
drivers/net/dm9000.c
drivers/net/eepro100.c
drivers/net/epic100.c
drivers/net/fealnx.c
drivers/net/fec.c
drivers/net/fs_enet/fs_enet-mii.c
drivers/net/hamradio/dmascc.c
drivers/net/irda/irport.c
drivers/net/irda/nsc-ircc.c
drivers/net/natsemi.c
drivers/net/pcmcia/smc91c92_cs.c
drivers/net/pcnet32.c
drivers/net/phy/lxt.c
drivers/net/ppp_generic.c
drivers/net/tulip/winbond-840.c
drivers/net/wan/c101.c
drivers/net/wan/n2.c
drivers/net/wan/pci200syn.c
drivers/net/wireless/bcm43xx/Kconfig
drivers/net/wireless/bcm43xx/bcm43xx.h
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/ipw2100.c
drivers/net/wireless/ipw2200.c
drivers/net/yellowfin.c
drivers/parport/parport_gsc.c
drivers/parport/parport_gsc.h
drivers/parport/parport_pc.c
drivers/parport/parport_sunbpp.c
drivers/parport/procfs.c
drivers/pci/msi-apic.c
drivers/pci/pci.c
drivers/pcmcia/m8xx_pcmcia.c
drivers/rapidio/rio-access.c
drivers/rtc/class.c
drivers/rtc/rtc-ds1553.c
drivers/rtc/rtc-sa1100.c
drivers/rtc/rtc-vr41xx.c
drivers/s390/block/dasd_eer.c
drivers/s390/net/lcs.c
drivers/s390/scsi/zfcp_erp.c
drivers/sbus/char/cpwatchdog.c
drivers/sbus/char/openprom.c
drivers/sbus/char/riowatchdog.c
drivers/scsi/Kconfig
drivers/scsi/NCR5380.c
drivers/scsi/advansys.c
drivers/scsi/ahci.c
drivers/scsi/ata_piix.c
drivers/scsi/dc395x.c
drivers/scsi/ibmmca.c
drivers/scsi/imm.c
drivers/scsi/imm.h
drivers/scsi/ips.c
drivers/scsi/libata-core.c
drivers/scsi/libata-eh.c
drivers/scsi/libata-scsi.c
drivers/scsi/libata.h
drivers/scsi/ncr53c8xx.c
drivers/scsi/ppa.c
drivers/scsi/ppa.h
drivers/scsi/qla2xxx/qla_init.c
drivers/scsi/sata_nv.c
drivers/scsi/sata_sil.c
drivers/scsi/sata_sil24.c
drivers/scsi/sata_svw.c
drivers/scsi/sata_uli.c
drivers/scsi/sata_via.c
drivers/scsi/sata_vsc.c
drivers/scsi/st.c
drivers/serial/8250_pnp.c
drivers/sn/ioc3.c
drivers/telephony/ixj.c
drivers/usb/host/hc_crisv10.c
drivers/usb/input/fixp-arith.h
drivers/usb/input/hid-debug.h
drivers/usb/serial/whiteheat.c
drivers/usb/storage/usb.h
drivers/video/Kconfig
drivers/video/Makefile
drivers/video/aty/aty128fb.c
drivers/video/aty/atyfb_base.c
drivers/video/aty/mach64_accel.c
drivers/video/aty/mach64_cursor.c
drivers/video/aty/radeon_base.c
drivers/video/au1100fb.c
drivers/video/backlight/Kconfig
drivers/video/backlight/Makefile
drivers/video/backlight/hp680_bl.c
drivers/video/backlight/locomolcd.c
drivers/video/cfbimgblt.c
drivers/video/cirrusfb.c
drivers/video/console/fbcon.c
drivers/video/console/fbcon.h
drivers/video/console/mdacon.c
drivers/video/console/newport_con.c
drivers/video/console/promcon.c
drivers/video/console/sticon.c
drivers/video/console/vgacon.c
drivers/video/epson1355fb.c
drivers/video/fbcvt.c
drivers/video/fbmem.c
drivers/video/fbmon.c
drivers/video/fbsysfs.c
drivers/video/geode/gx1fb_core.c
drivers/video/geode/gxfb_core.c
drivers/video/i810/i810_main.c
drivers/video/imacfb.c [new file with mode: 0644]
drivers/video/macmodes.c
drivers/video/macmodes.h
drivers/video/modedb.c
drivers/video/neofb.c
drivers/video/nvidia/nv_hw.c
drivers/video/nvidia/nvidia.c
drivers/video/riva/fbdev.c
drivers/video/s3c2410fb.c
drivers/video/savage/savagefb.h
drivers/video/savage/savagefb_driver.c
drivers/video/sis/sis_main.c
drivers/video/skeletonfb.c
drivers/video/tgafb.c
drivers/video/vesafb.c
drivers/video/vfb.c
drivers/video/vga16fb.c
fs/9p/mux.c
fs/Kconfig
fs/afs/cell.c
fs/afs/kafsasyncd.c
fs/afs/server.c
fs/afs/vlocation.c
fs/afs/vnode.c
fs/aio.c
fs/autofs4/expire.c
fs/buffer.c
fs/cifs/CHANGES
fs/cifs/Makefile
fs/cifs/README
fs/cifs/asn1.c
fs/cifs/cifs_debug.c
fs/cifs/cifs_debug.h
fs/cifs/cifs_unicode.c
fs/cifs/cifsencrypt.c
fs/cifs/cifsfs.c
fs/cifs/cifsfs.h
fs/cifs/cifsglob.h
fs/cifs/cifspdu.h
fs/cifs/cifsproto.h
fs/cifs/cifssmb.c
fs/cifs/connect.c
fs/cifs/dir.c
fs/cifs/fcntl.c
fs/cifs/file.c
fs/cifs/inode.c
fs/cifs/link.c
fs/cifs/misc.c
fs/cifs/netmisc.c
fs/cifs/ntlmssp.c [deleted file]
fs/cifs/readdir.c
fs/cifs/sess.c [new file with mode: 0644]
fs/cifs/smbencrypt.c
fs/cifs/transport.c
fs/coda/psdev.c
fs/coda/upcall.c
fs/compat.c
fs/compat_ioctl.c
fs/configfs/dir.c
fs/dcache.c
fs/dquot.c
fs/exec.c
fs/ext3/super.c
fs/jbd/journal.c
fs/jffs2/acl.c
fs/jffs2/erase.c
fs/jffs2/fs.c
fs/jffs2/gc.c
fs/jffs2/jffs2_fs_sb.h
fs/jffs2/malloc.c
fs/jffs2/nodelist.c
fs/jffs2/nodemgmt.c
fs/jffs2/readinode.c
fs/jffs2/scan.c
fs/jffs2/summary.c
fs/jffs2/wbuf.c
fs/jffs2/xattr.c
fs/jffs2/xattr.h
fs/jfs/jfs_extent.c
fs/libfs.c
fs/namespace.c
fs/nfs/direct.c
fs/nfs/inode.c
fs/nfs/internal.h
fs/nfs/pagelist.c
fs/nfs/read.c
fs/nfs/write.c
fs/nfsd/nfs4state.c
fs/nfsd/nfscache.c
fs/ocfs2/cluster/heartbeat.c
fs/ocfs2/cluster/tcp.c
fs/ocfs2/dlm/dlmast.c
fs/ocfs2/dlm/dlmcommon.h
fs/ocfs2/dlm/dlmconvert.c
fs/ocfs2/dlm/dlmdebug.c
fs/ocfs2/dlm/dlmdebug.h [deleted file]
fs/ocfs2/dlm/dlmdomain.c
fs/ocfs2/dlm/dlmfs.c
fs/ocfs2/dlm/dlmlock.c
fs/ocfs2/dlm/dlmmaster.c
fs/ocfs2/dlm/dlmrecovery.c
fs/ocfs2/dlm/dlmthread.c
fs/ocfs2/dlm/dlmunlock.c
fs/ocfs2/dlm/userdlm.c
fs/ocfs2/dlmglue.c
fs/ocfs2/journal.c
fs/ocfs2/vote.c
fs/openpromfs/inode.c
fs/pnode.c
fs/proc/base.c
fs/proc/inode.c
fs/proc/internal.h
fs/proc/task_mmu.c
fs/proc/task_nommu.c
fs/reiserfs/file.c
fs/reiserfs/journal.c
fs/smbfs/request.c
fs/smbfs/smbiod.c
fs/sysfs/dir.c
fs/ufs/inode.c
fs/xfs/linux-2.6/xfs_iops.c
fs/xfs/linux-2.6/xfs_linux.h
fs/xfs/linux-2.6/xfs_vnode.h
fs/xfs/xfs_behavior.h
fs/xfs/xfs_inode.c
fs/xfs/xfs_log.c
fs/xfs/xfs_log_recover.c
fs/xfs/xfs_mount.c
fs/xfs/xfs_rtalloc.c
fs/xfs/xfs_trans.h
fs/xfs/xfs_vnodeops.c
include/asm-alpha/core_t2.h
include/asm-arm/arch-s3c2410/regs-nand.h
include/asm-arm/assembler.h
include/asm-arm/hardware/locomo.h
include/asm-generic/bug.h
include/asm-i386/alternative.h
include/asm-i386/apic.h
include/asm-i386/cpu.h
include/asm-i386/cpufeature.h
include/asm-i386/delay.h
include/asm-i386/dwarf2.h [new file with mode: 0644]
include/asm-i386/elf.h
include/asm-i386/fixmap.h
include/asm-i386/hw_irq.h
include/asm-i386/intel_arch_perfmon.h [new file with mode: 0644]
include/asm-i386/k8.h [new file with mode: 0644]
include/asm-i386/kdebug.h
include/asm-i386/kprobes.h
include/asm-i386/local.h
include/asm-i386/mach-default/mach_ipi.h
include/asm-i386/mach-default/mach_timer.h
include/asm-i386/mach-summit/mach_mpparse.h
include/asm-i386/mmu.h
include/asm-i386/nmi.h
include/asm-i386/node.h [deleted file]
include/asm-i386/page.h
include/asm-i386/processor.h
include/asm-i386/system.h
include/asm-i386/thread_info.h
include/asm-i386/timer.h
include/asm-i386/timex.h
include/asm-i386/topology.h
include/asm-i386/tsc.h [new file with mode: 0644]
include/asm-i386/unwind.h [new file with mode: 0644]
include/asm-ia64/kdebug.h
include/asm-ia64/kprobes.h
include/asm-ia64/nodedata.h
include/asm-ia64/thread_info.h
include/asm-ia64/topology.h
include/asm-m32r/system.h
include/asm-m68knommu/page_offset.h
include/asm-m68knommu/ptrace.h
include/asm-powerpc/kdebug.h
include/asm-powerpc/kprobes.h
include/asm-powerpc/topology.h
include/asm-sparc/io.h
include/asm-sparc/prom.h
include/asm-sparc64/dma-mapping.h
include/asm-sparc64/floppy.h
include/asm-sparc64/kdebug.h
include/asm-sparc64/kprobes.h
include/asm-sparc64/prom.h
include/asm-sparc64/topology.h
include/asm-x86_64/alternative.h [new file with mode: 0644]
include/asm-x86_64/apic.h
include/asm-x86_64/atomic.h
include/asm-x86_64/bitops.h
include/asm-x86_64/calgary.h [new file with mode: 0644]
include/asm-x86_64/cpufeature.h
include/asm-x86_64/dma-mapping.h
include/asm-x86_64/dma.h
include/asm-x86_64/gart-mapping.h [deleted file]
include/asm-x86_64/hpet.h
include/asm-x86_64/hw_irq.h
include/asm-x86_64/ia32_unistd.h
include/asm-x86_64/intel_arch_perfmon.h [new file with mode: 0644]
include/asm-x86_64/k8.h [new file with mode: 0644]
include/asm-x86_64/kdebug.h
include/asm-x86_64/kprobes.h
include/asm-x86_64/local.h
include/asm-x86_64/mce.h
include/asm-x86_64/mutex.h
include/asm-x86_64/nmi.h
include/asm-x86_64/pci.h
include/asm-x86_64/pgtable.h
include/asm-x86_64/processor.h
include/asm-x86_64/proto.h
include/asm-x86_64/rwlock.h
include/asm-x86_64/semaphore.h
include/asm-x86_64/smp.h
include/asm-x86_64/spinlock.h
include/asm-x86_64/string.h
include/asm-x86_64/system.h
include/asm-x86_64/tce.h [new file with mode: 0644]
include/asm-x86_64/thread_info.h
include/asm-x86_64/topology.h
include/asm-x86_64/unwind.h [new file with mode: 0644]
include/keys/user-type.h
include/linux/acpi.h
include/linux/bitmap.h
include/linux/buffer_head.h
include/linux/clocksource.h [new file with mode: 0644]
include/linux/compat.h
include/linux/compat_ioctl.h
include/linux/console.h
include/linux/cpu.h
include/linux/crypto.h
include/linux/device-mapper.h
include/linux/dm-ioctl.h
include/linux/dmaengine.h
include/linux/fb.h
include/linux/futex.h
include/linux/hw_random.h [new file with mode: 0644]
include/linux/idr.h
include/linux/init_task.h
include/linux/input.h
include/linux/ioport.h
include/linux/ipmi.h
include/linux/jffs2.h
include/linux/kernel.h
include/linux/key.h
include/linux/libata.h
include/linux/license.h [new file with mode: 0644]
include/linux/list.h
include/linux/loop.h
include/linux/memory_hotplug.h
include/linux/mm.h
include/linux/module.h
include/linux/netdevice.h
include/linux/netpoll.h
include/linux/node.h
include/linux/nsc_gpio.h [new file with mode: 0644]
include/linux/pci_ids.h
include/linux/plist.h [new file with mode: 0644]
include/linux/poison.h [new file with mode: 0644]
include/linux/proc_fs.h
include/linux/ptrace.h
include/linux/raid/bitmap.h
include/linux/raid/linear.h
include/linux/raid/md.h
include/linux/raid/md_k.h
include/linux/raid/md_p.h
include/linux/raid/raid10.h
include/linux/raid/raid5.h
include/linux/rcupdate.h
include/linux/rtmutex.h [new file with mode: 0644]
include/linux/sched.h
include/linux/scx200.h
include/linux/scx200_gpio.h
include/linux/security.h
include/linux/sunrpc/gss_api.h
include/linux/swap.h
include/linux/syscalls.h
include/linux/sysctl.h
include/linux/time.h
include/linux/timex.h
include/linux/topology.h
include/linux/unwind.h [new file with mode: 0644]
include/linux/videodev2.h
include/media/cx2341x.h
include/net/tipc/tipc_bearer.h
init/Kconfig
init/initramfs.c
init/main.c
kernel/Makefile
kernel/acct.c
kernel/audit.c
kernel/auditsc.c
kernel/cpu.c
kernel/cpuset.c
kernel/exit.c
kernel/fork.c
kernel/futex.c
kernel/futex_compat.c
kernel/hrtimer.c
kernel/kprobes.c
kernel/module.c
kernel/mutex-debug.c
kernel/mutex-debug.h
kernel/mutex.c
kernel/mutex.h
kernel/power/Kconfig
kernel/profile.c
kernel/ptrace.c
kernel/rcupdate.c
kernel/rcutorture.c
kernel/resource.c
kernel/rtmutex-debug.c [new file with mode: 0644]
kernel/rtmutex-debug.h [new file with mode: 0644]
kernel/rtmutex-tester.c [new file with mode: 0644]
kernel/rtmutex.c [new file with mode: 0644]
kernel/rtmutex.h [new file with mode: 0644]
kernel/rtmutex_common.h [new file with mode: 0644]
kernel/sched.c
kernel/signal.c
kernel/softirq.c
kernel/softlockup.c
kernel/sysctl.c
kernel/time.c
kernel/time/Makefile [new file with mode: 0644]
kernel/time/clocksource.c [new file with mode: 0644]
kernel/time/jiffies.c [new file with mode: 0644]
kernel/timer.c
kernel/unwind.c [new file with mode: 0644]
kernel/workqueue.c
lib/Kconfig
lib/Kconfig.debug
lib/Makefile
lib/idr.c
lib/kernel_lock.c
lib/plist.c [new file with mode: 0644]
lib/zlib_inflate/inffast.c
lib/zlib_inflate/inftrees.c
mm/Kconfig
mm/filemap.c
mm/memory_hotplug.c
mm/mempolicy.c
mm/page-writeback.c
mm/page_alloc.c
mm/readahead.c
mm/slab.c
mm/sparse.c
mm/swap.c
mm/vmscan.c
net/atm/mpc.c
net/core/dev.c
net/core/netpoll.c
net/core/skbuff.c
net/ipv4/tcp.c
net/ipv6/route.c
net/netrom/nr_route.c
net/rxrpc/call.c
net/rxrpc/connection.c
net/rxrpc/krxsecd.c
net/sunrpc/auth_gss/gss_krb5_mech.c
net/sunrpc/auth_gss/gss_krb5_seal.c
net/sunrpc/auth_gss/gss_spkm3_mech.c
net/tipc/bcast.c
net/tipc/bcast.h
net/tipc/bearer.c
net/tipc/cluster.c
net/tipc/config.c
net/tipc/core.c
net/tipc/core.h
net/tipc/dbg.c
net/tipc/discover.c
net/tipc/eth_media.c
net/tipc/handler.c
net/tipc/link.c
net/tipc/name_distr.c
net/tipc/name_table.c
net/tipc/net.c
net/tipc/node.c
net/tipc/node.h
net/tipc/node_subscr.c
net/tipc/port.c
net/tipc/ref.c
net/tipc/socket.c
net/tipc/subscr.c
net/tipc/user_reg.c
net/tipc/zone.c
scripts/Makefile.build
scripts/Makefile.host
scripts/Makefile.modinst
scripts/Makefile.modpost
scripts/basic/Makefile
scripts/basic/split-include.c [deleted file]
scripts/export_report.pl [new file with mode: 0644]
scripts/genksyms/genksyms.c
scripts/genksyms/genksyms.h
scripts/genksyms/lex.c_shipped
scripts/genksyms/lex.l
scripts/kconfig/conf.c
scripts/kconfig/confdata.c
scripts/kconfig/expr.c
scripts/kconfig/expr.h
scripts/kconfig/gconf.c
scripts/kconfig/lex.zconf.c_shipped
scripts/kconfig/lkc.h
scripts/kconfig/lkc_proto.h
scripts/kconfig/menu.c
scripts/kconfig/qconf.cc
scripts/kconfig/qconf.h
scripts/kconfig/symbol.c
scripts/kconfig/util.c
scripts/kconfig/zconf.gperf
scripts/kconfig/zconf.hash.c_shipped
scripts/kconfig/zconf.tab.c_shipped
scripts/kconfig/zconf.y
scripts/mod/mk_elfconfig.c
scripts/mod/modpost.c
scripts/mod/modpost.h
scripts/package/mkspec
scripts/rt-tester/check-all.sh [new file with mode: 0644]
scripts/rt-tester/rt-tester.py [new file with mode: 0644]
scripts/rt-tester/t2-l1-2rt-sameprio.tst [new file with mode: 0644]
scripts/rt-tester/t2-l1-pi.tst [new file with mode: 0644]
scripts/rt-tester/t2-l1-signal.tst [new file with mode: 0644]
scripts/rt-tester/t2-l2-2rt-deadlock.tst [new file with mode: 0644]
scripts/rt-tester/t3-l1-pi-1rt.tst [new file with mode: 0644]
scripts/rt-tester/t3-l1-pi-2rt.tst [new file with mode: 0644]
scripts/rt-tester/t3-l1-pi-3rt.tst [new file with mode: 0644]
scripts/rt-tester/t3-l1-pi-signal.tst [new file with mode: 0644]
scripts/rt-tester/t3-l1-pi-steal.tst [new file with mode: 0644]
scripts/rt-tester/t3-l2-pi.tst [new file with mode: 0644]
scripts/rt-tester/t4-l2-pi-deboost.tst [new file with mode: 0644]
scripts/rt-tester/t5-l4-pi-boost-deboost-setsched.tst [new file with mode: 0644]
scripts/rt-tester/t5-l4-pi-boost-deboost.tst [new file with mode: 0644]
scripts/setlocalversion
security/Kconfig
security/dummy.c
security/keys/internal.h
security/keys/key.c
security/keys/keyctl.c
security/keys/keyring.c
security/keys/proc.c
security/keys/process_keys.c
security/keys/request_key.c
security/keys/request_key_auth.c
security/keys/user_defined.c
security/selinux/hooks.c
security/selinux/include/av_perm_to_string.h
security/selinux/include/av_permissions.h
security/selinux/include/objsec.h
sound/core/seq/seq_memory.h
sound/oss/Kconfig
sound/oss/sb_ess.c
sound/oss/via82cxxx_audio.c
sound/pci/cs5535audio/cs5535audio_pcm.c
sound/ppc/toonie.c [deleted file]
usr/Makefile

diff --git a/CREDITS b/CREDITS
index 1d35f10ec3b2e51e984bf33e1bc4790c0c596417..85c7c70b7044bb9e098e6d87949709033ebdc3d5 100644 (file)
--- a/CREDITS
+++ b/CREDITS
@@ -24,6 +24,11 @@ S: C. Negri 6, bl. D3
 S: Iasi 6600
 S: Romania
 
+N: Mark Adler
+E: madler@alumni.caltech.edu
+W: http://alumnus.caltech.edu/~madler/
+D: zlib decompression
+
 N: Monalisa Agrawal
 E: magrawal@nortelnetworks.com
 D: Basic Interphase 5575 driver with UBR and ABR support.
index 158ffe9bfadee23eccfe93e6c777f5ea52def8c9..644c3884fab94eb22001e8876f20a36e7e1d7995 100644 (file)
@@ -1590,7 +1590,7 @@ the amount of locking which needs to be done.
     <para>
       Our final dilemma is this: when can we actually destroy the
       removed element?  Remember, a reader might be stepping through
-      this element in the list right now: it we free this element and
+      this element in the list right now: if we free this element and
       the <symbol>next</symbol> pointer changes, the reader will jump
       off into garbage and crash.  We need to wait until we know that
       all the readers who were traversing the list when we deleted the
index e4c38152f7f799b94a70493f90dbf36b830e9cde..a4948591607d0e1d7b653ce1f66c08e4831cbad1 100644 (file)
@@ -7,7 +7,7 @@ The CONFIG_RCU_TORTURE_TEST config option is available for all RCU
 implementations.  It creates an rcutorture kernel module that can
 be loaded to run a torture test.  The test periodically outputs
 status messages via printk(), which can be examined via the dmesg
-command (perhaps grepping for "rcutorture").  The test is started
+command (perhaps grepping for "torture").  The test is started
 when the module is loaded, and stops when the module is unloaded.
 
 However, actually setting this config option to "y" results in the system
@@ -35,6 +35,19 @@ stat_interval        The number of seconds between output of torture
                be printed -only- when the module is unloaded, and this
                is the default.
 
+shuffle_interval
+               The number of seconds to keep the test threads affinitied
+               to a particular subset of the CPUs.  Used in conjunction
+               with test_no_idle_hz.
+
+test_no_idle_hz        Whether or not to test the ability of RCU to operate in
+               a kernel that disables the scheduling-clock interrupt to
+               idle CPUs.  Boolean parameter, "1" to test, "0" otherwise.
+
+torture_type   The type of RCU to test: "rcu" for the rcu_read_lock()
+               API, "rcu_bh" for the rcu_read_lock_bh() API, and "srcu"
+               for the "srcu_read_lock()" API.
+
 verbose                Enable debug printk()s.  Default is disabled.
 
 
@@ -42,14 +55,14 @@ OUTPUT
 
 The statistics output is as follows:
 
-       rcutorture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
-       rcutorture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
-       rcutorture: Reader Pipe:  1466408 9747 0 0 0 0 0 0 0 0 0
-       rcutorture: Reader Batch:  1464477 11678 0 0 0 0 0 0 0 0
-       rcutorture: Free-Block Circulation:  1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
-       rcutorture: --- End of test
+       rcu-torture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
+       rcu-torture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
+       rcu-torture: Reader Pipe:  1466408 9747 0 0 0 0 0 0 0 0 0
+       rcu-torture: Reader Batch:  1464477 11678 0 0 0 0 0 0 0 0
+       rcu-torture: Free-Block Circulation:  1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
+       rcu-torture: --- End of test
 
-The command "dmesg | grep rcutorture:" will extract this information on
+The command "dmesg | grep torture:" will extract this information on
 most systems.  On more esoteric configurations, it may be necessary to
 use other commands to access the output of the printk()s used by
 the RCU torture test.  The printk()s use KERN_ALERT, so they should
@@ -115,8 +128,9 @@ The following script may be used to torture RCU:
        modprobe rcutorture
        sleep 100
        rmmod rcutorture
-       dmesg | grep rcutorture:
+       dmesg | grep torture:
 
 The output can be manually inspected for the error flag of "!!!".
 One could of course create a more elaborate script that automatically
-checked for such errors.
+checked for such errors.  The "rmmod" command forces a "SUCCESS" or
+"FAILURE" indication to be printk()ed.
index 8c6ee684174c10d965205e986de08ab725219f1b..3e46d2a3115814a67e6990a9bba8e09e77f80854 100644 (file)
@@ -7,11 +7,13 @@ Introduction
 ------------
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
-  by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and
-  the S3C2440 are supported CPUs.
+  by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
+  S3C2440 and S3C2442 devices are supported.
 
   Support for the S3C2400 series is in progress.
 
+  Support for the S3C2412 and S3C2413 CPUs is being merged.
+
 
 Configuration
 -------------
@@ -43,9 +45,18 @@ Machines
 
     Samsung's own development board, geared for PDA work.
 
+  Samsung/Aiji SMDK2412
+
+    The S3C2412 version of the SMDK2440.
+
+  Samsung/Aiji SMDK2413
+
+    The S3C2412 version of the SMDK2440.
+
   Samsung/Meritech SMDK2440
 
-    The S3C2440 compatible version of the SMDK2440
+    The S3C2440 compatible version of the SMDK2440, which has the
+    option of an S3C2440 or S3C2442 CPU module.
 
   Thorcom VR1000
 
@@ -211,24 +222,6 @@ Port Contributors
   Lucas Correia Villa Real (S3C2400 port)
 
 
-Document Changes
-----------------
-
-  05 Sep 2004 - BJD - Added Document Changes section
-  05 Sep 2004 - BJD - Added Klaus Fetscher to list of contributors
-  25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors
-  25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge
-  21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors
-  10 Feb 2005 - BJD - Added Guillaume Gourat to contributors
-  02 Mar 2005 - BJD - Added SMDK2440 to list of machines
-  06 Mar 2005 - BJD - Added Christer Weinigel
-  08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction
-  08 Mar 2005 - BJD - Added section on adding machines
-  09 Sep 2005 - BJD - Added section on platform data
-  11 Feb 2006 - BJD - Added I2C, RTC and Watchdog sections
-  11 Feb 2006 - BJD - Added Osiris machine, and S3C2400 information
-
-
 Document Author
 ---------------
 
diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt
new file mode 100644 (file)
index 0000000..cb82a7f
--- /dev/null
@@ -0,0 +1,120 @@
+               S3C2412 ARM Linux Overview
+               ==========================
+
+Introduction
+------------
+
+  The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs
+  from Samsung. This part has an ARM926-EJS core, capable of running up
+  to 266MHz (see data-sheet for more information)
+
+
+Clock
+-----
+
+  The core clock code provides a set of clocks to the drivers, and allows
+  for source selection and a number of other features.
+
+
+Power
+-----
+
+  No support for suspend/resume to RAM in the current system.
+
+
+DMA
+---
+
+  No current support for DMA.
+
+
+GPIO
+----
+
+  There is support for setting the GPIO to input/output/special function
+  and reading or writing to them.
+
+
+UART
+----
+
+  The UART hardware is similar to the S3C2440, and is supported by the
+  s3c2410 driver in the drivers/serial directory.
+
+
+NAND
+----
+
+  The NAND hardware is similar to the S3C2440, and is supported by the
+  s3c2410 driver in the drivers/mtd/nand directory.
+
+
+USB Host
+--------
+
+  The USB hardware is similar to the S3C2410, with extended clock source
+  control. The OHCI portion is supported by the ohci-s3c2410 driver, and
+  the clock control selection is supported by the core clock code.
+
+
+USB Device
+----------
+
+  No current support in the kernel
+
+
+IRQs
+----
+
+  All the standard, and external interrupt sources are supported. The
+  extra sub-sources are not yet supported.
+
+
+RTC
+---
+
+  The RTC hardware is similar to the S3C2410, and is supported by the
+  s3c2410-rtc driver.
+
+
+Watchdog
+--------
+
+  The watchdog harware is the same as the S3C2410, and is supported by
+  the s3c2410_wdt driver.
+
+
+MMC/SD/SDIO
+-----------
+
+  No current support for the MMC/SD/SDIO block.
+
+IIC
+---
+
+  The IIC hardware is the same as the S3C2410, and is supported by the
+  i2c-s3c24xx driver.
+
+
+IIS
+---
+
+  No current support for the IIS interface.
+
+
+SPI
+---
+
+  No current support for the SPI interfaces.
+
+
+ATA
+---
+
+  No current support for the on-board ATA block.
+
+
+Document Author
+---------------
+
+Ben Dooks, (c) 2006 Simtec Electronics
diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2413.txt b/Documentation/arm/Samsung-S3C24XX/S3C2413.txt
new file mode 100644 (file)
index 0000000..ab2a888
--- /dev/null
@@ -0,0 +1,21 @@
+               S3C2413 ARM Linux Overview
+               ==========================
+
+Introduction
+------------
+
+  The S3C2413 is an extended version of the S3C2412, with an camera
+  interface and mobile DDR memory support. See the S3C2412 support
+  documentation for more information.
+
+
+Camera Interface
+---------------
+
+  This block is currently not supported.
+
+
+Document Author
+---------------
+
+Ben Dooks, (c) 2006 Simtec Electronics
index 23a1c2402bccf3ec6d8bbf97bba3becfcf149272..2a63d5662a93a1fd2e0889bc6aab93c1ae987102 100644 (file)
@@ -157,13 +157,13 @@ For example, smp_mb__before_atomic_dec() can be used like so:
        smp_mb__before_atomic_dec();
        atomic_dec(&obj->ref_count);
 
-It makes sure that all memory operations preceeding the atomic_dec()
+It makes sure that all memory operations preceding the atomic_dec()
 call are strongly ordered with respect to the atomic counter
-operation.  In the above example, it guarentees that the assignment of
+operation.  In the above example, it guarantees that the assignment of
 "1" to obj->dead will be globally visible to other cpus before the
 atomic counter decrement.
 
-Without the explicitl smp_mb__before_atomic_dec() call, the
+Without the explicit smp_mb__before_atomic_dec() call, the
 implementation could legally allow the atomic counter update visible
 to other cpus before the "obj->dead = 1;" assignment.
 
@@ -173,11 +173,11 @@ ordering with respect to memory operations after an atomic_dec() call
 (smp_mb__{before,after}_atomic_inc()).
 
 A missing memory barrier in the cases where they are required by the
-atomic_t implementation above can have disasterous results.  Here is
-an example, which follows a pattern occuring frequently in the Linux
+atomic_t implementation above can have disastrous results.  Here is
+an example, which follows a pattern occurring frequently in the Linux
 kernel.  It is the use of atomic counters to implement reference
 counting, and it works such that once the counter falls to zero it can
-be guarenteed that no other entity can be accessing the object:
+be guaranteed that no other entity can be accessing the object:
 
 static void obj_list_add(struct obj *obj)
 {
@@ -291,9 +291,9 @@ to the size of an "unsigned long" C data type, and are least of that
 size.  The endianness of the bits within each "unsigned long" are the
 native endianness of the cpu.
 
-       void set_bit(unsigned long nr, volatils unsigned long *addr);
-       void clear_bit(unsigned long nr, volatils unsigned long *addr);
-       void change_bit(unsigned long nr, volatils unsigned long *addr);
+       void set_bit(unsigned long nr, volatile unsigned long *addr);
+       void clear_bit(unsigned long nr, volatile unsigned long *addr);
+       void change_bit(unsigned long nr, volatile unsigned long *addr);
 
 These routines set, clear, and change, respectively, the bit number
 indicated by "nr" on the bit mask pointed to by "ADDR".
@@ -301,9 +301,9 @@ indicated by "nr" on the bit mask pointed to by "ADDR".
 They must execute atomically, yet there are no implicit memory barrier
 semantics required of these interfaces.
 
-       int test_and_set_bit(unsigned long nr, volatils unsigned long *addr);
-       int test_and_clear_bit(unsigned long nr, volatils unsigned long *addr);
-       int test_and_change_bit(unsigned long nr, volatils unsigned long *addr);
+       int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
+       int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
+       int test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
 
 Like the above, except that these routines return a boolean which
 indicates whether the changed bit was set _BEFORE_ the atomic bit
@@ -335,7 +335,7 @@ subsequent memory operation is made visible.  For example:
                /* ... */;
        obj->killed = 1;
 
-The implementation of test_and_set_bit() must guarentee that
+The implementation of test_and_set_bit() must guarantee that
 "obj->dead = 1;" is visible to cpus before the atomic memory operation
 done by test_and_set_bit() becomes visible.  Likewise, the atomic
 memory operation done by test_and_set_bit() must become visible before
@@ -474,7 +474,7 @@ Now, as far as memory barriers go, as long as spin_lock()
 strictly orders all subsequent memory operations (including
 the cas()) with respect to itself, things will be fine.
 
-Said another way, _atomic_dec_and_lock() must guarentee that
+Said another way, _atomic_dec_and_lock() must guarantee that
 a counter dropping to zero is never made visible before the
 spinlock being acquired.
 
diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt
new file mode 100644 (file)
index 0000000..d3e1744
--- /dev/null
@@ -0,0 +1,144 @@
+Console Drivers
+===============
+
+The linux kernel has 2 general types of console drivers.  The first type is
+assigned by the kernel to all the virtual consoles during the boot process.
+This type will be called 'system driver', and only one system driver is allowed
+to exist. The system driver is persistent and it can never be unloaded, though
+it may become inactive.
+
+The second type has to be explicitly loaded and unloaded. This will be called
+'modular driver' by this document. Multiple modular drivers can coexist at
+any time with each driver sharing the console with other drivers including
+the system driver. However, modular drivers cannot take over the console
+that is currently occupied by another modular driver. (Exception: Drivers that
+call take_over_console() will succeed in the takeover regardless of the type
+of driver occupying the consoles.) They can only take over the console that is
+occupied by the system driver. In the same token, if the modular driver is
+released by the console, the system driver will take over.
+
+Modular drivers, from the programmer's point of view, has to call:
+
+        take_over_console() - load and bind driver to console layer
+        give_up_console() - unbind and unload driver
+
+In newer kernels, the following are also available:
+
+        register_con_driver()
+        unregister_con_driver()
+
+If sysfs is enabled, the contents of /sys/class/vtconsole can be
+examined. This shows the console backends currently registered by the
+system which are named vtcon<n> where <n> is an integer fro 0 to 15. Thus:
+
+       ls /sys/class/vtconsole
+       .  ..  vtcon0  vtcon1
+
+Each directory in /sys/class/vtconsole has 3 files:
+
+     ls /sys/class/vtconsole/vtcon0
+     .  ..  bind  name  uevent
+
+What do these files signify?
+
+     1. bind - this is a read/write file. It shows the status of the driver if
+        read, or acts to bind or unbind the driver to the virtual consoles
+        when written to. The possible values are:
+
+       0 - means the driver is not bound and if echo'ed, commands the driver
+           to unbind
+
+        1 - means the driver is bound and if echo'ed, commands the driver to
+           bind
+
+     2. name - read-only file. Shows the name of the driver in this format:
+
+       cat /sys/class/vtconsole/vtcon0/name
+       (S) VGA+
+
+           '(S)' stands for a (S)ystem driver, ie, it cannot be directly
+           commanded to bind or unbind
+
+           'VGA+' is the name of the driver
+
+       cat /sys/class/vtconsole/vtcon1/name
+       (M) frame buffer device
+
+           In this case, '(M)' stands for a (M)odular driver, one that can be
+           directly commanded to bind or unbind.
+
+     3. uevent - ignore this file
+
+When unbinding, the modular driver is detached first, and then the system
+driver takes over the consoles vacated by the driver. Binding, on the other
+hand, will bind the driver to the consoles that are currently occupied by a
+system driver.
+
+NOTE1: Binding and binding must be selected in Kconfig. It's under:
+
+Device Drivers -> Character devices -> Support for binding and unbinding
+console drivers
+
+NOTE2: If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
+unbinding will not succeed. An example of an application that sets the console
+to KD_GRAPHICS is X.
+
+How useful is this feature? This is very useful for console driver
+developers. By unbinding the driver from the console layer, one can unload the
+driver, make changes, recompile, reload and rebind the driver without any need
+for rebooting the kernel. For regular users who may want to switch from
+framebuffer console to VGA console and vice versa, this feature also makes
+this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
+for more details).
+
+Notes for developers:
+=====================
+
+take_over_console() is now broken up into:
+
+     register_con_driver()
+     bind_con_driver() - private function
+
+give_up_console() is a wrapper to unregister_con_driver(), and a driver must
+be fully unbound for this call to succeed. con_is_bound() will check if the
+driver is bound or not.
+
+Guidelines for console driver writers:
+=====================================
+
+In order for binding to and unbinding from the console to properly work,
+console drivers must follow these guidelines:
+
+1. All drivers, except system drivers, must call either register_con_driver()
+   or take_over_console(). register_con_driver() will just add the driver to
+   the console's internal list. It won't take over the
+   console. take_over_console(), as it name implies, will also take over (or
+   bind to) the console.
+
+2. All resources allocated during con->con_init() must be released in
+   con->con_deinit().
+
+3. All resources allocated in con->con_startup() must be released when the
+   driver, which was previously bound, becomes unbound.  The console layer
+   does not have a complementary call to con->con_startup() so it's up to the
+   driver to check when it's legal to release these resources. Calling
+   con_is_bound() in con->con_deinit() will help.  If the call returned
+   false(), then it's safe to release the resources.  This balance has to be
+   ensured because con->con_startup() can be called again when a request to
+   rebind the driver to the console arrives.
+
+4. Upon exit of the driver, ensure that the driver is totally unbound. If the
+   condition is satisfied, then the driver must call unregister_con_driver()
+   or give_up_console().
+
+5. unregister_con_driver() can also be called on conditions which make it
+   impossible for the driver to service console requests.  This can happen
+   with the framebuffer console that suddenly lost all of its drivers.
+
+The current crop of console drivers should still work correctly, but binding
+and unbinding them may cause problems. With minimal fixes, these drivers can
+be made to work correctly.
+
+==========================
+Antonino Daplas <adaplas@pol.net>
+
index ac4a7a737e430207a22be59b2d817b309eefa828..2050c9ffc629da6a3079816551cdbc88f43deb49 100644 (file)
@@ -18,7 +18,7 @@ Traditional driver models implemented some sort of tree-like structure
 (sometimes just a list) for the devices they control. There wasn't any
 uniformity across the different bus types.
 
-The current driver model provides a comon, uniform data model for describing
+The current driver model provides a common, uniform data model for describing
 a bus and the devices that can appear under the bus. The unified bus
 model includes a set of common attributes which all busses carry, and a set
 of common callbacks, such as device discovery during bus probing, bus
index 08dce0f631bf90cc322282d33f21ec6509a9307f..f373df12ed4ce9bd236454495529387509359801 100644 (file)
@@ -135,10 +135,10 @@ C. Boot options
 
        The angle can be changed anytime afterwards by 'echoing' the same
        numbers to any one of the 2 attributes found in
-       /sys/class/graphics/fb{x}
+        /sys/class/graphics/fbcon
 
-               con_rotate     - rotate the display of the active console
-               con_rotate_all - rotate the display of all consoles
+               rotate     - rotate the display of the active console
+               rotate_all - rotate the display of all consoles
 
        Console rotation will only become available if Console Rotation
        Support is compiled in your kernel.
@@ -148,5 +148,177 @@ C. Boot options
        Actually, the underlying fb driver is totally ignorant of console
        rotation.
 
----
+C. Attaching, Detaching and Unloading
+
+Before going on on how to attach, detach and unload the framebuffer console, an
+illustration of the dependencies may help.
+
+The console layer, as with most subsystems, needs a driver that interfaces with
+the hardware. Thus, in a VGA console:
+
+console ---> VGA driver ---> hardware.
+
+Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
+from the console layer before unloading the driver.  The VGA driver cannot be
+unloaded if it is still bound to the console layer. (See
+Documentation/console/console.txt for more information).
+
+This is more complicated in the case of the the framebuffer console (fbcon),
+because fbcon is an intermediate layer between the console and the drivers:
+
+console ---> fbcon ---> fbdev drivers ---> hardware
+
+The fbdev drivers cannot be unloaded if it's bound to fbcon, and fbcon cannot
+be unloaded if it's bound to the console layer.
+
+So to unload the fbdev drivers, one must first unbind fbcon from the console,
+then unbind the fbdev drivers from fbcon.  Fortunately, unbinding fbcon from
+the console layer will automatically unbind framebuffer drivers from
+fbcon. Thus, there is no need to explicitly unbind the fbdev drivers from
+fbcon.
+
+So, how do we unbind fbcon from the console? Part of the answer is in
+Documentation/console/console.txt. To summarize:
+
+Echo a value to the bind file that represents the framebuffer console
+driver. So assuming vtcon1 represents fbcon, then:
+
+echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
+                                           console layer
+echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
+                                           console layer
+
+If fbcon is detached from the console layer, your boot console driver (which is
+usually VGA text mode) will take over.  A few drivers (rivafb and i810fb) will
+restore VGA text mode for you.  With the rest, before detaching fbcon, you
+must take a few additional steps to make sure that your VGA text mode is
+restored properly. The following is one of the several methods that you can do:
+
+1. Download or install vbetool.  This utility is included with most
+   distributions nowadays, and is usually part of the suspend/resume tool.
+
+2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
+   to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.
+
+3. Boot into text mode and as root run:
+
+       vbetool vbestate save > <vga state file>
+
+       The above command saves the register contents of your graphics
+       hardware to <vga state file>.  You need to do this step only once as
+       the state file can be reused.
+
+4. If fbcon is compiled as a module, load fbcon by doing:
+
+       modprobe fbcon
+
+5. Now to detach fbcon:
+
+       vbetool vbestate restore < <vga state file> && \
+       echo 0 > /sys/class/vtconsole/vtcon1/bind
+
+6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
+   you can unload it by 'rmmod fbcon'
+
+7. To reattach fbcon:
+
+       echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+8. Once fbcon is unbound, all drivers registered to the system will also
+become unbound.  This means that fbcon and individual framebuffer drivers
+can be unloaded or reloaded at will. Reloading the drivers or fbcon will
+automatically bind the console, fbcon and the drivers together. Unloading
+all the drivers without unloading fbcon will make it impossible for the
+console to bind fbcon.
+
+Notes for vesafb users:
+=======================
+
+Unfortunately, if your bootline includes a vga=xxx parameter that sets the
+hardware in graphics mode, such as when loading vesafb, vgacon will not load.
+Instead, vgacon will replace the default boot console with dummycon, and you
+won't get any display after detaching fbcon. Your machine is still alive, so
+you can reattach vesafb. However, to reattach vesafb, you need to do one of
+the following:
+
+Variation 1:
+
+    a. Before detaching fbcon, do
+
+       vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
+                                               # the file can be reused
+
+    b. Detach fbcon as in step 5.
+
+    c. Attach fbcon
+
+        vbetool vbestate restore < <vesa state file> && \
+       echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+Variation 2:
+
+    a. Before detaching fbcon, do:
+       echo <ID> > /sys/class/tty/console/bind
+
+
+       vbetool vbemode get
+
+    b. Take note of the mode number
+
+    b. Detach fbcon as in step 5.
+
+    c. Attach fbcon:
+
+       vbetool vbemode set <mode number> && \
+       echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+Samples:
+========
+
+Here are 2 sample bash scripts that you can use to bind or unbind the
+framebuffer console driver if you are in an X86 box:
+
+---------------------------------------------------------------------------
+#!/bin/bash
+# Unbind fbcon
+
+# Change this to where your actual vgastate file is located
+# Or Use VGASTATE=$1 to indicate the state file at runtime
+VGASTATE=/tmp/vgastate
+
+# path to vbetool
+VBETOOL=/usr/local/bin
+
+
+for (( i = 0; i < 16; i++))
+do
+  if test -x /sys/class/vtconsole/vtcon$i; then
+      if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
+           = 1 ]; then
+           if test -x $VBETOOL/vbetool; then
+              echo Unbinding vtcon$i
+              $VBETOOL/vbetool vbestate restore < $VGASTATE
+              echo 0 > /sys/class/vtconsole/vtcon$i/bind
+           fi
+      fi
+  fi
+done
+
+---------------------------------------------------------------------------
+#!/bin/bash
+# Bind fbcon
+
+for (( i = 0; i < 16; i++))
+do
+  if test -x /sys/class/vtconsole/vtcon$i; then
+      if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
+           = 1 ]; then
+         echo Unbinding vtcon$i
+         echo 1 > /sys/class/vtconsole/vtcon$i/bind
+      fi
+  fi
+done
+---------------------------------------------------------------------------
+
+--
 Antonino Daplas <adaplas@pol.net>
index afb1335c05d6fb5db31402dcd33c9a1ff21fb275..4aecc9bdb273a3df8656a2db59899cf52e47de21 100644 (file)
@@ -113,6 +113,14 @@ noquota
 grpquota
 usrquota
 
+bh             (*)     ext3 associates buffer heads to data pages to
+nobh                   (a) cache disk block mapping information
+                       (b) link pages into transaction to provide
+                           ordering guarantees.
+                       "bh" option forces use of buffer heads.
+                       "nobh" option tries to avoid associating buffer
+                       heads (supported only for "writeback" mode).
+
 
 Specification
 =============
index a9c00facdf401103a2ef7cb1301694c34a49432d..14ef3868a328d5080b8748507a8e8be576c936cd 100644 (file)
@@ -1123,6 +1123,14 @@ The top Makefile exports the following variables:
        $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE).  The user may
        override this value on the command line if desired.
 
+    INSTALL_MOD_STRIP
+
+       If this variable is specified, will cause modules to be stripped
+       after they are installed.  If INSTALL_MOD_STRIP is '1', then the
+       default option --strip-debug will be used.  Otherwise,
+       INSTALL_MOD_STRIP will used as the option(s) to the strip command.
+
+
 === 8 Makefile language
 
 The kernel Makefiles are designed to run with GNU Make.  The Makefiles
index dcf5580380ab3c848f185ed15df95b25b24b2037..9b9b454b048ad78e9745a3d12971aa0cff665fc5 100644 (file)
@@ -175,7 +175,7 @@ end
 document trapinfo
        Run info threads and lookup pid of thread #1
        'trapinfo <pid>' will tell you by which trap & possibly
-       addresthe kernel paniced.
+       address the kernel panicked.
 end
 
 
index bca6f389da66eb509815a0d115ddacb6d24cb50d..0d189c93eeaf94b283d22fd39d4dea8274d2d3cc 100644 (file)
@@ -61,6 +61,7 @@ parameter is applicable:
        MTD     MTD support is enabled.
        NET     Appropriate network support is enabled.
        NUMA    NUMA support is enabled.
+       GENERIC_TIME The generic timeofday code is enabled.
        NFS     Appropriate NFS support is enabled.
        OSS     OSS sound support is enabled.
        PARIDE  The ParIDE subsystem is enabled.
@@ -179,6 +180,11 @@ running once the system is up.
                        override platform specific driver.
                        See also Documentation/acpi-hotkey.txt.
 
+       acpi_pm_good    [IA-32,X86-64]
+                       Override the pmtimer bug detection: force the kernel
+                       to assume that this machine's pmtimer latches its value
+                       and always returns good values.
+
        enable_timer_pin_1 [i386,x86-64]
                        Enable PIN 1 of APIC timer
                        Can be useful to work around chipset bugs
@@ -341,10 +347,11 @@ running once the system is up.
                        Value can be changed at runtime via
                                /selinux/checkreqprot.
 
-       clock=          [BUGS=IA-32,HW] gettimeofday timesource override.
-                       Forces specified timesource (if avaliable) to be used
-                       when calculating gettimeofday(). If specicified
-                       timesource is not avalible, it defaults to PIT.
+       clock=          [BUGS=IA-32, HW] gettimeofday clocksource override.
+                       [Deprecated]
+                       Forces specified clocksource (if avaliable) to be used
+                       when calculating gettimeofday(). If specified
+                       clocksource is not avalible, it defaults to PIT.
                        Format: { pit | tsc | cyclone | pmtmr }
 
        disable_8254_timer
@@ -1617,6 +1624,10 @@ running once the system is up.
 
        time            Show timing data prefixed to each printk message line
 
+       clocksource=    [GENERIC_TIME] Override the default clocksource
+                       Override the default clocksource and use the clocksource
+                       with the name specified.
+
        tipar.timeout=  [HW,PPT]
                        Set communications timeout in tenths of a second
                        (default 15).
@@ -1658,6 +1669,10 @@ running once the system is up.
        usbhid.mousepoll=
                        [USBHID] The interval which mice are to be polled at.
 
+       vdso=           [IA-32]
+                       vdso=1: enable VDSO (default)
+                       vdso=0: disable VDSO mapping
+
        video=          [FB] Frame buffer configuration
                        See Documentation/fb/modedb.txt.
 
index 3bbe157b45e470ca656c72e47e523138c9be6fe8..61c0fad2fe2fa01ca14b14d218b56282940bafa6 100644 (file)
@@ -241,25 +241,30 @@ The security class "key" has been added to SELinux so that mandatory access
 controls can be applied to keys created within various contexts.  This support
 is preliminary, and is likely to change quite significantly in the near future.
 Currently, all of the basic permissions explained above are provided in SELinux
-as well; SE Linux is simply invoked after all basic permission checks have been
+as well; SELinux is simply invoked after all basic permission checks have been
 performed.
 
-Each key is labeled with the same context as the task to which it belongs.
-Typically, this is the same task that was running when the key was created.
-The default keyrings are handled differently, but in a way that is very
-intuitive:
+The value of the file /proc/self/attr/keycreate influences the labeling of
+newly-created keys.  If the contents of that file correspond to an SELinux
+security context, then the key will be assigned that context.  Otherwise, the
+key will be assigned the current context of the task that invoked the key
+creation request.  Tasks must be granted explicit permission to assign a
+particular context to newly-created keys, using the "create" permission in the
+key security class.
 
- (*) The user and user session keyrings that are created when the user logs in
-     are currently labeled with the context of the login manager.
-
- (*) The keyrings associated with new threads are each labeled with the context
-     of their associated thread, and both session and process keyrings are
-     handled similarly.
+The default keyrings associated with users will be labeled with the default
+context of the user if and only if the login programs have been instrumented to
+properly initialize keycreate during the login process.  Otherwise, they will
+be labeled with the context of the login program itself.
 
 Note, however, that the default keyrings associated with the root user are
 labeled with the default kernel context, since they are created early in the
 boot process, before root has a chance to log in.
 
+The keyrings associated with new threads are each labeled with the context of
+their associated thread, and both session and process keyrings are handled
+similarly.
+
 
 ================
 NEW PROCFS FILES
@@ -270,9 +275,17 @@ about the status of the key service:
 
  (*) /proc/keys
 
-     This lists all the keys on the system, giving information about their
-     type, description and permissions. The payload of the key is not available
-     this way:
+     This lists the keys that are currently viewable by the task reading the
+     file, giving information about their type, description and permissions.
+     It is not possible to view the payload of the key this way, though some
+     information about it may be given.
+
+     The only keys included in the list are those that grant View permission to
+     the reading process whether or not it possesses them.  Note that LSM
+     security checks are still performed, and may further filter out keys that
+     the current process is not authorised to view.
+
+     The contents of the file look like this:
 
        SERIAL   FLAGS  USAGE EXPY PERM     UID   GID   TYPE      DESCRIPTION: SUMMARY
        00000001 I-----    39 perm 1f3f0000     0     0 keyring   _uid_ses.0: 1/4
@@ -300,7 +313,7 @@ about the status of the key service:
  (*) /proc/key-users
 
      This file lists the tracking data for each user that has at least one key
-     on the system. Such data includes quota information and statistics:
+     on the system.  Such data includes quota information and statistics:
 
        [root@andromeda root]# cat /proc/key-users
        0:     46 45/45 1/100 13/10000
index 03a13c462cf20ed8e09d85ead4b953cfad3b6218..0668f9dc9d29635393e5876b15b1a3bce9abaa13 100644 (file)
@@ -200,6 +200,17 @@ All md devices contain:
      This can be written only while the array is being assembled, not
      after it is started.
 
+  layout
+     The "layout" for the array for the particular level.  This is
+     simply a number that is interpretted differently by different
+     levels.  It can be written while assembling an array.
+
+  resync_start
+     The point at which resync should start.  If no resync is needed,
+     this will be a very large number.  At array creation it will
+     default to 0, though starting the array as 'clean' will
+     set it much larger.
+
    new_dev
      This file can be written but not read.  The value written should
      be a block device number as major:minor.  e.g. 8:0
@@ -207,6 +218,54 @@ All md devices contain:
      available.  It will then appear at md/dev-XXX (depending on the
      name of the device) and further configuration is then possible.
 
+   safe_mode_delay
+     When an md array has seen no write requests for a certain period
+     of time, it will be marked as 'clean'.  When another write
+     request arrive, the array is marked as 'dirty' before the write
+     commenses.  This is known as 'safe_mode'.
+     The 'certain period' is controlled by this file which stores the
+     period as a number of seconds.  The default is 200msec (0.200).
+     Writing a value of 0 disables safemode.
+
+   array_state
+     This file contains a single word which describes the current
+     state of the array.  In many cases, the state can be set by
+     writing the word for the desired state, however some states
+     cannot be explicitly set, and some transitions are not allowed.
+
+     clear
+         No devices, no size, no level
+         Writing is equivalent to STOP_ARRAY ioctl
+     inactive
+         May have some settings, but array is not active
+            all IO results in error
+         When written, doesn't tear down array, but just stops it
+     suspended (not supported yet)
+         All IO requests will block. The array can be reconfigured.
+         Writing this, if accepted, will block until array is quiessent
+     readonly
+         no resync can happen.  no superblocks get written.
+         write requests fail
+     read-auto
+         like readonly, but behaves like 'clean' on a write request.
+
+     clean - no pending writes, but otherwise active.
+         When written to inactive array, starts without resync
+         If a write request arrives then
+           if metadata is known, mark 'dirty' and switch to 'active'.
+           if not known, block and switch to write-pending
+         If written to an active array that has pending writes, then fails.
+     active
+         fully active: IO and resync can be happening.
+         When written to inactive array, starts with resync
+
+     write-pending
+         clean, but writes are blocked waiting for 'active' to be written.
+
+     active-idle
+         like active, but no writes have been seen for a while (safe_mode_delay).
+
+
    sync_speed_min
    sync_speed_max
      This are similar to /proc/sys/dev/raid/speed_limit_{min,max}
@@ -250,10 +309,18 @@ Each directory contains:
              faulty   - device has been kicked from active use due to
                          a detected fault
              in_sync  - device is a fully in-sync member of the array
+             writemostly - device will only be subject to read
+                        requests if there are no other options.
+                        This applies only to raid1 arrays.
              spare    - device is working, but not a full member.
                         This includes spares that are in the process
                         of being recoverred to
        This list make grow in future.
+       This can be written to.
+       Writing "faulty"  simulates a failure on the device.
+       Writing "remove" removes the device from the array.
+       Writing "writemostly" sets the writemostly flag.
+       Writing "-writemostly" clears the writemostly flag.
 
       errors
        An approximate count of read errors that have been detected on
diff --git a/Documentation/pi-futex.txt b/Documentation/pi-futex.txt
new file mode 100644 (file)
index 0000000..5d61dac
--- /dev/null
@@ -0,0 +1,121 @@
+Lightweight PI-futexes
+----------------------
+
+We are calling them lightweight for 3 reasons:
+
+ - in the user-space fastpath a PI-enabled futex involves no kernel work
+   (or any other PI complexity) at all. No registration, no extra kernel
+   calls - just pure fast atomic ops in userspace.
+
+ - even in the slowpath, the system call and scheduling pattern is very
+   similar to normal futexes.
+
+ - the in-kernel PI implementation is streamlined around the mutex
+   abstraction, with strict rules that keep the implementation
+   relatively simple: only a single owner may own a lock (i.e. no
+   read-write lock support), only the owner may unlock a lock, no
+   recursive locking, etc.
+
+Priority Inheritance - why?
+---------------------------
+
+The short reply: user-space PI helps achieving/improving determinism for
+user-space applications. In the best-case, it can help achieve
+determinism and well-bound latencies. Even in the worst-case, PI will
+improve the statistical distribution of locking related application
+delays.
+
+The longer reply:
+-----------------
+
+Firstly, sharing locks between multiple tasks is a common programming
+technique that often cannot be replaced with lockless algorithms. As we
+can see it in the kernel [which is a quite complex program in itself],
+lockless structures are rather the exception than the norm - the current
+ratio of lockless vs. locky code for shared data structures is somewhere
+between 1:10 and 1:100. Lockless is hard, and the complexity of lockless
+algorithms often endangers to ability to do robust reviews of said code.
+I.e. critical RT apps often choose lock structures to protect critical
+data structures, instead of lockless algorithms. Furthermore, there are
+cases (like shared hardware, or other resource limits) where lockless
+access is mathematically impossible.
+
+Media players (such as Jack) are an example of reasonable application
+design with multiple tasks (with multiple priority levels) sharing
+short-held locks: for example, a highprio audio playback thread is
+combined with medium-prio construct-audio-data threads and low-prio
+display-colory-stuff threads. Add video and decoding to the mix and
+we've got even more priority levels.
+
+So once we accept that synchronization objects (locks) are an
+unavoidable fact of life, and once we accept that multi-task userspace
+apps have a very fair expectation of being able to use locks, we've got
+to think about how to offer the option of a deterministic locking
+implementation to user-space.
+
+Most of the technical counter-arguments against doing priority
+inheritance only apply to kernel-space locks. But user-space locks are
+different, there we cannot disable interrupts or make the task
+non-preemptible in a critical section, so the 'use spinlocks' argument
+does not apply (user-space spinlocks have the same priority inversion
+problems as other user-space locking constructs). Fact is, pretty much
+the only technique that currently enables good determinism for userspace
+locks (such as futex-based pthread mutexes) is priority inheritance:
+
+Currently (without PI), if a high-prio and a low-prio task shares a lock
+[this is a quite common scenario for most non-trivial RT applications],
+even if all critical sections are coded carefully to be deterministic
+(i.e. all critical sections are short in duration and only execute a
+limited number of instructions), the kernel cannot guarantee any
+deterministic execution of the high-prio task: any medium-priority task
+could preempt the low-prio task while it holds the shared lock and
+executes the critical section, and could delay it indefinitely.
+
+Implementation:
+---------------
+
+As mentioned before, the userspace fastpath of PI-enabled pthread
+mutexes involves no kernel work at all - they behave quite similarly to
+normal futex-based locks: a 0 value means unlocked, and a value==TID
+means locked. (This is the same method as used by list-based robust
+futexes.) Userspace uses atomic ops to lock/unlock these mutexes without
+entering the kernel.
+
+To handle the slowpath, we have added two new futex ops:
+
+  FUTEX_LOCK_PI
+  FUTEX_UNLOCK_PI
+
+If the lock-acquire fastpath fails, [i.e. an atomic transition from 0 to
+TID fails], then FUTEX_LOCK_PI is called. The kernel does all the
+remaining work: if there is no futex-queue attached to the futex address
+yet then the code looks up the task that owns the futex [it has put its
+own TID into the futex value], and attaches a 'PI state' structure to
+the futex-queue. The pi_state includes an rt-mutex, which is a PI-aware,
+kernel-based synchronization object. The 'other' task is made the owner
+of the rt-mutex, and the FUTEX_WAITERS bit is atomically set in the
+futex value. Then this task tries to lock the rt-mutex, on which it
+blocks. Once it returns, it has the mutex acquired, and it sets the
+futex value to its own TID and returns. Userspace has no other work to
+perform - it now owns the lock, and futex value contains
+FUTEX_WAITERS|TID.
+
+If the unlock side fastpath succeeds, [i.e. userspace manages to do a
+TID -> 0 atomic transition of the futex value], then no kernel work is
+triggered.
+
+If the unlock fastpath fails (because the FUTEX_WAITERS bit is set),
+then FUTEX_UNLOCK_PI is called, and the kernel unlocks the futex on the
+behalf of userspace - and it also unlocks the attached
+pi_state->rt_mutex and thus wakes up any potential waiters.
+
+Note that under this approach, contrary to previous PI-futex approaches,
+there is no prior 'registration' of a PI-futex. [which is not quite
+possible anyway, due to existing ABI properties of pthread mutexes.]
+
+Also, under this scheme, 'robustness' and 'PI' are two orthogonal
+properties of futexes, and all four combinations are possible: futex,
+robust-futex, PI-futex, robust+PI-futex.
+
+More details about priority inheritance can be found in
+Documentation/rtmutex.txt.
index df82d75245a01b5055c6793fa822efe949982a2e..76e8064b8c3a5ccb60e6cbb2f55ad5d455d097b0 100644 (file)
@@ -95,7 +95,7 @@ comparison. If the thread has registered a list, then normally the list
 is empty. If the thread/process crashed or terminated in some incorrect
 way then the list might be non-empty: in this case the kernel carefully
 walks the list [not trusting it], and marks all locks that are owned by
-this thread with the FUTEX_OWNER_DEAD bit, and wakes up one waiter (if
+this thread with the FUTEX_OWNER_DIED bit, and wakes up one waiter (if
 any).
 
 The list is guaranteed to be private and per-thread at do_exit() time,
diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt
new file mode 100644 (file)
index 0000000..c472ffa
--- /dev/null
@@ -0,0 +1,781 @@
+#
+# Copyright (c) 2006 Steven Rostedt
+# Licensed under the GNU Free Documentation License, Version 1.2
+#
+
+RT-mutex implementation design
+------------------------------
+
+This document tries to describe the design of the rtmutex.c implementation.
+It doesn't describe the reasons why rtmutex.c exists. For that please see
+Documentation/rt-mutex.txt.  Although this document does explain problems
+that happen without this code, but that is in the concept to understand
+what the code actually is doing.
+
+The goal of this document is to help others understand the priority
+inheritance (PI) algorithm that is used, as well as reasons for the
+decisions that were made to implement PI in the manner that was done.
+
+
+Unbounded Priority Inversion
+----------------------------
+
+Priority inversion is when a lower priority process executes while a higher
+priority process wants to run.  This happens for several reasons, and
+most of the time it can't be helped.  Anytime a high priority process wants
+to use a resource that a lower priority process has (a mutex for example),
+the high priority process must wait until the lower priority process is done
+with the resource.  This is a priority inversion.  What we want to prevent
+is something called unbounded priority inversion.  That is when the high
+priority process is prevented from running by a lower priority process for
+an undetermined amount of time.
+
+The classic example of unbounded priority inversion is were you have three
+processes, let's call them processes A, B, and C, where A is the highest
+priority process, C is the lowest, and B is in between. A tries to grab a lock
+that C owns and must wait and lets C run to release the lock. But in the
+meantime, B executes, and since B is of a higher priority than C, it preempts C,
+but by doing so, it is in fact preempting A which is a higher priority process.
+Now there's no way of knowing how long A will be sleeping waiting for C
+to release the lock, because for all we know, B is a CPU hog and will
+never give C a chance to release the lock.  This is called unbounded priority
+inversion.
+
+Here's a little ASCII art to show the problem.
+
+   grab lock L1 (owned by C)
+     |
+A ---+
+        C preempted by B
+          |
+C    +----+
+
+B         +-------->
+                B now keeps A from running.
+
+
+Priority Inheritance (PI)
+-------------------------
+
+There are several ways to solve this issue, but other ways are out of scope
+for this document.  Here we only discuss PI.
+
+PI is where a process inherits the priority of another process if the other
+process blocks on a lock owned by the current process.  To make this easier
+to understand, let's use the previous example, with processes A, B, and C again.
+
+This time, when A blocks on the lock owned by C, C would inherit the priority
+of A.  So now if B becomes runnable, it would not preempt C, since C now has
+the high priority of A.  As soon as C releases the lock, it loses its
+inherited priority, and A then can continue with the resource that C had.
+
+Terminology
+-----------
+
+Here I explain some terminology that is used in this document to help describe
+the design that is used to implement PI.
+
+PI chain - The PI chain is an ordered series of locks and processes that cause
+           processes to inherit priorities from a previous process that is
+           blocked on one of its locks.  This is described in more detail
+           later in this document.
+
+mutex    - In this document, to differentiate from locks that implement
+           PI and spin locks that are used in the PI code, from now on
+           the PI locks will be called a mutex.
+
+lock     - In this document from now on, I will use the term lock when
+           referring to spin locks that are used to protect parts of the PI
+           algorithm.  These locks disable preemption for UP (when
+           CONFIG_PREEMPT is enabled) and on SMP prevents multiple CPUs from
+           entering critical sections simultaneously.
+
+spin lock - Same as lock above.
+
+waiter   - A waiter is a struct that is stored on the stack of a blocked
+           process.  Since the scope of the waiter is within the code for
+           a process being blocked on the mutex, it is fine to allocate
+           the waiter on the process's stack (local variable).  This
+           structure holds a pointer to the task, as well as the mutex that
+           the task is blocked on.  It also has the plist node structures to
+           place the task in the waiter_list of a mutex as well as the
+           pi_list of a mutex owner task (described below).
+
+           waiter is sometimes used in reference to the task that is waiting
+           on a mutex. This is the same as waiter->task.
+
+waiters  - A list of processes that are blocked on a mutex.
+
+top waiter - The highest priority process waiting on a specific mutex.
+
+top pi waiter - The highest priority process waiting on one of the mutexes
+                that a specific process owns.
+
+Note:  task and process are used interchangeably in this document, mostly to
+       differentiate between two processes that are being described together.
+
+
+PI chain
+--------
+
+The PI chain is a list of processes and mutexes that may cause priority
+inheritance to take place.  Multiple chains may converge, but a chain
+would never diverge, since a process can't be blocked on more than one
+mutex at a time.
+
+Example:
+
+   Process:  A, B, C, D, E
+   Mutexes:  L1, L2, L3, L4
+
+   A owns: L1
+           B blocked on L1
+           B owns L2
+                  C blocked on L2
+                  C owns L3
+                         D blocked on L3
+                         D owns L4
+                                E blocked on L4
+
+The chain would be:
+
+   E->L4->D->L3->C->L2->B->L1->A
+
+To show where two chains merge, we could add another process F and
+another mutex L5 where B owns L5 and F is blocked on mutex L5.
+
+The chain for F would be:
+
+   F->L5->B->L1->A
+
+Since a process may own more than one mutex, but never be blocked on more than
+one, the chains merge.
+
+Here we show both chains:
+
+   E->L4->D->L3->C->L2-+
+                       |
+                       +->B->L1->A
+                       |
+                 F->L5-+
+
+For PI to work, the processes at the right end of these chains (or we may
+also call it the Top of the chain) must be equal to or higher in priority
+than the processes to the left or below in the chain.
+
+Also since a mutex may have more than one process blocked on it, we can
+have multiple chains merge at mutexes.  If we add another process G that is
+blocked on mutex L2:
+
+  G->L2->B->L1->A
+
+And once again, to show how this can grow I will show the merging chains
+again.
+
+   E->L4->D->L3->C-+
+                   +->L2-+
+                   |     |
+                 G-+     +->B->L1->A
+                         |
+                   F->L5-+
+
+
+Plist
+-----
+
+Before I go further and talk about how the PI chain is stored through lists
+on both mutexes and processes, I'll explain the plist.  This is similar to
+the struct list_head functionality that is already in the kernel.
+The implementation of plist is out of scope for this document, but it is
+very important to understand what it does.
+
+There are a few differences between plist and list, the most important one
+being that plist is a priority sorted linked list.  This means that the
+priorities of the plist are sorted, such that it takes O(1) to retrieve the
+highest priority item in the list.  Obviously this is useful to store processes
+based on their priorities.
+
+Another difference, which is important for implementation, is that, unlike
+list, the head of the list is a different element than the nodes of a list.
+So the head of the list is declared as struct plist_head and nodes that will
+be added to the list are declared as struct plist_node.
+
+
+Mutex Waiter List
+-----------------
+
+Every mutex keeps track of all the waiters that are blocked on itself. The mutex
+has a plist to store these waiters by priority.  This list is protected by
+a spin lock that is located in the struct of the mutex. This lock is called
+wait_lock.  Since the modification of the waiter list is never done in
+interrupt context, the wait_lock can be taken without disabling interrupts.
+
+
+Task PI List
+------------
+
+To keep track of the PI chains, each process has its own PI list.  This is
+a list of all top waiters of the mutexes that are owned by the process.
+Note that this list only holds the top waiters and not all waiters that are
+blocked on mutexes owned by the process.
+
+The top of the task's PI list is always the highest priority task that
+is waiting on a mutex that is owned by the task.  So if the task has
+inherited a priority, it will always be the priority of the task that is
+at the top of this list.
+
+This list is stored in the task structure of a process as a plist called
+pi_list.  This list is protected by a spin lock also in the task structure,
+called pi_lock.  This lock may also be taken in interrupt context, so when
+locking the pi_lock, interrupts must be disabled.
+
+
+Depth of the PI Chain
+---------------------
+
+The maximum depth of the PI chain is not dynamic, and could actually be
+defined.  But is very complex to figure it out, since it depends on all
+the nesting of mutexes.  Let's look at the example where we have 3 mutexes,
+L1, L2, and L3, and four separate functions func1, func2, func3 and func4.
+The following shows a locking order of L1->L2->L3, but may not actually
+be directly nested that way.
+
+void func1(void)
+{
+       mutex_lock(L1);
+
+       /* do anything */
+
+       mutex_unlock(L1);
+}
+
+void func2(void)
+{
+       mutex_lock(L1);
+       mutex_lock(L2);
+
+       /* do something */
+
+       mutex_unlock(L2);
+       mutex_unlock(L1);
+}
+
+void func3(void)
+{
+       mutex_lock(L2);
+       mutex_lock(L3);
+
+       /* do something else */
+
+       mutex_unlock(L3);
+       mutex_unlock(L2);
+}
+
+void func4(void)
+{
+       mutex_lock(L3);
+
+       /* do something again */
+
+       mutex_unlock(L3);
+}
+
+Now we add 4 processes that run each of these functions separately.
+Processes A, B, C, and D which run functions func1, func2, func3 and func4
+respectively, and such that D runs first and A last.  With D being preempted
+in func4 in the "do something again" area, we have a locking that follows:
+
+D owns L3
+       C blocked on L3
+       C owns L2
+              B blocked on L2
+              B owns L1
+                     A blocked on L1
+
+And thus we have the chain A->L1->B->L2->C->L3->D.
+
+This gives us a PI depth of 4 (four processes), but looking at any of the
+functions individually, it seems as though they only have at most a locking
+depth of two.  So, although the locking depth is defined at compile time,
+it still is very difficult to find the possibilities of that depth.
+
+Now since mutexes can be defined by user-land applications, we don't want a DOS
+type of application that nests large amounts of mutexes to create a large
+PI chain, and have the code holding spin locks while looking at a large
+amount of data.  So to prevent this, the implementation not only implements
+a maximum lock depth, but also only holds at most two different locks at a
+time, as it walks the PI chain.  More about this below.
+
+
+Mutex owner and flags
+---------------------
+
+The mutex structure contains a pointer to the owner of the mutex.  If the
+mutex is not owned, this owner is set to NULL.  Since all architectures
+have the task structure on at least a four byte alignment (and if this is
+not true, the rtmutex.c code will be broken!), this allows for the two
+least significant bits to be used as flags.  This part is also described
+in Documentation/rt-mutex.txt, but will also be briefly described here.
+
+Bit 0 is used as the "Pending Owner" flag.  This is described later.
+Bit 1 is used as the "Has Waiters" flags.  This is also described later
+  in more detail, but is set whenever there are waiters on a mutex.
+
+
+cmpxchg Tricks
+--------------
+
+Some architectures implement an atomic cmpxchg (Compare and Exchange).  This
+is used (when applicable) to keep the fast path of grabbing and releasing
+mutexes short.
+
+cmpxchg is basically the following function performed atomically:
+
+unsigned long _cmpxchg(unsigned long *A, unsigned long *B, unsigned long *C)
+{
+        unsigned long T = *A;
+        if (*A == *B) {
+                *A = *C;
+        }
+        return T;
+}
+#define cmpxchg(a,b,c) _cmpxchg(&a,&b,&c)
+
+This is really nice to have, since it allows you to only update a variable
+if the variable is what you expect it to be.  You know if it succeeded if
+the return value (the old value of A) is equal to B.
+
+The macro rt_mutex_cmpxchg is used to try to lock and unlock mutexes. If
+the architecture does not support CMPXCHG, then this macro is simply set
+to fail every time.  But if CMPXCHG is supported, then this will
+help out extremely to keep the fast path short.
+
+The use of rt_mutex_cmpxchg with the flags in the owner field help optimize
+the system for architectures that support it.  This will also be explained
+later in this document.
+
+
+Priority adjustments
+--------------------
+
+The implementation of the PI code in rtmutex.c has several places that a
+process must adjust its priority.  With the help of the pi_list of a
+process this is rather easy to know what needs to be adjusted.
+
+The functions implementing the task adjustments are rt_mutex_adjust_prio,
+__rt_mutex_adjust_prio (same as the former, but expects the task pi_lock
+to already be taken), rt_mutex_get_prio, and rt_mutex_setprio.
+
+rt_mutex_getprio and rt_mutex_setprio are only used in __rt_mutex_adjust_prio.
+
+rt_mutex_getprio returns the priority that the task should have.  Either the
+task's own normal priority, or if a process of a higher priority is waiting on
+a mutex owned by the task, then that higher priority should be returned.
+Since the pi_list of a task holds an order by priority list of all the top
+waiters of all the mutexes that the task owns, rt_mutex_getprio simply needs
+to compare the top pi waiter to its own normal priority, and return the higher
+priority back.
+
+(Note:  if looking at the code, you will notice that the lower number of
+        prio is returned.  This is because the prio field in the task structure
+        is an inverse order of the actual priority.  So a "prio" of 5 is
+        of higher priority than a "prio" of 10.)
+
+__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
+result does not equal the task's current priority, then rt_mutex_setprio
+is called to adjust the priority of the task to the new priority.
+Note that rt_mutex_setprio is defined in kernel/sched.c to implement the
+actual change in priority.
+
+It is interesting to note that __rt_mutex_adjust_prio can either increase
+or decrease the priority of the task.  In the case that a higher priority
+process has just blocked on a mutex owned&