diff options
Diffstat (limited to 'Documentation')
83 files changed, 1379 insertions, 1106 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 02457ec..f08ca95 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -104,8 +104,6 @@ firmware_class/ - request_firmware() hotplug interface info. floppy.txt - notes and driver options for the floppy disk driver. -ftape.txt - - notes about the floppy tape device driver. hayes-esp.txt - info on using the Hayes ESP serial driver. highuid.txt diff --git a/Documentation/Changes b/Documentation/Changes index abee7f5..73a8617 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -201,7 +201,7 @@ udev ---- udev is a userspace application for populating /dev dynamically with only entries for devices actually present. udev replaces the basic -functionality of devfs, while allowing persistant device naming for +functionality of devfs, while allowing persistent device naming for devices. FUSE diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 2ffb0d6..0543162 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -489,7 +489,7 @@ size is the size of the area (must be multiples of PAGE_SIZE). flags can be or'd together and are DMA_MEMORY_MAP - request that the memory returned from -dma_alloc_coherent() be directly writeable. +dma_alloc_coherent() be directly writable. DMA_MEMORY_IO - request that the memory returned from dma_alloc_coherent() be addressable using read/write/memcpy_toio etc. diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt index 705f6be..e767805 100644 --- a/Documentation/DMA-ISA-LPC.txt +++ b/Documentation/DMA-ISA-LPC.txt @@ -110,7 +110,7 @@ lock. Once the DMA transfer is finished (or timed out) you should disable the channel again. You should also check get_dma_residue() to make -sure that all data has been transfered. +sure that all data has been transferred. Example: diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl index 07cd34c..d4188d4 100644 --- a/Documentation/DocBook/writing_usb_driver.tmpl +++ b/Documentation/DocBook/writing_usb_driver.tmpl @@ -345,8 +345,7 @@ static inline void skel_delete (struct usb_skel *dev) usb_buffer_free (dev->udev, dev->bulk_out_size, dev->bulk_out_buffer, dev->write_urb->transfer_dma); - if (dev->write_urb != NULL) - usb_free_urb (dev->write_urb); + usb_free_urb (dev->write_urb); kfree (dev); } </programlisting> diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt index 5c34910..d389388 100644 --- a/Documentation/MSI-HOWTO.txt +++ b/Documentation/MSI-HOWTO.txt @@ -219,7 +219,7 @@ into the field vector of each element contained in a second argument. Note that the pre-assigned IOAPIC dev->irq is valid only if the device operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at using dev->irq by the device driver to request for interrupt service -may result unpredictabe behavior. +may result in unpredictable behavior. For each MSI-X vector granted, a device driver is responsible for calling other functions like request_irq(), enable_irq(), etc. to enable diff --git a/Documentation/accounting/taskstats.txt b/Documentation/accounting/taskstats.txt index 92ebf29..ff06b73 100644 --- a/Documentation/accounting/taskstats.txt +++ b/Documentation/accounting/taskstats.txt @@ -96,9 +96,9 @@ a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates a pid/tgid will be followed by some stats. b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats -is being returned. +are being returned. -c) TASKSTATS_TYPE_STATS: attribute with a struct taskstsats as payload. The +c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The same structure is used for both per-pid and per-tgid stats. 3. New message sent by kernel whenever a task exits. The payload consists of a @@ -122,12 +122,12 @@ of atomicity). However, maintaining per-process, in addition to per-task stats, within the kernel has space and time overheads. To address this, the taskstats code -accumalates each exiting task's statistics into a process-wide data structure. -When the last task of a process exits, the process level data accumalated also +accumulates each exiting task's statistics into a process-wide data structure. +When the last task of a process exits, the process level data accumulated also gets sent to userspace (along with the per-task data). When a user queries to get per-tgid data, the sum of all other live threads in -the group is added up and added to the accumalated total for previously exited +the group is added up and added to the accumulated total for previously exited threads of the same thread group. Extending taskstats diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 34bf8f6..c6c9a9c 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -183,7 +183,7 @@ it, the pci dma mapping routines and associated data structures have now been modified to accomplish a direct page -> bus translation, without requiring a virtual address mapping (unlike the earlier scheme of virtual address -> bus translation). So this works uniformly for high-memory pages (which -do not have a correponding kernel virtual address space mapping) and +do not have a corresponding kernel virtual address space mapping) and low-memory pages. Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA @@ -391,7 +391,7 @@ forced such requests to be broken up into small chunks before being passed on to the generic block layer, only to be merged by the i/o scheduler when the underlying device was capable of handling the i/o in one shot. Also, using the buffer head as an i/o structure for i/os that didn't originate -from the buffer cache unecessarily added to the weight of the descriptors +from the buffer cache unnecessarily added to the weight of the descriptors which were generated for each such chunk. The following were some of the goals and expectations considered in the @@ -403,14 +403,14 @@ i. Should be appropriate as a descriptor for both raw and buffered i/o - for raw i/o. ii. Ability to represent high-memory buffers (which do not have a virtual address mapping in kernel address space). -iii.Ability to represent large i/os w/o unecessarily breaking them up (i.e +iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e greater than PAGE_SIZE chunks in one shot) iv. At the same time, ability to retain independent identity of i/os from different sources or i/o units requiring individual completion (e.g. for latency reasons) v. Ability to represent an i/o involving multiple physical memory segments (including non-page aligned page fragments, as specified via readv/writev) - without unecessarily breaking it up, if the underlying device is capable of + without unnecessarily breaking it up, if the underlying device is capable of handling it. vi. Preferably should be based on a memory descriptor structure that can be passed around different types of subsystems or layers, maybe even @@ -1013,7 +1013,7 @@ Characteristics: i. Binary tree AS and deadline i/o schedulers use red black binary trees for disk position sorting and searching, and a fifo linked list for time-based searching. This -gives good scalability and good availablility of information. Requests are +gives good scalability and good availability of information. Requests are almost always dispatched in disk sort order, so a cache is kept of the next request in sort order to prevent binary tree lookups. diff --git a/Documentation/cpu-freq/cpufreq-nforce2.txt b/Documentation/cpu-freq/cpufreq-nforce2.txt index 9188337..babce13 100644 --- a/Documentation/cpu-freq/cpufreq-nforce2.txt +++ b/Documentation/cpu-freq/cpufreq-nforce2.txt @@ -1,7 +1,7 @@ -The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms. +The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms. -This works better than on other plattforms, because the FSB of the CPU +This works better than on other platforms, because the FSB of the CPU can be controlled independently from the PCI/AGP clock. The module has two options: diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 4868c34f..cc60d29 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -54,8 +54,8 @@ additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT to determine the number of potentially hot-pluggable cpus. The implementation -should only rely on this to count the #of cpus, but *MUST* not rely on the -apicid values in those tables for disabled apics. In the event BIOS doesnt +should only rely on this to count the # of cpus, but *MUST* not rely on the +apicid values in those tables for disabled apics. In the event BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could use this parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map. diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 28c4f79..70690f1 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -92,7 +92,7 @@ Your cooperation is appreciated. 7 = /dev/full Returns ENOSPC on write 8 = /dev/random Nondeterministic random number gen. 9 = /dev/urandom Faster, less secure random number gen. - 10 = /dev/aio Asyncronous I/O notification interface + 10 = /dev/aio Asynchronous I/O notification interface 11 = /dev/kmsg Writes to this come out as printk's 1 block RAM disk 0 = /dev/ram0 First RAM disk @@ -1093,7 +1093,7 @@ Your cooperation is appreciated. 55 char DSP56001 digital signal processor 0 = /dev/dsp56k First DSP56001 - 55 block Mylex DAC960 PCI RAID controller; eigth controller + 55 block Mylex DAC960 PCI RAID controller; eighth controller 0 = /dev/rd/c7d0 First disk, whole disk 8 = /dev/rd/c7d1 Second disk, whole disk ... @@ -1456,7 +1456,7 @@ Your cooperation is appreciated. 1 = /dev/cum1 Callout device for ttyM1 ... - 79 block Compaq Intelligent Drive Array, eigth controller + 79 block Compaq Intelligent Drive Array, eighth controller 0 = /dev/ida/c7d0 First logical drive whole disk 16 = /dev/ida/c7d1 Second logical drive whole disk ... @@ -1900,7 +1900,7 @@ Your cooperation is appreciated. 1 = /dev/av1 Second A/V card ... -111 block Compaq Next Generation Drive Array, eigth controller +111 block Compaq Next Generation Drive Array, eighth controller 0 = /dev/cciss/c7d0 First logical drive, whole disk 16 = /dev/cciss/c7d1 Second logical drive, whole disk ... diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt index 5eee3e0..9f0bc3b 100644 --- a/Documentation/driver-model/platform.txt +++ b/Documentation/driver-model/platform.txt @@ -1,99 +1,131 @@ Platform Devices and Drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See <linux/platform_device.h> for the driver model interface to the +platform bus: platform_device, and platform_driver. This pseudo-bus +is used to connect devices on busses with minimal infrastructure, +like those used to integrate peripherals on many system-on-chip +processors, or some "legacy" PC interconnects; as opposed to large +formally specified ones like PCI or USB. + Platform devices ~~~~~~~~~~~~~~~~ Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and -host bridges to peripheral buses. - - -Platform drivers -~~~~~~~~~~~~~~~~ -Drivers for platform devices are typically very simple and -unstructured. Either the device was present at a particular I/O port -and the driver was loaded, or it was not. There was no possibility -of hotplugging or alternative discovery besides probing at a specific -I/O address and expecting a specific response. +host bridges to peripheral buses, and most controllers integrated +into system-on-chip platforms. What they usually have in common +is direct addressing from a CPU bus. Rarely, a platform_device will +be connected through a segment of some other kind of bus; but its +registers will still be directly addressible. +Platform devices are given a name, used in driver binding, and a +list of resources such as addresses and IRQs. -Other Architectures, Modern Firmware, and new Platforms -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -These devices are not always at the legacy I/O ports. This is true on -other architectures and on some modern architectures. In most cases, -the drivers are modified to discover the devices at other well-known -ports for the given platform. However, the firmware in these systems -does usually know where exactly these devices reside, and in some -cases, it's the only way of discovering them. +struct platform_device { + const char *name; + u32 id; + struct device dev; + u32 num_resources; + struct resource *resource; +}; -The Platform Bus -~~~~~~~~~~~~~~~~ -A platform bus has been created to deal with these issues. First and -foremost, it groups all the legacy devices under a common bus, and -gives them a common parent if they don't already have one. - -But, besides the organizational benefits, the platform bus can also -accommodate firmware-based enumeration. - - -Device Discovery +Platform drivers ~~~~~~~~~~~~~~~~ -The platform bus has no concept of probing for devices. Devices -discovery is left up to either the legacy drivers or the -firmware. These entities are expected to notify the platform of -devices that it discovers via the bus's add() callback: - - platform_bus.add(parent,bus_id). - - -Bus IDs -~~~~~~~ -Bus IDs are the canonical names for the devices. There is no globally -standard addressing mechanism for legacy devices. In the IA-32 world, -we have Pnp IDs to use, as well as the legacy I/O ports. However, -neither tell what the device really is or have any meaning on other -platforms. - -Since both PnP IDs and the legacy I/O ports (and other standard I/O -ports for specific devices) have a 1:1 mapping, we map the -platform-specific name or identifier to a generic name (at least -within the scope of the kernel). - -For example, a serial driver might find a device at I/O 0x3f8. The -ACPI firmware might also discover a device with PnP ID (_HID) -PNP0501. Both correspond to the same device and should be mapped to the -canonical name 'serial'. - -The bus_id field should be a concatenation of the canonical name and -the instance of that type of device. For example, the device at I/O -port 0x3f8 should have a bus_id of "serial0". This places the -responsibility of enumerating devices of a particular type up to the -discovery mechanism. But, they are the entity that should know best -(as opposed to the platform bus driver). - - -Drivers -~~~~~~~ -Drivers for platform devices should have a name that is the same as -the canonical name of the devices they support. This allows the -platform bus driver to do simple matching with the basic data -structures to determine if a driver supports a certain device. - -For example, a legacy serial driver should have a name of 'serial' and -register itself with the platform bus. - - -Driver Binding -~~~~~~~~~~~~~~ -Legacy drivers assume they are bound to the device once they start up -and probe an I/O port. Divorcing them from this will be a difficult -process. However, that shouldn't prevent us from implementing -firmware-based enumeration. - -The firmware should notify the platform bus about devices before the -legacy drivers have had a chance to load. Once the drivers are loaded, -they driver model core will attempt to bind the driver to any -previously-discovered devices. Once that has happened, it will be free -to discover any other devices it pleases. +Platform drivers follow the standard driver model convention, where +discovery/enumeration is handled outside the drivers, and drivers +provide probe() and remove() methods. They support power management +and shutdown notifications using the standard conventions. + +struct platform_driver { + int (*probe)(struct platform_device *); + int (*remove)(struct platform_device *); + void (*shutdown)(struct platform_device *); + int (*suspend)(struct platform_device *, pm_message_t state); + int (*suspend_late)(struct platform_device *, pm_message_t state); + int (*resume_early)(struct platform_device *); + int (*resume)(struct platform_device *); + struct device_driver driver; +}; + +Note that probe() should general verify that the specified device hardware +actually exists; sometimes platform setup code can't be sure. The probing +can use device resources, including clocks, and device platform_data. + +Platform drivers register themselves the normal way: + + int platform_driver_register(struct platform_driver *drv); + +Or, in common situations where the device is known not to be hot-pluggable, +the probe() routine can live in an init section to reduce the driver's +runtime memory footprint: + + int platform_driver_probe(struct platform_driver *drv, + int (*probe)(struct platform_device *)) + + +Device Enumeration +~~~~~~~~~~~~~~~~~~ +As a rule, platform specific (and often board-specific) setup code wil +register platform devices: + + int platform_device_register(struct platform_device *pdev); + + int platform_add_devices(struct platform_device **pdevs, int ndev); + +The general rule is to register only those devices that actually exist, +but in some cases extra devices might be registered. For example, a kernel +might be configured to work with an external network adapter that might not +be populated on all boards, or likewise to work with an integrated controller +that some boards might not hook up to any peripherals. + +In some cases, boot firmware will export tables describing the devices +that are populated on a given board. Without such tables, often the +only way for system setup code to set up the correct devices is to build +a kernel for a specific target board. Such board-specific kernels are +common with embedded and custom systems development. + +In many cases, the memory and IRQ resources associated with the platform +device are not enough to let the device's driver work. Board setup code +will often provide additional information using the device's platform_data +field to hold additional information. + +Embedded systems frequently need one or more clocks for platform devices, +which are normally kept off until they're actively needed (to save power). +System setup also associates those clocks with the device, so that that +calls to clk_get(&pdev->dev, clock_name) return them as needed. + + +Device Naming and Driver Binding +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The platform_device.dev.bus_id is the canonical name for the devices. +It's built from two components: + + * platform_device.name ... which is also used to for driver matching. + + * platform_device.id ... the device instance number, or else "-1" + to indicate there's only one. + +These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and +"serial/3" indicates bus_id "serial.3"; both would use the platform_driver +named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id) +and use the platform_driver called "my_rtc". + +Driver binding is performed automatically by the driver core, invoking +driver probe() after finding a match between device and driver. If the +probe() succeeds, the driver and device are bound as usual. There are +three different ways to find such a match: + + - Whenever a device is registered, the drivers for that bus are + checked for matches. Platform devices should be registered very + early during system boot. + + - When a driver is registered using platform_driver_register(), all + unbound devices on that bus are checked for matches. Drivers + usually register later during booting, or by module loading. + + - Registering a driver using platform_driver_probe() works just like + using platform_driver_register(), except that the the driver won't + be probed later if another device registers. (Which is OK, since + this interface is only for use with non-hotpluggable devices.) diff --git a/Documentation/driver-model/porting.txt b/Documentation/driver-model/porting.txt index 98b233c..92d86f7 100644 --- a/Documentation/driver-model/porting.txt +++ b/Documentation/driver-model/porting.txt @@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata describing the relationship the device has to other entities. -- Embedd a struct device in the bus-specific device type. +- Embed a struct device in the bus-specific device type. struct pci_dev { diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt index 531239b..2ecd834 100644 --- a/Documentation/dvb/ci.txt +++ b/Documentation/dvb/ci.txt @@ -71,7 +71,7 @@ eliminating the need for any additional ioctls. The disadvantage is that the driver/hardware has to manage the rest. For the application programmer it would be as simple as sending/receiving an array to/from the CI ioctls as defined in the Linux DVB API. No changes -have been made in the API to accomodate this feature. +have been made in the API to accommodate this feature. * Why the need for another CI interface ? @@ -102,7 +102,7 @@ This CI interface follows the CI high level interface, which is not implemented by most applications. Hence this area is revisited. This CI interface is quite different in the case that it tries to -accomodate all other CI based devices, that fall into the other categories +accommodate all other CI based devices, that fall into the other categories. This means that this CI interface handles the EN50221 style tags in the Application layer only and no session management is taken care of by the diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt index 6a099ed..60e361b 100644 --- a/Documentation/eisa.txt +++ b/Documentation/eisa.txt @@ -62,7 +62,7 @@ res : root device I/O resource bus_base_addr : slot 0 address on this bus slots : max slot number to probe force_probe : Probe even when slot 0 is empty (no EISA mainboard) -dma_mask : Default DMA mask. Usualy the bridge device dma_mask. +dma_mask : Default DMA mask. Usually the bridge device dma_mask. bus_nr : unique bus id, set by eisa_root_register ** Driver : diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d52c4aa..226ecf2 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -70,18 +70,6 @@ Who: Dominik Brodowski <linux@brodo.de> --------------------------- -What: ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue) -When: December 2005 -Why: This interface has been obsoleted by the new layer3-independent - "nfnetlink_queue". The Kernel interface is compatible, so the old - ip[6]tables "QUEUE" targets still work and will transparently handle - all packets into nfnetlink queue number 0. Userspace users will have - to link against API-compatible library on top of libnfnetlink_queue - instead of the current 'libipq'. -Who: Harald Welte <laforge@netfilter.org> - ---------------------------- - What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c @@ -227,21 +215,6 @@ Who: Patrick McHardy <kaber@trash.net> --------------------------- -What: frame diverter -When: November 2006 -Why: The frame diverter is included in most distribution kernels, but is - broken. It does not correctly handle many things: - - IPV6 - - non-linear skb's - - network device RCU on removal - - input frames not correctly checked for protocol errors - It also adds allocation overhead even if not enabled. - It is not clear if anyone is still using it. -Who: Stephen Hemminger <shemminger@osdl.org> - ---------------------------- - - What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment When: October 2008 Why: The stacking of class devices makes these values misleading and @@ -261,10 +234,11 @@ Who: Jean Delvare <khali@linux-fr.org> --------------------------- -What: ftape -When: 2.6.20 -Why: Orphaned for ages. SMP bugs long unfixed. Few users left - in the world. -Who: Jeff Garzik <jeff@garzik.org> +What: IPv4 only connection tracking/NAT/helpers +When: 2.6.22 +Why: The new layer 3 independant connection tracking replaces the old + IPv4 only version. After some stabilization of the new code the + old one will be removed. +Who: Patrick McHardy <kaber@trash.net> --------------------------- diff --git a/Documentation/filesystems/adfs.txt b/Documentation/filesystems/adfs.txt index 060abb0..9e8811f 100644 --- a/Documentation/filesystems/adfs.txt +++ b/Documentation/filesystems/adfs.txt @@ -3,7 +3,7 @@ Mount options for ADFS uid=nnn All files in the partition will be owned by user id nnn. Default 0 (root). - gid=nnn All files in the partition willbe in group + gid=nnn All files in the partition will be in group nnn. Default 0 (root). ownmask=nnn The permission mask for ADFS 'owner' permissions will be nnn. Default 0700. diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index c3a7afb..b34cdb5 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt @@ -209,7 +209,7 @@ will happen for write(2). [struct config_group] -A config_item cannot live in a vaccum. The only way one can be created +A config_item cannot live in a vacuum. The only way one can be created is via mkdir(2) on a config_group. This will trigger creation of a child item. @@ -275,7 +275,7 @@ directory is not empty. [struct configfs_subsystem] -A subsystem must register itself, ususally at module_init time. This +A subsystem must register itself, usually at module_init time. This tells configfs to make the subsystem appear in the file tree. struct configfs_subsystem { diff --git a/Documentation/filesystems/fuse.txt b/Documentation/filesystems/fuse.txt index a584f05..3d74477 100644 --- a/Documentation/filesystems/fuse.txt +++ b/Documentation/filesystems/fuse.txt @@ -111,7 +111,7 @@ For each connection the following files exist within this directory: 'waiting' - The number of requests which are waiting to be transfered to + The number of requests which are waiting to be transferred to userspace or being processed by the filesystem daemon. If there is no filesystem activity and 'waiting' is non-zero, then the filesystem is hung or deadlocked. @@ -136,7 +136,7 @@ following will happen: 2) If the request is not yet sent to userspace AND the signal is not fatal, then an 'interrupted' flag is set for the request. When - the request has been successfully transfered to userspace and + the request has been successfully transferred to userspace and this flag is set, an INTERRUPT request is queued. 3) If the request is already sent to userspace, then an INTERRUPT diff --git a/Documentation/filesystems/hpfs.txt b/Documentation/filesystems/hpfs.txt index 33dc360..38aba03 100644 --- a/Documentation/filesystems/hpfs.txt +++ b/Documentation/filesystems/hpfs.txt @@ -274,7 +274,7 @@ History Fixed race-condition in buffer code - it is in all filesystems in Linux; when reading device (cat /dev/hda) while creating files on it, files could be damaged -2.02 Woraround for bug in breada in Linux. breada could cause accesses beyond +2.02 Workaround for bug in breada in Linux. breada could cause accesses beyond end of partition 2.03 Char, block devices and pipes are correctly created Fixed non-crashing race in unlink (Alexander Viro) diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 35f105b..13ba649 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt @@ -337,7 +337,7 @@ Finally, for a mirrored volume, i.e. raid level 1, the table would look like this (note all values are in 512-byte sectors): --- cut here --- -# Ofs Size Raid Log Number Region Should Number Source Start Taget Start +# Ofs Size Raid Log Number Region Should Number Source Start Target Start # in of the type type of log size sync? of Device in Device in # vol volume params mirrors Device Device 0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0 @@ -599,7 +599,7 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. - Major bug fixes for reading files and volumes in corner cases which were being hit by Windows 2k/XP users. 2.1.2: - - Major bug fixes aleviating the hangs in statfs experienced by some + - Major bug fixes alleviating the hangs in statfs experienced by some users. 2.1.1: - Update handling of compressed files so people no longer get the diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index 4389c68..af6defd 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt @@ -30,7 +30,7 @@ Caveats Features which OCFS2 does not support yet: - sparse files - extended attributes - - shared writeable mmap + - shared writable mmap - loopback is supported, but data written will not be cluster coherent. - quotas diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 3355e69..72af5de 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1220,9 +1220,9 @@ applications are using mlock(), or if you are running with no swap then you probably should increase the lower_zone_protection setting. The units of this tunable are fairly vague. It is approximately equal -to "megabytes". So setting lower_zone_protection=100 will protect around 100 +to "megabytes," so setting lower_zone_protection=100 will protect around 100 megabytes of the lowmem zone from user allocations. It will also make -those 100 megabytes unavaliable for use by applications and by +those 100 megabytes unavailable for use by applications and by pagecache, so there is a cost. The effects of this tunable may be observed by monitoring @@ -1538,10 +1538,10 @@ TCP settings tcp_ecn ------- -This file controls the use of the ECN bit in the IPv4 headers, this is a new +This file controls the use of the ECN bit in the IPv4 headers. This is a new feature about Explicit Congestion Notification, but some routers and firewalls -block trafic that has this bit set, so it could be necessary to echo 0 to -/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info +block traffic that has this bit set, so it could be necessary to echo 0 to +/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info you could read RFC2481. tcp_retrans_collapse diff --git a/Documentation/filesystems/spufs.txt b/Documentation/filesystems/spufs.txt index 982645a..1343d11 100644 --- a/Documentation/filesystems/spufs.txt +++ b/Documentation/filesystems/spufs.txt @@ -210,7 +210,7 @@ FILES /signal2 The two signal notification channels of an SPU. These are read-write files that operate on a 32 bit word. Writing to one of these files - triggers an interrupt on the SPU. The value writting to the signal + triggers an interrupt on the SPU. The value written to the signal files can be read from the SPU through a channel read or from host user space through the file. After the value has been read by the SPU, it is reset to zero. The possible operations on an open signal1 or sig- diff --git a/Documentation/ftape.txt b/Documentation/ftape.txt deleted file mode 100644 index 7d8bb33..0000000 --- a/Documentation/ftape.txt +++ /dev/null @@ -1,307 +0,0 @@ -Intro -===== - -This file describes some issues involved when using the "ftape" -floppy tape device driver that comes with the Linux kernel. - -ftape has a home page at - -http://ftape.dot-heine.de/ - -which contains further information about ftape. Please cross check -this WWW address against the address given (if any) in the MAINTAINERS -file located in the top level directory of the Linux kernel source -tree. - -NOTE: This is an unmaintained set of drivers, and it is not guaranteed to work. -If you are interested in taking over maintenance, contact Claus-Justus Heine -<ch@dot-heine.de>, the former maintainer. - -Contents -======== - -A minus 1: Ftape documentation - -A. Changes - 1. Goal - 2. I/O Block Size - 3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape) - 4. Formatting - 5. Interchanging cartridges with other operating systems - -B. Debugging Output - 1. Introduction - 2. Tuning the debugging output - -C. Boot and load time configuration - 1. Setting boot time parameters - 2. Module load time parameters - 3. Ftape boot- and load time options - 4. Example kernel parameter setting - 5. Example module parameter setting - -D. Support and contacts - -******************************************************************************* - -A minus 1. Ftape documentation -============================== - -Unluckily, the ftape-HOWTO is out of date. This really needs to be -changed. Up to date documentation as well as recent development -versions of ftape and useful links to related topics can be found at -the ftape home page at - -http://ftape.dot-heine.de/ - -******************************************************************************* - -A. Changes -========== - -1. Goal - ~~~~ - The goal of all that incompatibilities was to give ftape an interface - that resembles the interface provided by SCSI tape drives as close - as possible. Thus any Unix backup program that is known to work - with SCSI tape drives should also work. - - The concept of a fixed block size for read/write transfers is - rather unrelated to this SCSI tape compatibility at the file system - interface level. It developed out of a feature of zftape, a - block wise user transparent on-the-fly compression. That compression - support will not be dropped in future releases for compatibility - reasons with previous releases of zftape. - -2. I/O Block Size - ~~~~~~~~~~~~~~ - The block size defaults to 10k which is the default block size of - GNU tar. - - The block size can be tuned either during kernel configuration or - at runtime with the MTIOCTOP ioctl using the MTSETBLK operation - (i.e. do "mt -f /dev/qft0" setblk #BLKSZ). A block size of 0 - switches to variable block size mode i.e. "mt setblk 0" switches - off the block size restriction. However, this disables zftape's - built in on-the-fly compression which doesn't work with variable - block size mode. - - The BLKSZ parameter must be given as a byte count and must be a - multiple of 32k or 0, i.e. use "mt setblk 32768" to switch to a - block size of 32k. - - The typical symptom of a block size mismatch is an "invalid - argument" error message. - -3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape) - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - zftape (the file system interface of ftape-3.x) denies write access - to the tape cartridge when it isn't positioned either at BOT or - EOD. - -4. Formatting - ~~~~~~~~~~ - ftape DOES support formatting of floppy tape cartridges. You need the - `ftformat' program that is shipped with the modules version of ftape. - Please get the latest version of ftape from - - ftp://sunsite.unc.edu/pub/Linux/kernel/tapes - - or from the ftape home page at - - http://ftape.dot-heine.de/ - - `ftformat' is contained in the `./contrib/' subdirectory of that - separate ftape package. - -5. Interchanging cartridges with other operating systems - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - The internal emulation of Unix tape device file marks has changed - completely. ftape now uses the volume table segment as specified - by the QIC-40/80/3010/3020/113 standards to emulate file marks. As - a consequence there is limited support to interchange cartridges - with other operating systems. - - To be more precise: ftape will detect volumes written by other OS's - programs and other OS's programs will detect volumes written by - ftape. - - However, it isn't possible to extract the data dumped to the tape - by some MSDOS program with ftape. This exceeds the scope of a - kernel device driver. If you need such functionality, then go ahead - and write a user space utility that is able to do that. ftape already - provides all kernel level support necessary to do that. - -******************************************************************************* - -B. Debugging Output - ================ - -1. Introduction - ~~~~~~~~~~~~ - The ftape driver can be very noisy in that is can print lots of - debugging messages to the kernel log files and the system console. - While this is useful for debugging it might be annoying during - normal use and enlarges the size of the driver by several kilobytes. - - To reduce the size of the driver you can trim the maximal amount of - debugging information available during kernel configuration. Please - refer to the kernel configuration script and its on-line help - functionality. - - The amount of debugging output maps to the "tracing" boot time - option and the "ft_tracing" modules option as follows: - - 0 bugs - 1 + errors (with call-stack dump) - 2 + warnings - 3 + information - 4 + more information - 5 + program flow - 6 + fdc/dma info - 7 + data flow - 8 + everything else - -2. Tuning the debugging output - ~~~~~~~~~~~~~~~~~~~~~~~~~~~ - To reduce the amount of debugging output printed to the system - console you can - - i) trim the debugging output at run-time with - - mt -f /dev/nqft0 setdensity #DBGLVL - - where "#DBGLVL" is a number between 0 and 9 - - ii) trim the debugging output at module load time with - - modprobe ftape ft_tracing=#DBGLVL - - Of course, this applies only if you have configured ftape to be - compiled as a module. - - iii) trim the debugging output during system boot time. Add the - following to the kernel command line: - - ftape=#DBGLVL,tracing - - Please refer also to the next section if you don't know how to - set boot time parameters. - -******************************************************************************* - -C. Boot and load time configuration - ================================ - -1. Setting boot time parameters - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Assuming that you use lilo, the LI)nux LO)ader, boot time kernel - parameters can be set by adding a line - - append some_kernel_boot_time_parameter - - to `/etc/lilo.conf' or at real boot time by typing in the options - at the prompt provided by LILO. I can't give you advice on how to - specify those parameters with other loaders as I don't use them. - - For ftape, each "some_kernel_boot_time_parameter" looks like - "ftape=value,option". As an example, the debugging output can be - increased with - - ftape=4,tracing - - NOTE: the value precedes the option name. - -2. Module load time parameters - ~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Module parameters can be specified either directly when invoking - the program 'modprobe' at the shell prompt: - - modprobe ftape ft_tracing=4 - - or by editing the file `/etc/modprobe.conf' in which case they take - effect each time when the module is loaded with `modprobe' (please - refer to the respective manual pages). Thus, you should add a line - - options ftape ft_tracing=4 - - to `/etc/modprobe.conf` if you intend to increase the debugging - output of the driver. - - -3. Ftape boot- and load time options - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - i. Controlling the amount of debugging output - DBGLVL has to be replaced by a number between 0 and 8. - - module | kernel command line - -----------------------|---------------------- - ft_tracing=DBGLVL | ftape=DBGLVL,tracing - - ii. Hardware setup - BASE is the base address of your floppy disk controller, - IRQ and DMA give its interrupt and DMA channel, respectively. - BOOL is an integer, "0" means "no"; any other value means - "yes". You don't need to specify anything if connecting your tape - drive to the standard floppy disk controller. All of these - values have reasonable defaults. The defaults can be modified - during kernel configuration, i.e. while running "make config", - "make menuconfig" or "make xconfig" in the top level directory - of the Linux kernel source tree. Please refer also to the on - line documentation provided during that kernel configuration - process. - - ft_probe_fc10 is set to a non-zero value if you wish for ftape to - probe for a Colorado FC-10 or FC-20 controller. - - ft_mach2 is set to a non-zero value if you wish for ftape to probe - for a Mountain MACH-2 controller. - - module | kernel command line - -----------------------|---------------------- - ft_fdc_base=BASE | ftape=BASE,ioport - ft_fdc_irq=IRQ | ftape=IRQ,irq - ft_fdc_dma=DMA | ftape=DMA,dma - ft_probe_fc10=BOOL | ftape=BOOL,fc10 - ft_mach2=BOOL | ftape=BOOL,mach2 - ft_fdc_threshold=THR | ftape=THR,threshold - ft_fdc_rate_limit=RATE | ftape=RATE,datarate - -4. Example kernel parameter setting - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - To configure ftape to probe for a Colorado FC-10/FC-20 controller - and to increase the amount of debugging output a little bit, add - the following line to `/etc/lilo.conf': - - append ftape=1,fc10 ftape=4,tracing - -5. Example module parameter setting - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - To do the same, but with ftape compiled as a loadable kernel - module, add the following line to `/etc/modprobe.conf': - - options ftape ft_probe_fc10=1 ft_tracing=4 - -******************************************************************************* - -D. Support and contacts - ==================== - - Ftape is distributed under the GNU General Public License. There is - absolutely no warranty for this software. However, you can reach - the current maintainer of the ftape package under the email address - given in the MAINTAINERS file which is located in the top level - directory of the Linux kernel source tree. There you'll find also - the relevant mailing list to use as a discussion forum and the web - page to query for the most recent documentation, related work and - development versions of ftape. - - Changelog: - ========== - -~1996: Original Document - -10-24-2004: General cleanup and updating, noting additional module options. - James Nelson <james4765@gmail.com> diff --git a/Documentation/fujitsu/frv/gdbstub.txt b/Documentation/fujitsu/frv/gdbstub.txt index 6ce5aa9..9304fb3 100644 --- a/Documentation/fujitsu/frv/gdbstub.txt +++ b/Documentation/fujitsu/frv/gdbstub.txt @@ -59,7 +59,7 @@ the following things on the "Kernel Hacking" tab: Then build as usual, download to the board and execute. Note that if "Immediate activation" was selected, then the kernel will wait for GDB to attach. If not, then the kernel will boot immediately and GDB will have to -interupt it or wait for an exception to occur if before doing anything with +interrupt it or wait for an exception to occur before doing anything with the kernel. diff --git a/Documentation/fujitsu/frv/kernel-ABI.txt b/Documentation/fujitsu/frv/kernel-ABI.txt index 8b0a5fc..aaa1cec 100644 --- a/Documentation/fujitsu/frv/kernel-ABI.txt +++ b/Documentation/fujitsu/frv/kernel-ABI.txt @@ -156,7 +156,7 @@ with the main kernel in this regard. Hence the debug mode code (gdbstub) is almost completely self-contained. The only external code used is the sprintf family of functions. -Futhermore, break.S is so complicated because single-step mode does not +Furthermore, break.S is so complicated because single-step mode does not switch off on entry to an exception. That means unless manually disabled, single-stepping will blithely go on stepping into things like interrupts. See gdbstub.txt for more information. diff --git a/Documentation/ide.txt b/Documentation/ide.txt index 0bf38ba..786c3a7 100644 --- a/Documentation/ide.txt +++ b/Documentation/ide.txt @@ -390,5 +390,5 @@ mlord@pobox.com Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current maintainer. -Wed Aug 20 22:31:29 CEST 2003 updated ide boot uptions to current ide.c +Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv> diff --git a/Documentation/input/amijoy.txt b/Documentation/input/amijoy.txt index 4f0e89d..7dc4f17 100644 --- a/Documentation/input/amijoy.txt +++ b/Documentation/input/amijoy.txt @@ -91,8 +91,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 | 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) | | 2 | M0V | JOY0DAT Vertical Clock | | 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) | - | 4 | M1V | JOY1DAT Horizontall Clock | - | 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) | + | 4 | M1V | JOY1DAT Horizontal Clock | + | 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) | | 6 | M1V | JOY1DAT Vertical Clock | | 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) | +--------+----------+-----------------------------------------+ diff --git a/Documentation/input/atarikbd.txt b/Documentation/input/atarikbd.txt index 1e7e585..668f4d0 100644 --- a/Documentation/input/atarikbd.txt +++ b/Documentation/input/atarikbd.txt @@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75). 5.1 Joystick Event Reporting -In this mode, the ikbd generates a record whever the joystick position is +In this mode, the ikbd generates a record whenever the joystick position is changed (i.e. for each opening or closing of a joystick switch or trigger). The joystick event record is two bytes of the form: @@ -277,8 +277,8 @@ default to 1 at RESET (or power-up). 9.7 SET MOUSE SCALE 0x0C - X ; horizontal mouse ticks per internel X - Y ; vertical mouse ticks per internel Y + X ; horizontal mouse ticks per internal X + Y ; vertical mouse ticks per internal Y This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode. In this mode, the specified number of mouse phase changes ('clicks') must @@ -323,7 +323,7 @@ mouse position. 0x0F This command makes the origin of the Y axis to be at the bottom of the -logical coordinate system internel to the ikbd for all relative or absolute +logical coordinate system internal to the ikbd for all relative or absolute mouse motion. This causes mouse motion toward the user to be negative in sign and away from the user to be positive. @@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode. 10. SCAN CODES -The key scan codes return by the ikbd are chosen to simplify the -implementaion of GSX. +The key scan codes returned by the ikbd are chosen to simplify the +implementation of GSX. GSX Standard Keyboard Mapping. diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt index 0a8c97e..5360e43 100644 --- a/Documentation/input/yealink.txt +++ b/Documentation/input/yealink.txt @@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value: 888888888888 Linux Rocks! -Writing to /sys/../lineX will set the coresponding LCD line. +Writing to /sys/../lineX will set the corresponding LCD line. - Excess characters are ignored. - If less characters are written than allowed, the remaining digits are unchanged. diff --git a/Documentation/ioctl/cdrom.txt b/Documentation/ioctl/cdrom.txt index 8ec32cc..62d4af4 100644 --- a/Documentation/ioctl/cdrom.txt +++ b/Documentation/ioctl/cdrom.txt @@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc. Ok, this is where problems start. The current interface for the CDROM_DISC_STATUS ioctl is flawed. It makes the false assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc. - Unfortunatly, while this is often the case, it is also + Unfortunately, while this is often the case, it is also very common for CDs to have some tracks with data, and some tracks with audio. Just because I feel like it, I declare the following to be the best way to cope. If the CD has diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 50f4edd..4b3d671 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -227,9 +227,9 @@ more details, with real examples. be included in a library, lib.a. All objects listed with lib-y are combined in a single library for that directory. - Objects that are listed in obj-y and additionaly listed in - lib-y will not be included in the library, since they will anyway - be accessible. + Objects that are listed in obj-y and additionally listed in + lib-y will not be included in the library, since they will + be accessible anyway. For consistency, objects listed in lib-m will be included in lib.a. Note that the same kbuild makefile may list files to be built-in @@ -535,7 +535,7 @@ Both possibilities are described in the following. Host programs can be made up based on composite objects. The syntax used to define composite objects for host programs is similar to the syntax used for kernel objects. - $(<executeable>-objs) lists all objects used to link the final + $(<executable>-objs) lists all objects used to link the final executable. Example: @@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly): In this example, there are two possible targets, requiring different options to the linker. The linker options are specified using the LDFLAGS_$@ syntax - one for each potential target. - $(targets) are assinged all potential targets, by which kbuild knows + $(targets) are assigned all potential targets, by which kbuild knows the targets and will: 1) check for commandline changes 2) delete target during make clean diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6747384..15e4fed 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -557,9 +557,6 @@ and is between 256 and 4096 characters. It is defined in the file floppy= [HW] See Documentation/floppy.txt. - ftape= [HW] Floppy Tape subsystem debugging options. - See Documentation/ftape.txt. - gamecon.map[2|3]= [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) diff --git a/Documentation/keys.txt b/Documentation/keys.txt index 3da586b..60c665d 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt @@ -304,7 +304,7 @@ about the status of the key service: R Revoked D Dead Q Contributes to user's quota - U Under contruction by callback to userspace + U Under construction by callback to userspace N Negative key This file must be enabled at kernel configuration time as it allows anyone diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt index c487186..6f639e3 100644 --- a/Documentation/laptop-mode.txt +++ b/Documentation/laptop-mode.txt @@ -121,7 +121,7 @@ contains the following options: MAX_AGE: Maximum time, in seconds, of hard drive spindown time that you are -confortable with. Worst case, it's possible that you could lose this +comfortable with. Worst case, it's possible that you could lose this amount of work if your battery fails while you're in laptop mode. MINIMUM_BATTERY_MINUTES: @@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as --------------------CONFIG FILE BEGIN------------------------------------------- # Maximum time, in seconds, of hard drive spindown time that you are -# confortable with. Worst case, it's possible that you could lose this +# comfortable with. Worst case, it's possible that you could lose this # amount of work if your battery fails you while in laptop mode. #MAX_AGE=600 @@ -350,7 +350,7 @@ fi # set defaults instead: # Maximum time, in seconds, of hard drive spindown time that you are -# confortable with. Worst case, it's possible that you could lose this +# comfortable with. Worst case, it's possible that you could lose this # amount of work if your battery fails you while in laptop mode. MAX_AGE=${MAX_AGE:-'600'} @@ -699,7 +699,7 @@ ACPI integration Dax Kelson submitted this so that the ACPI acpid daemon will kick off the laptop_mode script and run hdparm. The part that automatically disables laptop mode when the battery is low was -writen by Jan Topinski. +written by Jan Topinski. -----------------/etc/acpi/events/ac_adapter BEGIN------------------------------ event=ac_adapter diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 7751704..58408dd 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU: STORE *X = c, d = LOAD *X - (Loads and stores overlap if they are targetted at overlapping pieces of + (Loads and stores overlap if they are targeted at overlapping pieces of memory). And there are a number of things that _must_ or _must_not_ be assumed: diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt index 93af3e8..fb8dc64 100644 --- a/Documentation/networking/NAPI_HOWTO.txt +++ b/Documentation/networking/NAPI_HOWTO.txt @@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms. Move all to dev->poll() C) Ability to detect new work correctly. -NAPI works by shutting down event interrupts when theres work and -turning them on when theres none. +NAPI works by shutting down event interrupts when there's work and +turning them on when there's none. New packets might show up in the small window while interrupts were being re-enabled (refer to appendix 2). A packet might sneak in during the period we are enabling interrupts. We only get to know about such a packet when the @@ -114,7 +114,7 @@ Locking rules and environmental guarantees only one CPU can pick the initial interrupt and hence the initial netif_rx_schedule(dev); - The core layer invokes devices to send packets in a round robin format. -This implies receive is totaly lockless because of the guarantee only that +This implies receive is totally lockless because of the guarantee that only one CPU is executing it. - contention can only be the result of some other CPU accessing the rx ring. This happens only in close() and suspend() (when these methods @@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget) an interrupt will be generated */ goto done; } - /* done! at least thats what it looks like ;-> + /* done! at least that's what it looks like ;-> if new packets came in after our last check on status bits they'll be caught by the while check and we go back and clear them since we havent exceeded our quota */ @@ -535,11 +535,11 @@ done: * 1. it can race with disabling irqs in irq handler (which are done to * schedule polls) * 2. it can race with dis/enabling irqs in other poll threads - * 3. if an irq raised after the begining of the outer beginning - * loop(marked in the code above), it will be immediately + * 3. if an irq raised after the beginning of the outer beginning + * loop (marked in the code above), it will be immediately * triggered here. * - * Summarizing: the logic may results in some redundant irqs both + * Summarizing: the logic may result in some redundant irqs both * due to races in masking and due to too late acking of already * processed irqs. The good news: no events are ever lost. */ @@ -601,7 +601,7 @@ a) 5) dev->close() and dev->suspend() issues ========================================== -The driver writter neednt worry about this. The top net layer takes +The driver writer needn't worry about this; the top net layer takes care of it. 6) Adding new Stats to /proc @@ -622,9 +622,9 @@ FC should be programmed to apply in the case when the system cant pull out packets fast enough i.e send a pause only when you run out of rx buffers. Note FC in itself is a good solution but we have found it to not be much of a commodity feature (both in NICs and switches) and hence falls -under the same category as using NIC based mitigation. Also experiments -indicate that its much harder to resolve the resource allocation -issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness +under the same category as using NIC based mitigation. Also, experiments +indicate that it's much harder to resolve the resource allocation +issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness proved harder. In any case, FC works even better with NAPI but is not necessary. @@ -678,10 +678,10 @@ routine: CSR5 bit of interest is only the rx status. If you look at the last if statement: you just finished grabbing all the packets from the rx ring .. you check if -status bit says theres more packets just in ... it says none; you then +status bit says there are more packets just in ... it says none; you then enable rx interrupts again; if a new packet just came in during this check, we are counting that CSR5 will be set in that small window of opportunity -and that by re-enabling interrupts, we would actually triger an interrupt +and that by re-enabling interrupts, we would actually trigger an interrupt to register the new packet for processing. [The above description nay be very verbose, if you have better wording diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt index 6489647..6387d3d 100644 --- a/Documentation/networking/cs89x0.txt +++ b/Documentation/networking/cs89x0.txt @@ -248,7 +248,7 @@ c) The driver's hardware probe routine is designed to avoid with device probing. To avoid this behaviour, add one to the `io=' module parameter. This doesn't actually change the I/O address, but it is a flag to tell the driver - topartially initialise the hardware before trying to + to partially initialise the hardware before trying to identify the card. This could be dangerous if you are not sure that there is a cs89x0 card at the provided address. @@ -620,8 +620,8 @@ I/O Address Device IRQ Device 12 Mouse (PS/2) Memory Address Device 13 Math Coprocessor -------------- --------------------- 14 Hard Disk controller -A000-BFFF EGA Graphics Adpater -A000-C7FF VGA Graphics Adpater +A000-BFFF EGA Graphics Adapter +A000-C7FF VGA Graphics Adapter B000-BFFF Mono Graphics Adapter B800-BFFF Color Graphics Adapter E000-FFFF AT BIOS diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index 74563b3..dda1588 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -19,21 +19,17 @@ for real time and multimedia traffic. It has a base protocol and pluggable congestion control IDs (CCIDs). -It is at draft RFC status and the homepage for DCCP as a protocol is at: - http://www.icir.org/kohler/dcp/ +It is at experimental RFC status and the homepage for DCCP as a protocol is at: + http://www.read.cs.ucla.edu/dccp/ Missing features ================ The DCCP implementation does not currently have all the features that are in -the draft RFC. +the RFC. -In particular the following are missing: -- CCID2 support -- feature negotiation - -When testing against other implementations it appears that elapsed time -options are not coded compliant to the specification. +The known bugs are at: + http://linux-net.osdl.org/index.php/TODO#DCCP Socket options ============== @@ -47,12 +43,70 @@ the socket will fall back to 0 (which means that no meaningful service code is present). Connecting sockets set at most one service option; for listening sockets, multiple service codes can be specified. +DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the +partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums +always cover the entire packet and that only fully covered application data is +accepted by the receiver. Hence, when using this feature on the sender, it must +be enabled at the receiver, too with suitable choice of CsCov. + +DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the + range 0..15 are acceptable. The default setting is 0 (full coverage), + values between 1..15 indicate partial coverage. +DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it + sets a threshold, where again values 0..15 are acceptable. The default + of 0 means that all packets with a partial coverage will be discarded. + Values in the range 1..15 indicate that packets with minimally such a + coverage value are also acceptable. The higher the number, the more + restrictive this setting (see [RFC 4340, sec. 9.2.1]). + +Sysctl variables +================ +Several DCCP default parameters can be managed by the following sysctls +(sysctl net.dccp.default or /proc/sys/net/dccp/default): + +request_retries + The number of active connection initiation retries (the number of + Requests minus one) before timing out. In addition, it also governs + the behaviour of the other, passive side: this variable also sets + the number of times DCCP repeats sending a Response when the initial + handshake does not progress from RESPOND to OPEN (i.e. when no Ack + is received after the initial Request). This value should be greater + than 0, suggested is less than 10. Analogue of tcp_syn_retries. + +retries1 + How often a DCCP Response is retransmitted until the listening DCCP + side considers its connecting peer dead. Analogue of tcp_retries1. + +retries2 + The number of times a general DCCP packet is retransmitted. This has + importance for retransmitted acknowledgments and feature negotiation, + data packets are never retransmitted. Analogue of tcp_retries2. + +send_ndp = 1 + Whether or not to send NDP count options (sec. 7.7.2). + +send_ackvec = 1 + Whether or not to send Ack Vector options (sec. 11.5). + +ack_ratio = 2 + The default Ack Ratio (sec. 11.3) to use. + +tx_ccid = 2 + Default CCID for the sender-receiver half-connection. + +rx_ccid = 2 + Default CCID for the receiver-sender half-connection. + +seq_window = 100 + The initial sequence window (sec. 7.5.2). + +tx_qlen = 5 + The size of the transmit buffer in packets. A value of 0 corresponds + to an unbounded transmit buffer. + Notes ===== -SELinux does not yet have support for DCCP. You will need to turn it off or -else you will get EACCES. - -DCCP does not travel through NAT successfully at present. This is because -the checksum covers the psuedo-header as per TCP and UDP. It should be -relatively trivial to add Linux NAT support for DCCP. +DCCP does not travel through NAT successfully at present on many boxes. This is +because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT +support for DCCP has been added. diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 5c0a5cc..61b171c 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters =============================================================== -November 15, 2005 +September 26, 2006 Contents @@ -9,6 +9,7 @@ Contents - In This Release - Identifying Your Adapter +- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations @@ -41,6 +42,9 @@ or later), lspci, and ifconfig to obtain the same information. Instructions on updating ethtool can be found in the section "Additional Configurations" later in this document. +NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 +support. + Identifying Your Adapter ======================== @@ -51,28 +55,27 @@ Driver ID Guide at: http://support.intel.com/support/network/adapter/pro100/21397.htm For the latest Intel network drivers for Linux, refer to the following -website. In the search field, enter your adapter name or type, or use the +website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: http://downloadfinder.intel.com/scripts-df/support_intel.asp -Command Line Parameters ======================= +Command Line Parameters +======================= If the driver is built as a module, the following optional parameters -are used by entering them on the command line with the modprobe or insmod -command using this syntax: +are used by entering them on the command line with the modprobe command +using this syntax: modprobe e1000 [<option>=<VAL1>,<VAL2>,...] - insmod e1000 [<option>=<VAL1>,<VAL2>,...] - For example, with two PRO/1000 PCI adapters, entering: - insmod e1000 TxDescriptors=80,128 + modprobe e1000 TxDescriptors=80,128 -loads the e1000 driver with 80 TX descriptors for the first adapter and 128 -TX descriptors for the second adapter. +loads the e1000 driver with 80 TX descriptors for the first adapter and +128 TX descriptors for the second adapter. The default value for each parameter is generally the recommended setting, unless otherwise noted. @@ -87,7 +90,7 @@ NOTES: For more information about the AutoNeg, Duplex, and Speed http://www.intel.com/design/network/applnots/ap450.htm A descriptor describes a data buffer and attributes related to - the data buffer. This information is accessed by the hardware. + the data buffer. This information is accessed by the hardware. AutoNeg @@ -96,9 +99,9 @@ AutoNeg Valid Range: 0x01-0x0F, 0x20-0x2F Default Value: 0x2F -This parameter is a bit mask that specifies which speed and duplex -settings the board advertises. When this parameter is used, the Speed -and Duplex parameters must not be specified. +This parameter is a bit-mask that specifies the speed and duplex settings +advertised by the adapter. When this parameter is used, the Speed and +Duplex parameters must not be specified. NOTE: Refer to the Speed and Duplex section of this readme for more information on the AutoNeg parameter. @@ -110,14 +113,15 @@ Duplex Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full) Default Value: 0 -Defines the direction in which data is allowed to flow. Can be either -one or two-directional. If both Duplex and the link partner are set to -auto-negotiate, the board auto-detects the correct duplex. If the link -partner is forced (either full or half), Duplex defaults to half-duplex. +This defines the direction in which data is allowed to flow. Can be +either one or two-directional. If both Duplex and the link partner are +set to auto-negotiate, the board auto-detects the correct duplex. If the +link partner is forced (either full or half), Duplex defaults to half- +duplex. FlowControl ----------- +----------- Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) Default Value: Reads flow control settings from the EEPROM @@ -127,57 +131,107 @@ to Ethernet PAUSE frames. InterruptThrottleRate --------------------- -(not supported on Intel 82542, 82543 or 82544-based adapters) -Valid Range: 100-100000 (0=off, 1=dynamic) -Default Value: 8000 - -This value represents the maximum number of interrupts per second the -controller generates. InterruptThrottleRate is another setting used in -interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust -InterruptThrottleRate based on the current traffic load. +(not supported on Intel(R) 82542, 82543 or 82544-based adapters) +Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative) +Default Value: 3 + +The driver can limit the amount of interrupts per second that the adapter +will generate for incoming packets. It does this by writing a value to the +adapter that is based on the maximum amount of interrupts that the adapter +will generate per second. + +Setting InterruptThrottleRate to a value greater or equal to 100 +will program the adapter to send out a maximum of that many interrupts +per second, even if more packets have come in. This reduces interrupt +load on the system and can lower CPU utilization under heavy load, +but will increase latency as packets are not processed as quickly. + +The default behaviour of the driver previously assumed a static +InterruptThrottleRate value of 8000, providing a good fallback value for +all traffic types,but lacking in small packet performance and latency. +The hardware can handle many more small packets per second however, and +for this reason an adaptive interrupt moderation algorithm was implemented. + +Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which +it dynamically adjusts the InterruptThrottleRate value based on the traffic +that it receives. After determining the type of incoming traffic in the last +timeframe, it will adjust the InterruptThrottleRate to an appropriate value +for that traffic. + +The algorithm classifies the incoming traffic every interval into +classes. Once the class is determined, the InterruptThrottleRate value is +adjusted to suit that traffic type the best. There are three classes defined: +"Bulk traffic", for large amounts of packets of normal size; "Low latency", +for small amounts of traffic and/or a significant percentage of small +packets; and "Lowest latency", for almost completely small packets or +minimal traffic. + +In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 +for traffic that falls in class "Bulk traffic". If traffic falls in the "Low +latency" or "Lowest latency" class, the InterruptThrottleRate is increased +stepwise to 20000. This default mode is suitable for most applications. + +For situations where low latency is vital such as cluster or +grid computing, the algorithm can reduce latency even more when +InterruptThrottleRate is set to mode 1. In this mode, which operates +the same as mode 3, the InterruptThrottleRate will be increased stepwise to +70000 for traffic in class "Lowest latency". + +Setting InterruptThrottleRate to 0 turns off any interrupt moderation +and may improve small packet latency, but is generally not suitable +for bulk throughput traffic. NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and - RxAbsIntDelay parameters. In other words, minimizing the receive + RxAbsIntDelay parameters. In other words, minimizing the receive and/or transmit absolute delays does not force the controller to generate more interrupts than what the Interrupt Throttle Rate allows. -CAUTION: If you are using the Intel PRO/1000 CT Network Connection +CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection (controller 82547), setting InterruptThrottleRate to a value greater than 75,000, may hang (stop transmitting) adapters - under certain network conditions. If this occurs a NETDEV - WATCHDOG message is logged in the system event log. In + under certain network conditions. If this occurs a NETDEV + WATCHDOG message is logged in the system event log. In addition, the controller is automatically reset, restoring - the network connection. To eliminate the potential for the + the network connection. To eliminate the potential for the hang, ensure that InterruptThrottleRate is set no greater than 75,000 and is not set to 0. NOTE: When e1000 is loaded with default settings and multiple adapters are in use simultaneously, the CPU utilization may increase non- - linearly. In order to limit the CPU utilization without impacting + linearly. In order to limit the CPU utilization without impacting the overall throughput, we recommend that you load the driver as follows: - insmod e1000.o InterruptThrottleRate=3000,3000,3000 + modprobe e1000 InterruptThrottleRate=3000,3000,3000 This sets the InterruptThrottleRate to 3000 interrupts/sec for - the first, second, and third instances of the driver. The range + the first, second, and third instances of the driver. The range of 2000 to 3000 interrupts per second works on a majority of systems and is a good starting point, but the optimal value will - be platform-specific. If CPU utilization is not a concern, use + be platform-specific. If CPU utilization is not a concern, use RX_POLLING (NAPI) and default driver settings. + RxDescriptors ------------- Valid Range: 80-256 for 82542 and 82543-based adapters 80-4096 for all other supported adapters Default Value: 256 -This value specifies the number of receive descriptors allocated by the -driver. Increasing this value allows the driver to buffer more incoming -packets. Each descriptor is 16 bytes. A receive buffer is also -allocated for each descriptor and is 2048. +This value specifies the number of receive buffer descriptors allocated +by the driver. Increasing this value allows the driver to buffer more +incoming packets, at the expense of increased system memory utilization. + +Each descriptor is 16 bytes. A receive buffer is also allocated for each +descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending +on the MTU setting. The maximum MTU size is 16110. + +NOTE: MTU designates the frame size. It only needs to be set for Jumbo + Frames. Depending on the available system resources, the request + for a higher number of receive descriptors may be denied. In this + case, use a lower number. RxIntDelay @@ -187,17 +241,17 @@ Default Value: 0 This value delays the generation of receive interrupts in units of 1.024 microseconds. Receive interrupt reduction can improve CPU efficiency if -properly tuned for specific network traffic. Increasing this value adds +properly tuned for specific network traffic. Increasing this value adds extra latency to frame reception and can end up decreasing the throughput -of TCP traffic. If the system is reporting dropped receives, this value +of TCP traffic. If the system is reporting dropped receives, this value may be set too high, causing the driver to run out of available receive descriptors. CAUTION: When setting RxIntDelay to a value other than 0, adapters may - hang (stop transmitting) under certain network conditions. If + hang (stop transmitting) under certain network conditions. If this occurs a NETDEV WATCHDOG message is logged in the system - event log. In addition, the controller is automatically reset, - restoring the network connection. To eliminate the potential + event log. In addition, the controller is automatically reset, + restoring the network connection. To eliminate the potential for the hang ensure that RxIntDelay is set to 0. @@ -208,7 +262,7 @@ Valid Range: 0-65535 (0=off) Default Value: 128 This value, in units of 1.024 microseconds, limits the delay in which a -receive interrupt is generated. Useful only if RxIntDelay is non-zero, +receive interrupt is generated. Useful only if RxIntDelay is non-zero, this value ensures that an interrupt is generated after the initial packet is received within the set amount of time. Proper tuning, along with RxIntDelay, may improve traffic throughput in specific network @@ -222,9 +276,9 @@ Valid Settings: 0, 10, 100, 1000 Default Value: 0 (auto-negotiate at all supported speeds) Speed forces the line speed to the specified value in megabits per second -(Mbps). If this parameter is not specified or is set to 0 and the link +(Mbps). If this parameter is not specified or is set to 0 and the link partner is set to auto-negotiate, the board will auto-detect the correct -speed. Duplex should also be set when Speed is set to either 10 or 100. +speed. Duplex should also be set when Speed is set to either 10 or 100. TxDescriptors @@ -234,7 +288,7 @@ Valid Range: 80-256 for 82542 and 82543-based adapters Default Value: 256 This value is the number of transmit descriptors allocated by the driver. -Increasing this value allows the driver to queue more transmits. Each +Increasing this value allows the driver to queue more transmits. Each descriptor is 16 bytes. NOTE: Depending on the available system resources, the request for a @@ -248,8 +302,8 @@ Valid Range: 0-65535 (0=off) Default Value: 64 This value delays the generation of transmit interrupts in units of -1.024 microseconds. Transmit interrupt reduction can improve CPU -efficiency if properly tuned for specific network traffic. If the +1.024 microseconds. Transmit interrupt reduction can improve CPU +efficiency if properly tuned for specific network traffic. If the system is reporting dropped transmits, this value may be set too high causing the driver to run out of available transmit descriptors. @@ -261,7 +315,7 @@ Valid Range: 0-65535 (0=off) Default Value: 64 This value, in units of 1.024 microseconds, limits the delay in which a -transmit interrupt is generated. Useful only if TxIntDelay is non-zero, +transmit interrupt is generated. Useful only if TxIntDelay is non-zero, this value ensures that an interrupt is generated after the initial packet is sent on the wire within the set amount of time. Proper tuning, along with TxIntDelay, may improve traffic throughput in specific @@ -288,15 +342,15 @@ fiber interface board only links at 1000 Mbps full-duplex. For copper-based boards, the keywords interact as follows: - The default operation is auto-negotiate. The board advertises all + The default operation is auto-negotiate. The board advertises all supported speed and duplex combinations, and it links at the highest common speed and duplex mode IF the link partner is set to auto-negotiate. If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps is advertised (The 1000BaseT spec requires auto-negotiation.) - If Speed = 10 or 100, then both Speed and Duplex should be set. Auto- - negotiation is disabled, and the AutoNeg parameter is ignored. Partner + If Speed = 10 or 100, then both Speed and Duplex should be set. Auto- + negotiation is disabled, and the AutoNeg parameter is ignored. Partner SHOULD also be forced. The AutoNeg parameter is used when more control is required over the @@ -304,7 +358,7 @@ auto-negotiation process. It should be used when you wish to control which speed and duplex combinations are advertised during the auto-negotiation process. -The parameter may be specified as either a decimal or hexidecimal value as +The parameter may be specified as either a decimal or hexadecimal value as determined by the bitmap below. Bit position 7 6 5 4 3 2 1 0 @@ -337,20 +391,19 @@ Additional Configurations Configuring the Driver on Different Distributions ------------------------------------------------- - Configuring a network driver to load properly when the system is started - is distribution dependent. Typically, the configuration process involves + is distribution dependent. Typically, the configuration process involves adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well - as editing other system startup scripts and/or configuration files. Many + as editing other system startup scripts and/or configuration files. Many popular Linux distributions ship with tools to make these changes for you. To learn the proper way to configure a network device for your system, - refer to your distribution documentation. If during this process you are + refer to your distribution documentation. If during this process you are asked for the driver or module name, the name for the Linux Base Driver - for the Intel PRO/1000 Family of Adapters is e1000. + for the Intel(R) PRO/1000 Family of Adapters is e1000. As an example, if you install the e1000 driver for two PRO/1000 adapters (eth0 and eth1) and set the speed and duplex to 10full and 100half, add - the following to modules.conf or modprobe.conf: + the following to modules.conf or or modprobe.conf: alias eth0 e1000 alias eth1 e1000 @@ -358,9 +411,8 @@ Additional Configurations Viewing Link Messages --------------------- - Link messages will not be displayed to the console if the distribution is - restricting system messages. In order to see network driver link messages + restricting system messages. In order to see network driver link messages on your console, set dmesg to eight by entering the following: dmesg -n 8 @@ -369,11 +421,9 @@ Additional Configurations Jumbo Frames ------------ - - The driver supports Jumbo Frames for all adapters except 82542 and - 82573-based adapters. Jumbo Frames support is enabled by changing the - MTU to a value larger than the default of 1500. Use the ifconfig command - to increase the MTU size. For example: + Jumbo Frames support is enabled by changing the MTU to a value larger than + the default of 1500. Use the ifconfig command to increase the MTU size. + For example: ifconfig eth<x> mtu 9000 up @@ -390,26 +440,49 @@ Additional Configurations - To enable Jumbo Frames, increase the MTU size on the interface beyond 1500. - - The maximum MTU setting for Jumbo Frames is 16110. This value coincides + + - The maximum MTU setting for Jumbo Frames is 16110. This value coincides with the maximum Jumbo Frames size of 16128. + - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or loss of link. + - Some Intel gigabit adapters that support Jumbo Frames have a frame size limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes. - The adapters with this limitation are based on the Intel 82571EB and - 82572EI controllers, which correspond to these product names: - Intel® PRO/1000 PT Dual Port Server Adapter - Intel® PRO/1000 PF Dual Port Server Adapter - Intel® PRO/1000 PT Server Adapter - Intel® PRO/1000 PT Desktop Adapter - Intel® PRO/1000 PF Server Adapter - - - The Intel PRO/1000 PM Network Connection does not support jumbo frames. + The adapters with this limitation are based on the Intel(R) 82571EB, + 82572EI, 82573L and 80003ES2LAN controller. These correspond to the + following product names: + Intel(R) PRO/1000 PT Server Adapter + Intel(R) PRO/1000 PT Desktop Adapter + Intel(R) PRO/1000 PT Network Connection + Intel(R) PRO/1000 PT Dual Port Server Adapter + Intel(R) PRO/1000 PT Dual Port Network Connection + Intel(R) PRO/1000 PF Server Adapter + Intel(R) PRO/1000 PF Network Connection + Intel(R) PRO/1000 PF Dual Port Server Adapter + Intel(R) PRO/1000 PB Server Connection + Intel(R) PRO/1000 PL Network Connection + Intel(R) PRO/1000 EB Network Connection with I/O Acceleration + Intel(R) PRO/1000 EB Backplane Connection with I/O Acceleration + Intel(R) PRO/1000 PT Quad Port Server Adapter + + - Adapters based on the Intel(R) 82542 and 82573V/E controller do not + support Jumbo Frames. These correspond to the following product names: + Intel(R) PRO/1000 Gigabit Server Adapter + Intel(R) PRO/1000 PM Network Connection + + - The following adapters do not support Jumbo Frames: + Intel(R) 82562V 10/100 Network Connection + Intel(R) 82566DM Gigabit Network Connection + Intel(R) 82566DC Gigabit Network Connection + Intel(R) 82566MM Gigabit Network Connection + Intel(R) 82566MC Gigabit Network Connection + Intel(R) 82562GT 10/100 Network Connection + Intel(R) 82562G 10/100 Network Connection Ethtool ------- - The driver utilizes the ethtool interface for driver configuration and diagnostics, as well as displaying statistical information. Ethtool version 1.6 or later is required for this functionality. @@ -417,15 +490,14 @@ Additional Configurations The latest release of ethtool can be found from http://sourceforge.net/projects/gkernel. - NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support + NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support for a more complete ethtool feature set can be enabled by upgrading ethtool to ethtool-1.8.1. Enabling Wake on LAN* (WoL) --------------------------- - - WoL is configured through the Ethtool* utility. Ethtool is included with - all versions of Red Hat after Red Hat 7.2. For other Linux distributions, + WoL is configured through the Ethtool* utility. Ethtool is included with + all versions of Red Hat after Red Hat 7.2. For other Linux distributions, download and install Ethtool from the following website: http://sourceforge.net/projects/gkernel. @@ -436,11 +508,17 @@ Additional Configurations For this driver version, in order to enable WoL, the e1000 driver must be loaded when shutting down or rebooting the system. + Wake On LAN is only supported on port A for the following devices: + Intel(R) PRO/1000 PT Dual Port Network Connection + Intel(R) PRO/1000 PT Dual Port Server Connection + Intel(R) PRO/1000 PT Dual Port Server Adapter + Intel(R) PRO/1000 PF Dual Port Server Adapter + Intel(R) PRO/1000 PT Quad Port Server Adapter + NAPI ---- - - NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled - or disabled based on the configuration of the kernel. To override + NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled + or disabled based on the configuration of the kernel. To override the default, use the following compile-time flags. To enable NAPI, compile the driver module, passing in a configuration option: @@ -457,88 +535,105 @@ Additional Configurations Known Issues ============ - Jumbo Frames System Requirement - ------------------------------- - - Memory allocation failures have been observed on Linux systems with 64 MB - of RAM or less that are running Jumbo Frames. If you are using Jumbo - Frames, your system may require more than the advertised minimum - requirement of 64 MB of system memory. - - Performance Degradation with Jumbo Frames - ----------------------------------------- - - Degradation in throughput performance may be observed in some Jumbo frames - environments. If this is observed, increasing the application's socket - buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values - may help. See the specific application manual and - /usr/src/linux*/Documentation/ - networking/ip-sysctl.txt for more details. - - Jumbo frames on Foundry BigIron 8000 switch - ------------------------------------------- - There is a known issue using Jumbo frames when connected to a Foundry - BigIron 8000 switch. This is a 3rd party limitation. If you experience - loss of packets, lower the MTU size. - - Multiple Interfaces on Same Ethernet Broadcast Network - ------------------------------------------------------ - - Due to the default ARP behavior on Linux, it is not possible to have - one system on two IP networks in the same Ethernet broadcast domain - (non-partitioned switch) behave as expected. All Ethernet interfaces - will respond to IP traffic for any IP address assigned to the system. - This results in unbalanced receive traffic. - - If you have multiple interfaces in a server, either turn on ARP - filtering by entering: - - echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter - (this only works if your kernel's version is higher than 2.4.5), - - NOTE: This setting is not saved across reboots. The configuration - change can be made permanent by adding the line: - net.ipv4.conf.all.arp_filter = 1 - to the file /etc/sysctl.conf - - or, - - install the interfaces in separate broadcast domains (either in - different switches or in a switch partitioned to VLANs). - - 82541/82547 can't link or are slow to link with some link partners - ----------------------------------------------------------------- - - There is a known compatibility issue with 82541/82547 and some - low-end switches where the link will not be established, or will - be slow to establish. In particular, these switches are known to - be incompatible with 82541/82547: - - Planex FXG-08TE - I-O Data ETG-SH8 - - To workaround this issue, the driver can be compiled with an override - of the PHY's master/slave setting. Forcing master or forcing slave - mode will improve time-to-link. - - # make EXTRA_CFLAGS=-DE1000_MASTER_SLAVE=<n> - - Where <n> is: - - 0 = Hardware default - 1 = Master mode - 2 = Slave mode - 3 = Auto master/slave - - Disable rx flow control with ethtool - ------------------------------------ - - In order to disable receive flow control using ethtool, you must turn - off auto-negotiation on the same command line. - - For example: - - ethtool -A eth? autoneg off rx off +Dropped Receive Packets on Half-duplex 10/100 Networks +------------------------------------------------------ +If you have an Intel PCI Express adapter running at 10mbps or 100mbps, half- +duplex, you may observe occasional dropped receive packets. There are no +workarounds for this problem in this network configuration. The network must +be updated to operate in full-duplex, and/or 1000mbps only. + +Jumbo Frames System Requirement +------------------------------- +Memory allocation failures have been observed on Linux systems with 64 MB +of RAM or less that are running Jumbo Frames. If you are using Jumbo +Frames, your system may require more than the advertised minimum +requirement of 64 MB of system memory. + +Performance Degradation with Jumbo Frames +----------------------------------------- +Degradation in throughput performance may be observed in some Jumbo frames +environments. If this is observed, increasing the application's socket +buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values +may help. See the specific application manual and +/usr/src/linux*/Documentation/ +networking/ip-sysctl.txt for more details. + +Jumbo Frames on Foundry BigIron 8000 switch +------------------------------------------- +There is a known issue using Jumbo frames when connected to a Foundry +BigIron 8000 switch. This is a 3rd party limitation. If you experience +loss of packets, lower the MTU size. + +Allocating Rx Buffers when Using Jumbo Frames +--------------------------------------------- +Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if +the available memory is heavily fragmented. This issue may be seen with PCI-X +adapters or with packet split disabled. This can be reduced or eliminated +by changing the amount of available memory for receive buffer allocation, by +increasing /proc/sys/vm/min_free_kbytes. + +Multiple Interfaces on Same Ethernet Broadcast Network +------------------------------------------------------ +Due to the default ARP behavior on Linux, it is not possible to have +one system on two IP networks in the same Ethernet broadcast domain +(non-partitioned switch) behave as expected. All Ethernet interfaces +will respond to IP traffic for any IP address assigned to the system. +This results in unbalanced receive traffic. + +If you have multiple interfaces in a server, either turn on ARP +filtering by entering: + + echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter +(this only works if your kernel's version is higher than 2.4.5), + +NOTE: This setting is not saved across reboots. The configuration +change can be made permanent by adding the line: + net.ipv4.conf.all.arp_filter = 1 +to the file /etc/sysctl.conf + + or, + +install the interfaces in separate broadcast domains (either in +different switches or in a switch partitioned to VLANs). + +82541/82547 can't link or are slow to link with some link partners +----------------------------------------------------------------- +There is a known compatibility issue with 82541/82547 and some +low-end switches where the link will not be established, or will +be slow to establish. In particular, these switches are known to +be incompatible with 82541/82547: + + Planex FXG-08TE + I-O Data ETG-SH8 + +To workaround this issue, the driver can be compiled with an override +of the PHY's master/slave setting. Forcing master or forcing slave +mode will improve time-to-link. + + # make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n> + +Where <n> is: + + 0 = Hardware default + 1 = Master mode + 2 = Slave mode + 3 = Auto master/slave + +Disable rx flow control with ethtool +------------------------------------ +In order to disable receive flow control using ethtool, you must turn +off auto-negotiation on the same command line. + +For example: + + ethtool -A eth? autoneg off rx off + +Unplugging network cable while ethtool -p is running +---------------------------------------------------- +In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging +the network cable while ethtool -p is running will cause the system to +become unresponsive to keyboard commands, except for control-alt-delete. +Restarting the system appears to be the only remedy. Support @@ -548,24 +643,10 @@ For general information, go to the Intel support website at: http://support.intel.com - or the Intel Wired Networking project hosted by Sourceforge at: +or the Intel Wired Networking project hosted by Sourceforge at: http://sourceforge.net/projects/e1000 If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related -to the issue to e1000-devel@lists.sourceforge.net - - -License -======= - -This software program is released under the terms of a license agreement -between you ('Licensee') and Intel. Do not use or load this software or any -associated materials (collectively, the 'Software') until you have carefully -read the full terms and conditions of the file COPYING located in this software -package. By loading or using the Software, you agree to the terms of this -Agreement. If you do not agree with the terms of this Agreement, do not -install or use the Software. - -* Other names and brands may be claimed as the property of others. +to the issue to e1000-devel@lists.sf.net diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index fd3c0c0..a0f6842 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER TCP variables: +somaxconn - INTEGER + Limit of socket listen() backlog, known in userspace as SOMAXCONN. + Defaults to 128. See also tcp_max_syn_backlog for additional tuning + for TCP sockets. + tcp_abc - INTEGER Controls Appropriate Byte Count (ABC) defined in RFC3465. ABC is a way of increasing congestion window (cwnd) more slowly @@ -112,48 +117,51 @@ tcp_abc - INTEGER of two segments to compensate for delayed acknowledgments. Default: 0 (off) -tcp_syn_retries - INTEGER - Number of times initial SYNs for an active TCP connection attempt - will be retransmitted. Should not be higher than 255. Default value - is 5, which corresponds to ~180seconds. +tcp_abort_on_overflow - BOOLEAN + If listening service is too slow to accept new connections, + reset them. Default state is FALSE. It means that if overflow + occurred due to a burst, connection will recover. Enable this + option _only_ if you are really sure that listening daemon + cannot be tuned to accept connections faster. Enabling this + option can harm clients of your server. -tcp_synack_retries - INTEGER - Number of times SYNACKs for a passive TCP connection attempt will - be retransmitted. Should not be higher than 255. Default value - is 5, which corresponds to ~180seconds. +tcp_adv_win_scale - INTEGER + Count buffering overhead as bytes/2^tcp_adv_win_scale + (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale), + if it is <= 0. + Default: 2 -tcp_keepalive_time - INTEGER - How often TCP sends out keepalive messages when keepalive is enabled. - Default: 2hours. +tcp_allowed_congestion_control - STRING + Show/set the congestion control choices available to non-privileged + processes. The list is a subset of those listed in + tcp_available_congestion_control. + Default is "reno" and the default setting (tcp_congestion_control). -tcp_keepalive_probes - INTEGER - How many keepalive probes TCP sends out, until it decides that the - connection is broken. Default value: 9. +tcp_app_win - INTEGER + Reserve max(window/2^tcp_app_win, mss) of window for application + buffer. Value 0 is special, it means that nothing is reserved. + Default: 31 -tcp_keepalive_intvl - INTEGER - How frequently the probes are send out. Multiplied by - tcp_keepalive_probes it is time to kill not responding connection, - after probes started. Default value: 75sec i.e. connection - will be aborted after ~11 minutes of retries. +tcp_available_congestion_control - STRING + Shows the available congestion control choices that are registered. + More congestion control algorithms may be available as modules, + but not loaded. -tcp_retries1 - INTEGER - How many times to retry before deciding that something is wrong - and it is necessary to report this suspicion to network layer. - Minimal RFC value is 3, it is default, which corresponds - to ~3sec-8min depending on RTO. +tcp_congestion_control - STRING + Set the congestion control algorithm to be used for new + connections. The algorithm "reno" is always available, but + additional choices may be available based on kernel configuration. + Default is set as part of kernel configuration. -tcp_retries2 - INTEGER - How may times to retry before killing alive TCP connection. - RFC1122 says that the limit should be longer than 100 sec. - It is too small number. Default value 15 corresponds to ~13-30min - depending on RTO. +tcp_dsack - BOOLEAN + Allows TCP to send "duplicate" SACKs. -tcp_orphan_retries - INTEGER - How may times to retry before killing TCP connection, closed - by our side. Default value 7 corresponds to ~50sec-16min - depending on RTO. If you machine is loaded WEB server, - you should think about lowering this value, such sockets - may consume significant resources. Cf. tcp_max_orphans. +tcp_ecn - BOOLEAN + Enable Explicit Congestion Notification in TCP. + +tcp_fack - BOOLEAN + Enable FACK congestion avoidance and fast retransmission. + The value is not used, if tcp_sack is not enabled. tcp_fin_timeout - INTEGER Time to hold socket in state FIN-WAIT-2, if it was closed @@ -166,24 +174,33 @@ tcp_fin_timeout - INTEGER because they eat maximum 1.5K of memory, but they tend to live longer. Cf. tcp_max_orphans. -tcp_max_tw_buckets - INTEGER - Maximal number of timewait sockets held by system simultaneously. - If this number is exceeded time-wait socket is immediately destroyed - and warning is printed. This limit exists only to prevent - simple DoS attacks, you _must_ not lower the limit artificially, - but rather increase it (probably, after increasing installed memory), - if network conditions require more than default value. +tcp_frto - BOOLEAN + Enables F-RTO, an enhanced recovery algorithm for TCP retransmission + timeouts. It is particularly beneficial in wireless environments + where packet loss is typically due to random radio interference + rather than intermediate router congestion. -tcp_tw_recycle - BOOLEAN - Enable fast recycling TIME-WAIT sockets. Default value is 0. - It should not be changed without advice/request of technical - experts. +tcp_keepalive_time - INTEGER + How often TCP sends out keepalive messages when keepalive is enabled. + Default: 2hours. -tcp_tw_reuse - BOOLEAN - Allow to reuse TIME-WAIT sockets for new connections when it is - safe from protocol viewpoint. Default value is 0. - It should not be changed without advice/request of technical - experts. +tcp_keepalive_probes - INTEGER + How many keepalive probes TCP sends out, until it decides that the + connection is broken. Default value: 9. + +tcp_keepalive_intvl - INTEGER + How frequently the probes are send out. Multiplied by + tcp_keepalive_probes it is time to kill not responding connection, + after probes started. Default value: 75sec i.e. connection + will be aborted after ~11 minutes of retries. + +tcp_low_latency - BOOLEAN + If set, the TCP stack makes decisions that prefer lower + latency as opposed to higher throughput. By default, this + option is not set meaning that higher throughput is preferred. + An example of an application where this default should be + changed would be a Beowulf compute cluster. + Default: 0 tcp_max_orphans - INTEGER Maximal number of TCP sockets not attached to any user file handle, @@ -197,41 +214,6 @@ tcp_max_orphans - INTEGER more aggressively. Let me to remind again: each orphan eats up to ~64K of unswappable memory. -tcp_abort_on_overflow - BOOLEAN - If listening service is too slow to accept new connections, - reset them. Default state is FALSE. It means that if overflow - occurred due to a burst, connection will recover. Enable this - option _only_ if you are really sure that listening daemon - cannot be tuned to accept connections faster. Enabling this - option can harm clients of your server. - -tcp_syncookies - BOOLEAN - Only valid when the kernel was compiled with CONFIG_SYNCOOKIES - Send out syncookies when the syn backlog queue of a socket - overflows. This is to prevent against the common 'syn flood attack' - Default: FALSE - - Note, that syncookies is fallback facility. - It MUST NOT be used to help highly loaded servers to stand - against legal connection rate. If you see synflood warnings - in your logs, but investigation shows that they occur - because of overload with legal connections, you should tune - another parameters until this warning disappear. - See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow. - - syncookies seriously violate TCP protocol, do not allow - to use TCP extensions, can result in serious degradation - of some services (f.e. SMTP relaying), visible not by you, - but your clients and relays, contacting you. While you see - synflood warnings in logs not being really flooded, your server - is seriously misconfigured. - -tcp_stdurg - BOOLEAN - Use the Host requirements interpretation of the TCP urg pointer field. - Most hosts use the older BSD interpretation, so if you turn this on - Linux might not communicate correctly with them. - Default: FALSE - tcp_max_syn_backlog - INTEGER Maximal number of remembered connection requests, which are still did not receive an acknowledgment from connecting client. @@ -239,24 +221,34 @@ tcp_max_syn_backlog - INTEGER and 128 for low memory machines. If server suffers of overload, try to increase this number. -tcp_window_scaling - BOOLEAN - Enable window scaling as defined in RFC1323. +tcp_max_tw_buckets - INTEGER + Maximal number of timewait sockets held by system simultaneously. + If this number is exceeded time-wait socket is immediately destroyed + and warning is printed. This limit exists only to prevent + simple DoS attacks, you _must_ not lower the limit artificially, + but rather increase it (probably, after increasing installed memory), + if network conditions require more than default value. -tcp_timestamps - BOOLEAN - Enable timestamps as defined in RFC1323. +tcp_mem - vector of 3 INTEGERs: min, pressure, max + min: below this number of pages TCP is not bothered about its + memory appetite. -tcp_sack - BOOLEAN - Enable select acknowledgments (SACKS). + pressure: when amount of memory allocated by TCP exceeds this number + of pages, TCP moderates its memory consumption and enters memory + pressure mode, which is exited when memory consumption falls + under "min". -tcp_fack - BOOLEAN - Enable FACK congestion avoidance and fast retransmission. - The value is not used, if tcp_sack is not enabled. + max: number of pages allowed for queueing by all TCP sockets. -tcp_dsack - BOOLEAN - Allows TCP to send "duplicate" SACKs. + Defaults are calculated at boot time from amount of available + memory. -tcp_ecn - BOOLEAN - Enable Explicit Congestion Notification in TCP. +tcp_orphan_retries - INTEGER + How may times to retry before killing TCP connection, closed + by our side. Default value 7 corresponds to ~50sec-16min + depending on RTO. If you machine is loaded WEB server, + you should think about lowering this value, such sockets + may consume significant resources. Cf. tcp_max_orphans. tcp_reordering - INTEGER Maximal reordering of packets in a TCP stream. @@ -267,20 +259,23 @@ tcp_retrans_collapse - BOOLEAN On retransmit try to send bigger packets to work around bugs in certain TCP stacks. -tcp_wmem - vector of 3 INTEGERs: min, default, max - min: Amount of memory reserved for send buffers for TCP socket. - Each TCP socket has rights to use it due to fact of its birth. - Default: 4K +tcp_retries1 - INTEGER + How many times to retry before deciding that something is wrong + and it is necessary to report this suspicion to network layer. + Minimal RFC value is 3, it is default, which corresponds + to ~3sec-8min depending on RTO. - default: Amount of memory allowed for send buffers for TCP socket - by default. This value overrides net.core.wmem_default used - by other protocols, it is usually lower than net.core.wmem_default. - Default: 16K +tcp_retries2 - INTEGER + How may times to retry before killing alive TCP connection. + RFC1122 says that the limit should be longer than 100 sec. + It is too small number. Default value 15 corresponds to ~13-30min + depending on RTO. - max: Maximal amount of memory allowed for automatically selected - send buffers for TCP socket. This value does not override - net.core.wmem_max, "static" selection via SO_SNDBUF does not use this. - Default: 128K +tcp_rfc1337 - BOOLEAN + If set, the TCP stack behaves conforming to RFC1337. If unset, + we are not conforming to RFC, but prevent TCP TIME_WAIT + assassination. + Default: 0 tcp_rmem - vector of 3 INTEGERs: min, default, max min: Minimal size of receive buffer used by TCP sockets. @@ -299,67 +294,91 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max net.core.rmem_max, "static" selection via SO_RCVBUF does not use this. Default: 87380*2 bytes. -tcp_mem - vector of 3 INTEGERs: min, pressure, max - min: below this number of pages TCP is not bothered about its - memory appetite. +tcp_sack - BOOLEAN + Enable select acknowledgments (SACKS). - pressure: when amount of memory allocated by TCP exceeds this number - of pages, TCP moderates its memory consumption and enters memory - pressure mode, which is exited when memory consumption falls - under "min". +tcp_slow_start_after_idle - BOOLEAN + If set, provide RFC2861 behavior and time out the congestion + window after an idle period. An idle period is defined at + the current RTO. If unset, the congestion window will not + be timed out after an idle period. + Default: 1 - max: number of pages allowed for queueing by all TCP sockets. +tcp_stdurg - BOOLEAN + Use the Host requirements interpretation of the TCP urg pointer field. + Most hosts use the older BSD interpretation, so if you turn this on + Linux might not communicate correctly with them. + Default: FALSE - Defaults are calculated at boot time from amount of available - memory. +tcp_synack_retries - INTEGER + Number of times SYNACKs for a passive TCP connection attempt will + be retransmitted. Should not be higher than 255. Default value + is 5, which corresponds to ~180seconds. -tcp_app_win - INTEGER - Reserve max(window/2^tcp_app_win, mss) of window for application - buffer. Value 0 is special, it means that nothing is reserved. - Default: 31 +tcp_syncookies - BOOLEAN + Only valid when the kernel was compiled with CONFIG_SYNCOOKIES + Send out syncookies when the syn backlog queue of a socket + overflows. This is to prevent against the common 'syn flood attack' + Default: FALSE -tcp_adv_win_scale - INTEGER - Count buffering overhead as bytes/2^tcp_adv_win_scale - (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale), - if it is <= 0. - Default: 2 + Note, that syncookies is fallback facility. + It MUST NOT be used to help highly loaded servers to stand + against legal connection rate. If you see synflood warnings + in your logs, but investigation shows that they occur + because of overload with legal connections, you should tune + another parameters until this warning disappear. + See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow. -tcp_rfc1337 - BOOLEAN - If set, the TCP stack behaves conforming to RFC1337. If unset, - we are not conforming to RFC, but prevent TCP TIME_WAIT - assassination. - Default: 0 + syncookies seriously violate TCP protocol, do not allow + to use TCP extensions, can result in serious degradation + of some services (f.e. SMTP relaying), visible not by you, + but your clients and relays, contacting you. While you see + synflood warnings in logs not being really flooded, your server + is seriously misconfigured. -tcp_low_latency - BOOLEAN - If set, the TCP stack makes decisions that prefer lower - latency as opposed to higher throughput. By default, this - option is not set meaning that higher throughput is preferred. - An example of an application where this default should be - changed would be a Beowulf compute cluster. - Default: 0 +tcp_syn_retries - INTEGER + Number of times initial SYNs for an active TCP connection attempt + will be retransmitted. Should not be higher than 255. Default value + is 5, which corresponds to ~180seconds. + +tcp_timestamps - BOOLEAN + Enable timestamps as defined in RFC1323. tcp_tso_win_divisor - INTEGER - This allows control over what percentage of the congestion window - can be consumed by a single TSO frame. - The setting of this parameter is a choice between burstiness and - building larger TSO frames. - Default: 3 + This allows control over what percentage of the congestion window + can be consumed by a single TSO frame. + The setting of this parameter is a choice between burstiness and + building larger TSO frames. + Default: 3 -tcp_frto - BOOLEAN - Enables F-RTO, an enhanced recovery algorithm for TCP retransmission - timeouts. It is particularly beneficial in wireless environments - where packet loss is typically due to random radio interference - rather than intermediate router congestion. +tcp_tw_recycle - BOOLEAN + Enable fast recycling TIME-WAIT sockets. Default value is 0. + It should not be changed without advice/request of technical + experts. -tcp_congestion_control - STRING - Set the congestion control algorithm to be used for new - connections. The algorithm "reno" is always available, but - additional choices may be available based on kernel configuration. +tcp_tw_reuse - BOOLEAN + Allow to reuse TIME-WAIT sockets for new connections when it is + safe from protocol viewpoint. Default value is 0. + It should not be changed without advice/request of technical + experts. -somaxconn - INTEGER - Limit of socket listen() backlog, known in userspace as SOMAXCONN. - Defaults to 128. See also tcp_max_syn_backlog for additional tuning - for TCP sockets. +tcp_window_scaling - BOOLEAN + Enable window scaling as defined in RFC1323. + +tcp_wmem - vector of 3 INTEGERs: min, default, max + min: Amount of memory reserved for send buffers for TCP socket. + Each TCP socket has rights to use it due to fact of its birth. + Default: 4K + + default: Amount of memory allowed for send buffers for TCP socket + by default. This value overrides net.core.wmem_default used + by other protocols, it is usually lower than net.core.wmem_default. + Default: 16K + + max: Maximal amount of memory allowed for automatically selected + send buffers for TCP socket. This value does not override + net.core.wmem_max, "static" selection via SO_SNDBUF does not use this. + Default: 128K tcp_workaround_signed_windows - BOOLEAN If set, assume no receipt of a window scaling option means the @@ -368,13 +387,6 @@ tcp_workaround_signed_windows - BOOLEAN not receive a window scaling option from them. Default: 0 -tcp_slow_start_after_idle - BOOLEAN - If set, provide RFC2861 behavior and time out the congestion - window after an idle period. An idle period is defined at - the current RTO. If unset, the congestion window will not - be timed out after an idle period. - Default: 1 - CIPSOv4 Variables: cipso_cache_enable - BOOLEAN @@ -974,4 +986,3 @@ no_cong_thresh FIXME slot_timeout FIXME warn_noreply_time FIXME -$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $ diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt index 493203a..55eac4a 100644 --- a/Documentation/networking/iphase.txt +++ b/Documentation/networking/iphase.txt @@ -81,7 +81,7 @@ Installation 1M. The RAM size decides the number of buffers and buffer size. The default size and number of buffers are set as following: - Totol Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf + Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf RAM size size size size size cnt cnt -------- ------ ------ ------ ------ ------ ------ 128K 64K 64K 10K 10K 6 6 diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 12a008a..5a232d9 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -284,7 +284,7 @@ the necessary memory, so normally limits can be reached. ------------------- If you check the source code you will see that what I draw here as a frame -is not only the link level frame. At the begining of each frame there is a +is not only the link level frame. At the beginning of each frame there is a header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame meta information like timestamp. So what we draw here a frame it's really the following (from include/linux/if_packet.h): diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index 29ccae4..0bc95ea 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -1,7 +1,7 @@ ------- PHY Abstraction Layer -(Updated 2005-07-21) +(Updated 2006-11-30) Purpose @@ -97,11 +97,12 @@ Letting the PHY Abstraction Layer do Everything Next, you need to know the device name of the PHY connected to this device. The name will look something like, "phy0:0", where the first number is the - bus id, and the second is the PHY's address on that bus. + bus id, and the second is the PHY's address on that bus. Typically, + the bus is responsible for making its ID unique. Now, to connect, just call this function: - phydev = phy_connect(dev, phy_name, &adjust_link, flags); + phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface); phydev is a pointer to the phy_device structure which represents the PHY. If phy_connect is successful, it will return the pointer. dev, here, is the @@ -115,6 +116,10 @@ Letting the PHY Abstraction Layer do Everything This is useful if the system has put hardware restrictions on the PHY/controller, of which the PHY needs to be aware. + interface is a u32 which specifies the connection type used + between the controller and the PHY. Examples are GMII, MII, + RGMII, and SGMII. For a full list, see include/linux/phy.h + Now just make sure that phydev->supported and phydev->advertising have any values pruned from them which don't make sense for your controller (a 10/100 controller may be connected to a gigabit capable PHY, so you would need to @@ -191,7 +196,7 @@ Doing it all yourself start, or disables then frees them for stop. struct phy_device * phy_attach(struct net_device *dev, const char *phy_id, - u32 flags); + u32 flags, phy_interface_t interface); Attaches a network device to a particular PHY, binding the PHY to a generic driver if none was found during bus initialization. Passes in diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index c8eee23..c6cf4a3 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -63,8 +63,8 @@ Current: Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags) 763292pps 390Mb/sec (390805504bps) errors: 39664 -Confguring threads and devices -============================== +Configuring threads and devices +================================ This is done via the /proc interface easiest done via pgset in the scripts Examples: @@ -116,7 +116,7 @@ Examples: there must be no spaces between the arguments. Leading zeros are required. Do not set the bottom of stack bit, - thats done automatically. If you do + that's done automatically. If you do set the bottom of stack bit, that indicates that you want to randomly generate that address and the flag diff --git a/Documentation/networking/proc_net_tcp.txt b/Documentation/networking/proc_net_tcp.txt index 59cb915..5e21f7c 100644 --- a/Documentation/networking/proc_net_tcp.txt +++ b/Documentation/networking/proc_net_tcp.txt @@ -25,7 +25,7 @@ up into 3 parts because of the length of the line): 1000 0 54165785 4 cd1e6040 25 4 27 3 -1 | | | | | | | | | |--> slow start size threshold, - | | | | | | | | | or -1 if the treshold + | | | | | | | | | or -1 if the threshold | | | | | | | | | is >= 0xFFFF | | | | | | | | |----> sending congestion window | | | | | | | |-------> (ack.quick<<1)|ack.pingpong diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt index 4e1cc74..8590a95 100644 --- a/Documentation/networking/sk98lin.txt +++ b/Documentation/networking/sk98lin.txt @@ -346,7 +346,7 @@ Possible modes: depending on the load of the system. If the driver detects that the system load is too high, the driver tries to shield the system against too much network load by enabling interrupt moderation. If - at a later - time - the CPU utilizaton decreases again (or if the network load is + time - the CPU utilization decreases again (or if the network load is negligible) the interrupt moderation will automatically be disabled. Interrupt moderation should be used when the driver has to handle one or more diff --git a/Documentation/networking/slicecom.txt b/Documentation/networking/slicecom.txt index 2f04c92..32d3b91 100644 --- a/Documentation/networking/slicecom.txt +++ b/Documentation/networking/slicecom.txt @@ -126,7 +126,7 @@ comx0/boardnum - board number of the SliceCom in the PC (using the 'natural' Though the options below are to be set on a single interface, they apply to the whole board. The restriction, to use them on 'UP' interfaces, is because the -command sequence below could lead to unpredicable results. +command sequence below could lead to unpredictable results. # echo 0 >boardnum # echo internal >clock_source diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt new file mode 100644 index 0000000..dd6f46b --- /dev/null +++ b/Documentation/networking/udplite.txt @@ -0,0 +1,281 @@ + =========================================================================== + The UDP-Lite protocol (RFC 3828) + =========================================================================== + + + UDP-Lite is a Standards-Track IETF transport protocol whose characteristic + is a variable-length checksum. This has advantages for transport of multimedia + (video, VoIP) over wireless networks, as partly damaged packets can still be + fed into the codec instead of being discarded due to a failed checksum test. + + This file briefly describes the existing kernel support and the socket API. + For in-depth information, you can consult: + + o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ + Fom here you can also download some example application source code. + + o The UDP-Lite HOWTO on + http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt + + o The Wireshark UDP-Lite WiKi (with capture files): + http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol + + o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt + + + I) APPLICATIONS + + Several applications have been ported successfully to UDP-Lite. Ethereal + (now called wireshark) has UDP-Litev4/v6 support by default. The tarball on + + http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz + + has source code for several v4/v6 client-server and network testing examples. + + Porting applications to UDP-Lite is straightforward: only socket level and + IPPROTO need to be changed; senders additionally set the checksum coverage + length (default = header length = 8). Details are in the next section. + + + II) PROGRAMMING API + + UDP-Lite provides a connectionless, unreliable datagram service and hence + uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is + very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2) + call so that the statement looks like: + + s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); + + or, respectively, + + s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE); + + With just the above change you are able to run UDP-Lite services or connect + to UDP-Lite servers. The kernel will assume that you are not interested in + using partial checksum coverage and so emulate UDP mode (full coverage). + + To make use of the partial checksum coverage facilities requires setting a + single socket option, which takes an integer specifying the coverage length: + + * Sender checksum coverage: UDPLITE_SEND_CSCOV + + For example, + + int val = 20; + setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int)); + + sets the checksum coverage length to 20 bytes (12b data + 8b header). + Of each packet only the first 20 bytes (plus the pseudo-header) will be + checksummed. This is useful for RTP applications which have a 12-byte + base header. + + + * Receiver checksum coverage: UDPLITE_RECV_CSCOV + + This option is the receiver-side analogue. It is truly optional, i.e. not + required to enable traffic with partial checksum coverage. Its function is + that of a traffic filter: when enabled, it instructs the kernel to drop + all packets which have a coverage _less_ than this value. For example, if + RTP and UDP headers are to be protected, a receiver can enforce that only + packets with a minimum coverage of 20 are admitted: + + int min = 20; + setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int)); + + The calls to getsockopt(2) are analogous. Being an extension and not a stand- + alone protocol, all socket options known from UDP can be used in exactly the + same manner as before, e.g. UDP_CORK or UDP_ENCAP. + + A detailed discussion of UDP-Lite checksum coverage options is in section IV. + + + III) HEADER FILES + + The socket API requires support through header files in /usr/include: + + * /usr/include/netinet/in.h + to define IPPROTO_UDPLITE + + * /usr/include/netinet/udplite.h + for UDP-Lite header fields and protocol constants + + For testing purposes, the following can serve as a `mini' header file: + + #define IPPROTO_UDPLITE 136 + #define SOL_UDPLITE 136 + #define UDPLITE_SEND_CSCOV 10 + #define UDPLITE_RECV_CSCOV 11 + + Ready-made header files for various distros are in the UDP-Lite tarball. + + + IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS + + To enable debugging messages, the log level need to be set to 8, as most + messages use the KERN_DEBUG level (7). + + 1) Sender Socket Options + + If the sender specifies a value of 0 as coverage length, the module + assumes full coverage, transmits a packet with coverage length of 0 + and according checksum. If the sender specifies a coverage < 8 and + different from 0, the kernel assumes 8 as default value. Finally, + if the specified coverage length exceeds the packet length, the packet + length is used instead as coverage length. + + 2) Receiver Socket Options + + The receiver specifies the minimum value of the coverage length it + is willing to accept. A value of 0 here indicates that the receiver + always wants the whole of the packet covered. In this case, all + partially covered packets are dropped and an error is logged. + + It is not possible to specify illegal values (<0 and <8); in these + cases the default of 8 is assumed. + + All packets arriving with a coverage value less than the specified + threshold are discarded, these events are also logged. + + 3) Disabling the Checksum Computation + + On both sender and receiver, checksumming will always be performed + and can not be disabled using SO_NO_CHECK. Thus + + setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... ); + + will always will be ignored, while the value of + + getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); + + is meaningless (as in TCP). Packets with a zero checksum field are + illegal (cf. RFC 3828, sec. 3.1) will be silently discarded. + + 4) Fragmentation + + The checksum computation respects both buffersize and MTU. The size + of UDP-Lite packets is determined by the size of the send buffer. The + minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF + in include/net/sock.h), the default value is configurable as + net.core.wmem_default or via setting the SO_SNDBUF socket(7) + option. The maximum upper bound for the send buffer is determined + by net.core.wmem_max. + + Given a payload size larger than the send buffer size, UDP-Lite will + split the payload into several individual packets, filling up the + send buffer size in each case. + + The precise value also depends on the interface MTU. The interface MTU, + in turn, may trigger IP fragmentation. In this case, the generated + UDP-Lite packet is split into several IP packets, of which only the + first one contains the L4 header. + + The send buffer size has implications on the checksum coverage length. + Consider the following example: + + Payload: 1536 bytes Send Buffer: 1024 bytes + MTU: 1500 bytes Coverage Length: 856 bytes + + UDP-Lite will ship the 1536 bytes in two separate packets: + + Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes + Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes + + The coverage packet covers the UDP-Lite header and 848 bytes of the + payload in the first packet, the second packet is fully covered. Note + that for the second packet, the coverage length exceeds the packet + length. The kernel always re-adjusts the coverage length to the packet + length in such cases. + + As an example of what happens when one UDP-Lite packet is split into + several tiny fragments, consider the following example. + + Payload: 1024 bytes Send buffer size: 1024 bytes + MTU: 300 bytes Coverage length: 575 bytes + + +-+-----------+--------------+--------------+--------------+ + |8| 272 | 280 | 280 | 280 | + +-+-----------+--------------+--------------+--------------+ + 280 560 840 1032 + ^ + *****checksum coverage************* + + The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte + header). According to the interface MTU, these are split into 4 IP + packets (280 byte IP payload + 20 byte IP header). The kernel module + sums the contents of the entire first two packets, plus 15 bytes of + the last packet before releasing the fragments to the IP module. + + To see the analogous case for IPv6 fragmentation, consider a link + MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum + coverage is less than 1232 bytes (MTU minus IPv6/fragment header + lengths), only the first fragment needs to be considered. When using + larger checksum coverage lengths, each eligible fragment needs to be + checksummed. Suppose we have a checksum coverage of 3062. The buffer + of 3356 bytes will be split into the following fragments: + + Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data + Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data + Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data + + The first two fragments have to be checksummed in full, of the last + fragment only 598 (= 3062 - 2*1232) bytes are checksummed. + + While it is important that such cases are dealt with correctly, they + are (annoyingly) rare: UDP-Lite is designed for optimising multimedia + performance over wireless (or generally noisy) links and thus smaller + coverage lenghts are likely to be expected. + + + V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING + + Exceptional and error conditions are logged to syslog at the KERN_DEBUG + level. Live statistics about UDP-Lite are available in /proc/net/snmp + and can (with newer versions of netstat) be viewed using + + netstat -svu + + This displays UDP-Lite statistics variables, whose meaning is as follows. + + InDatagrams: Total number of received datagrams. + + NoPorts: Number of packets received to an unknown port. + These cases are counted separately (not as InErrors). + + InErrors: Number of erroneous UDP-Lite packets. Errors include: + * internal socket queue receive errors + * packet too short (less than 8 bytes or stated + coverage length exceeds received length) + * xfrm4_policy_check() returned with error + * application has specified larger min. coverage + length than that of incoming packet + * checksum coverage violated + * bad checksum + + OutDatagrams: Total number of sent datagrams. + + These statistics derive from the UDP MIB (RFC 2013). + + + VI) IPTABLES + + There is packet match support for UDP-Lite as well as support for the LOG target. + If you copy and paste the following line into /etc/protcols, + + udplite 136 UDP-Lite # UDP-Lite [RFC 3828] + + then + iptables -A INPUT -p udplite -j LOG + + will produce logging output to syslog. Dropping and rejecting packets also works. + + + VII) MAINTAINER ADDRESS + + The UDP-Lite patch was developed at + University of Aberdeen + Electronics Research Group + Department of Engineering + Fraser Noble Building + Aberdeen AB24 3UE; UK + The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial + code was developed by William Stanislaus, <william@erg.abdn.ac.uk>. diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt index 0cf6541..653978d 100644 --- a/Documentation/networking/wan-router.txt +++ b/Documentation/networking/wan-router.txt @@ -412,7 +412,7 @@ beta-2.1.4 Jul 2000 o Dynamic interface configuration: beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix. o Added the Multi-Port PPP - Updated utilites for the Multi-Port PPP. + Updated utilities for the Multi-Port PPP. 2.1.4 Aut 2000 o In X25API: @@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000 o Cpipemon - Added set FT1 commands to the cpipemon. Thus CSU/DSU - configuraiton can be performed using cpipemon. + configuration can be performed using cpipemon. All systems that cannot run cfgft1 GUI utility should use cpipemon to configure the on board CSU/DSU. o Keyboard Led Monitor/Debugger - - A new utilty /usr/sbin/wpkbdmon uses keyboard leds + - A new utility /usr/sbin/wpkbdmon uses keyboard leds to convey operational statistic information of the Sangoma WANPIPE cards. NUM_LOCK = Line State (On=connected, Off=disconnected) @@ -464,7 +464,7 @@ beta1-2.1.5 Nov 15 2000 - Appropriate number of devices are dynamically loaded based on the number of Sangoma cards found. - Note: The kernel configuraiton option + Note: The kernel configuration option CONFIG_WANPIPE_CARDS has been taken out. o Fixed the Frame Relay and Chdlc network interfaces so they are diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt index 8be626f..d7aac9d 100644 --- a/Documentation/networking/xfrm_sync.txt +++ b/Documentation/networking/xfrm_sync.txt @@ -47,10 +47,13 @@ aevent_id structure looks like: struct xfrm_aevent_id { struct xfrm_usersa_id sa_id; + xfrm_address_t saddr; __u32 flags; + __u32 reqid; }; -xfrm_usersa_id in this message layout identifies the SA. +The unique SA is identified by the combination of xfrm_usersa_id, +reqid and saddr. flags are used to indicate different things. The possible flags are: diff --git a/Documentation/pnp.txt b/Documentation/pnp.txt index 9ff966b..28037aa 100644 --- a/Documentation/pnp.txt +++ b/Documentation/pnp.txt @@ -184,7 +184,7 @@ static const struct pnp_id pnp_dev_table[] = { Please note that the character 'X' can be used as a wild card in the function portion (last four characters). ex: - /* Unkown PnP modems */ + /* Unknown PnP modems */ { "PNPCXXX", UNKNOWN_DEV }, Supported PnP card IDs can optionally be defined. diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index 24edf25..c750f9f 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -153,7 +153,7 @@ Description: events, which is implicit if it doesn't even support it in the first place). - Note that the PMC Register in the device's PM Capabilties has a bitmask + Note that the PMC Register in the device's PM Capabilities has a bitmask of the states it supports generating PME# from. D3hot is bit 3 and D3cold is bit 4. So, while a value of 4 as the state may not seem semantically correct, it is. @@ -268,7 +268,7 @@ to wake the system up. (However, it is possible that a device may support some non-standard way of generating a wake event on sleep.) Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's -PM Capabilties describe what power states the device supports generating a +PM Capabilities describe what power states the device supports generating a wake event from: +------------------+ diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 3e5e5d3..0931a33 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt @@ -62,7 +62,7 @@ setup via another operating system for it to use. Despite the inconvenience, this method requires minimal work by the kernel, since the firmware will also handle restoring memory contents on resume. -If the kernel is responsible for persistantly saving state, a mechanism +If the kernel is responsible for persistently saving state, a mechanism called 'swsusp' (Swap Suspend) is used to write memory contents to free swap space. swsusp has some restrictive requirements, but should work in most cases. Some, albeit outdated, documentation can be found diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 9ea2208..e635e6f 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -153,7 +153,7 @@ add: If the thread is needed for writing the image to storage, you should instead set the PF_NOFREEZE process flag when creating the thread (and -be very carefull). +be very careful). Q: What is the difference between "platform", "shutdown" and diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 27b457c..4ac2d64 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -33,13 +33,13 @@ - Change version 16 format to always align property data to 4 bytes. Since tokens are already aligned, that means no specific - required alignement between property size + required alignment between property size and property data. The old style variable alignment would make it impossible to do "simple" insertion of properties using memove (thanks Milton for noticing). Updated kernel patch as well - - Correct a few more alignement constraints + - Correct a few more alignment constraints - Add a chapter about the device-tree compiler and the textural representation of the tree that can be "compiled" by dtc. @@ -854,7 +854,7 @@ address which can extend beyond that limit. console device if any. Typically, if you have serial devices on your board, you may want to put the full path to the one set as the default console in the firmware here, for the kernel to pick - it up as it's own default console. If you look at the funciton + it up as its own default console. If you look at the function set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see that the kernel tries to find out the default console and has knowledge of various types like 8250 serial ports. You may want @@ -1124,7 +1124,7 @@ should have the following properties: - interrupt-parent : contains the phandle of the interrupt controller which handles interrupts for this device - interrupts : a list of tuples representing the interrupt - number and the interrupt sense and level for each interupt + number and the interrupt sense and level for each interrupt for this device. This information is used by the kernel to build the interrupt table diff --git a/Documentation/robust-futex-ABI.txt b/Documentation/robust-futex-ABI.txt index 8529a17..535f69f 100644 --- a/Documentation/robust-futex-ABI.txt +++ b/Documentation/robust-futex-ABI.txt @@ -170,7 +170,7 @@ any point: 1) the 'head' pointer or an subsequent linked list pointer is not a valid address of a user space word 2) the calculated location of the 'lock word' (address plus - 'offset') is not the valud address of a 32 bit user space + 'offset') is not the valid address of a 32 bit user space word 3) if the list contains more than 1 million (subject to future kernel configuration changes) elements. diff --git a/Documentation/robust-futexes.txt b/Documentation/robust-futexes.txt index 76e8064..0a9446a 100644 --- a/Documentation/robust-futexes.txt +++ b/Documentation/robust-futexes.txt @@ -181,7 +181,7 @@ for new threads, without the need of another syscall.] So there is virtually zero overhead for tasks not using robust futexes, and even for robust futex users, there is only one extra syscall per thread lifetime, and the cleanup operation, if it happens, is fast and -straightforward. The kernel doesnt have any internal distinction between +straightforward. The kernel doesn't have any internal distinction between robust and normal futexes. If a futex is found to be held at exit time, the kernel sets the diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 2a58f98..7cf1ec5 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt @@ -1,12 +1,49 @@ - Real Time Clock Driver for Linux - ================================ + Real Time Clock (RTC) Drivers for Linux + ======================================= + +When Linux developers talk about a "Real Time Clock", they usually mean +something that tracks wall clock time and is battery backed so that it +works even with system power off. Such clocks will normally not track +the local time zone or daylight savings time -- unless they dual boot +with MS-Windows -- but will instead be set to Coordinated Universal Time +(UTC, formerly "Greenwich Mean Time"). + +The newest non-PC hardware tends to just count seconds, like the time(2) +system call reports, but RTCs also very commonly represent time using +the Gregorian calendar and 24 hour time, as reported by gmtime(3). + +Linux has two largely-compatible userspace RTC API families you may +need to know about: + + * /dev/rtc ... is the RTC provided by PC compatible systems, + so it's not very portable to non-x86 systems. + + * /dev/rtc0, /dev/rtc1 ... are part of a framework that's + supported by a wide variety of RTC chips on all systems. + +Programmers need to understand that the PC/AT functionality is not +always available, and some systems can do much more. That is, the +RTCs use the same API to make requests in both RTC frameworks (using +different filenames of course), but the hardware may not offer the +same functionality. For example, not every RTC is hooked up to an +IRQ, so they can't all issue alarms; and where standard PC RTCs can +only issue an alarm up to 24 hours in the future, other hardware may +be able to schedule one any time in the upcoming century. + + + Old PC/AT-Compatible driver: /dev/rtc + -------------------------------------- All PCs (even Alpha machines) have a Real Time Clock built into them. Usually they are built into the chipset of the computer, but some may actually have a Motorola MC146818 (or clone) on the board. This is the clock that keeps the date and time while your computer is turned off. +ACPI has standardized that MC146818 functionality, and extended it in +a few ways (enabling longer alarm periods, and wake-from-hibernate). +That functionality is NOT exposed in the old driver. + However it can also be used to generate signals from a slow 2Hz to a relatively fast 8192Hz, in increments of powers of two. These signals are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is @@ -63,223 +100,331 @@ Rather than write 50 pages describing the ioctl() and so on, it is perhaps more useful to include a small test program that demonstrates how to use them, and demonstrates the features of the driver. This is probably a lot more useful to people interested in writing applications -that will be using this driver. +that will be using this driver. See the code at the end of this document. + +(The original /dev/rtc driver was written by Paul Gortmaker.) + + + New portable "RTC Class" drivers: /dev/rtcN + -------------------------------------------- + +Because Linux supports many non-ACPI and non-PC platforms, some of which +have more than one RTC style clock, it needed a more portable solution +than expecting a single battery-backed MC146818 clone on every system. +Accordingly, a new "RTC Class" framework has been defined. It offers +three different userspace interfaces: + + * /dev/rtcN ... much the same as the older /dev/rtc interface + + * /sys/class/rtc/rtcN ... sysfs attributes support readonly + access to some RTC attributes. + + * /proc/driver/rtc ... the first RTC (rtc0) may expose itself + using a procfs interface. More information is (currently) shown + here than through sysfs. + +The RTC Class framework supports a wide variety of RTCs, ranging from those +integrated into embeddable system-on-chip (SOC) processors to discrete chips +using I2C, SPI, or some other bus to communicate with the host CPU. There's +even support for PC-style RTCs ... including the features exposed on newer PCs +through ACPI. + +The new framework also removes the "one RTC per system" restriction. For +example, maybe the low-power battery-backed RTC is a discrete I2C chip, but +a high functionality RTC is integrated into the SOC. That system might read +the system clock from the discrete RTC, but use the integrated one for all +other tasks, because of its greater functionality. + +The ioctl() calls supported by /dev/rtc are also supported by the RTC class +framework. However, because the chips and systems are not standardized, +some PC/AT functionality might not be provided. And in the same way, some +newer features -- including those enabled by ACPI -- are exposed by the +RTC class framework, but can't be supported by the older driver. + + * RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading + time, returning the result as a Gregorian calendar date and 24 hour + wall clock time. To be most useful, this time may also be updated. + + * RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC + is connected to an IRQ line, it can often issue an alarm IRQ up to + 24 hours in the future. + + * RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond + the next 24 hours use a slightly more powerful API, which supports + setting the longer alarm time and enabling its IRQ using a single + request (using the same model as EFI firmware). + + * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably + also offers update IRQs whenever the "seconds" counter changes. + If needed, the RTC framework can emulate this mechanism. + + * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another + feature often accessible with an IRQ line is a periodic IRQ, issued + at settable frequencies (usually 2^N Hz). + +In many cases, the RTC alarm can be a system wake event, used to force +Linux out of a low power sleep state (or hibernation) back to a fully +operational state. For example, a system could enter a deep power saving +state until it's time to execute some scheduled tasks. - Paul Gortmaker -------------------- 8< ---------------- 8< ----------------------------- /* - * Real Time Clock Driver Test/Example Program + * Real Time Clock Driver Test/Example Program * - * Compile with: - * gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest + * Compile with: + * gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest * - * Copyright (C) 1996, Paul Gortmaker. + * Copyright (C) 1996, Paul Gortmaker. * - * Released under the GNU General Public License, version 2, - * included herein by reference. + * Released under the GNU General Public License, version 2, + * included herein by reference. * */ #include <stdio.h> -#include <stdlib.h> #include <linux/rtc.h> #include <sys/ioctl.h> #include <sys/time.h> #include <sys/types.h> #include <fcntl.h> #include <unistd.h> +#include <stdlib.h> #include <errno.h> -int main(void) { - -int i, fd, retval, irqcount = 0; -unsigned long tmp, data; -struct rtc_time rtc_tm; -fd = open ("/dev/rtc", O_RDONLY); +/* + * This expects the new RTC class driver framework, working with + * clocks that will often not be clones of what the PC-AT had. + * Use the command line to specify another RTC if you need one. + */ +static const char default_rtc[] = "/dev/rtc0"; + + +int main(int argc, char **argv) +{ + int i, fd, retval, irqcount = 0; + unsigned long tmp, data; + struct rtc_time rtc_tm; + const char *rtc = default_rtc; + + switch (argc) { + case 2: + rtc = argv[1]; + /* FALLTHROUGH */ + case 1: + break; + default: + fprintf(stderr, "usage: rtctest [rtcdev]\n"); + return 1; + } -if (fd == -1) { - perror("/dev/rtc"); - exit(errno); -} + fd = open(rtc, O_RDONLY); -fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n"); + if (fd == -1) { + perror(rtc); + exit(errno); + } -/* Turn on update interrupts (one per second) */ -retval = ioctl(fd, RTC_UIE_ON, 0); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} + fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n"); -fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:"); -fflush(stderr); -for (i=1; i<6; i++) { - /* This read will block */ - retval = read(fd, &data, sizeof(unsigned long)); + /* Turn on update interrupts (one per second) */ + retval = ioctl(fd, RTC_UIE_ON, 0); if (retval == -1) { - perror("read"); + if (errno == ENOTTY) { + fprintf(stderr, + "\n...Update IRQs not supported.\n"); + goto test_READ; + } + perror("ioctl"); exit(errno); } - fprintf(stderr, " %d",i); + + fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:", + rtc); fflush(stderr); - irqcount++; -} + for (i=1; i<6; i++) { + /* This read will block */ + retval = read(fd, &data, sizeof(unsigned long)); + if (retval == -1) { + perror("read"); + exit(errno); + } + fprintf(stderr, " %d",i); + fflush(stderr); + irqcount++; + } -fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:"); -fflush(stderr); -for (i=1; i<6; i++) { - struct timeval tv = {5, 0}; /* 5 second timeout on select */ - fd_set readfds; + fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:"); + fflush(stderr); + for (i=1; i<6; i++) { + struct timeval tv = {5, 0}; /* 5 second timeout on select */ + fd_set readfds; + + FD_ZERO(&readfds); + FD_SET(fd, &readfds); + /* The select will wait until an RTC interrupt happens. */ + retval = select(fd+1, &readfds, NULL, NULL, &tv); + if (retval == -1) { + perror("select"); + exit(errno); + } + /* This read won't block unlike the select-less case above. */ + retval = read(fd, &data, sizeof(unsigned long)); + if (retval == -1) { + perror("read"); + exit(errno); + } + fprintf(stderr, " %d",i); + fflush(stderr); + irqcount++; + } - FD_ZERO(&readfds); - FD_SET(fd, &readfds); - /* The select will wait until an RTC interrupt happens. */ - retval = select(fd+1, &readfds, NULL, NULL, &tv); + /* Turn off update interrupts */ + retval = ioctl(fd, RTC_UIE_OFF, 0); if (retval == -1) { - perror("select"); + perror("ioctl"); exit(errno); } - /* This read won't block unlike the select-less case above. */ - retval = read(fd, &data, sizeof(unsigned long)); + +test_READ: + /* Read the RTC time/date */ + retval = ioctl(fd, RTC_RD_TIME, &rtc_tm); if (retval == -1) { - perror("read"); + perror("ioctl"); exit(errno); } - fprintf(stderr, " %d",i); - fflush(stderr); - irqcount++; -} - -/* Turn off update interrupts */ -retval = ioctl(fd, RTC_UIE_OFF, 0); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} - -/* Read the RTC time/date */ -retval = ioctl(fd, RTC_RD_TIME, &rtc_tm); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} - -fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n", - rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900, - rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec); - -/* Set the alarm to 5 sec in the future, and check for rollover */ -rtc_tm.tm_sec += 5; -if (rtc_tm.tm_sec >= 60) { - rtc_tm.tm_sec %= 60; - rtc_tm.tm_min++; -} -if (rtc_tm.tm_min == 60) { - rtc_tm.tm_min = 0; - rtc_tm.tm_hour++; -} -if (rtc_tm.tm_hour == 24) - rtc_tm.tm_hour = 0; - -retval = ioctl(fd, RTC_ALM_SET, &rtc_tm); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} - -/* Read the current alarm settings */ -retval = ioctl(fd, RTC_ALM_READ, &rtc_tm); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} - -fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n", - rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec); -/* Enable alarm interrupts */ -retval = ioctl(fd, RTC_AIE_ON, 0); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} + fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n", + rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900, + rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec); -fprintf(stderr, "Waiting 5 seconds for alarm..."); -fflush(stderr); -/* This blocks until the alarm ring causes an interrupt */ -retval = read(fd, &data, sizeof(unsigned long)); -if (retval == -1) { - perror("read"); - exit(errno); -} -irqcount++; -fprintf(stderr, " okay. Alarm rang.\n"); - -/* Disable alarm interrupts */ -retval = ioctl(fd, RTC_AIE_OFF, 0); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} + /* Set the alarm to 5 sec in the future, and check for rollover */ + rtc_tm.tm_sec += 5; + if (rtc_tm.tm_sec >= 60) { + rtc_tm.tm_sec %= 60; + rtc_tm.tm_min++; + } + if (rtc_tm.tm_min == 60) { + rtc_tm.tm_min = 0; + rtc_tm.tm_hour++; + } + if (rtc_tm.tm_hour == 24) + rtc_tm.tm_hour = 0; -/* Read periodic IRQ rate */ -retval = ioctl(fd, RTC_IRQP_READ, &tmp); -if (retval == -1) { - perror("ioctl"); - exit(errno); -} -fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp); + retval = ioctl(fd, RTC_ALM_SET, &rtc_tm); + if (retval == -1) { + if (errno == ENOTTY) { + fprintf(stderr, + "\n...Alarm IRQs not supported.\n"); + goto test_PIE; + } + perror("ioctl"); + exit(errno); + } -fprintf(stderr, "Counting 20 interrupts at:"); -fflush(stderr); + /* Read the current alarm settings */ + retval = ioctl(fd, RTC_ALM_READ, &rtc_tm); + if (retval == -1) { + perror("ioctl"); + exit(errno); + } -/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */ -for (tmp=2; tmp<=64; tmp*=2) { + fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n", + rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec); - retval = ioctl(fd, RTC_IRQP_SET, tmp); + /* Enable alarm interrupts */ + retval = ioctl(fd, RTC_AIE_ON, 0); if (retval == -1) { perror("ioctl"); exit(errno); } - fprintf(stderr, "\n%ldHz:\t", tmp); + fprintf(stderr, "Waiting 5 seconds for alarm..."); fflush(stderr); + /* This blocks until the alarm ring causes an interrupt */ + retval = read(fd, &data, sizeof(unsigned long)); + if (retval == -1) { + perror("read"); + exit(errno); + } + irqcount++; + fprintf(stderr, " okay. Alarm rang.\n"); - /* Enable periodic interrupts */ - retval = ioctl(fd, RTC_PIE_ON, 0); + /* Disable alarm interrupts */ + retval = ioctl(fd, RTC_AIE_OFF, 0); if (retval == -1) { perror("ioctl"); exit(errno); } - for (i=1; i<21; i++) { - /* This blocks */ - retval = read(fd, &data, sizeof(unsigned long)); +test_PIE: + /* Read periodic IRQ rate */ + retval = ioctl(fd, RTC_IRQP_READ, &tmp); + if (retval == -1) { + /* not all RTCs support periodic IRQs */ + if (errno == ENOTTY) { + fprintf(stderr, "\nNo periodic IRQ support\n"); + return 0; + } + perror("ioctl"); + exit(errno); + } + fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp); + + fprintf(stderr, "Counting 20 interrupts at:"); + fflush(stderr); + + /* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */ + for (tmp=2; tmp<=64; tmp*=2) { + + retval = ioctl(fd, RTC_IRQP_SET, tmp); if (retval == -1) { - perror("read"); - exit(errno); + /* not all RTCs can change their periodic IRQ rate */ + if (errno == ENOTTY) { + fprintf(stderr, + "\n...Periodic IRQ rate is fixed\n"); + goto done; + } + perror("ioctl"); + exit(errno); } - fprintf(stderr, " %d",i); + + fprintf(stderr, "\n%ldHz:\t", tmp); fflush(stderr); - irqcount++; - } - /* Disable periodic interrupts */ - retval = ioctl(fd, RTC_PIE_OFF, 0); - if (retval == -1) { - perror("ioctl"); - exit(errno); + /* Enable periodic interrupts */ + retval = ioctl(fd, RTC_PIE_ON, 0); + if (retval == -1) { + perror("ioctl"); + exit(errno); + } + + for (i=1; i<21; i++) { + /* This blocks */ + retval = read(fd, &data, sizeof(unsigned long)); + if (retval == -1) { + perror("read"); + exit(errno); + } + fprintf(stderr, " %d",i); + fflush(stderr); + irqcount++; + } + + /* Disable periodic interrupts */ + retval = ioctl(fd, RTC_PIE_OFF, 0); + if (retval == -1) { + perror("ioctl"); + exit(errno); + } } -} -fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n"); -fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n", - irqcount); +done: + fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n"); -close(fd); -return 0; + close(fd); -} /* end main */ + return 0; +} diff --git a/Documentation/s390/crypto/crypto-API.txt b/Documentation/s390/crypto/crypto-API.txt index 29dee79..41a8b07 100644 --- a/Documentation/s390/crypto/crypto-API.txt +++ b/Documentation/s390/crypto/crypto-API.txt @@ -75,8 +75,8 @@ name of the respective module is given in square brackets. - SHA1 Digest Algorithm [sha1 -> sha1_z990] - DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990] -- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990] -- Tripple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990] +- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990] +- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990] In order to load, for example, the sha1_z990 module when the sha1 algorithm is requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf. diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt index 904d49e..6aa9a89 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt @@ -127,7 +127,7 @@ The following information is available in this file: - Correct a reference to free'ed memory during controller shutdown. - Reset the bus on an SE->LVD change. This is required - to reset our transcievers. + to reset our transceivers. 1.3.5 (March 24th, 2003) - Fix a few register window mode bugs. @@ -169,7 +169,7 @@ The following information is available in this file: 1.3.0 (January 21st, 2003) - Full regression testing for all U320 products completed. - Added abort and target/lun reset error recovery handler and - interrupt coalessing. + interrupt coalescing. 1.2.0 (November 14th, 2002) - Added support for Domain Validation diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt index c92f447..05667e7 100644 --- a/Documentation/scsi/aic7xxx_old.txt +++ b/Documentation/scsi/aic7xxx_old.txt @@ -256,7 +256,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD En/Disable High Byte LVD Termination The upper 2 bits that deal with LVD termination only apply to Ultra2 - controllers. Futhermore, due to the current Ultra2 controller + controllers. Furthermore, due to the current Ultra2 controller designs, these bits are tied together such that setting either bit enables both low and high byte LVD termination. It is not possible to only set high or low byte LVD termination in this manner. This is @@ -436,7 +436,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD the commas to periods, insmod won't interpret this as more than one string and write junk into our binary image. I consider it a bug in the insmod program that even if you wrap your string in quotes (quotes - that pass the shell mind you and that insmod sees) it still treates + that pass the shell mind you and that insmod sees) it still treats a comma inside of those quotes as starting a new variable, resulting in memory scribbles if you don't switch the commas to periods. diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index 35f6b8e..9707941 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt @@ -461,7 +461,7 @@ This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which allows data to be written from the system to the device. It is a necessary step to be allowed to set blocksize of SCSI-tape-drives and - the tape-speed, whithout confusing the SCSI-Subsystem. + the tape-speed, without confusing the SCSI-Subsystem. 2) The recognition of a tape is included in the check_devices routine. This is done by checking for TYPE_TAPE, that is already defined in the kernel-scsi-environment. The markup of a tape is done in the @@ -710,8 +710,8 @@ of troubles with some controllers and after I wanted to apply some extensions, it jumped out in the same situation, on my w/cache, as like on D. Weinehalls' Model 56, having integrated SCSI. This gave me the - descissive hint to move the code-part out and declare it global. Now, - it seems to work by far much better an more stable. Let us see, what + decisive hint to move the code-part out and declare it global. Now + it seems to work far better and more stable. Let us see what the world thinks of it... 3) By the way, only Sony DAT-drives seem to show density code 0x13. A test with a HP drive gave right results, so the problem is vendor- @@ -822,10 +822,10 @@ A long period of collecting bugreports from all corners of the world now lead to the following corrections to the code: 1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this - was, that it is possible to disbale Fast-SCSI for the external bus. - The feature-control command, where this crash appeared regularly tried + was that it is possible to disable Fast-SCSI for the external bus. + The feature-control command, where this crash appeared regularly, tried to set the maximum speed of 10MHz synchronous transfer speed and that - reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now, + reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now, the feature-command probes down from maximum speed until the adapter stops to complain, which is at the same time the maximum possible speed selected in the reference program. So, F/W external can run at @@ -920,7 +920,7 @@ completed in such a way, that they are now completely conform to the demands in the technical description of IBM. Main candidates were the DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must - be tranferred by bypassing the internal command buffer of the adapter + be transferred by bypassing the internal command buffer of the adapter or else the response can be a random result. GET_POS_INFO would be more safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this is not allowed by the technical references of IBM. (Sorry, folks, the diff --git a/Documentation/scsi/in2000.txt b/Documentation/scsi/in2000.txt index 80f1040..c3e2a90 100644 --- a/Documentation/scsi/in2000.txt +++ b/Documentation/scsi/in2000.txt @@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98 UPDATE NEWS: version 1.31 - 6 Jul 97 Fixed a bug that caused incorrect SCSI status bytes to be - returned from commands sent to LUN's greater than 0. This + returned from commands sent to LUNs greater than 0. This means that CDROM changers work now! Fixed a bug in the handling of command-line arguments when loaded as a module. Also put all the header data in in2000.h where it belongs. diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt index 9e2078b..aa54f54 100644 --- a/Documentation/scsi/libsas.txt +++ b/Documentation/scsi/libsas.txt @@ -393,7 +393,7 @@ struct sas_task { task_proto -- _one_ of enum sas_proto scatter -- pointer to scatter gather list array num_scatter -- number of elements in scatter - total_xfer_len -- total number of bytes expected to be transfered + total_xfer_len -- total number of bytes expected to be transferred data_dir -- PCI_DMA_... task_done -- callback when the task has finished execution }; diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 58ad8db..caf10b1 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server: ftp://ftp.symbios.com/ -Usefull SCSI tools written by Eric Youngdale are available at tsx-11: +Useful SCSI tools written by Eric Youngdale are available at tsx-11: ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt index d74bbd2..032399b 100644 --- a/Documentation/scsi/scsi-changer.txt +++ b/Documentation/scsi/scsi-changer.txt @@ -88,7 +88,7 @@ If the module finds the changer, it prints some messages about the device [ try "dmesg" if you don't see anything ] and should show up in /proc/devices. If not.... some changers use ID ? / LUN 0 for the device and ID ? / LUN 1 for the robot mechanism. But Linux does *not* -look for LUN's other than 0 as default, becauce there are to many +look for LUNs other than 0 as default, because there are too many broken devices. So you can try: 1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi @@ -107,7 +107,7 @@ because the kernel will translate the error codes into human-readable strings then. You can display these messages with the dmesg command (or check the -logfiles). If you email me some question becauce of a problem with the +logfiles). If you email me some question because of a problem with the driver, please include these messages. diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt index b964eef..7acbebb 100644 --- a/Documentation/scsi/scsi_eh.txt +++ b/Documentation/scsi/scsi_eh.txt @@ -75,7 +75,7 @@ with the command. - otherwise scsi_eh_scmd_add(scmd, 0) is invoked for the command. See - [1-3] for details of this funciton. + [1-3] for details of this function. [1-2-2] Completing a scmd w/ timeout diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index 5ff65b1..3c12422 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -261,7 +261,7 @@ pairs are separated with a comma (no spaces allowed). A colon can be used instead of the equal mark. The definition is prepended by the string st=. Here is an example: - st=buffer_kbs:64,write_threhold_kbs:60 + st=buffer_kbs:64,write_threshold_kbs:60 The following syntax used by the old kernel versions is also supported: diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index 26c8a08..2c1745a 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -609,7 +609,7 @@ appropriate mailing lists or news-groups. Send me a copy in order to be sure I will receive it. Obviously, a bug in the driver code is possible. - My cyrrent email address: Gerard Roudier <groudier@free.fr> + My current email address: Gerard Roudier <groudier@free.fr> Allowing disconnections is important if you use several devices on your SCSI bus but often causes problems with buggy devices. diff --git a/Documentation/sharedsubtree.txt b/Documentation/sharedsubtree.txt index 2d8f403..ccf1ceb 100644 --- a/Documentation/sharedsubtree.txt +++ b/Documentation/sharedsubtree.txt @@ -942,13 +942,13 @@ replicas continue to be exactly same. ->mnt_slave ->mnt_master - ->mnt_share links togather all the mount to/from which this vfsmount + ->mnt_share links together all the mount to/from which this vfsmount send/receives propagation events. ->mnt_slave_list links all the mounts to which this vfsmount propagates to. - ->mnt_slave links togather all the slaves that its master vfsmount + ->mnt_slave links together all the slaves that its master vfsmount propagates to. ->mnt_master points to the master vfsmount from which this vfsmount diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 3472d9c..9fef210 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -955,7 +955,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. dmx6fire, dsp24, dsp24_value, dsp24_71, ez8, phase88, mediastation omni - Omni I/O support for MidiMan M-Audio Delta44/66 - cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever) + cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transceiver) in msec resolution, default value is 500 (0.5 sec) This module supports multiple cards and autoprobe. Note: The consumer part diff --git a/Documentation/sound/alsa/Audigy-mixer.txt b/Documentation/sound/alsa/Audigy-mixer.txt index 5132fd9..7f10dc6 100644 --- a/Documentation/sound/alsa/Audigy-mixer.txt +++ b/Documentation/sound/alsa/Audigy-mixer.txt @@ -6,7 +6,7 @@ This is based on SB-Live-mixer.txt. The EMU10K2 chips have a DSP part which can be programmed to support various ways of sample processing, which is described here. -(This acticle does not deal with the overall functionality of the +(This article does not deal with the overall functionality of the EMU10K2 chips. See the manuals section for further details.) The ALSA driver programs this portion of chip by default code diff --git a/Documentation/sound/alsa/SB-Live-mixer.txt b/Documentation/sound/alsa/SB-Live-mixer.txt index 651adaf..f5639d4 100644 --- a/Documentation/sound/alsa/SB-Live-mixer.txt +++ b/Documentation/sound/alsa/SB-Live-mixer.txt @@ -5,7 +5,7 @@ The EMU10K1 chips have a DSP part which can be programmed to support various ways of sample processing, which is described here. -(This acticle does not deal with the overall functionality of the +(This article does not deal with the overall functionality of the EMU10K1 chips. See the manuals section for further details.) The ALSA driver programs this portion of chip by default code diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index 02a4812..c815c52 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -50,7 +50,7 @@ Review cycle: Contact the kernel security team for more details on this procedure. -Review committe: +Review committee: - This is made up of a number of kernel developers who have volunteered for this task, and a few that haven't. diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 5c3a519..aa986a3 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt @@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are readable by root only. This allows the end user to remove such a dump but not access it directly. For security reasons core dumps in this mode will not overwrite one another or - other files. This mode is appropriate when adminstrators are + other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment. ============================================================== diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 20d0d79..e96a341 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -129,7 +129,7 @@ the high water marks for each per cpu page list. zone_reclaim_mode: -Zone_reclaim_mode allows to set more or less agressive approaches to +Zone_reclaim_mode allows someone to set more or less aggressive approaches to reclaim memory when a zone runs out of memory. If it is set to zero then no zone reclaim occurs. Allocations will be satisfied from other zones / nodes in the system. diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/uml/UserModeLinux-HOWTO.txt index b60590e..628013f 100644 --- a/Documentation/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/uml/UserModeLinux-HOWTO.txt @@ -1477,7 +1477,7 @@ - Making it world-writeable looks bad, but it seems not to be + Making it world-writable looks bad, but it seems not to be exploitable as a security hole. However, it does allow anyone to cre- ate useless tap devices (useless because they can't configure them), which is a DOS attack. A somewhat more secure alternative would to be diff --git a/Documentation/usb/hiddev.txt b/Documentation/usb/hiddev.txt index 6a79075..6e8c9f1 100644 --- a/Documentation/usb/hiddev.txt +++ b/Documentation/usb/hiddev.txt @@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big examples for this are power devices (especially uninterruptable power supplies) and monitor control on higher end monitors. -To support these disparite requirements, the Linux USB system provides +To support these disparate requirements, the Linux USB system provides HID events to two separate interfaces: * the input subsystem, which converts HID events into normal input device interfaces (such as keyboard, mouse and joystick) and a diff --git a/Documentation/usb/rio.txt b/Documentation/usb/rio.txt index ab21db4..aee715a 100644 --- a/Documentation/usb/rio.txt +++ b/Documentation/usb/rio.txt @@ -24,10 +24,10 @@ are in no way responsible for any damage that may occur, no matter how inconsequential. It seems that the Rio has a problem when sending .mp3 with low batteries. -I suggest when the batteries are low and want to transfer stuff that you +I suggest when the batteries are low and you want to transfer stuff that you replace it with a fresh one. In my case, what happened is I lost two 16kb blocks (they are no longer usable to store information to it). But I don't -know if thats normal or not. It could simply be a problem with the flash +know if that's normal or not; it could simply be a problem with the flash memory. In an extreme case, I left my Rio playing overnight and the batteries wore diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 50436e1..d61f6e7 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -175,7 +175,7 @@ Keyspan USA-series Serial Adapters Current status: The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and - have been pretty throughly tested at various baud rates with 8-N-1 + have been pretty thoroughly tested at various baud rates with 8-N-1 character settings. Other character lengths and parity setups are presently untested. @@ -253,7 +253,7 @@ Cypress M8 CY4601 Family Serial Driver together without hacking the adapter to set the line high. The driver is smp safe. Performance with the driver is rather low when using - it for transfering files. This is being worked on, but I would be willing to + it for transferring files. This is being worked on, but I would be willing to accept patches. An urb queue or packet buffer would likely fit the bill here. If you have any questions, problems, patches, feature requests, etc. you can @@ -297,7 +297,7 @@ Belkin USB Serial Adapter F5U103 Parity N,E,O,M,S Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)* Break Set and clear - Line contrl Input/Output query and control ** + Line control Input/Output query and control ** * Hardware input flow control is only enabled for firmware levels above 2.06. Read source code comments describing Belkin @@ -309,7 +309,7 @@ Belkin USB Serial Adapter F5U103 automatic hardware flow control. TO DO List: - -- Add true modem contol line query capability. Currently tracks the + -- Add true modem control line query capability. Currently tracks the states reported by the interrupt and the states requested. -- Add error reporting back to application for UART error conditions. -- Add support for flush ioctls. diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt index 7e8ae83..8d16f6f 100644 --- a/Documentation/watchdog/watchdog-api.txt +++ b/Documentation/watchdog/watchdog-api.txt @@ -214,7 +214,7 @@ returned value is the temperature in degrees fahrenheit. Finally the SETOPTIONS ioctl can be used to control some aspects of the cards operation; right now the pcwd driver is the only one -supporting thiss ioctl. +supporting this ioctl. int options = 0; ioctl(fd, WDIOC_SETOPTIONS, options); |
