Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Conflicts: drivers/infiniband/core/iwcm.c drivers/net/chelsio/cxgb2.c drivers/net/wireless/bcm43xx/bcm43xx_main.c drivers/net/wireless/prism54/islpci_eth.c drivers/usb/core/hub.h drivers/usb/input/hid-core.c net/core/netpoll.c Fix up merge failures with Linus's head and fix new compilation failures. Signed-Off-By: David Howells <dhowells@redhat.com>
This commit is contained in:
David Howells
David Howells
Коммит
4c1ac1b491
3
CREDITS
3
CREDITS
|
|
@ -2598,6 +2598,9 @@ S: Ucitelska 1576
|
|||
S: Prague 8
|
||||
S: 182 00 Czech Republic
|
||||
|
||||
N: Rick Payne
|
||||
D: RFC2385 Support for TCP
|
||||
|
||||
N: Barak A. Pearlmutter
|
||||
E: bap@cs.unm.edu
|
||||
W: http://www.cs.unm.edu/~bap/
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -345,7 +345,6 @@ 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);
|
||||
kfree (dev);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
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.
|
||||
|
||||
struct platform_device {
|
||||
const char *name;
|
||||
u32 id;
|
||||
struct device dev;
|
||||
u32 num_resources;
|
||||
struct resource *resource;
|
||||
};
|
||||
|
||||
|
||||
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.
|
||||
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 *))
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
Device Naming and Driver Binding
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The platform_device.dev.bus_id is the canonical name for the devices.
|
||||
It's built from two components:
|
||||
|
||||
But, besides the organizational benefits, the platform bus can also
|
||||
accommodate firmware-based enumeration.
|
||||
* 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.
|
||||
|
||||
Device Discovery
|
||||
~~~~~~~~~~~~~~~~
|
||||
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:
|
||||
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".
|
||||
|
||||
platform_bus.add(parent,bus_id).
|
||||
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.
|
||||
|
||||
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.
|
||||
- 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.
|
||||
|
||||
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.
|
||||
- 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.)
|
||||
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 :
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
---------------------------
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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-
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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) |
|
||||
+--------+----------+-----------------------------------------+
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
========================
|
||||
|
|
@ -57,22 +61,21 @@ 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.
|
||||
|
|
@ -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,14 +131,55 @@ 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
|
||||
(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
|
||||
|
||||
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.
|
||||
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
|
||||
|
|
@ -142,7 +187,7 @@ NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
|
|||
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
|
||||
|
|
@ -158,7 +203,7 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
|
|||
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
|
||||
|
|
@ -168,16 +213,25 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
|
|||
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
|
||||
|
|
@ -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,7 +391,6 @@ 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
|
||||
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
|
||||
|
|
@ -346,11 +399,11 @@ Additional Configurations
|
|||
To learn the proper way to configure a network device for your system,
|
||||
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,7 +411,6 @@ 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
|
||||
on your console, set dmesg to eight by entering the following:
|
||||
|
|
@ -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
|
||||
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 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
|
||||
|
||||
- The Intel PRO/1000 PM Network Connection does not support jumbo frames.
|
||||
- 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.
|
||||
|
|
@ -423,7 +496,6 @@ Additional Configurations
|
|||
|
||||
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,
|
||||
download and install Ethtool from the following website:
|
||||
|
|
@ -436,9 +508,15 @@ 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
|
||||
the default, use the following compile-time flags.
|
||||
|
|
@ -457,89 +535,106 @@ Additional Configurations
|
|||
Known Issues
|
||||
============
|
||||
|
||||
Jumbo Frames System Requirement
|
||||
-------------------------------
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
-----------------------------------------
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
------------------------------------------------------
|
||||
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.
|
||||
|
||||
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:
|
||||
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),
|
||||
(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:
|
||||
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
|
||||
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).
|
||||
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:
|
||||
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.
|
||||
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>
|
||||
# make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
|
||||
|
||||
Where <n> is:
|
||||
Where <n> is:
|
||||
|
||||
0 = Hardware default
|
||||
1 = Master mode
|
||||
2 = Slave mode
|
||||
3 = Auto master/slave
|
||||
|
||||
Disable rx flow control with ethtool
|
||||
------------------------------------
|
||||
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.
|
||||
|
||||
In order to disable receive flow control using ethtool, you must turn
|
||||
off auto-negotiation on the same command line.
|
||||
|
||||
For example:
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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,15 +117,68 @@ 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_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_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_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_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_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
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
|
||||
by our side. Peer can be broken and never close its side,
|
||||
or even died unexpectedly. Default value is 60sec.
|
||||
Usual value used in 2.2 was 180 seconds, you may restore
|
||||
it, but remember that if your machine is even underloaded WEB server,
|
||||
you risk to overflow memory with kilotons of dead sockets,
|
||||
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
|
||||
because they eat maximum 1.5K of memory, but they tend
|
||||
to live longer. Cf. tcp_max_orphans.
|
||||
|
||||
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_keepalive_time - INTEGER
|
||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
||||
|
|
@ -136,54 +194,13 @@ tcp_keepalive_intvl - INTEGER
|
|||
after probes started. Default value: 75sec i.e. connection
|
||||
will be aborted after ~11 minutes of retries.
|
||||
|
||||
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_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_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_fin_timeout - INTEGER
|
||||
Time to hold socket in state FIN-WAIT-2, if it was closed
|
||||
by our side. Peer can be broken and never close its side,
|
||||
or even died unexpectedly. Default value is 60sec.
|
||||
Usual value used in 2.2 was 180 seconds, you may restore
|
||||
it, but remember that if your machine is even underloaded WEB server,
|
||||
you risk to overflow memory with kilotons of dead sockets,
|
||||
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
|
||||
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_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_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_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,13 +214,106 @@ 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_max_syn_backlog - INTEGER
|
||||
Maximal number of remembered connection requests, which are
|
||||
still did not receive an acknowledgment from connecting client.
|
||||
Default value is 1024 for systems with more than 128Mb of memory,
|
||||
and 128 for low memory machines. If server suffers of overload,
|
||||
try to increase this number.
|
||||
|
||||
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_mem - vector of 3 INTEGERs: min, pressure, max
|
||||
min: below this number of pages TCP is not bothered about its
|
||||
memory appetite.
|
||||
|
||||
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".
|
||||
|
||||
max: number of pages allowed for queueing by all TCP sockets.
|
||||
|
||||
Defaults are calculated at boot time from amount of available
|
||||
memory.
|
||||
|
||||
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.
|
||||
Default: 3
|
||||
|
||||
tcp_retrans_collapse - BOOLEAN
|
||||
Bug-to-bug compatibility with some broken printers.
|
||||
On retransmit try to send bigger packets to work around bugs in
|
||||
certain TCP stacks.
|
||||
|
||||
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_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_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.
|
||||
It is guaranteed to each TCP socket, even under moderate memory
|
||||
pressure.
|
||||
Default: 8K
|
||||
|
||||
default: default size of receive buffer used by TCP sockets.
|
||||
This value overrides net.core.rmem_default used by other protocols.
|
||||
Default: 87380 bytes. This value results in window of 65535 with
|
||||
default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit
|
||||
less for default tcp_app_win. See below about these variables.
|
||||
|
||||
max: maximal size of receive buffer allowed for automatically
|
||||
selected receiver buffers for TCP socket. This value does not override
|
||||
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
|
||||
Default: 87380*2 bytes.
|
||||
|
||||
tcp_sack - BOOLEAN
|
||||
Enable select acknowledgments (SACKS).
|
||||
|
||||
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
|
||||
|
||||
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_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_syncookies - BOOLEAN
|
||||
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
|
||||
|
|
@ -226,46 +336,34 @@ tcp_syncookies - BOOLEAN
|
|||
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.
|
||||
Default value is 1024 for systems with more than 128Mb of memory,
|
||||
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_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_sack - BOOLEAN
|
||||
Enable select acknowledgments (SACKS).
|
||||
|
||||
tcp_fack - BOOLEAN
|
||||
Enable FACK congestion avoidance and fast retransmission.
|
||||
The value is not used, if tcp_sack is not enabled.
|
||||
|
||||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
tcp_ecn - BOOLEAN
|
||||
Enable Explicit Congestion Notification in TCP.
|
||||
|
||||
tcp_reordering - INTEGER
|
||||
Maximal reordering of packets in a TCP stream.
|
||||
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
|
||||
|
||||
tcp_retrans_collapse - BOOLEAN
|
||||
Bug-to-bug compatibility with some broken printers.
|
||||
On retransmit try to send bigger packets to work around bugs in
|
||||
certain TCP stacks.
|
||||
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_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_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.
|
||||
|
|
@ -282,85 +380,6 @@ tcp_wmem - vector of 3 INTEGERs: min, default, max
|
|||
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
|
||||
Default: 128K
|
||||
|
||||
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
||||
min: Minimal size of receive buffer used by TCP sockets.
|
||||
It is guaranteed to each TCP socket, even under moderate memory
|
||||
pressure.
|
||||
Default: 8K
|
||||
|
||||
default: default size of receive buffer used by TCP sockets.
|
||||
This value overrides net.core.rmem_default used by other protocols.
|
||||
Default: 87380 bytes. This value results in window of 65535 with
|
||||
default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit
|
||||
less for default tcp_app_win. See below about these variables.
|
||||
|
||||
max: maximal size of receive buffer allowed for automatically
|
||||
selected receiver buffers for TCP socket. This value does not override
|
||||
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.
|
||||
|
||||
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".
|
||||
|
||||
max: number of pages allowed for queueing by all TCP sockets.
|
||||
|
||||
Defaults are calculated at boot time from amount of available
|
||||
memory.
|
||||
|
||||
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_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_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_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_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
|
||||
|
||||
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_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.
|
||||
|
||||
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_workaround_signed_windows - BOOLEAN
|
||||
If set, assume no receipt of a window scaling option means the
|
||||
remote TCP is broken and treats the window as a signed quantity.
|
||||
|
|
@ -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 $
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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):
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
+------------------+
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,9 +100,73 @@ 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< -----------------------------
|
||||
|
||||
|
|
@ -83,40 +184,67 @@ that will be using this driver.
|
|||
*/
|
||||
|
||||
#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;
|
||||
/*
|
||||
* 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";
|
||||
|
||||
fd = open ("/dev/rtc", O_RDONLY);
|
||||
|
||||
if (fd == -1) {
|
||||
perror("/dev/rtc");
|
||||
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;
|
||||
}
|
||||
|
||||
fd = open(rtc, O_RDONLY);
|
||||
|
||||
if (fd == -1) {
|
||||
perror(rtc);
|
||||
exit(errno);
|
||||
}
|
||||
}
|
||||
|
||||
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
|
||||
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
|
||||
|
||||
/* Turn on update interrupts (one per second) */
|
||||
retval = ioctl(fd, RTC_UIE_ON, 0);
|
||||
if (retval == -1) {
|
||||
/* Turn on update interrupts (one per second) */
|
||||
retval = ioctl(fd, RTC_UIE_ON, 0);
|
||||
if (retval == -1) {
|
||||
if (errno == ENOTTY) {
|
||||
fprintf(stderr,
|
||||
"\n...Update IRQs not supported.\n");
|
||||
goto test_READ;
|
||||
}
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
}
|
||||
|
||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
|
||||
fflush(stderr);
|
||||
for (i=1; i<6; i++) {
|
||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
|
||||
rtc);
|
||||
fflush(stderr);
|
||||
for (i=1; i<6; i++) {
|
||||
/* This read will block */
|
||||
retval = read(fd, &data, sizeof(unsigned long));
|
||||
if (retval == -1) {
|
||||
|
|
@ -126,11 +254,11 @@ for (i=1; i<6; i++) {
|
|||
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++) {
|
||||
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;
|
||||
|
||||
|
|
@ -151,96 +279,114 @@ for (i=1; i<6; i++) {
|
|||
fprintf(stderr, " %d",i);
|
||||
fflush(stderr);
|
||||
irqcount++;
|
||||
}
|
||||
}
|
||||
|
||||
/* Turn off update interrupts */
|
||||
retval = ioctl(fd, RTC_UIE_OFF, 0);
|
||||
if (retval == -1) {
|
||||
/* 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) {
|
||||
test_READ:
|
||||
/* 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",
|
||||
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) {
|
||||
/* 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) {
|
||||
}
|
||||
if (rtc_tm.tm_min == 60) {
|
||||
rtc_tm.tm_min = 0;
|
||||
rtc_tm.tm_hour++;
|
||||
}
|
||||
if (rtc_tm.tm_hour == 24)
|
||||
}
|
||||
if (rtc_tm.tm_hour == 24)
|
||||
rtc_tm.tm_hour = 0;
|
||||
|
||||
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
|
||||
if (retval == -1) {
|
||||
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);
|
||||
}
|
||||
}
|
||||
|
||||
/* Read the current alarm settings */
|
||||
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
|
||||
if (retval == -1) {
|
||||
/* 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",
|
||||
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) {
|
||||
/* Enable alarm interrupts */
|
||||
retval = ioctl(fd, RTC_AIE_ON, 0);
|
||||
if (retval == -1) {
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
}
|
||||
|
||||
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) {
|
||||
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");
|
||||
}
|
||||
irqcount++;
|
||||
fprintf(stderr, " okay. Alarm rang.\n");
|
||||
|
||||
/* Disable alarm interrupts */
|
||||
retval = ioctl(fd, RTC_AIE_OFF, 0);
|
||||
if (retval == -1) {
|
||||
/* Disable alarm interrupts */
|
||||
retval = ioctl(fd, RTC_AIE_OFF, 0);
|
||||
if (retval == -1) {
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
}
|
||||
|
||||
/* Read periodic IRQ rate */
|
||||
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
|
||||
if (retval == -1) {
|
||||
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 was %ldHz.\n", tmp);
|
||||
}
|
||||
fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);
|
||||
|
||||
fprintf(stderr, "Counting 20 interrupts at:");
|
||||
fflush(stderr);
|
||||
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) {
|
||||
/* 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) {
|
||||
/* 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);
|
||||
}
|
||||
|
|
@ -273,13 +419,12 @@ for (tmp=2; tmp<=64; tmp*=2) {
|
|||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
}
|
||||
|
||||
done:
|
||||
fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
|
||||
|
||||
close(fd);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
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);
|
||||
|
||||
close(fd);
|
||||
return 0;
|
||||
|
||||
} /* end main */
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
==============================================================
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
25
MAINTAINERS
25
MAINTAINERS
|
|
@ -353,6 +353,12 @@ P: Richard Purdie
|
|||
M: rpurdie@rpsys.net
|
||||
S: Maintained
|
||||
|
||||
ARM/HP JORNADA 7XX MACHINE SUPPORT
|
||||
P: Kristoffer Ericson
|
||||
M: kristoffer_e1@hotmail.com
|
||||
W: www.jlime.com
|
||||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dirk Opfer
|
||||
M: dirk@opfer-online.de
|
||||
|
|
@ -426,6 +432,13 @@ L: linux-atm-general@lists.sourceforge.net (subscribers-only)
|
|||
W: http://linux-atm.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
ATMEL MACB ETHERNET DRIVER
|
||||
P: Atmel AVR32 Support Team
|
||||
M: avr32@atmel.com
|
||||
P: Haavard Skinnemoen
|
||||
M: hskinnemoen@atmel.com
|
||||
S: Supported
|
||||
|
||||
ATMEL WIRELESS DRIVER
|
||||
P: Simon Kelley
|
||||
M: simon@thekelleys.org.uk
|
||||
|
|
@ -1153,11 +1166,6 @@ P: David Howells
|
|||
M: dhowells@redhat.com
|
||||
S: Maintained
|
||||
|
||||
FTAPE/QIC-117
|
||||
L: linux-tape@vger.kernel.org
|
||||
W: http://sourceforge.net/projects/ftape
|
||||
S: Orphan
|
||||
|
||||
FUSE: FILESYSTEM IN USERSPACE
|
||||
P: Miklos Szeredi
|
||||
M: miklos@szeredi.hu
|
||||
|
|
@ -2126,6 +2134,13 @@ L: netdev@vger.kernel.org
|
|||
T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
|
||||
S: Maintained
|
||||
|
||||
NETXEN (1/10) GbE SUPPORT
|
||||
P: Amit S. Kale
|
||||
M: amitkale@netxen.com
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.netxen.com
|
||||
S: Supported
|
||||
|
||||
IPVS
|
||||
P: Wensong Zhang
|
||||
M: wensong@linux-vs.org
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 19
|
||||
EXTRAVERSION =-rc6
|
||||
EXTRAVERSION =
|
||||
NAME=Avast! A bilge rat!
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
|
|||
|
|
@ -41,28 +41,25 @@ static inline unsigned short from64to16(unsigned long x)
|
|||
* computes the checksum of the TCP/UDP pseudo-header
|
||||
* returns a 16-bit checksum, already complemented.
|
||||
*/
|
||||
unsigned short int csum_tcpudp_magic(unsigned long saddr,
|
||||
unsigned long daddr,
|
||||
__sum16 csum_tcpudp_magic(__be32 saddr, __be32 daddr,
|
||||
unsigned short len,
|
||||
unsigned short proto,
|
||||
unsigned int sum)
|
||||
__wsum sum)
|
||||
{
|
||||
return ~from64to16(saddr + daddr + sum +
|
||||
((unsigned long) ntohs(len) << 16) +
|
||||
((unsigned long) proto << 8));
|
||||
return (__force __sum16)~from64to16(
|
||||
(__force u64)saddr + (__force u64)daddr +
|
||||
(__force u64)sum + ((len + proto) << 8));
|
||||
}
|
||||
|
||||
unsigned int csum_tcpudp_nofold(unsigned long saddr,
|
||||
unsigned long daddr,
|
||||
__wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
|
||||
unsigned short len,
|
||||
unsigned short proto,
|
||||
unsigned int sum)
|
||||
__wsum sum)
|
||||
{
|
||||
unsigned long result;
|
||||
|
||||
result = (saddr + daddr + sum +
|
||||
((unsigned long) ntohs(len) << 16) +
|
||||
((unsigned long) proto << 8));
|
||||
result = (__force u64)saddr + (__force u64)daddr +
|
||||
(__force u64)sum + ((len + proto) << 8);
|
||||
|
||||
/* Fold down to 32-bits so we don't lose in the typedef-less
|
||||
network stack. */
|
||||
|
|
@ -70,7 +67,7 @@ unsigned int csum_tcpudp_nofold(unsigned long saddr,
|
|||
result = (result & 0xffffffff) + (result >> 32);
|
||||
/* 33 to 32 */
|
||||
result = (result & 0xffffffff) + (result >> 32);
|
||||
return result;
|
||||
return (__force __wsum)result;
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -146,9 +143,9 @@ out:
|
|||
* This is a version of ip_compute_csum() optimized for IP headers,
|
||||
* which always checksum on 4 octet boundaries.
|
||||
*/
|
||||
unsigned short ip_fast_csum(unsigned char * iph, unsigned int ihl)
|
||||
__sum16 ip_fast_csum(const void *iph, unsigned int ihl)
|
||||
{
|
||||
return ~do_csum(iph,ihl*4);
|
||||
return (__force __sum16)~do_csum(iph,ihl*4);
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -163,15 +160,15 @@ unsigned short ip_fast_csum(unsigned char * iph, unsigned int ihl)
|
|||
*
|
||||
* it's best to have buff aligned on a 32-bit boundary
|
||||
*/
|
||||
unsigned int csum_partial(const unsigned char * buff, int len, unsigned int sum)
|
||||
__wsum csum_partial(const void *buff, int len, __wsum sum)
|
||||
{
|
||||
unsigned long result = do_csum(buff, len);
|
||||
|
||||
/* add in old sum, and carry.. */
|
||||
result += sum;
|
||||
result += (__force u32)sum;
|
||||
/* 32+c bits -> 32 bits */
|
||||
result = (result & 0xffffffff) + (result >> 32);
|
||||
return result;
|
||||
return (__force __wsum)result;
|
||||
}
|
||||
|
||||
EXPORT_SYMBOL(csum_partial);
|
||||
|
|
@ -180,7 +177,7 @@ EXPORT_SYMBOL(csum_partial);
|
|||
* this routine is used for miscellaneous IP-like checksums, mainly
|
||||
* in icmp.c
|
||||
*/
|
||||
unsigned short ip_compute_csum(unsigned char * buff, int len)
|
||||
__sum16 ip_compute_csum(const void *buff, int len)
|
||||
{
|
||||
return ~from64to16(do_csum(buff,len));
|
||||
return (__force __sum16)~from64to16(do_csum(buff,len));
|
||||
}
|
||||
|
|
|
|||
|
|
@ -329,11 +329,11 @@ csum_partial_cfu_unaligned(const unsigned long __user * src,
|
|||
return checksum;
|
||||
}
|
||||
|
||||
static unsigned int
|
||||
do_csum_partial_copy_from_user(const char __user *src, char *dst, int len,
|
||||
unsigned int sum, int *errp)
|
||||
__wsum
|
||||
csum_partial_copy_from_user(const void __user *src, void *dst, int len,
|
||||
__wsum sum, int *errp)
|
||||
{
|
||||
unsigned long checksum = (unsigned) sum;
|
||||
unsigned long checksum = (__force u32) sum;
|
||||
unsigned long soff = 7 & (unsigned long) src;
|
||||
unsigned long doff = 7 & (unsigned long) dst;
|
||||
|
||||
|
|
@ -367,25 +367,12 @@ do_csum_partial_copy_from_user(const char __user *src, char *dst, int len,
|
|||
}
|
||||
checksum = from64to16 (checksum);
|
||||
}
|
||||
return checksum;
|
||||
return (__force __wsum)checksum;
|
||||
}
|
||||
|
||||
unsigned int
|
||||
csum_partial_copy_from_user(const char __user *src, char *dst, int len,
|
||||
unsigned int sum, int *errp)
|
||||
__wsum
|
||||
csum_partial_copy_nocheck(const void *src, void *dst, int len, __wsum sum)
|
||||
{
|
||||
if (!access_ok(VERIFY_READ, src, len)) {
|
||||
*errp = -EFAULT;
|
||||
memset(dst, 0, len);
|
||||
return sum;
|
||||
}
|
||||
|
||||
return do_csum_partial_copy_from_user(src, dst, len, sum, errp);
|
||||
}
|
||||
|
||||
unsigned int
|
||||
csum_partial_copy_nocheck(const char __user *src, char *dst, int len,
|
||||
unsigned int sum)
|
||||
{
|
||||
return do_csum_partial_copy_from_user(src, dst, len, sum, NULL);
|
||||
return csum_partial_copy_from_user((__force const void __user *)src,
|
||||
dst, len, sum, NULL);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -879,6 +879,8 @@ endif
|
|||
|
||||
source "drivers/scsi/Kconfig"
|
||||
|
||||
source "drivers/ata/Kconfig"
|
||||
|
||||
source "drivers/md/Kconfig"
|
||||
|
||||
source "drivers/message/fusion/Kconfig"
|
||||
|
|
|
|||
|
|
@ -184,6 +184,7 @@ CONFIG_BINFMT_ELF=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
# CONFIG_APM is not set
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -194,6 +194,7 @@ CONFIG_BINFMT_ELF=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
# CONFIG_APM is not set
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -208,6 +208,7 @@ CONFIG_BINFMT_MISC=m
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
CONFIG_APM=y
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -194,6 +194,7 @@ CONFIG_BINFMT_ELF=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
# CONFIG_APM is not set
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -190,6 +190,7 @@ CONFIG_BINFMT_ELF=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
# CONFIG_APM is not set
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -182,6 +182,7 @@ CONFIG_BINFMT_AOUT=m
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
# CONFIG_APM is not set
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -180,6 +180,7 @@ CONFIG_BINFMT_AOUT=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
CONFIG_APM=m
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -190,6 +190,7 @@ CONFIG_BINFMT_AOUT=y
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
CONFIG_APM=y
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -180,6 +180,7 @@ CONFIG_BINFMT_MISC=m
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
CONFIG_APM=y
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -207,6 +207,7 @@ CONFIG_BINFMT_MISC=m
|
|||
# Power management options
|
||||
#
|
||||
CONFIG_PM=y
|
||||
# CONFIG_PM_LEGACY is not set
|
||||
CONFIG_APM=y
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -451,6 +451,7 @@ int smp_call_function(void (*func)(void *info), void *info, int retry,
|
|||
return smp_call_function_on_cpu(func, info, retry, wait,
|
||||
cpu_online_map);
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(smp_call_function);
|
||||
|
||||
void show_ipi_list(struct seq_file *p)
|
||||
{
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче