Merge branch 'linux-2.6' into for-linus
This commit is contained in:
Paul Mackerras
Коммит
79acbb3ff2
|
|
@ -20,6 +20,7 @@
|
|||
# Top-level generic files
|
||||
#
|
||||
tags
|
||||
TAGS
|
||||
vmlinux*
|
||||
System.map
|
||||
Module.symvers
|
||||
|
|
|
|||
11
CREDITS
11
CREDITS
|
|
@ -45,7 +45,7 @@ S: Longford, Ireland
|
|||
S: Sydney, Australia
|
||||
|
||||
N: Tigran A. Aivazian
|
||||
E: tigran@veritas.com
|
||||
E: tigran@aivazian.fsnet.co.uk
|
||||
W: http://www.moses.uklinux.net/patches
|
||||
D: BFS filesystem
|
||||
D: Intel IA32 CPU microcode update support
|
||||
|
|
@ -2598,6 +2598,9 @@ S: Ucitelska 1576
|
|||
S: Prague 8
|
||||
S: 182 00 Czech Republic
|
||||
|
||||
N: Rick Payne
|
||||
D: RFC2385 Support for TCP
|
||||
|
||||
N: Barak A. Pearlmutter
|
||||
E: bap@cs.unm.edu
|
||||
W: http://www.cs.unm.edu/~bap/
|
||||
|
|
@ -3511,14 +3514,12 @@ D: The Linux Support Team Erlangen
|
|||
|
||||
N: David Weinehall
|
||||
E: tao@acc.umu.se
|
||||
P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16
|
||||
W: http://www.acc.umu.se/~tao/
|
||||
W: http://www.acc.umu.se/~mcalinux/
|
||||
D: v2.0 kernel maintainer
|
||||
D: Fixes for the NE/2-driver
|
||||
D: Miscellaneous MCA-support
|
||||
D: Cleanup of the Config-files
|
||||
S: Axtorpsvagen 40:20
|
||||
S: S-903 37 UMEA
|
||||
S: Sweden
|
||||
|
||||
N: Matt Welsh
|
||||
E: mdw@metalab.unc.edu
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Description:
|
|||
these states.
|
||||
|
||||
What: /sys/power/disk
|
||||
Date: August 2006
|
||||
Date: September 2006
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/power/disk file controls the operating mode of the
|
||||
|
|
@ -39,6 +39,19 @@ Description:
|
|||
'reboot' - the memory image will be saved by the kernel and
|
||||
the system will be rebooted.
|
||||
|
||||
Additionally, /sys/power/disk can be used to turn on one of the
|
||||
two testing modes of the suspend-to-disk mechanism: 'testproc'
|
||||
or 'test'. If the suspend-to-disk mechanism is in the
|
||||
'testproc' mode, writing 'disk' to /sys/power/state will cause
|
||||
the kernel to disable nonboot CPUs and freeze tasks, wait for 5
|
||||
seconds, unfreeze tasks and enable nonboot CPUs. If it is in
|
||||
the 'test' mode, writing 'disk' to /sys/power/state will cause
|
||||
the kernel to disable nonboot CPUs and freeze tasks, shrink
|
||||
memory, suspend devices, wait for 5 seconds, resume devices,
|
||||
unfreeze tasks and enable nonboot CPUs. Then, we are able to
|
||||
look in the log messages and work out, for example, which code
|
||||
is being slow and which device drivers are misbehaving.
|
||||
|
||||
The suspend-to-disk method may be chosen by writing to this
|
||||
file one of the accepted strings:
|
||||
|
||||
|
|
@ -46,6 +59,8 @@ Description:
|
|||
'platform'
|
||||
'shutdown'
|
||||
'reboot'
|
||||
'testproc'
|
||||
'test'
|
||||
|
||||
It will only change to 'firmware' or 'platform' if the system
|
||||
supports that.
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ udev
|
|||
----
|
||||
udev is a userspace application for populating /dev dynamically with
|
||||
only entries for devices actually present. udev replaces the basic
|
||||
functionality of devfs, while allowing persistant device naming for
|
||||
functionality of devfs, while allowing persistent device naming for
|
||||
devices.
|
||||
|
||||
FUSE
|
||||
|
|
|
|||
|
|
@ -489,7 +489,7 @@ size is the size of the area (must be multiples of PAGE_SIZE).
|
|||
flags can be or'd together and are
|
||||
|
||||
DMA_MEMORY_MAP - request that the memory returned from
|
||||
dma_alloc_coherent() be directly writeable.
|
||||
dma_alloc_coherent() be directly writable.
|
||||
|
||||
DMA_MEMORY_IO - request that the memory returned from
|
||||
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ lock.
|
|||
|
||||
Once the DMA transfer is finished (or timed out) you should disable
|
||||
the channel again. You should also check get_dma_residue() to make
|
||||
sure that all data has been transfered.
|
||||
sure that all data has been transferred.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
||||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||
procfs-guide.xml writing_usb_driver.xml \
|
||||
kernel-api.xml journal-api.xml lsm.xml usb.xml \
|
||||
kernel-api.xml filesystems.xml lsm.xml usb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml
|
||||
|
||||
|
|
|
|||
|
|
@ -2,37 +2,9 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="LinuxJBDAPI">
|
||||
<book id="Linux-filesystems-API">
|
||||
<bookinfo>
|
||||
<title>The Linux Journalling API</title>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Roger</firstname>
|
||||
<surname>Gammans</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>rgammans@computer-surgery.co.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Stephen</firstname>
|
||||
<surname>Tweedie</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>sct@redhat.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
<holder>Roger Gammans</holder>
|
||||
</copyright>
|
||||
<title>Linux Filesystems API</title>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
|
|
@ -66,9 +38,105 @@
|
|||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="Overview">
|
||||
<title>Overview</title>
|
||||
<chapter id="vfs">
|
||||
<title>The Linux VFS</title>
|
||||
<sect1><title>The Filesystem types</title>
|
||||
!Iinclude/linux/fs.h
|
||||
</sect1>
|
||||
<sect1><title>The Directory Cache</title>
|
||||
!Efs/dcache.c
|
||||
!Iinclude/linux/dcache.h
|
||||
</sect1>
|
||||
<sect1><title>Inode Handling</title>
|
||||
!Efs/inode.c
|
||||
!Efs/bad_inode.c
|
||||
</sect1>
|
||||
<sect1><title>Registration and Superblocks</title>
|
||||
!Efs/super.c
|
||||
</sect1>
|
||||
<sect1><title>File Locks</title>
|
||||
!Efs/locks.c
|
||||
!Ifs/locks.c
|
||||
</sect1>
|
||||
<sect1><title>Other Functions</title>
|
||||
!Efs/mpage.c
|
||||
!Efs/namei.c
|
||||
!Efs/buffer.c
|
||||
!Efs/bio.c
|
||||
!Efs/seq_file.c
|
||||
!Efs/filesystems.c
|
||||
!Efs/fs-writeback.c
|
||||
!Efs/block_dev.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="proc">
|
||||
<title>The proc filesystem</title>
|
||||
|
||||
<sect1><title>sysctl interface</title>
|
||||
!Ekernel/sysctl.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>proc filesystem interface</title>
|
||||
!Ifs/proc/base.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="sysfs">
|
||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
!Efs/sysfs/symlink.c
|
||||
!Efs/sysfs/bin.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="debugfs">
|
||||
<title>The debugfs filesystem</title>
|
||||
|
||||
<sect1><title>debugfs interface</title>
|
||||
!Efs/debugfs/inode.c
|
||||
!Efs/debugfs/file.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="LinuxJDBAPI">
|
||||
<chapterinfo>
|
||||
<title>The Linux Journalling API</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Roger</firstname>
|
||||
<surname>Gammans</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>rgammans@computer-surgery.co.uk</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Stephen</firstname>
|
||||
<surname>Tweedie</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>sct@redhat.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
<holder>Roger Gammans</holder>
|
||||
</copyright>
|
||||
</chapterinfo>
|
||||
|
||||
<title>The Linux Journalling API</title>
|
||||
|
||||
<sect1>
|
||||
<title>Overview</title>
|
||||
<sect2>
|
||||
<title>Details</title>
|
||||
<para>
|
||||
The journalling layer is easy to use. You need to
|
||||
|
|
@ -111,7 +179,6 @@ Now you can go ahead and start modifying the underlying
|
|||
filesystem. Almost.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
|
||||
You still need to actually journal your filesystem changes, this
|
||||
|
|
@ -156,7 +223,6 @@ Then at umount time , in your put_super() (2.4) or write_super() (2.5)
|
|||
you can then call journal_destroy() to clean up your in-core journal object.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Unfortunately there a couple of ways the journal layer can cause a deadlock.
|
||||
The first thing to note is that each task can only have
|
||||
|
|
@ -239,9 +305,9 @@ this would be useful if you needed to know when data was committed to a
|
|||
particular inode.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<title>Summary</title>
|
||||
<para>
|
||||
Using the journal is a matter of wrapping the different context changes,
|
||||
|
|
@ -279,11 +345,11 @@ an example.
|
|||
}
|
||||
journal_destroy(my_jrnl);
|
||||
</programlisting>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="adt">
|
||||
<sect1>
|
||||
<title>Data Types</title>
|
||||
<para>
|
||||
The journalling layer uses typedefs to 'hide' the concrete definitions
|
||||
|
|
@ -292,27 +358,27 @@ an example.
|
|||
|
||||
Obviously the hiding is not enforced as this is 'C'.
|
||||
</para>
|
||||
<sect1><title>Structures</title>
|
||||
<sect2><title>Structures</title>
|
||||
!Iinclude/linux/jbd.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="calls">
|
||||
<sect1>
|
||||
<title>Functions</title>
|
||||
<para>
|
||||
The functions here are split into two groups those that
|
||||
affect a journal as a whole, and those which are used to
|
||||
manage transactions
|
||||
</para>
|
||||
<sect1><title>Journal Level</title>
|
||||
<sect2><title>Journal Level</title>
|
||||
!Efs/jbd/journal.c
|
||||
!Ifs/jbd/recovery.c
|
||||
</sect1>
|
||||
<sect1><title>Transasction Level</title>
|
||||
</sect2>
|
||||
<sect2><title>Transasction Level</title>
|
||||
!Efs/jbd/transaction.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter>
|
||||
<sect1>
|
||||
<title>See also</title>
|
||||
<para>
|
||||
<citation>
|
||||
|
|
@ -328,6 +394,8 @@ an example.
|
|||
</ulink>
|
||||
</citation>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
@ -182,66 +182,6 @@ X!Ilib/string.c
|
|||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="vfs">
|
||||
<title>The Linux VFS</title>
|
||||
<sect1><title>The Filesystem types</title>
|
||||
!Iinclude/linux/fs.h
|
||||
</sect1>
|
||||
<sect1><title>The Directory Cache</title>
|
||||
!Efs/dcache.c
|
||||
!Iinclude/linux/dcache.h
|
||||
</sect1>
|
||||
<sect1><title>Inode Handling</title>
|
||||
!Efs/inode.c
|
||||
!Efs/bad_inode.c
|
||||
</sect1>
|
||||
<sect1><title>Registration and Superblocks</title>
|
||||
!Efs/super.c
|
||||
</sect1>
|
||||
<sect1><title>File Locks</title>
|
||||
!Efs/locks.c
|
||||
!Ifs/locks.c
|
||||
</sect1>
|
||||
<sect1><title>Other Functions</title>
|
||||
!Efs/mpage.c
|
||||
!Efs/namei.c
|
||||
!Efs/buffer.c
|
||||
!Efs/bio.c
|
||||
!Efs/seq_file.c
|
||||
!Efs/filesystems.c
|
||||
!Efs/fs-writeback.c
|
||||
!Efs/block_dev.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="proc">
|
||||
<title>The proc filesystem</title>
|
||||
|
||||
<sect1><title>sysctl interface</title>
|
||||
!Ekernel/sysctl.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>proc filesystem interface</title>
|
||||
!Ifs/proc/base.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="sysfs">
|
||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
!Efs/sysfs/symlink.c
|
||||
!Efs/sysfs/bin.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="debugfs">
|
||||
<title>The debugfs filesystem</title>
|
||||
|
||||
<sect1><title>debugfs interface</title>
|
||||
!Efs/debugfs/inode.c
|
||||
!Efs/debugfs/file.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="relayfs">
|
||||
<title>relay interface support</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -345,7 +345,6 @@ static inline void skel_delete (struct usb_skel *dev)
|
|||
usb_buffer_free (dev->udev, dev->bulk_out_size,
|
||||
dev->bulk_out_buffer,
|
||||
dev->write_urb->transfer_dma);
|
||||
if (dev->write_urb != NULL)
|
||||
usb_free_urb (dev->write_urb);
|
||||
kfree (dev);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -395,6 +395,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here)
|
|||
|
||||
|
||||
|
||||
Managing bug reports
|
||||
--------------------
|
||||
|
||||
One of the best ways to put into practice your hacking skills is by fixing
|
||||
bugs reported by other people. Not only you will help to make the kernel
|
||||
more stable, you'll learn to fix real world problems and you will improve
|
||||
your skills, and other developers will be aware of your presence. Fixing
|
||||
bugs is one of the best ways to get merits among other developers, because
|
||||
not many people like wasting time fixing other people's bugs.
|
||||
|
||||
To work in the already reported bug reports, go to http://bugzilla.kernel.org.
|
||||
If you want to be advised of the future bug reports, you can subscribe to the
|
||||
bugme-new mailing list (only new bug reports are mailed here) or to the
|
||||
bugme-janitor mailing list (every change in the bugzilla is mailed here)
|
||||
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-new
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-janitors
|
||||
|
||||
|
||||
|
||||
Mailing lists
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ into the field vector of each element contained in a second argument.
|
|||
Note that the pre-assigned IOAPIC dev->irq is valid only if the device
|
||||
operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
|
||||
using dev->irq by the device driver to request for interrupt service
|
||||
may result unpredictabe behavior.
|
||||
may result in unpredictable behavior.
|
||||
|
||||
For each MSI-X vector granted, a device driver is responsible for calling
|
||||
other functions like request_irq(), enable_irq(), etc. to enable
|
||||
|
|
@ -470,7 +470,68 @@ LOC: 324553 325068
|
|||
ERR: 0
|
||||
MIS: 0
|
||||
|
||||
6. FAQ
|
||||
6. MSI quirks
|
||||
|
||||
Several PCI chipsets or devices are known to not support MSI.
|
||||
The PCI stack provides 3 possible levels of MSI disabling:
|
||||
* on a single device
|
||||
* on all devices behind a specific bridge
|
||||
* globally
|
||||
|
||||
6.1. Disabling MSI on a single device
|
||||
|
||||
Under some circumstances, it might be required to disable MSI on a
|
||||
single device, It may be achived by either not calling pci_enable_msi()
|
||||
or all, or setting the pci_dev->no_msi flag before (most of the time
|
||||
in a quirk).
|
||||
|
||||
6.2. Disabling MSI below a bridge
|
||||
|
||||
The vast majority of MSI quirks are required by PCI bridges not
|
||||
being able to route MSI between busses. In this case, MSI have to be
|
||||
disabled on all devices behind this bridge. It is achieves by setting
|
||||
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
|
||||
subordinate bus. There is no need to set the same flag on bridges that
|
||||
are below the broken brigde. When pci_enable_msi() is called to enable
|
||||
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
|
||||
flag in all parent busses of the device.
|
||||
|
||||
Some bridges actually support dynamic MSI support enabling/disabling
|
||||
by changing some bits in their PCI configuration space (especially
|
||||
the Hypertransport chipsets such as the nVidia nForce and Serverworks
|
||||
HT2000). It may then be required to update the NO_MSI flag on the
|
||||
corresponding devices in the sysfs hierarchy. To enable MSI support
|
||||
on device "0000:00:0e", do:
|
||||
|
||||
echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus
|
||||
|
||||
To disable MSI support, echo 0 instead of 1. Note that it should be
|
||||
used with caution since changing this value might break interrupts.
|
||||
|
||||
6.3. Disabling MSI globally
|
||||
|
||||
Some extreme cases may require to disable MSI globally on the system.
|
||||
For now, the only known case is a Serverworks PCI-X chipsets (MSI are
|
||||
not supported on several busses that are not all connected to the
|
||||
chipset in the Linux PCI hierarchy). In the vast majority of other
|
||||
cases, disabling only behind a specific bridge is enough.
|
||||
|
||||
For debugging purpose, the user may also pass pci=nomsi on the kernel
|
||||
command-line to explicitly disable MSI globally. But, once the appro-
|
||||
priate quirks are added to the kernel, this option should not be
|
||||
required anymore.
|
||||
|
||||
6.4. Finding why MSI cannot be enabled on a device
|
||||
|
||||
Assuming that MSI are not enabled on a device, you should look at
|
||||
dmesg to find messages that quirks may output when disabling MSI
|
||||
on some devices, some bridges or even globally.
|
||||
Then, lspci -t gives the list of bridges above a device. Reading
|
||||
/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
|
||||
are enabled (1) or disabled (0). In 0 is found in a single bridge
|
||||
msi_bus file above the device, MSI cannot be enabled.
|
||||
|
||||
7. FAQ
|
||||
|
||||
Q1. Are there any limitations on using the MSI?
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ __u64 stime, utime;
|
|||
}
|
||||
|
||||
/* Maximum size of response requested or message sent */
|
||||
#define MAX_MSG_SIZE 256
|
||||
#define MAX_MSG_SIZE 1024
|
||||
/* Maximum number of cpus expected to be specified in a cpumask */
|
||||
#define MAX_CPUS 32
|
||||
/* Maximum length of pathname to log file */
|
||||
|
|
|
|||
|
|
@ -96,9 +96,9 @@ a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates
|
|||
a pid/tgid will be followed by some stats.
|
||||
|
||||
b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
|
||||
is being returned.
|
||||
are being returned.
|
||||
|
||||
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstsats as payload. The
|
||||
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
|
||||
same structure is used for both per-pid and per-tgid stats.
|
||||
|
||||
3. New message sent by kernel whenever a task exits. The payload consists of a
|
||||
|
|
@ -122,12 +122,12 @@ of atomicity).
|
|||
|
||||
However, maintaining per-process, in addition to per-task stats, within the
|
||||
kernel has space and time overheads. To address this, the taskstats code
|
||||
accumalates each exiting task's statistics into a process-wide data structure.
|
||||
When the last task of a process exits, the process level data accumalated also
|
||||
accumulates each exiting task's statistics into a process-wide data structure.
|
||||
When the last task of a process exits, the process level data accumulated also
|
||||
gets sent to userspace (along with the per-task data).
|
||||
|
||||
When a user queries to get per-tgid data, the sum of all other live threads in
|
||||
the group is added up and added to the accumalated total for previously exited
|
||||
the group is added up and added to the accumulated total for previously exited
|
||||
threads of the same thread group.
|
||||
|
||||
Extending taskstats
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ it, the pci dma mapping routines and associated data structures have now been
|
|||
modified to accomplish a direct page -> bus translation, without requiring
|
||||
a virtual address mapping (unlike the earlier scheme of virtual address
|
||||
-> bus translation). So this works uniformly for high-memory pages (which
|
||||
do not have a correponding kernel virtual address space mapping) and
|
||||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
|
||||
|
|
@ -391,7 +391,7 @@ forced such requests to be broken up into small chunks before being passed
|
|||
on to the generic block layer, only to be merged by the i/o scheduler
|
||||
when the underlying device was capable of handling the i/o in one shot.
|
||||
Also, using the buffer head as an i/o structure for i/os that didn't originate
|
||||
from the buffer cache unecessarily added to the weight of the descriptors
|
||||
from the buffer cache unnecessarily added to the weight of the descriptors
|
||||
which were generated for each such chunk.
|
||||
|
||||
The following were some of the goals and expectations considered in the
|
||||
|
|
@ -403,14 +403,14 @@ i. Should be appropriate as a descriptor for both raw and buffered i/o -
|
|||
for raw i/o.
|
||||
ii. Ability to represent high-memory buffers (which do not have a virtual
|
||||
address mapping in kernel address space).
|
||||
iii.Ability to represent large i/os w/o unecessarily breaking them up (i.e
|
||||
iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e
|
||||
greater than PAGE_SIZE chunks in one shot)
|
||||
iv. At the same time, ability to retain independent identity of i/os from
|
||||
different sources or i/o units requiring individual completion (e.g. for
|
||||
latency reasons)
|
||||
v. Ability to represent an i/o involving multiple physical memory segments
|
||||
(including non-page aligned page fragments, as specified via readv/writev)
|
||||
without unecessarily breaking it up, if the underlying device is capable of
|
||||
without unnecessarily breaking it up, if the underlying device is capable of
|
||||
handling it.
|
||||
vi. Preferably should be based on a memory descriptor structure that can be
|
||||
passed around different types of subsystems or layers, maybe even
|
||||
|
|
@ -1013,7 +1013,7 @@ Characteristics:
|
|||
i. Binary tree
|
||||
AS and deadline i/o schedulers use red black binary trees for disk position
|
||||
sorting and searching, and a fifo linked list for time-based searching. This
|
||||
gives good scalability and good availablility of information. Requests are
|
||||
gives good scalability and good availability of information. Requests are
|
||||
almost always dispatched in disk sort order, so a cache is kept of the next
|
||||
request in sort order to prevent binary tree lookups.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms.
|
||||
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
|
||||
|
||||
This works better than on other plattforms, because the FSB of the CPU
|
||||
This works better than on other platforms, because the FSB of the CPU
|
||||
can be controlled independently from the PCI/AGP clock.
|
||||
|
||||
The module has two options:
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
|
|||
maxcpus=2 will only boot 2. You can choose to bring the
|
||||
other cpus later online, read FAQ's for more info.
|
||||
|
||||
additional_cpus*=n Use this to limit hotpluggable cpus. This option sets
|
||||
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
|
||||
cpu_possible_map = cpu_present_map + additional_cpus
|
||||
|
||||
(*) Option valid only for following architectures
|
||||
|
|
@ -55,7 +55,7 @@ additional_cpus*=n Use this to limit hotpluggable cpus. This option sets
|
|||
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
|
||||
to determine the number of potentially hot-pluggable cpus. The implementation
|
||||
should only rely on this to count the # of cpus, but *MUST* not rely on the
|
||||
apicid values in those tables for disabled apics. In the event BIOS doesnt
|
||||
apicid values in those tables for disabled apics. In the event BIOS doesn't
|
||||
mark such hot-pluggable cpus as disabled entries, one could use this
|
||||
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ will work as long as stop_machine_run() is used to take a cpu down.
|
|||
|
||||
CPU Hotplug - Frequently Asked Questions.
|
||||
|
||||
Q: How to i enable my kernel to support CPU hotplug?
|
||||
Q: How to enable my kernel to support CPU hotplug?
|
||||
A: When doing make defconfig, Enable CPU hotplug support
|
||||
|
||||
"Processor type and Features" -> Support for Hotpluggable CPUs
|
||||
|
|
@ -145,12 +145,12 @@ an entry as shown below in the output.
|
|||
none on /sys type sysfs (rw)
|
||||
....
|
||||
|
||||
if this is not mounted, do the following.
|
||||
If this is not mounted, do the following.
|
||||
|
||||
#mkdir /sysfs
|
||||
#mount -t sysfs sys /sys
|
||||
|
||||
now you should see entries for all present cpu, the following is an example
|
||||
Now you should see entries for all present cpu, the following is an example
|
||||
in a 8-way system.
|
||||
|
||||
#pwd
|
||||
|
|
@ -173,7 +173,7 @@ file to logically online/offline a processor.
|
|||
|
||||
Q: Does hot-add/hot-remove refer to physical add/remove of cpus?
|
||||
A: The usage of hot-add/remove may not be very consistently used in the code.
|
||||
CONFIG_CPU_HOTPLUG enables logical online/offline capability in the kernel.
|
||||
CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel.
|
||||
To support physical addition/removal, one would need some BIOS hooks and
|
||||
the platform should have something like an attention button in PCI hotplug.
|
||||
CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.
|
||||
|
|
@ -183,11 +183,11 @@ A: Do the following.
|
|||
|
||||
#echo 0 > /sys/devices/system/cpu/cpuX/online
|
||||
|
||||
once the logical offline is successful, check
|
||||
Once the logical offline is successful, check
|
||||
|
||||
#cat /proc/interrupts
|
||||
|
||||
you should now not see the CPU that you removed. Also online file will report
|
||||
You should now not see the CPU that you removed. Also online file will report
|
||||
the state as 0 when a cpu if offline and 1 when its online.
|
||||
|
||||
#To display the current cpu state.
|
||||
|
|
@ -281,7 +281,7 @@ A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
|
|||
|
||||
for_each_online_cpu(i) {
|
||||
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
|
||||
foobar_cpu_callback(&foobar-cpu_notifier, CPU_ONLINE, i);
|
||||
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
|
||||
}
|
||||
|
||||
Q: If i would like to develop cpu hotplug support for a new architecture,
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ Your cooperation is appreciated.
|
|||
7 = /dev/full Returns ENOSPC on write
|
||||
8 = /dev/random Nondeterministic random number gen.
|
||||
9 = /dev/urandom Faster, less secure random number gen.
|
||||
10 = /dev/aio Asyncronous I/O notification interface
|
||||
10 = /dev/aio Asynchronous I/O notification interface
|
||||
11 = /dev/kmsg Writes to this come out as printk's
|
||||
1 block RAM disk
|
||||
0 = /dev/ram0 First RAM disk
|
||||
|
|
@ -1093,7 +1093,7 @@ Your cooperation is appreciated.
|
|||
|
||||
55 char DSP56001 digital signal processor
|
||||
0 = /dev/dsp56k First DSP56001
|
||||
55 block Mylex DAC960 PCI RAID controller; eigth controller
|
||||
55 block Mylex DAC960 PCI RAID controller; eighth controller
|
||||
0 = /dev/rd/c7d0 First disk, whole disk
|
||||
8 = /dev/rd/c7d1 Second disk, whole disk
|
||||
...
|
||||
|
|
@ -1456,7 +1456,7 @@ Your cooperation is appreciated.
|
|||
1 = /dev/cum1 Callout device for ttyM1
|
||||
...
|
||||
|
||||
79 block Compaq Intelligent Drive Array, eigth controller
|
||||
79 block Compaq Intelligent Drive Array, eighth controller
|
||||
0 = /dev/ida/c7d0 First logical drive whole disk
|
||||
16 = /dev/ida/c7d1 Second logical drive whole disk
|
||||
...
|
||||
|
|
@ -1900,7 +1900,7 @@ Your cooperation is appreciated.
|
|||
1 = /dev/av1 Second A/V card
|
||||
...
|
||||
|
||||
111 block Compaq Next Generation Drive Array, eigth controller
|
||||
111 block Compaq Next Generation Drive Array, eighth controller
|
||||
0 = /dev/cciss/c7d0 First logical drive, whole disk
|
||||
16 = /dev/cciss/c7d1 Second logical drive, whole disk
|
||||
...
|
||||
|
|
|
|||
|
|
@ -1,99 +1,131 @@
|
|||
Platform Devices and Drivers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
See <linux/platform_device.h> for the driver model interface to the
|
||||
platform bus: platform_device, and platform_driver. This pseudo-bus
|
||||
is used to connect devices on busses with minimal infrastructure,
|
||||
like those used to integrate peripherals on many system-on-chip
|
||||
processors, or some "legacy" PC interconnects; as opposed to large
|
||||
formally specified ones like PCI or USB.
|
||||
|
||||
|
||||
Platform devices
|
||||
~~~~~~~~~~~~~~~~
|
||||
Platform devices are devices that typically appear as autonomous
|
||||
entities in the system. This includes legacy port-based devices and
|
||||
host bridges to peripheral buses.
|
||||
host bridges to peripheral buses, and most controllers integrated
|
||||
into system-on-chip platforms. What they usually have in common
|
||||
is direct addressing from a CPU bus. Rarely, a platform_device will
|
||||
be connected through a segment of some other kind of bus; but its
|
||||
registers will still be directly addressible.
|
||||
|
||||
Platform devices are given a name, used in driver binding, and a
|
||||
list of resources such as addresses and IRQs.
|
||||
|
||||
struct platform_device {
|
||||
const char *name;
|
||||
u32 id;
|
||||
struct device dev;
|
||||
u32 num_resources;
|
||||
struct resource *resource;
|
||||
};
|
||||
|
||||
|
||||
Platform drivers
|
||||
~~~~~~~~~~~~~~~~
|
||||
Drivers for platform devices are typically very simple and
|
||||
unstructured. Either the device was present at a particular I/O port
|
||||
and the driver was loaded, or it was not. There was no possibility
|
||||
of hotplugging or alternative discovery besides probing at a specific
|
||||
I/O address and expecting a specific response.
|
||||
Platform drivers follow the standard driver model convention, where
|
||||
discovery/enumeration is handled outside the drivers, and drivers
|
||||
provide probe() and remove() methods. They support power management
|
||||
and shutdown notifications using the standard conventions.
|
||||
|
||||
struct platform_driver {
|
||||
int (*probe)(struct platform_device *);
|
||||
int (*remove)(struct platform_device *);
|
||||
void (*shutdown)(struct platform_device *);
|
||||
int (*suspend)(struct platform_device *, pm_message_t state);
|
||||
int (*suspend_late)(struct platform_device *, pm_message_t state);
|
||||
int (*resume_early)(struct platform_device *);
|
||||
int (*resume)(struct platform_device *);
|
||||
struct device_driver driver;
|
||||
};
|
||||
|
||||
Note that probe() should general verify that the specified device hardware
|
||||
actually exists; sometimes platform setup code can't be sure. The probing
|
||||
can use device resources, including clocks, and device platform_data.
|
||||
|
||||
Platform drivers register themselves the normal way:
|
||||
|
||||
int platform_driver_register(struct platform_driver *drv);
|
||||
|
||||
Or, in common situations where the device is known not to be hot-pluggable,
|
||||
the probe() routine can live in an init section to reduce the driver's
|
||||
runtime memory footprint:
|
||||
|
||||
int platform_driver_probe(struct platform_driver *drv,
|
||||
int (*probe)(struct platform_device *))
|
||||
|
||||
|
||||
Other Architectures, Modern Firmware, and new Platforms
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
These devices are not always at the legacy I/O ports. This is true on
|
||||
other architectures and on some modern architectures. In most cases,
|
||||
the drivers are modified to discover the devices at other well-known
|
||||
ports for the given platform. However, the firmware in these systems
|
||||
does usually know where exactly these devices reside, and in some
|
||||
cases, it's the only way of discovering them.
|
||||
Device Enumeration
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
As a rule, platform specific (and often board-specific) setup code wil
|
||||
register platform devices:
|
||||
|
||||
int platform_device_register(struct platform_device *pdev);
|
||||
|
||||
int platform_add_devices(struct platform_device **pdevs, int ndev);
|
||||
|
||||
The general rule is to register only those devices that actually exist,
|
||||
but in some cases extra devices might be registered. For example, a kernel
|
||||
might be configured to work with an external network adapter that might not
|
||||
be populated on all boards, or likewise to work with an integrated controller
|
||||
that some boards might not hook up to any peripherals.
|
||||
|
||||
In some cases, boot firmware will export tables describing the devices
|
||||
that are populated on a given board. Without such tables, often the
|
||||
only way for system setup code to set up the correct devices is to build
|
||||
a kernel for a specific target board. Such board-specific kernels are
|
||||
common with embedded and custom systems development.
|
||||
|
||||
In many cases, the memory and IRQ resources associated with the platform
|
||||
device are not enough to let the device's driver work. Board setup code
|
||||
will often provide additional information using the device's platform_data
|
||||
field to hold additional information.
|
||||
|
||||
Embedded systems frequently need one or more clocks for platform devices,
|
||||
which are normally kept off until they're actively needed (to save power).
|
||||
System setup also associates those clocks with the device, so that that
|
||||
calls to clk_get(&pdev->dev, clock_name) return them as needed.
|
||||
|
||||
|
||||
The Platform Bus
|
||||
~~~~~~~~~~~~~~~~
|
||||
A platform bus has been created to deal with these issues. First and
|
||||
foremost, it groups all the legacy devices under a common bus, and
|
||||
gives them a common parent if they don't already have one.
|
||||
Device Naming and Driver Binding
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The platform_device.dev.bus_id is the canonical name for the devices.
|
||||
It's built from two components:
|
||||
|
||||
But, besides the organizational benefits, the platform bus can also
|
||||
accommodate firmware-based enumeration.
|
||||
* platform_device.name ... which is also used to for driver matching.
|
||||
|
||||
* platform_device.id ... the device instance number, or else "-1"
|
||||
to indicate there's only one.
|
||||
|
||||
Device Discovery
|
||||
~~~~~~~~~~~~~~~~
|
||||
The platform bus has no concept of probing for devices. Devices
|
||||
discovery is left up to either the legacy drivers or the
|
||||
firmware. These entities are expected to notify the platform of
|
||||
devices that it discovers via the bus's add() callback:
|
||||
These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and
|
||||
"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
|
||||
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
|
||||
and use the platform_driver called "my_rtc".
|
||||
|
||||
platform_bus.add(parent,bus_id).
|
||||
Driver binding is performed automatically by the driver core, invoking
|
||||
driver probe() after finding a match between device and driver. If the
|
||||
probe() succeeds, the driver and device are bound as usual. There are
|
||||
three different ways to find such a match:
|
||||
|
||||
- Whenever a device is registered, the drivers for that bus are
|
||||
checked for matches. Platform devices should be registered very
|
||||
early during system boot.
|
||||
|
||||
Bus IDs
|
||||
~~~~~~~
|
||||
Bus IDs are the canonical names for the devices. There is no globally
|
||||
standard addressing mechanism for legacy devices. In the IA-32 world,
|
||||
we have Pnp IDs to use, as well as the legacy I/O ports. However,
|
||||
neither tell what the device really is or have any meaning on other
|
||||
platforms.
|
||||
- When a driver is registered using platform_driver_register(), all
|
||||
unbound devices on that bus are checked for matches. Drivers
|
||||
usually register later during booting, or by module loading.
|
||||
|
||||
Since both PnP IDs and the legacy I/O ports (and other standard I/O
|
||||
ports for specific devices) have a 1:1 mapping, we map the
|
||||
platform-specific name or identifier to a generic name (at least
|
||||
within the scope of the kernel).
|
||||
|
||||
For example, a serial driver might find a device at I/O 0x3f8. The
|
||||
ACPI firmware might also discover a device with PnP ID (_HID)
|
||||
PNP0501. Both correspond to the same device and should be mapped to the
|
||||
canonical name 'serial'.
|
||||
|
||||
The bus_id field should be a concatenation of the canonical name and
|
||||
the instance of that type of device. For example, the device at I/O
|
||||
port 0x3f8 should have a bus_id of "serial0". This places the
|
||||
responsibility of enumerating devices of a particular type up to the
|
||||
discovery mechanism. But, they are the entity that should know best
|
||||
(as opposed to the platform bus driver).
|
||||
|
||||
|
||||
Drivers
|
||||
~~~~~~~
|
||||
Drivers for platform devices should have a name that is the same as
|
||||
the canonical name of the devices they support. This allows the
|
||||
platform bus driver to do simple matching with the basic data
|
||||
structures to determine if a driver supports a certain device.
|
||||
|
||||
For example, a legacy serial driver should have a name of 'serial' and
|
||||
register itself with the platform bus.
|
||||
|
||||
|
||||
Driver Binding
|
||||
~~~~~~~~~~~~~~
|
||||
Legacy drivers assume they are bound to the device once they start up
|
||||
and probe an I/O port. Divorcing them from this will be a difficult
|
||||
process. However, that shouldn't prevent us from implementing
|
||||
firmware-based enumeration.
|
||||
|
||||
The firmware should notify the platform bus about devices before the
|
||||
legacy drivers have had a chance to load. Once the drivers are loaded,
|
||||
they driver model core will attempt to bind the driver to any
|
||||
previously-discovered devices. Once that has happened, it will be free
|
||||
to discover any other devices it pleases.
|
||||
- Registering a driver using platform_driver_probe() works just like
|
||||
using platform_driver_register(), except that the the driver won't
|
||||
be probed later if another device registers. (Which is OK, since
|
||||
this interface is only for use with non-hotpluggable devices.)
|
||||
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
|
|||
describing the relationship the device has to other entities.
|
||||
|
||||
|
||||
- Embedd a struct device in the bus-specific device type.
|
||||
- Embed a struct device in the bus-specific device type.
|
||||
|
||||
|
||||
struct pci_dev {
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ eliminating the need for any additional ioctls.
|
|||
The disadvantage is that the driver/hardware has to manage the rest. For
|
||||
the application programmer it would be as simple as sending/receiving an
|
||||
array to/from the CI ioctls as defined in the Linux DVB API. No changes
|
||||
have been made in the API to accomodate this feature.
|
||||
have been made in the API to accommodate this feature.
|
||||
|
||||
|
||||
* Why the need for another CI interface ?
|
||||
|
|
@ -102,7 +102,7 @@ This CI interface follows the CI high level interface, which is not
|
|||
implemented by most applications. Hence this area is revisited.
|
||||
|
||||
This CI interface is quite different in the case that it tries to
|
||||
accomodate all other CI based devices, that fall into the other categories
|
||||
accommodate all other CI based devices, that fall into the other categories.
|
||||
|
||||
This means that this CI interface handles the EN50221 style tags in the
|
||||
Application layer only and no session management is taken care of by the
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ res : root device I/O resource
|
|||
bus_base_addr : slot 0 address on this bus
|
||||
slots : max slot number to probe
|
||||
force_probe : Probe even when slot 0 is empty (no EISA mainboard)
|
||||
dma_mask : Default DMA mask. Usualy the bridge device dma_mask.
|
||||
dma_mask : Default DMA mask. Usually the bridge device dma_mask.
|
||||
bus_nr : unique bus id, set by eisa_root_register
|
||||
|
||||
** Driver :
|
||||
|
|
|
|||
|
|
@ -53,18 +53,6 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: sys_sysctl
|
||||
When: January 2007
|
||||
Why: The same information is available through /proc/sys and that is the
|
||||
interface user space prefers to use. And there do not appear to be
|
||||
any existing user in user space of sys_sysctl. The additional
|
||||
maintenance overhead of keeping a set of binary names gets
|
||||
in the way of doing a good job of maintaining this interface.
|
||||
|
||||
Who: Eric Biederman <ebiederm@xmission.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||
When: November 2005
|
||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
||||
|
|
@ -82,18 +70,6 @@ Who: Dominik Brodowski <linux@brodo.de>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
|
||||
When: December 2005
|
||||
Why: This interface has been obsoleted by the new layer3-independent
|
||||
"nfnetlink_queue". The Kernel interface is compatible, so the old
|
||||
ip[6]tables "QUEUE" targets still work and will transparently handle
|
||||
all packets into nfnetlink queue number 0. Userspace users will have
|
||||
to link against API-compatible library on top of libnfnetlink_queue
|
||||
instead of the current 'libipq'.
|
||||
Who: Harald Welte <laforge@netfilter.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||
When: August 2006
|
||||
Files: arch/*/kernel/*_ksyms.c
|
||||
|
|
@ -239,23 +215,8 @@ Who: Patrick McHardy <kaber@trash.net>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: frame diverter
|
||||
When: November 2006
|
||||
Why: The frame diverter is included in most distribution kernels, but is
|
||||
broken. It does not correctly handle many things:
|
||||
- IPV6
|
||||
- non-linear skb's
|
||||
- network device RCU on removal
|
||||
- input frames not correctly checked for protocol errors
|
||||
It also adds allocation overhead even if not enabled.
|
||||
It is not clear if anyone is still using it.
|
||||
Who: Stephen Hemminger <shemminger@osdl.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
|
||||
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
|
||||
When: Oktober 2008
|
||||
When: October 2008
|
||||
Why: The stacking of class devices makes these values misleading and
|
||||
inconsistent.
|
||||
Class devices should not carry any of these properties, and bus
|
||||
|
|
@ -280,3 +241,12 @@ Why: Orphaned for ages. SMP bugs long unfixed. Few users left
|
|||
Who: Jeff Garzik <jeff@garzik.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: IPv4 only connection tracking/NAT/helpers
|
||||
When: 2.6.22
|
||||
Why: The new layer 3 independant connection tracking replaces the old
|
||||
IPv4 only version. After some stabilization of the new code the
|
||||
old one will be removed.
|
||||
Who: Patrick McHardy <kaber@trash.net>
|
||||
|
||||
---------------------------
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ will happen for write(2).
|
|||
|
||||
[struct config_group]
|
||||
|
||||
A config_item cannot live in a vaccum. The only way one can be created
|
||||
A config_item cannot live in a vacuum. The only way one can be created
|
||||
is via mkdir(2) on a config_group. This will trigger creation of a
|
||||
child item.
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ directory is not empty.
|
|||
|
||||
[struct configfs_subsystem]
|
||||
|
||||
A subsystem must register itself, ususally at module_init time. This
|
||||
A subsystem must register itself, usually at module_init time. This
|
||||
tells configfs to make the subsystem appear in the file tree.
|
||||
|
||||
struct configfs_subsystem {
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ For each connection the following files exist within this directory:
|
|||
|
||||
'waiting'
|
||||
|
||||
The number of requests which are waiting to be transfered to
|
||||
The number of requests which are waiting to be transferred to
|
||||
userspace or being processed by the filesystem daemon. If there is
|
||||
no filesystem activity and 'waiting' is non-zero, then the
|
||||
filesystem is hung or deadlocked.
|
||||
|
|
@ -136,7 +136,7 @@ following will happen:
|
|||
|
||||
2) If the request is not yet sent to userspace AND the signal is not
|
||||
fatal, then an 'interrupted' flag is set for the request. When
|
||||
the request has been successfully transfered to userspace and
|
||||
the request has been successfully transferred to userspace and
|
||||
this flag is set, an INTERRUPT request is queued.
|
||||
|
||||
3) If the request is already sent to userspace, then an INTERRUPT
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ History
|
|||
Fixed race-condition in buffer code - it is in all filesystems in Linux;
|
||||
when reading device (cat /dev/hda) while creating files on it, files
|
||||
could be damaged
|
||||
2.02 Woraround for bug in breada in Linux. breada could cause accesses beyond
|
||||
2.02 Workaround for bug in breada in Linux. breada could cause accesses beyond
|
||||
end of partition
|
||||
2.03 Char, block devices and pipes are correctly created
|
||||
Fixed non-crashing race in unlink (Alexander Viro)
|
||||
|
|
|
|||
|
|
@ -337,7 +337,7 @@ Finally, for a mirrored volume, i.e. raid level 1, the table would look like
|
|||
this (note all values are in 512-byte sectors):
|
||||
|
||||
--- cut here ---
|
||||
# Ofs Size Raid Log Number Region Should Number Source Start Taget Start
|
||||
# Ofs Size Raid Log Number Region Should Number Source Start Target Start
|
||||
# in of the type type of log size sync? of Device in Device in
|
||||
# vol volume params mirrors Device Device
|
||||
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
|
||||
|
|
@ -599,7 +599,7 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
|||
- Major bug fixes for reading files and volumes in corner cases which
|
||||
were being hit by Windows 2k/XP users.
|
||||
2.1.2:
|
||||
- Major bug fixes aleviating the hangs in statfs experienced by some
|
||||
- Major bug fixes alleviating the hangs in statfs experienced by some
|
||||
users.
|
||||
2.1.1:
|
||||
- Update handling of compressed files so people no longer get the
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Caveats
|
|||
Features which OCFS2 does not support yet:
|
||||
- sparse files
|
||||
- extended attributes
|
||||
- shared writeable mmap
|
||||
- shared writable mmap
|
||||
- loopback is supported, but data written will not
|
||||
be cluster coherent.
|
||||
- quotas
|
||||
|
|
|
|||
|
|
@ -1220,9 +1220,9 @@ applications are using mlock(), or if you are running with no swap then
|
|||
you probably should increase the lower_zone_protection setting.
|
||||
|
||||
The units of this tunable are fairly vague. It is approximately equal
|
||||
to "megabytes". So setting lower_zone_protection=100 will protect around 100
|
||||
to "megabytes," so setting lower_zone_protection=100 will protect around 100
|
||||
megabytes of the lowmem zone from user allocations. It will also make
|
||||
those 100 megabytes unavaliable for use by applications and by
|
||||
those 100 megabytes unavailable for use by applications and by
|
||||
pagecache, so there is a cost.
|
||||
|
||||
The effects of this tunable may be observed by monitoring
|
||||
|
|
@ -1538,10 +1538,10 @@ TCP settings
|
|||
tcp_ecn
|
||||
-------
|
||||
|
||||
This file controls the use of the ECN bit in the IPv4 headers, this is a new
|
||||
This file controls the use of the ECN bit in the IPv4 headers. This is a new
|
||||
feature about Explicit Congestion Notification, but some routers and firewalls
|
||||
block trafic that has this bit set, so it could be necessary to echo 0 to
|
||||
/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info
|
||||
block traffic that has this bit set, so it could be necessary to echo 0 to
|
||||
/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
|
||||
you could read RFC2481.
|
||||
|
||||
tcp_retrans_collapse
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ FILES
|
|||
/signal2
|
||||
The two signal notification channels of an SPU. These are read-write
|
||||
files that operate on a 32 bit word. Writing to one of these files
|
||||
triggers an interrupt on the SPU. The value writting to the signal
|
||||
triggers an interrupt on the SPU. The value written to the signal
|
||||
files can be read from the SPU through a channel read or from host user
|
||||
space through the file. After the value has been read by the SPU, it
|
||||
is reset to zero. The possible operations on an open signal1 or sig-
|
||||
|
|
|
|||
|
|
@ -7,8 +7,17 @@ If you encounter problems with reading UDF discs using this driver,
|
|||
please report them to linux_udf@hpesjro.fc.hp.com, which is the
|
||||
developer's list.
|
||||
|
||||
Write support requires a block driver which supports writing. The current
|
||||
scsi and ide cdrom drivers do not support writing.
|
||||
Write support requires a block driver which supports writing. Currently
|
||||
dvd+rw drives and media support true random sector writes, and so a udf
|
||||
filesystem on such devices can be directly mounted read/write. CD-RW
|
||||
media however, does not support this. Instead the media can be formatted
|
||||
for packet mode using the utility cdrwtool, then the pktcdvd driver can
|
||||
be bound to the underlying cd device to provide the required buffering
|
||||
and read-modify-write cycles to allow the filesystem random sector writes
|
||||
while providing the hardware with only full packet writes. While not
|
||||
required for dvd+rw media, use of the pktcdvd driver often enhances
|
||||
performance due to very poor read-modify-write support supplied internally
|
||||
by drive firmware.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
The following mount options are supported:
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ the following things on the "Kernel Hacking" tab:
|
|||
Then build as usual, download to the board and execute. Note that if
|
||||
"Immediate activation" was selected, then the kernel will wait for GDB to
|
||||
attach. If not, then the kernel will boot immediately and GDB will have to
|
||||
interupt it or wait for an exception to occur if before doing anything with
|
||||
interrupt it or wait for an exception to occur before doing anything with
|
||||
the kernel.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ with the main kernel in this regard. Hence the debug mode code (gdbstub) is
|
|||
almost completely self-contained. The only external code used is the
|
||||
sprintf family of functions.
|
||||
|
||||
Futhermore, break.S is so complicated because single-step mode does not
|
||||
Furthermore, break.S is so complicated because single-step mode does not
|
||||
switch off on entry to an exception. That means unless manually disabled,
|
||||
single-stepping will blithely go on stepping into things like interrupts.
|
||||
See gdbstub.txt for more information.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Authors:
|
|||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Michiel Rook <michiel@grendelproject.nl>,
|
||||
Grant Coady <gcoady@gmail.com> with guidance
|
||||
Grant Coady <gcoady.lk@gmail.com> with guidance
|
||||
from Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
Interface
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Thanks to Kris Chen from Fintek for answering technical questions and
|
|||
providing additional documentation.
|
||||
|
||||
Thanks to Chris Lin from Jetway for providing wiring schematics and
|
||||
anwsering technical questions.
|
||||
answering technical questions.
|
||||
|
||||
|
||||
Description
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Kernel driver k8temp
|
|||
====================
|
||||
|
||||
Supported chips:
|
||||
* AMD K8 CPU
|
||||
* AMD Athlon64/FX or Opteron CPUs
|
||||
Prefix: 'k8temp'
|
||||
Addresses scanned: PCI space
|
||||
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
|
||||
|
|
@ -13,10 +13,13 @@ Contact: Rudolf Marek <r.marek@sh.cvut.cz>
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
|
||||
Official documentation says that it works from revision F of K8 core, but
|
||||
in fact it seems to be implemented for all revisions of K8 except the first
|
||||
two revisions (SH-B0 and SH-B3).
|
||||
This driver permits reading temperature sensor(s) embedded inside AMD K8
|
||||
family CPUs (Athlon64/FX, Opteron). Official documentation says that it works
|
||||
from revision F of K8 core, but in fact it seems to be implemented for all
|
||||
revisions of K8 except the first two revisions (SH-B0 and SH-B3).
|
||||
|
||||
Please note that you will need at least lm-sensors 2.10.1 for proper userspace
|
||||
support.
|
||||
|
||||
There can be up to four temperature sensors inside single CPU. The driver
|
||||
will auto-detect the sensors and will display only temperatures from
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@ Kernel driver smsc47m1
|
|||
======================
|
||||
|
||||
Supported chips:
|
||||
* SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192
|
||||
* SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x,
|
||||
LPC47M15x and LPC47M192
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Prefix: 'smsc47m1'
|
||||
Datasheets:
|
||||
http://www.smsc.com/main/datasheets/47b27x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m10x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m112.pdf
|
||||
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m14x.pdf
|
||||
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ fan control mode).
|
|||
Temperatures are measured in degrees Celsius and measurement resolution is 1
|
||||
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
|
||||
the temperature gets higher than high limit; it stays on until the temperature
|
||||
falls below the Hysteresis value.
|
||||
falls below the hysteresis value.
|
||||
|
||||
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
|
||||
triggered if the rotation speed has dropped below a programmable limit. Fan
|
||||
|
|
@ -67,9 +67,9 @@ Thermal Cruise mode
|
|||
|
||||
If the temperature is in the range defined by:
|
||||
|
||||
pwm[1-4]_target - set target temperature, unit millidegree Celcius
|
||||
pwm[1-4]_target - set target temperature, unit millidegree Celsius
|
||||
(range 0 - 127000)
|
||||
pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000)
|
||||
pwm[1-4]_tolerance - tolerance, unit millidegree Celsius (range 0 - 15000)
|
||||
|
||||
there are no changes to fan speed. Once the temperature leaves the interval,
|
||||
fan speed increases (temp is higher) or decreases if lower than desired.
|
||||
|
|
|
|||
|
|
@ -390,5 +390,5 @@ mlord@pobox.com
|
|||
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
|
||||
maintainer.
|
||||
|
||||
Wed Aug 20 22:31:29 CEST 2003 updated ide boot uptions to current ide.c
|
||||
Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c
|
||||
comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv>
|
||||
|
|
|
|||
|
|
@ -91,8 +91,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
|
|||
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
|
||||
| 2 | M0V | JOY0DAT Vertical Clock |
|
||||
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
||||
| 4 | M1V | JOY1DAT Horizontall Clock |
|
||||
| 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) |
|
||||
| 4 | M1V | JOY1DAT Horizontal Clock |
|
||||
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
|
||||
| 6 | M1V | JOY1DAT Vertical Clock |
|
||||
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
||||
+--------+----------+-----------------------------------------+
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
|
|||
|
||||
5.1 Joystick Event Reporting
|
||||
|
||||
In this mode, the ikbd generates a record whever the joystick position is
|
||||
In this mode, the ikbd generates a record whenever the joystick position is
|
||||
changed (i.e. for each opening or closing of a joystick switch or trigger).
|
||||
|
||||
The joystick event record is two bytes of the form:
|
||||
|
|
@ -277,8 +277,8 @@ default to 1 at RESET (or power-up).
|
|||
9.7 SET MOUSE SCALE
|
||||
|
||||
0x0C
|
||||
X ; horizontal mouse ticks per internel X
|
||||
Y ; vertical mouse ticks per internel Y
|
||||
X ; horizontal mouse ticks per internal X
|
||||
Y ; vertical mouse ticks per internal Y
|
||||
|
||||
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
||||
In this mode, the specified number of mouse phase changes ('clicks') must
|
||||
|
|
@ -323,7 +323,7 @@ mouse position.
|
|||
0x0F
|
||||
|
||||
This command makes the origin of the Y axis to be at the bottom of the
|
||||
logical coordinate system internel to the ikbd for all relative or absolute
|
||||
logical coordinate system internal to the ikbd for all relative or absolute
|
||||
mouse motion. This causes mouse motion toward the user to be negative in sign
|
||||
and away from the user to be positive.
|
||||
|
||||
|
|
@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
|
|||
|
||||
10. SCAN CODES
|
||||
|
||||
The key scan codes return by the ikbd are chosen to simplify the
|
||||
implementaion of GSX.
|
||||
The key scan codes returned by the ikbd are chosen to simplify the
|
||||
implementation of GSX.
|
||||
|
||||
GSX Standard Keyboard Mapping.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,20 +3,37 @@ xpad - Linux USB driver for X-Box gamepads
|
|||
This is the very first release of a driver for X-Box gamepads.
|
||||
Basically, this was hacked away in just a few hours, so don't expect
|
||||
miracles.
|
||||
|
||||
In particular, there is currently NO support for the rumble pack.
|
||||
You won't find many ff-aware linux applications anyway.
|
||||
|
||||
|
||||
0. Status
|
||||
---------
|
||||
0. Notes
|
||||
--------
|
||||
|
||||
For now, this driver has only been tested on just one Linux-Box.
|
||||
This one is running a 2.4.18 kernel with usb-uhci on an amd athlon 600.
|
||||
Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.)
|
||||
|
||||
The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) reports
|
||||
8 axes and 10 buttons.
|
||||
The number of buttons/axes reported varies based on 3 things:
|
||||
- if you are using a known controller
|
||||
- if you are using a known dance pad
|
||||
- if using an unknown device (one not listed below), what you set in the
|
||||
module configuration for "Map D-PAD to buttons rather than axes for unknown
|
||||
pads" (module option dpad_to_buttons)
|
||||
|
||||
Alls 8 axes work, though they all have the same range (-32768..32767)
|
||||
If you set dpad_to_buttons to 0 and you are using an unknown device (one
|
||||
not listed below), the driver will map the directional pad to axes (X/Y),
|
||||
if you said N it will map the d-pad to buttons, which is needed for dance
|
||||
style games to function correctly. The default is Y.
|
||||
|
||||
dpad_to_buttons has no effect for known pads.
|
||||
|
||||
0.1 Normal Controllers
|
||||
----------------------
|
||||
With a normal controller, the directional pad is mapped to its own X/Y axes.
|
||||
The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) will report 8
|
||||
axes and 10 buttons.
|
||||
|
||||
All 8 axes work, though they all have the same range (-32768..32767)
|
||||
and the zero-setting is not correct for the triggers (I don't know if that
|
||||
is some limitation of jstest, since the input device setup should be fine. I
|
||||
didn't have a look at jstest itself yet).
|
||||
|
|
@ -30,16 +47,50 @@ in game functionality were OK. However, I find it rather difficult to
|
|||
play first person shooters with a pad. Your mileage may vary.
|
||||
|
||||
|
||||
0.2 Xbox Dance Pads
|
||||
-------------------
|
||||
When using a known dance pad, jstest will report 6 axes and 14 buttons.
|
||||
|
||||
For dance style pads (like the redoctane pad) several changes
|
||||
have been made. The old driver would map the d-pad to axes, resulting
|
||||
in the driver being unable to report when the user was pressing both
|
||||
left+right or up+down, making DDR style games unplayable.
|
||||
|
||||
Known dance pads automatically map the d-pad to buttons and will work
|
||||
correctly out of the box.
|
||||
|
||||
If your dance pad is recognized by the driver but is using axes instead
|
||||
of buttons, see section 0.3 - Unknown Controllers
|
||||
|
||||
I've tested this with Stepmania, and it works quite well.
|
||||
|
||||
|
||||
0.3 Unkown Controllers
|
||||
----------------------
|
||||
If you have an unkown xbox controller, it should work just fine with
|
||||
the default settings.
|
||||
|
||||
HOWEVER if you have an unknown dance pad not listed below, it will not
|
||||
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
|
||||
|
||||
PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
|
||||
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
|
||||
whether it is a dance pad or normal controller) so that we can add your pad
|
||||
to the list of supported devices, ensuring that it will work out of the
|
||||
box in the future.
|
||||
|
||||
|
||||
1. USB adapter
|
||||
--------------
|
||||
|
||||
Before you can actually use the driver, you need to get yourself an
|
||||
adapter cable to connect the X-Box controller to your Linux-Box.
|
||||
adapter cable to connect the X-Box controller to your Linux-Box. You
|
||||
can buy these online fairly cheap, or build your own.
|
||||
|
||||
Such a cable is pretty easy to build. The Controller itself is a USB compound
|
||||
device (a hub with three ports for two expansion slots and the controller
|
||||
device) with the only difference in a nonstandard connector (5 pins vs. 4 on
|
||||
standard USB connector).
|
||||
Such a cable is pretty easy to build. The Controller itself is a USB
|
||||
compound device (a hub with three ports for two expansion slots and
|
||||
the controller device) with the only difference in a nonstandard connector
|
||||
(5 pins vs. 4 on standard USB connector).
|
||||
|
||||
You just need to solder a USB connector onto the cable and keep the
|
||||
yellow wire unconnected. The other pins have the same order on both
|
||||
|
|
@ -51,36 +102,36 @@ original one. You can buy an extension cable and cut that instead. That way,
|
|||
you can still use the controller with your X-Box, if you have one ;)
|
||||
|
||||
|
||||
2. driver installation
|
||||
2. Driver Installation
|
||||
----------------------
|
||||
|
||||
Once you have the adapter cable and the controller is connected, you need
|
||||
to load your USB subsystem and should cat /proc/bus/usb/devices.
|
||||
There should be an entry like the one at the end [4].
|
||||
|
||||
Currently (as of version 0.0.4), the following three devices are included:
|
||||
Currently (as of version 0.0.6), the following devices are included:
|
||||
original Microsoft XBOX controller (US), vendor=0x045e, product=0x0202
|
||||
smaller Microsoft XBOX controller (US), vendor=0x045e, product=0x0289
|
||||
original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285
|
||||
InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a
|
||||
RedOctane Xbox Dance Pad (US), vendor=0x0c12, product=0x8809
|
||||
|
||||
If you have another controller that is not listed above and is not recognized
|
||||
by the driver, please drop me a line with the appropriate info (that is, include
|
||||
the name, vendor and product ID, as well as the country where you bought it;
|
||||
sending the whole dump out of /proc/bus/usb/devices along would be even better).
|
||||
The driver should work with xbox pads not listed above as well, however
|
||||
you will need to do something extra for dance pads to work.
|
||||
|
||||
In theory, the driver should work with other controllers than mine
|
||||
(InterAct PowerPad pro, bought in Germany) just fine, but I cannot test this
|
||||
for I only have this one controller.
|
||||
If you have a controller not listed above, see 0.3 - Unknown Controllers
|
||||
|
||||
If you compiled and installed the driver, test the functionality:
|
||||
> modprobe xpad
|
||||
> modprobe joydev
|
||||
> jstest /dev/js0
|
||||
|
||||
There should be a single line showing 18 inputs (8 axes, 10 buttons), and
|
||||
it's values should change if you move the sticks and push the buttons.
|
||||
If you're using a normal controller, there should be a single line showing
|
||||
18 inputs (8 axes, 10 buttons), and its values should change if you move
|
||||
the sticks and push the buttons. If you're using a dance pad, it should
|
||||
show 20 inputs (6 axes, 14 buttons).
|
||||
|
||||
It works? Voila, your done ;)
|
||||
It works? Voila, you're done ;)
|
||||
|
||||
|
||||
3. Thanks
|
||||
|
|
@ -111,6 +162,22 @@ I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
|
|||
E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl= 10ms
|
||||
E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl= 10ms
|
||||
|
||||
5. /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
|
||||
|
||||
T: Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0
|
||||
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
|
||||
P: Vendor=0c12 ProdID=8809 Rev= 0.01
|
||||
S: Product=XBOX DDR
|
||||
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
|
||||
I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
|
||||
E: Ad=82(I) Atr=03(Int.) MxPS= 32 Ivl=4ms
|
||||
E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl=4ms
|
||||
|
||||
--
|
||||
Marko Friedemann <mfr@bmx-chemnitz.de>
|
||||
2002-07-16
|
||||
- original doc
|
||||
|
||||
Dominic Cerquetti <binary1230@yahoo.com>
|
||||
2005-03-19
|
||||
- added stuff for dance pads, new d-pad->axes mappings
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
|
|||
888888888888
|
||||
Linux Rocks!
|
||||
|
||||
Writing to /sys/../lineX will set the coresponding LCD line.
|
||||
Writing to /sys/../lineX will set the corresponding LCD line.
|
||||
- Excess characters are ignored.
|
||||
- If less characters are written than allowed, the remaining digits are
|
||||
unchanged.
|
||||
|
|
|
|||
|
|
@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc.
|
|||
Ok, this is where problems start. The current interface for
|
||||
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
||||
assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
|
||||
Unfortunatly, while this is often the case, it is also
|
||||
Unfortunately, while this is often the case, it is also
|
||||
very common for CDs to have some tracks with data, and some
|
||||
tracks with audio. Just because I feel like it, I declare
|
||||
the following to be the best way to cope. If the CD has
|
||||
|
|
|
|||
|
|
@ -227,9 +227,9 @@ more details, with real examples.
|
|||
be included in a library, lib.a.
|
||||
All objects listed with lib-y are combined in a single
|
||||
library for that directory.
|
||||
Objects that are listed in obj-y and additionaly listed in
|
||||
lib-y will not be included in the library, since they will anyway
|
||||
be accessible.
|
||||
Objects that are listed in obj-y and additionally listed in
|
||||
lib-y will not be included in the library, since they will
|
||||
be accessible anyway.
|
||||
For consistency, objects listed in lib-m will be included in lib.a.
|
||||
|
||||
Note that the same kbuild makefile may list files to be built-in
|
||||
|
|
@ -535,7 +535,7 @@ Both possibilities are described in the following.
|
|||
Host programs can be made up based on composite objects.
|
||||
The syntax used to define composite objects for host programs is
|
||||
similar to the syntax used for kernel objects.
|
||||
$(<executeable>-objs) lists all objects used to link the final
|
||||
$(<executable>-objs) lists all objects used to link the final
|
||||
executable.
|
||||
|
||||
Example:
|
||||
|
|
@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
|
|||
In this example, there are two possible targets, requiring different
|
||||
options to the linker. The linker options are specified using the
|
||||
LDFLAGS_$@ syntax - one for each potential target.
|
||||
$(targets) are assinged all potential targets, by which kbuild knows
|
||||
$(targets) are assigned all potential targets, by which kbuild knows
|
||||
the targets and will:
|
||||
1) check for commandline changes
|
||||
2) delete target during make clean
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ are:
|
|||
special place-holders for where the extracted documentation should
|
||||
go.
|
||||
|
||||
- scripts/docproc.c
|
||||
- scripts/basic/docproc.c
|
||||
|
||||
This is a program for converting SGML template files into SGML
|
||||
files. When a file is referenced it is searched for symbols
|
||||
|
|
|
|||
|
|
@ -164,6 +164,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
acpi_skip_timer_override [HW,ACPI]
|
||||
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
||||
For broken nForce2 BIOS resulting in XT-PIC timer.
|
||||
acpi_use_timer_override [HW,ACPI}
|
||||
Use timer override. For some broken Nvidia NF5 boards
|
||||
that require a timer override, but don't have
|
||||
HPET
|
||||
|
||||
acpi_dbg_layer= [HW,ACPI]
|
||||
Format: <int>
|
||||
|
|
@ -1231,6 +1235,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
machine check when some devices' config space
|
||||
is read. But various workarounds are disabled
|
||||
and some IOMMU drivers will not work.
|
||||
bfsort Sort PCI devices into breadth-first order.
|
||||
This sorting is done to get a device
|
||||
order compatible with older (<= 2.4) kernels.
|
||||
nobfsort Don't sort PCI devices into breadth-first order.
|
||||
|
||||
pcmv= [HW,PCMCIA] BadgePAD 4
|
||||
|
||||
pd. [PARIDE]
|
||||
|
|
|
|||
|
|
@ -304,7 +304,7 @@ about the status of the key service:
|
|||
R Revoked
|
||||
D Dead
|
||||
Q Contributes to user's quota
|
||||
U Under contruction by callback to userspace
|
||||
U Under construction by callback to userspace
|
||||
N Negative key
|
||||
|
||||
This file must be enabled at kernel configuration time as it allows anyone
|
||||
|
|
|
|||
|
|
@ -442,9 +442,10 @@ static int __init kprobe_init(void)
|
|||
kp.fault_handler = handler_fault;
|
||||
kp.symbol_name = "do_fork";
|
||||
|
||||
if ((ret = register_kprobe(&kp) < 0)) {
|
||||
ret = register_kprobe(&kp);
|
||||
if (ret < 0) {
|
||||
printk("register_kprobe failed, returned %d\n", ret);
|
||||
return -1;
|
||||
return ret;
|
||||
}
|
||||
printk("kprobe registered\n");
|
||||
return 0;
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ contains the following options:
|
|||
MAX_AGE:
|
||||
|
||||
Maximum time, in seconds, of hard drive spindown time that you are
|
||||
confortable with. Worst case, it's possible that you could lose this
|
||||
comfortable with. Worst case, it's possible that you could lose this
|
||||
amount of work if your battery fails while you're in laptop mode.
|
||||
|
||||
MINIMUM_BATTERY_MINUTES:
|
||||
|
|
@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
|
|||
|
||||
--------------------CONFIG FILE BEGIN-------------------------------------------
|
||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
||||
# confortable with. Worst case, it's possible that you could lose this
|
||||
# comfortable with. Worst case, it's possible that you could lose this
|
||||
# amount of work if your battery fails you while in laptop mode.
|
||||
#MAX_AGE=600
|
||||
|
||||
|
|
@ -350,7 +350,7 @@ fi
|
|||
# set defaults instead:
|
||||
|
||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
||||
# confortable with. Worst case, it's possible that you could lose this
|
||||
# comfortable with. Worst case, it's possible that you could lose this
|
||||
# amount of work if your battery fails you while in laptop mode.
|
||||
MAX_AGE=${MAX_AGE:-'600'}
|
||||
|
||||
|
|
@ -699,7 +699,7 @@ ACPI integration
|
|||
Dax Kelson submitted this so that the ACPI acpid daemon will
|
||||
kick off the laptop_mode script and run hdparm. The part that
|
||||
automatically disables laptop mode when the battery is low was
|
||||
writen by Jan Topinski.
|
||||
written by Jan Topinski.
|
||||
|
||||
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
||||
event=ac_adapter
|
||||
|
|
|
|||
|
|
@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU:
|
|||
|
||||
STORE *X = c, d = LOAD *X
|
||||
|
||||
(Loads and stores overlap if they are targetted at overlapping pieces of
|
||||
(Loads and stores overlap if they are targeted at overlapping pieces of
|
||||
memory).
|
||||
|
||||
And there are a number of things that _must_ or _must_not_ be assumed:
|
||||
|
|
@ -1016,7 +1016,7 @@ There are some more advanced barrier functions:
|
|||
|
||||
(*) set_mb(var, value)
|
||||
|
||||
This assigns the value to the variable and then inserts at least a write
|
||||
This assigns the value to the variable and then inserts a full memory
|
||||
barrier after it, depending on the function. It isn't guaranteed to
|
||||
insert anything more than a compiler barrier in a UP compilation.
|
||||
|
||||
|
|
@ -1898,7 +1898,7 @@ queue before processing any further requests:
|
|||
smp_wmb();
|
||||
<A:modify v=2> <C:busy>
|
||||
<C:queue v=2>
|
||||
p = &b; q = p;
|
||||
p = &v; q = p;
|
||||
<D:request p>
|
||||
<B:modify p=&v> <D:commit p=&v>
|
||||
<D:read p>
|
||||
|
|
|
|||
|
|
@ -38,17 +38,12 @@ The new time code provide the following services:
|
|||
|
||||
a) Implements functions required by Linux common code:
|
||||
time_init
|
||||
do_gettimeofday
|
||||
do_settimeofday
|
||||
|
||||
b) provides an abstraction of RTC and null RTC implementation as default.
|
||||
extern unsigned long (*rtc_get_time)(void);
|
||||
extern int (*rtc_set_time)(unsigned long);
|
||||
|
||||
c) a set of gettimeoffset functions for different CPUs and different
|
||||
needs.
|
||||
|
||||
d) high-level and low-level timer interrupt routines where the timer
|
||||
c) high-level and low-level timer interrupt routines where the timer
|
||||
interrupt source may or may not be the CPU timer. The high-level
|
||||
routine is dispatched through do_IRQ() while the low-level is
|
||||
dispatched in assemably code (usually int-handler.S)
|
||||
|
|
@ -63,7 +58,7 @@ the following functions or values:
|
|||
a) board_time_init - a function pointer. Invoked at the beginnig of
|
||||
time_init(). It is optional.
|
||||
1. (optional) set up RTC routines
|
||||
2. (optional) calibrate and set the mips_counter_frequency
|
||||
2. (optional) calibrate and set the mips_hpt_frequency
|
||||
|
||||
b) plat_timer_setup - a function pointer. Invoked at the end of time_init()
|
||||
1. (optional) over-ride any decisions made in time_init()
|
||||
|
|
@ -72,9 +67,8 @@ the following functions or values:
|
|||
|
||||
c) (optional) board-specific RTC routines.
|
||||
|
||||
d) (optional) mips_counter_frequency - It must be definied if the board
|
||||
is using CPU counter for timer interrupt or it is using fixed rate
|
||||
gettimeoffset().
|
||||
d) (optional) mips_hpt_frequency - It must be definied if the board
|
||||
is using CPU counter for timer interrupt.
|
||||
|
||||
|
||||
PORTING GUIDE
|
||||
|
|
@ -89,22 +83,12 @@ Step 1: decide how you like to implement the time services.
|
|||
If the answer is no, you need a timer to provide the timer interrupt
|
||||
at 100 HZ speed.
|
||||
|
||||
You cannot use the fast gettimeoffset functions, i.e.,
|
||||
|
||||
unsigned long fixed_rate_gettimeoffset(void);
|
||||
unsigned long calibrate_div32_gettimeoffset(void);
|
||||
unsigned long calibrate_div64_gettimeoffset(void);
|
||||
|
||||
You can use null_gettimeoffset() will gives the same time resolution as
|
||||
jiffy. Or you can implement your own gettimeoffset (probably based on
|
||||
some ad hoc hardware on your machine.)
|
||||
|
||||
c) The following sub steps assume your CPU has counter register.
|
||||
Do you plan to use the CPU counter register as the timer interrupt
|
||||
or use an exnternal timer?
|
||||
|
||||
In order to use CPU counter register as the timer interrupt source, you
|
||||
must know the counter speed (mips_counter_frequency). It is usually the
|
||||
must know the counter speed (mips_hpt_frequency). It is usually the
|
||||
same as the CPU speed or an integral divisor of it.
|
||||
|
||||
d) decide on whether you want to use high-level or low-level timer
|
||||
|
|
@ -122,9 +106,9 @@ Step 3: implement rtc routines, board_time_init() and plat_timer_setup()
|
|||
|
||||
board_time_init() -
|
||||
a) (optional) set up RTC routines,
|
||||
b) (optional) calibrate and set the mips_counter_frequency
|
||||
(only needed if you intended to use fixed_rate_gettimeoffset
|
||||
or use cpu counter as timer interrupt source)
|
||||
b) (optional) calibrate and set the mips_hpt_frequency
|
||||
(only needed if you intended to use cpu counter as timer interrupt
|
||||
source)
|
||||
|
||||
plat_timer_setup() -
|
||||
a) (optional) over-write any choices made above by time_init().
|
||||
|
|
@ -154,8 +138,8 @@ for some of the functions in time.c.
|
|||
For example, you may define your own timer interrupt routine, which does
|
||||
some of its own processing and then calls timer_interrupt().
|
||||
|
||||
You can also over-ride any of the built-in functions (gettimeoffset,
|
||||
RTC routines and/or timer interrupt routine).
|
||||
You can also over-ride any of the built-in functions (RTC routines
|
||||
and/or timer interrupt routine).
|
||||
|
||||
|
||||
PORTING NOTES FOR SMP
|
||||
|
|
@ -187,10 +171,3 @@ You need to decide on your timer interrupt sources.
|
|||
|
||||
You can also do the low-level version of those interrupt routines,
|
||||
following similar dispatching routes described above.
|
||||
|
||||
Note about do_gettimeoffset():
|
||||
|
||||
It is very likely the CPU counter registers are not sync'ed up in a SMP box.
|
||||
Therefore you cannot really use the many of the existing routines that
|
||||
are based on CPU counter. You should wirte your own gettimeoffset rouinte
|
||||
if you want intra-jiffy resolution.
|
||||
|
|
|
|||
|
|
@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
|
|||
Move all to dev->poll()
|
||||
|
||||
C) Ability to detect new work correctly.
|
||||
NAPI works by shutting down event interrupts when theres work and
|
||||
turning them on when theres none.
|
||||
NAPI works by shutting down event interrupts when there's work and
|
||||
turning them on when there's none.
|
||||
New packets might show up in the small window while interrupts were being
|
||||
re-enabled (refer to appendix 2). A packet might sneak in during the period
|
||||
we are enabling interrupts. We only get to know about such a packet when the
|
||||
|
|
@ -114,7 +114,7 @@ Locking rules and environmental guarantees
|
|||
only one CPU can pick the initial interrupt and hence the initial
|
||||
netif_rx_schedule(dev);
|
||||
- The core layer invokes devices to send packets in a round robin format.
|
||||
This implies receive is totaly lockless because of the guarantee only that
|
||||
This implies receive is totally lockless because of the guarantee that only
|
||||
one CPU is executing it.
|
||||
- contention can only be the result of some other CPU accessing the rx
|
||||
ring. This happens only in close() and suspend() (when these methods
|
||||
|
|
@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget)
|
|||
an interrupt will be generated */
|
||||
goto done;
|
||||
}
|
||||
/* done! at least thats what it looks like ;->
|
||||
/* done! at least that's what it looks like ;->
|
||||
if new packets came in after our last check on status bits
|
||||
they'll be caught by the while check and we go back and clear them
|
||||
since we havent exceeded our quota */
|
||||
|
|
@ -535,11 +535,11 @@ done:
|
|||
* 1. it can race with disabling irqs in irq handler (which are done to
|
||||
* schedule polls)
|
||||
* 2. it can race with dis/enabling irqs in other poll threads
|
||||
* 3. if an irq raised after the begining of the outer beginning
|
||||
* 3. if an irq raised after the beginning of the outer beginning
|
||||
* loop (marked in the code above), it will be immediately
|
||||
* triggered here.
|
||||
*
|
||||
* Summarizing: the logic may results in some redundant irqs both
|
||||
* Summarizing: the logic may result in some redundant irqs both
|
||||
* due to races in masking and due to too late acking of already
|
||||
* processed irqs. The good news: no events are ever lost.
|
||||
*/
|
||||
|
|
@ -601,7 +601,7 @@ a)
|
|||
|
||||
5) dev->close() and dev->suspend() issues
|
||||
==========================================
|
||||
The driver writter neednt worry about this. The top net layer takes
|
||||
The driver writer needn't worry about this; the top net layer takes
|
||||
care of it.
|
||||
|
||||
6) Adding new Stats to /proc
|
||||
|
|
@ -622,9 +622,9 @@ FC should be programmed to apply in the case when the system cant pull out
|
|||
packets fast enough i.e send a pause only when you run out of rx buffers.
|
||||
Note FC in itself is a good solution but we have found it to not be
|
||||
much of a commodity feature (both in NICs and switches) and hence falls
|
||||
under the same category as using NIC based mitigation. Also experiments
|
||||
indicate that its much harder to resolve the resource allocation
|
||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
|
||||
under the same category as using NIC based mitigation. Also, experiments
|
||||
indicate that it's much harder to resolve the resource allocation
|
||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
|
||||
proved harder. In any case, FC works even better with NAPI but is not
|
||||
necessary.
|
||||
|
||||
|
|
@ -678,10 +678,10 @@ routine:
|
|||
CSR5 bit of interest is only the rx status.
|
||||
If you look at the last if statement:
|
||||
you just finished grabbing all the packets from the rx ring .. you check if
|
||||
status bit says theres more packets just in ... it says none; you then
|
||||
status bit says there are more packets just in ... it says none; you then
|
||||
enable rx interrupts again; if a new packet just came in during this check,
|
||||
we are counting that CSR5 will be set in that small window of opportunity
|
||||
and that by re-enabling interrupts, we would actually triger an interrupt
|
||||
and that by re-enabling interrupts, we would actually trigger an interrupt
|
||||
to register the new packet for processing.
|
||||
|
||||
[The above description nay be very verbose, if you have better wording
|
||||
|
|
|
|||
|
|
@ -620,8 +620,8 @@ I/O Address Device IRQ Device
|
|||
12 Mouse (PS/2)
|
||||
Memory Address Device 13 Math Coprocessor
|
||||
-------------- --------------------- 14 Hard Disk controller
|
||||
A000-BFFF EGA Graphics Adpater
|
||||
A000-C7FF VGA Graphics Adpater
|
||||
A000-BFFF EGA Graphics Adapter
|
||||
A000-C7FF VGA Graphics Adapter
|
||||
B000-BFFF Mono Graphics Adapter
|
||||
B800-BFFF Color Graphics Adapter
|
||||
E000-FFFF AT BIOS
|
||||
|
|
|
|||
|
|
@ -19,21 +19,17 @@ for real time and multimedia traffic.
|
|||
|
||||
It has a base protocol and pluggable congestion control IDs (CCIDs).
|
||||
|
||||
It is at draft RFC status and the homepage for DCCP as a protocol is at:
|
||||
http://www.icir.org/kohler/dcp/
|
||||
It is at experimental RFC status and the homepage for DCCP as a protocol is at:
|
||||
http://www.read.cs.ucla.edu/dccp/
|
||||
|
||||
Missing features
|
||||
================
|
||||
|
||||
The DCCP implementation does not currently have all the features that are in
|
||||
the draft RFC.
|
||||
the RFC.
|
||||
|
||||
In particular the following are missing:
|
||||
- CCID2 support
|
||||
- feature negotiation
|
||||
|
||||
When testing against other implementations it appears that elapsed time
|
||||
options are not coded compliant to the specification.
|
||||
The known bugs are at:
|
||||
http://linux-net.osdl.org/index.php/TODO#DCCP
|
||||
|
||||
Socket options
|
||||
==============
|
||||
|
|
@ -47,12 +43,70 @@ the socket will fall back to 0 (which means that no meaningful service code
|
|||
is present). Connecting sockets set at most one service option; for
|
||||
listening sockets, multiple service codes can be specified.
|
||||
|
||||
DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
|
||||
partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
|
||||
always cover the entire packet and that only fully covered application data is
|
||||
accepted by the receiver. Hence, when using this feature on the sender, it must
|
||||
be enabled at the receiver, too with suitable choice of CsCov.
|
||||
|
||||
DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
|
||||
range 0..15 are acceptable. The default setting is 0 (full coverage),
|
||||
values between 1..15 indicate partial coverage.
|
||||
DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
|
||||
sets a threshold, where again values 0..15 are acceptable. The default
|
||||
of 0 means that all packets with a partial coverage will be discarded.
|
||||
Values in the range 1..15 indicate that packets with minimally such a
|
||||
coverage value are also acceptable. The higher the number, the more
|
||||
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
|
||||
|
||||
Sysctl variables
|
||||
================
|
||||
Several DCCP default parameters can be managed by the following sysctls
|
||||
(sysctl net.dccp.default or /proc/sys/net/dccp/default):
|
||||
|
||||
request_retries
|
||||
The number of active connection initiation retries (the number of
|
||||
Requests minus one) before timing out. In addition, it also governs
|
||||
the behaviour of the other, passive side: this variable also sets
|
||||
the number of times DCCP repeats sending a Response when the initial
|
||||
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
|
||||
is received after the initial Request). This value should be greater
|
||||
than 0, suggested is less than 10. Analogue of tcp_syn_retries.
|
||||
|
||||
retries1
|
||||
How often a DCCP Response is retransmitted until the listening DCCP
|
||||
side considers its connecting peer dead. Analogue of tcp_retries1.
|
||||
|
||||
retries2
|
||||
The number of times a general DCCP packet is retransmitted. This has
|
||||
importance for retransmitted acknowledgments and feature negotiation,
|
||||
data packets are never retransmitted. Analogue of tcp_retries2.
|
||||
|
||||
send_ndp = 1
|
||||
Whether or not to send NDP count options (sec. 7.7.2).
|
||||
|
||||
send_ackvec = 1
|
||||
Whether or not to send Ack Vector options (sec. 11.5).
|
||||
|
||||
ack_ratio = 2
|
||||
The default Ack Ratio (sec. 11.3) to use.
|
||||
|
||||
tx_ccid = 2
|
||||
Default CCID for the sender-receiver half-connection.
|
||||
|
||||
rx_ccid = 2
|
||||
Default CCID for the receiver-sender half-connection.
|
||||
|
||||
seq_window = 100
|
||||
The initial sequence window (sec. 7.5.2).
|
||||
|
||||
tx_qlen = 5
|
||||
The size of the transmit buffer in packets. A value of 0 corresponds
|
||||
to an unbounded transmit buffer.
|
||||
|
||||
Notes
|
||||
=====
|
||||
|
||||
SELinux does not yet have support for DCCP. You will need to turn it off or
|
||||
else you will get EACCES.
|
||||
|
||||
DCCP does not travel through NAT successfully at present. This is because
|
||||
the checksum covers the psuedo-header as per TCP and UDP. It should be
|
||||
relatively trivial to add Linux NAT support for DCCP.
|
||||
DCCP does not travel through NAT successfully at present on many boxes. This is
|
||||
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
|
||||
support for DCCP has been added.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
|
||||
===============================================================
|
||||
|
||||
November 15, 2005
|
||||
September 26, 2006
|
||||
|
||||
|
||||
Contents
|
||||
|
|
@ -9,6 +9,7 @@ Contents
|
|||
|
||||
- In This Release
|
||||
- Identifying Your Adapter
|
||||
- Building and Installation
|
||||
- Command Line Parameters
|
||||
- Speed and Duplex Configuration
|
||||
- Additional Configurations
|
||||
|
|
@ -41,6 +42,9 @@ or later), lspci, and ifconfig to obtain the same information.
|
|||
Instructions on updating ethtool can be found in the section "Additional
|
||||
Configurations" later in this document.
|
||||
|
||||
NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
|
||||
support.
|
||||
|
||||
|
||||
Identifying Your Adapter
|
||||
========================
|
||||
|
|
@ -57,22 +61,21 @@ networking link on the left to search for your adapter:
|
|||
http://downloadfinder.intel.com/scripts-df/support_intel.asp
|
||||
|
||||
|
||||
Command Line Parameters =======================
|
||||
Command Line Parameters
|
||||
=======================
|
||||
|
||||
If the driver is built as a module, the following optional parameters
|
||||
are used by entering them on the command line with the modprobe or insmod
|
||||
command using this syntax:
|
||||
are used by entering them on the command line with the modprobe command
|
||||
using this syntax:
|
||||
|
||||
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
|
||||
|
||||
insmod e1000 [<option>=<VAL1>,<VAL2>,...]
|
||||
|
||||
For example, with two PRO/1000 PCI adapters, entering:
|
||||
|
||||
insmod e1000 TxDescriptors=80,128
|
||||
modprobe e1000 TxDescriptors=80,128
|
||||
|
||||
loads the e1000 driver with 80 TX descriptors for the first adapter and 128
|
||||
TX descriptors for the second adapter.
|
||||
loads the e1000 driver with 80 TX descriptors for the first adapter and
|
||||
128 TX descriptors for the second adapter.
|
||||
|
||||
The default value for each parameter is generally the recommended setting,
|
||||
unless otherwise noted.
|
||||
|
|
@ -96,9 +99,9 @@ AutoNeg
|
|||
Valid Range: 0x01-0x0F, 0x20-0x2F
|
||||
Default Value: 0x2F
|
||||
|
||||
This parameter is a bit mask that specifies which speed and duplex
|
||||
settings the board advertises. When this parameter is used, the Speed
|
||||
and Duplex parameters must not be specified.
|
||||
This parameter is a bit-mask that specifies the speed and duplex settings
|
||||
advertised by the adapter. When this parameter is used, the Speed and
|
||||
Duplex parameters must not be specified.
|
||||
|
||||
NOTE: Refer to the Speed and Duplex section of this readme for more
|
||||
information on the AutoNeg parameter.
|
||||
|
|
@ -110,14 +113,15 @@ Duplex
|
|||
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
|
||||
Default Value: 0
|
||||
|
||||
Defines the direction in which data is allowed to flow. Can be either
|
||||
one or two-directional. If both Duplex and the link partner are set to
|
||||
auto-negotiate, the board auto-detects the correct duplex. If the link
|
||||
partner is forced (either full or half), Duplex defaults to half-duplex.
|
||||
This defines the direction in which data is allowed to flow. Can be
|
||||
either one or two-directional. If both Duplex and the link partner are
|
||||
set to auto-negotiate, the board auto-detects the correct duplex. If the
|
||||
link partner is forced (either full or half), Duplex defaults to half-
|
||||
duplex.
|
||||
|
||||
|
||||
FlowControl
|
||||
----------
|
||||
-----------
|
||||
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
||||
Default Value: Reads flow control settings from the EEPROM
|
||||
|
||||
|
|
@ -127,14 +131,55 @@ to Ethernet PAUSE frames.
|
|||
|
||||
InterruptThrottleRate
|
||||
---------------------
|
||||
(not supported on Intel 82542, 82543 or 82544-based adapters)
|
||||
Valid Range: 100-100000 (0=off, 1=dynamic)
|
||||
Default Value: 8000
|
||||
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
|
||||
Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
|
||||
Default Value: 3
|
||||
|
||||
This value represents the maximum number of interrupts per second the
|
||||
controller generates. InterruptThrottleRate is another setting used in
|
||||
interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
|
||||
InterruptThrottleRate based on the current traffic load.
|
||||
The driver can limit the amount of interrupts per second that the adapter
|
||||
will generate for incoming packets. It does this by writing a value to the
|
||||
adapter that is based on the maximum amount of interrupts that the adapter
|
||||
will generate per second.
|
||||
|
||||
Setting InterruptThrottleRate to a value greater or equal to 100
|
||||
will program the adapter to send out a maximum of that many interrupts
|
||||
per second, even if more packets have come in. This reduces interrupt
|
||||
load on the system and can lower CPU utilization under heavy load,
|
||||
but will increase latency as packets are not processed as quickly.
|
||||
|
||||
The default behaviour of the driver previously assumed a static
|
||||
InterruptThrottleRate value of 8000, providing a good fallback value for
|
||||
all traffic types,but lacking in small packet performance and latency.
|
||||
The hardware can handle many more small packets per second however, and
|
||||
for this reason an adaptive interrupt moderation algorithm was implemented.
|
||||
|
||||
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
|
||||
it dynamically adjusts the InterruptThrottleRate value based on the traffic
|
||||
that it receives. After determining the type of incoming traffic in the last
|
||||
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
|
||||
for that traffic.
|
||||
|
||||
The algorithm classifies the incoming traffic every interval into
|
||||
classes. Once the class is determined, the InterruptThrottleRate value is
|
||||
adjusted to suit that traffic type the best. There are three classes defined:
|
||||
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
|
||||
for small amounts of traffic and/or a significant percentage of small
|
||||
packets; and "Lowest latency", for almost completely small packets or
|
||||
minimal traffic.
|
||||
|
||||
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
|
||||
for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
|
||||
latency" or "Lowest latency" class, the InterruptThrottleRate is increased
|
||||
stepwise to 20000. This default mode is suitable for most applications.
|
||||
|
||||
For situations where low latency is vital such as cluster or
|
||||
grid computing, the algorithm can reduce latency even more when
|
||||
InterruptThrottleRate is set to mode 1. In this mode, which operates
|
||||
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
|
||||
70000 for traffic in class "Lowest latency".
|
||||
|
||||
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
|
||||
and may improve small packet latency, but is generally not suitable
|
||||
for bulk throughput traffic.
|
||||
|
||||
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
|
||||
RxAbsIntDelay parameters. In other words, minimizing the receive
|
||||
|
|
@ -142,7 +187,7 @@ NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
|
|||
generate more interrupts than what the Interrupt Throttle Rate
|
||||
allows.
|
||||
|
||||
CAUTION: If you are using the Intel PRO/1000 CT Network Connection
|
||||
CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection
|
||||
(controller 82547), setting InterruptThrottleRate to a value
|
||||
greater than 75,000, may hang (stop transmitting) adapters
|
||||
under certain network conditions. If this occurs a NETDEV
|
||||
|
|
@ -158,7 +203,7 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
|
|||
the overall throughput, we recommend that you load the driver as
|
||||
follows:
|
||||
|
||||
insmod e1000.o InterruptThrottleRate=3000,3000,3000
|
||||
modprobe e1000 InterruptThrottleRate=3000,3000,3000
|
||||
|
||||
This sets the InterruptThrottleRate to 3000 interrupts/sec for
|
||||
the first, second, and third instances of the driver. The range
|
||||
|
|
@ -168,16 +213,25 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
|
|||
RX_POLLING (NAPI) and default driver settings.
|
||||
|
||||
|
||||
|
||||
RxDescriptors
|
||||
-------------
|
||||
Valid Range: 80-256 for 82542 and 82543-based adapters
|
||||
80-4096 for all other supported adapters
|
||||
Default Value: 256
|
||||
|
||||
This value specifies the number of receive descriptors allocated by the
|
||||
driver. Increasing this value allows the driver to buffer more incoming
|
||||
packets. Each descriptor is 16 bytes. A receive buffer is also
|
||||
allocated for each descriptor and is 2048.
|
||||
This value specifies the number of receive buffer descriptors allocated
|
||||
by the driver. Increasing this value allows the driver to buffer more
|
||||
incoming packets, at the expense of increased system memory utilization.
|
||||
|
||||
Each descriptor is 16 bytes. A receive buffer is also allocated for each
|
||||
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
|
||||
on the MTU setting. The maximum MTU size is 16110.
|
||||
|
||||
NOTE: MTU designates the frame size. It only needs to be set for Jumbo
|
||||
Frames. Depending on the available system resources, the request
|
||||
for a higher number of receive descriptors may be denied. In this
|
||||
case, use a lower number.
|
||||
|
||||
|
||||
RxIntDelay
|
||||
|
|
@ -304,7 +358,7 @@ auto-negotiation process. It should be used when you wish to control which
|
|||
speed and duplex combinations are advertised during the auto-negotiation
|
||||
process.
|
||||
|
||||
The parameter may be specified as either a decimal or hexidecimal value as
|
||||
The parameter may be specified as either a decimal or hexadecimal value as
|
||||
determined by the bitmap below.
|
||||
|
||||
Bit position 7 6 5 4 3 2 1 0
|
||||
|
|
@ -337,7 +391,6 @@ Additional Configurations
|
|||
|
||||
Configuring the Driver on Different Distributions
|
||||
-------------------------------------------------
|
||||
|
||||
Configuring a network driver to load properly when the system is started
|
||||
is distribution dependent. Typically, the configuration process involves
|
||||
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
|
||||
|
|
@ -346,11 +399,11 @@ Additional Configurations
|
|||
To learn the proper way to configure a network device for your system,
|
||||
refer to your distribution documentation. If during this process you are
|
||||
asked for the driver or module name, the name for the Linux Base Driver
|
||||
for the Intel PRO/1000 Family of Adapters is e1000.
|
||||
for the Intel(R) PRO/1000 Family of Adapters is e1000.
|
||||
|
||||
As an example, if you install the e1000 driver for two PRO/1000 adapters
|
||||
(eth0 and eth1) and set the speed and duplex to 10full and 100half, add
|
||||
the following to modules.conf or modprobe.conf:
|
||||
the following to modules.conf or or modprobe.conf:
|
||||
|
||||
alias eth0 e1000
|
||||
alias eth1 e1000
|
||||
|
|
@ -358,7 +411,6 @@ Additional Configurations
|
|||
|
||||
Viewing Link Messages
|
||||
---------------------
|
||||
|
||||
Link messages will not be displayed to the console if the distribution is
|
||||
restricting system messages. In order to see network driver link messages
|
||||
on your console, set dmesg to eight by entering the following:
|
||||
|
|
@ -369,11 +421,9 @@ Additional Configurations
|
|||
|
||||
Jumbo Frames
|
||||
------------
|
||||
|
||||
The driver supports Jumbo Frames for all adapters except 82542 and
|
||||
82573-based adapters. Jumbo Frames support is enabled by changing the
|
||||
MTU to a value larger than the default of 1500. Use the ifconfig command
|
||||
to increase the MTU size. For example:
|
||||
Jumbo Frames support is enabled by changing the MTU to a value larger than
|
||||
the default of 1500. Use the ifconfig command to increase the MTU size.
|
||||
For example:
|
||||
|
||||
ifconfig eth<x> mtu 9000 up
|
||||
|
||||
|
|
@ -390,26 +440,49 @@ Additional Configurations
|
|||
|
||||
- To enable Jumbo Frames, increase the MTU size on the interface beyond
|
||||
1500.
|
||||
|
||||
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
|
||||
with the maximum Jumbo Frames size of 16128.
|
||||
|
||||
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
|
||||
loss of link.
|
||||
|
||||
- Some Intel gigabit adapters that support Jumbo Frames have a frame size
|
||||
limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes.
|
||||
The adapters with this limitation are based on the Intel 82571EB and
|
||||
82572EI controllers, which correspond to these product names:
|
||||
Intel® PRO/1000 PT Dual Port Server Adapter
|
||||
Intel® PRO/1000 PF Dual Port Server Adapter
|
||||
Intel® PRO/1000 PT Server Adapter
|
||||
Intel® PRO/1000 PT Desktop Adapter
|
||||
Intel® PRO/1000 PF Server Adapter
|
||||
The adapters with this limitation are based on the Intel(R) 82571EB,
|
||||
82572EI, 82573L and 80003ES2LAN controller. These correspond to the
|
||||
following product names:
|
||||
Intel(R) PRO/1000 PT Server Adapter
|
||||
Intel(R) PRO/1000 PT Desktop Adapter
|
||||
Intel(R) PRO/1000 PT Network Connection
|
||||
Intel(R) PRO/1000 PT Dual Port Server Adapter
|
||||
Intel(R) PRO/1000 PT Dual Port Network Connection
|
||||
Intel(R) PRO/1000 PF Server Adapter
|
||||
Intel(R) PRO/1000 PF Network Connection
|
||||
Intel(R) PRO/1000 PF Dual Port Server Adapter
|
||||
Intel(R) PRO/1000 PB Server Connection
|
||||
Intel(R) PRO/1000 PL Network Connection
|
||||
Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
|
||||
Intel(R) PRO/1000 EB Backplane Connection with I/O Acceleration
|
||||
Intel(R) PRO/1000 PT Quad Port Server Adapter
|
||||
|
||||
- The Intel PRO/1000 PM Network Connection does not support jumbo frames.
|
||||
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
|
||||
support Jumbo Frames. These correspond to the following product names:
|
||||
Intel(R) PRO/1000 Gigabit Server Adapter
|
||||
Intel(R) PRO/1000 PM Network Connection
|
||||
|
||||
- The following adapters do not support Jumbo Frames:
|
||||
Intel(R) 82562V 10/100 Network Connection
|
||||
Intel(R) 82566DM Gigabit Network Connection
|
||||
Intel(R) 82566DC Gigabit Network Connection
|
||||
Intel(R) 82566MM Gigabit Network Connection
|
||||
Intel(R) 82566MC Gigabit Network Connection
|
||||
Intel(R) 82562GT 10/100 Network Connection
|
||||
Intel(R) 82562G 10/100 Network Connection
|
||||
|
||||
|
||||
Ethtool
|
||||
-------
|
||||
|
||||
The driver utilizes the ethtool interface for driver configuration and
|
||||
diagnostics, as well as displaying statistical information. Ethtool
|
||||
version 1.6 or later is required for this functionality.
|
||||
|
|
@ -423,7 +496,6 @@ Additional Configurations
|
|||
|
||||
Enabling Wake on LAN* (WoL)
|
||||
---------------------------
|
||||
|
||||
WoL is configured through the Ethtool* utility. Ethtool is included with
|
||||
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
|
||||
download and install Ethtool from the following website:
|
||||
|
|
@ -436,9 +508,15 @@ Additional Configurations
|
|||
For this driver version, in order to enable WoL, the e1000 driver must be
|
||||
loaded when shutting down or rebooting the system.
|
||||
|
||||
Wake On LAN is only supported on port A for the following devices:
|
||||
Intel(R) PRO/1000 PT Dual Port Network Connection
|
||||
Intel(R) PRO/1000 PT Dual Port Server Connection
|
||||
Intel(R) PRO/1000 PT Dual Port Server Adapter
|
||||
Intel(R) PRO/1000 PF Dual Port Server Adapter
|
||||
Intel(R) PRO/1000 PT Quad Port Server Adapter
|
||||
|
||||
NAPI
|
||||
----
|
||||
|
||||
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
||||
or disabled based on the configuration of the kernel. To override
|
||||
the default, use the following compile-time flags.
|
||||
|
|
@ -457,9 +535,15 @@ Additional Configurations
|
|||
Known Issues
|
||||
============
|
||||
|
||||
Dropped Receive Packets on Half-duplex 10/100 Networks
|
||||
------------------------------------------------------
|
||||
If you have an Intel PCI Express adapter running at 10mbps or 100mbps, half-
|
||||
duplex, you may observe occasional dropped receive packets. There are no
|
||||
workarounds for this problem in this network configuration. The network must
|
||||
be updated to operate in full-duplex, and/or 1000mbps only.
|
||||
|
||||
Jumbo Frames System Requirement
|
||||
-------------------------------
|
||||
|
||||
Memory allocation failures have been observed on Linux systems with 64 MB
|
||||
of RAM or less that are running Jumbo Frames. If you are using Jumbo
|
||||
Frames, your system may require more than the advertised minimum
|
||||
|
|
@ -467,7 +551,6 @@ Known Issues
|
|||
|
||||
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
|
||||
|
|
@ -475,15 +558,22 @@ Known Issues
|
|||
/usr/src/linux*/Documentation/
|
||||
networking/ip-sysctl.txt for more details.
|
||||
|
||||
Jumbo frames on Foundry BigIron 8000 switch
|
||||
Jumbo Frames on Foundry BigIron 8000 switch
|
||||
-------------------------------------------
|
||||
There is a known issue using Jumbo frames when connected to a Foundry
|
||||
BigIron 8000 switch. This is a 3rd party limitation. If you experience
|
||||
loss of packets, lower the MTU size.
|
||||
|
||||
Allocating Rx Buffers when Using Jumbo Frames
|
||||
---------------------------------------------
|
||||
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
|
||||
the available memory is heavily fragmented. This issue may be seen with PCI-X
|
||||
adapters or with packet split disabled. This can be reduced or eliminated
|
||||
by changing the amount of available memory for receive buffer allocation, by
|
||||
increasing /proc/sys/vm/min_free_kbytes.
|
||||
|
||||
Multiple Interfaces on Same Ethernet Broadcast Network
|
||||
------------------------------------------------------
|
||||
|
||||
Due to the default ARP behavior on Linux, it is not possible to have
|
||||
one system on two IP networks in the same Ethernet broadcast domain
|
||||
(non-partitioned switch) behave as expected. All Ethernet interfaces
|
||||
|
|
@ -508,7 +598,6 @@ Known Issues
|
|||
|
||||
82541/82547 can't link or are slow to link with some link partners
|
||||
-----------------------------------------------------------------
|
||||
|
||||
There is a known compatibility issue with 82541/82547 and some
|
||||
low-end switches where the link will not be established, or will
|
||||
be slow to establish. In particular, these switches are known to
|
||||
|
|
@ -521,7 +610,7 @@ Known Issues
|
|||
of the PHY's master/slave setting. Forcing master or forcing slave
|
||||
mode will improve time-to-link.
|
||||
|
||||
# make EXTRA_CFLAGS=-DE1000_MASTER_SLAVE=<n>
|
||||
# make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
|
||||
|
||||
Where <n> is:
|
||||
|
||||
|
|
@ -532,7 +621,6 @@ Known Issues
|
|||
|
||||
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.
|
||||
|
||||
|
|
@ -540,6 +628,13 @@ Known Issues
|
|||
|
||||
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
|
||||
=======
|
||||
|
|
@ -554,18 +649,4 @@ For general information, go to the Intel support website at:
|
|||
|
||||
If an issue is identified with the released source code on the supported
|
||||
kernel with a supported adapter, email the specific information related
|
||||
to the issue to e1000-devel@lists.sourceforge.net
|
||||
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
This software program is released under the terms of a license agreement
|
||||
between you ('Licensee') and Intel. Do not use or load this software or any
|
||||
associated materials (collectively, the 'Software') until you have carefully
|
||||
read the full terms and conditions of the file COPYING located in this software
|
||||
package. By loading or using the Software, you agree to the terms of this
|
||||
Agreement. If you do not agree with the terms of this Agreement, do not
|
||||
install or use the Software.
|
||||
|
||||
* Other names and brands may be claimed as the property of others.
|
||||
to the issue to e1000-devel@lists.sf.net
|
||||
|
|
|
|||
|
|
@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER
|
|||
|
||||
TCP variables:
|
||||
|
||||
somaxconn - INTEGER
|
||||
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
|
||||
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
|
||||
for TCP sockets.
|
||||
|
||||
tcp_abc - INTEGER
|
||||
Controls Appropriate Byte Count (ABC) defined in RFC3465.
|
||||
ABC is a way of increasing congestion window (cwnd) more slowly
|
||||
|
|
@ -112,15 +117,68 @@ tcp_abc - INTEGER
|
|||
of two segments to compensate for delayed acknowledgments.
|
||||
Default: 0 (off)
|
||||
|
||||
tcp_syn_retries - INTEGER
|
||||
Number of times initial SYNs for an active TCP connection attempt
|
||||
will be retransmitted. Should not be higher than 255. Default value
|
||||
is 5, which corresponds to ~180seconds.
|
||||
tcp_abort_on_overflow - BOOLEAN
|
||||
If listening service is too slow to accept new connections,
|
||||
reset them. Default state is FALSE. It means that if overflow
|
||||
occurred due to a burst, connection will recover. Enable this
|
||||
option _only_ if you are really sure that listening daemon
|
||||
cannot be tuned to accept connections faster. Enabling this
|
||||
option can harm clients of your server.
|
||||
|
||||
tcp_synack_retries - INTEGER
|
||||
Number of times SYNACKs for a passive TCP connection attempt will
|
||||
be retransmitted. Should not be higher than 255. Default value
|
||||
is 5, which corresponds to ~180seconds.
|
||||
tcp_adv_win_scale - INTEGER
|
||||
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
||||
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
||||
if it is <= 0.
|
||||
Default: 2
|
||||
|
||||
tcp_allowed_congestion_control - STRING
|
||||
Show/set the congestion control choices available to non-privileged
|
||||
processes. The list is a subset of those listed in
|
||||
tcp_available_congestion_control.
|
||||
Default is "reno" and the default setting (tcp_congestion_control).
|
||||
|
||||
tcp_app_win - INTEGER
|
||||
Reserve max(window/2^tcp_app_win, mss) of window for application
|
||||
buffer. Value 0 is special, it means that nothing is reserved.
|
||||
Default: 31
|
||||
|
||||
tcp_available_congestion_control - STRING
|
||||
Shows the available congestion control choices that are registered.
|
||||
More congestion control algorithms may be available as modules,
|
||||
but not loaded.
|
||||
|
||||
tcp_congestion_control - STRING
|
||||
Set the congestion control algorithm to be used for new
|
||||
connections. The algorithm "reno" is always available, but
|
||||
additional choices may be available based on kernel configuration.
|
||||
Default is set as part of kernel configuration.
|
||||
|
||||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
tcp_ecn - BOOLEAN
|
||||
Enable Explicit Congestion Notification in TCP.
|
||||
|
||||
tcp_fack - BOOLEAN
|
||||
Enable FACK congestion avoidance and fast retransmission.
|
||||
The value is not used, if tcp_sack is not enabled.
|
||||
|
||||
tcp_fin_timeout - INTEGER
|
||||
Time to hold socket in state FIN-WAIT-2, if it was closed
|
||||
by our side. Peer can be broken and never close its side,
|
||||
or even died unexpectedly. Default value is 60sec.
|
||||
Usual value used in 2.2 was 180 seconds, you may restore
|
||||
it, but remember that if your machine is even underloaded WEB server,
|
||||
you risk to overflow memory with kilotons of dead sockets,
|
||||
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
|
||||
because they eat maximum 1.5K of memory, but they tend
|
||||
to live longer. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_frto - BOOLEAN
|
||||
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
|
||||
timeouts. It is particularly beneficial in wireless environments
|
||||
where packet loss is typically due to random radio interference
|
||||
rather than intermediate router congestion.
|
||||
|
||||
tcp_keepalive_time - INTEGER
|
||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
||||
|
|
@ -136,54 +194,13 @@ tcp_keepalive_intvl - INTEGER
|
|||
after probes started. Default value: 75sec i.e. connection
|
||||
will be aborted after ~11 minutes of retries.
|
||||
|
||||
tcp_retries1 - INTEGER
|
||||
How many times to retry before deciding that something is wrong
|
||||
and it is necessary to report this suspicion to network layer.
|
||||
Minimal RFC value is 3, it is default, which corresponds
|
||||
to ~3sec-8min depending on RTO.
|
||||
|
||||
tcp_retries2 - INTEGER
|
||||
How may times to retry before killing alive TCP connection.
|
||||
RFC1122 says that the limit should be longer than 100 sec.
|
||||
It is too small number. Default value 15 corresponds to ~13-30min
|
||||
depending on RTO.
|
||||
|
||||
tcp_orphan_retries - INTEGER
|
||||
How may times to retry before killing TCP connection, closed
|
||||
by our side. Default value 7 corresponds to ~50sec-16min
|
||||
depending on RTO. If you machine is loaded WEB server,
|
||||
you should think about lowering this value, such sockets
|
||||
may consume significant resources. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_fin_timeout - INTEGER
|
||||
Time to hold socket in state FIN-WAIT-2, if it was closed
|
||||
by our side. Peer can be broken and never close its side,
|
||||
or even died unexpectedly. Default value is 60sec.
|
||||
Usual value used in 2.2 was 180 seconds, you may restore
|
||||
it, but remember that if your machine is even underloaded WEB server,
|
||||
you risk to overflow memory with kilotons of dead sockets,
|
||||
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
|
||||
because they eat maximum 1.5K of memory, but they tend
|
||||
to live longer. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_max_tw_buckets - INTEGER
|
||||
Maximal number of timewait sockets held by system simultaneously.
|
||||
If this number is exceeded time-wait socket is immediately destroyed
|
||||
and warning is printed. This limit exists only to prevent
|
||||
simple DoS attacks, you _must_ not lower the limit artificially,
|
||||
but rather increase it (probably, after increasing installed memory),
|
||||
if network conditions require more than default value.
|
||||
|
||||
tcp_tw_recycle - BOOLEAN
|
||||
Enable fast recycling TIME-WAIT sockets. Default value is 0.
|
||||
It should not be changed without advice/request of technical
|
||||
experts.
|
||||
|
||||
tcp_tw_reuse - BOOLEAN
|
||||
Allow to reuse TIME-WAIT sockets for new connections when it is
|
||||
safe from protocol viewpoint. Default value is 0.
|
||||
It should not be changed without advice/request of technical
|
||||
experts.
|
||||
tcp_low_latency - BOOLEAN
|
||||
If set, the TCP stack makes decisions that prefer lower
|
||||
latency as opposed to higher throughput. By default, this
|
||||
option is not set meaning that higher throughput is preferred.
|
||||
An example of an application where this default should be
|
||||
changed would be a Beowulf compute cluster.
|
||||
Default: 0
|
||||
|
||||
tcp_max_orphans - INTEGER
|
||||
Maximal number of TCP sockets not attached to any user file handle,
|
||||
|
|
@ -197,13 +214,106 @@ tcp_max_orphans - INTEGER
|
|||
more aggressively. Let me to remind again: each orphan eats
|
||||
up to ~64K of unswappable memory.
|
||||
|
||||
tcp_abort_on_overflow - BOOLEAN
|
||||
If listening service is too slow to accept new connections,
|
||||
reset them. Default state is FALSE. It means that if overflow
|
||||
occurred due to a burst, connection will recover. Enable this
|
||||
option _only_ if you are really sure that listening daemon
|
||||
cannot be tuned to accept connections faster. Enabling this
|
||||
option can harm clients of your server.
|
||||
tcp_max_syn_backlog - INTEGER
|
||||
Maximal number of remembered connection requests, which are
|
||||
still did not receive an acknowledgment from connecting client.
|
||||
Default value is 1024 for systems with more than 128Mb of memory,
|
||||
and 128 for low memory machines. If server suffers of overload,
|
||||
try to increase this number.
|
||||
|
||||
tcp_max_tw_buckets - INTEGER
|
||||
Maximal number of timewait sockets held by system simultaneously.
|
||||
If this number is exceeded time-wait socket is immediately destroyed
|
||||
and warning is printed. This limit exists only to prevent
|
||||
simple DoS attacks, you _must_ not lower the limit artificially,
|
||||
but rather increase it (probably, after increasing installed memory),
|
||||
if network conditions require more than default value.
|
||||
|
||||
tcp_mem - vector of 3 INTEGERs: min, pressure, max
|
||||
min: below this number of pages TCP is not bothered about its
|
||||
memory appetite.
|
||||
|
||||
pressure: when amount of memory allocated by TCP exceeds this number
|
||||
of pages, TCP moderates its memory consumption and enters memory
|
||||
pressure mode, which is exited when memory consumption falls
|
||||
under "min".
|
||||
|
||||
max: number of pages allowed for queueing by all TCP sockets.
|
||||
|
||||
Defaults are calculated at boot time from amount of available
|
||||
memory.
|
||||
|
||||
tcp_orphan_retries - INTEGER
|
||||
How may times to retry before killing TCP connection, closed
|
||||
by our side. Default value 7 corresponds to ~50sec-16min
|
||||
depending on RTO. If you machine is loaded WEB server,
|
||||
you should think about lowering this value, such sockets
|
||||
may consume significant resources. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_reordering - INTEGER
|
||||
Maximal reordering of packets in a TCP stream.
|
||||
Default: 3
|
||||
|
||||
tcp_retrans_collapse - BOOLEAN
|
||||
Bug-to-bug compatibility with some broken printers.
|
||||
On retransmit try to send bigger packets to work around bugs in
|
||||
certain TCP stacks.
|
||||
|
||||
tcp_retries1 - INTEGER
|
||||
How many times to retry before deciding that something is wrong
|
||||
and it is necessary to report this suspicion to network layer.
|
||||
Minimal RFC value is 3, it is default, which corresponds
|
||||
to ~3sec-8min depending on RTO.
|
||||
|
||||
tcp_retries2 - INTEGER
|
||||
How may times to retry before killing alive TCP connection.
|
||||
RFC1122 says that the limit should be longer than 100 sec.
|
||||
It is too small number. Default value 15 corresponds to ~13-30min
|
||||
depending on RTO.
|
||||
|
||||
tcp_rfc1337 - BOOLEAN
|
||||
If set, the TCP stack behaves conforming to RFC1337. If unset,
|
||||
we are not conforming to RFC, but prevent TCP TIME_WAIT
|
||||
assassination.
|
||||
Default: 0
|
||||
|
||||
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
||||
min: Minimal size of receive buffer used by TCP sockets.
|
||||
It is guaranteed to each TCP socket, even under moderate memory
|
||||
pressure.
|
||||
Default: 8K
|
||||
|
||||
default: default size of receive buffer used by TCP sockets.
|
||||
This value overrides net.core.rmem_default used by other protocols.
|
||||
Default: 87380 bytes. This value results in window of 65535 with
|
||||
default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit
|
||||
less for default tcp_app_win. See below about these variables.
|
||||
|
||||
max: maximal size of receive buffer allowed for automatically
|
||||
selected receiver buffers for TCP socket. This value does not override
|
||||
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
|
||||
Default: 87380*2 bytes.
|
||||
|
||||
tcp_sack - BOOLEAN
|
||||
Enable select acknowledgments (SACKS).
|
||||
|
||||
tcp_slow_start_after_idle - BOOLEAN
|
||||
If set, provide RFC2861 behavior and time out the congestion
|
||||
window after an idle period. An idle period is defined at
|
||||
the current RTO. If unset, the congestion window will not
|
||||
be timed out after an idle period.
|
||||
Default: 1
|
||||
|
||||
tcp_stdurg - BOOLEAN
|
||||
Use the Host requirements interpretation of the TCP urg pointer field.
|
||||
Most hosts use the older BSD interpretation, so if you turn this on
|
||||
Linux might not communicate correctly with them.
|
||||
Default: FALSE
|
||||
|
||||
tcp_synack_retries - INTEGER
|
||||
Number of times SYNACKs for a passive TCP connection attempt will
|
||||
be retransmitted. Should not be higher than 255. Default value
|
||||
is 5, which corresponds to ~180seconds.
|
||||
|
||||
tcp_syncookies - BOOLEAN
|
||||
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
|
||||
|
|
@ -226,46 +336,34 @@ tcp_syncookies - BOOLEAN
|
|||
synflood warnings in logs not being really flooded, your server
|
||||
is seriously misconfigured.
|
||||
|
||||
tcp_stdurg - BOOLEAN
|
||||
Use the Host requirements interpretation of the TCP urg pointer field.
|
||||
Most hosts use the older BSD interpretation, so if you turn this on
|
||||
Linux might not communicate correctly with them.
|
||||
Default: FALSE
|
||||
|
||||
tcp_max_syn_backlog - INTEGER
|
||||
Maximal number of remembered connection requests, which are
|
||||
still did not receive an acknowledgment from connecting client.
|
||||
Default value is 1024 for systems with more than 128Mb of memory,
|
||||
and 128 for low memory machines. If server suffers of overload,
|
||||
try to increase this number.
|
||||
|
||||
tcp_window_scaling - BOOLEAN
|
||||
Enable window scaling as defined in RFC1323.
|
||||
tcp_syn_retries - INTEGER
|
||||
Number of times initial SYNs for an active TCP connection attempt
|
||||
will be retransmitted. Should not be higher than 255. Default value
|
||||
is 5, which corresponds to ~180seconds.
|
||||
|
||||
tcp_timestamps - BOOLEAN
|
||||
Enable timestamps as defined in RFC1323.
|
||||
|
||||
tcp_sack - BOOLEAN
|
||||
Enable select acknowledgments (SACKS).
|
||||
|
||||
tcp_fack - BOOLEAN
|
||||
Enable FACK congestion avoidance and fast retransmission.
|
||||
The value is not used, if tcp_sack is not enabled.
|
||||
|
||||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
tcp_ecn - BOOLEAN
|
||||
Enable Explicit Congestion Notification in TCP.
|
||||
|
||||
tcp_reordering - INTEGER
|
||||
Maximal reordering of packets in a TCP stream.
|
||||
tcp_tso_win_divisor - INTEGER
|
||||
This allows control over what percentage of the congestion window
|
||||
can be consumed by a single TSO frame.
|
||||
The setting of this parameter is a choice between burstiness and
|
||||
building larger TSO frames.
|
||||
Default: 3
|
||||
|
||||
tcp_retrans_collapse - BOOLEAN
|
||||
Bug-to-bug compatibility with some broken printers.
|
||||
On retransmit try to send bigger packets to work around bugs in
|
||||
certain TCP stacks.
|
||||
tcp_tw_recycle - BOOLEAN
|
||||
Enable fast recycling TIME-WAIT sockets. Default value is 0.
|
||||
It should not be changed without advice/request of technical
|
||||
experts.
|
||||
|
||||
tcp_tw_reuse - BOOLEAN
|
||||
Allow to reuse TIME-WAIT sockets for new connections when it is
|
||||
safe from protocol viewpoint. Default value is 0.
|
||||
It should not be changed without advice/request of technical
|
||||
experts.
|
||||
|
||||
tcp_window_scaling - BOOLEAN
|
||||
Enable window scaling as defined in RFC1323.
|
||||
|
||||
tcp_wmem - vector of 3 INTEGERs: min, default, max
|
||||
min: Amount of memory reserved for send buffers for TCP socket.
|
||||
|
|
@ -282,85 +380,6 @@ tcp_wmem - vector of 3 INTEGERs: min, default, max
|
|||
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
|
||||
Default: 128K
|
||||
|
||||
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
||||
min: Minimal size of receive buffer used by TCP sockets.
|
||||
It is guaranteed to each TCP socket, even under moderate memory
|
||||
pressure.
|
||||
Default: 8K
|
||||
|
||||
default: default size of receive buffer used by TCP sockets.
|
||||
This value overrides net.core.rmem_default used by other protocols.
|
||||
Default: 87380 bytes. This value results in window of 65535 with
|
||||
default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit
|
||||
less for default tcp_app_win. See below about these variables.
|
||||
|
||||
max: maximal size of receive buffer allowed for automatically
|
||||
selected receiver buffers for TCP socket. This value does not override
|
||||
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
|
||||
Default: 87380*2 bytes.
|
||||
|
||||
tcp_mem - vector of 3 INTEGERs: min, pressure, max
|
||||
min: below this number of pages TCP is not bothered about its
|
||||
memory appetite.
|
||||
|
||||
pressure: when amount of memory allocated by TCP exceeds this number
|
||||
of pages, TCP moderates its memory consumption and enters memory
|
||||
pressure mode, which is exited when memory consumption falls
|
||||
under "min".
|
||||
|
||||
max: number of pages allowed for queueing by all TCP sockets.
|
||||
|
||||
Defaults are calculated at boot time from amount of available
|
||||
memory.
|
||||
|
||||
tcp_app_win - INTEGER
|
||||
Reserve max(window/2^tcp_app_win, mss) of window for application
|
||||
buffer. Value 0 is special, it means that nothing is reserved.
|
||||
Default: 31
|
||||
|
||||
tcp_adv_win_scale - INTEGER
|
||||
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
||||
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
||||
if it is <= 0.
|
||||
Default: 2
|
||||
|
||||
tcp_rfc1337 - BOOLEAN
|
||||
If set, the TCP stack behaves conforming to RFC1337. If unset,
|
||||
we are not conforming to RFC, but prevent TCP TIME_WAIT
|
||||
assassination.
|
||||
Default: 0
|
||||
|
||||
tcp_low_latency - BOOLEAN
|
||||
If set, the TCP stack makes decisions that prefer lower
|
||||
latency as opposed to higher throughput. By default, this
|
||||
option is not set meaning that higher throughput is preferred.
|
||||
An example of an application where this default should be
|
||||
changed would be a Beowulf compute cluster.
|
||||
Default: 0
|
||||
|
||||
tcp_tso_win_divisor - INTEGER
|
||||
This allows control over what percentage of the congestion window
|
||||
can be consumed by a single TSO frame.
|
||||
The setting of this parameter is a choice between burstiness and
|
||||
building larger TSO frames.
|
||||
Default: 3
|
||||
|
||||
tcp_frto - BOOLEAN
|
||||
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
|
||||
timeouts. It is particularly beneficial in wireless environments
|
||||
where packet loss is typically due to random radio interference
|
||||
rather than intermediate router congestion.
|
||||
|
||||
tcp_congestion_control - STRING
|
||||
Set the congestion control algorithm to be used for new
|
||||
connections. The algorithm "reno" is always available, but
|
||||
additional choices may be available based on kernel configuration.
|
||||
|
||||
somaxconn - INTEGER
|
||||
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
|
||||
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
|
||||
for TCP sockets.
|
||||
|
||||
tcp_workaround_signed_windows - BOOLEAN
|
||||
If set, assume no receipt of a window scaling option means the
|
||||
remote TCP is broken and treats the window as a signed quantity.
|
||||
|
|
@ -368,13 +387,6 @@ tcp_workaround_signed_windows - BOOLEAN
|
|||
not receive a window scaling option from them.
|
||||
Default: 0
|
||||
|
||||
tcp_slow_start_after_idle - BOOLEAN
|
||||
If set, provide RFC2861 behavior and time out the congestion
|
||||
window after an idle period. An idle period is defined at
|
||||
the current RTO. If unset, the congestion window will not
|
||||
be timed out after an idle period.
|
||||
Default: 1
|
||||
|
||||
CIPSOv4 Variables:
|
||||
|
||||
cipso_cache_enable - BOOLEAN
|
||||
|
|
@ -974,4 +986,3 @@ no_cong_thresh FIXME
|
|||
slot_timeout FIXME
|
||||
warn_noreply_time FIXME
|
||||
|
||||
$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Installation
|
|||
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||
size and number of buffers are set as following:
|
||||
|
||||
Totol Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
RAM size size size size size cnt cnt
|
||||
-------- ------ ------ ------ ------ ------ ------
|
||||
128K 64K 64K 10K 10K 6 6
|
||||
|
|
|
|||
|
|
@ -284,7 +284,7 @@ the necessary memory, so normally limits can be reached.
|
|||
-------------------
|
||||
|
||||
If you check the source code you will see that what I draw here as a frame
|
||||
is not only the link level frame. At the begining of each frame there is a
|
||||
is not only the link level frame. At the beginning of each frame there is a
|
||||
header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
|
||||
meta information like timestamp. So what we draw here a frame it's really
|
||||
the following (from include/linux/if_packet.h):
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
-------
|
||||
PHY Abstraction Layer
|
||||
(Updated 2005-07-21)
|
||||
(Updated 2006-11-30)
|
||||
|
||||
Purpose
|
||||
|
||||
|
|
@ -97,11 +97,12 @@ Letting the PHY Abstraction Layer do Everything
|
|||
|
||||
Next, you need to know the device name of the PHY connected to this device.
|
||||
The name will look something like, "phy0:0", where the first number is the
|
||||
bus id, and the second is the PHY's address on that bus.
|
||||
bus id, and the second is the PHY's address on that bus. Typically,
|
||||
the bus is responsible for making its ID unique.
|
||||
|
||||
Now, to connect, just call this function:
|
||||
|
||||
phydev = phy_connect(dev, phy_name, &adjust_link, flags);
|
||||
phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
|
||||
|
||||
phydev is a pointer to the phy_device structure which represents the PHY. If
|
||||
phy_connect is successful, it will return the pointer. dev, here, is the
|
||||
|
|
@ -115,6 +116,10 @@ Letting the PHY Abstraction Layer do Everything
|
|||
This is useful if the system has put hardware restrictions on
|
||||
the PHY/controller, of which the PHY needs to be aware.
|
||||
|
||||
interface is a u32 which specifies the connection type used
|
||||
between the controller and the PHY. Examples are GMII, MII,
|
||||
RGMII, and SGMII. For a full list, see include/linux/phy.h
|
||||
|
||||
Now just make sure that phydev->supported and phydev->advertising have any
|
||||
values pruned from them which don't make sense for your controller (a 10/100
|
||||
controller may be connected to a gigabit capable PHY, so you would need to
|
||||
|
|
@ -191,7 +196,7 @@ Doing it all yourself
|
|||
start, or disables then frees them for stop.
|
||||
|
||||
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
|
||||
u32 flags);
|
||||
u32 flags, phy_interface_t interface);
|
||||
|
||||
Attaches a network device to a particular PHY, binding the PHY to a generic
|
||||
driver if none was found during bus initialization. Passes in
|
||||
|
|
|
|||
|
|
@ -63,8 +63,8 @@ Current:
|
|||
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
||||
763292pps 390Mb/sec (390805504bps) errors: 39664
|
||||
|
||||
Confguring threads and devices
|
||||
==============================
|
||||
Configuring threads and devices
|
||||
================================
|
||||
This is done via the /proc interface easiest done via pgset in the scripts
|
||||
|
||||
Examples:
|
||||
|
|
@ -116,7 +116,7 @@ Examples:
|
|||
there must be no spaces between the
|
||||
arguments. Leading zeros are required.
|
||||
Do not set the bottom of stack bit,
|
||||
thats done automatically. If you do
|
||||
that's done automatically. If you do
|
||||
set the bottom of stack bit, that
|
||||
indicates that you want to randomly
|
||||
generate that address and the flag
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ up into 3 parts because of the length of the line):
|
|||
|
||||
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
|
||||
| | | | | | | | | |--> slow start size threshold,
|
||||
| | | | | | | | | or -1 if the treshold
|
||||
| | | | | | | | | or -1 if the threshold
|
||||
| | | | | | | | | is >= 0xFFFF
|
||||
| | | | | | | | |----> sending congestion window
|
||||
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
||||
|
|
|
|||
|
|
@ -346,7 +346,7 @@ Possible modes:
|
|||
depending on the load of the system. If the driver detects that the
|
||||
system load is too high, the driver tries to shield the system against
|
||||
too much network load by enabling interrupt moderation. If - at a later
|
||||
time - the CPU utilizaton decreases again (or if the network load is
|
||||
time - the CPU utilization decreases again (or if the network load is
|
||||
negligible) the interrupt moderation will automatically be disabled.
|
||||
|
||||
Interrupt moderation should be used when the driver has to handle one or more
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ comx0/boardnum - board number of the SliceCom in the PC (using the 'natural'
|
|||
|
||||
Though the options below are to be set on a single interface, they apply to the
|
||||
whole board. The restriction, to use them on 'UP' interfaces, is because the
|
||||
command sequence below could lead to unpredicable results.
|
||||
command sequence below could lead to unpredictable results.
|
||||
|
||||
# echo 0 >boardnum
|
||||
# echo internal >clock_source
|
||||
|
|
|
|||
|
|
@ -0,0 +1,281 @@
|
|||
===========================================================================
|
||||
The UDP-Lite protocol (RFC 3828)
|
||||
===========================================================================
|
||||
|
||||
|
||||
UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
|
||||
is a variable-length checksum. This has advantages for transport of multimedia
|
||||
(video, VoIP) over wireless networks, as partly damaged packets can still be
|
||||
fed into the codec instead of being discarded due to a failed checksum test.
|
||||
|
||||
This file briefly describes the existing kernel support and the socket API.
|
||||
For in-depth information, you can consult:
|
||||
|
||||
o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
|
||||
Fom here you can also download some example application source code.
|
||||
|
||||
o The UDP-Lite HOWTO on
|
||||
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
|
||||
|
||||
o The Wireshark UDP-Lite WiKi (with capture files):
|
||||
http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
|
||||
|
||||
o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
|
||||
|
||||
|
||||
I) APPLICATIONS
|
||||
|
||||
Several applications have been ported successfully to UDP-Lite. Ethereal
|
||||
(now called wireshark) has UDP-Litev4/v6 support by default. The tarball on
|
||||
|
||||
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
|
||||
|
||||
has source code for several v4/v6 client-server and network testing examples.
|
||||
|
||||
Porting applications to UDP-Lite is straightforward: only socket level and
|
||||
IPPROTO need to be changed; senders additionally set the checksum coverage
|
||||
length (default = header length = 8). Details are in the next section.
|
||||
|
||||
|
||||
II) PROGRAMMING API
|
||||
|
||||
UDP-Lite provides a connectionless, unreliable datagram service and hence
|
||||
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
|
||||
very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
|
||||
call so that the statement looks like:
|
||||
|
||||
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
|
||||
|
||||
or, respectively,
|
||||
|
||||
s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
|
||||
|
||||
With just the above change you are able to run UDP-Lite services or connect
|
||||
to UDP-Lite servers. The kernel will assume that you are not interested in
|
||||
using partial checksum coverage and so emulate UDP mode (full coverage).
|
||||
|
||||
To make use of the partial checksum coverage facilities requires setting a
|
||||
single socket option, which takes an integer specifying the coverage length:
|
||||
|
||||
* Sender checksum coverage: UDPLITE_SEND_CSCOV
|
||||
|
||||
For example,
|
||||
|
||||
int val = 20;
|
||||
setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
|
||||
|
||||
sets the checksum coverage length to 20 bytes (12b data + 8b header).
|
||||
Of each packet only the first 20 bytes (plus the pseudo-header) will be
|
||||
checksummed. This is useful for RTP applications which have a 12-byte
|
||||
base header.
|
||||
|
||||
|
||||
* Receiver checksum coverage: UDPLITE_RECV_CSCOV
|
||||
|
||||
This option is the receiver-side analogue. It is truly optional, i.e. not
|
||||
required to enable traffic with partial checksum coverage. Its function is
|
||||
that of a traffic filter: when enabled, it instructs the kernel to drop
|
||||
all packets which have a coverage _less_ than this value. For example, if
|
||||
RTP and UDP headers are to be protected, a receiver can enforce that only
|
||||
packets with a minimum coverage of 20 are admitted:
|
||||
|
||||
int min = 20;
|
||||
setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
|
||||
|
||||
The calls to getsockopt(2) are analogous. Being an extension and not a stand-
|
||||
alone protocol, all socket options known from UDP can be used in exactly the
|
||||
same manner as before, e.g. UDP_CORK or UDP_ENCAP.
|
||||
|
||||
A detailed discussion of UDP-Lite checksum coverage options is in section IV.
|
||||
|
||||
|
||||
III) HEADER FILES
|
||||
|
||||
The socket API requires support through header files in /usr/include:
|
||||
|
||||
* /usr/include/netinet/in.h
|
||||
to define IPPROTO_UDPLITE
|
||||
|
||||
* /usr/include/netinet/udplite.h
|
||||
for UDP-Lite header fields and protocol constants
|
||||
|
||||
For testing purposes, the following can serve as a `mini' header file:
|
||||
|
||||
#define IPPROTO_UDPLITE 136
|
||||
#define SOL_UDPLITE 136
|
||||
#define UDPLITE_SEND_CSCOV 10
|
||||
#define UDPLITE_RECV_CSCOV 11
|
||||
|
||||
Ready-made header files for various distros are in the UDP-Lite tarball.
|
||||
|
||||
|
||||
IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS
|
||||
|
||||
To enable debugging messages, the log level need to be set to 8, as most
|
||||
messages use the KERN_DEBUG level (7).
|
||||
|
||||
1) Sender Socket Options
|
||||
|
||||
If the sender specifies a value of 0 as coverage length, the module
|
||||
assumes full coverage, transmits a packet with coverage length of 0
|
||||
and according checksum. If the sender specifies a coverage < 8 and
|
||||
different from 0, the kernel assumes 8 as default value. Finally,
|
||||
if the specified coverage length exceeds the packet length, the packet
|
||||
length is used instead as coverage length.
|
||||
|
||||
2) Receiver Socket Options
|
||||
|
||||
The receiver specifies the minimum value of the coverage length it
|
||||
is willing to accept. A value of 0 here indicates that the receiver
|
||||
always wants the whole of the packet covered. In this case, all
|
||||
partially covered packets are dropped and an error is logged.
|
||||
|
||||
It is not possible to specify illegal values (<0 and <8); in these
|
||||
cases the default of 8 is assumed.
|
||||
|
||||
All packets arriving with a coverage value less than the specified
|
||||
threshold are discarded, these events are also logged.
|
||||
|
||||
3) Disabling the Checksum Computation
|
||||
|
||||
On both sender and receiver, checksumming will always be performed
|
||||
and can not be disabled using SO_NO_CHECK. Thus
|
||||
|
||||
setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
|
||||
|
||||
will always will be ignored, while the value of
|
||||
|
||||
getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
|
||||
|
||||
is meaningless (as in TCP). Packets with a zero checksum field are
|
||||
illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.
|
||||
|
||||
4) Fragmentation
|
||||
|
||||
The checksum computation respects both buffersize and MTU. The size
|
||||
of UDP-Lite packets is determined by the size of the send buffer. The
|
||||
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
|
||||
in include/net/sock.h), the default value is configurable as
|
||||
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
|
||||
option. The maximum upper bound for the send buffer is determined
|
||||
by net.core.wmem_max.
|
||||
|
||||
Given a payload size larger than the send buffer size, UDP-Lite will
|
||||
split the payload into several individual packets, filling up the
|
||||
send buffer size in each case.
|
||||
|
||||
The precise value also depends on the interface MTU. The interface MTU,
|
||||
in turn, may trigger IP fragmentation. In this case, the generated
|
||||
UDP-Lite packet is split into several IP packets, of which only the
|
||||
first one contains the L4 header.
|
||||
|
||||
The send buffer size has implications on the checksum coverage length.
|
||||
Consider the following example:
|
||||
|
||||
Payload: 1536 bytes Send Buffer: 1024 bytes
|
||||
MTU: 1500 bytes Coverage Length: 856 bytes
|
||||
|
||||
UDP-Lite will ship the 1536 bytes in two separate packets:
|
||||
|
||||
Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
|
||||
Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
|
||||
|
||||
The coverage packet covers the UDP-Lite header and 848 bytes of the
|
||||
payload in the first packet, the second packet is fully covered. Note
|
||||
that for the second packet, the coverage length exceeds the packet
|
||||
length. The kernel always re-adjusts the coverage length to the packet
|
||||
length in such cases.
|
||||
|
||||
As an example of what happens when one UDP-Lite packet is split into
|
||||
several tiny fragments, consider the following example.
|
||||
|
||||
Payload: 1024 bytes Send buffer size: 1024 bytes
|
||||
MTU: 300 bytes Coverage length: 575 bytes
|
||||
|
||||
+-+-----------+--------------+--------------+--------------+
|
||||
|8| 272 | 280 | 280 | 280 |
|
||||
+-+-----------+--------------+--------------+--------------+
|
||||
280 560 840 1032
|
||||
^
|
||||
*****checksum coverage*************
|
||||
|
||||
The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
|
||||
header). According to the interface MTU, these are split into 4 IP
|
||||
packets (280 byte IP payload + 20 byte IP header). The kernel module
|
||||
sums the contents of the entire first two packets, plus 15 bytes of
|
||||
the last packet before releasing the fragments to the IP module.
|
||||
|
||||
To see the analogous case for IPv6 fragmentation, consider a link
|
||||
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
|
||||
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
|
||||
lengths), only the first fragment needs to be considered. When using
|
||||
larger checksum coverage lengths, each eligible fragment needs to be
|
||||
checksummed. Suppose we have a checksum coverage of 3062. The buffer
|
||||
of 3356 bytes will be split into the following fragments:
|
||||
|
||||
Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
|
||||
Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
|
||||
Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
|
||||
|
||||
The first two fragments have to be checksummed in full, of the last
|
||||
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
|
||||
|
||||
While it is important that such cases are dealt with correctly, they
|
||||
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
|
||||
performance over wireless (or generally noisy) links and thus smaller
|
||||
coverage lenghts are likely to be expected.
|
||||
|
||||
|
||||
V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
|
||||
|
||||
Exceptional and error conditions are logged to syslog at the KERN_DEBUG
|
||||
level. Live statistics about UDP-Lite are available in /proc/net/snmp
|
||||
and can (with newer versions of netstat) be viewed using
|
||||
|
||||
netstat -svu
|
||||
|
||||
This displays UDP-Lite statistics variables, whose meaning is as follows.
|
||||
|
||||
InDatagrams: Total number of received datagrams.
|
||||
|
||||
NoPorts: Number of packets received to an unknown port.
|
||||
These cases are counted separately (not as InErrors).
|
||||
|
||||
InErrors: Number of erroneous UDP-Lite packets. Errors include:
|
||||
* internal socket queue receive errors
|
||||
* packet too short (less than 8 bytes or stated
|
||||
coverage length exceeds received length)
|
||||
* xfrm4_policy_check() returned with error
|
||||
* application has specified larger min. coverage
|
||||
length than that of incoming packet
|
||||
* checksum coverage violated
|
||||
* bad checksum
|
||||
|
||||
OutDatagrams: Total number of sent datagrams.
|
||||
|
||||
These statistics derive from the UDP MIB (RFC 2013).
|
||||
|
||||
|
||||
VI) IPTABLES
|
||||
|
||||
There is packet match support for UDP-Lite as well as support for the LOG target.
|
||||
If you copy and paste the following line into /etc/protcols,
|
||||
|
||||
udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
|
||||
|
||||
then
|
||||
iptables -A INPUT -p udplite -j LOG
|
||||
|
||||
will produce logging output to syslog. Dropping and rejecting packets also works.
|
||||
|
||||
|
||||
VII) MAINTAINER ADDRESS
|
||||
|
||||
The UDP-Lite patch was developed at
|
||||
University of Aberdeen
|
||||
Electronics Research Group
|
||||
Department of Engineering
|
||||
Fraser Noble Building
|
||||
Aberdeen AB24 3UE; UK
|
||||
The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
|
||||
code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.
|
||||
|
|
@ -412,7 +412,7 @@ beta-2.1.4 Jul 2000 o Dynamic interface configuration:
|
|||
|
||||
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
|
||||
o Added the Multi-Port PPP
|
||||
Updated utilites for the Multi-Port PPP.
|
||||
Updated utilities for the Multi-Port PPP.
|
||||
|
||||
2.1.4 Aut 2000
|
||||
o In X25API:
|
||||
|
|
@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000
|
|||
|
||||
o Cpipemon
|
||||
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
|
||||
configuraiton can be performed using cpipemon.
|
||||
configuration can be performed using cpipemon.
|
||||
All systems that cannot run cfgft1 GUI utility should
|
||||
use cpipemon to configure the on board CSU/DSU.
|
||||
|
||||
|
||||
o Keyboard Led Monitor/Debugger
|
||||
- A new utilty /usr/sbin/wpkbdmon uses keyboard leds
|
||||
- A new utility /usr/sbin/wpkbdmon uses keyboard leds
|
||||
to convey operational statistic information of the
|
||||
Sangoma WANPIPE cards.
|
||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
||||
|
|
@ -464,7 +464,7 @@ beta1-2.1.5 Nov 15 2000
|
|||
- Appropriate number of devices are dynamically loaded
|
||||
based on the number of Sangoma cards found.
|
||||
|
||||
Note: The kernel configuraiton option
|
||||
Note: The kernel configuration option
|
||||
CONFIG_WANPIPE_CARDS has been taken out.
|
||||
|
||||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
||||
|
|
|
|||
|
|
@ -47,10 +47,13 @@ aevent_id structure looks like:
|
|||
|
||||
struct xfrm_aevent_id {
|
||||
struct xfrm_usersa_id sa_id;
|
||||
xfrm_address_t saddr;
|
||||
__u32 flags;
|
||||
__u32 reqid;
|
||||
};
|
||||
|
||||
xfrm_usersa_id in this message layout identifies the SA.
|
||||
The unique SA is identified by the combination of xfrm_usersa_id,
|
||||
reqid and saddr.
|
||||
|
||||
flags are used to indicate different things. The possible
|
||||
flags are:
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ static const struct pnp_id pnp_dev_table[] = {
|
|||
Please note that the character 'X' can be used as a wild card in the function
|
||||
portion (last four characters).
|
||||
ex:
|
||||
/* Unkown PnP modems */
|
||||
/* Unknown PnP modems */
|
||||
{ "PNPCXXX", UNKNOWN_DEV },
|
||||
|
||||
Supported PnP card IDs can optionally be defined.
|
||||
|
|
|
|||
|
|
@ -30,6 +30,17 @@ testing). The system will support either 'firmware' or 'platform', and
|
|||
that is known a priori. But, the user may choose 'shutdown' or
|
||||
'reboot' as alternatives.
|
||||
|
||||
Additionally, /sys/power/disk can be used to turn on one of the two testing
|
||||
modes of the suspend-to-disk mechanism: 'testproc' or 'test'. If the
|
||||
suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to
|
||||
/sys/power/state will cause the kernel to disable nonboot CPUs and freeze
|
||||
tasks, wait for 5 seconds, unfreeze tasks and enable nonboot CPUs. If it is
|
||||
in the 'test' mode, writing 'disk' to /sys/power/state will cause the kernel
|
||||
to disable nonboot CPUs and freeze tasks, shrink memory, suspend devices, wait
|
||||
for 5 seconds, resume devices, unfreeze tasks and enable nonboot CPUs. Then,
|
||||
we are able to look in the log messages and work out, for example, which code
|
||||
is being slow and which device drivers are misbehaving.
|
||||
|
||||
Reading from this file will display what the mode is currently set
|
||||
to. Writing to this file will accept one of
|
||||
|
||||
|
|
@ -37,6 +48,8 @@ to. Writing to this file will accept one of
|
|||
'platform'
|
||||
'shutdown'
|
||||
'reboot'
|
||||
'testproc'
|
||||
'test'
|
||||
|
||||
It will only change to 'firmware' or 'platform' if the system supports
|
||||
it.
|
||||
|
|
|
|||
|
|
@ -153,7 +153,7 @@ Description:
|
|||
events, which is implicit if it doesn't even support it in the first
|
||||
place).
|
||||
|
||||
Note that the PMC Register in the device's PM Capabilties has a bitmask
|
||||
Note that the PMC Register in the device's PM Capabilities has a bitmask
|
||||
of the states it supports generating PME# from. D3hot is bit 3 and
|
||||
D3cold is bit 4. So, while a value of 4 as the state may not seem
|
||||
semantically correct, it is.
|
||||
|
|
@ -268,7 +268,7 @@ to wake the system up. (However, it is possible that a device may support
|
|||
some non-standard way of generating a wake event on sleep.)
|
||||
|
||||
Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's
|
||||
PM Capabilties describe what power states the device supports generating a
|
||||
PM Capabilities describe what power states the device supports generating a
|
||||
wake event from:
|
||||
|
||||
+------------------+
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ setup via another operating system for it to use. Despite the
|
|||
inconvenience, this method requires minimal work by the kernel, since
|
||||
the firmware will also handle restoring memory contents on resume.
|
||||
|
||||
If the kernel is responsible for persistantly saving state, a mechanism
|
||||
If the kernel is responsible for persistently saving state, a mechanism
|
||||
called 'swsusp' (Swap Suspend) is used to write memory contents to
|
||||
free swap space. swsusp has some restrictive requirements, but should
|
||||
work in most cases. Some, albeit outdated, documentation can be found
|
||||
|
|
|
|||
|
|
@ -153,7 +153,7 @@ add:
|
|||
|
||||
If the thread is needed for writing the image to storage, you should
|
||||
instead set the PF_NOFREEZE process flag when creating the thread (and
|
||||
be very carefull).
|
||||
be very careful).
|
||||
|
||||
|
||||
Q: What is the difference between "platform", "shutdown" and
|
||||
|
|
|
|||
|
|
@ -33,13 +33,13 @@
|
|||
- Change version 16 format to always align
|
||||
property data to 4 bytes. Since tokens are
|
||||
already aligned, that means no specific
|
||||
required alignement between property size
|
||||
required alignment between property size
|
||||
and property data. The old style variable
|
||||
alignment would make it impossible to do
|
||||
"simple" insertion of properties using
|
||||
memove (thanks Milton for
|
||||
noticing). Updated kernel patch as well
|
||||
- Correct a few more alignement constraints
|
||||
- Correct a few more alignment constraints
|
||||
- Add a chapter about the device-tree
|
||||
compiler and the textural representation of
|
||||
the tree that can be "compiled" by dtc.
|
||||
|
|
@ -854,7 +854,7 @@ address which can extend beyond that limit.
|
|||
console device if any. Typically, if you have serial devices on
|
||||
your board, you may want to put the full path to the one set as
|
||||
the default console in the firmware here, for the kernel to pick
|
||||
it up as it's own default console. If you look at the funciton
|
||||
it up as its own default console. If you look at the function
|
||||
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||
that the kernel tries to find out the default console and has
|
||||
knowledge of various types like 8250 serial ports. You may want
|
||||
|
|
@ -1124,7 +1124,7 @@ should have the following properties:
|
|||
- interrupt-parent : contains the phandle of the interrupt
|
||||
controller which handles interrupts for this device
|
||||
- interrupts : a list of tuples representing the interrupt
|
||||
number and the interrupt sense and level for each interupt
|
||||
number and the interrupt sense and level for each interrupt
|
||||
for this device.
|
||||
|
||||
This information is used by the kernel to build the interrupt table
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ any point:
|
|||
1) the 'head' pointer or an subsequent linked list pointer
|
||||
is not a valid address of a user space word
|
||||
2) the calculated location of the 'lock word' (address plus
|
||||
'offset') is not the valud address of a 32 bit user space
|
||||
'offset') is not the valid address of a 32 bit user space
|
||||
word
|
||||
3) if the list contains more than 1 million (subject to
|
||||
future kernel configuration changes) elements.
|
||||
|
|
|
|||
|
|
@ -181,7 +181,7 @@ for new threads, without the need of another syscall.]
|
|||
So there is virtually zero overhead for tasks not using robust futexes,
|
||||
and even for robust futex users, there is only one extra syscall per
|
||||
thread lifetime, and the cleanup operation, if it happens, is fast and
|
||||
straightforward. The kernel doesnt have any internal distinction between
|
||||
straightforward. The kernel doesn't have any internal distinction between
|
||||
robust and normal futexes.
|
||||
|
||||
If a futex is found to be held at exit time, the kernel sets the
|
||||
|
|
|
|||
|
|
@ -1,12 +1,49 @@
|
|||
|
||||
Real Time Clock Driver for Linux
|
||||
================================
|
||||
Real Time Clock (RTC) Drivers for Linux
|
||||
=======================================
|
||||
|
||||
When Linux developers talk about a "Real Time Clock", they usually mean
|
||||
something that tracks wall clock time and is battery backed so that it
|
||||
works even with system power off. Such clocks will normally not track
|
||||
the local time zone or daylight savings time -- unless they dual boot
|
||||
with MS-Windows -- but will instead be set to Coordinated Universal Time
|
||||
(UTC, formerly "Greenwich Mean Time").
|
||||
|
||||
The newest non-PC hardware tends to just count seconds, like the time(2)
|
||||
system call reports, but RTCs also very commonly represent time using
|
||||
the Gregorian calendar and 24 hour time, as reported by gmtime(3).
|
||||
|
||||
Linux has two largely-compatible userspace RTC API families you may
|
||||
need to know about:
|
||||
|
||||
* /dev/rtc ... is the RTC provided by PC compatible systems,
|
||||
so it's not very portable to non-x86 systems.
|
||||
|
||||
* /dev/rtc0, /dev/rtc1 ... are part of a framework that's
|
||||
supported by a wide variety of RTC chips on all systems.
|
||||
|
||||
Programmers need to understand that the PC/AT functionality is not
|
||||
always available, and some systems can do much more. That is, the
|
||||
RTCs use the same API to make requests in both RTC frameworks (using
|
||||
different filenames of course), but the hardware may not offer the
|
||||
same functionality. For example, not every RTC is hooked up to an
|
||||
IRQ, so they can't all issue alarms; and where standard PC RTCs can
|
||||
only issue an alarm up to 24 hours in the future, other hardware may
|
||||
be able to schedule one any time in the upcoming century.
|
||||
|
||||
|
||||
Old PC/AT-Compatible driver: /dev/rtc
|
||||
--------------------------------------
|
||||
|
||||
All PCs (even Alpha machines) have a Real Time Clock built into them.
|
||||
Usually they are built into the chipset of the computer, but some may
|
||||
actually have a Motorola MC146818 (or clone) on the board. This is the
|
||||
clock that keeps the date and time while your computer is turned off.
|
||||
|
||||
ACPI has standardized that MC146818 functionality, and extended it in
|
||||
a few ways (enabling longer alarm periods, and wake-from-hibernate).
|
||||
That functionality is NOT exposed in the old driver.
|
||||
|
||||
However it can also be used to generate signals from a slow 2Hz to a
|
||||
relatively fast 8192Hz, in increments of powers of two. These signals
|
||||
are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is
|
||||
|
|
@ -63,9 +100,73 @@ Rather than write 50 pages describing the ioctl() and so on, it is
|
|||
perhaps more useful to include a small test program that demonstrates
|
||||
how to use them, and demonstrates the features of the driver. This is
|
||||
probably a lot more useful to people interested in writing applications
|
||||
that will be using this driver.
|
||||
that will be using this driver. See the code at the end of this document.
|
||||
|
||||
(The original /dev/rtc driver was written by Paul Gortmaker.)
|
||||
|
||||
|
||||
New portable "RTC Class" drivers: /dev/rtcN
|
||||
--------------------------------------------
|
||||
|
||||
Because Linux supports many non-ACPI and non-PC platforms, some of which
|
||||
have more than one RTC style clock, it needed a more portable solution
|
||||
than expecting a single battery-backed MC146818 clone on every system.
|
||||
Accordingly, a new "RTC Class" framework has been defined. It offers
|
||||
three different userspace interfaces:
|
||||
|
||||
* /dev/rtcN ... much the same as the older /dev/rtc interface
|
||||
|
||||
* /sys/class/rtc/rtcN ... sysfs attributes support readonly
|
||||
access to some RTC attributes.
|
||||
|
||||
* /proc/driver/rtc ... the first RTC (rtc0) may expose itself
|
||||
using a procfs interface. More information is (currently) shown
|
||||
here than through sysfs.
|
||||
|
||||
The RTC Class framework supports a wide variety of RTCs, ranging from those
|
||||
integrated into embeddable system-on-chip (SOC) processors to discrete chips
|
||||
using I2C, SPI, or some other bus to communicate with the host CPU. There's
|
||||
even support for PC-style RTCs ... including the features exposed on newer PCs
|
||||
through ACPI.
|
||||
|
||||
The new framework also removes the "one RTC per system" restriction. For
|
||||
example, maybe the low-power battery-backed RTC is a discrete I2C chip, but
|
||||
a high functionality RTC is integrated into the SOC. That system might read
|
||||
the system clock from the discrete RTC, but use the integrated one for all
|
||||
other tasks, because of its greater functionality.
|
||||
|
||||
The ioctl() calls supported by /dev/rtc are also supported by the RTC class
|
||||
framework. However, because the chips and systems are not standardized,
|
||||
some PC/AT functionality might not be provided. And in the same way, some
|
||||
newer features -- including those enabled by ACPI -- are exposed by the
|
||||
RTC class framework, but can't be supported by the older driver.
|
||||
|
||||
* RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading
|
||||
time, returning the result as a Gregorian calendar date and 24 hour
|
||||
wall clock time. To be most useful, this time may also be updated.
|
||||
|
||||
* RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC
|
||||
is connected to an IRQ line, it can often issue an alarm IRQ up to
|
||||
24 hours in the future.
|
||||
|
||||
* RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond
|
||||
the next 24 hours use a slightly more powerful API, which supports
|
||||
setting the longer alarm time and enabling its IRQ using a single
|
||||
request (using the same model as EFI firmware).
|
||||
|
||||
* RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
|
||||
also offers update IRQs whenever the "seconds" counter changes.
|
||||
If needed, the RTC framework can emulate this mechanism.
|
||||
|
||||
* RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another
|
||||
feature often accessible with an IRQ line is a periodic IRQ, issued
|
||||
at settable frequencies (usually 2^N Hz).
|
||||
|
||||
In many cases, the RTC alarm can be a system wake event, used to force
|
||||
Linux out of a low power sleep state (or hibernation) back to a fully
|
||||
operational state. For example, a system could enter a deep power saving
|
||||
state until it's time to execute some scheduled tasks.
|
||||
|
||||
Paul Gortmaker
|
||||
|
||||
-------------------- 8< ---------------- 8< -----------------------------
|
||||
|
||||
|
|
@ -83,25 +184,46 @@ that will be using this driver.
|
|||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <linux/rtc.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <sys/time.h>
|
||||
#include <sys/types.h>
|
||||
#include <fcntl.h>
|
||||
#include <unistd.h>
|
||||
#include <stdlib.h>
|
||||
#include <errno.h>
|
||||
|
||||
int main(void) {
|
||||
|
||||
/*
|
||||
* This expects the new RTC class driver framework, working with
|
||||
* clocks that will often not be clones of what the PC-AT had.
|
||||
* Use the command line to specify another RTC if you need one.
|
||||
*/
|
||||
static const char default_rtc[] = "/dev/rtc0";
|
||||
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int i, fd, retval, irqcount = 0;
|
||||
unsigned long tmp, data;
|
||||
struct rtc_time rtc_tm;
|
||||
const char *rtc = default_rtc;
|
||||
|
||||
fd = open ("/dev/rtc", O_RDONLY);
|
||||
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("/dev/rtc");
|
||||
perror(rtc);
|
||||
exit(errno);
|
||||
}
|
||||
|
||||
|
|
@ -110,11 +232,17 @@ fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
|
|||
/* Turn on update interrupts (one per second) */
|
||||
retval = ioctl(fd, RTC_UIE_ON, 0);
|
||||
if (retval == -1) {
|
||||
if (errno == ENOTTY) {
|
||||
fprintf(stderr,
|
||||
"\n...Update IRQs not supported.\n");
|
||||
goto test_READ;
|
||||
}
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
|
||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
|
||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
|
||||
rtc);
|
||||
fflush(stderr);
|
||||
for (i=1; i<6; i++) {
|
||||
/* This read will block */
|
||||
|
|
@ -160,6 +288,7 @@ if (retval == -1) {
|
|||
exit(errno);
|
||||
}
|
||||
|
||||
test_READ:
|
||||
/* Read the RTC time/date */
|
||||
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
|
||||
if (retval == -1) {
|
||||
|
|
@ -186,6 +315,11 @@ if (rtc_tm.tm_hour == 24)
|
|||
|
||||
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
|
||||
if (retval == -1) {
|
||||
if (errno == ENOTTY) {
|
||||
fprintf(stderr,
|
||||
"\n...Alarm IRQs not supported.\n");
|
||||
goto test_PIE;
|
||||
}
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
|
|
@ -225,13 +359,19 @@ if (retval == -1) {
|
|||
exit(errno);
|
||||
}
|
||||
|
||||
test_PIE:
|
||||
/* Read periodic IRQ rate */
|
||||
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
|
||||
if (retval == -1) {
|
||||
/* not all RTCs support periodic IRQs */
|
||||
if (errno == ENOTTY) {
|
||||
fprintf(stderr, "\nNo periodic IRQ support\n");
|
||||
return 0;
|
||||
}
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);
|
||||
fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);
|
||||
|
||||
fprintf(stderr, "Counting 20 interrupts at:");
|
||||
fflush(stderr);
|
||||
|
|
@ -241,6 +381,12 @@ for (tmp=2; tmp<=64; tmp*=2) {
|
|||
|
||||
retval = ioctl(fd, RTC_IRQP_SET, tmp);
|
||||
if (retval == -1) {
|
||||
/* not all RTCs can change their periodic IRQ rate */
|
||||
if (errno == ENOTTY) {
|
||||
fprintf(stderr,
|
||||
"\n...Periodic IRQ rate is fixed\n");
|
||||
goto done;
|
||||
}
|
||||
perror("ioctl");
|
||||
exit(errno);
|
||||
}
|
||||
|
|
@ -275,11 +421,10 @@ for (tmp=2; tmp<=64; tmp*=2) {
|
|||
}
|
||||
}
|
||||
|
||||
done:
|
||||
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 */
|
||||
return 0;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Command line parameters
|
|||
|
||||
When a device is un-ignored, device recognition and sensing is performed and
|
||||
the device driver will be notified if possible, so the device will become
|
||||
available to the system.
|
||||
available to the system. Note that un-ignoring is performed asynchronously.
|
||||
|
||||
You can also add ranges of devices to be ignored by piping to
|
||||
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
|
||||
|
|
|
|||
|
|
@ -174,14 +174,10 @@ read_dev_chars() - Read Device Characteristics
|
|||
|
||||
This routine returns the characteristics for the device specified.
|
||||
|
||||
The function is meant to be called with an irq handler in place; that is,
|
||||
The function is meant to be called with the device already enabled; that is,
|
||||
at earliest during set_online() processing.
|
||||
|
||||
While the request is processed synchronously, the device interrupt
|
||||
handler is called for final ending status. In case of error situations the
|
||||
interrupt handler may recover appropriately. The device irq handler can
|
||||
recognize the corresponding interrupts by the interruption parameter be
|
||||
0x00524443. The ccw_device must not be locked prior to calling read_dev_chars().
|
||||
The ccw_device must not be locked prior to calling read_dev_chars().
|
||||
|
||||
The function may be called enabled or disabled.
|
||||
|
||||
|
|
@ -410,26 +406,7 @@ individual flag meanings.
|
|||
|
||||
Usage Notes :
|
||||
|
||||
Prior to call ccw_device_start() the device driver must assure disabled state,
|
||||
i.e. the I/O mask value in the PSW must be disabled. This can be accomplished
|
||||
by calling local_save_flags( flags). The current PSW flags are preserved and
|
||||
can be restored by local_irq_restore( flags) at a later time.
|
||||
|
||||
If the device driver violates this rule while running in a uni-processor
|
||||
environment an interrupt might be presented prior to the ccw_device_start()
|
||||
routine returning to the device driver main path. In this case we will end in a
|
||||
deadlock situation as the interrupt handler will try to obtain the irq
|
||||
lock the device driver still owns (see below) !
|
||||
|
||||
The driver must assure to hold the device specific lock. This can be
|
||||
accomplished by
|
||||
|
||||
(i) spin_lock(get_ccwdev_lock(cdev)), or
|
||||
(ii) spin_lock_irqsave(get_ccwdev_lock(cdev), flags)
|
||||
|
||||
Option (i) should be used if the calling routine is running disabled for
|
||||
I/O interrupts (see above) already. Option (ii) obtains the device gate und
|
||||
puts the CPU into I/O disabled state by preserving the current PSW flags.
|
||||
ccw_device_start() must be called disabled and with the ccw device lock held.
|
||||
|
||||
The device driver is allowed to issue the next ccw_device_start() call from
|
||||
within its interrupt handler already. It is not required to schedule a
|
||||
|
|
@ -488,7 +465,7 @@ int ccw_device_resume(struct ccw_device *cdev);
|
|||
|
||||
cdev - ccw_device the resume operation is requested for
|
||||
|
||||
The resume_IO() function returns:
|
||||
The ccw_device_resume() function returns:
|
||||
|
||||
0 - suspended channel program is resumed
|
||||
-EBUSY - status pending
|
||||
|
|
@ -507,6 +484,8 @@ a long-running channel program or the device might require to initially issue
|
|||
a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
|
||||
command is provided.
|
||||
|
||||
ccw_device_halt() must be called disabled and with the ccw device lock held.
|
||||
|
||||
int ccw_device_halt(struct ccw_device *cdev,
|
||||
unsigned long intparm);
|
||||
|
||||
|
|
@ -517,7 +496,7 @@ intparm : interruption parameter; value is only used if no I/O
|
|||
|
||||
The ccw_device_halt() function returns :
|
||||
|
||||
0 - successful completion or request successfully initiated
|
||||
0 - request successfully initiated
|
||||
-EBUSY - the device is currently busy, or status pending.
|
||||
-ENODEV - cdev invalid.
|
||||
-EINVAL - The device is not operational or the ccw device is not online.
|
||||
|
|
@ -533,6 +512,23 @@ can then perform an appropriate action. Prior to interrupt of an outstanding
|
|||
read to a network device (with or without PCI flag) a ccw_device_halt()
|
||||
is required to end the pending operation.
|
||||
|
||||
ccw_device_clear() - Terminage I/O Request Processing
|
||||
|
||||
In order to terminate all I/O processing at the subchannel, the clear subchannel
|
||||
(CSCH) command is used. It can be issued via ccw_device_clear().
|
||||
|
||||
ccw_device_clear() must be called disabled and with the ccw device lock held.
|
||||
|
||||
int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm);
|
||||
|
||||
cdev: ccw_device the clear operation is requested for
|
||||
intparm: interruption parameter (see ccw_device_halt())
|
||||
|
||||
The ccw_device_clear() function returns:
|
||||
|
||||
0 - request successfully initiated
|
||||
-ENODEV - cdev invalid
|
||||
-EINVAL - The device is not operational or the ccw device is not online.
|
||||
|
||||
Miscellaneous Support Routines
|
||||
|
||||
|
|
|
|||
|
|
@ -75,8 +75,8 @@ name of the respective module is given in square brackets.
|
|||
|
||||
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||
- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Tripple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
|
||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
||||
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
||||
|
|
|
|||
|
|
@ -239,6 +239,9 @@ status - Can be 'online' or 'offline'.
|
|||
|
||||
type - The physical type of the channel path.
|
||||
|
||||
shared - Whether the channel path is shared.
|
||||
|
||||
cmg - The channel measurement group.
|
||||
|
||||
3. System devices
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ The following information is available in this file:
|
|||
- Correct a reference to free'ed memory during controller
|
||||
shutdown.
|
||||
- Reset the bus on an SE->LVD change. This is required
|
||||
to reset our transcievers.
|
||||
to reset our transceivers.
|
||||
|
||||
1.3.5 (March 24th, 2003)
|
||||
- Fix a few register window mode bugs.
|
||||
|
|
@ -169,7 +169,7 @@ The following information is available in this file:
|
|||
1.3.0 (January 21st, 2003)
|
||||
- Full regression testing for all U320 products completed.
|
||||
- Added abort and target/lun reset error recovery handler and
|
||||
interrupt coalessing.
|
||||
interrupt coalescing.
|
||||
|
||||
1.2.0 (November 14th, 2002)
|
||||
- Added support for Domain Validation
|
||||
|
|
|
|||
|
|
@ -256,7 +256,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
|||
En/Disable High Byte LVD Termination
|
||||
|
||||
The upper 2 bits that deal with LVD termination only apply to Ultra2
|
||||
controllers. Futhermore, due to the current Ultra2 controller
|
||||
controllers. Furthermore, due to the current Ultra2 controller
|
||||
designs, these bits are tied together such that setting either bit
|
||||
enables both low and high byte LVD termination. It is not possible
|
||||
to only set high or low byte LVD termination in this manner. This is
|
||||
|
|
@ -436,7 +436,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
|||
the commas to periods, insmod won't interpret this as more than one
|
||||
string and write junk into our binary image. I consider it a bug in
|
||||
the insmod program that even if you wrap your string in quotes (quotes
|
||||
that pass the shell mind you and that insmod sees) it still treates
|
||||
that pass the shell mind you and that insmod sees) it still treats
|
||||
a comma inside of those quotes as starting a new variable, resulting
|
||||
in memory scribbles if you don't switch the commas to periods.
|
||||
|
||||
|
|
|
|||
|
|
@ -461,7 +461,7 @@
|
|||
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
|
||||
allows data to be written from the system to the device. It is a
|
||||
necessary step to be allowed to set blocksize of SCSI-tape-drives and
|
||||
the tape-speed, whithout confusing the SCSI-Subsystem.
|
||||
the tape-speed, without confusing the SCSI-Subsystem.
|
||||
2) The recognition of a tape is included in the check_devices routine.
|
||||
This is done by checking for TYPE_TAPE, that is already defined in
|
||||
the kernel-scsi-environment. The markup of a tape is done in the
|
||||
|
|
@ -710,8 +710,8 @@
|
|||
of troubles with some controllers and after I wanted to apply some
|
||||
extensions, it jumped out in the same situation, on my w/cache, as like
|
||||
on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
|
||||
descissive hint to move the code-part out and declare it global. Now,
|
||||
it seems to work by far much better an more stable. Let us see, what
|
||||
decisive hint to move the code-part out and declare it global. Now
|
||||
it seems to work far better and more stable. Let us see what
|
||||
the world thinks of it...
|
||||
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
|
||||
test with a HP drive gave right results, so the problem is vendor-
|
||||
|
|
@ -822,10 +822,10 @@
|
|||
A long period of collecting bugreports from all corners of the world
|
||||
now lead to the following corrections to the code:
|
||||
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
||||
was, that it is possible to disbale Fast-SCSI for the external bus.
|
||||
The feature-control command, where this crash appeared regularly tried
|
||||
was that it is possible to disable Fast-SCSI for the external bus.
|
||||
The feature-control command, where this crash appeared regularly, tried
|
||||
to set the maximum speed of 10MHz synchronous transfer speed and that
|
||||
reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now,
|
||||
reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
|
||||
the feature-command probes down from maximum speed until the adapter
|
||||
stops to complain, which is at the same time the maximum possible
|
||||
speed selected in the reference program. So, F/W external can run at
|
||||
|
|
@ -920,7 +920,7 @@
|
|||
completed in such a way, that they are now completely conform to the
|
||||
demands in the technical description of IBM. Main candidates were the
|
||||
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
|
||||
be tranferred by bypassing the internal command buffer of the adapter
|
||||
be transferred by bypassing the internal command buffer of the adapter
|
||||
or else the response can be a random result. GET_POS_INFO would be more
|
||||
safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
|
||||
is not allowed by the technical references of IBM. (Sorry, folks, the
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98
|
|||
UPDATE NEWS: version 1.31 - 6 Jul 97
|
||||
|
||||
Fixed a bug that caused incorrect SCSI status bytes to be
|
||||
returned from commands sent to LUN's greater than 0. This
|
||||
returned from commands sent to LUNs greater than 0. This
|
||||
means that CDROM changers work now! Fixed a bug in the
|
||||
handling of command-line arguments when loaded as a module.
|
||||
Also put all the header data in in2000.h where it belongs.
|
||||
|
|
|
|||
|
|
@ -393,7 +393,7 @@ struct sas_task {
|
|||
task_proto -- _one_ of enum sas_proto
|
||||
scatter -- pointer to scatter gather list array
|
||||
num_scatter -- number of elements in scatter
|
||||
total_xfer_len -- total number of bytes expected to be transfered
|
||||
total_xfer_len -- total number of bytes expected to be transferred
|
||||
data_dir -- PCI_DMA_...
|
||||
task_done -- callback when the task has finished execution
|
||||
};
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server:
|
|||
|
||||
ftp://ftp.symbios.com/
|
||||
|
||||
Usefull SCSI tools written by Eric Youngdale are available at tsx-11:
|
||||
Useful SCSI tools written by Eric Youngdale are available at tsx-11:
|
||||
|
||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
|
||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ If the module finds the changer, it prints some messages about the
|
|||
device [ try "dmesg" if you don't see anything ] and should show up in
|
||||
/proc/devices. If not.... some changers use ID ? / LUN 0 for the
|
||||
device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
|
||||
look for LUN's other than 0 as default, becauce there are to many
|
||||
look for LUNs other than 0 as default, because there are too many
|
||||
broken devices. So you can try:
|
||||
|
||||
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
|
||||
|
|
@ -107,7 +107,7 @@ because the kernel will translate the error codes into human-readable
|
|||
strings then.
|
||||
|
||||
You can display these messages with the dmesg command (or check the
|
||||
logfiles). If you email me some question becauce of a problem with the
|
||||
logfiles). If you email me some question because of a problem with the
|
||||
driver, please include these messages.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ with the command.
|
|||
|
||||
- otherwise
|
||||
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
|
||||
[1-3] for details of this funciton.
|
||||
[1-3] for details of this function.
|
||||
|
||||
|
||||
[1-2-2] Completing a scmd w/ timeout
|
||||
|
|
|
|||
|
|
@ -261,7 +261,7 @@ pairs are separated with a comma (no spaces allowed). A colon can be
|
|||
used instead of the equal mark. The definition is prepended by the
|
||||
string st=. Here is an example:
|
||||
|
||||
st=buffer_kbs:64,write_threhold_kbs:60
|
||||
st=buffer_kbs:64,write_threshold_kbs:60
|
||||
|
||||
The following syntax used by the old kernel versions is also supported:
|
||||
|
||||
|
|
|
|||
|
|
@ -609,7 +609,7 @@ appropriate mailing lists or news-groups. Send me a copy in order to
|
|||
be sure I will receive it. Obviously, a bug in the driver code is
|
||||
possible.
|
||||
|
||||
My cyrrent email address: Gerard Roudier <groudier@free.fr>
|
||||
My current email address: Gerard Roudier <groudier@free.fr>
|
||||
|
||||
Allowing disconnections is important if you use several devices on
|
||||
your SCSI bus but often causes problems with buggy devices.
|
||||
|
|
|
|||
|
|
@ -942,13 +942,13 @@ replicas continue to be exactly same.
|
|||
->mnt_slave
|
||||
->mnt_master
|
||||
|
||||
->mnt_share links togather all the mount to/from which this vfsmount
|
||||
->mnt_share links together all the mount to/from which this vfsmount
|
||||
send/receives propagation events.
|
||||
|
||||
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
||||
to.
|
||||
|
||||
->mnt_slave links togather all the slaves that its master vfsmount
|
||||
->mnt_slave links together all the slaves that its master vfsmount
|
||||
propagates to.
|
||||
|
||||
->mnt_master points to the master vfsmount from which this vfsmount
|
||||
|
|
|
|||
|
|
@ -753,7 +753,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
|
||||
single_cmd - Use single immediate commands to communicate with
|
||||
codecs (for debugging only)
|
||||
disable_msi - Disable Message Signaled Interrupt (MSI)
|
||||
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
|
||||
|
||||
This module supports one card and autoprobe.
|
||||
|
||||
|
|
@ -955,7 +955,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
|
||||
phase88, mediastation
|
||||
omni - Omni I/O support for MidiMan M-Audio Delta44/66
|
||||
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
|
||||
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transceiver)
|
||||
in msec resolution, default value is 500 (0.5 sec)
|
||||
|
||||
This module supports multiple cards and autoprobe. Note: The consumer part
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This is based on SB-Live-mixer.txt.
|
|||
|
||||
The EMU10K2 chips have a DSP part which can be programmed to support
|
||||
various ways of sample processing, which is described here.
|
||||
(This acticle does not deal with the overall functionality of the
|
||||
(This article does not deal with the overall functionality of the
|
||||
EMU10K2 chips. See the manuals section for further details.)
|
||||
|
||||
The ALSA driver programs this portion of chip by default code
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
The EMU10K1 chips have a DSP part which can be programmed to support
|
||||
various ways of sample processing, which is described here.
|
||||
(This acticle does not deal with the overall functionality of the
|
||||
(This article does not deal with the overall functionality of the
|
||||
EMU10K1 chips. See the manuals section for further details.)
|
||||
|
||||
The ALSA driver programs this portion of chip by default code
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Review cycle:
|
|||
Contact the kernel security team for more details on this procedure.
|
||||
|
||||
|
||||
Review committe:
|
||||
Review committee:
|
||||
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are
|
|||
readable by root only. This allows the end user to remove
|
||||
such a dump but not access it directly. For security reasons
|
||||
core dumps in this mode will not overwrite one another or
|
||||
other files. This mode is appropriate when adminstrators are
|
||||
other files. This mode is appropriate when administrators are
|
||||
attempting to debug problems in a normal environment.
|
||||
|
||||
==============================================================
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ the high water marks for each per cpu page list.
|
|||
|
||||
zone_reclaim_mode:
|
||||
|
||||
Zone_reclaim_mode allows to set more or less agressive approaches to
|
||||
Zone_reclaim_mode allows someone to set more or less aggressive approaches to
|
||||
reclaim memory when a zone runs out of memory. If it is set to zero then no
|
||||
zone reclaim occurs. Allocations will be satisfied from other zones / nodes
|
||||
in the system.
|
||||
|
|
|
|||
|
|
@ -1477,7 +1477,7 @@
|
|||
|
||||
|
||||
|
||||
Making it world-writeable looks bad, but it seems not to be
|
||||
Making it world-writable looks bad, but it seems not to be
|
||||
exploitable as a security hole. However, it does allow anyone to cre-
|
||||
ate useless tap devices (useless because they can't configure them),
|
||||
which is a DOS attack. A somewhat more secure alternative would to be
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big
|
|||
examples for this are power devices (especially uninterruptable power
|
||||
supplies) and monitor control on higher end monitors.
|
||||
|
||||
To support these disparite requirements, the Linux USB system provides
|
||||
To support these disparate requirements, the Linux USB system provides
|
||||
HID events to two separate interfaces:
|
||||
* the input subsystem, which converts HID events into normal input
|
||||
device interfaces (such as keyboard, mouse and joystick) and a
|
||||
|
|
|
|||
|
|
@ -24,10 +24,10 @@ are in no way responsible for any damage that may occur, no matter how
|
|||
inconsequential.
|
||||
|
||||
It seems that the Rio has a problem when sending .mp3 with low batteries.
|
||||
I suggest when the batteries are low and want to transfer stuff that you
|
||||
I suggest when the batteries are low and you want to transfer stuff that you
|
||||
replace it with a fresh one. In my case, what happened is I lost two 16kb
|
||||
blocks (they are no longer usable to store information to it). But I don't
|
||||
know if thats normal or not. It could simply be a problem with the flash
|
||||
know if that's normal or not; it could simply be a problem with the flash
|
||||
memory.
|
||||
|
||||
In an extreme case, I left my Rio playing overnight and the batteries wore
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче