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:
commit
4c1ac1b491
1476 changed files with 67646 additions and 41035 deletions
3
CREDITS
3
CREDITS
|
@ -2598,6 +2598,9 @@ S: Ucitelska 1576
|
||||||
S: Prague 8
|
S: Prague 8
|
||||||
S: 182 00 Czech Republic
|
S: 182 00 Czech Republic
|
||||||
|
|
||||||
|
N: Rick Payne
|
||||||
|
D: RFC2385 Support for TCP
|
||||||
|
|
||||||
N: Barak A. Pearlmutter
|
N: Barak A. Pearlmutter
|
||||||
E: bap@cs.unm.edu
|
E: bap@cs.unm.edu
|
||||||
W: http://www.cs.unm.edu/~bap/
|
W: http://www.cs.unm.edu/~bap/
|
||||||
|
|
|
@ -104,8 +104,6 @@ firmware_class/
|
||||||
- request_firmware() hotplug interface info.
|
- request_firmware() hotplug interface info.
|
||||||
floppy.txt
|
floppy.txt
|
||||||
- notes and driver options for the floppy disk driver.
|
- notes and driver options for the floppy disk driver.
|
||||||
ftape.txt
|
|
||||||
- notes about the floppy tape device driver.
|
|
||||||
hayes-esp.txt
|
hayes-esp.txt
|
||||||
- info on using the Hayes ESP serial driver.
|
- info on using the Hayes ESP serial driver.
|
||||||
highuid.txt
|
highuid.txt
|
||||||
|
|
|
@ -201,7 +201,7 @@ udev
|
||||||
----
|
----
|
||||||
udev is a userspace application for populating /dev dynamically with
|
udev is a userspace application for populating /dev dynamically with
|
||||||
only entries for devices actually present. udev replaces the basic
|
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.
|
devices.
|
||||||
|
|
||||||
FUSE
|
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
|
flags can be or'd together and are
|
||||||
|
|
||||||
DMA_MEMORY_MAP - request that the memory returned from
|
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_MEMORY_IO - request that the memory returned from
|
||||||
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
|
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
|
Once the DMA transfer is finished (or timed out) you should disable
|
||||||
the channel again. You should also check get_dma_residue() to make
|
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:
|
Example:
|
||||||
|
|
||||||
|
|
|
@ -345,7 +345,6 @@ static inline void skel_delete (struct usb_skel *dev)
|
||||||
usb_buffer_free (dev->udev, dev->bulk_out_size,
|
usb_buffer_free (dev->udev, dev->bulk_out_size,
|
||||||
dev->bulk_out_buffer,
|
dev->bulk_out_buffer,
|
||||||
dev->write_urb->transfer_dma);
|
dev->write_urb->transfer_dma);
|
||||||
if (dev->write_urb != NULL)
|
|
||||||
usb_free_urb (dev->write_urb);
|
usb_free_urb (dev->write_urb);
|
||||||
kfree (dev);
|
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
|
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
|
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
|
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
|
For each MSI-X vector granted, a device driver is responsible for calling
|
||||||
other functions like request_irq(), enable_irq(), etc. to enable
|
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.
|
a pid/tgid will be followed by some stats.
|
||||||
|
|
||||||
b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose 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.
|
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
|
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
|
However, maintaining per-process, in addition to per-task stats, within the
|
||||||
kernel has space and time overheads. To address this, the taskstats code
|
kernel has space and time overheads. To address this, the taskstats code
|
||||||
accumalates each exiting task's statistics into a process-wide data structure.
|
accumulates 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
|
When the last task of a process exits, the process level data accumulated also
|
||||||
gets sent to userspace (along with the per-task data).
|
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
|
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.
|
threads of the same thread group.
|
||||||
|
|
||||||
Extending taskstats
|
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
|
modified to accomplish a direct page -> bus translation, without requiring
|
||||||
a virtual address mapping (unlike the earlier scheme of virtual address
|
a virtual address mapping (unlike the earlier scheme of virtual address
|
||||||
-> bus translation). So this works uniformly for high-memory pages (which
|
-> 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.
|
low-memory pages.
|
||||||
|
|
||||||
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
|
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
|
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.
|
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
|
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.
|
which were generated for each such chunk.
|
||||||
|
|
||||||
The following were some of the goals and expectations considered in the
|
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.
|
for raw i/o.
|
||||||
ii. Ability to represent high-memory buffers (which do not have a virtual
|
ii. Ability to represent high-memory buffers (which do not have a virtual
|
||||||
address mapping in kernel address space).
|
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)
|
greater than PAGE_SIZE chunks in one shot)
|
||||||
iv. At the same time, ability to retain independent identity of i/os from
|
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
|
different sources or i/o units requiring individual completion (e.g. for
|
||||||
latency reasons)
|
latency reasons)
|
||||||
v. Ability to represent an i/o involving multiple physical memory segments
|
v. Ability to represent an i/o involving multiple physical memory segments
|
||||||
(including non-page aligned page fragments, as specified via readv/writev)
|
(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.
|
handling it.
|
||||||
vi. Preferably should be based on a memory descriptor structure that can be
|
vi. Preferably should be based on a memory descriptor structure that can be
|
||||||
passed around different types of subsystems or layers, maybe even
|
passed around different types of subsystems or layers, maybe even
|
||||||
|
@ -1013,7 +1013,7 @@ Characteristics:
|
||||||
i. Binary tree
|
i. Binary tree
|
||||||
AS and deadline i/o schedulers use red black binary trees for disk position
|
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
|
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
|
almost always dispatched in disk sort order, so a cache is kept of the next
|
||||||
request in sort order to prevent binary tree lookups.
|
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.
|
can be controlled independently from the PCI/AGP clock.
|
||||||
|
|
||||||
The module has two options:
|
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
|
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
|
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
|
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
|
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
|
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.
|
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
|
7 = /dev/full Returns ENOSPC on write
|
||||||
8 = /dev/random Nondeterministic random number gen.
|
8 = /dev/random Nondeterministic random number gen.
|
||||||
9 = /dev/urandom Faster, less secure 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
|
11 = /dev/kmsg Writes to this come out as printk's
|
||||||
1 block RAM disk
|
1 block RAM disk
|
||||||
0 = /dev/ram0 First RAM disk
|
0 = /dev/ram0 First RAM disk
|
||||||
|
@ -1093,7 +1093,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
55 char DSP56001 digital signal processor
|
55 char DSP56001 digital signal processor
|
||||||
0 = /dev/dsp56k First DSP56001
|
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
|
0 = /dev/rd/c7d0 First disk, whole disk
|
||||||
8 = /dev/rd/c7d1 Second 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
|
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
|
0 = /dev/ida/c7d0 First logical drive whole disk
|
||||||
16 = /dev/ida/c7d1 Second 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
|
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
|
0 = /dev/cciss/c7d0 First logical drive, whole disk
|
||||||
16 = /dev/cciss/c7d1 Second logical drive, whole disk
|
16 = /dev/cciss/c7d1 Second logical drive, whole disk
|
||||||
...
|
...
|
||||||
|
|
|
@ -1,99 +1,131 @@
|
||||||
Platform Devices and Drivers
|
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
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
Platform devices are devices that typically appear as autonomous
|
Platform devices are devices that typically appear as autonomous
|
||||||
entities in the system. This includes legacy port-based devices and
|
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
|
Platform drivers
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
Drivers for platform devices are typically very simple and
|
Platform drivers follow the standard driver model convention, where
|
||||||
unstructured. Either the device was present at a particular I/O port
|
discovery/enumeration is handled outside the drivers, and drivers
|
||||||
and the driver was loaded, or it was not. There was no possibility
|
provide probe() and remove() methods. They support power management
|
||||||
of hotplugging or alternative discovery besides probing at a specific
|
and shutdown notifications using the standard conventions.
|
||||||
I/O address and expecting a specific response.
|
|
||||||
|
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
|
Device Enumeration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
These devices are not always at the legacy I/O ports. This is true on
|
As a rule, platform specific (and often board-specific) setup code wil
|
||||||
other architectures and on some modern architectures. In most cases,
|
register platform devices:
|
||||||
the drivers are modified to discover the devices at other well-known
|
|
||||||
ports for the given platform. However, the firmware in these systems
|
int platform_device_register(struct platform_device *pdev);
|
||||||
does usually know where exactly these devices reside, and in some
|
|
||||||
cases, it's the only way of discovering them.
|
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
|
Device Naming and Driver Binding
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
A platform bus has been created to deal with these issues. First and
|
The platform_device.dev.bus_id is the canonical name for the devices.
|
||||||
foremost, it groups all the legacy devices under a common bus, and
|
It's built from two components:
|
||||||
gives them a common parent if they don't already have one.
|
|
||||||
|
|
||||||
But, besides the organizational benefits, the platform bus can also
|
* platform_device.name ... which is also used to for driver matching.
|
||||||
accommodate firmware-based enumeration.
|
|
||||||
|
|
||||||
|
* platform_device.id ... the device instance number, or else "-1"
|
||||||
|
to indicate there's only one.
|
||||||
|
|
||||||
Device Discovery
|
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
|
||||||
The platform bus has no concept of probing for devices. Devices
|
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
|
||||||
discovery is left up to either the legacy drivers or the
|
and use the platform_driver called "my_rtc".
|
||||||
firmware. These entities are expected to notify the platform of
|
|
||||||
devices that it discovers via the bus's add() callback:
|
|
||||||
|
|
||||||
platform_bus.add(parent,bus_id).
|
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
|
- When a driver is registered using platform_driver_register(), all
|
||||||
~~~~~~~
|
unbound devices on that bus are checked for matches. Drivers
|
||||||
Bus IDs are the canonical names for the devices. There is no globally
|
usually register later during booting, or by module loading.
|
||||||
standard addressing mechanism for legacy devices. In the IA-32 world,
|
|
||||||
we have Pnp IDs to use, as well as the legacy I/O ports. However,
|
|
||||||
neither tell what the device really is or have any meaning on other
|
|
||||||
platforms.
|
|
||||||
|
|
||||||
Since both PnP IDs and the legacy I/O ports (and other standard I/O
|
- Registering a driver using platform_driver_probe() works just like
|
||||||
ports for specific devices) have a 1:1 mapping, we map the
|
using platform_driver_register(), except that the the driver won't
|
||||||
platform-specific name or identifier to a generic name (at least
|
be probed later if another device registers. (Which is OK, since
|
||||||
within the scope of the kernel).
|
this interface is only for use with non-hotpluggable devices.)
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
|
@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
|
||||||
describing the relationship the device has to other entities.
|
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 {
|
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 disadvantage is that the driver/hardware has to manage the rest. For
|
||||||
the application programmer it would be as simple as sending/receiving an
|
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
|
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 ?
|
* 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.
|
implemented by most applications. Hence this area is revisited.
|
||||||
|
|
||||||
This CI interface is quite different in the case that it tries to
|
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
|
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
|
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
|
bus_base_addr : slot 0 address on this bus
|
||||||
slots : max slot number to probe
|
slots : max slot number to probe
|
||||||
force_probe : Probe even when slot 0 is empty (no EISA mainboard)
|
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
|
bus_nr : unique bus id, set by eisa_root_register
|
||||||
|
|
||||||
** Driver :
|
** 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)
|
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||||
When: August 2006
|
When: August 2006
|
||||||
Files: arch/*/kernel/*_ksyms.c
|
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
|
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
|
||||||
When: October 2008
|
When: October 2008
|
||||||
Why: The stacking of class devices makes these values misleading and
|
Why: The stacking of class devices makes these values misleading and
|
||||||
|
@ -261,10 +234,11 @@ Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: ftape
|
What: IPv4 only connection tracking/NAT/helpers
|
||||||
When: 2.6.20
|
When: 2.6.22
|
||||||
Why: Orphaned for ages. SMP bugs long unfixed. Few users left
|
Why: The new layer 3 independant connection tracking replaces the old
|
||||||
in the world.
|
IPv4 only version. After some stabilization of the new code the
|
||||||
Who: Jeff Garzik <jeff@garzik.org>
|
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
|
uid=nnn All files in the partition will be owned by
|
||||||
user id nnn. Default 0 (root).
|
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).
|
nnn. Default 0 (root).
|
||||||
ownmask=nnn The permission mask for ADFS 'owner' permissions
|
ownmask=nnn The permission mask for ADFS 'owner' permissions
|
||||||
will be nnn. Default 0700.
|
will be nnn. Default 0700.
|
||||||
|
|
|
@ -209,7 +209,7 @@ will happen for write(2).
|
||||||
|
|
||||||
[struct config_group]
|
[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
|
is via mkdir(2) on a config_group. This will trigger creation of a
|
||||||
child item.
|
child item.
|
||||||
|
|
||||||
|
@ -275,7 +275,7 @@ directory is not empty.
|
||||||
|
|
||||||
[struct configfs_subsystem]
|
[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.
|
tells configfs to make the subsystem appear in the file tree.
|
||||||
|
|
||||||
struct configfs_subsystem {
|
struct configfs_subsystem {
|
||||||
|
|
|
@ -111,7 +111,7 @@ For each connection the following files exist within this directory:
|
||||||
|
|
||||||
'waiting'
|
'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
|
userspace or being processed by the filesystem daemon. If there is
|
||||||
no filesystem activity and 'waiting' is non-zero, then the
|
no filesystem activity and 'waiting' is non-zero, then the
|
||||||
filesystem is hung or deadlocked.
|
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
|
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
|
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.
|
this flag is set, an INTERRUPT request is queued.
|
||||||
|
|
||||||
3) If the request is already sent to userspace, then an INTERRUPT
|
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;
|
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
|
when reading device (cat /dev/hda) while creating files on it, files
|
||||||
could be damaged
|
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
|
end of partition
|
||||||
2.03 Char, block devices and pipes are correctly created
|
2.03 Char, block devices and pipes are correctly created
|
||||||
Fixed non-crashing race in unlink (Alexander Viro)
|
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):
|
this (note all values are in 512-byte sectors):
|
||||||
|
|
||||||
--- cut here ---
|
--- 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
|
# in of the type type of log size sync? of Device in Device in
|
||||||
# vol volume params mirrors Device Device
|
# vol volume params mirrors Device Device
|
||||||
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
|
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
|
- Major bug fixes for reading files and volumes in corner cases which
|
||||||
were being hit by Windows 2k/XP users.
|
were being hit by Windows 2k/XP users.
|
||||||
2.1.2:
|
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.
|
users.
|
||||||
2.1.1:
|
2.1.1:
|
||||||
- Update handling of compressed files so people no longer get the
|
- Update handling of compressed files so people no longer get the
|
||||||
|
|
|
@ -30,7 +30,7 @@ Caveats
|
||||||
Features which OCFS2 does not support yet:
|
Features which OCFS2 does not support yet:
|
||||||
- sparse files
|
- sparse files
|
||||||
- extended attributes
|
- extended attributes
|
||||||
- shared writeable mmap
|
- shared writable mmap
|
||||||
- loopback is supported, but data written will not
|
- loopback is supported, but data written will not
|
||||||
be cluster coherent.
|
be cluster coherent.
|
||||||
- quotas
|
- 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.
|
you probably should increase the lower_zone_protection setting.
|
||||||
|
|
||||||
The units of this tunable are fairly vague. It is approximately equal
|
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
|
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.
|
pagecache, so there is a cost.
|
||||||
|
|
||||||
The effects of this tunable may be observed by monitoring
|
The effects of this tunable may be observed by monitoring
|
||||||
|
@ -1538,10 +1538,10 @@ TCP settings
|
||||||
tcp_ecn
|
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
|
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
|
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 this sites. For more info
|
/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
|
||||||
you could read RFC2481.
|
you could read RFC2481.
|
||||||
|
|
||||||
tcp_retrans_collapse
|
tcp_retrans_collapse
|
||||||
|
|
|
@ -210,7 +210,7 @@ FILES
|
||||||
/signal2
|
/signal2
|
||||||
The two signal notification channels of an SPU. These are read-write
|
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
|
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
|
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
|
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-
|
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
|
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
|
"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
|
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.
|
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
|
almost completely self-contained. The only external code used is the
|
||||||
sprintf family of functions.
|
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,
|
switch off on entry to an exception. That means unless manually disabled,
|
||||||
single-stepping will blithely go on stepping into things like interrupts.
|
single-stepping will blithely go on stepping into things like interrupts.
|
||||||
See gdbstub.txt for more information.
|
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
|
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
|
||||||
maintainer.
|
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>
|
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) |
|
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
|
||||||
| 2 | M0V | JOY0DAT Vertical Clock |
|
| 2 | M0V | JOY0DAT Vertical Clock |
|
||||||
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
||||||
| 4 | M1V | JOY1DAT Horizontall Clock |
|
| 4 | M1V | JOY1DAT Horizontal Clock |
|
||||||
| 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) |
|
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
|
||||||
| 6 | M1V | JOY1DAT Vertical Clock |
|
| 6 | M1V | JOY1DAT Vertical Clock |
|
||||||
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
||||||
+--------+----------+-----------------------------------------+
|
+--------+----------+-----------------------------------------+
|
||||||
|
|
|
@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
|
||||||
|
|
||||||
5.1 Joystick Event Reporting
|
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).
|
changed (i.e. for each opening or closing of a joystick switch or trigger).
|
||||||
|
|
||||||
The joystick event record is two bytes of the form:
|
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
|
9.7 SET MOUSE SCALE
|
||||||
|
|
||||||
0x0C
|
0x0C
|
||||||
X ; horizontal mouse ticks per internel X
|
X ; horizontal mouse ticks per internal X
|
||||||
Y ; vertical mouse ticks per internel Y
|
Y ; vertical mouse ticks per internal Y
|
||||||
|
|
||||||
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
||||||
In this mode, the specified number of mouse phase changes ('clicks') must
|
In this mode, the specified number of mouse phase changes ('clicks') must
|
||||||
|
@ -323,7 +323,7 @@ mouse position.
|
||||||
0x0F
|
0x0F
|
||||||
|
|
||||||
This command makes the origin of the Y axis to be at the bottom of the
|
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
|
mouse motion. This causes mouse motion toward the user to be negative in sign
|
||||||
and away from the user to be positive.
|
and away from the user to be positive.
|
||||||
|
|
||||||
|
@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
|
||||||
|
|
||||||
10. SCAN CODES
|
10. SCAN CODES
|
||||||
|
|
||||||
The key scan codes return by the ikbd are chosen to simplify the
|
The key scan codes returned by the ikbd are chosen to simplify the
|
||||||
implementaion of GSX.
|
implementation of GSX.
|
||||||
|
|
||||||
GSX Standard Keyboard Mapping.
|
GSX Standard Keyboard Mapping.
|
||||||
|
|
||||||
|
|
|
@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
|
||||||
888888888888
|
888888888888
|
||||||
Linux Rocks!
|
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.
|
- Excess characters are ignored.
|
||||||
- If less characters are written than allowed, the remaining digits are
|
- If less characters are written than allowed, the remaining digits are
|
||||||
unchanged.
|
unchanged.
|
||||||
|
|
|
@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc.
|
||||||
Ok, this is where problems start. The current interface for
|
Ok, this is where problems start. The current interface for
|
||||||
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
||||||
assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
|
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
|
very common for CDs to have some tracks with data, and some
|
||||||
tracks with audio. Just because I feel like it, I declare
|
tracks with audio. Just because I feel like it, I declare
|
||||||
the following to be the best way to cope. If the CD has
|
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.
|
be included in a library, lib.a.
|
||||||
All objects listed with lib-y are combined in a single
|
All objects listed with lib-y are combined in a single
|
||||||
library for that directory.
|
library for that directory.
|
||||||
Objects that are listed in obj-y and additionaly listed in
|
Objects that are listed in obj-y and additionally listed in
|
||||||
lib-y will not be included in the library, since they will anyway
|
lib-y will not be included in the library, since they will
|
||||||
be accessible.
|
be accessible anyway.
|
||||||
For consistency, objects listed in lib-m will be included in lib.a.
|
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
|
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.
|
Host programs can be made up based on composite objects.
|
||||||
The syntax used to define composite objects for host programs is
|
The syntax used to define composite objects for host programs is
|
||||||
similar to the syntax used for kernel objects.
|
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.
|
executable.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||||
In this example, there are two possible targets, requiring different
|
In this example, there are two possible targets, requiring different
|
||||||
options to the linker. The linker options are specified using the
|
options to the linker. The linker options are specified using the
|
||||||
LDFLAGS_$@ syntax - one for each potential target.
|
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:
|
the targets and will:
|
||||||
1) check for commandline changes
|
1) check for commandline changes
|
||||||
2) delete target during make clean
|
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]
|
floppy= [HW]
|
||||||
See Documentation/floppy.txt.
|
See Documentation/floppy.txt.
|
||||||
|
|
||||||
ftape= [HW] Floppy Tape subsystem debugging options.
|
|
||||||
See Documentation/ftape.txt.
|
|
||||||
|
|
||||||
gamecon.map[2|3]=
|
gamecon.map[2|3]=
|
||||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||||
support via parallel port (up to 5 devices per port)
|
support via parallel port (up to 5 devices per port)
|
||||||
|
|
|
@ -304,7 +304,7 @@ about the status of the key service:
|
||||||
R Revoked
|
R Revoked
|
||||||
D Dead
|
D Dead
|
||||||
Q Contributes to user's quota
|
Q Contributes to user's quota
|
||||||
U Under contruction by callback to userspace
|
U Under construction by callback to userspace
|
||||||
N Negative key
|
N Negative key
|
||||||
|
|
||||||
This file must be enabled at kernel configuration time as it allows anyone
|
This file must be enabled at kernel configuration time as it allows anyone
|
||||||
|
|
|
@ -121,7 +121,7 @@ contains the following options:
|
||||||
MAX_AGE:
|
MAX_AGE:
|
||||||
|
|
||||||
Maximum time, in seconds, of hard drive spindown time that you are
|
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.
|
amount of work if your battery fails while you're in laptop mode.
|
||||||
|
|
||||||
MINIMUM_BATTERY_MINUTES:
|
MINIMUM_BATTERY_MINUTES:
|
||||||
|
@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
|
||||||
|
|
||||||
--------------------CONFIG FILE BEGIN-------------------------------------------
|
--------------------CONFIG FILE BEGIN-------------------------------------------
|
||||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
# 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.
|
# amount of work if your battery fails you while in laptop mode.
|
||||||
#MAX_AGE=600
|
#MAX_AGE=600
|
||||||
|
|
||||||
|
@ -350,7 +350,7 @@ fi
|
||||||
# set defaults instead:
|
# set defaults instead:
|
||||||
|
|
||||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
# 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.
|
# amount of work if your battery fails you while in laptop mode.
|
||||||
MAX_AGE=${MAX_AGE:-'600'}
|
MAX_AGE=${MAX_AGE:-'600'}
|
||||||
|
|
||||||
|
@ -699,7 +699,7 @@ ACPI integration
|
||||||
Dax Kelson submitted this so that the ACPI acpid daemon will
|
Dax Kelson submitted this so that the ACPI acpid daemon will
|
||||||
kick off the laptop_mode script and run hdparm. The part that
|
kick off the laptop_mode script and run hdparm. The part that
|
||||||
automatically disables laptop mode when the battery is low was
|
automatically disables laptop mode when the battery is low was
|
||||||
writen by Jan Topinski.
|
written by Jan Topinski.
|
||||||
|
|
||||||
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
||||||
event=ac_adapter
|
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
|
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).
|
memory).
|
||||||
|
|
||||||
And there are a number of things that _must_ or _must_not_ be assumed:
|
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()
|
Move all to dev->poll()
|
||||||
|
|
||||||
C) Ability to detect new work correctly.
|
C) Ability to detect new work correctly.
|
||||||
NAPI works by shutting down event interrupts when theres work and
|
NAPI works by shutting down event interrupts when there's work and
|
||||||
turning them on when theres none.
|
turning them on when there's none.
|
||||||
New packets might show up in the small window while interrupts were being
|
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
|
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
|
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
|
only one CPU can pick the initial interrupt and hence the initial
|
||||||
netif_rx_schedule(dev);
|
netif_rx_schedule(dev);
|
||||||
- The core layer invokes devices to send packets in a round robin format.
|
- 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.
|
one CPU is executing it.
|
||||||
- contention can only be the result of some other CPU accessing the rx
|
- contention can only be the result of some other CPU accessing the rx
|
||||||
ring. This happens only in close() and suspend() (when these methods
|
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 */
|
an interrupt will be generated */
|
||||||
goto done;
|
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
|
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
|
they'll be caught by the while check and we go back and clear them
|
||||||
since we havent exceeded our quota */
|
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
|
* 1. it can race with disabling irqs in irq handler (which are done to
|
||||||
* schedule polls)
|
* schedule polls)
|
||||||
* 2. it can race with dis/enabling irqs in other poll threads
|
* 2. it can race with dis/enabling irqs in other poll threads
|
||||||
* 3. if an irq raised after the begining of the outer beginning
|
* 3. if an irq raised after the beginning of the outer beginning
|
||||||
* loop(marked in the code above), it will be immediately
|
* loop (marked in the code above), it will be immediately
|
||||||
* triggered here.
|
* 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
|
* due to races in masking and due to too late acking of already
|
||||||
* processed irqs. The good news: no events are ever lost.
|
* processed irqs. The good news: no events are ever lost.
|
||||||
*/
|
*/
|
||||||
|
@ -601,7 +601,7 @@ a)
|
||||||
|
|
||||||
5) dev->close() and dev->suspend() issues
|
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.
|
care of it.
|
||||||
|
|
||||||
6) Adding new Stats to /proc
|
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.
|
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
|
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
|
much of a commodity feature (both in NICs and switches) and hence falls
|
||||||
under the same category as using NIC based mitigation. Also experiments
|
under the same category as using NIC based mitigation. Also, experiments
|
||||||
indicate that its much harder to resolve the resource allocation
|
indicate that it's much harder to resolve the resource allocation
|
||||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
|
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
|
proved harder. In any case, FC works even better with NAPI but is not
|
||||||
necessary.
|
necessary.
|
||||||
|
|
||||||
|
@ -678,10 +678,10 @@ routine:
|
||||||
CSR5 bit of interest is only the rx status.
|
CSR5 bit of interest is only the rx status.
|
||||||
If you look at the last if statement:
|
If you look at the last if statement:
|
||||||
you just finished grabbing all the packets from the rx ring .. you check if
|
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,
|
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
|
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.
|
to register the new packet for processing.
|
||||||
|
|
||||||
[The above description nay be very verbose, if you have better wording
|
[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
|
with device probing. To avoid this behaviour, add one
|
||||||
to the `io=' module parameter. This doesn't actually change
|
to the `io=' module parameter. This doesn't actually change
|
||||||
the I/O address, but it is a flag to tell the driver
|
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
|
identify the card. This could be dangerous if you are
|
||||||
not sure that there is a cs89x0 card at the provided address.
|
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)
|
12 Mouse (PS/2)
|
||||||
Memory Address Device 13 Math Coprocessor
|
Memory Address Device 13 Math Coprocessor
|
||||||
-------------- --------------------- 14 Hard Disk controller
|
-------------- --------------------- 14 Hard Disk controller
|
||||||
A000-BFFF EGA Graphics Adpater
|
A000-BFFF EGA Graphics Adapter
|
||||||
A000-C7FF VGA Graphics Adpater
|
A000-C7FF VGA Graphics Adapter
|
||||||
B000-BFFF Mono Graphics Adapter
|
B000-BFFF Mono Graphics Adapter
|
||||||
B800-BFFF Color Graphics Adapter
|
B800-BFFF Color Graphics Adapter
|
||||||
E000-FFFF AT BIOS
|
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 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:
|
It is at experimental RFC status and the homepage for DCCP as a protocol is at:
|
||||||
http://www.icir.org/kohler/dcp/
|
http://www.read.cs.ucla.edu/dccp/
|
||||||
|
|
||||||
Missing features
|
Missing features
|
||||||
================
|
================
|
||||||
|
|
||||||
The DCCP implementation does not currently have all the features that are in
|
The DCCP implementation does not currently have all the features that are in
|
||||||
the draft RFC.
|
the RFC.
|
||||||
|
|
||||||
In particular the following are missing:
|
The known bugs are at:
|
||||||
- CCID2 support
|
http://linux-net.osdl.org/index.php/TODO#DCCP
|
||||||
- feature negotiation
|
|
||||||
|
|
||||||
When testing against other implementations it appears that elapsed time
|
|
||||||
options are not coded compliant to the specification.
|
|
||||||
|
|
||||||
Socket options
|
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
|
is present). Connecting sockets set at most one service option; for
|
||||||
listening sockets, multiple service codes can be specified.
|
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
|
Notes
|
||||||
=====
|
=====
|
||||||
|
|
||||||
SELinux does not yet have support for DCCP. You will need to turn it off or
|
DCCP does not travel through NAT successfully at present on many boxes. This is
|
||||||
else you will get EACCES.
|
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
|
||||||
|
support for DCCP has been added.
|
||||||
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.
|
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
|
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
|
||||||
===============================================================
|
===============================================================
|
||||||
|
|
||||||
November 15, 2005
|
September 26, 2006
|
||||||
|
|
||||||
|
|
||||||
Contents
|
Contents
|
||||||
|
@ -9,6 +9,7 @@ Contents
|
||||||
|
|
||||||
- In This Release
|
- In This Release
|
||||||
- Identifying Your Adapter
|
- Identifying Your Adapter
|
||||||
|
- Building and Installation
|
||||||
- Command Line Parameters
|
- Command Line Parameters
|
||||||
- Speed and Duplex Configuration
|
- Speed and Duplex Configuration
|
||||||
- Additional Configurations
|
- 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
|
Instructions on updating ethtool can be found in the section "Additional
|
||||||
Configurations" later in this document.
|
Configurations" later in this document.
|
||||||
|
|
||||||
|
NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
|
||||||
|
support.
|
||||||
|
|
||||||
|
|
||||||
Identifying Your Adapter
|
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
|
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
|
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
|
are used by entering them on the command line with the modprobe command
|
||||||
command using this syntax:
|
using this syntax:
|
||||||
|
|
||||||
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
|
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
|
||||||
|
|
||||||
insmod e1000 [<option>=<VAL1>,<VAL2>,...]
|
|
||||||
|
|
||||||
For example, with two PRO/1000 PCI adapters, entering:
|
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
|
loads the e1000 driver with 80 TX descriptors for the first adapter and
|
||||||
TX descriptors for the second adapter.
|
128 TX descriptors for the second adapter.
|
||||||
|
|
||||||
The default value for each parameter is generally the recommended setting,
|
The default value for each parameter is generally the recommended setting,
|
||||||
unless otherwise noted.
|
unless otherwise noted.
|
||||||
|
@ -96,9 +99,9 @@ AutoNeg
|
||||||
Valid Range: 0x01-0x0F, 0x20-0x2F
|
Valid Range: 0x01-0x0F, 0x20-0x2F
|
||||||
Default Value: 0x2F
|
Default Value: 0x2F
|
||||||
|
|
||||||
This parameter is a bit mask that specifies which speed and duplex
|
This parameter is a bit-mask that specifies the speed and duplex settings
|
||||||
settings the board advertises. When this parameter is used, the Speed
|
advertised by the adapter. When this parameter is used, the Speed and
|
||||||
and Duplex parameters must not be specified.
|
Duplex parameters must not be specified.
|
||||||
|
|
||||||
NOTE: Refer to the Speed and Duplex section of this readme for more
|
NOTE: Refer to the Speed and Duplex section of this readme for more
|
||||||
information on the AutoNeg parameter.
|
information on the AutoNeg parameter.
|
||||||
|
@ -110,14 +113,15 @@ Duplex
|
||||||
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
|
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
|
||||||
Default Value: 0
|
Default Value: 0
|
||||||
|
|
||||||
Defines the direction in which data is allowed to flow. Can be either
|
This defines the direction in which data is allowed to flow. Can be
|
||||||
one or two-directional. If both Duplex and the link partner are set to
|
either one or two-directional. If both Duplex and the link partner are
|
||||||
auto-negotiate, the board auto-detects the correct duplex. If the link
|
set to auto-negotiate, the board auto-detects the correct duplex. If the
|
||||||
partner is forced (either full or half), Duplex defaults to half-duplex.
|
link partner is forced (either full or half), Duplex defaults to half-
|
||||||
|
duplex.
|
||||||
|
|
||||||
|
|
||||||
FlowControl
|
FlowControl
|
||||||
----------
|
-----------
|
||||||
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
||||||
Default Value: Reads flow control settings from the EEPROM
|
Default Value: Reads flow control settings from the EEPROM
|
||||||
|
|
||||||
|
@ -127,14 +131,55 @@ to Ethernet PAUSE frames.
|
||||||
|
|
||||||
InterruptThrottleRate
|
InterruptThrottleRate
|
||||||
---------------------
|
---------------------
|
||||||
(not supported on Intel 82542, 82543 or 82544-based adapters)
|
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
|
||||||
Valid Range: 100-100000 (0=off, 1=dynamic)
|
Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
|
||||||
Default Value: 8000
|
Default Value: 3
|
||||||
|
|
||||||
This value represents the maximum number of interrupts per second the
|
The driver can limit the amount of interrupts per second that the adapter
|
||||||
controller generates. InterruptThrottleRate is another setting used in
|
will generate for incoming packets. It does this by writing a value to the
|
||||||
interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
|
adapter that is based on the maximum amount of interrupts that the adapter
|
||||||
InterruptThrottleRate based on the current traffic load.
|
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
|
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
|
||||||
RxAbsIntDelay parameters. In other words, minimizing the receive
|
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
|
generate more interrupts than what the Interrupt Throttle Rate
|
||||||
allows.
|
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
|
(controller 82547), setting InterruptThrottleRate to a value
|
||||||
greater than 75,000, may hang (stop transmitting) adapters
|
greater than 75,000, may hang (stop transmitting) adapters
|
||||||
under certain network conditions. If this occurs a NETDEV
|
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
|
the overall throughput, we recommend that you load the driver as
|
||||||
follows:
|
follows:
|
||||||
|
|
||||||
insmod e1000.o InterruptThrottleRate=3000,3000,3000
|
modprobe e1000 InterruptThrottleRate=3000,3000,3000
|
||||||
|
|
||||||
This sets the InterruptThrottleRate to 3000 interrupts/sec for
|
This sets the InterruptThrottleRate to 3000 interrupts/sec for
|
||||||
the first, second, and third instances of the driver. The range
|
the first, second, and third instances of the driver. The range
|
||||||
|
@ -168,16 +213,25 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
|
||||||
RX_POLLING (NAPI) and default driver settings.
|
RX_POLLING (NAPI) and default driver settings.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
RxDescriptors
|
RxDescriptors
|
||||||
-------------
|
-------------
|
||||||
Valid Range: 80-256 for 82542 and 82543-based adapters
|
Valid Range: 80-256 for 82542 and 82543-based adapters
|
||||||
80-4096 for all other supported adapters
|
80-4096 for all other supported adapters
|
||||||
Default Value: 256
|
Default Value: 256
|
||||||
|
|
||||||
This value specifies the number of receive descriptors allocated by the
|
This value specifies the number of receive buffer descriptors allocated
|
||||||
driver. Increasing this value allows the driver to buffer more incoming
|
by the driver. Increasing this value allows the driver to buffer more
|
||||||
packets. Each descriptor is 16 bytes. A receive buffer is also
|
incoming packets, at the expense of increased system memory utilization.
|
||||||
allocated for each descriptor and is 2048.
|
|
||||||
|
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
|
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
|
speed and duplex combinations are advertised during the auto-negotiation
|
||||||
process.
|
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.
|
determined by the bitmap below.
|
||||||
|
|
||||||
Bit position 7 6 5 4 3 2 1 0
|
Bit position 7 6 5 4 3 2 1 0
|
||||||
|
@ -337,7 +391,6 @@ Additional Configurations
|
||||||
|
|
||||||
Configuring the Driver on Different Distributions
|
Configuring the Driver on Different Distributions
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
|
|
||||||
Configuring a network driver to load properly when the system is started
|
Configuring a network driver to load properly when the system is started
|
||||||
is distribution dependent. Typically, the configuration process involves
|
is distribution dependent. Typically, the configuration process involves
|
||||||
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
|
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,
|
To learn the proper way to configure a network device for your system,
|
||||||
refer to your distribution documentation. If during this process you are
|
refer to your distribution documentation. If during this process you are
|
||||||
asked for the driver or module name, the name for the Linux Base Driver
|
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
|
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
|
(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 eth0 e1000
|
||||||
alias eth1 e1000
|
alias eth1 e1000
|
||||||
|
@ -358,7 +411,6 @@ Additional Configurations
|
||||||
|
|
||||||
Viewing Link Messages
|
Viewing Link Messages
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
Link messages will not be displayed to the console if the distribution is
|
Link messages will not be displayed to the console if the distribution is
|
||||||
restricting system messages. In order to see network driver link messages
|
restricting system messages. In order to see network driver link messages
|
||||||
on your console, set dmesg to eight by entering the following:
|
on your console, set dmesg to eight by entering the following:
|
||||||
|
@ -369,11 +421,9 @@ Additional Configurations
|
||||||
|
|
||||||
Jumbo Frames
|
Jumbo Frames
|
||||||
------------
|
------------
|
||||||
|
Jumbo Frames support is enabled by changing the MTU to a value larger than
|
||||||
The driver supports Jumbo Frames for all adapters except 82542 and
|
the default of 1500. Use the ifconfig command to increase the MTU size.
|
||||||
82573-based adapters. Jumbo Frames support is enabled by changing the
|
For example:
|
||||||
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
|
ifconfig eth<x> mtu 9000 up
|
||||||
|
|
||||||
|
@ -390,26 +440,49 @@ Additional Configurations
|
||||||
|
|
||||||
- To enable Jumbo Frames, increase the MTU size on the interface beyond
|
- To enable Jumbo Frames, increase the MTU size on the interface beyond
|
||||||
1500.
|
1500.
|
||||||
|
|
||||||
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
|
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
|
||||||
with the maximum Jumbo Frames size of 16128.
|
with the maximum Jumbo Frames size of 16128.
|
||||||
|
|
||||||
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
|
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
|
||||||
loss of link.
|
loss of link.
|
||||||
|
|
||||||
- Some Intel gigabit adapters that support Jumbo Frames have a frame size
|
- 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.
|
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
|
The adapters with this limitation are based on the Intel(R) 82571EB,
|
||||||
82572EI controllers, which correspond to these product names:
|
82572EI, 82573L and 80003ES2LAN controller. These correspond to the
|
||||||
Intel® PRO/1000 PT Dual Port Server Adapter
|
following product names:
|
||||||
Intel® PRO/1000 PF Dual Port Server Adapter
|
Intel(R) PRO/1000 PT Server Adapter
|
||||||
Intel® PRO/1000 PT Server Adapter
|
Intel(R) PRO/1000 PT Desktop Adapter
|
||||||
Intel® PRO/1000 PT Desktop Adapter
|
Intel(R) PRO/1000 PT Network Connection
|
||||||
Intel® PRO/1000 PF Server Adapter
|
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
|
Ethtool
|
||||||
-------
|
-------
|
||||||
|
|
||||||
The driver utilizes the ethtool interface for driver configuration and
|
The driver utilizes the ethtool interface for driver configuration and
|
||||||
diagnostics, as well as displaying statistical information. Ethtool
|
diagnostics, as well as displaying statistical information. Ethtool
|
||||||
version 1.6 or later is required for this functionality.
|
version 1.6 or later is required for this functionality.
|
||||||
|
@ -423,7 +496,6 @@ Additional Configurations
|
||||||
|
|
||||||
Enabling Wake on LAN* (WoL)
|
Enabling Wake on LAN* (WoL)
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
WoL is configured through the Ethtool* utility. Ethtool is included with
|
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,
|
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
|
||||||
download and install Ethtool from the following website:
|
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
|
For this driver version, in order to enable WoL, the e1000 driver must be
|
||||||
loaded when shutting down or rebooting the system.
|
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
|
||||||
----
|
----
|
||||||
|
|
||||||
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
||||||
or disabled based on the configuration of the kernel. To override
|
or disabled based on the configuration of the kernel. To override
|
||||||
the default, use the following compile-time flags.
|
the default, use the following compile-time flags.
|
||||||
|
@ -457,89 +535,106 @@ Additional Configurations
|
||||||
Known Issues
|
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
|
Jumbo Frames System Requirement
|
||||||
of RAM or less that are running Jumbo Frames. If you are using Jumbo
|
-------------------------------
|
||||||
Frames, your system may require more than the advertised minimum
|
Memory allocation failures have been observed on Linux systems with 64 MB
|
||||||
requirement of 64 MB of system memory.
|
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
|
Jumbo Frames on Foundry BigIron 8000 switch
|
||||||
environments. If this is observed, increasing the application's socket
|
-------------------------------------------
|
||||||
buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
|
There is a known issue using Jumbo frames when connected to a Foundry
|
||||||
may help. See the specific application manual and
|
BigIron 8000 switch. This is a 3rd party limitation. If you experience
|
||||||
/usr/src/linux*/Documentation/
|
loss of packets, lower the MTU size.
|
||||||
networking/ip-sysctl.txt for more details.
|
|
||||||
|
|
||||||
Jumbo frames on Foundry BigIron 8000 switch
|
Allocating Rx Buffers when Using Jumbo Frames
|
||||||
-------------------------------------------
|
---------------------------------------------
|
||||||
There is a known issue using Jumbo frames when connected to a Foundry
|
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
|
||||||
BigIron 8000 switch. This is a 3rd party limitation. If you experience
|
the available memory is heavily fragmented. This issue may be seen with PCI-X
|
||||||
loss of packets, lower the MTU size.
|
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
|
If you have multiple interfaces in a server, either turn on ARP
|
||||||
one system on two IP networks in the same Ethernet broadcast domain
|
filtering by entering:
|
||||||
(non-partitioned switch) behave as expected. All Ethernet interfaces
|
|
||||||
will respond to IP traffic for any IP address assigned to the system.
|
|
||||||
This results in unbalanced receive traffic.
|
|
||||||
|
|
||||||
If you have multiple interfaces in a server, either turn on ARP
|
|
||||||
filtering by entering:
|
|
||||||
|
|
||||||
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
|
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
|
NOTE: This setting is not saved across reboots. The configuration
|
||||||
change can be made permanent by adding the line:
|
change can be made permanent by adding the line:
|
||||||
net.ipv4.conf.all.arp_filter = 1
|
net.ipv4.conf.all.arp_filter = 1
|
||||||
to the file /etc/sysctl.conf
|
to the file /etc/sysctl.conf
|
||||||
|
|
||||||
or,
|
or,
|
||||||
|
|
||||||
install the interfaces in separate broadcast domains (either in
|
install the interfaces in separate broadcast domains (either in
|
||||||
different switches or in a switch partitioned to VLANs).
|
different switches or in a switch partitioned to VLANs).
|
||||||
|
|
||||||
82541/82547 can't link or are slow to link with some link partners
|
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
|
||||||
There is a known compatibility issue with 82541/82547 and some
|
low-end switches where the link will not be established, or will
|
||||||
low-end switches where the link will not be established, or will
|
be slow to establish. In particular, these switches are known to
|
||||||
be slow to establish. In particular, these switches are known to
|
be incompatible with 82541/82547:
|
||||||
be incompatible with 82541/82547:
|
|
||||||
|
|
||||||
Planex FXG-08TE
|
Planex FXG-08TE
|
||||||
I-O Data ETG-SH8
|
I-O Data ETG-SH8
|
||||||
|
|
||||||
To workaround this issue, the driver can be compiled with an override
|
To workaround this issue, the driver can be compiled with an override
|
||||||
of the PHY's master/slave setting. Forcing master or forcing slave
|
of the PHY's master/slave setting. Forcing master or forcing slave
|
||||||
mode will improve time-to-link.
|
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
|
0 = Hardware default
|
||||||
1 = Master mode
|
1 = Master mode
|
||||||
2 = Slave mode
|
2 = Slave mode
|
||||||
3 = Auto master/slave
|
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
|
For example:
|
||||||
off auto-negotiation on the same command line.
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
ethtool -A eth? autoneg off rx off
|
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
|
Support
|
||||||
=======
|
=======
|
||||||
|
@ -548,24 +643,10 @@ For general information, go to the Intel support website at:
|
||||||
|
|
||||||
http://support.intel.com
|
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
|
http://sourceforge.net/projects/e1000
|
||||||
|
|
||||||
If an issue is identified with the released source code on the supported
|
If an issue is identified with the released source code on the supported
|
||||||
kernel with a supported adapter, email the specific information related
|
kernel with a supported adapter, email the specific information related
|
||||||
to the issue to e1000-devel@lists.sourceforge.net
|
to the issue to e1000-devel@lists.sf.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.
|
|
||||||
|
|
|
@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER
|
||||||
|
|
||||||
TCP variables:
|
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
|
tcp_abc - INTEGER
|
||||||
Controls Appropriate Byte Count (ABC) defined in RFC3465.
|
Controls Appropriate Byte Count (ABC) defined in RFC3465.
|
||||||
ABC is a way of increasing congestion window (cwnd) more slowly
|
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.
|
of two segments to compensate for delayed acknowledgments.
|
||||||
Default: 0 (off)
|
Default: 0 (off)
|
||||||
|
|
||||||
tcp_syn_retries - INTEGER
|
tcp_abort_on_overflow - BOOLEAN
|
||||||
Number of times initial SYNs for an active TCP connection attempt
|
If listening service is too slow to accept new connections,
|
||||||
will be retransmitted. Should not be higher than 255. Default value
|
reset them. Default state is FALSE. It means that if overflow
|
||||||
is 5, which corresponds to ~180seconds.
|
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
|
tcp_adv_win_scale - INTEGER
|
||||||
Number of times SYNACKs for a passive TCP connection attempt will
|
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
||||||
be retransmitted. Should not be higher than 255. Default value
|
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
||||||
is 5, which corresponds to ~180seconds.
|
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
|
tcp_keepalive_time - INTEGER
|
||||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
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
|
after probes started. Default value: 75sec i.e. connection
|
||||||
will be aborted after ~11 minutes of retries.
|
will be aborted after ~11 minutes of retries.
|
||||||
|
|
||||||
tcp_retries1 - INTEGER
|
tcp_low_latency - BOOLEAN
|
||||||
How many times to retry before deciding that something is wrong
|
If set, the TCP stack makes decisions that prefer lower
|
||||||
and it is necessary to report this suspicion to network layer.
|
latency as opposed to higher throughput. By default, this
|
||||||
Minimal RFC value is 3, it is default, which corresponds
|
option is not set meaning that higher throughput is preferred.
|
||||||
to ~3sec-8min depending on RTO.
|
An example of an application where this default should be
|
||||||
|
changed would be a Beowulf compute cluster.
|
||||||
tcp_retries2 - INTEGER
|
Default: 0
|
||||||
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_max_orphans - INTEGER
|
tcp_max_orphans - INTEGER
|
||||||
Maximal number of TCP sockets not attached to any user file handle,
|
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
|
more aggressively. Let me to remind again: each orphan eats
|
||||||
up to ~64K of unswappable memory.
|
up to ~64K of unswappable memory.
|
||||||
|
|
||||||
tcp_abort_on_overflow - BOOLEAN
|
tcp_max_syn_backlog - INTEGER
|
||||||
If listening service is too slow to accept new connections,
|
Maximal number of remembered connection requests, which are
|
||||||
reset them. Default state is FALSE. It means that if overflow
|
still did not receive an acknowledgment from connecting client.
|
||||||
occurred due to a burst, connection will recover. Enable this
|
Default value is 1024 for systems with more than 128Mb of memory,
|
||||||
option _only_ if you are really sure that listening daemon
|
and 128 for low memory machines. If server suffers of overload,
|
||||||
cannot be tuned to accept connections faster. Enabling this
|
try to increase this number.
|
||||||
option can harm clients of your server.
|
|
||||||
|
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
|
tcp_syncookies - BOOLEAN
|
||||||
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
|
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
|
synflood warnings in logs not being really flooded, your server
|
||||||
is seriously misconfigured.
|
is seriously misconfigured.
|
||||||
|
|
||||||
tcp_stdurg - BOOLEAN
|
tcp_syn_retries - INTEGER
|
||||||
Use the Host requirements interpretation of the TCP urg pointer field.
|
Number of times initial SYNs for an active TCP connection attempt
|
||||||
Most hosts use the older BSD interpretation, so if you turn this on
|
will be retransmitted. Should not be higher than 255. Default value
|
||||||
Linux might not communicate correctly with them.
|
is 5, which corresponds to ~180seconds.
|
||||||
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_timestamps - BOOLEAN
|
tcp_timestamps - BOOLEAN
|
||||||
Enable timestamps as defined in RFC1323.
|
Enable timestamps as defined in RFC1323.
|
||||||
|
|
||||||
tcp_sack - BOOLEAN
|
tcp_tso_win_divisor - INTEGER
|
||||||
Enable select acknowledgments (SACKS).
|
This allows control over what percentage of the congestion window
|
||||||
|
can be consumed by a single TSO frame.
|
||||||
tcp_fack - BOOLEAN
|
The setting of this parameter is a choice between burstiness and
|
||||||
Enable FACK congestion avoidance and fast retransmission.
|
building larger TSO frames.
|
||||||
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.
|
|
||||||
Default: 3
|
Default: 3
|
||||||
|
|
||||||
tcp_retrans_collapse - BOOLEAN
|
tcp_tw_recycle - BOOLEAN
|
||||||
Bug-to-bug compatibility with some broken printers.
|
Enable fast recycling TIME-WAIT sockets. Default value is 0.
|
||||||
On retransmit try to send bigger packets to work around bugs in
|
It should not be changed without advice/request of technical
|
||||||
certain TCP stacks.
|
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
|
tcp_wmem - vector of 3 INTEGERs: min, default, max
|
||||||
min: Amount of memory reserved for send buffers for TCP socket.
|
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.
|
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
|
||||||
Default: 128K
|
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
|
tcp_workaround_signed_windows - BOOLEAN
|
||||||
If set, assume no receipt of a window scaling option means the
|
If set, assume no receipt of a window scaling option means the
|
||||||
remote TCP is broken and treats the window as a signed quantity.
|
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.
|
not receive a window scaling option from them.
|
||||||
Default: 0
|
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:
|
CIPSOv4 Variables:
|
||||||
|
|
||||||
cipso_cache_enable - BOOLEAN
|
cipso_cache_enable - BOOLEAN
|
||||||
|
@ -974,4 +986,3 @@ no_cong_thresh FIXME
|
||||||
slot_timeout FIXME
|
slot_timeout FIXME
|
||||||
warn_noreply_time 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
|
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||||
size and number of buffers are set as following:
|
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
|
RAM size size size size size cnt cnt
|
||||||
-------- ------ ------ ------ ------ ------ ------
|
-------- ------ ------ ------ ------ ------ ------
|
||||||
128K 64K 64K 10K 10K 6 6
|
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
|
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
|
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
|
meta information like timestamp. So what we draw here a frame it's really
|
||||||
the following (from include/linux/if_packet.h):
|
the following (from include/linux/if_packet.h):
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
|
|
||||||
-------
|
-------
|
||||||
PHY Abstraction Layer
|
PHY Abstraction Layer
|
||||||
(Updated 2005-07-21)
|
(Updated 2006-11-30)
|
||||||
|
|
||||||
Purpose
|
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.
|
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
|
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:
|
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
|
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
|
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
|
This is useful if the system has put hardware restrictions on
|
||||||
the PHY/controller, of which the PHY needs to be aware.
|
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
|
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
|
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
|
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.
|
start, or disables then frees them for stop.
|
||||||
|
|
||||||
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
|
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
|
Attaches a network device to a particular PHY, binding the PHY to a generic
|
||||||
driver if none was found during bus initialization. Passes in
|
driver if none was found during bus initialization. Passes in
|
||||||
|
|
|
@ -63,8 +63,8 @@ Current:
|
||||||
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
||||||
763292pps 390Mb/sec (390805504bps) errors: 39664
|
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
|
This is done via the /proc interface easiest done via pgset in the scripts
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
@ -116,7 +116,7 @@ Examples:
|
||||||
there must be no spaces between the
|
there must be no spaces between the
|
||||||
arguments. Leading zeros are required.
|
arguments. Leading zeros are required.
|
||||||
Do not set the bottom of stack bit,
|
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
|
set the bottom of stack bit, that
|
||||||
indicates that you want to randomly
|
indicates that you want to randomly
|
||||||
generate that address and the flag
|
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
|
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
|
||||||
| | | | | | | | | |--> slow start size threshold,
|
| | | | | | | | | |--> slow start size threshold,
|
||||||
| | | | | | | | | or -1 if the treshold
|
| | | | | | | | | or -1 if the threshold
|
||||||
| | | | | | | | | is >= 0xFFFF
|
| | | | | | | | | is >= 0xFFFF
|
||||||
| | | | | | | | |----> sending congestion window
|
| | | | | | | | |----> sending congestion window
|
||||||
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
||||||
|
|
|
@ -346,7 +346,7 @@ Possible modes:
|
||||||
depending on the load of the system. If the driver detects that the
|
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
|
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
|
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.
|
negligible) the interrupt moderation will automatically be disabled.
|
||||||
|
|
||||||
Interrupt moderation should be used when the driver has to handle one or more
|
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
|
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
|
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 0 >boardnum
|
||||||
# echo internal >clock_source
|
# echo internal >clock_source
|
||||||
|
|
281
Documentation/networking/udplite.txt
Normal file
281
Documentation/networking/udplite.txt
Normal file
|
@ -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.
|
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
|
||||||
o Added the Multi-Port PPP
|
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
|
2.1.4 Aut 2000
|
||||||
o In X25API:
|
o In X25API:
|
||||||
|
@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000
|
||||||
|
|
||||||
o Cpipemon
|
o Cpipemon
|
||||||
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
|
- 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
|
All systems that cannot run cfgft1 GUI utility should
|
||||||
use cpipemon to configure the on board CSU/DSU.
|
use cpipemon to configure the on board CSU/DSU.
|
||||||
|
|
||||||
|
|
||||||
o Keyboard Led Monitor/Debugger
|
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
|
to convey operational statistic information of the
|
||||||
Sangoma WANPIPE cards.
|
Sangoma WANPIPE cards.
|
||||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
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
|
- Appropriate number of devices are dynamically loaded
|
||||||
based on the number of Sangoma cards found.
|
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.
|
CONFIG_WANPIPE_CARDS has been taken out.
|
||||||
|
|
||||||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
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_aevent_id {
|
||||||
struct xfrm_usersa_id sa_id;
|
struct xfrm_usersa_id sa_id;
|
||||||
|
xfrm_address_t saddr;
|
||||||
__u32 flags;
|
__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 used to indicate different things. The possible
|
||||||
flags are:
|
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
|
Please note that the character 'X' can be used as a wild card in the function
|
||||||
portion (last four characters).
|
portion (last four characters).
|
||||||
ex:
|
ex:
|
||||||
/* Unkown PnP modems */
|
/* Unknown PnP modems */
|
||||||
{ "PNPCXXX", UNKNOWN_DEV },
|
{ "PNPCXXX", UNKNOWN_DEV },
|
||||||
|
|
||||||
Supported PnP card IDs can optionally be defined.
|
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
|
events, which is implicit if it doesn't even support it in the first
|
||||||
place).
|
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
|
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
|
D3cold is bit 4. So, while a value of 4 as the state may not seem
|
||||||
semantically correct, it is.
|
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.)
|
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
|
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:
|
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
|
inconvenience, this method requires minimal work by the kernel, since
|
||||||
the firmware will also handle restoring memory contents on resume.
|
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
|
called 'swsusp' (Swap Suspend) is used to write memory contents to
|
||||||
free swap space. swsusp has some restrictive requirements, but should
|
free swap space. swsusp has some restrictive requirements, but should
|
||||||
work in most cases. Some, albeit outdated, documentation can be found
|
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
|
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
|
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
|
Q: What is the difference between "platform", "shutdown" and
|
||||||
|
|
|
@ -33,13 +33,13 @@
|
||||||
- Change version 16 format to always align
|
- Change version 16 format to always align
|
||||||
property data to 4 bytes. Since tokens are
|
property data to 4 bytes. Since tokens are
|
||||||
already aligned, that means no specific
|
already aligned, that means no specific
|
||||||
required alignement between property size
|
required alignment between property size
|
||||||
and property data. The old style variable
|
and property data. The old style variable
|
||||||
alignment would make it impossible to do
|
alignment would make it impossible to do
|
||||||
"simple" insertion of properties using
|
"simple" insertion of properties using
|
||||||
memove (thanks Milton for
|
memove (thanks Milton for
|
||||||
noticing). Updated kernel patch as well
|
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
|
- Add a chapter about the device-tree
|
||||||
compiler and the textural representation of
|
compiler and the textural representation of
|
||||||
the tree that can be "compiled" by dtc.
|
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
|
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
|
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
|
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
|
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||||
that the kernel tries to find out the default console and has
|
that the kernel tries to find out the default console and has
|
||||||
knowledge of various types like 8250 serial ports. You may want
|
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
|
- interrupt-parent : contains the phandle of the interrupt
|
||||||
controller which handles interrupts for this device
|
controller which handles interrupts for this device
|
||||||
- interrupts : a list of tuples representing the interrupt
|
- 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.
|
for this device.
|
||||||
|
|
||||||
This information is used by the kernel to build the interrupt table
|
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
|
1) the 'head' pointer or an subsequent linked list pointer
|
||||||
is not a valid address of a user space word
|
is not a valid address of a user space word
|
||||||
2) the calculated location of the 'lock word' (address plus
|
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
|
word
|
||||||
3) if the list contains more than 1 million (subject to
|
3) if the list contains more than 1 million (subject to
|
||||||
future kernel configuration changes) elements.
|
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,
|
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
|
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
|
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.
|
robust and normal futexes.
|
||||||
|
|
||||||
If a futex is found to be held at exit time, the kernel sets the
|
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.
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
perhaps more useful to include a small test program that demonstrates
|
||||||
how to use them, and demonstrates the features of the driver. This is
|
how to use them, and demonstrates the features of the driver. This is
|
||||||
probably a lot more useful to people interested in writing applications
|
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< -----------------------------
|
-------------------- 8< ---------------- 8< -----------------------------
|
||||||
|
|
||||||
|
@ -83,40 +184,67 @@ that will be using this driver.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#include <stdio.h>
|
#include <stdio.h>
|
||||||
#include <stdlib.h>
|
|
||||||
#include <linux/rtc.h>
|
#include <linux/rtc.h>
|
||||||
#include <sys/ioctl.h>
|
#include <sys/ioctl.h>
|
||||||
#include <sys/time.h>
|
#include <sys/time.h>
|
||||||
#include <sys/types.h>
|
#include <sys/types.h>
|
||||||
#include <fcntl.h>
|
#include <fcntl.h>
|
||||||
#include <unistd.h>
|
#include <unistd.h>
|
||||||
|
#include <stdlib.h>
|
||||||
#include <errno.h>
|
#include <errno.h>
|
||||||
|
|
||||||
int main(void) {
|
|
||||||
|
|
||||||
int i, fd, retval, irqcount = 0;
|
/*
|
||||||
unsigned long tmp, data;
|
* This expects the new RTC class driver framework, working with
|
||||||
struct rtc_time rtc_tm;
|
* 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) {
|
int main(int argc, char **argv)
|
||||||
perror("/dev/rtc");
|
{
|
||||||
|
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);
|
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) */
|
/* Turn on update interrupts (one per second) */
|
||||||
retval = ioctl(fd, RTC_UIE_ON, 0);
|
retval = ioctl(fd, RTC_UIE_ON, 0);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
|
if (errno == ENOTTY) {
|
||||||
|
fprintf(stderr,
|
||||||
|
"\n...Update IRQs not supported.\n");
|
||||||
|
goto test_READ;
|
||||||
|
}
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
|
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
|
||||||
fflush(stderr);
|
rtc);
|
||||||
for (i=1; i<6; i++) {
|
fflush(stderr);
|
||||||
|
for (i=1; i<6; i++) {
|
||||||
/* This read will block */
|
/* This read will block */
|
||||||
retval = read(fd, &data, sizeof(unsigned long));
|
retval = read(fd, &data, sizeof(unsigned long));
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
|
@ -126,11 +254,11 @@ for (i=1; i<6; i++) {
|
||||||
fprintf(stderr, " %d",i);
|
fprintf(stderr, " %d",i);
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
irqcount++;
|
irqcount++;
|
||||||
}
|
}
|
||||||
|
|
||||||
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
|
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
for (i=1; i<6; i++) {
|
for (i=1; i<6; i++) {
|
||||||
struct timeval tv = {5, 0}; /* 5 second timeout on select */
|
struct timeval tv = {5, 0}; /* 5 second timeout on select */
|
||||||
fd_set readfds;
|
fd_set readfds;
|
||||||
|
|
||||||
|
@ -151,96 +279,114 @@ for (i=1; i<6; i++) {
|
||||||
fprintf(stderr, " %d",i);
|
fprintf(stderr, " %d",i);
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
irqcount++;
|
irqcount++;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Turn off update interrupts */
|
/* Turn off update interrupts */
|
||||||
retval = ioctl(fd, RTC_UIE_OFF, 0);
|
retval = ioctl(fd, RTC_UIE_OFF, 0);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Read the RTC time/date */
|
test_READ:
|
||||||
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
|
/* Read the RTC time/date */
|
||||||
if (retval == -1) {
|
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
|
||||||
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
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_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
|
||||||
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
|
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 */
|
/* Set the alarm to 5 sec in the future, and check for rollover */
|
||||||
rtc_tm.tm_sec += 5;
|
rtc_tm.tm_sec += 5;
|
||||||
if (rtc_tm.tm_sec >= 60) {
|
if (rtc_tm.tm_sec >= 60) {
|
||||||
rtc_tm.tm_sec %= 60;
|
rtc_tm.tm_sec %= 60;
|
||||||
rtc_tm.tm_min++;
|
rtc_tm.tm_min++;
|
||||||
}
|
}
|
||||||
if (rtc_tm.tm_min == 60) {
|
if (rtc_tm.tm_min == 60) {
|
||||||
rtc_tm.tm_min = 0;
|
rtc_tm.tm_min = 0;
|
||||||
rtc_tm.tm_hour++;
|
rtc_tm.tm_hour++;
|
||||||
}
|
}
|
||||||
if (rtc_tm.tm_hour == 24)
|
if (rtc_tm.tm_hour == 24)
|
||||||
rtc_tm.tm_hour = 0;
|
rtc_tm.tm_hour = 0;
|
||||||
|
|
||||||
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
|
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
|
if (errno == ENOTTY) {
|
||||||
|
fprintf(stderr,
|
||||||
|
"\n...Alarm IRQs not supported.\n");
|
||||||
|
goto test_PIE;
|
||||||
|
}
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Read the current alarm settings */
|
/* Read the current alarm settings */
|
||||||
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
|
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
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);
|
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
|
||||||
|
|
||||||
/* Enable alarm interrupts */
|
/* Enable alarm interrupts */
|
||||||
retval = ioctl(fd, RTC_AIE_ON, 0);
|
retval = ioctl(fd, RTC_AIE_ON, 0);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
fprintf(stderr, "Waiting 5 seconds for alarm...");
|
fprintf(stderr, "Waiting 5 seconds for alarm...");
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
/* This blocks until the alarm ring causes an interrupt */
|
/* This blocks until the alarm ring causes an interrupt */
|
||||||
retval = read(fd, &data, sizeof(unsigned long));
|
retval = read(fd, &data, sizeof(unsigned long));
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("read");
|
perror("read");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
irqcount++;
|
irqcount++;
|
||||||
fprintf(stderr, " okay. Alarm rang.\n");
|
fprintf(stderr, " okay. Alarm rang.\n");
|
||||||
|
|
||||||
/* Disable alarm interrupts */
|
/* Disable alarm interrupts */
|
||||||
retval = ioctl(fd, RTC_AIE_OFF, 0);
|
retval = ioctl(fd, RTC_AIE_OFF, 0);
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Read periodic IRQ rate */
|
test_PIE:
|
||||||
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
|
/* Read periodic IRQ rate */
|
||||||
if (retval == -1) {
|
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");
|
perror("ioctl");
|
||||||
exit(errno);
|
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:");
|
fprintf(stderr, "Counting 20 interrupts at:");
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
|
|
||||||
/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
|
/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
|
||||||
for (tmp=2; tmp<=64; tmp*=2) {
|
for (tmp=2; tmp<=64; tmp*=2) {
|
||||||
|
|
||||||
retval = ioctl(fd, RTC_IRQP_SET, tmp);
|
retval = ioctl(fd, RTC_IRQP_SET, tmp);
|
||||||
if (retval == -1) {
|
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");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
@ -273,13 +419,12 @@ for (tmp=2; tmp<=64; tmp*=2) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
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]
|
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||||
- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
- Triple 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 (192bit key) [des3_ede -> des_z990]
|
||||||
|
|
||||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
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.
|
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
|
- Correct a reference to free'ed memory during controller
|
||||||
shutdown.
|
shutdown.
|
||||||
- Reset the bus on an SE->LVD change. This is required
|
- 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)
|
1.3.5 (March 24th, 2003)
|
||||||
- Fix a few register window mode bugs.
|
- 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)
|
1.3.0 (January 21st, 2003)
|
||||||
- Full regression testing for all U320 products completed.
|
- Full regression testing for all U320 products completed.
|
||||||
- Added abort and target/lun reset error recovery handler and
|
- Added abort and target/lun reset error recovery handler and
|
||||||
interrupt coalessing.
|
interrupt coalescing.
|
||||||
|
|
||||||
1.2.0 (November 14th, 2002)
|
1.2.0 (November 14th, 2002)
|
||||||
- Added support for Domain Validation
|
- 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
|
En/Disable High Byte LVD Termination
|
||||||
|
|
||||||
The upper 2 bits that deal with LVD termination only apply to Ultra2
|
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
|
designs, these bits are tied together such that setting either bit
|
||||||
enables both low and high byte LVD termination. It is not possible
|
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
|
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
|
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
|
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
|
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
|
a comma inside of those quotes as starting a new variable, resulting
|
||||||
in memory scribbles if you don't switch the commas to periods.
|
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
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
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
|
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,
|
decisive 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
|
it seems to work far better and more stable. Let us see what
|
||||||
the world thinks of it...
|
the world thinks of it...
|
||||||
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
|
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-
|
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
|
A long period of collecting bugreports from all corners of the world
|
||||||
now lead to the following corrections to the code:
|
now lead to the following corrections to the code:
|
||||||
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
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.
|
was that it is possible to disable Fast-SCSI for the external bus.
|
||||||
The feature-control command, where this crash appeared regularly tried
|
The feature-control command, where this crash appeared regularly, tried
|
||||||
to set the maximum speed of 10MHz synchronous transfer speed and that
|
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
|
the feature-command probes down from maximum speed until the adapter
|
||||||
stops to complain, which is at the same time the maximum possible
|
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
|
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
|
completed in such a way, that they are now completely conform to the
|
||||||
demands in the technical description of IBM. Main candidates were the
|
demands in the technical description of IBM. Main candidates were the
|
||||||
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
|
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
|
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
|
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
|
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
|
UPDATE NEWS: version 1.31 - 6 Jul 97
|
||||||
|
|
||||||
Fixed a bug that caused incorrect SCSI status bytes to be
|
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
|
means that CDROM changers work now! Fixed a bug in the
|
||||||
handling of command-line arguments when loaded as a module.
|
handling of command-line arguments when loaded as a module.
|
||||||
Also put all the header data in in2000.h where it belongs.
|
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
|
task_proto -- _one_ of enum sas_proto
|
||||||
scatter -- pointer to scatter gather list array
|
scatter -- pointer to scatter gather list array
|
||||||
num_scatter -- number of elements in scatter
|
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_...
|
data_dir -- PCI_DMA_...
|
||||||
task_done -- callback when the task has finished execution
|
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/
|
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/scsiinfo-X.Y.tar.gz
|
||||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-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
|
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
|
/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*
|
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:
|
broken devices. So you can try:
|
||||||
|
|
||||||
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
|
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.
|
strings then.
|
||||||
|
|
||||||
You can display these messages with the dmesg command (or check the
|
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.
|
driver, please include these messages.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -75,7 +75,7 @@ with the command.
|
||||||
|
|
||||||
- otherwise
|
- otherwise
|
||||||
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
|
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
|
[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
|
used instead of the equal mark. The definition is prepended by the
|
||||||
string st=. Here is an example:
|
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:
|
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
|
be sure I will receive it. Obviously, a bug in the driver code is
|
||||||
possible.
|
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
|
Allowing disconnections is important if you use several devices on
|
||||||
your SCSI bus but often causes problems with buggy devices.
|
your SCSI bus but often causes problems with buggy devices.
|
||||||
|
|
|
@ -942,13 +942,13 @@ replicas continue to be exactly same.
|
||||||
->mnt_slave
|
->mnt_slave
|
||||||
->mnt_master
|
->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.
|
send/receives propagation events.
|
||||||
|
|
||||||
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
||||||
to.
|
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.
|
propagates to.
|
||||||
|
|
||||||
->mnt_master points to the master vfsmount from which this vfsmount
|
->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,
|
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
|
||||||
phase88, mediastation
|
phase88, mediastation
|
||||||
omni - Omni I/O support for MidiMan M-Audio Delta44/66
|
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)
|
in msec resolution, default value is 500 (0.5 sec)
|
||||||
|
|
||||||
This module supports multiple cards and autoprobe. Note: The consumer part
|
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
|
The EMU10K2 chips have a DSP part which can be programmed to support
|
||||||
various ways of sample processing, which is described here.
|
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.)
|
EMU10K2 chips. See the manuals section for further details.)
|
||||||
|
|
||||||
The ALSA driver programs this portion of chip by default code
|
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
|
The EMU10K1 chips have a DSP part which can be programmed to support
|
||||||
various ways of sample processing, which is described here.
|
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.)
|
EMU10K1 chips. See the manuals section for further details.)
|
||||||
|
|
||||||
The ALSA driver programs this portion of chip by default code
|
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.
|
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 is made up of a number of kernel developers who have volunteered for
|
||||||
this task, and a few that haven't.
|
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
|
readable by root only. This allows the end user to remove
|
||||||
such a dump but not access it directly. For security reasons
|
such a dump but not access it directly. For security reasons
|
||||||
core dumps in this mode will not overwrite one another or
|
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.
|
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:
|
||||||
|
|
||||||
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
|
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
|
zone reclaim occurs. Allocations will be satisfied from other zones / nodes
|
||||||
in the system.
|
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-
|
exploitable as a security hole. However, it does allow anyone to cre-
|
||||||
ate useless tap devices (useless because they can't configure them),
|
ate useless tap devices (useless because they can't configure them),
|
||||||
which is a DOS attack. A somewhat more secure alternative would to be
|
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
|
examples for this are power devices (especially uninterruptable power
|
||||||
supplies) and monitor control on higher end monitors.
|
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:
|
HID events to two separate interfaces:
|
||||||
* the input subsystem, which converts HID events into normal input
|
* the input subsystem, which converts HID events into normal input
|
||||||
device interfaces (such as keyboard, mouse and joystick) and a
|
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.
|
inconsequential.
|
||||||
|
|
||||||
It seems that the Rio has a problem when sending .mp3 with low batteries.
|
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
|
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
|
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.
|
memory.
|
||||||
|
|
||||||
In an extreme case, I left my Rio playing overnight and the batteries wore
|
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:
|
Current status:
|
||||||
The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and
|
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
|
character settings. Other character lengths and parity setups are
|
||||||
presently untested.
|
presently untested.
|
||||||
|
|
||||||
|
@ -253,7 +253,7 @@ Cypress M8 CY4601 Family Serial Driver
|
||||||
together without hacking the adapter to set the line high.
|
together without hacking the adapter to set the line high.
|
||||||
|
|
||||||
The driver is smp safe. Performance with the driver is rather low when using
|
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.
|
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
|
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
|
Parity N,E,O,M,S
|
||||||
Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
|
Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
|
||||||
Break Set and clear
|
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
|
* Hardware input flow control is only enabled for firmware
|
||||||
levels above 2.06. Read source code comments describing Belkin
|
levels above 2.06. Read source code comments describing Belkin
|
||||||
|
@ -309,7 +309,7 @@ Belkin USB Serial Adapter F5U103
|
||||||
automatic hardware flow control.
|
automatic hardware flow control.
|
||||||
|
|
||||||
TO DO List:
|
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.
|
states reported by the interrupt and the states requested.
|
||||||
-- Add error reporting back to application for UART error conditions.
|
-- Add error reporting back to application for UART error conditions.
|
||||||
-- Add support for flush ioctls.
|
-- 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
|
Finally the SETOPTIONS ioctl can be used to control some aspects of
|
||||||
the cards operation; right now the pcwd driver is the only one
|
the cards operation; right now the pcwd driver is the only one
|
||||||
supporting thiss ioctl.
|
supporting this ioctl.
|
||||||
|
|
||||||
int options = 0;
|
int options = 0;
|
||||||
ioctl(fd, WDIOC_SETOPTIONS, options);
|
ioctl(fd, WDIOC_SETOPTIONS, options);
|
||||||
|
|
25
MAINTAINERS
25
MAINTAINERS
|
@ -353,6 +353,12 @@ P: Richard Purdie
|
||||||
M: rpurdie@rpsys.net
|
M: rpurdie@rpsys.net
|
||||||
S: Maintained
|
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
|
ARM/TOSA MACHINE SUPPORT
|
||||||
P: Dirk Opfer
|
P: Dirk Opfer
|
||||||
M: dirk@opfer-online.de
|
M: dirk@opfer-online.de
|
||||||
|
@ -426,6 +432,13 @@ L: linux-atm-general@lists.sourceforge.net (subscribers-only)
|
||||||
W: http://linux-atm.sourceforge.net
|
W: http://linux-atm.sourceforge.net
|
||||||
S: Maintained
|
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
|
ATMEL WIRELESS DRIVER
|
||||||
P: Simon Kelley
|
P: Simon Kelley
|
||||||
M: simon@thekelleys.org.uk
|
M: simon@thekelleys.org.uk
|
||||||
|
@ -1153,11 +1166,6 @@ P: David Howells
|
||||||
M: dhowells@redhat.com
|
M: dhowells@redhat.com
|
||||||
S: Maintained
|
S: Maintained
|
||||||
|
|
||||||
FTAPE/QIC-117
|
|
||||||
L: linux-tape@vger.kernel.org
|
|
||||||
W: http://sourceforge.net/projects/ftape
|
|
||||||
S: Orphan
|
|
||||||
|
|
||||||
FUSE: FILESYSTEM IN USERSPACE
|
FUSE: FILESYSTEM IN USERSPACE
|
||||||
P: Miklos Szeredi
|
P: Miklos Szeredi
|
||||||
M: miklos@szeredi.hu
|
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
|
T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
|
||||||
S: Maintained
|
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
|
IPVS
|
||||||
P: Wensong Zhang
|
P: Wensong Zhang
|
||||||
M: wensong@linux-vs.org
|
M: wensong@linux-vs.org
|
||||||
|
|
2
Makefile
2
Makefile
|
@ -1,7 +1,7 @@
|
||||||
VERSION = 2
|
VERSION = 2
|
||||||
PATCHLEVEL = 6
|
PATCHLEVEL = 6
|
||||||
SUBLEVEL = 19
|
SUBLEVEL = 19
|
||||||
EXTRAVERSION =-rc6
|
EXTRAVERSION =
|
||||||
NAME=Avast! A bilge rat!
|
NAME=Avast! A bilge rat!
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
|
|
|
@ -41,28 +41,25 @@ static inline unsigned short from64to16(unsigned long x)
|
||||||
* computes the checksum of the TCP/UDP pseudo-header
|
* computes the checksum of the TCP/UDP pseudo-header
|
||||||
* returns a 16-bit checksum, already complemented.
|
* returns a 16-bit checksum, already complemented.
|
||||||
*/
|
*/
|
||||||
unsigned short int csum_tcpudp_magic(unsigned long saddr,
|
__sum16 csum_tcpudp_magic(__be32 saddr, __be32 daddr,
|
||||||
unsigned long daddr,
|
|
||||||
unsigned short len,
|
unsigned short len,
|
||||||
unsigned short proto,
|
unsigned short proto,
|
||||||
unsigned int sum)
|
__wsum sum)
|
||||||
{
|
{
|
||||||
return ~from64to16(saddr + daddr + sum +
|
return (__force __sum16)~from64to16(
|
||||||
((unsigned long) ntohs(len) << 16) +
|
(__force u64)saddr + (__force u64)daddr +
|
||||||
((unsigned long) proto << 8));
|
(__force u64)sum + ((len + proto) << 8));
|
||||||
}
|
}
|
||||||
|
|
||||||
unsigned int csum_tcpudp_nofold(unsigned long saddr,
|
__wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
|
||||||
unsigned long daddr,
|
|
||||||
unsigned short len,
|
unsigned short len,
|
||||||
unsigned short proto,
|
unsigned short proto,
|
||||||
unsigned int sum)
|
__wsum sum)
|
||||||
{
|
{
|
||||||
unsigned long result;
|
unsigned long result;
|
||||||
|
|
||||||
result = (saddr + daddr + sum +
|
result = (__force u64)saddr + (__force u64)daddr +
|
||||||
((unsigned long) ntohs(len) << 16) +
|
(__force u64)sum + ((len + proto) << 8);
|
||||||
((unsigned long) proto << 8));
|
|
||||||
|
|
||||||
/* Fold down to 32-bits so we don't lose in the typedef-less
|
/* Fold down to 32-bits so we don't lose in the typedef-less
|
||||||
network stack. */
|
network stack. */
|
||||||
|
@ -70,7 +67,7 @@ unsigned int csum_tcpudp_nofold(unsigned long saddr,
|
||||||
result = (result & 0xffffffff) + (result >> 32);
|
result = (result & 0xffffffff) + (result >> 32);
|
||||||
/* 33 to 32 */
|
/* 33 to 32 */
|
||||||
result = (result & 0xffffffff) + (result >> 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,
|
* This is a version of ip_compute_csum() optimized for IP headers,
|
||||||
* which always checksum on 4 octet boundaries.
|
* 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
|
* 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);
|
unsigned long result = do_csum(buff, len);
|
||||||
|
|
||||||
/* add in old sum, and carry.. */
|
/* add in old sum, and carry.. */
|
||||||
result += sum;
|
result += (__force u32)sum;
|
||||||
/* 32+c bits -> 32 bits */
|
/* 32+c bits -> 32 bits */
|
||||||
result = (result & 0xffffffff) + (result >> 32);
|
result = (result & 0xffffffff) + (result >> 32);
|
||||||
return result;
|
return (__force __wsum)result;
|
||||||
}
|
}
|
||||||
|
|
||||||
EXPORT_SYMBOL(csum_partial);
|
EXPORT_SYMBOL(csum_partial);
|
||||||
|
@ -180,7 +177,7 @@ EXPORT_SYMBOL(csum_partial);
|
||||||
* this routine is used for miscellaneous IP-like checksums, mainly
|
* this routine is used for miscellaneous IP-like checksums, mainly
|
||||||
* in icmp.c
|
* 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;
|
return checksum;
|
||||||
}
|
}
|
||||||
|
|
||||||
static unsigned int
|
__wsum
|
||||||
do_csum_partial_copy_from_user(const char __user *src, char *dst, int len,
|
csum_partial_copy_from_user(const void __user *src, void *dst, int len,
|
||||||
unsigned int sum, int *errp)
|
__wsum sum, int *errp)
|
||||||
{
|
{
|
||||||
unsigned long checksum = (unsigned) sum;
|
unsigned long checksum = (__force u32) sum;
|
||||||
unsigned long soff = 7 & (unsigned long) src;
|
unsigned long soff = 7 & (unsigned long) src;
|
||||||
unsigned long doff = 7 & (unsigned long) dst;
|
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);
|
checksum = from64to16 (checksum);
|
||||||
}
|
}
|
||||||
return checksum;
|
return (__force __wsum)checksum;
|
||||||
}
|
}
|
||||||
|
|
||||||
unsigned int
|
__wsum
|
||||||
csum_partial_copy_from_user(const char __user *src, char *dst, int len,
|
csum_partial_copy_nocheck(const void *src, void *dst, int len, __wsum sum)
|
||||||
unsigned int sum, int *errp)
|
|
||||||
{
|
{
|
||||||
if (!access_ok(VERIFY_READ, src, len)) {
|
return csum_partial_copy_from_user((__force const void __user *)src,
|
||||||
*errp = -EFAULT;
|
dst, len, sum, NULL);
|
||||||
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);
|
|
||||||
}
|
}
|
||||||
|
|
|
@ -879,6 +879,8 @@ endif
|
||||||
|
|
||||||
source "drivers/scsi/Kconfig"
|
source "drivers/scsi/Kconfig"
|
||||||
|
|
||||||
|
source "drivers/ata/Kconfig"
|
||||||
|
|
||||||
source "drivers/md/Kconfig"
|
source "drivers/md/Kconfig"
|
||||||
|
|
||||||
source "drivers/message/fusion/Kconfig"
|
source "drivers/message/fusion/Kconfig"
|
||||||
|
|
|
@ -184,6 +184,7 @@ CONFIG_BINFMT_ELF=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
# CONFIG_APM is not set
|
# CONFIG_APM is not set
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -194,6 +194,7 @@ CONFIG_BINFMT_ELF=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
# CONFIG_APM is not set
|
# CONFIG_APM is not set
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -208,6 +208,7 @@ CONFIG_BINFMT_MISC=m
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
CONFIG_APM=y
|
CONFIG_APM=y
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -194,6 +194,7 @@ CONFIG_BINFMT_ELF=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
# CONFIG_APM is not set
|
# CONFIG_APM is not set
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -190,6 +190,7 @@ CONFIG_BINFMT_ELF=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
# CONFIG_APM is not set
|
# CONFIG_APM is not set
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -182,6 +182,7 @@ CONFIG_BINFMT_AOUT=m
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
# CONFIG_APM is not set
|
# CONFIG_APM is not set
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -180,6 +180,7 @@ CONFIG_BINFMT_AOUT=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
CONFIG_APM=m
|
CONFIG_APM=m
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -190,6 +190,7 @@ CONFIG_BINFMT_AOUT=y
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
CONFIG_APM=y
|
CONFIG_APM=y
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -180,6 +180,7 @@ CONFIG_BINFMT_MISC=m
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
CONFIG_APM=y
|
CONFIG_APM=y
|
||||||
|
|
||||||
#
|
#
|
||||||
|
|
|
@ -207,6 +207,7 @@ CONFIG_BINFMT_MISC=m
|
||||||
# Power management options
|
# Power management options
|
||||||
#
|
#
|
||||||
CONFIG_PM=y
|
CONFIG_PM=y
|
||||||
|
# CONFIG_PM_LEGACY is not set
|
||||||
CONFIG_APM=y
|
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,
|
return smp_call_function_on_cpu(func, info, retry, wait,
|
||||||
cpu_online_map);
|
cpu_online_map);
|
||||||
}
|
}
|
||||||
|
EXPORT_SYMBOL_GPL(smp_call_function);
|
||||||
|
|
||||||
void show_ipi_list(struct seq_file *p)
|
void show_ipi_list(struct seq_file *p)
|
||||||
{
|
{
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue