Merge HEAD from ../scsi-misc-2.6-tmp
authorJames Bottomley <jejb@titanic.(none)>
Sun, 28 Aug 2005 16:18:35 +0000 (11:18 -0500)
committerJames Bottomley <jejb@titanic.(none)>
Sun, 28 Aug 2005 16:18:35 +0000 (11:18 -0500)
610 files changed:
CREDITS
Documentation/SubmittingPatches
Documentation/acpi-hotkey.txt
Documentation/arm/Samsung-S3C24XX/USB-Host.txt [new file with mode: 0644]
Documentation/dontdiff
Documentation/fb/vesafb.txt
Documentation/kernel-parameters.txt
Documentation/kprobes.txt [new file with mode: 0644]
Documentation/networking/bonding.txt
Documentation/pci.txt
Documentation/usb/usbmon.txt
Documentation/video4linux/CARDLIST.cx88
Documentation/video4linux/CARDLIST.tuner
Documentation/video4linux/bttv/Insmod-options
Documentation/x86_64/boot-options.txt
MAINTAINERS
Makefile
REPORTING-BUGS
arch/alpha/Kconfig
arch/alpha/kernel/pci.c
arch/alpha/kernel/smp.c
arch/alpha/oprofile/common.c
arch/arm/Kconfig
arch/arm/kernel/bios32.c
arch/arm/kernel/calls.S
arch/arm/kernel/entry-armv.S
arch/arm/kernel/traps.c
arch/arm/lib/bitops.h
arch/arm/mach-ixp4xx/coyote-setup.c
arch/arm/mach-ixp4xx/gtwx5715-setup.c
arch/arm/mach-ixp4xx/ixdp425-setup.c
arch/arm/mach-s3c2410/mach-bast.c
arch/arm/mach-s3c2410/s3c2410.c
arch/arm/mach-s3c2410/usb-simtec.c
arch/arm/mach-sa1100/jornada720.c
arch/arm/mm/Kconfig
arch/arm/mm/fault.c
arch/arm/mm/mm-armv.c
arch/arm/mm/proc-v6.S
arch/arm/mm/proc-xscale.S
arch/arm/nwfpe/double_cpdo.c
arch/arm/nwfpe/extended_cpdo.c
arch/arm/nwfpe/fpa11.c
arch/arm/nwfpe/fpa11.h
arch/arm/nwfpe/fpa11_cpdo.c
arch/arm/nwfpe/fpa11_cpdt.c
arch/arm/nwfpe/fpa11_cprt.c
arch/arm/nwfpe/fpmodule.c
arch/arm/nwfpe/fpopcode.h
arch/arm/nwfpe/single_cpdo.c
arch/arm/nwfpe/softfloat.c
arch/arm/nwfpe/softfloat.h
arch/arm/oprofile/backtrace.c
arch/arm/vfp/vfpdouble.c
arch/arm26/mm/fault.c
arch/cris/mm/fault.c
arch/frv/mm/fault.c
arch/i386/Kconfig
arch/i386/kernel/apic.c
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
arch/i386/kernel/cpu/transmeta.c
arch/i386/kernel/nmi.c
arch/i386/kernel/syscall_table.S
arch/i386/kernel/traps.c
arch/i386/mach-visws/reboot.c
arch/i386/mach-visws/setup.c
arch/i386/mach-voyager/voyager_basic.c
arch/i386/mm/discontig.c
arch/i386/pci/acpi.c
arch/i386/pci/common.c
arch/i386/pci/irq.c
arch/i386/pci/pci.h
arch/i386/pci/visws.c
arch/ia64/Kconfig
arch/ia64/configs/sn2_defconfig
arch/ia64/configs/tiger_defconfig
arch/ia64/configs/zx1_defconfig
arch/ia64/hp/sim/boot/boot_head.S
arch/ia64/kernel/domain.c
arch/ia64/kernel/entry.S
arch/ia64/kernel/perfmon.c
arch/ia64/kernel/process.c
arch/ia64/kernel/salinfo.c
arch/ia64/pci/pci.c
arch/ia64/sn/kernel/io_init.c
arch/m32r/Kconfig
arch/m32r/Kconfig.debug
arch/m32r/kernel/setup_m32700ut.c
arch/m32r/kernel/setup_opsput.c
arch/m32r/kernel/smpboot.c
arch/m32r/kernel/time.c
arch/m32r/lib/csum_partial_copy.c
arch/m32r/mm/discontig.c
arch/m68k/mm/fault.c
arch/parisc/mm/fault.c
arch/ppc/8xx_io/Kconfig
arch/ppc/8xx_io/commproc.c
arch/ppc/8xx_io/fec.c
arch/ppc/Kconfig
arch/ppc/boot/simple/Makefile
arch/ppc/boot/simple/pibs.c
arch/ppc/configs/bamboo_defconfig [new file with mode: 0644]
arch/ppc/kernel/cputable.c
arch/ppc/kernel/entry.S
arch/ppc/kernel/head_44x.S
arch/ppc/kernel/misc.S
arch/ppc/kernel/pci.c
arch/ppc/kernel/ppc_ksyms.c
arch/ppc/platforms/4xx/Kconfig
arch/ppc/platforms/4xx/Makefile
arch/ppc/platforms/4xx/bamboo.c [new file with mode: 0644]
arch/ppc/platforms/4xx/bamboo.h [new file with mode: 0644]
arch/ppc/platforms/4xx/ebony.c
arch/ppc/platforms/4xx/ebony.h
arch/ppc/platforms/4xx/ibm440ep.c [new file with mode: 0644]
arch/ppc/platforms/4xx/ibm440ep.h [new file with mode: 0644]
arch/ppc/platforms/4xx/ocotea.c
arch/ppc/platforms/4xx/ocotea.h
arch/ppc/syslib/Makefile
arch/ppc/syslib/ibm440gx_common.c
arch/ppc/syslib/ibm44x_common.h
arch/ppc/syslib/m8xx_setup.c
arch/ppc/syslib/mpc83xx_devices.c
arch/ppc/syslib/ppc4xx_dma.c
arch/ppc64/boot/zlib.c
arch/ppc64/configs/bpa_defconfig [new file with mode: 0644]
arch/ppc64/configs/g5_defconfig
arch/ppc64/configs/iSeries_defconfig
arch/ppc64/configs/maple_defconfig
arch/ppc64/configs/pSeries_defconfig
arch/ppc64/defconfig
arch/ppc64/kernel/LparData.c
arch/ppc64/kernel/Makefile
arch/ppc64/kernel/head.S
arch/ppc64/kernel/iommu.c
arch/ppc64/kernel/lparmap.c [new file with mode: 0644]
arch/ppc64/kernel/machine_kexec.c
arch/ppc64/kernel/misc.S
arch/ppc64/kernel/mpic.c
arch/ppc64/kernel/mpic.h
arch/ppc64/kernel/pci.c
arch/ppc64/kernel/prom.c
arch/ppc64/kernel/prom_init.c
arch/ppc64/kernel/setup.c
arch/ppc64/kernel/xics.c
arch/ppc64/mm/numa.c
arch/ppc64/xmon/xmon.c
arch/s390/kernel/compat_wrapper.S
arch/s390/kernel/cpcmd.c
arch/s390/kernel/machine_kexec.c
arch/s390/kernel/relocate_kernel.S
arch/s390/kernel/relocate_kernel64.S
arch/s390/kernel/smp.c
arch/s390/kernel/syscalls.S
arch/s390/kernel/traps.c
arch/sh/kernel/entry.S
arch/sh64/kernel/syscalls.S
arch/sh64/mm/fault.c
arch/sparc/kernel/sparc_ksyms.c
arch/sparc64/kernel/Makefile
arch/sparc64/kernel/pci.c
arch/sparc64/kernel/traps.c
arch/sparc64/kernel/una_asm.S [new file with mode: 0644]
arch/sparc64/kernel/unaligned.c
arch/sparc64/kernel/us2e_cpufreq.c
arch/sparc64/kernel/us3_cpufreq.c
arch/sparc64/solaris/socket.c
arch/um/drivers/mmapper_kern.c
arch/um/kernel/skas/process.c
arch/um/os-Linux/elf_aux.c
arch/x86_64/crypto/aes.c
arch/x86_64/defconfig
arch/x86_64/ia32/ptrace32.c
arch/x86_64/kernel/e820.c
arch/x86_64/kernel/mce.c
arch/x86_64/kernel/mpparse.c
arch/x86_64/kernel/setup.c
arch/x86_64/kernel/smpboot.c
arch/x86_64/lib/csum-copy.S
arch/x86_64/mm/fault.c
arch/x86_64/mm/init.c
arch/x86_64/mm/numa.c
arch/x86_64/pci/k8-bus.c
drivers/acorn/block/fd1772.c
drivers/acpi/Kconfig
drivers/acpi/button.c
drivers/acpi/dispatcher/dswload.c
drivers/acpi/ec.c
drivers/acpi/hotkey.c
drivers/acpi/osl.c
drivers/acpi/pci_irq.c
drivers/acpi/pci_link.c
drivers/acpi/processor_idle.c
drivers/acpi/sleep/poweroff.c
drivers/base/bus.c
drivers/base/class.c
drivers/block/cfq-iosched.c
drivers/block/ll_rw_blk.c
drivers/block/scsi_ioctl.c
drivers/bluetooth/bpa10x.c
drivers/bluetooth/hci_bcsp.c
drivers/bluetooth/hci_h4.c
drivers/bluetooth/hci_ldisc.c
drivers/bluetooth/hci_usb.c
drivers/cdrom/cdrom.c
drivers/char/Kconfig
drivers/char/mem.c
drivers/char/rtc.c
drivers/char/tpm/Kconfig
drivers/char/tpm/tpm_infineon.c
drivers/char/vt.c
drivers/char/watchdog/i8xx_tco.c
drivers/char/watchdog/sa1100_wdt.c
drivers/fc4/fc.c
drivers/hwmon/adm1026.c
drivers/hwmon/adm1031.c
drivers/hwmon/adm9240.c
drivers/hwmon/fscpos.c
drivers/hwmon/smsc47b397.c
drivers/hwmon/smsc47m1.c
drivers/i2c/busses/i2c-mpc.c
drivers/i2c/busses/i2c-sibyte.c
drivers/ide/Kconfig
drivers/ide/ide-disk.c
drivers/ide/ide-floppy.c
drivers/ide/ide-probe.c
drivers/ide/legacy/ide-cs.c
drivers/ide/pci/generic.c
drivers/ide/pci/serverworks.c
drivers/ide/ppc/pmac.c
drivers/ide/setup-pci.c
drivers/ieee1394/ohci1394.c
drivers/infiniband/Kconfig
drivers/infiniband/core/uverbs_main.c
drivers/infiniband/include/ib_cm.h
drivers/infiniband/ulp/ipoib/ipoib_main.c
drivers/input/gameport/ns558.c
drivers/isdn/capi/capifs.c
drivers/isdn/hisax/Kconfig
drivers/isdn/icn/icn.c
drivers/macintosh/Kconfig
drivers/md/bitmap.c
drivers/md/dm-raid1.c
drivers/md/md.c
drivers/md/raid1.c
drivers/md/raid5.c
drivers/md/raid6main.c
drivers/media/dvb/dvb-usb/dibusb-common.c
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
drivers/media/dvb/frontends/Kconfig
drivers/media/dvb/frontends/dvb-pll.c
drivers/media/dvb/frontends/dvb-pll.h
drivers/media/dvb/frontends/lgdt330x.c
drivers/media/dvb/frontends/lgdt330x.h
drivers/media/dvb/frontends/lgdt330x_priv.h
drivers/media/video/Kconfig
drivers/media/video/bttv-cards.c
drivers/media/video/bttv-driver.c
drivers/media/video/bttv.h
drivers/media/video/bttvp.h
drivers/media/video/cx88/cx88-cards.c
drivers/media/video/cx88/cx88-dvb.c
drivers/media/video/cx88/cx88-video.c
drivers/media/video/cx88/cx88.h
drivers/media/video/msp3400.c
drivers/media/video/saa7134/saa7134-i2c.c
drivers/media/video/saa7134/saa7134.h
drivers/media/video/tea5767.c
drivers/media/video/tuner-core.c
drivers/media/video/tuner-simple.c
drivers/media/video/tveeprom.c
drivers/message/i2o/Kconfig
drivers/message/i2o/config-osm.c
drivers/message/i2o/pci.c
drivers/mmc/wbsd.c
drivers/net/8139cp.c
drivers/net/Kconfig
drivers/net/cs89x0.c
drivers/net/cs89x0.h
drivers/net/dm9000.c
drivers/net/e1000/e1000_main.c
drivers/net/hamradio/6pack.c
drivers/net/hamradio/Kconfig
drivers/net/ibm_emac/ibm_emac_core.c
drivers/net/ioc3-eth.c
drivers/net/loopback.c
drivers/net/sk98lin/skge.c
drivers/net/sk98lin/skgeinit.c
drivers/net/sk98lin/skxmac2.c
drivers/net/skge.c
drivers/net/skge.h
drivers/net/smc91x.h
drivers/net/tg3.c
drivers/net/tokenring/Kconfig
drivers/net/wireless/Kconfig
drivers/parport/Kconfig
drivers/pci/bus.c
drivers/pci/hotplug/pciehp.h
drivers/pci/hotplug/pciehp_core.c
drivers/pci/hotplug/pciehp_ctrl.c
drivers/pci/hotplug/pciehp_hpc.c
drivers/pci/hotplug/pciehp_pci.c
drivers/pci/hotplug/pciehprm.h
drivers/pci/hotplug/pciehprm_acpi.c
drivers/pci/hotplug/pciehprm_nonacpi.c
drivers/pci/hotplug/pciehprm_nonacpi.h
drivers/pci/hotplug/shpchp.h
drivers/pci/hotplug/shpchp_core.c
drivers/pci/hotplug/shpchp_ctrl.c
drivers/pci/hotplug/shpchp_hpc.c
drivers/pci/hotplug/shpchp_pci.c
drivers/pci/hotplug/shpchprm.h
drivers/pci/hotplug/shpchprm_acpi.c
drivers/pci/hotplug/shpchprm_legacy.c
drivers/pci/hotplug/shpchprm_legacy.h
drivers/pci/hotplug/shpchprm_nonacpi.c
drivers/pci/hotplug/shpchprm_nonacpi.h
drivers/pci/msi.c
drivers/pci/pci.h
drivers/pci/quirks.c
drivers/pci/setup-bus.c
drivers/pci/setup-res.c
drivers/pcmcia/ds.c
drivers/pcmcia/pcmcia_resource.c
drivers/pcmcia/yenta_socket.c
drivers/pnp/card.c
drivers/s390/cio/qdio.c
drivers/s390/crypto/z90crypt.h
drivers/s390/net/qeth_main.c
drivers/s390/net/qeth_proc.c
drivers/s390/scsi/zfcp_aux.c
drivers/s390/scsi/zfcp_ccw.c
drivers/s390/scsi/zfcp_def.h
drivers/s390/scsi/zfcp_erp.c
drivers/s390/scsi/zfcp_ext.h
drivers/s390/scsi/zfcp_fsf.c
drivers/s390/scsi/zfcp_scsi.c
drivers/sbus/char/bbc_envctrl.c
drivers/sbus/char/envctrl.c
drivers/sbus/char/vfc.h
drivers/sbus/char/vfc_dev.c
drivers/sbus/char/vfc_i2c.c
drivers/scsi/Kconfig
drivers/scsi/aacraid/aacraid.h
drivers/scsi/aacraid/linit.c
drivers/scsi/ahci.c
drivers/scsi/aic7xxx/aic7xxx_osm.c
drivers/scsi/arm/Kconfig
drivers/scsi/ata_piix.c
drivers/scsi/dc395x.c
drivers/scsi/dpt_i2o.c
drivers/scsi/ibmvscsi/srp.h
drivers/scsi/ips.c
drivers/scsi/ips.h
drivers/scsi/libata-core.c
drivers/scsi/libata-scsi.c
drivers/scsi/libata.h
drivers/scsi/sata_promise.c
drivers/scsi/sata_sx4.c
drivers/scsi/scsi_lib.c
drivers/scsi/scsi_scan.c
drivers/scsi/scsi_transport_fc.c
drivers/scsi/sg.c
drivers/scsi/st.c
drivers/serial/Kconfig
drivers/serial/cpm_uart/cpm_uart.h
drivers/serial/cpm_uart/cpm_uart_core.c
drivers/serial/cpm_uart/cpm_uart_cpm1.c
drivers/serial/m32r_sio.c
drivers/serial/sn_console.c
drivers/usb/host/ehci-dbg.c
drivers/usb/host/ehci-q.c
drivers/usb/host/ehci-sched.c
drivers/usb/host/ehci.h
drivers/usb/host/isp116x-hcd.c
drivers/usb/input/wacom.c
drivers/usb/mon/Kconfig
drivers/usb/mon/Makefile
drivers/usb/mon/mon_main.c
drivers/usb/mon/usb_mon.h
drivers/usb/net/usbnet.c
drivers/usb/net/zd1201.c
drivers/video/console/Kconfig
drivers/video/fbmem.c
drivers/video/fbsysfs.c
drivers/video/intelfb/intelfbdrv.c
drivers/video/modedb.c
drivers/video/nvidia/nvidia.c
drivers/video/pxafb.c
drivers/video/radeonfb.c
drivers/video/sa1100fb.c
drivers/video/tridentfb.c
drivers/w1/w1.c
fs/Kconfig
fs/afs/mntpt.c
fs/autofs/symlink.c
fs/autofs4/symlink.c
fs/befs/linuxvfs.c
fs/bio.c
fs/cifs/CHANGES
fs/cifs/cifsfs.h
fs/cifs/cifssmb.c
fs/cifs/file.c
fs/cifs/link.c
fs/cifs/misc.c
fs/dcache.c
fs/devfs/base.c
fs/ext2/symlink.c
fs/ext3/symlink.c
fs/freevxfs/vxfs_immed.c
fs/hfs/bnode.c
fs/hfs/extent.c
fs/hfsplus/bnode.c
fs/hfsplus/extents.c
fs/hppfs/hppfs_kern.c
fs/inotify.c
fs/ioprio.c
fs/isofs/compress.c
fs/jffs2/symlink.c
fs/jfs/inode.c
fs/jfs/jfs_logmgr.c
fs/jfs/jfs_logmgr.h
fs/jfs/jfs_txnmgr.c
fs/jfs/super.c
fs/jfs/symlink.c
fs/namei.c
fs/namespace.c
fs/nfs/dir.c
fs/nfs/file.c
fs/nfs/inode.c
fs/nfs/nfs3acl.c
fs/nfs/nfs3proc.c
fs/nfs/nfs4proc.c
fs/nfs/proc.c
fs/nfs/read.c
fs/nfs/symlink.c
fs/nfs_common/nfsacl.c
fs/nfsd/nfssvc.c
fs/ntfs/ChangeLog
fs/ntfs/aops.c
fs/ntfs/mft.c
fs/proc/base.c
fs/proc/generic.c
fs/reiserfs/inode.c
fs/reiserfs/namei.c
fs/smbfs/symlink.c
fs/sysfs/inode.c
fs/sysfs/symlink.c
fs/sysv/symlink.c
fs/ufs/symlink.c
fs/xfs/linux-2.6/xfs_iops.c
include/acpi/acpi_drivers.h
include/asm-alpha/pci.h
include/asm-alpha/system.h
include/asm-arm/arch-ixp4xx/timex.h
include/asm-arm/arch-s3c2410/usb-control.h
include/asm-arm/bug.h
include/asm-arm/cpu-multi32.h
include/asm-arm/cpu-single.h
include/asm-arm/pci.h
include/asm-arm/pgtable.h
include/asm-arm/unistd.h
include/asm-generic/pci.h
include/asm-i386/mach-visws/do_timer.h
include/asm-i386/processor.h
include/asm-ia64/io.h
include/asm-ia64/iosapic.h
include/asm-m32r/smp.h
include/asm-m68k/page.h
include/asm-parisc/pci.h
include/asm-ppc/ibm44x.h
include/asm-ppc/ibm4xx.h
include/asm-ppc/ibm_ocp.h
include/asm-ppc/pci.h
include/asm-ppc/pgtable.h
include/asm-ppc/ppc4xx_dma.h
include/asm-ppc/ppc_asm.h
include/asm-ppc/time.h
include/asm-ppc/unistd.h
include/asm-ppc64/bug.h
include/asm-ppc64/iSeries/LparMap.h
include/asm-ppc64/machdep.h
include/asm-ppc64/pci.h
include/asm-ppc64/topology.h
include/asm-ppc64/unistd.h
include/asm-ppc64/xics.h
include/asm-s390/uaccess.h
include/asm-s390/unistd.h
include/asm-sh/unistd.h
include/asm-sh64/unistd.h
include/asm-sparc64/thread_info.h
include/asm-um/page.h
include/asm-x86_64/e820.h
include/asm-x86_64/processor.h
include/linux/acpi.h
include/linux/bio.h
include/linux/blkdev.h
include/linux/dcookies.h
include/linux/fs.h
include/linux/fsnotify.h
include/linux/ide.h
include/linux/inotify.h
include/linux/mm.h
include/linux/netlink.h
include/linux/netpoll.h
include/linux/nfs_fs.h
include/linux/pci.h
include/linux/pci_ids.h
include/linux/raid/bitmap.h
include/linux/skbuff.h
include/linux/sunrpc/xdr.h
include/linux/swap.h
include/linux/zlib.h
include/media/tuner.h
include/net/ax25.h
include/net/bluetooth/bluetooth.h
include/net/sock.h
include/net/tcp.h
include/scsi/scsi_request.h
include/scsi/scsi_transport.h
include/sound/core.h
ipc/sem.c
ipc/shm.c
kernel/cpuset.c
kernel/exit.c
kernel/module.c
kernel/posix-timers.c
kernel/sched.c
kernel/signal.c
kernel/softirq.c
kernel/sys.c
kernel/sys_ni.c
kernel/timer.c
kernel/workqueue.c
lib/crc32.c
lib/idr.c
lib/inflate.c
lib/vsprintf.c
mm/hugetlb.c
mm/memory.c
mm/mempolicy.c
mm/mmap.c
mm/mremap.c
mm/nommu.c
mm/page_alloc.c
mm/shmem.c
net/802/tr.c
net/ax25/af_ax25.c
net/ax25/ax25_route.c
net/ax25/ax25_uid.c
net/bluetooth/hci_core.c
net/bluetooth/hci_event.c
net/bluetooth/lib.c
net/bluetooth/rfcomm/core.c
net/compat.c
net/core/dev.c
net/core/dst.c
net/core/netpoll.c
net/decnet/af_decnet.c
net/decnet/dn_neigh.c
net/ipv4/fib_semantics.c
net/ipv4/fib_trie.c
net/ipv4/icmp.c
net/ipv4/inetpeer.c
net/ipv4/ip_fragment.c
net/ipv4/ip_gre.c
net/ipv4/ip_sockglue.c
net/ipv4/ipcomp.c
net/ipv4/ipip.c
net/ipv4/ipmr.c
net/ipv4/netfilter/ip_conntrack_core.c
net/ipv4/netfilter/ip_nat_standalone.c
net/ipv4/netfilter/ip_queue.c
net/ipv4/netfilter/ipt_ECN.c
net/ipv4/netfilter/ipt_TCPMSS.c
net/ipv4/tcp.c
net/ipv4/tcp_ipv4.c
net/ipv4/tcp_output.c
net/ipv4/udp.c
net/ipv6/ip6_input.c
net/ipv6/ipcomp6.c
net/ipv6/ipv6_sockglue.c
net/ipv6/netfilter/ip6_queue.c
net/ipv6/raw.c
net/ipv6/sit.c
net/ipv6/tcp_ipv6.c
net/netrom/af_netrom.c
net/rose/af_rose.c
net/rose/rose_route.c
net/sched/sch_generic.c
net/sctp/proc.c
net/sunrpc/auth_gss/gss_krb5_crypto.c
net/sunrpc/svcsock.c
net/sunrpc/xdr.c
scripts/mod/modpost.c
security/keys/keyctl.c
security/keys/keyring.c
security/keys/process_keys.c
security/keys/request_key.c
sound/Kconfig
sound/core/Makefile
sound/core/sound.c
sound/isa/Kconfig
sound/oss/Kconfig
sound/oss/Makefile
sound/oss/i810_audio.c
sound/oss/vidc.h
sound/pci/Kconfig
sound/pci/intel8x0.c
sound/ppc/pmac.c

diff --git a/CREDITS b/CREDITS
index d97e62524ddcc46ae7e15a3577cf745a03844445..f553f8cfaa6266a54bc4081d448719d73abb5001 100644 (file)
--- a/CREDITS
+++ b/CREDITS
@@ -2380,8 +2380,8 @@ E: tmolina@cablespeed.com
 D: bug fixes, documentation, minor hackery
 
 N: James Morris
-E: jmorris@redhat.com
-W: http://www.intercode.com.au/jmorris/
+E: jmorris@namei.org
+W: http://namei.org/
 D: Netfilter, Linux Security Modules (LSM), SELinux, IPSec,
 D: Crypto API, general networking, miscellaneous.
 S: PO Box 707
@@ -2423,8 +2423,7 @@ S: Toronto, Ontario
 S: Canada
 
 N: Zwane Mwaikambo
-E: zwane@linuxpower.ca
-W: http://function.linuxpower.ca
+E: zwane@arm.linux.org.uk
 D: Various driver hacking
 D: Lowlevel x86 kernel hacking
 D: General debugging
index 6761a7b241a5fafbe77c69d09e23b1dd56781f06..7f43b040311e526e3e3fdf36f1f3a6f7d98f0f18 100644 (file)
@@ -149,6 +149,11 @@ USB, framebuffer devices, the VFS, the SCSI subsystem, etc.  See the
 MAINTAINERS file for a mailing list that relates specifically to
 your change.
 
+If changes affect userland-kernel interfaces, please send
+the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
+a man-pages patch, or at least a notification of the change,
+so that some information makes its way into the manual pages.
+
 Even if the maintainer did not respond in step #4, make sure to ALWAYS
 copy the maintainer when you change their code.
 
index 4c115a7bb8262a95080bbc36355ca77fcd3faa2e..0acdc80c30c2fab156a02238e6146afd6496425f 100644 (file)
@@ -33,3 +33,6 @@ The result of the execution of this aml method is
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method" 
 to retrieve it.
+
+Note: Use cmdline "acpi_generic_hotkey" to over-ride
+loading any platform specific drivers.
diff --git a/Documentation/arm/Samsung-S3C24XX/USB-Host.txt b/Documentation/arm/Samsung-S3C24XX/USB-Host.txt
new file mode 100644 (file)
index 0000000..b93b68e
--- /dev/null
@@ -0,0 +1,93 @@
+                       S3C24XX USB Host support
+                       ========================
+
+
+
+Introduction
+------------
+
+  This document details the S3C2410/S3C2440 in-built OHCI USB host support.
+
+Configuration
+-------------
+
+  Enable at least the following kernel options:
+
+  menuconfig:
+
+   Device Drivers  --->
+     USB support  --->
+       <*> Support for Host-side USB
+       <*>   OHCI HCD support
+
+
+  .config:
+    CONFIG_USB
+    CONFIG_USB_OHCI_HCD
+
+
+  Once these options are configured, the standard set of USB device
+  drivers can be configured and used.
+
+
+Board Support
+-------------
+
+  The driver attaches to a platform device, which will need to be
+  added by the board specific support file in linux/arch/arm/mach-s3c2410,
+  such as mach-bast.c or mach-smdk2410.c
+
+  The platform device's platform_data field is only needed if the
+  board implements extra power control or over-current monitoring.
+
+  The OHCI driver does not ensure the state of the S3C2410's MISCCTRL
+  register, so if both ports are to be used for the host, then it is
+  the board support file's responsibility to ensure that the second
+  port is configured to be connected to the OHCI core.
+
+
+Platform Data
+-------------
+
+  See linux/include/asm-arm/arch-s3c2410/usb-control.h for the
+  descriptions of the platform device data. An implementation
+  can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
+
+  The `struct s3c2410_hcd_info` contains a pair of functions
+  that get called to enable over-current detection, and to
+  control the port power status.
+
+  The ports are numbered 0 and 1.
+
+  power_control:
+
+    Called to enable or disable the power on the port.
+
+  enable_oc:
+
+    Called to enable or disable the over-current monitoring.
+    This should claim or release the resources being used to
+    check the power condition on the port, such as an IRQ.
+
+  report_oc:
+
+    The OHCI driver fills this field in for the over-current code
+    to call when there is a change to the over-current state on
+    an port. The ports argument is a bitmask of 1 bit per port,
+    with bit X being 1 for an over-current on port X.
+
+    The function s3c2410_usb_report_oc() has been provided to
+    ensure this is called correctly.
+
+  port[x]:
+
+    This is struct describes each port, 0 or 1. The platform driver
+    should set the flags field of each port to S3C_HCDFLG_USED if
+    the port is enabled.
+
+
+
+Document Author
+---------------
+
+Ben Dooks, (c) 2005 Simtec Electronics
index b974cf595d0185627d53cf65d84e41d1585e5ac5..96bea278bbf61eb9ae6d6cb5657f8092b543a87e 100644 (file)
@@ -104,6 +104,7 @@ logo_*.c
 logo_*_clut224.c
 logo_*_mono.c
 lxdialog
+mach-types
 mach-types.h
 make_times_h
 map
index 814e2f56a6ad35ce367e2d542769664c8b6641f3..62db6758d1c1050db42b638ad4d42dc06809c68b 100644 (file)
@@ -144,7 +144,21 @@ vgapal     Use the standard vga registers for palette changes.
        This is the default.
 pmipal Use the protected mode interface for palette changes.
 
-mtrr   setup memory type range registers for the vesafb framebuffer.
+mtrr:n setup memory type range registers for the vesafb framebuffer
+       where n:
+             0 - disabled (equivalent to nomtrr)
+             1 - uncachable
+             2 - write-back
+             3 - write-combining (default)
+             4 - write-through
+
+       If you see the following in dmesg, choose the type that matches the
+       old one. In this example, use "mtrr:2".
+...
+mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
+...
+
+nomtrr  disable mtrr
 
 vremap:n
         remap 'n' MiB of video RAM. If 0 or not specified, remap memory
index a998a8c2f95baee78ec3080a244a4ff8fa280fa6..3d5cd7a09b2fc1aa56b6c197ee8d35df7116ec4d 100644 (file)
@@ -159,6 +159,11 @@ running once the system is up.
 
        acpi_fake_ecdt  [HW,ACPI] Workaround failure due to BIOS lacking ECDT
 
+       acpi_generic_hotkey [HW,ACPI]
+                       Allow consolidated generic hotkey driver to
+                       over-ride platform specific driver.
+                       See also Documentation/acpi-hotkey.txt.
+
        ad1816=         [HW,OSS]
                        Format: <io>,<irq>,<dma>,<dma2>
                        See also Documentation/sound/oss/AD1816.
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
new file mode 100644 (file)
index 0000000..0541fe1
--- /dev/null
@@ -0,0 +1,588 @@
+Title  : Kernel Probes (Kprobes)
+Authors        : Jim Keniston <jkenisto@us.ibm.com>
+       : Prasanna S Panchamukhi <prasanna@in.ibm.com>
+
+CONTENTS
+
+1. Concepts: Kprobes, Jprobes, Return Probes
+2. Architectures Supported
+3. Configuring Kprobes
+4. API Reference
+5. Kprobes Features and Limitations
+6. Probe Overhead
+7. TODO
+8. Kprobes Example
+9. Jprobes Example
+10. Kretprobes Example
+
+1. Concepts: Kprobes, Jprobes, Return Probes
+
+Kprobes enables you to dynamically break into any kernel routine and
+collect debugging and performance information non-disruptively. You
+can trap at almost any kernel code address, specifying a handler
+routine to be invoked when the breakpoint is hit.
+
+There are currently three types of probes: kprobes, jprobes, and
+kretprobes (also called return probes).  A kprobe can be inserted
+on virtually any instruction in the kernel.  A jprobe is inserted at
+the entry to a kernel function, and provides convenient access to the
+function's arguments.  A return probe fires when a specified function
+returns.
+
+In the typical case, Kprobes-based instrumentation is packaged as
+a kernel module.  The module's init function installs ("registers")
+one or more probes, and the exit function unregisters them.  A
+registration function such as register_kprobe() specifies where
+the probe is to be inserted and what handler is to be called when
+the probe is hit.
+
+The next three subsections explain how the different types of
+probes work.  They explain certain things that you'll need to
+know in order to make the best use of Kprobes -- e.g., the
+difference between a pre_handler and a post_handler, and how
+to use the maxactive and nmissed fields of a kretprobe.  But
+if you're in a hurry to start using Kprobes, you can skip ahead
+to section 2.
+
+1.1 How Does a Kprobe Work?
+
+When a kprobe is registered, Kprobes makes a copy of the probed
+instruction and replaces the first byte(s) of the probed instruction
+with a breakpoint instruction (e.g., int3 on i386 and x86_64).
+
+When a CPU hits the breakpoint instruction, a trap occurs, the CPU's
+registers are saved, and control passes to Kprobes via the
+notifier_call_chain mechanism.  Kprobes executes the "pre_handler"
+associated with the kprobe, passing the handler the addresses of the
+kprobe struct and the saved registers.
+
+Next, Kprobes single-steps its copy of the probed instruction.
+(It would be simpler to single-step the actual instruction in place,
+but then Kprobes would have to temporarily remove the breakpoint
+instruction.  This would open a small time window when another CPU
+could sail right past the probepoint.)
+
+After the instruction is single-stepped, Kprobes executes the
+"post_handler," if any, that is associated with the kprobe.
+Execution then continues with the instruction following the probepoint.
+
+1.2 How Does a Jprobe Work?
+
+A jprobe is implemented using a kprobe that is placed on a function's
+entry point.  It employs a simple mirroring principle to allow
+seamless access to the probed function's arguments.  The jprobe
+handler routine should have the same signature (arg list and return
+type) as the function being probed, and must always end by calling
+the Kprobes function jprobe_return().
+
+Here's how it works.  When the probe is hit, Kprobes makes a copy of
+the saved registers and a generous portion of the stack (see below).
+Kprobes then points the saved instruction pointer at the jprobe's
+handler routine, and returns from the trap.  As a result, control
+passes to the handler, which is presented with the same register and
+stack contents as the probed function.  When it is done, the handler
+calls jprobe_return(), which traps again to restore the original stack
+contents and processor state and switch to the probed function.
+
+By convention, the callee owns its arguments, so gcc may produce code
+that unexpectedly modifies that portion of the stack.  This is why
+Kprobes saves a copy of the stack and restores it after the jprobe
+handler has run.  Up to MAX_STACK_SIZE bytes are copied -- e.g.,
+64 bytes on i386.
+
+Note that the probed function's args may be passed on the stack
+or in registers (e.g., for x86_64 or for an i386 fastcall function).
+The jprobe will work in either case, so long as the handler's
+prototype matches that of the probed function.
+
+1.3 How Does a Return Probe Work?
+
+When you call register_kretprobe(), Kprobes establishes a kprobe at
+the entry to the function.  When the probed function is called and this
+probe is hit, Kprobes saves a copy of the return address, and replaces
+the return address with the address of a "trampoline."  The trampoline
+is an arbitrary piece of code -- typically just a nop instruction.
+At boot time, Kprobes registers a kprobe at the trampoline.
+
+When the probed function executes its return instruction, control
+passes to the trampoline and that probe is hit.  Kprobes' trampoline
+handler calls the user-specified handler associated with the kretprobe,
+then sets the saved instruction pointer to the saved return address,
+and that's where execution resumes upon return from the trap.
+
+While the probed function is executing, its return address is
+stored in an object of type kretprobe_instance.  Before calling
+register_kretprobe(), the user sets the maxactive field of the
+kretprobe struct to specify how many instances of the specified
+function can be probed simultaneously.  register_kretprobe()
+pre-allocates the indicated number of kretprobe_instance objects.
+
+For example, if the function is non-recursive and is called with a
+spinlock held, maxactive = 1 should be enough.  If the function is
+non-recursive and can never relinquish the CPU (e.g., via a semaphore
+or preemption), NR_CPUS should be enough.  If maxactive <= 0, it is
+set to a default value.  If CONFIG_PREEMPT is enabled, the default
+is max(10, 2*NR_CPUS).  Otherwise, the default is NR_CPUS.
+
+It's not a disaster if you set maxactive too low; you'll just miss
+some probes.  In the kretprobe struct, the nmissed field is set to
+zero when the return probe is registered, and is incremented every
+time the probed function is entered but there is no kretprobe_instance
+object available for establishing the return probe.
+
+2. Architectures Supported
+
+Kprobes, jprobes, and return probes are implemented on the following
+architectures:
+
+- i386
+- x86_64 (AMD-64, E64MT)
+- ppc64
+- ia64 (Support for probes on certain instruction types is still in progress.)
+- sparc64 (Return probes not yet implemented.)
+
+3. Configuring Kprobes
+
+When configuring the kernel using make menuconfig/xconfig/oldconfig,
+ensure that CONFIG_KPROBES is set to "y".  Under "Kernel hacking",
+look for "Kprobes".  You may have to enable "Kernel debugging"
+(CONFIG_DEBUG_KERNEL) before you can enable Kprobes.
+
+You may also want to ensure that CONFIG_KALLSYMS and perhaps even
+CONFIG_KALLSYMS_ALL are set to "y", since kallsyms_lookup_name()
+is a handy, version-independent way to find a function's address.
+
+If you need to insert a probe in the middle of a function, you may find
+it useful to "Compile the kernel with debug info" (CONFIG_DEBUG_INFO),
+so you can use "objdump -d -l vmlinux" to see the source-to-object
+code mapping.
+
+4. API Reference
+
+The Kprobes API includes a "register" function and an "unregister"
+function for each type of probe.  Here are terse, mini-man-page
+specifications for these functions and the associated probe handlers
+that you'll write.  See the latter half of this document for examples.
+
+4.1 register_kprobe
+
+#include <linux/kprobes.h>
+int register_kprobe(struct kprobe *kp);
+
+Sets a breakpoint at the address kp->addr.  When the breakpoint is
+hit, Kprobes calls kp->pre_handler.  After the probed instruction
+is single-stepped, Kprobe calls kp->post_handler.  If a fault
+occurs during execution of kp->pre_handler or kp->post_handler,
+or during single-stepping of the probed instruction, Kprobes calls
+kp->fault_handler.  Any or all handlers can be NULL.
+
+register_kprobe() returns 0 on success, or a negative errno otherwise.
+
+User's pre-handler (kp->pre_handler):
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+int pre_handler(struct kprobe *p, struct pt_regs *regs);
+
+Called with p pointing to the kprobe associated with the breakpoint,
+and regs pointing to the struct containing the registers saved when
+the breakpoint was hit.  Return 0 here unless you're a Kprobes geek.
+
+User's post-handler (kp->post_handler):
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+void post_handler(struct kprobe *p, struct pt_regs *regs,
+       unsigned long flags);
+
+p and regs are as described for the pre_handler.  flags always seems
+to be zero.
+
+User's fault-handler (kp->fault_handler):
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+int fault_handler(struct kprobe *p, struct pt_regs *regs, int trapnr);
+
+p and regs are as described for the pre_handler.  trapnr is the
+architecture-specific trap number associated with the fault (e.g.,
+on i386, 13 for a general protection fault or 14 for a page fault).
+Returns 1 if it successfully handled the exception.
+
+4.2 register_jprobe
+
+#include <linux/kprobes.h>
+int register_jprobe(struct jprobe *jp)
+
+Sets a breakpoint at the address jp->kp.addr, which must be the address
+of the first instruction of a function.  When the breakpoint is hit,
+Kprobes runs the handler whose address is jp->entry.
+
+The handler should have the same arg list and return type as the probed
+function; and just before it returns, it must call jprobe_return().
+(The handler never actually returns, since jprobe_return() returns
+control to Kprobes.)  If the probed function is declared asmlinkage,
+fastcall, or anything else that affects how args are passed, the
+handler's declaration must match.
+
+register_jprobe() returns 0 on success, or a negative errno otherwise.
+
+4.3 register_kretprobe
+
+#include <linux/kprobes.h>
+int register_kretprobe(struct kretprobe *rp);
+
+Establishes a return probe for the function whose address is
+rp->kp.addr.  When that function returns, Kprobes calls rp->handler.
+You must set rp->maxactive appropriately before you call
+register_kretprobe(); see "How Does a Return Probe Work?" for details.
+
+register_kretprobe() returns 0 on success, or a negative errno
+otherwise.
+
+User's return-probe handler (rp->handler):
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+int kretprobe_handler(struct kretprobe_instance *ri, struct pt_regs *regs);
+
+regs is as described for kprobe.pre_handler.  ri points to the
+kretprobe_instance object, of which the following fields may be
+of interest:
+- ret_addr: the return address
+- rp: points to the corresponding kretprobe object
+- task: points to the corresponding task struct
+The handler's return value is currently ignored.
+
+4.4 unregister_*probe
+
+#include <linux/kprobes.h>
+void unregister_kprobe(struct kprobe *kp);
+void unregister_jprobe(struct jprobe *jp);
+void unregister_kretprobe(struct kretprobe *rp);
+
+Removes the specified probe.  The unregister function can be called
+at any time after the probe has been registered.
+
+5. Kprobes Features and Limitations
+
+As of Linux v2.6.12, Kprobes allows multiple probes at the same
+address.  Currently, however, there cannot be multiple jprobes on
+the same function at the same time.
+
+In general, you can install a probe anywhere in the kernel.
+In particular, you can probe interrupt handlers.  Known exceptions
+are discussed in this section.
+
+For obvious reasons, it's a bad idea to install a probe in
+the code that implements Kprobes (mostly kernel/kprobes.c and
+arch/*/kernel/kprobes.c).  A patch in the v2.6.13 timeframe instructs
+Kprobes to reject such requests.
+
+If you install a probe in an inline-able function, Kprobes makes
+no attempt to chase down all inline instances of the function and
+install probes there.  gcc may inline a function without being asked,
+so keep this in mind if you're not seeing the probe hits you expect.
+
+A probe handler can modify the environment of the probed function
+-- e.g., by modifying kernel data structures, or by modifying the
+contents of the pt_regs struct (which are restored to the registers
+upon return from the breakpoint).  So Kprobes can be used, for example,
+to install a bug fix or to inject faults for testing.  Kprobes, of
+course, has no way to distinguish the deliberately injected faults
+from the accidental ones.  Don't drink and probe.
+
+Kprobes makes no attempt to prevent probe handlers from stepping on
+each other -- e.g., probing printk() and then calling printk() from a
+probe handler.  As of Linux v2.6.12, if a probe handler hits a probe,
+that second probe's handlers won't be run in that instance.
+
+In Linux v2.6.12 and previous versions, Kprobes' data structures are
+protected by a single lock that is held during probe registration and
+unregistration and while handlers are run.  Thus, no two handlers
+can run simultaneously.  To improve scalability on SMP systems,
+this restriction will probably be removed soon, in which case
+multiple handlers (or multiple instances of the same handler) may
+run concurrently on different CPUs.  Code your handlers accordingly.
+
+Kprobes does not use semaphores or allocate memory except during
+registration and unregistration.
+
+Probe handlers are run with preemption disabled.  Depending on the
+architecture, handlers may also run with interrupts disabled.  In any
+case, your handler should not yield the CPU (e.g., by attempting to
+acquire a semaphore).
+
+Since a return probe is implemented by replacing the return
+address with the trampoline's address, stack backtraces and calls
+to __builtin_return_address() will typically yield the trampoline's
+address instead of the real return address for kretprobed functions.
+(As far as we can tell, __builtin_return_address() is used only
+for instrumentation and error reporting.)
+
+If the number of times a function is called does not match the
+number of times it returns, registering a return probe on that
+function may produce undesirable results.  We have the do_exit()
+and do_execve() cases covered.  do_fork() is not an issue.  We're
+unaware of other specific cases where this could be a problem.
+
+6. Probe Overhead
+
+On a typical CPU in use in 2005, a kprobe hit takes 0.5 to 1.0
+microseconds to process.  Specifically, a benchmark that hits the same
+probepoint repeatedly, firing a simple handler each time, reports 1-2
+million hits per second, depending on the architecture.  A jprobe or
+return-probe hit typically takes 50-75% longer than a kprobe hit.
+When you have a return probe set on a function, adding a kprobe at
+the entry to that function adds essentially no overhead.
+
+Here are sample overhead figures (in usec) for different architectures.
+k = kprobe; j = jprobe; r = return probe; kr = kprobe + return probe
+on same function; jr = jprobe + return probe on same function
+
+i386: Intel Pentium M, 1495 MHz, 2957.31 bogomips
+k = 0.57 usec; j = 1.00; r = 0.92; kr = 0.99; jr = 1.40
+
+x86_64: AMD Opteron 246, 1994 MHz, 3971.48 bogomips
+k = 0.49 usec; j = 0.76; r = 0.80; kr = 0.82; jr = 1.07
+
+ppc64: POWER5 (gr), 1656 MHz (SMT disabled, 1 virtual CPU per physical CPU)
+k = 0.77 usec; j = 1.31; r = 1.26; kr = 1.45; jr = 1.99
+
+7. TODO
+
+a. SystemTap (http://sourceware.org/systemtap): Work in progress
+to provide a simplified programming interface for probe-based
+instrumentation.
+b. Improved SMP scalability: Currently, work is in progress to handle
+multiple kprobes in parallel.
+c. Kernel return probes for sparc64.
+d. Support for other architectures.
+e. User-space probes.
+
+8. Kprobes Example
+
+Here's a sample kernel module showing the use of kprobes to dump a
+stack trace and selected i386 registers when do_fork() is called.
+----- cut here -----
+/*kprobe_example.c*/
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/kprobes.h>
+#include <linux/kallsyms.h>
+#include <linux/sched.h>
+
+/*For each probe you need to allocate a kprobe structure*/
+static struct kprobe kp;
+
+/*kprobe pre_handler: called just before the probed instruction is executed*/
+int handler_pre(struct kprobe *p, struct pt_regs *regs)
+{
+       printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n",
+               p->addr, regs->eip, regs->eflags);
+       dump_stack();
+       return 0;
+}
+
+/*kprobe post_handler: called after the probed instruction is executed*/
+void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags)
+{
+       printk("post_handler: p->addr=0x%p, eflags=0x%lx\n",
+               p->addr, regs->eflags);
+}
+
+/* fault_handler: this is called if an exception is generated for any
+ * instruction within the pre- or post-handler, or when Kprobes
+ * single-steps the probed instruction.
+ */
+int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
+{
+       printk("fault_handler: p->addr=0x%p, trap #%dn",
+               p->addr, trapnr);
+       /* Return 0 because we don't handle the fault. */
+       return 0;
+}
+
+int init_module(void)
+{
+       int ret;
+       kp.pre_handler = handler_pre;
+       kp.post_handler = handler_post;
+       kp.fault_handler = handler_fault;
+       kp.addr = (kprobe_opcode_t*) kallsyms_lookup_name("do_fork");
+       /* register the kprobe now */
+       if (!kp.addr) {
+               printk("Couldn't find %s to plant kprobe\n", "do_fork");
+               return -1;
+       }
+       if ((ret = register_kprobe(&kp) < 0)) {
+               printk("register_kprobe failed, returned %d\n", ret);
+               return -1;
+       }
+       printk("kprobe registered\n");
+       return 0;
+}
+
+void cleanup_module(void)
+{
+       unregister_kprobe(&kp);
+       printk("kprobe unregistered\n");
+}
+
+MODULE_LICENSE("GPL");
+----- cut here -----
+
+You can build the kernel module, kprobe-example.ko, using the following
+Makefile:
+----- cut here -----
+obj-m := kprobe-example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+       $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+       rm -f *.mod.c *.ko *.o
+----- cut here -----
+
+$ make
+$ su -
+...
+# insmod kprobe-example.ko
+
+You will see the trace data in /var/log/messages and on the console
+whenever do_fork() is invoked to create a new process.
+
+9. Jprobes Example
+
+Here's a sample kernel module showing the use of jprobes to dump
+the arguments of do_fork().
+----- cut here -----
+/*jprobe-example.c */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/uio.h>
+#include <linux/kprobes.h>
+#include <linux/kallsyms.h>
+
+/*
+ * Jumper probe for do_fork.
+ * Mirror principle enables access to arguments of the probed routine
+ * from the probe handler.
+ */
+
+/* Proxy routine having the same arguments as actual do_fork() routine */
+long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
+             struct pt_regs *regs, unsigned long stack_size,
+             int __user * parent_tidptr, int __user * child_tidptr)
+{
+       printk("jprobe: clone_flags=0x%lx, stack_size=0x%lx, regs=0x%p\n",
+              clone_flags, stack_size, regs);
+       /* Always end with a call to jprobe_return(). */
+       jprobe_return();
+       /*NOTREACHED*/
+       return 0;
+}
+
+static struct jprobe my_jprobe = {
+       .entry = (kprobe_opcode_t *) jdo_fork
+};
+
+int init_module(void)
+{
+       int ret;
+       my_jprobe.kp.addr = (kprobe_opcode_t *) kallsyms_lookup_name("do_fork");
+       if (!my_jprobe.kp.addr) {
+               printk("Couldn't find %s to plant jprobe\n", "do_fork");
+               return -1;
+       }
+
+       if ((ret = register_jprobe(&my_jprobe)) <0) {
+               printk("register_jprobe failed, returned %d\n", ret);
+               return -1;
+       }
+       printk("Planted jprobe at %p, handler addr %p\n",
+              my_jprobe.kp.addr, my_jprobe.entry);
+       return 0;
+}
+
+void cleanup_module(void)
+{
+       unregister_jprobe(&my_jprobe);
+       printk("jprobe unregistered\n");
+}
+
+MODULE_LICENSE("GPL");
+----- cut here -----
+
+Build and insert the kernel module as shown in the above kprobe
+example.  You will see the trace data in /var/log/messages and on
+the console whenever do_fork() is invoked to create a new process.
+(Some messages may be suppressed if syslogd is configured to
+eliminate duplicate messages.)
+
+10. Kretprobes Example
+
+Here's a sample kernel module showing the use of return probes to
+report failed calls to sys_open().
+----- cut here -----
+/*kretprobe-example.c*/
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/kprobes.h>
+#include <linux/kallsyms.h>
+
+static const char *probed_func = "sys_open";
+
+/* Return-probe handler: If the probed function fails, log the return value. */
+static int ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
+{
+       // Substitute the appropriate register name for your architecture --
+       // e.g., regs->rax for x86_64, regs->gpr[3] for ppc64.
+       int retval = (int) regs->eax;
+       if (retval < 0) {
+               printk("%s returns %d\n", probed_func, retval);
+       }
+       return 0;
+}
+
+static struct kretprobe my_kretprobe = {
+       .handler = ret_handler,
+       /* Probe up to 20 instances concurrently. */
+       .maxactive = 20
+};
+
+int init_module(void)
+{
+       int ret;
+       my_kretprobe.kp.addr =
+               (kprobe_opcode_t *) kallsyms_lookup_name(probed_func);
+       if (!my_kretprobe.kp.addr) {
+               printk("Couldn't find %s to plant return probe\n", probed_func);
+               return -1;
+       }
+       if ((ret = register_kretprobe(&my_kretprobe)) < 0) {
+               printk("register_kretprobe failed, returned %d\n", ret);
+               return -1;
+       }
+       printk("Planted return probe at %p\n", my_kretprobe.kp.addr);
+       return 0;
+}
+
+void cleanup_module(void)
+{
+       unregister_kretprobe(&my_kretprobe);
+       printk("kretprobe unregistered\n");
+       /* nmissed > 0 suggests that maxactive was set too low. */
+       printk("Missed probing %d instances of %s\n",
+               my_kretprobe.nmissed, probed_func);
+}
+
+MODULE_LICENSE("GPL");
+----- cut here -----
+
+Build and insert the kernel module as shown in the above kprobe
+example.  You will see the trace data in /var/log/messages and on the
+console whenever sys_open() returns a negative value.  (Some messages
+may be suppressed if syslogd is configured to eliminate duplicate
+messages.)
+
+For additional information on Kprobes, refer to the following URLs:
+http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe
+http://www.redhat.com/magazine/005mar05/features/kprobes/
index 0bc2ed136a3836ea48f5478252c953646b3d4ade..24d029455baadabc3acc398e3970ff8052e3ab1d 100644 (file)
@@ -1,5 +1,7 @@
 
-                   Linux Ethernet Bonding Driver HOWTO
+               Linux Ethernet Bonding Driver HOWTO
+
+               Latest update: 21 June 2005
 
 Initial release : Thomas Davis <tadavis at lbl.gov>
 Corrections, HA extensions : 2000/10/03-15 :
@@ -11,15 +13,22 @@ Corrections, HA extensions : 2000/10/03-15 :
 
 Reorganized and updated Feb 2005 by Jay Vosburgh
 
-Note :
-------
+Introduction
+============
+
+       The Linux bonding driver provides a method for aggregating
+multiple network interfaces into a single logical "bonded" interface.
+The behavior of the bonded interfaces depends upon the mode; generally
+speaking, modes provide either hot standby or load balancing services.
+Additionally, link integrity monitoring may be performed.
        
-The bonding driver originally came from Donald Becker's beowulf patches for
-kernel 2.0. It has changed quite a bit since, and the original tools from
-extreme-linux and beowulf sites will not work with this version of the driver.
+       The bonding driver originally came from Donald Becker's
+beowulf patches for kernel 2.0. It has changed quite a bit since, and
+the original tools from extreme-linux and beowulf sites will not work
+with this version of the driver.
 
-For new versions of the driver, patches for older kernels and the updated
-userspace tools, please follow the links at the end of this file.
+       For new versions of the driver, updated userspace tools, and
+who to ask for help, please follow the links at the end of this file.
 
 Table of Contents
 =================
@@ -30,9 +39,13 @@ Table of Contents
 
 3. Configuring Bonding Devices
 3.1    Configuration with sysconfig support
+3.1.1          Using DHCP with sysconfig
+3.1.2          Configuring Multiple Bonds with sysconfig
 3.2    Configuration with initscripts support
+3.2.1          Using DHCP with initscripts
+3.2.2          Configuring Multiple Bonds with initscripts
 3.3    Configuring Bonding Manually
-3.4    Configuring Multiple Bonds
+3.3.1          Configuring Multiple Bonds Manually
 
 5. Querying Bonding Configuration
 5.1    Bonding Configuration
@@ -56,21 +69,30 @@ Table of Contents
 
 11. Promiscuous mode
 
-12. High Availability Information
+12. Configuring Bonding for High Availability
 12.1   High Availability in a Single Switch Topology
-12.1.1         Bonding Mode Selection for Single Switch Topology
-12.1.2         Link Monitoring for Single Switch Topology
 12.2   High Availability in a Multiple Switch Topology
-12.2.1         Bonding Mode Selection for Multiple Switch Topology
-12.2.2         Link Monitoring for Multiple Switch Topology
-12.3   Switch Behavior Issues for High Availability
+12.2.1         HA Bonding Mode Selection for Multiple Switch Topology
+12.2.2         HA Link Monitoring for Multiple Switch Topology
+
+13. Configuring Bonding for Maximum Throughput
+13.1   Maximum Throughput in a Single Switch Topology
+13.1.1         MT Bonding Mode Selection for Single Switch Topology
+13.1.2         MT Link Monitoring for Single Switch Topology
+13.2   Maximum Throughput in a Multiple Switch Topology
+13.2.1         MT Bonding Mode Selection for Multiple Switch Topology
+13.2.2         MT Link Monitoring for Multiple Switch Topology
 
-13. Hardware Specific Considerations
-13.1   IBM BladeCenter
+14. Switch Behavior Issues
+14.1   Link Establishment and Failover Delays
+14.2   Duplicated Incoming Packets
 
-14. Frequently Asked Questions
+15. Hardware Specific Considerations
+15.1   IBM BladeCenter
 
-15. Resources and Links
+16. Frequently Asked Questions
+
+17. Resources and Links
 
 
 1. Bonding Driver Installation
@@ -86,16 +108,10 @@ the following steps:
 1.1 Configure and build the kernel with bonding
 -----------------------------------------------
 
-       The latest version of the bonding driver is available in the
+       The current version of the bonding driver is available in the
 drivers/net/bonding subdirectory of the most recent kernel source
-(which is available on http://kernel.org).
-
-       Prior to the 2.4.11 kernel, the bonding driver was maintained
-largely outside the kernel tree; patches for some earlier kernels are
-available on the bonding sourceforge site, although those patches are
-still several years out of date.  Most users will want to use either
-the most recent kernel from kernel.org or whatever kernel came with
-their distro.
+(which is available on http://kernel.org).  Most users "rolling their
+own" will want to use the most recent kernel from kernel.org.
 
        Configure kernel with "make menuconfig" (or "make xconfig" or
 "make config"), then select "Bonding driver support" in the "Network
@@ -103,8 +119,8 @@ device support" section.  It is recommended that you configure the
 driver as module since it is currently the only way to pass parameters
 to the driver or configure more than one bonding device.
 
-       Build and install the new kernel and modules, then proceed to
-step 2.
+       Build and install the new kernel and modules, then continue
+below to install ifenslave.
 
 1.2 Install ifenslave Control Utility
 -------------------------------------
@@ -147,9 +163,9 @@ default kernel source include directory.
        Options for the bonding driver are supplied as parameters to
 the bonding module at load time.  They may be given as command line
 arguments to the insmod or modprobe command, but are usually specified
-in either the /etc/modprobe.conf configuration file, or in a
-distro-specific configuration file (some of which are detailed in the
-next section).
+in either the /etc/modules.conf or /etc/modprobe.conf configuration
+file, or in a distro-specific configuration file (some of which are
+detailed in the next section).
 
        The available bonding driver parameters are listed below. If a
 parameter is not specified the default value is used.  When initially
@@ -162,34 +178,34 @@ degradation will occur during link failures.  Very few devices do not
 support at least miimon, so there is really no reason not to use it.
 
        Options with textual values will accept either the text name
-       or, for backwards compatibility, the option value.  E.g.,
-       "mode=802.3ad" and "mode=4" set the same mode.
+or, for backwards compatibility, the option value.  E.g.,
+"mode=802.3ad" and "mode=4" set the same mode.
 
        The parameters are as follows:
 
 arp_interval
 
-       Specifies the ARP monitoring frequency in milli-seconds. If
-       ARP monitoring is used in a load-balancing mode (mode 0 or 2),
-       the switch should be configured in a mode that evenly
-       distributes packets across all links - such as round-robin. If
-       the switch is configured to distribute the packets in an XOR
+       Specifies the ARP link monitoring frequency in milliseconds.
+       If ARP monitoring is used in an etherchannel compatible mode
+       (modes 0 and 2), the switch should be configured in a mode
+       that evenly distributes packets across all links. If the
+       switch is configured to distribute the packets in an XOR
        fashion, all replies from the ARP targets will be received on
        the same link which could cause the other team members to
-       fail. ARP monitoring should not be used in conjunction with
-       miimon. A value of 0 disables ARP monitoring. The default
+       fail.  ARP monitoring should not be used in conjunction with
+       miimon.  A value of 0 disables ARP monitoring.  The default
        value is 0.
 
 arp_ip_target
 
-       Specifies the ip addresses to use when arp_interval is > 0.
-       These are the targets of the ARP request sent to determine the
-       health of the link to the targets.  Specify these values in
-       ddd.ddd.ddd.ddd format.  Multiple ip adresses must be
-       seperated by a comma.  At least one IP address must be given
-       for ARP monitoring to function.  The maximum number of targets
-       that can be specified is 16.  The default value is no IP
-       addresses.
+       Specifies the IP addresses to use as ARP monitoring peers when
+       arp_interval is > 0.  These are the targets of the ARP request
+       sent to determine the health of the link to the targets.
+       Specify these values in ddd.ddd.ddd.ddd format.  Multiple IP
+       addresses must be separated by a comma.  At least one IP
+       address must be given for ARP monitoring to function.  The
+       maximum number of targets that can be specified is 16.  The
+       default value is no IP addresses.
 
 downdelay
 
@@ -207,11 +223,13 @@ lacp_rate
        are:
 
        slow or 0
-               Request partner to transmit LACPDUs every 30 seconds (default)
+               Request partner to transmit LACPDUs every 30 seconds
 
        fast or 1
                Request partner to transmit LACPDUs every 1 second
 
+       The default is slow.
+
 max_bonds
 
        Specifies the number of bonding devices to create for this
@@ -221,10 +239,11 @@ max_bonds
 
 miimon
 
-       Specifies the frequency in milli-seconds that MII link
-       monitoring will occur.  A value of zero disables MII link
-       monitoring.  A value of 100 is a good starting point.  The
-       use_carrier option, below, affects how the link state is
+       Specifies the MII link monitoring frequency in milliseconds.
+       This determines how often the link state of each slave is
+       inspected for link failures.  A value of zero disables MII
+       link monitoring.  A value of 100 is a good starting point.
+       The use_carrier option, below, affects how the link state is
        determined.  See the High Availability section for additional
        information.  The default value is 0.
 
@@ -246,17 +265,31 @@ mode
                active.  A different slave becomes active if, and only
                if, the active slave fails.  The bond's MAC address is
                externally visible on only one port (network adapter)
-               to avoid confusing the switch.  This mode provides
-               fault tolerance.  The primary option affects the
-               behavior of this mode.
+               to avoid confusing the switch.
+
+               In bonding version 2.6.2 or later, when a failover
+               occurs in active-backup mode, bonding will issue one
+               or more gratuitous ARPs on the newly active slave.
+               One gratutious ARP is issued for the bonding master
+               interface and each VLAN interfaces configured above
+               it, provided that the interface has at least one IP
+               address configured.  Gratuitous ARPs issued for VLAN
+               interfaces are tagged with the appropriate VLAN id.
+
+               This mode provides fault tolerance.  The primary
+               option, documented below, affects the behavior of this
+               mode.
 
        balance-xor or 2
 
-               XOR policy: Transmit based on [(source MAC address
-               XOR'd with destination MAC address) modulo slave
-               count].  This selects the same slave for each
-               destination MAC address.  This mode provides load
-               balancing and fault tolerance.
+               XOR policy: Transmit based on the selected transmit
+               hash policy.  The default policy is a simple [(source
+               MAC address XOR'd with destination MAC address) modulo
+               slave count].  Alternate transmit policies may be
+               selected via the xmit_hash_policy option, described
+               below.
+
+               This mode provides load balancing and fault tolerance.
 
        broadcast or 3
 
@@ -270,7 +303,17 @@ mode
                duplex settings.  Utilizes all slaves in the active
                aggregator according to the 802.3ad specification.
 
-               Pre-requisites:
+               Slave selection for outgoing traffic is done according
+               to the transmit hash policy, which may be changed from
+               the default simple XOR policy via the xmit_hash_policy
+               option, documented below.  Note that not all transmit
+               policies may be 802.3ad compliant, particularly in
+               regards to the packet mis-ordering requirements of
+               section 43.2.4 of the 802.3ad standard.  Differing
+               peer implementations will have varying tolerances for
+               noncompliance.
+
+               Prerequisites:
 
                1. Ethtool support in the base drivers for retrieving
                the speed and duplex of each slave.
@@ -333,7 +376,7 @@ mode
 
                When a link is reconnected or a new slave joins the
                bond the receive traffic is redistributed among all
-               active slaves in the bond by intiating ARP Replies
+               active slaves in the bond by initiating ARP Replies
                with the selected mac address to each of the
                clients. The updelay parameter (detailed below) must
                be set to a value equal or greater than the switch's
@@ -396,6 +439,60 @@ use_carrier
        0 will use the deprecated MII / ETHTOOL ioctls.  The default
        value is 1.
 
+xmit_hash_policy
+
+       Selects the transmit hash policy to use for slave selection in
+       balance-xor and 802.3ad modes.  Possible values are:
+
+       layer2
+
+               Uses XOR of hardware MAC addresses to generate the
+               hash.  The formula is
+
+               (source MAC XOR destination MAC) modulo slave count
+
+               This algorithm will place all traffic to a particular
+               network peer on the same slave.
+
+               This algorithm is 802.3ad compliant.
+
+       layer3+4
+
+               This policy uses upper layer protocol information,
+               when available, to generate the hash.  This allows for
+               traffic to a particular network peer to span multiple
+               slaves, although a single connection will not span
+               multiple slaves.
+
+               The formula for unfragmented TCP and UDP packets is
+
+               ((source port XOR dest port) XOR
+                        ((source IP XOR dest IP) AND 0xffff)
+                               modulo slave count
+
+               For fragmented TCP or UDP packets and all other IP
+               protocol traffic, the source and destination port
+               information is omitted.  For non-IP traffic, the
+               formula is the same as for the layer2 transmit hash
+               policy.
+
+               This policy is intended to mimic the behavior of
+               certain switches, notably Cisco switches with PFC2 as
+               well as some Foundry and IBM products.
+
+               This algorithm is not fully 802.3ad compliant.  A
+               single TCP or UDP conversation containing both
+               fragmented and unfragmented packets will see packets
+               striped across two interfaces.  This may result in out
+               of order delivery.  Most traffic types will not meet
+               this criteria, as TCP rarely fragments traffic, and
+               most UDP traffic is not involved in extended
+               conversations.  Other implementations of 802.3ad may
+               or may not tolerate this noncompliance.
+
+       The default value is layer2.  This option was added in bonding
+version 2.6.3.  In earlier versions of bonding, this parameter does
+not exist, and the layer2 policy is the only policy.
 
 
 3. Configuring Bonding Devices
@@ -448,8 +545,9 @@ Bonding devices can be managed by hand, however, as follows.
 slave devices.  On SLES 9, this is most easily done by running the
 yast2 sysconfig configuration utility.  The goal is for to create an
 ifcfg-id file for each slave device.  The simplest way to accomplish
-this is to configure the devices for DHCP.  The name of the
-configuration file for each device will be of the form:
+this is to configure the devices for DHCP (this is only to get the
+file ifcfg-id file created; see below for some issues with DHCP).  The
+name of the configuration file for each device will be of the form:
 
 ifcfg-id-xx:xx:xx:xx:xx:xx
 
@@ -459,7 +557,7 @@ the device's permanent MAC address.
        Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been
 created, it is necessary to edit the configuration files for the slave
 devices (the MAC addresses correspond to those of the slave devices).
-Before editing, the file will contain muliple lines, and will look
+Before editing, the file will contain multiple lines, and will look
 something like this:
 
 BOOTPROTO='dhcp'
@@ -496,16 +594,11 @@ STARTMODE="onboot"
 BONDING_MASTER="yes"
 BONDING_MODULE_OPTS="mode=active-backup miimon=100"
 BONDING_SLAVE0="eth0"
-BONDING_SLAVE1="eth1"
+BONDING_SLAVE1="bus-pci-0000:06:08.1"
 
        Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK
 values with the appropriate values for your network.
 
-       Note that configuring the bonding device with BOOTPROTO='dhcp'
-does not work; the scripts attempt to obtain the device address from
-DHCP prior to adding any of the slave devices.  Without active slaves,
-the DHCP requests are not sent to the network.
-
        The STARTMODE specifies when the device is brought online.
 The possible values are:
 
@@ -531,9 +624,17 @@ for the bonding mode, link monitoring, and so on here.  Do not include
 the max_bonds bonding parameter; this will confuse the configuration
 system if you have multiple bonding devices.
 
-       Finally, supply one BONDING_SLAVEn="ethX" for each slave,
-where "n" is an increasing value, one for each slave, and "ethX" is
-the name of the slave device (eth0, eth1, etc).
+       Finally, supply one BONDING_SLAVEn="slave device" for each
+slave.  where "n" is an increasing value, one for each slave.  The
+"slave device" is either an interface name, e.g., "eth0", or a device
+specifier for the network device.  The interface name is easier to
+find, but the ethN names are subject to change at boot time if, e.g.,
+a device early in the sequence has failed.  The device specifiers
+(bus-pci-0000:06:08.1 in the example above) specify the physical
+network device, and will not change unless the device's bus location
+changes (for example, it is moved from one PCI slot to another).  The
+example above uses one of each type for demonstration purposes; most
+configurations will choose one or the other for all slave devices.
 
        When all configuration files have been modified or created,
 networking must be restarted for the configuration changes to take
@@ -544,7 +645,7 @@ effect.  This can be accomplished via the following:
        Note that the network control script (/sbin/ifdown) will
 remove the bonding module as part of the network shutdown processing,
 so it is not necessary to remove the module by hand if, e.g., the
-module paramters have changed.
+module parameters have changed.
 
        Also, at this writing, YaST/YaST2 will not manage bonding
 devices (they do not show bonding interfaces on its list of network
@@ -559,12 +660,37 @@ format can be found in an example ifcfg template file:
        Note that the template does not document the various BONDING_
 settings described above, but does describe many of the other options.
 
+3.1.1 Using DHCP with sysconfig
+-------------------------------
+
+       Under sysconfig, configuring a device with BOOTPROTO='dhcp'
+will cause it to query DHCP for its IP address information.  At this
+writing, this does not function for bonding devices; the scripts
+attempt to obtain the device address from DHCP prior to adding any of
+the slave devices.  Without active slaves, the DHCP requests are not
+sent to the network.
+
+3.1.2 Configuring Multiple Bonds with sysconfig
+-----------------------------------------------
+
+       The sysconfig network initialization system is capable of
+handling multiple bonding devices.  All that is necessary is for each
+bonding instance to have an appropriately configured ifcfg-bondX file
+(as described above).  Do not specify the "max_bonds" parameter to any
+instance of bonding, as this will confuse sysconfig.  If you require
+multiple bonding devices with identical parameters, create multiple
+ifcfg-bondX files.
+
+       Because the sysconfig scripts supply the bonding module
+options in the ifcfg-bondX file, it is not necessary to add them to
+the system /etc/modules.conf or /etc/modprobe.conf configuration file.
+
 3.2 Configuration with initscripts support
 ------------------------------------------
 
        This section applies to distros using a version of initscripts
 with bonding support, for example, Red Hat Linux 9 or Red Hat
-Enterprise Linux version 3.  On these systems, the network
+Enterprise Linux version 3 or 4.  On these systems, the network
 initialization scripts have some knowledge of bonding, and can be
 configured to control bonding devices.
 
@@ -614,10 +740,11 @@ USERCTL=no
        Be sure to change the networking specific lines (IPADDR,
 NETMASK, NETWORK and BROADCAST) to match your network configuration.
 
-       Finally, it is necessary to edit /etc/modules.conf to load the
-bonding module when the bond0 interface is brought up.  The following
-sample lines in /etc/modules.conf will load the bonding module, and
-select its options:
+       Finally, it is necessary to edit /etc/modules.conf (or
+/etc/modprobe.conf, depending upon your distro) to load the bonding
+module with your desired options when the bond0 interface is brought
+up.  The following lines in /etc/modules.conf (or modprobe.conf) will
+load the bonding module, and select its options:
 
 alias bond0 bonding
 options bond0 mode=balance-alb miimon=100
@@ -629,6 +756,33 @@ options for your configuration.
 will restart the networking subsystem and your bond link should be now
 up and running.
 
+3.2.1 Using DHCP with initscripts
+---------------------------------
+
+       Recent versions of initscripts (the version supplied with
+Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do
+have support for assigning IP information to bonding devices via DHCP.
+
+       To configure bonding for DHCP, configure it as described
+above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
+and add a line consisting of "TYPE=Bonding".  Note that the TYPE value
+is case sensitive.
+
+3.2.2 Configuring Multiple Bonds with initscripts
+-------------------------------------------------
+
+       At this writing, the initscripts package does not directly
+support loading the bonding driver multiple times, so the process for
+doing so is the same as described in the "Configuring Multiple Bonds
+Manually" section, below.
+
+       NOTE: It has been observed that some Red Hat supplied kernels
+are apparently unable to rename modules at load time (the "-obonding1"
+part).  Attempts to pass that option to modprobe will produce an
+"Operation not permitted" error.  This has been reported on some
+Fedora Core kernels, and has been seen on RHEL 4 as well.  On kernels
+exhibiting this problem, it will be impossible to configure multiple
+bonds with differing parameters.
 
 3.3 Configuring Bonding Manually
 --------------------------------
@@ -638,10 +792,11 @@ scripts (the sysconfig or initscripts package) do not have specific
 knowledge of bonding.  One such distro is SuSE Linux Enterprise Server
 version 8.
 
-       The general methodology for these systems is to place the
-bonding module parameters into /etc/modprobe.conf, then add modprobe
-and/or ifenslave commands to the system's global init script.  The
-name of the global init script differs; for sysconfig, it is
+       The general method for these systems is to place the bonding
+module parameters into /etc/modules.conf or /etc/modprobe.conf (as
+appropriate for the installed distro), then add modprobe and/or
+ifenslave commands to the system's global init script.  The name of
+the global init script differs; for sysconfig, it is
 /etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
 
        For example, if you wanted to make a simple bond of two e100
@@ -649,7 +804,7 @@ devices (presumed to be eth0 and eth1), and have it persist across
 reboots, edit the appropriate file (/etc/init.d/boot.local or
 /etc/rc.d/rc.local), and add the following:
 
-modprobe bonding -obond0 mode=balance-alb miimon=100
+modprobe bonding mode=balance-alb miimon=100
 modprobe e100
 ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
 ifenslave bond0 eth0
@@ -657,11 +812,7 @@ ifenslave bond0 eth1
 
        Replace the example bonding module parameters and bond0
 network configuration (IP address, netmask, etc) with the appropriate
-values for your configuration.  The above example loads the bonding
-module with the name "bond0," this simplifies the naming if multiple
-bonding modules are loaded (each successive instance of the module is
-given a different name, and the module instance names match the
-bonding interface names).
+values for your configuration.
 
        Unfortunately, this method will not provide support for the
 ifup and ifdown scripts on the bond devices.  To reload the bonding
@@ -684,20 +835,23 @@ appropriate device driver modules.  For our example above, you can do
 the following:
 
 # ifconfig bond0 down
-# rmmod bond0
+# rmmod bonding
 # rmmod e100
 
        Again, for convenience, it may be desirable to create a script
 with these commands.
 
 
-3.4 Configuring Multiple Bonds
-------------------------------
+3.3.1 Configuring Multiple Bonds Manually
+-----------------------------------------
 
        This section contains information on configuring multiple
-bonding devices with differing options.  If you require multiple
-bonding devices, but all with the same options, see the "max_bonds"
-module paramter, documented above.
+bonding devices with differing options for those systems whose network
+initialization scripts lack support for configuring multiple bonds.
+
+       If you require multiple bonding devices, but all with the same
+options, you may wish to use the "max_bonds" module parameter,
+documented above.
 
        To create multiple bonding devices with differing options, it
 is necessary to load the bonding driver multiple times.  Note that
@@ -724,11 +878,16 @@ named "bond0" and creates the bond0 device in balance-rr mode with an
 miimon of 100.  The second instance is named "bond1" and creates the
 bond1 device in balance-alb mode with an miimon of 50.
 
+       In some circumstances (typically with older distributions),
+the above does not work, and the second bonding instance never sees
+its options.  In that case, the second options line can be substituted
+as follows:
+
+install bonding1 /sbin/modprobe bonding -obond1 mode=balance-alb miimon=50
+
        This may be repeated any number of times, specifying a new and
-unique name in place of bond0 or bond1 for each instance.
+unique name in place of bond1 for each subsequent instance.
 
-       When the appropriate module paramters are in place, then
-configure bonding according to the instructions for your distro.
 
 5. Querying Bonding Configuration 
 =================================
@@ -846,8 +1005,8 @@ tagged internally by bonding itself.  As a result, bonding must
 self generated packets.
 
        For reasons of simplicity, and to support the use of adapters
-that can do VLAN hardware acceleration offloding, the bonding
-interface declares itself as fully hardware offloaing capable, it gets
+that can do VLAN hardware acceleration offloading, the bonding
+interface declares itself as fully hardware offloading capable, it gets
 the add_vid/kill_vid notifications to gather the necessary
 information, and it propagates those actions to the slaves.  In case
 of mixed adapter types, hardware accelerated tagged packets that
@@ -880,7 +1039,7 @@ bond interface:
 matches the hardware address of the VLAN interfaces.
 
        Note that changing a VLAN interface's HW address would set the
-underlying device -- i.e. the bonding interface -- to promiscouos
+underlying device -- i.e. the bonding interface -- to promiscuous
 mode, which might not be what you want.
 
 
@@ -923,7 +1082,7 @@ down or have a problem making it unresponsive to ARP requests.  Having
 an additional target (or several) increases the reliability of the ARP
 monitoring.
 
-       Multiple ARP targets must be seperated by commas as follows:
+       Multiple ARP targets must be separated by commas as follows:
 
 # example options for ARP monitoring with three targets
 alias bond0 bonding
@@ -1045,7 +1204,7 @@ install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
        This will, when loading the bonding module, rather than
 performing the normal action, instead execute the provided command.
 This command loads the device drivers in the order needed, then calls
-modprobe with --ingore-install to cause the normal action to then take
+modprobe with --ignore-install to cause the normal action to then take
 place.  Full documentation on this can be found in the modprobe.conf
 and modprobe manual pages.
 
@@ -1130,14 +1289,14 @@ association.
 common to enable promiscuous mode on the device, so that all traffic
 is seen (instead of seeing only traffic destined for the local host).
 The bonding driver handles promiscuous mode changes to the bonding
-master device (e.g., bond0), and propogates the setting to the slave
+master device (e.g., bond0), and propagates the setting to the slave
 devices.
 
        For the balance-rr, balance-xor, broadcast, and 802.3ad modes,
-the promiscuous mode setting is propogated to all slaves.
+the promiscuous mode setting is propagated to all slaves.
 
        For the active-backup, balance-tlb and balance-alb modes, the
-promiscuous mode setting is propogated only to the active slave.
+promiscuous mode setting is propagated only to the active slave.
 
        For balance-tlb mode, the active slave is the slave currently
 receiving inbound traffic.
@@ -1148,46 +1307,182 @@ sending to peers that are unassigned or if the load is unbalanced.
 
        For the active-backup, balance-tlb and balance-alb modes, when
 the active slave changes (e.g., due to a link failure), the
-promiscuous setting will be propogated to the new active slave.
+promiscuous setting will be propagated to the new active slave.
 
-12. High Availability Information
-=================================
+12. Configuring Bonding for High Availability
+=============================================
 
        High Availability refers to configurations that provide
 maximum network availability by having redundant or backup devices,
-links and switches between the host and the rest of the world.
-
-       There are currently two basic methods for configuring to
-maximize availability. They are dependent on the network topology and
-the primary goal of the configuration, but in general, a configuration
-can be optimized for maximum available bandwidth, or for maximum
-network availability.
+links or switches between the host and the rest of the world.  The
+goal is to provide the maximum availability of network connectivity
+(i.e., the network always works), even though other configurations
+could provide higher throughput.
 
 12.1 High Availability in a Single Switch Topology
 --------------------------------------------------
 
-       If two hosts (or a host and a switch) are directly connected
-via multiple physical links, then there is no network availability
-penalty for optimizing for maximum bandwidth: there is only one switch
-(or peer), so if it fails, you have no alternative access to fail over
-to.
+       If two hosts (or a host and a single switch) are directly
+connected via multiple physical links, then there is no availability
+penalty to optimizing for maximum bandwidth.  In this case, there is
+only one switch (or peer), so if it fails, there is no alternative
+access to fail over to.  Additionally, the bonding load balance modes
+support link monitoring of their members, so if individual links fail,
+the load will be rebalanced across the remaining devices.
+
+       See Section 13, "Configuring Bonding for Maximum Throughput"
+for information on configuring bonding with one peer device.
+
+12.2 High Availability in a Multiple Switch Topology
+----------------------------------------------------
+
+       With multiple switches, the configuration of bonding and the
+network changes dramatically.  In multiple switch topologies, there is
+a trade off between network availability and usable bandwidth.
+
+       Below is a sample network, configured to maximize the
+availability of the network:
 
-Example 1 : host to switch (or other host)
+                |                                     |
+                |port3                           port3|
+          +-----+----+                          +-----+----+
+          |          |port2       ISL      port2|          |
+          | switch A +--------------------------+ switch B |
+          |          |                          |          |
+          +-----+----+                          +-----++---+
+                |port1                           port1|
+                |             +-------+               |
+                +-------------+ host1 +---------------+
+                         eth0 +-------+ eth1
 
-          +----------+                          +----------+
-          |          |eth0                  eth0|  switch  |
-          | Host A   +--------------------------+    or    |
-          |          +--------------------------+  other   |
-          |          |eth1                  eth1|  host    |
-          +----------+                          +----------+
+       In this configuration, there is a link between the two
+switches (ISL, or inter switch link), and multiple ports connecting to
+the outside world ("port3" on each switch).  There is no technical
+reason that this could not be extended to a third switch.
 
+12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+-------------------------------------------------------------
 
-12.1.1 Bonding Mode Selection for single switch topology
---------------------------------------------------------
+       In a topology such as the example above, the active-backup and
+broadcast modes are the only useful bonding modes when optimizing for
+availability; the other modes require all links to terminate on the
+same peer for them to behave rationally.
+
+active-backup: This is generally the preferred mode, particularly if
+       the switches have an ISL and play together well.  If the
+       network configuration is such that one switch is specifically
+       a backup switch (e.g., has lower capacity, higher cost, etc),
+       then the primary option can be used to insure that the
+       preferred link is always used when it is available.
+
+broadcast: This mode is really a special purpose mode, and is suitable
+       only for very specific needs.  For example, if the two
+       switches are not connected (no ISL), and the networks beyond
+       them are totally independent.  In this case, if it is
+       necessary for some specific one-way traffic to reach both
+       independent networks, then the broadcast mode may be suitable.
+
+12.2.2 HA Link Monitoring Selection for Multiple Switch Topology
+----------------------------------------------------------------
+
+       The choice of link monitoring ultimately depends upon your
+switch.  If the switch can reliably fail ports in response to other
+failures, then either the MII or ARP monitors should work.  For
+example, in the above example, if the "port3" link fails at the remote
+end, the MII monitor has no direct means to detect this.  The ARP
+monitor could be configured with a target at the remote end of port3,
+thus detecting that failure without switch support.
+
+       In general, however, in a multiple switch topology, the ARP
+monitor can provide a higher level of reliability in detecting end to
+end connectivity failures (which may be caused by the failure of any
+individual component to pass traffic for any reason).  Additionally,
+the ARP monitor should be configured with multiple targets (at least
+one for each switch in the network).  This will insure that,
+regardless of which switch is active, the ARP monitor has a suitable
+target to query.
+
+
+13. Configuring Bonding for Maximum Throughput
+==============================================
+
+13.1 Maximizing Throughput in a Single Switch Topology
+------------------------------------------------------
+
+       In a single switch configuration, the best method to maximize
+throughput depends upon the application and network environment.  The
+various load balancing modes each have strengths and weaknesses in
+different environments, as detailed below.
+
+       For this discussion, we will break down the topologies into
+two categories.  Depending upon the destination of most traffic, we
+categorize them into either "gatewayed" or "local" configurations.
+
+       In a gatewayed configuration, the "switch" is acting primarily
+as a router, and the majority of traffic passes through this router to
+other networks.  An example would be the following:
+
+
+     +----------+                     +----------+
+     |          |eth0            port1|          | to other networks
+     | Host A   +---------------------+ router   +------------------->
+     |          +---------------------+          | Hosts B and C are out
+     |          |eth1            port2|          | here somewhere
+     +----------+                     +----------+
+
+       The router may be a dedicated router device, or another host
+acting as a gateway.  For our discussion, the important point is that
+the majority of traffic from Host A will pass through the router to
+some other network before reaching its final destination.
+
+       In a gatewayed network configuration, although Host A may
+communicate with many other systems, all of its traffic will be sent
+and received via one other peer on the local network, the router.
+
+       Note that the case of two systems connected directly via
+multiple physical links is, for purposes of configuring bonding, the
+same as a gatewayed configuration.  In that case, it happens that all
+traffic is destined for the "gateway" itself, not some other network
+beyond the gateway.
+
+       In a local configuration, the "switch" is acting primarily as
+a switch, and the majority of traffic passes through this switch to
+reach other stations on the same network.  An example would be the
+following:
+
+    +----------+            +----------+       +--------+
+    |          |eth0   port1|          +-------+ Host B |
+    |  Host A  +------------+  switch  |port3  +--------+
+    |          +------------+          |                  +--------+
+    |          |eth1   port2|          +------------------+ Host C |
+    +----------+            +----------+port4             +--------+
+
+
+       Again, the switch may be a dedicated switch device, or another
+host acting as a gateway.  For our discussion, the important point is
+that the majority of traffic from Host A is destined for other hosts
+on the same local network (Hosts B and C in the above example).
+
+       In summary, in a gatewayed configuration, traffic to and from
+the bonded device will be to the same MAC level peer on the network
+(the gateway itself, i.e., the router), regardless of its final
+destination.  In a local configuration, traffic flows directly to and
+from the final destinations, thus, each destination (Host B, Host C)
+will be addressed directly by their individual MAC addresses.
+
+       This distinction between a gatewayed and a local network
+configuration is important because many of the load balancing modes
+available use the MAC addresses of the local network source and
+destination to make load balancing decisions.  The behavior of each
+mode is described below.
+
+
+13.1.1 MT Bonding Mode Selection for Single Switch Topology
+-----------------------------------------------------------
 
        This configuration is the easiest to set up and to understand,
 although you will have to decide which bonding mode best suits your
-needs.  The tradeoffs for each mode are detailed below:
+needs.  The trade offs for each mode are detailed below:
 
 balance-rr: This mode is the only mode that will permit a single
        TCP/IP connection to stripe traffic across multiple
@@ -1206,6 +1501,23 @@ balance-rr: This mode is the only mode that will permit a single
        interface's worth of throughput, even after adjusting
        tcp_reordering.
 
+       Note that this out of order delivery occurs when both the
+       sending and receiving systems are utilizing a multiple
+       interface bond.  Consider a configuration in which a
+       balance-rr bond feeds into a single higher capacity network
+       channel (e.g., multiple 100Mb/sec ethernets feeding a single
+       gigabit ethernet via an etherchannel capable switch).  In this
+       configuration, traffic sent from the multiple 100Mb devices to
+       a destination connected to the gigabit device will not see
+       packets out of order.  However, traffic sent from the gigabit
+       device to the multiple 100Mb devices may or may not see
+       traffic out of order, depending upon the balance policy of the
+       switch.  Many switches do not support any modes that stripe
+       traffic (instead choosing a port based upon IP or MAC level
+       addresses); for those devices, traffic flowing from the
+       gigabit device to the many 100Mb devices will only utilize one
+       interface.
+
        If you are utilizing protocols other than TCP/IP, UDP for
        example, and your application can tolerate out of order
        delivery, then this mode can allow for single stream datagram
@@ -1220,16 +1532,21 @@ active-backup: There is not much advantage in this network topology to
        connected to the same peer as the primary.  In this case, a
        load balancing mode (with link monitoring) will provide the
        same level of network availability, but with increased
-       available bandwidth.  On the plus side, it does not require
-       any configuration of the switch.
+       available bandwidth.  On the plus side, active-backup mode
+       does not require any configuration of the switch, so it may
+       have value if the hardware available does not support any of
+       the load balance modes.
 
 balance-xor: This mode will limit traffic such that packets destined
        for specific peers will always be sent over the same
        interface.  Since the destination is determined by the MAC
-       addresses involved, this may be desirable if you have a large
-       network with many hosts.  It is likely to be suboptimal if all
-       your traffic is passed through a single router, however.  As
-       with balance-rr, the switch ports need to be configured for
+       addresses involved, this mode works best in a "local" network
+       configuration (as described above), with destinations all on
+       the same local network.  This mode is likely to be suboptimal
+       if all your traffic is passed through a single router (i.e., a
+       "gatewayed" network configuration, as described above).
+
+       As with balance-rr, the switch ports need to be configured for
        "etherchannel" or "trunking."
 
 broadcast: Like active-backup, there is not much advantage to this
@@ -1241,122 +1558,131 @@ broadcast: Like active-backup, there is not much advantage to this
        protocol includes automatic configuration of the aggregates,
        so minimal manual configuration of the switch is needed
        (typically only to designate that some set of devices is
-       usable for 802.3ad).  The 802.3ad standard also mandates that
-       frames be delivered in order (within certain limits), so in
-       general single connections will not see misordering of
+       available for 802.3ad).  The 802.3ad standard also mandates
+       that frames be delivered in order (within certain limits), so
+       in general single connections will not see misordering of
        packets.  The 802.3ad mode does have some drawbacks: the
        standard mandates that all devices in the aggregate operate at
        the same speed and duplex.  Also, as with all bonding load
        balance modes other than balance-rr, no single connection will
        be able to utilize more than a single interface's worth of
-       bandwidth.  Additionally, the linux bonding 802.3ad
-       implementation distributes traffic by peer (using an XOR of
-       MAC addresses), so in general all traffic to a particular
-       destination will use the same interface.  Finally, the 802.3ad
-       mode mandates the use of the MII monitor, therefore, the ARP
-       monitor is not available in this mode.
-
-balance-tlb: This mode is also a good choice for this type of
-       topology.  It has no special switch configuration
-       requirements, and balances outgoing traffic by peer, in a
-       vaguely intelligent manner (not a simple XOR as in balance-xor
-       or 802.3ad mode), so that unlucky MAC addresses will not all
-       "bunch up" on a single interface.  Interfaces may be of
-       differing speeds.  On the down side, in this mode all incoming
-       traffic arrives over a single interface, this mode requires
-       certain ethtool support in the network device driver of the
-       slave interfaces, and the ARP monitor is not available.
-
-balance-alb: This mode is everything that balance-tlb is, and more. It
-       has all of the features (and restrictions) of balance-tlb, and
-       will also balance incoming traffic from peers (as described in
-       the Bonding Module Options section, above).  The only extra
-       down side to this mode is that the network device driver must
-       support changing the hardware address while the device is
-       open.
-
-12.1.2 Link Monitoring for Single Switch Topology
--------------------------------------------------
+       bandwidth.  
+
+       Additionally, the linux bonding 802.3ad implementation
+       distributes traffic by peer (using an XOR of MAC addresses),
+       so in a "gatewayed" configuration, all outgoing traffic will
+       generally use the same device.  Incoming traffic may also end
+       up on a single device, but that is dependent upon the
+       balancing policy of the peer's 8023.ad implementation.  In a
+       "local" configuration, traffic will be distributed across the
+       devices in the bond.
+
+       Finally, the 802.3ad mode mandates the use of the MII monitor,
+       therefore, the ARP monitor is not available in this mode.
+
+balance-tlb: The balance-tlb mode balances outgoing traffic by peer.
+       Since the balancing is done according to MAC address, in a
+       "gatewayed" configuration (as described above), this mode will
+       send all traffic across a single device.  However, in a
+       "local" network configuration, this mode balances multiple
+       local network peers across devices in a vaguely intelligent
+       manner (not a simple XOR as in balance-xor or 802.3ad mode),
+       so that mathematically unlucky MAC addresses (i.e., ones that
+       XOR to the same value) will not all "bunch up" on a single
+       interface.
+
+       Unlike 802.3ad, interfaces may be of differing speeds, and no
+       special switch configuration is required.  On the down side,
+       in this mode all incoming traffic arrives over a single
+       interface, this mode requires certain ethtool support in the
+       network device driver of the slave interfaces, and the ARP
+       monitor is not available.
+
+balance-alb: This mode is everything that balance-tlb is, and more.
+       It has all of the features (and restrictions) of balance-tlb,
+       and will also balance incoming traffic from local network
+       peers (as described in the Bonding Module Options section,
+       above).
+
+       The only additional down side to this mode is that the network
+       device driver must support changing the hardware address while
+       the device is open.
+
+13.1.2 MT Link Monitoring for Single Switch Topology
+----------------------------------------------------
 
        The choice of link monitoring may largely depend upon which
 mode you choose to use.  The more advanced load balancing modes do not
 support the use of the ARP monitor, and are thus restricted to using
-the MII monitor (which does not provide as high a level of assurance
-as the ARP monitor).
-
-
-12.2 High Availability in a Multiple Switch Topology
-----------------------------------------------------
-
-       With multiple switches, the configuration of bonding and the
-network changes dramatically.  In multiple switch topologies, there is
-a tradeoff between network availability and usable bandwidth.
-
-       Below is a sample network, configured to maximize the
-availability of the network:
-
-                |                                     |
-                |port3                           port3|
-          +-----+----+                          +-----+----+
-          |          |port2       ISL      port2|          |
-          | switch A +--------------------------+ switch B |
-          |          |                          |          |
-          +-----+----+                          +-----++---+
-                |port1                           port1|
-                |             +-------+               |
-                +-------------+ host1 +---------------+
-                         eth0 +-------+ eth1
-
-       In this configuration, there is a link between the two
-switches (ISL, or inter switch link), and multiple ports connecting to
-the outside world ("port3" on each switch).  There is no technical
-reason that this could not be extended to a third switch.
-
-12.2.1 Bonding Mode Selection for Multiple Switch Topology
-----------------------------------------------------------
-
-       In a topology such as this, the active-backup and broadcast
-modes are the only useful bonding modes; the other modes require all
-links to terminate on the same peer for them to behave rationally.
-
-active-backup: This is generally the preferred mode, particularly if
-       the switches have an ISL and play together well.  If the
-       network configuration is such that one switch is specifically
-       a backup switch (e.g., has lower capacity, higher cost, etc),
-       then the primary option can be used to insure that the
-       preferred link is always used when it is available.
-
-broadcast: This mode is really a special purpose mode, and is suitable
-       only for very specific needs.  For example, if the two
-       switches are not connected (no ISL), and the networks beyond
-       them are totally independant.  In this case, if it is
-       necessary for some specific one-way traffic to reach both
-       independent networks, then the broadcast mode may be suitable.
-
-12.2.2 Link Monitoring Selection for Multiple Switch Topology
+the MII monitor (which does not provide as high a level of end to end
+assurance as the ARP monitor).
+
+13.2 Maximum Throughput in a Multiple Switch Topology
+-----------------------------------------------------
+
+       Multiple switches may be utilized to optimize for throughput
+when they are configured in parallel as part of an isolated network
+between two or more systems, for example:
+
+                       +-----------+
+                       |  Host A   | 
+                       +-+---+---+-+
+                         |   |   |
+                +--------+   |   +---------+
+                |            |             |
+         +------+---+  +-----+----+  +-----+----+
+         | Switch A |  | Switch B |  | Switch C |
+         +------+---+  +-----+----+  +-----+----+
+                |            |             |
+                +--------+   |   +---------+
+                         |   |   |
+                       +-+---+---+-+
+                       |  Host B   | 
+                       +-----------+
+
+       In this configuration, the switches are isolated from one
+another.  One reason to employ a topology such as this is for an
+isolated network with many hosts (a cluster configured for high
+performance, for example), using multiple smaller switches can be more
+cost effective than a single larger switch, e.g., on a network with 24
+hosts, three 24 port switches can be significantly less expensive than
+a single 72 port switch.
+
+       If access beyond the network is required, an individual host
+can be equipped with an additional network device connected to an
+external network; this host then additionally acts as a gateway.
+
+13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
 -------------------------------------------------------------
 
-       The choice of link monitoring ultimately depends upon your
-switch.  If the switch can reliably fail ports in response to other
-failures, then either the MII or ARP monitors should work.  For
-example, in the above example, if the "port3" link fails at the remote
-end, the MII monitor has no direct means to detect this.  The ARP
-monitor could be configured with a target at the remote end of port3,
-thus detecting that failure without switch support.
+       In actual practice, the bonding mode typically employed in
+configurations of this type is balance-rr.  Historically, in this
+network configuration, the usual caveats about out of order packet
+delivery are mitigated by the use of network adapters that do not do
+any kind of packet coalescing (via the use of NAPI, or because the
+device itself does not generate interrupts until some number of
+packets has arrived).  When employed in this fashion, the balance-rr
+mode allows individual connections between two hosts to effectively
+utilize greater than one interface's bandwidth.
 
-       In general, however, in a multiple switch topology, the ARP
-monitor can provide a higher level of reliability in detecting link
-failures.  Additionally, it should be configured with multiple targets
-(at least one for each switch in the network).  This will insure that,
-regardless of which switch is active, the ARP monitor has a suitable
-target to query.
+13.2.2 MT Link Monitoring for Multiple Switch Topology
+------------------------------------------------------
 
+       Again, in actual practice, the MII monitor is most often used
+in this configuration, as performance is given preference over
+availability.  The ARP monitor will function in this topology, but its
+advantages over the MII monitor are mitigated by the volume of probes
+needed as the number of systems involved grows (remember that each
+host in the network is configured with bonding).
 
-12.3 Switch Behavior Issues for High Availability
--------------------------------------------------
+14. Switch Behavior Issues
+==========================
 
-       You may encounter issues with the timing of link up and down
-reporting by the switch.
+14.1 Link Establishment and Failover Delays
+-------------------------------------------
+
+       Some switches exhibit undesirable behavior with regard to the
+timing of link up and down reporting by the switch.
 
        First, when a link comes up, some switches may indicate that
 the link is up (carrier available), but not pass traffic over the
@@ -1370,30 +1696,70 @@ relevant interface(s).
        Second, some switches may "bounce" the link state one or more
 times while a link is changing state.  This occurs most commonly while
 the switch is initializing.  Again, an appropriate updelay value may
-help, but note that if all links are down, then updelay is ignored
-when any link becomes active (the slave closest to completing its
-updelay is chosen).
+help.
 
        Note that when a bonding interface has no active links, the
-driver will immediately reuse the first link that goes up, even if
-updelay parameter was specified.  If there are slave interfaces
-waiting for the updelay timeout to expire, the interface that first
-went into that state will be immediately reused.  This reduces down
-time of the network if the value of updelay has been overestimated.
+driver will immediately reuse the first link that goes up, even if the
+updelay parameter has been specified (the updelay is ignored in this
+case).  If there are slave interfaces waiting for the updelay timeout
+to expire, the interface that first went into that state will be
+immediately reused.  This reduces down time of the network if the
+value of updelay has been overestimated, and since this occurs only in
+cases with no connectivity, there is no additional penalty for
+ignoring the updelay.
 
        In addition to the concerns about switch timings, if your
 switches take a long time to go into backup mode, it may be desirable
 to not activate a backup interface immediately after a link goes down.
 Failover may be delayed via the downdelay bonding module option.
 
-13. Hardware Specific Considerations
+14.2 Duplicated Incoming Packets
+--------------------------------
+
+       It is not uncommon to observe a short burst of duplicated
+traffic when the bonding device is first used, or after it has been
+idle for some period of time.  This is most easily observed by issuing
+a "ping" to some other host on the network, and noticing that the
+output from ping flags duplicates (typically one per slave).
+
+       For example, on a bond in active-backup mode with five slaves
+all connected to one switch, the output may appear as follows:
+
+# ping -n 10.0.4.2
+PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
+64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
+64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
+64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
+64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
+64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
+64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms
+64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms
+64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms
+
+       This is not due to an error in the bonding driver, rather, it
+is a side effect of how many switches update their MAC forwarding
+tables.  Initially, the switch does not associate the MAC address in
+the packet with a particular switch port, and so it may send the
+traffic to all ports until its MAC forwarding table is updated.  Since
+the interfaces attached to the bond may occupy multiple ports on a
+single switch, when the switch (temporarily) floods the traffic to all
+ports, the bond device receives multiple copies of the same packet
+(one per slave device).
+
+       The duplicated packet behavior is switch dependent, some
+switches exhibit this, and some do not.  On switches that display this
+behavior, it can be induced by clearing the MAC forwarding table (on
+most Cisco switches, the privileged command "clear mac address-table
+dynamic" will accomplish this).
+
+15. Hardware Specific Considerations
 ====================================
 
        This section contains additional information for configuring
 bonding on specific hardware platforms, or for interfacing bonding
 with particular switches or other devices.
 
-13.1 IBM BladeCenter
+15.1 IBM BladeCenter
 --------------------
 
        This applies to the JS20 and similar systems.
@@ -1407,12 +1773,12 @@ JS20 network adapter information
 --------------------------------
 
        All JS20s come with two Broadcom Gigabit Ethernet ports
-integrated on the planar.  In the BladeCenter chassis, the eth0 port
-of all JS20 blades is hard wired to I/O Module #1; similarly, all eth1
-ports are wired to I/O Module #2.  An add-on Broadcom daughter card
-can be installed on a JS20 to provide two more Gigabit Ethernet ports.
-These ports, eth2 and eth3, are wired to I/O Modules 3 and 4,
-respectively.
+integrated on the planar (that's "motherboard" in IBM-speak).  In the
+BladeCenter chassis, the eth0 port of all JS20 blades is hard wired to
+I/O Module #1; similarly, all eth1 ports are wired to I/O Module #2.
+An add-on Broadcom daughter card can be installed on a JS20 to provide
+two more Gigabit Ethernet ports.  These ports, eth2 and eth3, are
+wired to I/O Modules 3 and 4, respectively.
 
        Each I/O Module may contain either a switch or a passthrough
 module (which allows ports to be directly connected to an external
@@ -1432,29 +1798,30 @@ BladeCenter networking configuration
 of ways, this discussion will be confined to describing basic
 configurations.
 
-       Normally, Ethernet Switch Modules (ESM) are used in I/O
+       Normally, Ethernet Switch Modules (ESMs) are used in I/O
 modules 1 and 2.  In this configuration, the eth0 and eth1 ports of a
 JS20 will be connected to different internal switches (in the
 respective I/O modules).
 
-       An optical passthru module (OPM) connects the I/O module
-directly to an external switch.  By using OPMs in I/O module #1 and
-#2, the eth0 and eth1 interfaces of a JS20 can be redirected to the
-outside world and connected to a common external switch.
-
-       Depending upon the mix of ESM and OPM modules, the network
-will appear to bonding as either a single switch topology (all OPM
-modules) or as a multiple switch topology (one or more ESM modules,
-zero or more OPM modules).  It is also possible to connect ESM modules
-together, resulting in a configuration much like the example in "High
-Availability in a multiple switch topology."
-
-Requirements for specifc modes
-------------------------------
-
-       The balance-rr mode requires the use of OPM modules for
-devices in the bond, all connected to an common external switch.  That
-switch must be configured for "etherchannel" or "trunking" on the
+       A passthrough module (OPM or CPM, optical or copper,
+passthrough module) connects the I/O module directly to an external
+switch.  By using PMs in I/O module #1 and #2, the eth0 and eth1
+interfaces of a JS20 can be redirected to the outside world and
+connected to a common external switch.
+
+       Depending upon the mix of ESMs and PMs, the network will
+appear to bonding as either a single switch topology (all PMs) or as a
+multiple switch topology (one or more ESMs, zero or more PMs).  It is
+also possible to connect ESMs together, resulting in a configuration
+much like the example in "High Availability in a Multiple Switch
+Topology," above.
+
+Requirements for specific modes
+-------------------------------
+
+       The balance-rr mode requires the use of passthrough modules
+for devices in the bond, all connected to an common external switch.
+That switch must be configured for "etherchannel" or "trunking" on the
 appropriate ports, as is usual for balance-rr.
 
        The balance-alb and balance-tlb modes will function with
@@ -1484,17 +1851,18 @@ connected to the JS20 system.
 Other concerns
 --------------
 
-       The Serial Over LAN link is established over the primary
+       The Serial Over LAN (SoL) link is established over the primary
 ethernet (eth0) only, therefore, any loss of link to eth0 will result
 in losing your SoL connection.  It will not fail over with other
-network traffic.
+network traffic, as the SoL system is beyond the control of the
+bonding driver.
 
        It may be desirable to disable spanning tree on the switch
 (either the internal Ethernet Switch Module, or an external switch) to
-avoid fail-over delays issues when using bonding.
+avoid fail-over delay issues when using bonding.
 
        
-14. Frequently Asked Questions
+16. Frequently Asked Questions
 ==============================
 
 1.  Is it SMP safe?
@@ -1505,8 +1873,8 @@ The new driver was designed to be SMP safe from the start.
 2.  What type of cards will work with it?
 
        Any Ethernet type cards (you can even mix cards - a Intel
-EtherExpress PRO/100 and a 3com 3c905b, for example).  They need not
-be of the same speed.
+EtherExpress PRO/100 and a 3com 3c905b, for example).  For most modes,
+devices need not be of the same speed.
 
 3.  How many bonding devices can I have?
 
@@ -1524,11 +1892,12 @@ system.
 disabled.  The active-backup mode will fail over to a backup link, and
 other modes will ignore the failed link.  The link will continue to be
 monitored, and should it recover, it will rejoin the bond (in whatever
-manner is appropriate for the mode). See the section on High
-Availability for additional information.
+manner is appropriate for the mode). See the sections on High
+Availability and the documentation for each mode for additional
+information.
        
        Link monitoring can be enabled via either the miimon or
-arp_interval paramters (described in the module paramters section,
+arp_interval parameters (described in the module parameters section,
 above).  In general, miimon monitors the carrier state as sensed by
 the underlying network device, and the arp monitor (arp_interval)
 monitors connectivity to another host on the local network.
@@ -1536,7 +1905,7 @@ monitors connectivity to another host on the local network.
        If no link monitoring is configured, the bonding driver will
 be unable to detect link failures, and will assume that all links are
 always available.  This will likely result in lost packets, and a
-resulting degredation of performance.  The precise performance loss
+resulting degradation of performance.  The precise performance loss
 depends upon the bonding mode and network configuration.
 
 6.  Can bonding be used for High Availability?
@@ -1550,12 +1919,12 @@ depends upon the bonding mode and network configuration.
        In the basic balance modes (balance-rr and balance-xor), it
 works with any system that supports etherchannel (also called
 trunking).  Most managed switches currently available have such
-support, and many unmananged switches as well.
+support, and many unmanaged switches as well.
 
        The advanced balance modes (balance-tlb and balance-alb) do
 not have special switch requirements, but do need device drivers that
 support specific features (described in the appropriate section under
-module paramters, above).
+module parameters, above).
 
        In 802.3ad mode, it works with with systems that support IEEE
 802.3ad Dynamic Link Aggregation.  Most managed and many unmanaged
@@ -1565,17 +1934,19 @@ switches currently available support 802.3ad.
 
 8.  Where does a bonding device get its MAC address from?
 
-       If not explicitly configured with ifconfig, the MAC address of
-the bonding device is taken from its first slave device. This MAC
-address is then passed to all following slaves and remains persistent
-(even if the the first slave is removed) until the bonding device is
-brought down or reconfigured.
+       If not explicitly configured (with ifconfig or ip link), the
+MAC address of the bonding device is taken from its first slave
+device.  This MAC address is then passed to all following slaves and
+remains persistent (even if the the first slave is removed) until the
+bonding device is brought down or reconfigured.
 
        If you wish to change the MAC address, you can set it with
-ifconfig:
+ifconfig or ip link:
 
 # ifconfig bond0 hw ether 00:11:22:33:44:55
 
+# ip link set bond0 address 66:77:88:99:aa:bb
+
        The MAC address can be also changed by bringing down/up the
 device and then changing its slaves (or their order):
 
@@ -1591,23 +1962,28 @@ from the bond (`ifenslave -d bond0 eth0'). The bonding driver will
 then restore the MAC addresses that the slaves had before they were
 enslaved.
 
-15. Resources and Links
+16. Resources and Links
 =======================
 
 The latest version of the bonding driver can be found in the latest
 version of the linux kernel, found on http://kernel.org
 
+The latest version of this document can be found in either the latest
+kernel source (named Documentation/networking/bonding.txt), or on the
+bonding sourceforge site:
+
+http://www.sourceforge.net/projects/bonding
+
 Discussions regarding the bonding driver take place primarily on the
 bonding-devel mailing list, hosted at sourceforge.net.  If you have
-questions or problems, post them to the list.
+questions or problems, post them to the list.  The list address is:
 
 bonding-devel@lists.sourceforge.net
 
-https://lists.sourceforge.net/lists/listinfo/bonding-devel
-
-There is also a project site on sourceforge.
+       The administrative interface (to subscribe or unsubscribe) can
+be found at:
 
-http://www.sourceforge.net/projects/bonding
+https://lists.sourceforge.net/lists/listinfo/bonding-devel
 
 Donald Becker's Ethernet Drivers and diag programs may be found at :
  - http://www.scyld.com/network/
index 62b1dc5d97e2e90523e8010b93054f81ef3ffe58..76d28d033657aac4158b8db93821553f332d6b11 100644 (file)
@@ -266,20 +266,6 @@ port an old driver to the new PCI interface.  They are no longer present
 in the kernel as they aren't compatible with hotplug or PCI domains or
 having sane locking.
 
-pcibios_present() and          Since ages, you don't need to test presence
-pci_present()                  of PCI subsystem when trying to talk to it.
-                               If it's not there, the list of PCI devices
-                               is empty and all functions for searching for
-                               devices just return NULL.
-pcibios_(read|write)_*         Superseded by their pci_(read|write)_*
-                               counterparts.
-pcibios_find_*                 Superseded by their pci_get_* counterparts.
-pci_for_each_dev()             Superseded by pci_get_device()
-pci_for_each_dev_reverse()     Superseded by pci_find_device_reverse()
-pci_for_each_bus()             Superseded by pci_find_next_bus()
 pci_find_device()              Superseded by pci_get_device()
 pci_find_subsys()              Superseded by pci_get_subsys()
 pci_find_slot()                        Superseded by pci_get_slot()
-pcibios_find_class()           Superseded by pci_get_class()
-pci_find_class()               Superseded by pci_get_class()
-pci_(read|write)_*_nodev()     Superseded by pci_bus_(read|write)_*()
index f1896ee3bb2abf97f9b09f811a16db6fe9f3d1d2..63cb7edd177ef87e304fb7500596ffaa72c42633 100644 (file)
@@ -102,7 +102,7 @@ Here is the list of words, from left to right:
 - URB Status. This field makes no sense for submissions, but is present
   to help scripts with parsing. In error case, it contains the error code.
   In case of a setup packet, it contains a Setup Tag. If scripts read a number
-  in this field, the proceed to read Data Length. Otherwise, they read
+  in this field, they proceed to read Data Length. Otherwise, they read
   the setup packet before reading the Data Length.
 - Setup packet, if present, consists of 5 words: one of each for bmRequestType,
   bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
index 6d44958289de94186ca1418edf8ae27b01dd6d46..03deb0726aa4476b2c141eb8e16bfb49b9c47704 100644 (file)
@@ -29,3 +29,4 @@ card=27 - PixelView PlayTV Ultra Pro (Stereo)
 card=28 - DViCO FusionHDTV 3 Gold-T
 card=29 - ADS Tech Instant TV DVB-T PCI
 card=30 - TerraTec Cinergy 1400 DVB-T
+card=31 - DViCO FusionHDTV 5 Gold
index d1b9d21ffd89a7b9199845bfce45ed4fdd5586dd..f3302e1b1b9c4a31836612917336af57094befcd 100644 (file)
@@ -62,3 +62,5 @@ tuner=60 - Thomson DDT 7611 (ATSC/NTSC)
 tuner=61 - Tena TNF9533-D/IF/TNF9533-B/DF
 tuner=62 - Philips TEA5767HN FM Radio
 tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
+tuner=64 - LG TDVS-H062F/TUA6034
+tuner=65 - Ymec TVF66T5-B/DFF
index 7bb5a50b07796f365007d86702e0bc0a56e7368b..fc94ff235ffac51f1f0079bbe673f47c3a460632 100644 (file)
@@ -44,6 +44,9 @@ bttv.o
                                push used by bttv.  bttv will disable overlay
                                by default on this hardware to avoid crashes.
                                With this insmod option you can override this.
+               no_overlay=1    Disable overlay. It should be used by broken
+                               hardware that doesn't support PCI2PCI direct
+                               transfers.
                automute=0/1    Automatically mutes the sound if there is
                                no TV signal, on by default.  You might try
                                to disable this if you have bad input signal
index 476c0c22fbb7e43788b543380c0aaf82f9c7dba3..678e8f192db2917c741ca0b88ddc97f761a4a8d7 100644 (file)
@@ -6,6 +6,11 @@ only the AMD64 specific ones are listed here.
 Machine check
 
    mce=off disable machine check
+   mce=bootlog Enable logging of machine checks left over from booting.
+               Disabled by default because some BIOS leave bogus ones.
+               If your BIOS doesn't do that it's a good idea to enable though
+               to make sure you log even machine check events that result
+               in a reboot.
 
    nomce (for compatibility with i386): same as mce=off
 
index 562441d67b82656284ba612e5493311db89a36b5..fb0da63621cd0f087bad4ed4cdf27f775291204f 100644 (file)
@@ -784,7 +784,7 @@ DVB SUBSYSTEM AND DRIVERS
 P:     LinuxTV.org Project
 M:     linux-dvb-maintainer@linuxtv.org
 L:     linux-dvb@linuxtv.org (subscription required)
-W:     http://linuxtv.org/developer/dvb.xml
+W:     http://linuxtv.org/
 S:     Supported
 
 EATA-DMA SCSI DRIVER
@@ -1528,6 +1528,12 @@ P:       Zach Brown
 M:     zab@zabbo.net
 S:     Odd Fixes
 
+MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
+P: Michael Kerrisk
+M: mtk-manpages@gmx.net
+W: ftp://ftp.kernel.org/pub/linux/docs/manpages
+S: Maintained
+
 MARVELL MV64340 ETHERNET DRIVER
 P:     Manish Lachwani
 M:     Manish_Lachwani@pmc-sierra.com
@@ -1659,7 +1665,7 @@ M:        kuznet@ms2.inr.ac.ru
 P:     Pekka Savola (ipv6)
 M:     pekkas@netcore.fi
 P:     James Morris
-M:     jmorris@redhat.com
+M:     jmorris@namei.org
 P:     Hideaki YOSHIFUJI
 M:     yoshfuji@linux-ipv6.org
 P:     Patrick McHardy
@@ -1740,7 +1746,7 @@ S:        Maintained
 
 OPL3-SA2, SA3, and SAx DRIVER
 P:     Zwane Mwaikambo
-M:     zwane@commfireservices.com
+M:     zwane@arm.linux.org.uk
 L:     linux-sound@vger.kernel.org
 S:     Maintained
 
@@ -1826,6 +1832,12 @@ P:       Greg Kroah-Hartman
 M:     greg@kroah.com
 S:     Maintained
 
+PCIE HOTPLUG DRIVER
+P:     Kristen Carlson Accardi
+M:     kristen.c.accardi@intel.com
+L:     pcihpd-discuss@lists.sourceforge.net
+S:     Maintained
+
 PCMCIA SUBSYSTEM
 P:     Linux PCMCIA Team
 L:     http://lists.infradead.org/mailman/listinfo/linux-pcmcia
@@ -1990,7 +2002,7 @@ S:        Maintained
 
 SC1200 WDT DRIVER
 P:     Zwane Mwaikambo
-M:     zwane@commfireservices.com
+M:     zwane@arm.linux.org.uk
 S:     Maintained
 
 SCHEDULER
@@ -2048,7 +2060,7 @@ SELINUX SECURITY MODULE
 P:     Stephen Smalley
 M:     sds@epoch.ncsc.mil
 P:     James Morris
-M:     jmorris@redhat.com
+M:     jmorris@namei.org
 L:     linux-kernel@vger.kernel.org (kernel issues)
 L:     selinux@tycho.nsa.gov (general discussion)
 W:     http://www.nsa.gov/selinux
@@ -2202,6 +2214,12 @@ W:       http://projects.buici.com/arm
 L:     linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
 S:     Maintained
 
+SHPC HOTPLUG DRIVER
+P:     Kristen Carlson Accardi
+M:     kristen.c.accardi@intel.com
+L:     pcihpd-discuss@lists.sourceforge.net
+S:     Maintained
+
 SPARC (sparc32):
 P:     William L. Irwin
 M:     wli@holomorphy.com
index 717b9b9192d5f535da43fbc658fed341cbde4c6c..300f61f6f6a25f52d44c5bee024f8cf57e8f3d66 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 13
-EXTRAVERSION =-rc4
+EXTRAVERSION =-rc7
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
index 2045eaea2d9e13d199d53d795260e5650baf1e7e..224c34741d32d139aec5d5ff110cfd5398565f58 100644 (file)
@@ -41,18 +41,19 @@ summary from [1.]>" for easy identification by the developers
 [2.] Full description of the problem/report:
 [3.] Keywords (i.e., modules, networking, kernel):
 [4.] Kernel version (from /proc/version):
-[5.] Output of Oops.. message (if applicable) with symbolic information 
+[5.] Most recent kernel version which did not have the bug:
+[6.] Output of Oops.. message (if applicable) with symbolic information
      resolved (see Documentation/oops-tracing.txt)
-[6.] A small shell script or example program which triggers the
+[7.] A small shell script or example program which triggers the
      problem (if possible)
-[7.] Environment
-[7.1.] Software (add the output of the ver_linux script here)
-[7.2.] Processor information (from /proc/cpuinfo):
-[7.3.] Module information (from /proc/modules):
-[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-[7.5.] PCI information ('lspci -vvv' as root)
-[7.6.] SCSI information (from /proc/scsi/scsi)
-[7.7.] Other information that might be relevant to the problem
+[8.] Environment
+[8.1.] Software (add the output of the ver_linux script here)
+[8.2.] Processor information (from /proc/cpuinfo):
+[8.3.] Module information (from /proc/modules):
+[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
+[8.5.] PCI information ('lspci -vvv' as root)
+[8.6.] SCSI information (from /proc/scsi/scsi)
+[8.7.] Other information that might be relevant to the problem
        (please look in /proc and include all information that you
        think to be relevant):
 [X.] Other notes, patches, fixes, workarounds:
index 083c5df42d35bea201f08e6875fe038b1596d44c..189d5eababa8d15708e15e354e0eb372d5e7fad1 100644 (file)
@@ -522,7 +522,7 @@ source "mm/Kconfig"
 
 config NUMA
        bool "NUMA Support (EXPERIMENTAL)"
-       depends on DISCONTIGMEM
+       depends on DISCONTIGMEM && BROKEN
        help
          Say Y to compile the kernel to support NUMA (Non-Uniform Memory
          Access).  This option is for configuring high-end multiprocessor
index 1f36bbd0ed5db64e88005d79be5c08d6be384998..2a8b364c822e9f0e17c9ead5352ab84ad9f1ace6 100644 (file)
@@ -350,8 +350,24 @@ pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
        region->end = res->end - offset;
 }
 
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+                            struct pci_bus_region *region)
+{
+       struct pci_controller *hose = (struct pci_controller *)dev->sysdata;
+       unsigned long offset = 0;
+
+       if (res->flags & IORESOURCE_IO)
+               offset = hose->io_space->start;
+       else if (res->flags & IORESOURCE_MEM)
+               offset = hose->mem_space->start;
+
+       res->start = region->start + offset;
+       res->end = region->end + offset;
+}
+
 #ifdef CONFIG_HOTPLUG
 EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
 #endif
 
 int
index 8f1e78551b1e39b669bf696284802ad216f2d065..e211aa7404e6152c4668277fdc03872547d8fab1 100644 (file)
@@ -1036,7 +1036,7 @@ debug_spin_lock(spinlock_t * lock, const char *base_file, int line_no)
        "       br      1b\n"
        ".previous"
        : "=r" (tmp), "=m" (lock->lock), "=r" (stuck)
-       : "1" (lock->lock), "2" (stuck) : "memory");
+       : "m" (lock->lock), "2" (stuck) : "memory");
 
        if (stuck < 0) {
                printk(KERN_WARNING
@@ -1115,7 +1115,7 @@ void _raw_write_lock(rwlock_t * lock)
        ".previous"
        : "=m" (*(volatile int *)lock), "=&r" (regx), "=&r" (regy),
          "=&r" (stuck_lock), "=&r" (stuck_reader)
-       : "0" (*(volatile int *)lock), "3" (stuck_lock), "4" (stuck_reader) : "memory");
+       : "m" (*(volatile int *)lock), "3" (stuck_lock), "4" (stuck_reader) : "memory");
 
        if (stuck_lock < 0) {
                printk(KERN_WARNING "write_lock stuck at %p\n", inline_pc);
@@ -1153,7 +1153,7 @@ void _raw_read_lock(rwlock_t * lock)
        "       br      1b\n"
        ".previous"
        : "=m" (*(volatile int *)lock), "=&r" (regx), "=&r" (stuck_lock)
-       : "0" (*(volatile int *)lock), "2" (stuck_lock) : "memory");
+       : "m" (*(volatile int *)lock), "2" (stuck_lock) : "memory");
 
        if (stuck_lock < 0) {
                printk(KERN_WARNING "read_lock stuck at %p\n", inline_pc);
index 908eb4af8decfe263e0908297256e7bfec5e73b3..ba788cfdc3c6cb00a31f31d82cd1f545420ff751 100644 (file)
@@ -65,7 +65,7 @@ op_axp_setup(void)
        model->reg_setup(&reg, ctr, &sys);
 
        /* Configure the registers on all cpus.  */
-       smp_call_function(model->cpu_setup, &reg, 0, 1);
+       (void)smp_call_function(model->cpu_setup, &reg, 0, 1);
        model->cpu_setup(&reg);
        return 0;
 }
@@ -86,7 +86,7 @@ op_axp_cpu_start(void *dummy)
 static int
 op_axp_start(void)
 {
-       smp_call_function(op_axp_cpu_start, NULL, 0, 1);
+       (void)smp_call_function(op_axp_cpu_start, NULL, 0, 1);
        op_axp_cpu_start(NULL);
        return 0;
 }
@@ -101,7 +101,7 @@ op_axp_cpu_stop(void *dummy)
 static void
 op_axp_stop(void)
 {
-       smp_call_function(op_axp_cpu_stop, NULL, 0, 1);
+       (void)smp_call_function(op_axp_cpu_stop, NULL, 0, 1);
        op_axp_cpu_stop(NULL);
 }
 
index 7bc4a583f4e101a01bfdc92707bf2f25f5048b61..c65c6eb9810d84b05267470cadfbf2efc9b0e682 100644 (file)
@@ -310,7 +310,7 @@ menu "Kernel Features"
 
 config SMP
        bool "Symmetric Multi-Processing (EXPERIMENTAL)"
-       depends on EXPERIMENTAL #&& n
+       depends on EXPERIMENTAL && BROKEN #&& n
        help
          This enables support for systems with more than one CPU. If you have
          a system with only one CPU, like most personal computers, say N. If
index ad26e98f1e62343c5f231c5358319c9342bd39cf..c4923fac8dff56bf9a6232b4554c643668fafe7b 100644 (file)
@@ -447,9 +447,26 @@ pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
        region->end   = res->end - offset;
 }
 
+void __devinit
+pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+                       struct pci_bus_region *region)
+{
+       struct pci_sys_data *root = dev->sysdata;
+       unsigned long offset = 0;
+
+       if (res->flags & IORESOURCE_IO)
+               offset = root->io_offset;
+       if (res->flags & IORESOURCE_MEM)
+               offset = root->mem_offset;
+
+       res->start = region->start + offset;
+       res->end   = region->end + offset;
+}
+
 #ifdef CONFIG_HOTPLUG
 EXPORT_SYMBOL(pcibios_fixup_bus);
 EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
 #endif
 
 /*
index e5d370c235d747575cf25a6f955c277c92df3957..2b6b4c786e654c125cfa62b750337bc5894b9731 100644 (file)
@@ -327,6 +327,12 @@ __syscall_start:
 /* 310 */      .long   sys_request_key
                .long   sys_keyctl
                .long   sys_semtimedop
+/* vserver */  .long   sys_ni_syscall
+               .long   sys_ioprio_set
+/* 315 */      .long   sys_ioprio_get
+               .long   sys_inotify_init
+               .long   sys_inotify_add_watch
+               .long   sys_inotify_rm_watch
 __syscall_end:
 
                .rept   NR_syscalls - (__syscall_end - __syscall_start) / 4
index 39a6c1b0b9a32db8f578bab2d9f4156acc5d4054..7152bfbee581ea4fa83769bd323564a6249782f7 100644 (file)
@@ -533,6 +533,13 @@ ENTRY(__switch_to)
        ldr     r3, [r2, #TI_TP_VALUE]
        stmia   ip!, {r4 - sl, fp, sp, lr}      @ Store most regs on stack
        ldr     r6, [r2, #TI_CPU_DOMAIN]!
+#if __LINUX_ARM_ARCH__ >= 6
+#ifdef CONFIG_CPU_MPCORE
+       clrex
+#else
+       strex   r3, r4, [ip]                    @ Clear exclusive monitor
+#endif
+#endif
 #if defined(CONFIG_CPU_XSCALE) && !defined(CONFIG_IWMMXT)
        mra     r4, r5, acc0
        stmia   ip, {r4, r5}
index d571c37ac30c1f0b16fd8e81f5542aa35995d4d4..4554c961251c5871e0a05a2c6a74d1f660d0af73 100644 (file)
@@ -617,7 +617,7 @@ baddataabort(int code, unsigned long instr, struct pt_regs *regs)
        notify_die("unknown data abort code", regs, &info, instr, 0);
 }
 
-volatile void __bug(const char *file, int line, void *data)
+void __attribute__((noreturn)) __bug(const char *file, int line, void *data)
 {
        printk(KERN_CRIT"kernel BUG at %s:%d!", file, line);
        if (data)
index 2036ff15bda9b70e0c5f8b6f79538008ebe393e4..64a988c1ad447739ccf7a67d4b4c0ebdb7e3f6d2 100644 (file)
@@ -1,4 +1,6 @@
-#if __LINUX_ARM_ARCH__ >= 6
+#include <linux/config.h>
+
+#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_MPCORE)
        .macro  bitop, instr
        mov     r2, #1
        and     r3, r0, #7              @ Get bit offset
index 4ff4393ef0ea681fcd0eca14fdae6bee00f03e35..411ea999619055a7b0e73bd3678ecd9ad8806989 100644 (file)
@@ -36,7 +36,7 @@ static struct flash_platform_data coyote_flash_data = {
 
 static struct resource coyote_flash_resource = {
        .start          = COYOTE_FLASH_BASE,
-       .end            = COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE,
+       .end            = COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE - 1,
        .flags          = IORESOURCE_MEM,
 };
 
@@ -61,7 +61,7 @@ static struct plat_serial8250_port coyote_uart_data[] = {
                .mapbase        = IXP4XX_UART2_BASE_PHYS,
                .membase        = (char *)IXP4XX_UART2_BASE_VIRT + REG_OFFSET,
                .irq            = IRQ_IXP4XX_UART2,
-               .flags          = UPF_BOOT_AUTOCONF,
+               .flags          = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
                .iotype         = UPIO_MEM,
                .regshift       = 2,
                .uartclk        = IXP4XX_UART_XTAL,
index 8ba1cd9406e702fbc66f1be2dd9124599d6c1630..333459d6aa464bb5394fd46783e9b6690b6ed4aa 100644 (file)
@@ -83,7 +83,7 @@ static struct plat_serial8250_port gtwx5715_uart_platform_data[] = {
        .mapbase        = IXP4XX_UART2_BASE_PHYS,
        .membase        = (char *)IXP4XX_UART2_BASE_VIRT + REG_OFFSET,
        .irq            = IRQ_IXP4XX_UART2,
-       .flags          = UPF_BOOT_AUTOCONF,
+       .flags          = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
        .iotype         = UPIO_MEM,
        .regshift       = 2,
        .uartclk        = IXP4XX_UART_XTAL,
@@ -114,7 +114,7 @@ static struct flash_platform_data gtwx5715_flash_data = {
 
 static struct resource gtwx5715_flash_resource = {
        .start          = GTWX5715_FLASH_BASE,
-       .end            = GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE,
+       .end            = GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE - 1,
        .flags          = IORESOURCE_MEM,
 };
 
index c2ba759e994611116101bb6719ed84d6bc069227..fa0646c8693b096c7c1ee6b6a16dc3074bff2679 100644 (file)
@@ -36,7 +36,7 @@ static struct flash_platform_data ixdp425_flash_data = {
 
 static struct resource ixdp425_flash_resource = {
        .start          = IXDP425_FLASH_BASE,
-       .end            = IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE,
+       .end            = IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE - 1,
        .flags          = IORESOURCE_MEM,
 };
 
@@ -82,7 +82,7 @@ static struct plat_serial8250_port ixdp425_uart_data[] = {
                .mapbase        = IXP4XX_UART1_BASE_PHYS,
                .membase        = (char *)IXP4XX_UART1_BASE_VIRT + REG_OFFSET,
                .irq            = IRQ_IXP4XX_UART1,
-               .flags          = UPF_BOOT_AUTOCONF,
+               .flags          = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
                .iotype         = UPIO_MEM,
                .regshift       = 2,
                .uartclk        = IXP4XX_UART_XTAL,
@@ -91,7 +91,7 @@ static struct plat_serial8250_port ixdp425_uart_data[] = {
                .mapbase        = IXP4XX_UART2_BASE_PHYS,
                .membase        = (char *)IXP4XX_UART2_BASE_VIRT + REG_OFFSET,
                .irq            = IRQ_IXP4XX_UART1,
-               .flags          = UPF_BOOT_AUTOCONF,
+               .flags          = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
                .iotype         = UPIO_MEM,
                .regshift       = 2,
                .uartclk        = IXP4XX_UART_XTAL,
index 1e7f343822d0c5c111d5988bcb0eeeb4126ad7bc..e9182242da95be91ebe9dfc5f389c0a3318d8a5e 100644 (file)
@@ -30,6 +30,7 @@
  *     28-Jun-2005 BJD  Moved pm functionality out to common code
  *     17-Jul-2005 BJD  Changed to platform device for SuperIO 16550s
  *     25-Jul-2005 BJD  Removed ASIX static mappings
+ *     27-Jul-2005 BJD  Ensure maximum frequency of i2c bus
 */
 
 #include <linux/kernel.h>
@@ -60,6 +61,7 @@
 #include <asm/arch/regs-mem.h>
 #include <asm/arch/regs-lcd.h>
 #include <asm/arch/nand.h>
+#include <asm/arch/iic.h>
 
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
@@ -304,7 +306,7 @@ static void bast_nand_select(struct s3c2410_nand_set *set, int slot)
 }
 
 static struct s3c2410_platform_nand bast_nand_info = {
-       .tacls          = 80,
+       .tacls          = 40,
        .twrph0         = 80,
        .twrph1         = 80,
        .nr_sets        = ARRAY_SIZE(bast_nand_sets),
@@ -385,6 +387,17 @@ static struct platform_device bast_sio = {
        },
 };
 
+/* we have devices on the bus which cannot work much over the
+ * standard 100KHz i2c bus frequency
+*/
+
+static struct s3c2410_platform_i2c bast_i2c_info = {
+       .flags          = 0,
+       .slave_addr     = 0x10,
+       .bus_freq       = 100*1000,
+       .max_freq       = 130*1000,
+};
+
 /* Standard BAST devices */
 
 static struct platform_device *bast_devices[] __initdata = {
@@ -431,6 +444,7 @@ void __init bast_map_io(void)
        s3c24xx_uclk.parent  = &s3c24xx_clkout1;
 
        s3c_device_nand.dev.platform_data = &bast_nand_info;
+       s3c_device_i2c.dev.platform_data = &bast_i2c_info;
 
        s3c24xx_init_io(bast_iodesc, ARRAY_SIZE(bast_iodesc));
        s3c24xx_init_clocks(0);
index ff2f25409e446baf77b66390dad0928b7d3d773a..0b88993dfd27c514c181f6adc83aeb898aaf28d7 100644 (file)
@@ -18,6 +18,7 @@
  *     28-Sep-2004 BJD  Updates for new serial port bits
  *     04-Nov-2004 BJD  Updated UART configuration process
  *     10-Jan-2005 BJD  Removed s3c2410_clock_tick_rate
+ *     13-Aug-2005 DA   Removed UART from initial I/O mappings
 */
 
 #include <linux/kernel.h>
@@ -49,10 +50,9 @@ static struct map_desc s3c2410_iodesc[] __initdata = {
        IODESC_ENT(USBHOST),
        IODESC_ENT(CLKPWR),
        IODESC_ENT(LCD),
-       IODESC_ENT(UART),
        IODESC_ENT(TIMER),
        IODESC_ENT(ADC),
-       IODESC_ENT(WATCHDOG)
+       IODESC_ENT(WATCHDOG),
 };
 
 static struct resource s3c_uart0_resource[] = {
index 7f2b61362976b088a5c8126f4f7915082062b307..f021fd82be52cb7260c91be5c02a8ce0c4d2ef49 100644 (file)
@@ -1,6 +1,6 @@
 /* linux/arch/arm/mach-s3c2410/usb-simtec.c
  *
- * Copyright (c) 2004 Simtec Electronics
+ * Copyright (c) 2004,2005 Simtec Electronics
  *   Ben Dooks <ben@simtec.co.uk>
  *
  * http://www.simtec.co.uk/products/EB2410ITX/
@@ -14,6 +14,8 @@
  * Modifications:
  *     14-Sep-2004 BJD  Created
  *     18-Oct-2004 BJD  Cleanups, and added code to report OC cleared
+ *     09-Aug-2005 BJD  Renamed s3c2410_report_oc to s3c2410_usb_report_oc
+ *     09-Aug-2005 BJD  Ports powered only if both are enabled
 */
 
 #define DEBUG
  * designed boards.
 */
 
+static unsigned int power_state[2];
+
 static void
 usb_simtec_powercontrol(int port, int to)
 {
        pr_debug("usb_simtec_powercontrol(%d,%d)\n", port, to);
 
-       if (port == 1)
-               s3c2410_gpio_setpin(S3C2410_GPB4, to ? 0:1);
+       power_state[port] = to;
+
+       if (power_state[0] && power_state[1])
+               s3c2410_gpio_setpin(S3C2410_GPB4, 0);
+       else
+               s3c2410_gpio_setpin(S3C2410_GPB4, 1);
 }
 
 static irqreturn_t
@@ -63,10 +71,10 @@ usb_simtec_ocirq(int irq, void *pw, struct pt_regs *regs)
 
        if (s3c2410_gpio_getpin(S3C2410_GPG10) == 0) {
                pr_debug("usb_simtec: over-current irq (oc detected)\n");
-               s3c2410_report_oc(info, 3);
+               s3c2410_usb_report_oc(info, 3);
        } else {
                pr_debug("usb_simtec: over-current irq (oc cleared)\n");
-               s3c2410_report_oc(info, 0);
+               s3c2410_usb_report_oc(info, 0);
        }
 
        return IRQ_HANDLED;
index eee3cbc5ec4f4d3a7bd9e0fcde4fc74e746c0454..2f497112c96a176c0d72b90095c66ffb1d0b5536 100644 (file)
@@ -97,6 +97,7 @@ static void __init jornada720_map_io(void)
 }
 
 MACHINE_START(JORNADA720, "HP Jornada 720")
+       /* Maintainer: Michael Gernoth <michael@gernoth.net> */
        .phys_ram       = 0xc0000000,
        .phys_io        = 0x80000000,
        .io_pg_offst    = ((0xf8000000) >> 18) & 0xfffc,
index afbbeb6f46582270b834ffa6e8da166a3d1bf014..db5e47dfc303dce4a49b9ca54db0ab1f0e3673af 100644 (file)
@@ -384,7 +384,7 @@ config CPU_DCACHE_DISABLE
 
 config CPU_DCACHE_WRITETHROUGH
        bool "Force write through D-cache"
-       depends on (CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM1020) && !CPU_DISABLE_DCACHE
+       depends on (CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM1020) && !CPU_DCACHE_DISABLE
        default y if CPU_ARM925T
        help
          Say Y here to use the data cache in writethrough mode. Unless you
index 65bfe84b6d672e8989f0d8141b5781093147cf74..0b6c4db44e08275e4ef15ab74923a581f48dc645 100644 (file)
@@ -238,9 +238,9 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
        up_read(&mm->mmap_sem);
 
        /*
-        * Handle the "normal" case first
+        * Handle the "normal" case first - VM_FAULT_MAJOR / VM_FAULT_MINOR
         */
-       if (fault > 0)
+       if (fault >= VM_FAULT_MINOR)
                return 0;
 
        /*
@@ -261,7 +261,7 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
                do_exit(SIGKILL);
                return 0;
 
-       case 0:
+       case VM_FAULT_SIGBUS:
                /*
                 * We had some memory, but were unable to
                 * successfully fix up this page fault.
index e33fe4229d056e9ae098249ceb2b3b022cd87196..3c655c54e23131b10cbf33d3d1fb1fe4a81d52be 100644 (file)
@@ -383,6 +383,7 @@ static void __init build_mem_type_table(void)
 {
        struct cachepolicy *cp;
        unsigned int cr = get_cr();
+       unsigned int user_pgprot;
        int cpu_arch = cpu_architecture();
        int i;
 
@@ -408,6 +409,9 @@ static void __init build_mem_type_table(void)
                }
        }
 
+       cp = &cache_policies[cachepolicy];
+       user_pgprot = cp->pte;
+
        /*
         * ARMv6 and above have extended page tables.
         */
@@ -426,11 +430,18 @@ static void __init build_mem_type_table(void)
                mem_types[MT_MINICLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
                mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
 
+               /*
+                * Mark the device area as "shared device"
+                */
                mem_types[MT_DEVICE].prot_pte |= L_PTE_BUFFERABLE;
                mem_types[MT_DEVICE].prot_sect |= PMD_SECT_BUFFERED;
-       }
 
-       cp = &cache_policies[cachepolicy];
+               /*
+                * User pages need to be mapped with the ASID
+                * (iow, non-global)
+                */
+               user_pgprot |= L_PTE_ASID;
+       }
 
        if (cpu_arch >= CPU_ARCH_ARMv5) {
                mem_types[MT_LOW_VECTORS].prot_pte |= cp->pte & PTE_CACHEABLE;
@@ -448,7 +459,7 @@ static void __init build_mem_type_table(void)
 
        for (i = 0; i < 16; i++) {
                unsigned long v = pgprot_val(protection_map[i]);
-               v &= (~(PTE_BUFFERABLE|PTE_CACHEABLE)) | cp->pte;
+               v &= (~(PTE_BUFFERABLE|PTE_CACHEABLE)) | user_pgprot;
                protection_map[i] = __pgprot(v);
        }
 
index 352db98ee2697f7f985973945f5d5fc2909d3263..139a38670c5d07d35d37150adcd6358f64aefb22 100644 (file)
@@ -105,18 +105,12 @@ ENTRY(cpu_v6_dcache_clean_area)
 ENTRY(cpu_v6_switch_mm)
        mov     r2, #0
        ldr     r1, [r1, #MM_CONTEXT_ID]        @ get mm->context.id
-       mcr     p15, 0, r2, c7, c5, 6           @ flush BTAC/BTB
+       mcr     p15, 0, r2, c7, c5, 6           @ flush BTAC/BTB
        mcr     p15, 0, r2, c7, c10, 4          @ drain write buffer
        mcr     p15, 0, r0, c2, c0, 0           @ set TTB 0
        mcr     p15, 0, r1, c13, c0, 1          @ set context ID
        mov     pc, lr
 
-#define nG     (1 << 11)
-#define APX    (1 << 9)
-#define AP1    (1 << 5)
-#define AP0    (1 << 4)
-#define XN     (1 << 0)
-
 /*
  *     cpu_v6_set_pte(ptep, pte)
  *
@@ -139,24 +133,24 @@ ENTRY(cpu_v6_switch_mm)
 ENTRY(cpu_v6_set_pte)
        str     r1, [r0], #-2048                @ linux version
 
-       bic     r2, r1, #0x00000ff0
+       bic     r2, r1, #0x000007f0
        bic     r2, r2, #0x00000003
-       orr     r2, r2, #AP0 | 2
+       orr     r2, r2, #PTE_EXT_AP0 | 2
 
        tst     r1, #L_PTE_WRITE
        tstne   r1, #L_PTE_DIRTY
-       orreq   r2, r2, #APX
+       orreq   r2, r2, #PTE_EXT_APX
 
        tst     r1, #L_PTE_USER
-       orrne   r2, r2, #AP1 | nG
-       tstne   r2, #APX
-       bicne   r2, r2, #APX | AP0
+       orrne   r2, r2, #PTE_EXT_AP1
+       tstne   r2, #PTE_EXT_APX
+       bicne   r2, r2, #PTE_EXT_APX | PTE_EXT_AP0
 
        tst     r1, #L_PTE_YOUNG
-       biceq   r2, r2, #APX | AP1 | AP0
+       biceq   r2, r2, #PTE_EXT_APX | PTE_EXT_AP_MASK
 
 @      tst     r1, #L_PTE_EXEC
-@      orreq   r2, r2, #XN
+@      orreq   r2, r2, #PTE_EXT_XN
 
        tst     r1, #L_PTE_PRESENT
        moveq   r2, #0
index 2d977b4eeeabf95937be3ad863a550d62e21e40e..b88de2700146e6cd494b774985eeca84df14c256 100644 (file)
@@ -370,142 +370,6 @@ ENTRY(cpu_xscale_dcache_clean_area)
        bhi     1b
        mov     pc, lr
 
-/* ================================ CACHE LOCKING============================
- *
- * The XScale MicroArchitecture implements support for locking entries into
- * the data and instruction cache.  The following functions implement the core
- * low level instructions needed to accomplish the locking.  The developer's
- * manual states that the code that performs the locking must be in non-cached
- * memory.  To accomplish this, the code in xscale-cache-lock.c copies the
- * following functions from the cache into a non-cached memory region that
- * is allocated through consistent_alloc().
- *
- */
-       .align  5
-/*
- * xscale_icache_lock
- *
- * r0: starting address to lock
- * r1: end address to lock
- */
-ENTRY(xscale_icache_lock)
-
-iLockLoop:
-       bic     r0, r0, #CACHELINESIZE - 1
-       mcr     p15, 0, r0, c9, c1, 0   @ lock into cache
-       cmp     r0, r1                  @ are we done?
-       add     r0, r0, #CACHELINESIZE  @ advance to next cache line
-       bls     iLockLoop
-       mov     pc, lr
-
-/*
- * xscale_icache_unlock
- */
-ENTRY(xscale_icache_unlock)
-       mcr     p15, 0, r0, c9, c1, 1   @ Unlock icache
-       mov     pc, lr
-
-/*
- * xscale_dcache_lock
- *
- * r0: starting address to lock
- * r1: end address to lock
- */
-ENTRY(xscale_dcache_lock)
-       mcr     p15, 0, ip, c7, c10, 4          @ Drain Write (& Fill) Buffer
-       mov     r2, #1
-       mcr     p15, 0, r2, c9, c2, 0   @ Put dcache in lock mode
-       cpwait  ip                      @ Wait for completion
-
-       mrs     r2, cpsr
-       orr     r3, r2, #PSR_F_BIT | PSR_I_BIT
-dLockLoop:
-       msr     cpsr_c, r3
-       mcr     p15, 0, r0, c7, c10, 1  @ Write back line if it is dirty
-       mcr     p15, 0, r0, c7, c6, 1   @ Flush/invalidate line
-       msr     cpsr_c, r2
-       ldr     ip, [r0], #CACHELINESIZE @ Preload 32 bytes into cache from
-                                       @ location [r0]. Post-increment
-                                       @ r3 to next cache line
-       cmp     r0, r1                  @ Are we done?
-       bls     dLockLoop
-
-       mcr     p15, 0, ip, c7, c10, 4          @ Drain Write (& Fill) Buffer
-       mov     r2, #0
-       mcr     p15, 0, r2, c9, c2, 0   @ Get out of lock mode
-       cpwait_ret lr, ip
-
-/*
- * xscale_dcache_unlock
- */
-ENTRY(xscale_dcache_unlock)
-       mcr     p15, 0, ip, c7, c10, 4          @ Drain Write (& Fill) Buffer
-       mcr     p15, 0, ip, c9, c2, 1   @ Unlock cache
-       mov     pc, lr
-
-/*
- * Needed to determine the length of the code that needs to be copied.
- */
-       .align  5
-ENTRY(xscale_cache_dummy)
-       mov     pc, lr
-
-/* ================================ TLB LOCKING==============================
- *
- * The XScale MicroArchitecture implements support for locking entries into
- * the Instruction and Data TLBs.  The following functions provide the
- * low level support for supporting these under Linux.  xscale-lock.c
- * implements some higher level management code.  Most of the following
- * is taken straight out of the Developer's Manual.
- */
-
-/*
- * Lock I-TLB entry
- *
- * r0: Virtual address to translate and lock
- */
-       .align  5
-ENTRY(xscale_itlb_lock)
-       mrs     r2, cpsr
-       orr     r3, r2, #PSR_F_BIT | PSR_I_BIT
-       msr     cpsr_c, r3                      @ Disable interrupts
-       mcr     p15, 0, r0, c8, c5, 1           @ Invalidate I-TLB entry
-       mcr     p15, 0, r0, c10, c4, 0          @ Translate and lock
-       msr     cpsr_c, r2                      @ Restore interrupts
-       cpwait_ret lr, ip
-
-/*
- * Lock D-TLB entry
- *
- * r0: Virtual address to translate and lock
- */
-       .align  5
-ENTRY(xscale_dtlb_lock)
-       mrs     r2, cpsr
-       orr     r3, r2, #PSR_F_BIT | PSR_I_BIT
-       msr     cpsr_c, r3                      @ Disable interrupts
-       mcr     p15, 0, r0, c8, c6, 1           @ Invalidate D-TLB entry
-       mcr     p15, 0, r0, c10, c8, 0          @ Translate and lock
-       msr     cpsr_c, r2                      @ Restore interrupts
-       cpwait_ret lr, ip
-
-/*
- * Unlock all I-TLB entries
- */
-       .align  5
-ENTRY(xscale_itlb_unlock)
-       mcr     p15, 0, ip, c10, c4, 1          @ Unlock I-TLB
-       mcr     p15, 0, ip, c8, c5, 0           @ Invalidate I-TLB
-       cpwait_ret lr, ip
-
-/*
- * Unlock all D-TLB entries
- */
-ENTRY(xscale_dtlb_unlock)
-       mcr     p15, 0, ip, c10, c8, 1          @ Unlock D-TBL
-       mcr     p15, 0, ip, c8, c6, 0           @ Invalidate D-TLB
-       cpwait_ret lr, ip
-
 /* =============================== PageTable ============================== */
 
 #define PTE_CACHE_WRITE_ALLOCATE 0
index 7ffd8cb9bc9609ced698a093777cc29e7678505b..c51d1386a97c9492786a0ec49ed7947be83d4a28 100644 (file)
@@ -40,17 +40,17 @@ float64 float64_arccos(float64 rFm);
 float64 float64_pow(float64 rFn, float64 rFm);
 float64 float64_pol(float64 rFn, float64 rFm);
 
-static float64 float64_rsf(float64 rFn, float64 rFm)
+static float64 float64_rsf(struct roundingData *roundData, float64 rFn, float64 rFm)
 {
-       return float64_sub(rFm, rFn);
+       return float64_sub(roundData, rFm, rFn);
 }
 
-static float64 float64_rdv(float64 rFn, float64 rFm)
+static float64 float64_rdv(struct roundingData *roundData, float64 rFn, float64 rFm)
 {
-       return float64_div(rFm, rFn);
+       return float64_div(roundData, rFm, rFn);
 }
 
-static float64 (*const dyadic_double[16])(float64 rFn, float64 rFm) = {
+static float64 (*const dyadic_double[16])(struct roundingData*, float64 rFn, float64 rFm) = {
        [ADF_CODE >> 20] = float64_add,
        [MUF_CODE >> 20] = float64_mul,
        [SUF_CODE >> 20] = float64_sub,
@@ -65,12 +65,12 @@ static float64 (*const dyadic_double[16])(float64 rFn, float64 rFm) = {
        [FRD_CODE >> 20] = float64_rdv,
 };
 
-static float64 float64_mvf(float64 rFm)
+static float64 float64_mvf(struct roundingData *roundData,float64 rFm)
 {
        return rFm;
 }
 
-static float64 float64_mnf(float64 rFm)
+static float64 float64_mnf(struct roundingData *roundData,float64 rFm)
 {
        union float64_components u;
 
@@ -84,7 +84,7 @@ static float64 float64_mnf(float64 rFm)
        return u.f64;
 }
 
-static float64 float64_abs(float64 rFm)
+static float64 float64_abs(struct roundingData *roundData,float64 rFm)
 {
        union float64_components u;
 
@@ -98,7 +98,7 @@ static float64 float64_abs(float64 rFm)
        return u.f64;
 }
 
-static float64 (*const monadic_double[16])(float64 rFm) = {
+static float64 (*const monadic_double[16])(struct roundingData *, float64 rFm) = {
        [MVF_CODE >> 20] = float64_mvf,
        [MNF_CODE >> 20] = float64_mnf,
        [ABS_CODE >> 20] = float64_abs,
@@ -108,7 +108,7 @@ static float64 (*const monadic_double[16])(float64 rFm) = {
        [NRM_CODE >> 20] = float64_mvf,
 };
 
-unsigned int DoubleCPDO(const unsigned int opcode, FPREG * rFd)
+unsigned int DoubleCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd)
 {
        FPA11 *fpa11 = GET_FPA11();
        float64 rFm;
@@ -151,13 +151,13 @@ unsigned int DoubleCPDO(const unsigned int opcode, FPREG * rFd)
                }
 
                if (dyadic_double[opc_mask_shift]) {
-                       rFd->fDouble = dyadic_double[opc_mask_shift](rFn, rFm);
+                       rFd->fDouble = dyadic_double[opc_mask_shift](roundData, rFn, rFm);
                } else {
                        return 0;
                }
        } else {
                if (monadic_double[opc_mask_shift]) {
-                       rFd->fDouble = monadic_double[opc_mask_shift](rFm);
+                       rFd->fDouble = monadic_double[opc_mask_shift](roundData, rFm);
                } else {
                        return 0;
                }
index c39f68a3449e0799a7e0db046c179d01f517b703..65a279ba927ffac47ca5de5e3a38317c8547e8fc 100644 (file)
@@ -35,17 +35,17 @@ floatx80 floatx80_arccos(floatx80 rFm);
 floatx80 floatx80_pow(floatx80 rFn, floatx80 rFm);
 floatx80 floatx80_pol(floatx80 rFn, floatx80 rFm);
 
-static floatx80 floatx80_rsf(floatx80 rFn, floatx80 rFm)
+static floatx80 floatx80_rsf(struct roundingData *roundData, floatx80 rFn, floatx80 rFm)
 {
-       return floatx80_sub(rFm, rFn);
+       return floatx80_sub(roundData, rFm, rFn);
 }
 
-static floatx80 floatx80_rdv(floatx80 rFn, floatx80 rFm)
+static floatx80 floatx80_rdv(struct roundingData *roundData, floatx80 rFn, floatx80 rFm)
 {
-       return floatx80_div(rFm, rFn);
+       return floatx80_div(roundData, rFm, rFn);
 }
 
-static floatx80 (*const dyadic_extended[16])(floatx80 rFn, floatx80 rFm) = {
+static floatx80 (*const dyadic_extended[16])(struct roundingData*, floatx80 rFn, floatx80 rFm) = {
        [ADF_CODE >> 20] = floatx80_add,
        [MUF_CODE >> 20] = floatx80_mul,
        [SUF_CODE >> 20] = floatx80_sub,
@@ -60,24 +60,24 @@ static floatx80 (*const dyadic_extended[16])(floatx80 rFn, floatx80 rFm) = {
        [FRD_CODE >> 20] = floatx80_rdv,
 };
 
-static floatx80 floatx80_mvf(floatx80 rFm)
+static floatx80 floatx80_mvf(struct roundingData *roundData, floatx80 rFm)
 {
        return rFm;
 }
 
-static floatx80 floatx80_mnf(floatx80 rFm)
+static floatx80 floatx80_mnf(struct roundingData *roundData, floatx80 rFm)
 {
        rFm.high ^= 0x8000;
        return rFm;
 }
 
-static floatx80 floatx80_abs(floatx80 rFm)
+static floatx80 floatx80_abs(struct roundingData *roundData, floatx80 rFm)
 {
        rFm.high &= 0x7fff;
        return rFm;
 }
 
-static floatx80 (*const monadic_extended[16])(floatx80 rFm) = {
+static floatx80 (*const monadic_extended[16])(struct roundingData*, floatx80 rFm) = {
        [MVF_CODE >> 20] = floatx80_mvf,
        [MNF_CODE >> 20] = floatx80_mnf,
        [ABS_CODE >> 20] = floatx80_abs,
@@ -87,7 +87,7 @@ static floatx80 (*const monadic_extended[16])(floatx80 rFm) = {
        [NRM_CODE >> 20] = floatx80_mvf,
 };
 
-unsigned int ExtendedCPDO(const unsigned int opcode, FPREG * rFd)
+unsigned int ExtendedCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd)
 {
        FPA11 *fpa11 = GET_FPA11();
        floatx80 rFm;
@@ -138,13 +138,13 @@ unsigned int ExtendedCPDO(const unsigned int opcode, FPREG * rFd)
                }
 
                if (dyadic_extended[opc_mask_shift]) {
-                       rFd->fExtended = dyadic_extended[opc_mask_shift](rFn, rFm);
+                       rFd->fExtended = dyadic_extended[opc_mask_shift](roundData, rFn, rFm);
                } else {
                        return 0;
                }
        } else {
                if (monadic_extended[opc_mask_shift]) {
-                       rFd->fExtended = monadic_extended[opc_mask_shift](rFm);
+                       rFd->fExtended = monadic_extended[opc_mask_shift](roundData, rFm);
                } else {
                        return 0;
                }
index bf61696865ec2c6531007d6eaa6aedd6c6bf8850..7690f731ee8706227acdf3b1f56de14f2b906839 100644 (file)
@@ -51,48 +51,42 @@ static void resetFPA11(void)
        fpa11->fpsr = FP_EMULATOR | BIT_AC;
 }
 
-void SetRoundingMode(const unsigned int opcode)
+int8 SetRoundingMode(const unsigned int opcode)
 {
        switch (opcode & MASK_ROUNDING_MODE) {
        default:
        case ROUND_TO_NEAREST:
-               float_rounding_mode = float_round_nearest_even;
-               break;
+               return float_round_nearest_even;
 
        case ROUND_TO_PLUS_INFINITY:
-               float_rounding_mode = float_round_up;
-               break;
+               return float_round_up;
 
        case ROUND_TO_MINUS_INFINITY:
-               float_rounding_mode = float_round_down;
-               break;
+               return float_round_down;
 
        case ROUND_TO_ZERO:
-               float_rounding_mode = float_round_to_zero;
-               break;
+               return float_round_to_zero;
        }
 }
 
-void SetRoundingPrecision(const unsigned int opcode)
+int8 SetRoundingPrecision(const unsigned int opcode)
 {
 #ifdef CONFIG_FPE_NWFPE_XP
        switch (opcode & MASK_ROUNDING_PRECISION) {
        case ROUND_SINGLE:
-               floatx80_rounding_precision = 32;
-               break;
+               return 32;
 
        case ROUND_DOUBLE:
-               floatx80_rounding_precision = 64;
-               break;
+               return 64;
 
        case ROUND_EXTENDED:
-               floatx80_rounding_precision = 80;
-               break;
+               return 80;
 
        default:
-               floatx80_rounding_precision = 80;
+               return 80;
        }
 #endif
+       return 80;
 }
 
 void nwfpe_init_fpa(union fp_state *fp)
@@ -103,8 +97,6 @@ void nwfpe_init_fpa(union fp_state *fp)
 #endif
        memset(fpa11, 0, sizeof(FPA11));
        resetFPA11();
-       SetRoundingMode(ROUND_TO_NEAREST);
-       SetRoundingPrecision(ROUND_EXTENDED);
        fpa11->initflag = 1;
 }
 
index e4a61aea534b4e840c02f969629d997a2465b339..93523ae4b7a1f028b6772de5d8f7455b27400c57 100644 (file)
 /* includes */
 #include "fpsr.h"              /* FP control and status register definitions */
 #include "milieu.h"
+
+struct roundingData {
+    int8 mode;
+    int8 precision;
+    signed char exception;
+};
+
 #include "softfloat.h"
 
 #define                typeNone                0x00
@@ -84,8 +91,8 @@ typedef struct tagFPA11 {
                                   initialised. */
 } FPA11;
 
-extern void SetRoundingMode(const unsigned int);
-extern void SetRoundingPrecision(const unsigned int);
+extern int8 SetRoundingMode(const unsigned int);
+extern int8 SetRoundingPrecision(const unsigned int);
 extern void nwfpe_init_fpa(union fp_state *fp);
 
 #endif
index 1bea67437b6f2bc5ed859b7aa0db2237e84a7c6e..4a31dfd9406884a90a242e7173bae04cd7f77bf2 100644 (file)
 #include "fpa11.h"
 #include "fpopcode.h"
 
-unsigned int SingleCPDO(const unsigned int opcode, FPREG * rFd);
-unsigned int DoubleCPDO(const unsigned int opcode, FPREG * rFd);
-unsigned int ExtendedCPDO(const unsigned int opcode, FPREG * rFd);
+unsigned int SingleCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd);
+unsigned int DoubleCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd);
+unsigned int ExtendedCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd);
 
 unsigned int EmulateCPDO(const unsigned int opcode)
 {
        FPA11 *fpa11 = GET_FPA11();
        FPREG *rFd;
        unsigned int nType, nDest, nRc;
+       struct roundingData roundData;
 
        /* Get the destination size.  If not valid let Linux perform
           an invalid instruction trap. */
@@ -40,7 +41,9 @@ unsigned int EmulateCPDO(const unsigned int opcode)
        if (typeNone == nDest)
                return 0;
 
-       SetRoundingMode(opcode);
+       roundData.mode = SetRoundingMode(opcode);
+       roundData.precision = SetRoundingPrecision(opcode);
+       roundData.exception = 0;
 
        /* Compare the size of the operands in Fn and Fm.
           Choose the largest size and perform operations in that size,
@@ -63,14 +66,14 @@ unsigned int EmulateCPDO(const unsigned int opcode)
 
        switch (nType) {
        case typeSingle:
-               nRc = SingleCPDO(opcode, rFd);
+               nRc = SingleCPDO(&roundData, opcode, rFd);
                break;
        case typeDouble:
-               nRc = DoubleCPDO(opcode, rFd);
+               nRc = DoubleCPDO(&roundData, opcode, rFd);
                break;
 #ifdef CONFIG_FPE_NWFPE_XP
        case typeExtended:
-               nRc = ExtendedCPDO(opcode, rFd);
+               nRc = ExtendedCPDO(&roundData, opcode, rFd);
                break;
 #endif
        default:
@@ -93,9 +96,9 @@ unsigned int EmulateCPDO(const unsigned int opcode)
                        case typeSingle:
                                {
                                        if (typeDouble == nType)
-                                               rFd->fSingle = float64_to_float32(rFd->fDouble);
+                                               rFd->fSingle = float64_to_float32(&roundData, rFd->fDouble);
                                        else
-                                               rFd->fSingle = floatx80_to_float32(rFd->fExtended);
+                                               rFd->fSingle = floatx80_to_float32(&roundData, rFd->fExtended);
                                }
                                break;
 
@@ -104,7 +107,7 @@ unsigned int EmulateCPDO(const unsigned int opcode)
                                        if (typeSingle == nType)
                                                rFd->fDouble = float32_to_float64(rFd->fSingle);
                                        else
-                                               rFd->fDouble = floatx80_to_float64(rFd->fExtended);
+                                               rFd->fDouble = floatx80_to_float64(&roundData, rFd->fExtended);
                                }
                                break;
 
@@ -121,12 +124,15 @@ unsigned int EmulateCPDO(const unsigned int opcode)
 #else
                if (nDest != nType) {
                        if (nDest == typeSingle)
-                               rFd->fSingle = float64_to_float32(rFd->fDouble);
+                               rFd->fSingle = float64_to_float32(&roundData, rFd->fDouble);
                        else
                                rFd->fDouble = float32_to_float64(rFd->fSingle);
                }
 #endif
        }
 
+       if (roundData.exception)
+               float_raise(roundData.exception);
+
        return nRc;
 }
index 95fb63fa9d181238423e6c5202c7ca3d57844a70..b0db5cbcc3b190575774991ff759d1590461a7d2 100644 (file)
@@ -96,7 +96,7 @@ static inline void loadMultiple(const unsigned int Fn, const unsigned int __user
        }
 }
 
-static inline void storeSingle(const unsigned int Fn, unsigned int __user *pMem)
+static inline void storeSingle(struct roundingData *roundData, const unsigned int Fn, unsigned int __user *pMem)
 {
        FPA11 *fpa11 = GET_FPA11();
        union {
@@ -106,12 +106,12 @@ static inline void storeSingle(const unsigned int Fn, unsigned int __user *pMem)
 
        switch (fpa11->fType[Fn]) {
        case typeDouble:
-               val.f = float64_to_float32(fpa11->fpreg[Fn].fDouble);
+               val.f = float64_to_float32(roundData, fpa11->fpreg[Fn].fDouble);
                break;
 
 #ifdef CONFIG_FPE_NWFPE_XP
        case typeExtended:
-               val.f = floatx80_to_float32(fpa11->fpreg[Fn].fExtended);
+               val.f = floatx80_to_float32(roundData, fpa11->fpreg[Fn].fExtended);
                break;
 #endif
 
@@ -122,7 +122,7 @@ static inline void storeSingle(const unsigned int Fn, unsigned int __user *pMem)
        put_user(val.i[0], pMem);
 }
 
-static inline void storeDouble(const unsigned int Fn, unsigned int __user *pMem)
+static inline void storeDouble(struct roundingData *roundData, const unsigned int Fn, unsigned int __user *pMem)
 {
        FPA11 *fpa11 = GET_FPA11();
        union {
@@ -137,7 +137,7 @@ static inline void storeDouble(const unsigned int Fn, unsigned int __user *pMem)
 
 #ifdef CONFIG_FPE_NWFPE_XP
        case typeExtended:
-               val.f = floatx80_to_float64(fpa11->fpreg[Fn].fExtended);
+               val.f = floatx80_to_float64(roundData, fpa11->fpreg[Fn].fExtended);
                break;
 #endif
 
@@ -259,8 +259,11 @@ unsigned int PerformSTF(const unsigned int opcode)
 {
        unsigned int __user *pBase, *pAddress, *pFinal;
        unsigned int nRc = 1, write_back = WRITE_BACK(opcode);
+       struct roundingData roundData;
 
-       SetRoundingMode(ROUND_TO_NEAREST);
+       roundData.mode = SetRoundingMode(opcode);
+       roundData.precision = SetRoundingPrecision(opcode);
+       roundData.exception = 0;
 
        pBase = (unsigned int __user *) readRegister(getRn(opcode));
        if (REG_PC == getRn(opcode)) {
@@ -281,10 +284,10 @@ unsigned int PerformSTF(const unsigned int opcode)
 
        switch (opcode & MASK_TRANSFER_LENGTH) {
        case TRANSFER_SINGLE:
-               storeSingle(getFd(opcode), pAddress);
+               storeSingle(&roundData, getFd(opcode), pAddress);
                break;
        case TRANSFER_DOUBLE:
-               storeDouble(getFd(opcode), pAddress);
+               storeDouble(&roundData, getFd(opcode), pAddress);
                break;
 #ifdef CONFIG_FPE_NWFPE_XP
        case TRANSFER_EXTENDED:
@@ -295,6 +298,9 @@ unsigned int PerformSTF(const unsigned int opcode)
                nRc = 0;
        }
 
+       if (roundData.exception)
+               float_raise(roundData.exception);
+
        if (write_back)
                writeRegister(getRn(opcode), (unsigned long) pFinal);
        return nRc;
index db01fbc97216829b52db0b5117b88e2457c1253e..adf8d3000540f9c6f774024ff22d720507a2e24f 100644 (file)
@@ -33,8 +33,6 @@ extern flag floatx80_is_nan(floatx80);
 extern flag float64_is_nan(float64);
 extern flag float32_is_nan(float32);
 
-void SetRoundingMode(const unsigned int opcode);
-
 unsigned int PerformFLT(const unsigned int opcode);
 unsigned int PerformFIX(const unsigned int opcode);
 
@@ -77,14 +75,17 @@ unsigned int EmulateCPRT(const unsigned int opcode)
 unsigned int PerformFLT(const unsigned int opcode)
 {
        FPA11 *fpa11 = GET_FPA11();
-       SetRoundingMode(opcode);
-       SetRoundingPrecision(opcode);
+       struct roundingData roundData;
+
+       roundData.mode = SetRoundingMode(opcode);
+       roundData.precision = SetRoundingPrecision(opcode);
+       roundData.exception = 0;
 
        switch (opcode & MASK_ROUNDING_PRECISION) {
        case ROUND_SINGLE:
                {
                        fpa11->fType[getFn(opcode)] = typeSingle;
-                       fpa11->fpreg[getFn(opcode)].fSingle = int32_to_float32(readRegister(getRd(opcode)));
+                       fpa11->fpreg[getFn(opcode)].fSingle = int32_to_float32(&roundData, readRegister(getRd(opcode)));
                }
                break;
 
@@ -108,6 +109,9 @@ unsigned int PerformFLT(const unsigned int opcode)
                return 0;
        }
 
+       if (roundData.exception)
+               float_raise(roundData.exception);
+
        return 1;
 }
 
@@ -115,26 +119,29 @@ unsigned int PerformFIX(const unsigned int opcode)
 {
        FPA11 *fpa11 = GET_FPA11();
        unsigned int Fn = getFm(opcode);
+       struct roundingData roundData;
 
-       SetRoundingMode(opcode);
+       roundData.mode = SetRoundingMode(opcode);
+       roundData.precision = SetRoundingPrecision(opcode);
+       roundData.exception = 0;
 
        switch (fpa11->fType[Fn]) {
        case typeSingle:
                {
-                       writeRegister(getRd(opcode), float32_to_int32(fpa11->fpreg[Fn].fSingle));
+                       writeRegister(getRd(opcode), float32_to_int32(&roundData, fpa11->fpreg[Fn].fSingle));
                }
                break;
 
        case typeDouble:
                {
-                       writeRegister(getRd(opcode), float64_to_int32(fpa11->fpreg[Fn].fDouble));
+                       writeRegister(getRd(opcode), float64_to_int32(&roundData, fpa11->fpreg[Fn].fDouble));
                }
                break;
 
 #ifdef CONFIG_FPE_NWFPE_XP
        case typeExtended:
                {
-                       writeRegister(getRd(opcode), floatx80_to_int32(fpa11->fpreg[Fn].fExtended));
+                       writeRegister(getRd(opcode), floatx80_to_int32(&roundData, fpa11->fpreg[Fn].fExtended));
                }
                break;
 #endif
@@ -143,6 +150,9 @@ unsigned int PerformFIX(const unsigned int opcode)
                return 0;
        }
 
+       if (roundData.exception)
+               float_raise(roundData.exception);
+
        return 1;
 }
 
index 12885f31d34794dde98be059088669efbc250c89..2dfe1ac42ee8916cc2734d22a671a2f3858ce19d 100644 (file)
@@ -116,8 +116,6 @@ fpmodule.c to integrate with the NetBSD kernel (I hope!).
 code to access data in user space in some other source files at the 
 moment (grep for get_user / put_user calls).  --philb]
 
-float_exception_flags is a global variable in SoftFloat.
-
 This function is called by the SoftFloat routines to raise a floating
 point exception.  We check the trap enable byte in the FPSR, and raise
 a SIGFPE exception if necessary.  If not the relevant bits in the 
@@ -129,15 +127,14 @@ void float_raise(signed char flags)
        register unsigned int fpsr, cumulativeTraps;
 
 #ifdef CONFIG_DEBUG_USER
-       printk(KERN_DEBUG
-              "NWFPE: %s[%d] takes exception %08x at %p from %08lx\n",
-              current->comm, current->pid, flags,
-              __builtin_return_address(0), GET_USERREG()->ARM_pc);
+       /* Ignore inexact errors as there are far too many of them to log */
+       if (flags & ~BIT_IXC)
+               printk(KERN_DEBUG
+                      "NWFPE: %s[%d] takes exception %08x at %p from %08lx\n",
+                      current->comm, current->pid, flags,
+                      __builtin_return_address(0), GET_USERREG()->ARM_pc);
 #endif
 
-       /* Keep SoftFloat exception flags up to date.  */
-       float_exception_flags |= flags;
-
        /* Read fpsr and initialize the cumulativeTraps.  */
        fpsr = readFPSR();
        cumulativeTraps = 0;
index 8035f4faafbfa4ce780649808cd0b8bffffdf361..1777e92a88e69c73db5a0fa67438ff8520a9d56a 100644 (file)
@@ -370,20 +370,20 @@ TABLE 5
 #define getRoundingMode(opcode)                ((opcode & MASK_ROUNDING_MODE) >> 5)
 
 #ifdef CONFIG_FPE_NWFPE_XP
-static inline const floatx80 getExtendedConstant(const unsigned int nIndex)
+static inline __attribute_pure__ floatx80 getExtendedConstant(const unsigned int nIndex)
 {
        extern const floatx80 floatx80Constant[];
        return floatx80Constant[nIndex];
 }
 #endif
 
-static inline const float64 getDoubleConstant(const unsigned int nIndex)
+static inline __attribute_pure__ float64 getDoubleConstant(const unsigned int nIndex)
 {
        extern const float64 float64Constant[];
        return float64Constant[nIndex];
 }
 
-static inline const float32 getSingleConstant(const unsigned int nIndex)
+static inline __attribute_pure__ float32 getSingleConstant(const unsigned int nIndex)
 {
        extern const float32 float32Constant[];
        return float32Constant[nIndex];
index 705808e88d9d3041a02b3cb3b86988d810bd02bb..c66981d682cfe89d9bbfb01c8d71a0db20938be5 100644 (file)
@@ -36,17 +36,17 @@ float32 float32_arccos(float32 rFm);
 float32 float32_pow(float32 rFn, float32 rFm);
 float32 float32_pol(float32 rFn, float32 rFm);
 
-static float32 float32_rsf(float32 rFn, float32 rFm)
+static float32 float32_rsf(struct roundingData *roundData, float32 rFn, float32 rFm)
 {
-       return float32_sub(rFm, rFn);
+       return float32_sub(roundData, rFm, rFn);
 }
 
-static float32 float32_rdv(float32 rFn, float32 rFm)
+static float32 float32_rdv(struct roundingData *roundData, float32 rFn, float32 rFm)
 {
-       return float32_div(rFm, rFn);
+       return float32_div(roundData, rFm, rFn);
 }
 
-static float32 (*const dyadic_single[16])(float32 rFn, float32 rFm) = {
+static float32 (*const dyadic_single[16])(struct roundingData *, float32 rFn, float32 rFm) = {
        [ADF_CODE >> 20] = float32_add,
        [MUF_CODE >> 20] = float32_mul,
        [SUF_CODE >> 20] = float32_sub,
@@ -60,22 +60,22 @@ static float32 (*const dyadic_single[16])(float32 rFn, float32 rFm) = {
        [FRD_CODE >> 20] = float32_rdv,
 };
 
-static float32 float32_mvf(float32 rFm)
+static float32 float32_mvf(struct roundingData *roundData, float32 rFm)
 {
        return rFm;
 }
 
-static float32 float32_mnf(float32 rFm)
+static float32 float32_mnf(struct roundingData *roundData, float32 rFm)
 {
        return rFm ^ 0x80000000;
 }
 
-static float32 float32_abs(float32 rFm)
+static float32 float32_abs(struct roundingData *roundData, float32 rFm)
 {
        return rFm & 0x7fffffff;
 }
 
-static float32 (*const monadic_single[16])(float32 rFm) = {
+static float32 (*const monadic_single[16])(struct roundingData*, float32 rFm) = {
        [MVF_CODE >> 20] = float32_mvf,
        [MNF_CODE >> 20] = float32_mnf,
        [ABS_CODE >> 20] = float32_abs,
@@ -85,7 +85,7 @@ static float32 (*const monadic_single[16])(float32 rFm) = {
        [NRM_CODE >> 20] = float32_mvf,
 };
 
-unsigned int SingleCPDO(const unsigned int opcode, FPREG * rFd)
+unsigned int SingleCPDO(struct roundingData *roundData, const unsigned int opcode, FPREG * rFd)
 {
        FPA11 *fpa11 = GET_FPA11();
        float32 rFm;
@@ -108,13 +108,13 @@ unsigned int SingleCPDO(const unsigned int opcode, FPREG * rFd)
                if (fpa11->fType[Fn] == typeSingle &&
                    dyadic_single[opc_mask_shift]) {
                        rFn = fpa11->fpreg[Fn].fSingle;
-                       rFd->fSingle = dyadic_single[opc_mask_shift](rFn, rFm);
+                       rFd->fSingle = dyadic_single[opc_mask_shift](roundData, rFn, rFm);
                } else {
                        return 0;
                }
        } else {
                if (monadic_single[opc_mask_shift]) {
-                       rFd->fSingle = monadic_single[opc_mask_shift](rFm);
+                       rFd->fSingle = monadic_single[opc_mask_shift](roundData, rFm);
                } else {
                        return 0;
                }
index e038dd3be9b3c63e019a5be3f77de94f25f4c949..f9f049132a17bffb920acb8df278f5e91b514f7a 100644 (file)
@@ -34,16 +34,6 @@ this code that are retained.
 //#include "milieu.h"
 //#include "softfloat.h"
 
-/*
--------------------------------------------------------------------------------
-Floating-point rounding mode, extended double-precision rounding precision,
-and exception flags.
--------------------------------------------------------------------------------
-*/
-int8 float_rounding_mode = float_round_nearest_even;
-int8 floatx80_rounding_precision = 80;
-int8 float_exception_flags;
-
 /*
 -------------------------------------------------------------------------------
 Primitive arithmetic functions, including multi-word arithmetic, and
@@ -77,14 +67,14 @@ input is too large, however, the invalid exception is raised and the largest
 positive or negative integer is returned.
 -------------------------------------------------------------------------------
 */
-static int32 roundAndPackInt32( flag zSign, bits64 absZ )
+static int32 roundAndPackInt32( struct roundingData *roundData, flag zSign, bits64 absZ )
 {
     int8 roundingMode;
     flag roundNearestEven;
     int8 roundIncrement, roundBits;
     int32 z;
 
-    roundingMode = float_rounding_mode;
+    roundingMode = roundData->mode;
     roundNearestEven = ( roundingMode == float_round_nearest_even );
     roundIncrement = 0x40;
     if ( ! roundNearestEven ) {
@@ -107,10 +97,10 @@ static int32 roundAndPackInt32( flag zSign, bits64 absZ )
     z = absZ;
     if ( zSign ) z = - z;
     if ( ( absZ>>32 ) || ( z && ( ( z < 0 ) ^ zSign ) ) ) {
-        float_exception_flags |= float_flag_invalid;
+        roundData->exception |= float_flag_invalid;
         return zSign ? 0x80000000 : 0x7FFFFFFF;
     }
-    if ( roundBits ) float_exception_flags |= float_flag_inexact;
+    if ( roundBits ) roundData->exception |= float_flag_inexact;
     return z;
 
 }
@@ -224,14 +214,14 @@ The handling of underflow and overflow follows the IEC/IEEE Standard for
 Binary Floating-point Arithmetic.
 -------------------------------------------------------------------------------
 */
-static float32 roundAndPackFloat32( flag zSign, int16 zExp, bits32 zSig )
+static float32 roundAndPackFloat32( struct roundingData *roundData, flag zSign, int16 zExp, bits32 zSig )
 {
     int8 roundingMode;
     flag roundNearestEven;
     int8 roundIncrement, roundBits;
     flag isTiny;
 
-    roundingMode = float_rounding_mode;
+    roundingMode = roundData->mode;
     roundNearestEven = ( roundingMode == float_round_nearest_even );
     roundIncrement = 0x40;
     if ( ! roundNearestEven ) {
@@ -254,7 +244,7 @@ static float32 roundAndPackFloat32( flag zSign, int16 zExp, bits32 zSig )
              || (    ( zExp == 0xFD )
                   && ( (sbits32) ( zSig + roundIncrement ) < 0 ) )
            ) {
-            float_raise( float_flag_overflow | float_flag_inexact );
+            roundData->exception |= float_flag_overflow | float_flag_inexact;
             return packFloat32( zSign, 0xFF, 0 ) - ( roundIncrement == 0 );
         }
         if ( zExp < 0 ) {
@@ -265,10 +255,10 @@ static float32 roundAndPackFloat32( flag zSign, int16 zExp, bits32 zSig )
             shift32RightJamming( zSig, - zExp, &zSig );
             zExp = 0;
             roundBits = zSig & 0x7F;
-            if ( isTiny && roundBits ) float_raise( float_flag_underflow );
+            if ( isTiny && roundBits ) roundData->exception |= float_flag_underflow;
         }
     }
-    if ( roundBits ) float_exception_flags |= float_flag_inexact;
+    if ( roundBits ) roundData->exception |= float_flag_inexact;
     zSig = ( zSig + roundIncrement )>>7;
     zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven );
     if ( zSig == 0 ) zExp = 0;
@@ -287,12 +277,12 @@ point exponent.
 -------------------------------------------------------------------------------
 */
 static float32
- normalizeRoundAndPackFloat32( flag zSign, int16 zExp, bits32 zSig )
+ normalizeRoundAndPackFloat32( struct roundingData *roundData, flag zSign, int16 zExp, bits32 zSig )
 {
     int8 shiftCount;
 
     shiftCount = countLeadingZeros32( zSig ) - 1;
-    return roundAndPackFloat32( zSign, zExp - shiftCount, zSig<<shiftCount );
+    return roundAndPackFloat32( roundData, zSign, zExp - shiftCount, zSig<<shiftCount );
 
 }
 
@@ -395,14 +385,14 @@ The handling of underflow and overflow follows the IEC/IEEE Standard for
 Binary Floating-point Arithmetic.
 -------------------------------------------------------------------------------
 */
-static float64 roundAndPackFloat64( flag zSign, int16 zExp, bits64 zSig )
+static float64 roundAndPackFloat64( struct roundingData *roundData, flag zSign, int16 zExp, bits64 zSig )
 {
     int8 roundingMode;
     flag roundNearestEven;
     int16 roundIncrement, roundBits;
     flag isTiny;
 
-    roundingMode = float_rounding_mode;
+    roundingMode = roundData->mode;
     roundNearestEven = ( roundingMode == float_round_nearest_even );
     roundIncrement = 0x200;
     if ( ! roundNearestEven ) {
@@ -427,7 +417,7 @@ static float64 roundAndPackFloat64( flag zSign, int16 zExp, bits64 zSig )
            ) {
             //register int lr = __builtin_return_address(0);
             //printk("roundAndPackFloat64 called from 0x%08x\n",lr);
-            float_raise( float_flag_overflow | float_flag_inexact );
+            roundData->exception |= float_flag_overflow | float_flag_inexact;
             return packFloat64( zSign, 0x7FF, 0 ) - ( roundIncrement == 0 );
         }
         if ( zExp < 0 ) {
@@ -438,10 +428,10 @@ static float64 roundAndPackFloat64( flag zSign, int16 zExp, bits64 zSig )
             shift64RightJamming( zSig, - zExp, &zSig );
             zExp = 0;
             roundBits = zSig & 0x3FF;
-            if ( isTiny && roundBits ) float_raise( float_flag_underflow );
+            if ( isTiny && roundBits ) roundData->exception |= float_flag_underflow;
         }
     }
-    if ( roundBits ) float_exception_flags |= float_flag_inexact;
+    if ( roundBits ) roundData->exception |= float_flag_inexact;
     zSig = ( zSig + roundIncrement )>>10;
     zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven );
     if ( zSig == 0 ) zExp = 0;
@@ -460,12 +450,12 @@ point exponent.
 -------------------------------------------------------------------------------
 */
 static float64
- normalizeRoundAndPackFloat64( flag zSign, int16 zExp, bits64 zSig )
+ normalizeRoundAndPackFloat64( struct roundingData *roundData, flag zSign, int16 zExp, bits64 zSig )
 {
     int8 shiftCount;
 
     shiftCount = countLeadingZeros64( zSig ) - 1;
-    return roundAndPackFloat64( zSign, zExp - shiftCount, zSig<<shiftCount );
+    return roundAndPackFloat64( roundData, zSign, zExp - shiftCount, zSig<<shiftCount );
 
 }
 
@@ -572,14 +562,15 @@ Floating-point Arithmetic.
 */
 static floatx80
  roundAndPackFloatx80(
-     int8 roundingPrecision, flag zSign, int32 zExp, bits64 zSig0, bits64 zSig1
+     struct roundingData *roundData, flag zSign, int32 zExp, bits64 zSig0, bits64 zSig1
  )
 {
-    int8 roundingMode;
+    int8 roundingMode, roundingPrecision;
     flag roundNearestEven, increment, isTiny;
     int64 roundIncrement, roundMask, roundBits;
 
-    roundingMod