Kernel/linux-next
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git synced 2025-01-10 07:50:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of /pub/scm/linux/kernel/git/torvalds/linux-2.6

Browse Source 
Conflicts:

	fs/cifs/export.c
This commit is contained in:
Steve French 2007-07-19 00:38:57 +00:00
commit 1ff8392c32
4638 changed files with 244246 additions and 237070 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -45,3 +45,6 @@ series
# cscope files
cscope.*
*.orig
*.rej

142
Documentation/00-INDEX
View File

@ -12,6 +12,8 @@ Following translations are available on the WWW:
00-INDEX
- this file.
ABI/
- info on kernel <-> userspace ABI and relative interface stability.
BUG-HUNTING
- brute force method of doing binary search of patches to find bug.
Changes
@ -25,37 +27,57 @@ DMA-mapping.txt
DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
- The process and procedures of how to do Linux kernel development.
- the process and procedures of how to do Linux kernel development.
IO-mapping.txt
- how to access I/O mapped memory from within device drivers.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ.txt
- description of what an IRQ is.
ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
README.cycladesZ
- info on Cyclades-Z firmware loading.
SAK.txt
- info on Secure Attention Keys.
SecurityBugs
- procedure for reporting security bugs found in the kernel.
SubmitChecklist
- Linux kernel patch submission checklist.
SubmittingDrivers
- procedure to get a new driver source included into the kernel tree.
SubmittingPatches
- procedure to get a source patch included into the kernel tree.
VGA-softcursor.txt
- how to change your VGA cursor from a blinking underscore.
accounting/
- documentation on accounting and taskstats.
aoe/
- description of AoE (ATA over Ethernet) along with config examples.
applying-patches.txt
- description of various trees and how to apply their patches.
arm/
- directory with info about Linux on the ARM architecture.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
- misc. LCD driver documentation (cfag12864b, ks0108).
basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
binfmt_misc.txt
- info on the kernel support for extra binary formats.
blackfin/
- directory with documentation for the Blackfin arch.
block/
- info on the Block I/O (BIO) layer.
cachetlb.txt
@ -68,16 +90,32 @@ cli-sti-removal.txt
- cli()/sti() removal guide.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
- documentation on Linux console drivers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
cpu-freq/
- info on CPU frequency and voltage scaling.
cpu-hotplug.txt
- document describing CPU hotplug support in the Linux kernel.
cpu-load.txt
- document describing how CPU load statistics are collected.
cpusets.txt
- documents the cpusets feature; assign CPUs and Mem to a set of tasks.
cputopology.txt
- documentation on how CPU topology info is exported via sysfs.
cris/
- directory with info about Linux on CRIS architecture.
crypto/
- directory with info on the Crypto API.
dcdbas.txt
- information on the Dell Systems Management Base Driver.
debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
dell_rbu.txt
- document demonstrating the use of the Dell Remote BIOS Update driver.
device-mapper/
- directory with info on Device Mapper.
devices.txt
@ -86,32 +124,52 @@ digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
dnotify.txt
- info about directory notification in Linux.
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
- directory with info about Linux driver model.
drivers/
- directory with driver documentation (currently only EDAC).
dvb/
- info on Linux Digital Video Broadcast (DVB) subsystem.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
ecryptfs.txt
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
eisa.txt
- info on EISA bus support.
exception.txt
- how Linux v2.2 handles exceptions without verify_area etc.
fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
- directory with info on the frame buffer graphics abstraction layer.
feature-removal-schedule.txt
- list of files and features that are going to be removed.
filesystems/
- directory with info on the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
floppy.txt
- notes and driver options for the floppy disk driver.
fujitsu/
- Fujitsu FR-V Linux documentation.
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hpet.txt
- High Precision Event Timer Driver for Linux.
hrtimer/
- info on the timer_stats debugging facility for timer (ab)use.
hrtimers/
- info on the hrtimers subsystem for high-resolution kernel timers.
hw_random.txt
- info on Linux support for random number generator in i8xx chipsets.
hwmon/
- directory with docs on various hardware monitoring drivers.
i2c/
- directory with info about the I2C bus/protocol (2 wire, kHz speed).
i2o/
@ -122,16 +180,22 @@ ia64/
- directory with info about Linux on Intel 64 bit architecture.
ide.txt
- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
infiniband/
- directory with documents concerning Linux InfiniBand support.
initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/
- directory with documents describing various IOCTL calls.
ioctl-number.txt
- how to implement and register device/driver ioctl calls.
iostats.txt
- info on I/O statistics Linux kernel provides.
irqflags-tracing.txt
- how to use the irq-flags tracing feature.
isapnp.txt
- info on Linux ISA Plug & Play support.
isdn/
@ -140,26 +204,40 @@ java.txt
- info on the in-kernel binary support for Java(tm).
kbuild/
- directory with info about the kernel build process.
kdumpt.txt
- mini HowTo on getting the crash dump code to work.
kdump/
- directory with mini HowTo on getting the crash dump code to work.
kernel-doc-nano-HOWTO.txt
- mini HowTo on generation and location of kernel documentation files.
kernel-docs.txt
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
keys-request-key.txt
- description of the kernel key request service.
keys.txt
- description of the kernel key retention service.
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
- documents the kernel probes debugging feature.
kref.txt
- docs on adding reference counters (krefs) to kernel objects.
laptop-mode.txt
- How to conserve battery power using laptop-mode.
- how to conserve battery power using laptop-mode.
ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
leds-class.txt
- documents LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
locks.txt
- info on file locking implementations, flock() vs. fcntl(), etc.
logo.gif
- Full colour GIF image of Linux logo (penguin).
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- Info on creator of above logo & site to get additional images from.
- info on creator of above logo & site to get additional images from.
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
@ -170,6 +248,8 @@ mca.txt
- info on supporting Micro Channel Architecture (e.g. PS/2) systems.
md.txt
- info on boot arguments for the multiple devices driver.
memory-barriers.txt
- info on Linux kernel memory barriers.
memory.txt
- info on typical Linux memory problems.
mips/
@ -177,9 +257,11 @@ mips/
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
moxa-smartio
- info on installing/using Moxa multiport serial driver.
- file with info on installing/using Moxa multiport serial driver.
mtrr.txt
- how to use PPro Memory Type Range Registers to increase performance.
mutex-design.txt
- info on the generic mutex subsystem.
nbd.txt
- info on a TCP implementation of a network block device.
netlabel/
@ -190,6 +272,8 @@ nfsroot.txt
- short guide on setting up a diskless box with NFS root filesystem.
nmi_watchdog.txt
- info on NMI watchdog for SMP systems.
nommu-mmap.txt
- documentation about no-mmu memory mapping support.
numastat.txt
- info on how to read Numa policy hit/miss statistics in sysfs.
oops-tracing.txt
@ -202,8 +286,16 @@ parport.txt
- how to use the parallel-port driver.
parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pci-error-recovery.txt
- info on PCI error recovery.
pci.txt
- info on the PCI subsystem for device driver authors.
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO.
pcmcia/
- info on the Linux PCMCIA driver.
pi-futex.txt
- documentation on lightweight PI-futexes.
pm.txt
- info on Linux power management support.
pnp.txt
@ -214,18 +306,32 @@ powerpc/
- directory with info on using Linux with the PowerPC.
preempt-locking.txt
- info on locking under a preemptive kernel.
prio_tree.txt
- info on radix-priority-search-tree use for indexing vmas.
ramdisk.txt
- short guide on how to set up and use the RAM disk.
rbtree.txt
- info on what red-black trees are and what they are for.
riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer.
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
- desc. of RT-mutex subsystem with PI (Priority Inheritance) support.
rtc.txt
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
s390/
- directory with info on using Linux on the IBM S390.
sched-arch.txt
- CPU Scheduler implementation hints for architecture specific code.
sched-coding.txt
- reference for various scheduler-related methods in the O(1) scheduler.
sched-design.txt
@ -240,22 +346,32 @@ serial/
- directory with info on the low level serial API.
serial-console.txt
- how to set up Linux with a serial line console as the default.
sgi-ioc4.txt
- description of the SGI IOC4 PCI (multi function) device.
sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
sharedsubtree.txt
- a description of shared subtrees for namespaces.
smart-config.txt
- description of the Smart Config makefile feature.
smp.txt
- a few notes on symmetric multi-processing.
sony-laptop.txt
- Sony Notebook Control Driver (SNC) Readme.
sonypi.txt
- info on Linux Sony Programmable I/O Device support.
sound/
- directory with info on sound card support.
sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
spinlocks.txt
- info on using spinlocks to provide exclusive access in kernel.
stable_api_nonsense.txt
@ -274,24 +390,32 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
thinkpad-acpi.txt
- information on the (IBM and Lenovo) ThinkPad ACPI Extras driver.
time_interpolators.txt
- info on time interpolators.
tipar.txt
- information about Parallel link cable for Texas Instruments handhelds.
tty.txt
- guide to the locking policies of the tty layer.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
uml/
- directory with information about User Mode Linux.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt
- description of the Linux unshare system call.
usb/
- directory with info regarding the Universal Serial Bus.
video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
vm/
- directory with info on the Linux vm code.
voyager.txt
- guide to running Linux on the Voyager architecture.
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
x86_64/

16
Documentation/ABI/removed/raw1394_legacy_isochronous Normal file
View File

@ -0,0 +1,16 @@
What: legacy isochronous ABI of raw1394 (1st generation iso ABI)
Date: June 2007 (scheduled), removed in kernel v2.6.23
Contact: linux1394-devel@lists.sourceforge.net
Description:
The two request types RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN have
been deprecated for quite some time. They are very inefficient as they
come with high interrupt load and several layers of callbacks for each
packet. Because of these deficiencies, the video1394 and dv1394 drivers
and the 3rd-generation isochronous ABI in raw1394 (rawiso) were created.
Users:
libraw1394 users via the long deprecated API raw1394_iso_write,
raw1394_start_iso_write, raw1394_start_iso_rcv, raw1394_stop_iso_rcv
libdc1394, which optionally uses these old libraw1394 calls
alternatively to the more efficient video1394 ABI

13
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -39,3 +39,16 @@ Description:
If you want to suspend a device immediately but leave it
free to wake up in response to I/O requests, you should
write "0" to power/autosuspend.
What: /sys/bus/usb/devices/.../power/persist
Date: May 2007
KernelVersion: 2.6.23
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
If CONFIG_USB_PERSIST is set, then each USB device directory
will contain a file named power/persist. The file holds a
boolean value (0 or 1) indicating whether or not the
"USB-Persist" facility is enabled for the device. Since the
facility is inherently dangerous, it is disabled by default
for all devices except hubs. For more information, see
Documentation/usb/persist.txt.

39
Documentation/CodingStyle
View File

@ -218,6 +218,18 @@ no space after the prefix increment & decrement unary operators:
and no space around the '.' and "->" structure member operators.
Do not leave trailing whitespace at the ends of lines. Some editors with
"smart" indentation will insert whitespace at the beginning of new lines as
appropriate, so you can start typing the next line of code right away.
However, some such editors do not remove the whitespace if you end up not
putting a line of code there, such as if you leave a blank line. As a result,
you end up with lines containing trailing whitespace.
Git will warn you about patches that introduce trailing whitespace, and can
optionally strip the trailing whitespace for you; however, if applying a series
of patches, this may make later patches in the series fail by changing their
context lines.
Chapter 4: Naming
@ -726,6 +738,33 @@ need them. Feel free to peruse that header file to see what else is already
defined that you shouldn't reproduce in your code.
Chapter 18: Editor modelines and other cruft
Some editors can interpret configuration information embedded in source files,
indicated with special markers. For example, emacs interprets lines marked
like this:
-*- mode: c -*-
Or like this:
/*
Local Variables:
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
End:
*/
Vim interprets markers that look like this:
/* vim:set sw=8 noet */
Do not include any of these in source files. People have their own personal
editor configurations, and your source files should not override them. This
includes markers for indentation and mode configuration. People may use their
own custom mode, or may have some other magic method for making indentation
work correctly.
Appendix I: References

103
Documentation/DMA-mapping.txt
View File

@ -664,109 +664,6 @@ It is that simple.
Well, not for some odd devices. See the next section for information
about that.
DAC Addressing for Address Space Hungry Devices
There exists a class of devices which do not mesh well with the PCI
DMA mapping API. By definition these "mappings" are a finite
resource. The number of total available mappings per bus is platform
specific, but there will always be a reasonable amount.
What is "reasonable"? Reasonable means that networking and block I/O
devices need not worry about using too many mappings.
As an example of a problematic device, consider compute cluster cards.
They can potentially need to access gigabytes of memory at once via
DMA. Dynamic mappings are unsuitable for this kind of access pattern.
To this end we've provided a small API by which a device driver
may use DAC cycles to directly address all of physical memory.
Not all platforms support this, but most do. It is easy to determine
whether the platform will work properly at probe time.
First, understand that there may be a SEVERE performance penalty for
using these interfaces on some platforms. Therefore, you MUST only
use these interfaces if it is absolutely required. %99 of devices can
use the normal APIs without any problems.
Note that for streaming type mappings you must either use these
interfaces, or the dynamic mapping interfaces above. You may not mix
usage of both for the same device. Such an act is illegal and is
guaranteed to put a banana in your tailpipe.
However, consistent mappings may in fact be used in conjunction with
these interfaces. Remember that, as defined, consistent mappings are
always going to be SAC addressable.
The first thing your driver needs to do is query the PCI platform
layer if it is capable of handling your devices DAC addressing
capabilities:
int pci_dac_dma_supported(struct pci_dev *hwdev, u64 mask);
You may not use the following interfaces if this routine fails.
Next, DMA addresses using this API are kept track of using the
dma64_addr_t type. It is guaranteed to be big enough to hold any
DAC address the platform layer will give to you from the following
routines. If you have consistent mappings as well, you still
use plain dma_addr_t to keep track of those.
All mappings obtained here will be direct. The mappings are not
translated, and this is the purpose of this dialect of the DMA API.
All routines work with page/offset pairs. This is the _ONLY_ way to
portably refer to any piece of memory. If you have a cpu pointer
(which may be validly DMA'd too) you may easily obtain the page
and offset using something like this:
struct page *page = virt_to_page(ptr);
unsigned long offset = offset_in_page(ptr);
Here are the interfaces:
dma64_addr_t pci_dac_page_to_dma(struct pci_dev *pdev,
struct page *page,
unsigned long offset,
int direction);
The DAC address for the tuple PAGE/OFFSET are returned. The direction
argument is the same as for pci_{map,unmap}_single(). The same rules
for cpu/device access apply here as for the streaming mapping
interfaces. To reiterate:
The cpu may touch the buffer before pci_dac_page_to_dma.
The device may touch the buffer after pci_dac_page_to_dma
is made, but the cpu may NOT.
When the DMA transfer is complete, invoke:
void pci_dac_dma_sync_single_for_cpu(struct pci_dev *pdev,
dma64_addr_t dma_addr,
size_t len, int direction);
This must be done before the CPU looks at the buffer again.
This interface behaves identically to pci_dma_sync_{single,sg}_for_cpu().
And likewise, if you wish to let the device get back at the buffer after
the cpu has read/written it, invoke:
void pci_dac_dma_sync_single_for_device(struct pci_dev *pdev,
dma64_addr_t dma_addr,
size_t len, int direction);
before letting the device access the DMA area again.
If you need to get back to the PAGE/OFFSET tuple from a dma64_addr_t
the following interfaces are provided:
struct page *pci_dac_dma_to_page(struct pci_dev *pdev,
dma64_addr_t dma_addr);
unsigned long pci_dac_dma_to_offset(struct pci_dev *pdev,
dma64_addr_t dma_addr);
This is possible with the DAC interfaces purely because they are
not translated in any way.
Optimizing Unmap State Space Consumption
On many platforms, pci_unmap_{single,page}() is simply a nop.

70
Documentation/DocBook/kernel-api.tmpl
View File

@ -139,8 +139,10 @@ X!Ilib/string.c
!Elib/cmdline.c
</sect1>
<sect1><title>CRC Functions</title>
<sect1 id="crc"><title>CRC Functions</title>
!Elib/crc7.c
!Elib/crc16.c
!Elib/crc-itu-t.c
!Elib/crc32.c
!Elib/crc-ccitt.c
</sect1>
@ -643,4 +645,70 @@ X!Idrivers/video/console/fonts.c
!Edrivers/spi/spi.c
</chapter>
<chapter id="i2c">
<title>I<superscript>2</superscript>C and SMBus Subsystem</title>
<para>
I<superscript>2</superscript>C (or without fancy typography, "I2C")
is an acronym for the "Inter-IC" bus, a simple bus protocol which is
widely used where low data rate communications suffice.
Since it's also a licensed trademark, some vendors use another
name (such as "Two-Wire Interface", TWI) for the same bus.
I2C only needs two signals (SCL for clock, SDA for data), conserving
board real estate and minimizing signal quality issues.
Most I2C devices use seven bit addresses, and bus speeds of up
to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
found wide use.
I2C is a multi-master bus; open drain signaling is used to
arbitrate between masters, as well as to handshake and to
synchronize clocks from slower clients.
</para>
<para>
The Linux I2C programming interfaces support only the master
side of bus interactions, not the slave side.
The programming interface is structured around two kinds of driver,
and two kinds of device.
An I2C "Adapter Driver" abstracts the controller hardware; it binds
to a physical device (perhaps a PCI device or platform_device) and
exposes a <structname>struct i2c_adapter</structname> representing
each I2C bus segment it manages.
On each I2C bus segment will be I2C devices represented by a
<structname>struct i2c_client</structname>. Those devices will
be bound to a <structname>struct i2c_driver</structname>,
which should follow the standard Linux driver model.
(At this writing, a legacy model is more widely used.)
There are functions to perform various I2C protocol operations; at
this writing all such functions are usable only from task context.
</para>
<para>
The System Management Bus (SMBus) is a sibling protocol. Most SMBus
systems are also I2C conformant. The electrical constraints are
tighter for SMBus, and it standardizes particular protocol messages
and idioms. Controllers that support I2C can also support most
SMBus operations, but SMBus controllers don't support all the protocol
options that an I2C controller will.
There are functions to perform various SMBus protocol operations,
either using I2C primitives or by issuing SMBus commands to
i2c_adapter devices which don't support those I2C operations.
</para>
!Iinclude/linux/i2c.h
!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="splice">
<title>splice API</title>
<para>)
splice is a method for moving blocks of data around inside the
kernel, without continually transferring it between the kernel
and user space.
</para>
!Iinclude/linux/splice.h
!Ffs/splice.c
</chapter>
</book>

82
Documentation/DocBook/procfs-guide.tmpl
View File

@ -352,49 +352,93 @@ entry->write_proc = write_proc_foo;
<funcsynopsis>
<funcprototype>
<funcdef>int <function>read_func</function></funcdef>
<paramdef>char* <parameter>page</parameter></paramdef>
<paramdef>char* <parameter>buffer</parameter></paramdef>
<paramdef>char** <parameter>start</parameter></paramdef>
<paramdef>off_t <parameter>off</parameter></paramdef>
<paramdef>int <parameter>count</parameter></paramdef>
<paramdef>int* <parameter>eof</parameter></paramdef>
<paramdef>int* <parameter>peof</parameter></paramdef>
<paramdef>void* <parameter>data</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
The read function should write its information into the
<parameter>page</parameter>. For proper use, the function
should start writing at an offset of
<parameter>off</parameter> in <parameter>page</parameter> and
write at most <parameter>count</parameter> bytes, but because
most read functions are quite simple and only return a small
amount of information, these two parameters are usually
ignored (it breaks pagers like <literal>more</literal> and
<literal>less</literal>, but <literal>cat</literal> still
works).
<parameter>buffer</parameter>, which will be exactly
<literal>PAGE_SIZE</literal> bytes long.
</para>
<para>
If the <parameter>off</parameter> and
<parameter>count</parameter> parameters are properly used,
<parameter>eof</parameter> should be used to signal that the
The parameter
<parameter>peof</parameter> should be used to signal that the
end of the file has been reached by writing
<literal>1</literal> to the memory location
<parameter>eof</parameter> points to.
<parameter>peof</parameter> points to.
</para>
<para>
The parameter <parameter>start</parameter> doesn't seem to be
used anywhere in the kernel. The <parameter>data</parameter>
The <parameter>data</parameter>
parameter can be used to create a single call back function for
several files, see <xref linkend="usingdata"/>.
</para>
<para>
The <function>read_func</function> function must return the
number of bytes written into the <parameter>page</parameter>.
The rest of the parameters and the return value are described
by a comment in <filename>fs/proc/generic.c</filename> as follows:
</para>
<blockquote>
<para>
You have three ways to return data:
</para>
<orderedlist>
<listitem>
<para>
Leave <literal>*start = NULL</literal>. (This is the default.)
Put the data of the requested offset at that
offset within the buffer. Return the number (<literal>n</literal>)
of bytes there are from the beginning of the
buffer up to the last byte of data. If the
number of supplied bytes (<literal>= n - offset</literal>) is
greater than zero and you didn't signal eof
and the reader is prepared to take more data
you will be called again with the requested
offset advanced by the number of bytes
absorbed. This interface is useful for files
no larger than the buffer.
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> to an unsigned long value less than
the buffer address but greater than zero.
Put the data of the requested offset at the
beginning of the buffer. Return the number of
bytes of data placed there. If this number is
greater than zero and you didn't signal eof
and the reader is prepared to take more data
you will be called again with the requested
offset advanced by <literal>*start</literal>. This interface is
useful when you have a large file consisting
of a series of blocks which you want to count
and return as wholes.
(Hack by Paul.Russell@rustcorp.com.au)
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> to an address within the buffer.
Put the data of the requested offset at <literal>*start</literal>.
Return the number of bytes of data placed there.
If this number is greater than zero and you
didn't signal eof and the reader is prepared to
take more data you will be called again with the
requested offset advanced by the number of bytes
absorbed.
</para>
</listitem>
</orderedlist>
</blockquote>
<para>
<xref linkend="example"/> shows how to use a read call back
function.

28
Documentation/HOWTO
View File

@ -322,39 +322,34 @@ kernel releases as described above.
Here is a list of some of the different kernel trees available:
git trees:
- Kbuild development tree, Sam Ravnborg <sam@ravnborg.org>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI development tree, Len Brown <len.brown@intel.com>
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- Block development tree, Jens Axboe <axboe@suse.de>
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM development tree, Dave Airlie <airlied@linux.ie>
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 development tree, Tony Luck <tony.luck@intel.com>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394 development tree, Jody McIntyre <scjody@modernduck.com>
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- infiniband, Roland Dreier <rolandd@cisco.com>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- network drivers, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
Other git kernel trees can be found listed at http://kernel.org/git
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
@ -362,6 +357,9 @@ Here is a list of some of the different kernel trees available:
- x86-64, partly i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.
Bug Reporting
-------------

10
Documentation/RCU/checklist.txt
View File

@ -222,7 +222,15 @@ over a rather long period of time, but improvements are always welcome!
deadlock as soon as the RCU callback happens to interrupt that
acquisition's critical section.
13. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
13. RCU callbacks can be and are executed in parallel. In many cases,
the callback code simply wrappers around kfree(), so that this
is not an issue (or, more accurately, to the extent that it is
an issue, the memory-allocator locking handles it). However,
if the callbacks do manipulate a shared data structure, they
must use whatever locking or other synchronization is required
to safely access and/or modify that data structure.
14. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu())
may only be invoked from process context. Unlike other forms of
RCU, it -is- permissible to block in an SRCU read-side critical
section (demarked by srcu_read_lock() and srcu_read_unlock()),

66
Documentation/SM501.txt Normal file
View File

@ -0,0 +1,66 @@
SM501 Driver
============
Copyright 2006, 2007 Simtec Electronics
Core
----
The core driver in drivers/mfd provides common services for the
drivers which manage the specific hardware blocks. These services
include locking for common registers, clock control and resource
management.
The core registers drivers for both PCI and generic bus based
chips via the platform device and driver system.
On detection of a device, the core initialises the chip (which may
be specified by the platform data) and then exports the selected
peripheral set as platform devices for the specific drivers.
The core re-uses the platform device system as the platform device
system provides enough features to support the drivers without the
need to create a new bus-type and the associated code to go with it.
Resources
---------
Each peripheral has a view of the device which is implicitly narrowed to
the specific set of resources that peripheral requires in order to
function correctly.
The centralised memory allocation allows the driver to ensure that the
maximum possible resource allocation can be made to the video subsystem
as this is by-far the most resource-sensitive of the on-chip functions.
The primary issue with memory allocation is that of moving the video
buffers once a display mode is chosen. Indeed when a video mode change
occurs the memory footprint of the video subsystem changes.
Since video memory is difficult to move without changing the display
(unless sufficient contiguous memory can be provided for the old and new
modes simultaneously) the video driver fully utilises the memory area
given to it by aligning fb0 to the start of the area and fb1 to the end
of it. Any memory left over in the middle is used for the acceleration
functions, which are transient and thus their location is less critical
as it can be moved.
Configuration
-------------
The platform device driver uses a set of platform data to pass
configurations through to the core and the subsidiary drivers
so that there can be support for more than one system carrying
an SM501 built into a single kernel image.
The PCI driver assumes that the PCI card behaves as per the Silicon
Motion reference design.
There is an errata (AB-5) affecting the selection of the
of the M1XCLK and M1CLK frequencies. These two clocks
must be sourced from the same PLL, although they can then
be divided down individually. If this is not set, then SM501 may
lock and hang the whole system. The driver will refuse to
attach if the PLL selection is different.

3
Documentation/SubmitChecklist
View File

@ -1,4 +1,4 @@
Linux Kernel patch sumbittal checklist
Linux Kernel patch submission checklist
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here are some basic things that developers should do if they want to see their
@ -9,7 +9,6 @@ Documentation/SubmittingPatches and elsewhere regarding submitting Linux
kernel patches.
1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
=n. No gcc warnings/errors, no linker warnings/errors.

20
Documentation/SubmittingPatches
View File

@ -464,9 +464,25 @@ section Linus Computer Science 101.
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
Once significant exception is when moving code from one file to
another in this case you should not modify the moved code at all in
the same patch which moves it. This clearly delineates the act of
moving the code and your changes. This greatly aids review of the
actual differences and allows tools to better track the history of
the code itself.
Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl). You should be able to justify all
violations that remain in your patch.
(scripts/checkpatch.pl). The style checker should be viewed as
a guide not as the final word. If your code looks better with
a violation then its probably best left alone.
The checker reports at three levels:
- ERROR: things that are very likely to be wrong
- WARNING: things requiring careful review
- CHECK: things requiring thought
You should be able to justify all violations that remain in your
patch.

19
Documentation/accounting/getdelays.c
View File

@ -49,6 +49,7 @@ char name[100];
int dbg;
int print_delays;
int print_io_accounting;
int print_task_context_switch_counts;
__u64 stime, utime;
#define PRINTF(fmt, arg...) { \
@ -195,7 +196,7 @@ void print_delayacct(struct taskstats *t)
"IO %15s%15s\n"
" %15llu%15llu\n"
"MEM %15s%15s\n"
" %15llu%15llu\n\n",
" %15llu%15llu\n"
"count", "real total", "virtual total", "delay total",
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
t->cpu_delay_total,
@ -204,6 +205,14 @@ void print_delayacct(struct taskstats *t)
"count", "delay total", t->swapin_count, t->swapin_delay_total);
}
void task_context_switch_counts(struct taskstats *t)
{
printf("\n\nTask %15s%15s\n"
" %15lu%15lu\n",
"voluntary", "nonvoluntary",
t->nvcsw, t->nivcsw);
}
void print_ioacct(struct taskstats *t)
{
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
@ -235,7 +244,7 @@ int main(int argc, char *argv[])
struct msgtemplate msg;
while (1) {
c = getopt(argc, argv, "diw:r:m:t:p:vl");
c = getopt(argc, argv, "qdiw:r:m:t:p:vl");
if (c < 0)
break;
@ -248,6 +257,10 @@ int main(int argc, char *argv[])
printf("printing IO accounting\n");
print_io_accounting = 1;
break;
case 'q':
printf("printing task/process context switch rates\n");
print_task_context_switch_counts = 1;
break;
case 'w':
logfile = strdup(optarg);
printf("write to file %s\n", logfile);
@ -389,6 +402,8 @@ int main(int argc, char *argv[])
print_delayacct((struct taskstats *) NLA_DATA(na));
if (print_io_accounting)
print_ioacct((struct taskstats *) NLA_DATA(na));
if (print_task_context_switch_counts)
task_context_switch_counts((struct taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
err(1,"write error\n");

6
Documentation/accounting/taskstats-struct.txt
View File

@ -22,6 +22,8 @@ There are three different groups of fields in the struct taskstats:
/* Extended accounting fields end */
Their values are collected if CONFIG_TASK_XACCT is set.
4) Per-task and per-thread context switch count statistics
Future extension should add fields to the end of the taskstats struct, and
should not change the relative position of each field within the struct.
@ -158,4 +160,8 @@ struct taskstats {
/* Extended accounting fields end */
4) Per-task and per-thread statistics
__u64 nvcsw; /* Context voluntary switch counter */
__u64 nivcsw; /* Context involuntary switch counter */
}

155
Documentation/blackfin/kgdb.txt Normal file
View File

@ -0,0 +1,155 @@
A Simple Guide to Configure KGDB
Sonic Zhang <sonic.zhang@analog.com>
Aug. 24th 2006
This KGDB patch enables the kernel developer to do source level debugging on
the kernel for the Blackfin architecture. The debugging works over either the
ethernet interface or one of the uarts. Both software breakpoints and
hardware breakpoints are supported in this version.
http://docs.blackfin.uclinux.org/doku.php?id=kgdb
2 known issues:
1. This bug:
http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=544&group_id=18&atid=145
The GDB client for Blackfin uClinux causes incorrect values of local
variables to be displayed when the user breaks the running of kernel in GDB.
2. Because of a hardware bug in Blackfin 533 v1.0.3:
05000067 - Watchpoints (Hardware Breakpoints) are not supported
Hardware breakpoints cannot be set properly.
Debug over Ethernet:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over (Ethernet)". Add "kgdboe=@target-IP/,@host-IP/" to
the option "Compiled-in Kernel Boot Parameter" under "Kernel hacking".
4. Connect minicom to the serial port and boot the kernel image.
5. Configure the IP "/> ifconfig eth0 target-IP"
6. Start GDB client "bfin-elf-gdb vmlinux".
7. Connect to the target "(gdb) target remote udp:target-IP:6443".
8. Set software breakpoint "(gdb) break sys_open".
9. Continue "(gdb) c".
10. Run ls in the target console "/> ls".
11. Breakpoint hits. "Breakpoint 1: sys_open(..."
12. Display local variables and function paramters.
(*) This operation gives wrong results, see known issue 1.
13. Single stepping "(gdb) si".
14. Remove breakpoint 1. "(gdb) del 1"
15. Set hardware breakpoint "(gdb) hbreak sys_open".
16. Continue "(gdb) c".
17. Run ls in the target console "/> ls".
18. Hardware breakpoint hits. "Breakpoint 1: sys_open(...".
(*) This hardware breakpoint will not be hit, see known issue 2.
19. Continue "(gdb) c".
20. Interrupt the target in GDB "Ctrl+C".
21. Detach from the target "(gdb) detach".
22. Exit GDB "(gdb) quit".
Debug over the UART:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over (UART)". Set "KGDB: UART port number" to be
a different one from the console. Don't forget to change the mode of
blackfin serial driver to PIO. Otherwise kgdb works incorrectly on UART.
4. If you want connect to kgdb when the kernel boots, enable
"KGDB: Wait for gdb connection early"
5. Compile kernel.
6. Connect minicom to the serial port of the console and boot the kernel image.
7. Start GDB client "bfin-elf-gdb vmlinux".
8. Set the baud rate in GDB "(gdb) set remotebaud 57600".
9. Connect to the target on the second serial port "(gdb) target remote /dev/ttyS1".
10. Set software breakpoint "(gdb) break sys_open".
11. Continue "(gdb) c".
12. Run ls in the target console "/> ls".
13. A breakpoint is hit. "Breakpoint 1: sys_open(..."
14. All other operations are the same as that in KGDB over Ethernet.
Debug over the same UART as console:
1. Compile and install the cross platform version of gdb for blackfin, which
can be found at $(BINROOT)/bfin-elf-gdb.
2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under
"Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb".
With this selected, option "Full Symbolic/Source Debugging support" and
"Compile the kernel with frame pointers" are also selected.
3. Select option "KGDB: connect over UART". Set "KGDB: UART port number" to console.
Don't forget to change the mode of blackfin serial driver to PIO.
Otherwise kgdb works incorrectly on UART.
4. If you want connect to kgdb when the kernel boots, enable
"KGDB: Wait for gdb connection early"
5. Connect minicom to the serial port and boot the kernel image.
6. (Optional) Ask target to wait for gdb connection by entering Ctrl+A. In minicom, you should enter Ctrl+A+A.
7. Start GDB client "bfin-elf-gdb vmlinux".
8. Set the baud rate in GDB "(gdb) set remotebaud 57600".
9. Connect to the target "(gdb) target remote /dev/ttyS0".
10. Set software breakpoint "(gdb) break sys_open".
11. Continue "(gdb) c". Then enter Ctrl+C twice to stop GDB connection.
12. Run ls in the target console "/> ls". Dummy string can be seen on the console.
13. Then connect the gdb to target again. "(gdb) target remote /dev/ttyS0".
Now you will find a breakpoint is hit. "Breakpoint 1: sys_open(..."
14. All other operations are the same as that in KGDB over Ethernet. The only
difference is that after continue command in GDB, please stop GDB
connection by 2 "Ctrl+C"s and connect again after breakpoints are hit or
Ctrl+A is entered.

16
Documentation/block/barrier.txt
View File

@ -82,23 +82,12 @@ including draining and flushing.
typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq);
int blk_queue_ordered(request_queue_t *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn,
unsigned gfp_mask);
int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn,
unsigned gfp_mask);
The only difference between the two functions is whether or not the
caller is holding q->queue_lock on entry. The latter expects the
caller is holding the lock.
prepare_flush_fn *prepare_flush_fn);
@q : the queue in question
@ordered : the ordered mode the driver/device supports
@prepare_flush_fn : this function should prepare @rq such that it
flushes cache to physical medium when executed
@gfp_mask : gfp_mask used when allocating data structures
for ordered processing
For example, SCSI disk driver's prepare_flush_fn looks like the
following.
@ -106,9 +95,10 @@ following.
static void sd_prepare_flush(request_queue_t *q, struct request *rq)
{
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->flags |= REQ_BLOCK_PC;
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->timeout = SD_TIMEOUT;
rq->cmd[0] = SYNCHRONIZE_CACHE;
rq->cmd_len = 10;
}
The following seven ordered modes are supported. The following table

2
Documentation/cachetlb.txt
View File

@ -253,7 +253,7 @@ Here are the routines, one by one:
The first of these two routines is invoked after map_vm_area()
has installed the page table entries. The second is invoked
before unmap_vm_area() deletes the page table entries.
before unmap_kernel_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.

22
Documentation/cdrom/00-INDEX
View File

@ -2,32 +2,10 @@
- this file (info on CD-ROMs and Linux)
Makefile
- only used to generate TeX output from the documentation.
aztcd
- info on Aztech/Orchid/Okano/Wearnes/Conrad/CyCDROM driver.
cdrom-standard.tex
- LaTeX document on standardizing the CD-ROM programming interface.
cdu31a
- info on the Sony CDU31A/CDU33A CD-ROM driver.
cm206
- info on the Philips/LMS cm206/cm260 CD-ROM driver.
gscd
- info on the Goldstar R420 CD-ROM driver.
ide-cd
- info on setting up and using ATAPI (aka IDE) CD-ROMs.
isp16
- info on the CD-ROM interface on ISP16, MAD16 or Mozart sound card.
mcd
- info on limitations of standard Mitsumi CD-ROM driver.
mcdx
- info on improved Mitsumi CD-ROM driver.
optcd
- info on the Optics Storage 8000 AT CD-ROM driver
packet-writing.txt
- Info on the CDRW packet writing module
sbpcd
- info on the SoundBlaster/Panasonic CD-ROM interface driver.
sjcd
- info on the SANYO CDR-H94A CD-ROM interface driver.
sonycd535
- info on the Sony CDU-535 (and 531) CD-ROM driver.

822
Documentation/cdrom/aztcd
View File

@ -1,822 +0,0 @@
$Id: README.aztcd,v 2.60 1997/11/29 09:51:25 root Exp root $
Readme-File Documentation/cdrom/aztcd
for
AZTECH CD-ROM CDA268-01A, ORCHID CD-3110,
OKANO/WEARNES CDD110, CONRAD TXC, CyCDROM CR520, CR540
CD-ROM Drives
Version 2.6 and newer
(for other drives see 6.-8.)
NOTE: THIS DRIVER WILL WORK WITH THE CD-ROM DRIVES LISTED, WHICH HAVE
A PROPRIETARY INTERFACE (implemented on a sound card or on an
ISA-AT-bus card).
IT WILL DEFINITELY NOT WORK WITH CD-ROM DRIVES WITH *IDE*-INTERFACE,
such as the Aztech CDA269-031SE !!! (The only known exceptions are
'faked' IDE drives like the CyCDROM CR520ie which work with aztcd
under certain conditions, see 7.). IF YOU'RE USING A CD-ROM DRIVE
WITH IDE-INTERFACE, SOMETIMES ALSO CALLED ATAPI-COMPATIBLE, PLEASE
USE THE ide-cd.c DRIVER, WRITTEN BY MARK LORD AND SCOTT SNYDER !
THE STANDARD-KERNEL 1.2.x NOW ALSO SUPPORTS IDE-CDROM-DRIVES, SEE THE
HARDDISK (!) SECTION OF make config, WHEN COMPILING A NEW KERNEL!!!
----------------------------------------------------------------------------
Contents of this file:
1. NOTE
2. INSTALLATION
3. CONFIGURING YOUR KERNEL
4. RECOMPILING YOUR KERNEL
4.1 AZTCD AS A RUN-TIME LOADABLE MODULE
4.2 CDROM CONNECTED TO A SOUNDCARD
5. KNOWN PROBLEMS, FUTURE DEVELOPMENTS
5.1 MULTISESSION SUPPORT
5.2 STATUS RECOGNITION
5.3 DOSEMU's CDROM SUPPORT
6. BUG REPORTS
7. OTHER DRIVES
8. IF YOU DON'T SUCCEED ... DEBUGGING
9. TECHNICAL HISTORY OF THE DRIVER
10. ACKNOWLEDGMENTS
11. PROGRAMMING ADD ONS: CDPLAY.C
APPENDIX: Source code of cdplay.c
----------------------------------------------------------------------------
1. NOTE
This software has been successfully in alpha and beta test and is part of
the standard kernel since kernel 1.1.8x since December 1994. It works with
AZTECH CDA268-01A, ORCHID CDS-3110, ORCHID/WEARNES CDD110 and CONRAD TXC
(Nr.99 31 23 -series 04) and has proven to be stable with kernel
versions 1.0.9 and newer. But with any software there still may be bugs in it.
So if you encounter problems, you are invited to help us improve this software.
Please send me a detailed bug report (see chapter BUG REPORTS). You are also
invited in helping us to increase the number of drives, which are supported.
Please read the README-files carefully and always keep a backup copy of your
old kernel, in order to reboot if something goes wrong!
2. INSTALLATION
The driver consists of a header file 'aztcd.h', which normally should reside
in /usr/src/linux/drivers/cdrom and the source code 'aztcd.c', which normally
resides in the same place. It uses /dev/aztcd (/dev/aztcd0 in some distri-
butions), which must be a valid block device with major number 29 and reside
in directory /dev. To mount a CD-ROM, your kernel needs to have the ISO9660-
filesystem support included.
PLEASE NOTE: aztcd.c has been developed in parallel to the linux kernel,
which had and is having many major and minor changes which are not backward
compatible. Quite definitely aztcd.c version 1.80 and newer will NOT work
in kernels older than 1.3.33. So please always use the most recent version
of aztcd.c with the appropriate linux-kernel.
3. CONFIGURING YOUR KERNEL
If your kernel is already configured for using the AZTECH driver you will
see the following message while Linux boots:
Aztech CD-ROM Init: DriverVersion=<version number> BaseAddress=<baseaddress>
Aztech CD-ROM Init: FirmwareVersion=<firmware version id of your I/O-card>>>
Aztech CD-ROM Init: <drive type> detected
Aztech CD-ROM Init: End
If the message looks different and you are sure to have a supported drive,
it may have a different base address. The Aztech driver does look for the
CD-ROM drive at the base address specified in aztcd.h at compile time. This
address can be overwritten by boot parameter aztcd=....You should reboot and
start Linux with boot parameter aztcd=<base address>, e.g. aztcd=0x320. If
you do not know the base address, start your PC with DOS and look at the boot
message of your CD-ROM's DOS driver. If that still does not help, use boot
parameter aztcd=<base address>,0x79 , this tells aztcd to try a little harder.
aztcd may be configured to use autoprobing the base address by recompiling
it (see chapter 4.).
If the message looks correct, as user 'root' you should be able to mount the
drive by
mount -t iso9660 -r /dev/aztcd0 /mnt
and use it as any other filesystem. (If this does not work, check if
/dev/aztcd0 and /mnt do exist and create them, if necessary by doing
mknod /dev/aztcd0 b 29 0
mkdir /mnt
If you still get a different message while Linux boots or when you get the
message, that the ISO9660-filesystem is not supported by your kernel, when
you try to mount the CD-ROM drive, you have to recompile your kernel.
If you do *not* have an Aztech/Orchid/Okano/Wearnes/TXC drive and want to
bypass drive detection during Linux boot up, start with boot parameter aztcd=0.
Most distributions nowadays do contain a boot disk image containing aztcd.
Please note, that this driver will not work with IDE/ATAPI drives! With these
you must use ide-cd.c instead.
4. RECOMPILING YOUR KERNEL
If your kernel is not yet configured for the AZTECH driver and the ISO9660-
filesystem, you have to recompile your kernel:
- Edit aztcd.h to set the I/O-address to your I/O-Base address (AZT_BASE_ADDR),
the driver does not use interrupts or DMA, so if you are using an AZTECH
CD268, an ORCHID CD-3110 or ORCHID/WEARNES CDD110 that's the only item you
have to set up. If you have a soundcard, read chapter 4.2.
Users of other drives should read chapter OTHER DRIVES of this file.
You also can configure that address by kernel boot parameter aztcd=...
- aztcd may be configured to use autoprobing the base address by setting
AZT_BASE_ADDR to '-1'. In that case aztcd probes the addresses listed
under AZT_BASE_AUTO. But please remember, that autoprobing always may
incorrectly influence other hardware components too!
- There are some other points, which may be configured, e.g. auto-eject the
CD when unmounting a drive, tray locking etc., see aztcd.h for details.
- If you're using a linux kernel version prior to 2.1.0, in aztcd.h
uncomment the line '#define AZT_KERNEL_PRIOR_2_1'
- Build a new kernel, configure it for 'Aztech/Orchid/Okano/Wearnes support'
(if you want aztcd to be part of the kernel). Do not configure it for
'Aztech... support', if you want to use aztcd as a run time loadable module.
But in any case you must have the ISO9660-filesystem included in your
kernel.
- Activate the new kernel, normally this is done by running LILO (don't for-
get to configure it before and to keep a copy of your old kernel in case
something goes wrong!).
- Reboot
- If you've included aztcd in your kernel, you now should see during boot
some messages like
Aztech CD-ROM Init: DriverVersion=<version number> BaseAddress=<baseaddress>
Aztech CD-ROM Init: FirmwareVersion=<firmware version id of your I/O-card>
Aztech CD-ROM Init: <drive type> detected
Aztech CD-ROM Init: End
- If you have not included aztcd in your kernel, but want to load aztcd as a
run time loadable module see 4.1.
- If the message looks correct, as user 'root' you should be able to mount
the drive by
mount -t iso9660 -r /dev/aztcd0 /mnt
and use it as any other filesystem. (If this does not work, check if
/dev/aztcd0 and /mnt do exist and create them, if necessary by doing
mknod /dev/aztcd0 b 29 0
mkdir /mnt
- If this still does not help, see chapters OTHER DRIVES and DEBUGGING.
4.1 AZTCD AS A RUN-TIME LOADABLE MODULE
If you do not need aztcd permanently, you can also load and remove the driver
during runtime via insmod and rmmod. To build aztcd as a loadable module you
must configure your kernel for AZTECH module support (answer 'm' when con-
figuring the kernel). Anyhow, you may run into problems, if the version of
your boot kernel is not the same than the source kernel version, from which
you create the modules. So rebuild your kernel, if necessary.
Now edit the base address of your AZTECH interface card in
/usr/src/linux/drivers/cdrom/aztcd.h to the appropriate value.
aztcd may be configured to use autoprobing the base address by setting
AZT_BASE_ADDR to '-1'. In that case aztcd probes the addresses listed
under AZT_BASE_AUTO. But please remember, that autoprobing always may
incorrectly influence other hardware components too!
There are also some special features which may be configured, e.g.
auto-eject a CD when unmounting the drive etc; see aztcd.h for details.
Then change to /usr/src/linux and do a
make modules
make modules_install
After that you can run-time load the driver via
insmod /lib/modules/X.X.X/misc/aztcd.o
and remove it via rmmod aztcd.
If you did not set the correct base address in aztcd.h, you can also supply the
base address when loading the driver via
insmod /lib/modules/X.X.X/misc/aztcd.o aztcd=<base address>
Again specifying aztcd=-1 will cause autoprobing.
If you do not have the iso9660-filesystem in your boot kernel, you also have
to load it before you can mount the CDROM:
insmod /lib/modules/X.X.X/fs/isofs.o
The mount procedure works as described in 4. above.
(In all commands 'X.X.X' is the current linux kernel version number)
4.2 CDROM CONNECTED TO A SOUNDCARD
Most soundcards do have a bus interface to the CDROM-drive. In many cases
this soundcard needs to be configured, before the CDROM can be used. This
configuration procedure consists of writing some kind of initialization
data to the soundcard registers. The AZTECH-CDROM driver in the moment does
only support one type of soundcard (SoundWave32). Users of other soundcards
should try to boot DOS first and let their DOS drivers initialize the
soundcard and CDROM, then warm boot (or use loadlin) their PC to start
Linux.
Support for the CDROM-interface of SoundWave32-soundcards is directly
implemented in the AZTECH driver. Please edit linux/drivers/cdrom/aztdc.h,
uncomment line '#define AZT_SW32' and set the appropriate value for
AZT_BASE_ADDR and AZT_SW32_BASE_ADDR. This support was tested with an Orchid
CDS-3110 connected to a SoundWave32.
If you want your soundcard to be supported, find out, how it needs to be
configured and mail me (see 6.) the appropriate information.
5. KNOWN PROBLEMS, FUTURE DEVELOPMENTS
5.1 MULTISESSION SUPPORT
Multisession support for CD's still is a myth. I implemented and tested a basic
support for multisession and XA CDs, but I still have not enough CDs and appli-
cations to test it rigorously. So if you'd like to help me, please contact me
(Email address see below). As of version 1.4 and newer you can enable the
multisession support in aztcd.h by setting AZT_MULTISESSION to 1. Doing so
will cause the ISO9660-filesystem to deal with multisession CDs, ie. redirect
requests to the Table of Contents (TOC) information from the last session,
which contains the info of all previous sessions etc.. If you do set
AZT_MULTISESSION to 0, you can use multisession CDs anyway. In that case the
drive's firmware will do automatic redirection. For the ISO9660-filesystem any
multisession CD will then look like a 'normal' single session CD. But never-
theless the data of all sessions are viewable and accessible. So with practical-
ly all real world applications you won't notice the difference. But as future
applications may make use of advanced multisession features, I've started to
implement the interface for the ISO9660 multisession interface via ioctl
CDROMMULTISESSION.
5.2 STATUS RECOGNITION
The drive status recognition does not work correctly in all cases. Changing
a disk or having the door open, when a drive is already mounted, is detected
by the Aztech driver itself, but nevertheless causes multiple read attempts
by the different layers of the ISO9660-filesystem driver, which finally timeout,
so you have to wait quite a little... But isn't it bad style to change a disk
in a mounted drive, anyhow ?!
The driver uses busy wait in most cases for the drive handshake (macros
STEN_LOW and DTEN_LOW). I tested with a 486/DX2 at 66MHz and a Pentium at
60MHz and 90MHz. Whenever you use a much faster machine you are likely to get
timeout messages. In that case edit aztcd.h and increase the timeout value
AZT_TIMEOUT.
For some 'slow' drive commands I implemented waiting with a timer waitqueue
(macro STEN_LOW_WAIT). If you get this timeout message, you may also edit
aztcd.h and increase the timeout value AZT_STATUS_DELAY. The waitqueue has
shown to be a little critical. If you get kernel panic messages, edit aztcd.c
and substitute STEN_LOW_WAIT by STEN_LOW. Busy waiting with STEN_LOW is more
stable, but also causes CPU overhead.
5.3 DOSEMU's CD-ROM SUPPORT
With release 1.20 aztcd was modified to allow access to CD-ROMS when running
under dosemu-0.60.0 aztcd-versions before 1.20 are most likely to crash
Linux, when a CD-ROM is accessed under dosemu. This problem has partly been
fixed, but still when accessing a directory for the first time the system
might hang for some 30sec. So be patient, when using dosemu's CD-ROM support
in combination with aztcd :-) !
This problem has now (July 1995) been fixed by a modification to dosemu's
CD-ROM driver. The new version came with dosemu-0.60.2, see dosemu's
README.CDROM.
6. BUG REPORTS
Please send detailed bug reports and bug fixes via EMail to
Werner.Zimmermann@fht-esslingen.de
Please include a description of your CD-ROM drive type and interface card,
the exact firmware message during Linux bootup, the version number of the
AZTECH-CDROM-driver and the Linux kernel version. Also a description of your
system's other hardware could be of interest, especially microprocessor type,
clock frequency, other interface cards such as soundcards, ethernet adapter,
game cards etc..
I will try to collect the reports and make the necessary modifications from
time to time. I may also come back to you directly with some bug fixes and
ask you to do further testing and debugging.
Editors of CD-ROMs are invited to send a 'cooperation' copy of their
CD-ROMs to the volunteers, who provided the CD-ROM support for Linux. My
snail mail address for such 'stuff' is
Prof. Dr. W. Zimmermann
Fachhochschule fuer Technik Esslingen
Fachbereich IT
Flandernstrasse 101
D-73732 Esslingen
Germany
7. OTHER DRIVES
The following drives ORCHID CDS3110, OKANO CDD110, WEARNES CDD110 and Conrad
TXC Nr. 993123-series 04 nearly look the same as AZTECH CDA268-01A, especially
they seem to use the same command codes. So it was quite simple to make the
AZTECH driver work with these drives.
Unfortunately I do not have any of these drives available, so I couldn't test
it myself. In some installations, it seems necessary to initialize the drive
with the DOS driver before (especially if combined with a sound card) and then
do a warm boot (CTRL-ALT-RESET) or start Linux from DOS, e.g. with 'loadlin'.
If you do not succeed, read chapter DEBUGGING. Thanks in advance!
Sorry for the inconvenience, but it is difficult to develop for hardware,
which you don't have available for testing. So if you like, please help us.
If you do have a CyCDROM CR520ie thanks to Hilmar Berger's help your chances
are good, that it will work with aztcd. The CR520ie is sold as an IDE-drive
and really is connected to the IDE interface (primary at 0x1F0 or secondary
at 0x170, configured as slave, not as master). Nevertheless it is not ATAPI
compatible but still uses Aztech's command codes.
8. DEBUGGING : IF YOU DON'T SUCCEED, TRY THE FOLLOWING
-reread the complete README file
-make sure, that your drive is hardware configured for
transfer mode: polled
IRQ: not used
DMA: not used
Base Address: something like 300, 320 ...
You can check this, when you start the DOS driver, which came with your
drive. By appropriately configuring the drive and the DOS driver you can
check, whether your drive does operate in this mode correctly under DOS. If
it does not operate under DOS, it won't under Linux.
If your drive's base address is something like 0x170 or 0x1F0 (and it is
not a CyCDROM CR520ie or CR 940ie) you most likely are having an IDE/ATAPI-
compatible drive, which is not supported by aztcd.c, use ide-cd.c instead.
Make sure the Base Address is configured correctly in aztcd.h, also make
sure, that /dev/aztcd0 exists with the correct major number (compare it with
the entry in file /usr/include/linux/major.h for the Aztech drive).
-insert a CD-ROM and close the tray
-cold boot your PC (i.e. via the power on switch or the reset button)
-if you start Linux via DOS, e.g. using loadlin, make sure, that the DOS
driver for the CD-ROM drive is not loaded (comment out the calling lines
in DOS' config.sys!)
-look for the aztcd: init message during Linux init and note them exactly
-log in as root and do a mount -t iso9660 /dev/aztcd0 /mnt
-if you don't succeed in the first time, try several times. Try also to open
and close the tray, then mount again. Please note carefully all commands
you typed in and the aztcd-messages, which you get.
-if you get an 'Aztech CD-ROM init: aborted' message, read the remarks about
the version string below.
If this does not help, do the same with the following differences
-start DOS before; make now sure, that the DOS driver for the CD-ROM is
loaded under DOS (i.e. uncomment it again in config.sys)
-warm boot your PC (i.e. via CTRL-ALT-DEL)
if you have it, you can also start via loadlin (try both).
...
Again note all commands and the aztcd-messages.
If you see STEN_LOW or STEN_LOW_WAIT error messages, increase the timeout
values.
If this still does not help,
-look in aztcd.c for the lines #if 0
#define AZT_TEST1
...
#endif
and substitute '#if 0' by '#if 1'.
-recompile your kernel and repeat the above two procedures. You will now get
a bundle of debugging messages from the driver. Again note your commands
and the appropriate messages. If you have syslogd running, these messages
may also be found in syslogd's kernel log file. Nevertheless in some
installations syslogd does not yet run, when init() is called, thus look for
the aztcd-messages during init, before the login-prompt appears.
Then look in aztcd.c, to find out, what happened. The normal calling sequence
is: aztcd_init() during Linux bootup procedure init()
after doing a 'mount -t iso9660 /dev/aztcd0 /mnt' the normal calling sequence is
aztcd_open() -> Status 2c after cold reboot with CDROM or audio CD inserted
-> Status 8 after warm reboot with CDROM inserted
-> Status 2e after cold reboot with no disk, closed tray
-> Status 6e after cold reboot, mount with door open
aztUpdateToc()
aztGetDiskInfo()
aztGetQChannelInfo() repeated several times
aztGetToc()
aztGetQChannelInfo() repeated several times
a list of track information
do_aztcd_request() }
azt_transfer() } repeated several times
azt_poll }
Check, if there is a difference in the calling sequence or the status flags!
There are a lot of other messages, eg. the ACMD-command code (defined in
aztcd.h), status info from the getAztStatus-command and the state sequence of
the finite state machine in azt_poll(). The most important are the status
messages, look how they are defined and try to understand, if they make
sense in the context where they appear. With a CD-ROM inserted the status
should always be 8, except in aztcd_open(). Try to open the tray, insert an
audio disk, insert no disk or reinsert the CD-ROM and check, if the status
bits change accordingly. The status bits are the most likely point, where
the drive manufacturers may implement changes.
If you still don't succeed, a good point to start is to look in aztcd.c in
function aztcd_init, where the drive should be detected during init. Do the
following:
-reboot the system with boot parameter 'aztcd=<your base address>,0x79'. With
parameter 0x79 most of the drive version detection is bypassed. After that
you should see the complete version string including leading and trailing
blanks during init.
Now adapt the statement
if ((result[1]=='A')&&(result[2]=='Z' ...)
in aztcd_init() to exactly match the first 3 or 4 letters you have seen.
-Another point is the 'smart' card detection feature in aztcd_init(). Normally
the CD-ROM drive is ready, when aztcd_init is trying to read the version
string and a time consuming ACMD_SOFT_RESET command can be avoided. This is
detected by looking, if AFL_OP_OK can be read correctly. If the CD-ROM drive
hangs in some unknown state, e.g. because of an error before a warm start or
because you first operated under DOS, even the version string may be correct,
but the following commands will not. Then change the code in such a way,
that the ACMD_SOFT_RESET is issued in any case, by substituting the
if-statement 'if ( ...=AFL_OP_OK)' by 'if (1)'.
If you succeed, please mail me the exact version string of your drive and
the code modifications, you have made together with a short explanation.
If you don't succeed, you may mail me the output of the debugging messages.
But remember, they are only useful, if they are exact and complete and you
describe in detail your hardware setup and what you did (cold/warm reboot,
with/without DOS, DOS-driver started/not started, which Linux-commands etc.)
9. TECHNICAL HISTORY OF THE DRIVER
The AZTECH-Driver is a rework of the Mitsumi-Driver. Four major items had to
be reworked:
a) The Mitsumi drive does issue complete status information acknowledging
each command, the Aztech drive does only signal that the command was
processed. So whenever the complete status information is needed, an extra
ACMD_GET_STATUS command is issued. The handshake procedure for the drive
can be found in the functions aztSendCmd(), sendAztCmd() and getAztStatus().
b) The Aztech Drive does not have a ACMD_GET_DISK_INFO command, so the
necessary info about the number of tracks (firstTrack, lastTrack), disk
length etc. has to be read from the TOC in the lead in track (see function
aztGetDiskInfo()).
c) Whenever data is read from the drive, the Mitsumi drive is started with a
command to read an indefinite (0xffffff) number of sectors. When the appropriate
number of sectors is read, the drive is stopped by a ACDM_STOP command. This
does not work with the Aztech drive. I did not find a way to stop it. The
stop and pause commands do only work in AUDIO mode but not in DATA mode.
Therefore I had to modify the 'finite state machine' in function azt_poll to
only read a certain number of sectors and then start a new read on demand. As I
have not completely understood, how the buffer/caching scheme of the Mitsumi
driver was implemented, I am not sure, if I have covered all cases correctly,
whenever you get timeout messages, the bug is most likely to be in that
function azt_poll() around switch(cmd) .... case ACD_S_DATA.
d) I did not get information about changing drive mode. So I doubt, that the
code around function azt_poll() case AZT_S_MODE does work. In my test I have
not been able to switch to reading in raw mode. For reading raw mode, Aztech
uses a different command than for cooked mode, which I only have implemen-
ted in the ioctl-section but not in the section which is used by the ISO9660.
The driver was developed on an AST PC with Intel 486/DX2, 8MB RAM, 340MB IDE
hard disk and on an AST PC with Intel Pentium 60MHz, 16MB RAM, 520MB IDE
running Linux kernel version 1.0.9 from the LST 1.8 Distribution. The kernel
was compiled with gcc.2.5.8. My CD-ROM drive is an Aztech CDA268-01A. My
drive says, that it has Firmware Version AZT26801A1.3. It came with an ISA-bus
interface card and works with polled I/O without DMA and without interrupts.
The code for all other drives was 'remote' tested and debugged by a number of
volunteers on the Internet.
Points, where I feel that possible problems might be and all points where I
did not completely understand the drive's behaviour or trust my own code are
marked with /*???*/ in the source code. There are also some parts in the
Mitsumi driver, where I did not completely understand their code.
10. ACKNOWLEDGMENTS
Without the help of P.Bush, Aztech, who delivered technical information
about the Aztech Drive and without the help of E.Moenkeberg, GWDG, who did a
great job in analyzing the command structure of various CD-ROM drives, this
work would not have been possible. E.Moenkeberg was also a great help in
making the software 'kernel ready' and in answering many of the CDROM-related
questions in the newsgroups. He really is *the* Linux CD-ROM guru. Thanks
also to all the guys on the Internet, who collected valuable technical
information about CDROMs.
Joe Nardone (joe@access.digex.net) was a patient tester even for my first
trial, which was more than slow, and made suggestions for code improvement.
Especially the 'finite state machine' azt_poll() was rewritten by Joe to get
clean C code and avoid the ugly 'gotos', which I copied from mcd.c.
Robby Schirmer (schirmer@fmi.uni-passau.de) tested the audio stuff (ioctls)
and suggested a lot of patches for them.
Joseph Piskor and Peter Nugent were the first users with the ORCHID CD3110
and also were very patient with the problems which occurred.
Reinhard Max delivered the information for the CDROM-interface of the
SoundWave32 soundcards.
Jochen Kunz and Olaf Kaluza delivered the information for supporting Conrad's
TXC drive.
Hilmar Berger delivered the patches for supporting CyCDROM CR520ie.
Anybody, who is interested in these items should have a look at 'ftp.gwdg.de',
directory 'pub/linux/cdrom' and at 'ftp.cdrom.com', directory 'pub/cdrom'.
11. PROGRAMMING ADD ONs: cdplay.c
You can use the ioctl-functions included in aztcd.c in your own programs. As
an example on how to do this, you will find a tiny CD Player for audio CDs
named 'cdplay.c'. It allows you to play audio CDs. You can play a specified
track, pause and resume or skip tracks forward and backwards. If you quit the
program without stopping the drive, playing is continued. You can also
(mis)use cdplay to read and hexdump data disks. You can find the code in the
APPENDIX of this file, which you should cut out with an editor and store in a
separate file 'cdplay.c'. To compile it and make it executable, do
gcc -s -Wall -O2 -L/usr/lib cdplay.c -o /usr/local/bin/cdplay # compiles it
chmod +755 /usr/local/bin/cdplay # makes it executable
ln -s /dev/aztcd0 /dev/cdrom # creates a link
(for /usr/lib substitute the top level directory, where your include files
reside, and for /usr/local/bin the directory, where you want the executable
binary to reside )
You have to set the correct permissions for cdplay *and* for /dev/mcd0 or
/dev/aztcd0 in order to use it. Remember, that you should not have /dev/cdrom
mounted, when you're playing audio CDs.
This program is just a hack for testing the ioctl-functions in aztcd.c. I will
not maintain it, so if you run into problems, discard it or have a look into
the source code 'cdplay.c'. The program does only contain a minimum of user
protection and input error detection. If you use the commands in the wrong
order or if you try to read a CD at wrong addresses, you may get error messages
or even hang your machine. If you get STEN_LOW, STEN_LOW_WAIT or segment violation
error messages when using cdplay, after that, the system might not be stable
any more, so you'd better reboot. As the ioctl-functions run in kernel mode,
most normal Linux-multitasking protection features do not work. By using
uninitialized 'wild' pointers etc., it is easy to write to other users' data
and program areas, destroy kernel tables etc.. So if you experiment with ioctls
as always when you are doing systems programming and kernel hacking, you
should have a backup copy of your system in a safe place (and you also
should try restoring from a backup copy first)!
A reworked and improved version called 'cdtester.c', which has yet more
features for testing CDROM-drives can be found in
Documentation/cdrom/sbpcd, written by E.Moenkeberg.
Werner Zimmermann
Fachhochschule fuer Technik Esslingen
(EMail: Werner.Zimmermann@fht-esslingen.de)
October, 1997
---------------------------------------------------------------------------
APPENDIX: Source code of cdplay.c
/* Tiny Audio CD Player
Copyright 1994, 1995, 1996 Werner Zimmermann (Werner.Zimmermann@fht-esslingen.de)
This program originally was written to test the audio functions of the
AZTECH.CDROM-driver, but it should work with every CD-ROM drive. Before
using it, you should set a symlink from /dev/cdrom to your real CDROM
device.
The GNU General Public License applies to this program.
History: V0.1 W.Zimmermann: First release. Nov. 8, 1994
V0.2 W.Zimmermann: Enhanced functionality. Nov. 9, 1994
V0.3 W.Zimmermann: Additional functions. Nov. 28, 1994
V0.4 W.Zimmermann: fixed some bugs. Dec. 17, 1994
V0.5 W.Zimmermann: clean 'scanf' commands without compiler warnings
Jan. 6, 1995
V0.6 W.Zimmermann: volume control (still experimental). Jan. 24, 1995
V0.7 W.Zimmermann: read raw modified. July 26, 95
*/
#include <stdio.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/cdrom.h>
#include <linux/../../drivers/cdrom/aztcd.h>
void help(void)
{ printf("Available Commands: STOP s EJECT/CLOSE e QUIT q\n");
printf(" PLAY TRACK t PAUSE p RESUME r\n");
printf(" NEXT TRACK n REPEAT LAST l HELP h\n");
printf(" SUB CHANNEL c TRACK INFO i PLAY AT a\n");
printf(" READ d READ RAW w VOLUME v\n");
}
int main(void)
{ int handle;
unsigned char command=' ', ini=0, first=1, last=1;
unsigned int cmd, i,j,k, arg1,arg2,arg3;
struct cdrom_ti ti;
struct cdrom_tochdr tocHdr;
struct cdrom_subchnl subchnl;
struct cdrom_tocentry entry;
struct cdrom_msf msf;
union { struct cdrom_msf msf;
unsigned char buf[CD_FRAMESIZE_RAW];
} azt;
struct cdrom_volctrl volctrl;
printf("\nMini-Audio CD-Player V0.72 (C) 1994,1995,1996 W.Zimmermann\n");
handle=open("/dev/cdrom",O_RDWR);
ioctl(handle,CDROMRESUME);
if (handle<=0)
{ printf("Drive Error: already playing, no audio disk, door open\n");
printf(" or no permission (you must be ROOT in order to use this program)\n");
}
else
{ help();
while (1)
{ printf("Type command (h = help): ");
scanf("%s",&command);
switch (command)
{ case 'e': cmd=CDROMEJECT;
ioctl(handle,cmd);
break;
case 'p': if (!ini)
{ printf("Command not allowed - play track first\n");
}
else
{ cmd=CDROMPAUSE;
if (ioctl(handle,cmd)) printf("Drive Error\n");
}
break;
case 'r': if (!ini)
{ printf("Command not allowed - play track first\n");
}
else
{ cmd=CDROMRESUME;
if (ioctl(handle,cmd)) printf("Drive Error\n");
}
break;
case 's': cmd=CDROMPAUSE;
if (ioctl(handle,cmd)) printf("Drive error or already stopped\n");
cmd=CDROMSTOP;
if (ioctl(handle,cmd)) printf("Drive error\n");
break;
case 't': cmd=CDROMREADTOCHDR;
if (ioctl(handle,cmd,&tocHdr)) printf("Drive Error\n");
first=tocHdr.cdth_trk0;
last= tocHdr.cdth_trk1;
if ((first==0)||(first>last))
{ printf ("--could not read TOC\n");
}
else
{ printf("--first track: %d --last track: %d --enter track number: ",first,last);
cmd=CDROMPLAYTRKIND;
scanf("%i",&arg1);
ti.cdti_trk0=arg1;
if (ti.cdti_trk0<first) ti.cdti_trk0=first;
if (ti.cdti_trk0>last) ti.cdti_trk0=last;
ti.cdti_ind0=0;
ti.cdti_trk1=last;
ti.cdti_ind1=0;
if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
ini=1;
}
break;
case 'n': if (!ini++)
{ if (ioctl(handle,CDROMREADTOCHDR,&tocHdr)) printf("Drive Error\n");
first=tocHdr.cdth_trk0;
last= tocHdr.cdth_trk1;
ti.cdti_trk0=first-1;
}
if ((first==0)||(first>last))
{ printf ("--could not read TOC\n");
}
else
{ cmd=CDROMPLAYTRKIND;
if (++ti.cdti_trk0 > last) ti.cdti_trk0=last;
ti.cdti_ind0=0;
ti.cdti_trk1=last;
ti.cdti_ind1=0;
if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
ini=1;
}
break;
case 'l': if (!ini++)
{ if (ioctl(handle,CDROMREADTOCHDR,&tocHdr)) printf("Drive Error\n");
first=tocHdr.cdth_trk0;
last= tocHdr.cdth_trk1;
ti.cdti_trk0=first+1;
}
if ((first==0)||(first>last))
{ printf ("--could not read TOC\n");
}
else
{ cmd=CDROMPLAYTRKIND;
if (--ti.cdti_trk0 < first) ti.cdti_trk0=first;
ti.cdti_ind0=0;
ti.cdti_trk1=last;
ti.cdti_ind1=0;
if (ioctl(handle,cmd,&ti)) printf("Drive Error\n");
ini=1;
}
break;
case 'c': subchnl.cdsc_format=CDROM_MSF;
if (ioctl(handle,CDROMSUBCHNL,&subchnl))
printf("Drive Error\n");
else
{ printf("AudioStatus:%s Track:%d Mode:%d MSF=%d:%d:%d\n", \
subchnl.cdsc_audiostatus==CDROM_AUDIO_PLAY ? "PLAYING":"NOT PLAYING",\
subchnl.cdsc_trk,subchnl.cdsc_adr, \
subchnl.cdsc_absaddr.msf.minute, subchnl.cdsc_absaddr.msf.second, \
subchnl.cdsc_absaddr.msf.frame);
}
break;
case 'i': if (!ini)
{ printf("Command not allowed - play track first\n");
}
else
{ cmd=CDROMREADTOCENTRY;
printf("Track No.: ");
scanf("%d",&arg1);
entry.cdte_track=arg1;
if (entry.cdte_track<first) entry.cdte_track=first;
if (entry.cdte_track>last) entry.cdte_track=last;
entry.cdte_format=CDROM_MSF;
if (ioctl(handle,cmd,&entry))
{ printf("Drive error or invalid track no.\n");
}
else
{ printf("Mode %d Track, starts at %d:%d:%d\n", \
entry.cdte_adr,entry.cdte_addr.msf.minute, \
entry.cdte_addr.msf.second,entry.cdte_addr.msf.frame);
}
}
break;
case 'a': cmd=CDROMPLAYMSF;
printf("Address (min:sec:frame) ");
scanf("%d:%d:%d",&arg1,&arg2,&arg3);
msf.cdmsf_min0 =arg1;
msf.cdmsf_sec0 =arg2;
msf.cdmsf_frame0=arg3;
if (msf.cdmsf_sec0 > 59) msf.cdmsf_sec0 =59;
if (msf.cdmsf_frame0> 74) msf.cdmsf_frame0=74;
msf.cdmsf_min1=60;
msf.cdmsf_sec1=00;
msf.cdmsf_frame1=00;
if (ioctl(handle,cmd,&msf))
{ printf("Drive error or invalid address\n");
}
break;
#ifdef AZT_PRIVATE_IOCTLS /*not supported by every CDROM driver*/
case 'd': cmd=CDROMREADCOOKED;
printf("Address (min:sec:frame) ");
scanf("%d:%d:%d",&arg1,&arg2,&arg3);
azt.msf.cdmsf_min0 =arg1;
azt.msf.cdmsf_sec0 =arg2;
azt.msf.cdmsf_frame0=arg3;
if (azt.msf.cdmsf_sec0 > 59) azt.msf.cdmsf_sec0 =59;
if (azt.msf.cdmsf_frame0> 74) azt.msf.cdmsf_frame0=74;
if (ioctl(handle,cmd,&azt.msf))
{ printf("Drive error, invalid address or unsupported command\n");
}
k=0;
getchar();
for (i=0;i<128;i++)
{ printf("%4d:",i*16);
for (j=0;j<16;j++)
{ printf("%2x ",azt.buf[i*16+j]);
}
for (j=0;j<16;j++)
{ if (isalnum(azt.buf[i*16+j]))
printf("%c",azt.buf[i*16+j]);
else
printf(".");
}
printf("\n");
k++;
if (k>=20)
{ printf("press ENTER to continue\n");
getchar();
k=0;
}
}
break;
case 'w': cmd=CDROMREADRAW;
printf("Address (min:sec:frame) ");
scanf("%d:%d:%d",&arg1,&arg2,&arg3);
azt.msf.cdmsf_min0 =arg1;
azt.msf.cdmsf_sec0 =arg2;
azt.msf.cdmsf_frame0=arg3;
if (azt.msf.cdmsf_sec0 > 59) azt.msf.cdmsf_sec0 =59;
if (azt.msf.cdmsf_frame0> 74) azt.msf.cdmsf_frame0=74;
if (ioctl(handle,cmd,&azt))
{ printf("Drive error, invalid address or unsupported command\n");
}
k=0;
for (i=0;i<147;i++)
{ printf("%4d:",i*16);
for (j=0;j<16;j++)
{ printf("%2x ",azt.buf[i*16+j]);
}
for (j=0;j<16;j++)
{ if (isalnum(azt.buf[i*16+j]))
printf("%c",azt.buf[i*16+j]);
else
printf(".");
}
printf("\n");
k++;
if (k>=20)
{ getchar();
k=0;
}
}
break;
#endif
case 'v': cmd=CDROMVOLCTRL;
printf("--Channel 0 Left (0-255): ");
scanf("%d",&arg1);
printf("--Channel 1 Right (0-255): ");
scanf("%d",&arg2);
volctrl.channel0=arg1;
volctrl.channel1=arg2;
volctrl.channel2=0;
volctrl.channel3=0;
if (ioctl(handle,cmd,&volctrl))
{ printf("Drive error or unsupported command\n");
}
break;
case 'q': if (close(handle)) printf("Drive Error: CLOSE\n");
exit(0);
case 'h': help();
break;
default: printf("unknown command\n");
break;
}
}
}
return 0;
}

196
Documentation/cdrom/cdu31a
View File

@ -1,196 +0,0 @@
CDU31A/CDU33A Driver Info
-------------------------
Information on the Sony CDU31A/CDU33A CDROM driver for the Linux
kernel.
Corey Minyard (minyard@metronet.com)
Colossians 3:17
Crude Table of Contents
-----------------------
Setting Up the Hardware
Configuring the Kernel
Configuring as a Module
Driver Special Features
This device driver handles Sony CDU31A/CDU33A CDROM drives and
provides a complete block-level interface as well as an ioctl()
interface as specified in include/linux/cdrom.h). With this
interface, CDROMs can be accessed, standard audio CDs can be played
back normally, and CD audio information can be read off the drive.
Note that this will only work for CDU31A/CDU33A drives. Some vendors
market their drives as CDU31A compatible. They lie. Their drives are
really CDU31A hardware interface compatible (they can plug into the
same card). They are not software compatible.
Setting Up the Hardware
-----------------------
The CDU31A driver is unable to safely tell if an interface card is
present that it can use because the interface card does not announce
its presence in any way besides placing 4 I/O locations in memory. It
used to just probe memory and attempt commands, but Linus wisely asked
me to remove that because it could really screw up other hardware in
the system.
Because of this, you must tell the kernel where the drive interface
is, what interrupts are used, and possibly if you are on a PAS-16
soundcard.
If you have the Sony CDU31A/CDU33A drive interface card, the following
diagram will help you set it up. If you have another card, you are on
your own. You need to make sure that the I/O address and interrupt is
not used by another card in the system. You will need to know the I/O
address and interrupt you have set. Note that use of interrupts is
highly recommended, if possible, it really cuts down on CPU used.
Unfortunately, most soundcards do not support interrupts for their
CDROM interfaces. By default, the Sony interface card comes with
interrupts disabled.
+----------+-----------------+----------------------+
| JP1 | 34 Pin Conn | |
| JP2 +-----------------+ |
| JP3 |
| JP4 |
| +--+
| | +-+
| | | | External
| | | | Connector
| | | |
| | +-+
| +--+
| |
| +--------+
| |
+------------------------------------------+
JP1 sets the Base Address, using the following settings:
Address Pin 1 Pin 2
------- ----- -----
0x320 Short Short
0x330 Short Open
0x340 Open Short
0x360 Open Open
JP2 and JP3 configure the DMA channel; they must be set the same.
DMA Pin 1 Pin 2 Pin 3
--- ----- ----- -----
1 On Off On
2 Off On Off
3 Off Off On
JP4 Configures the IRQ:
IRQ Pin 1 Pin 2 Pin 3 Pin 4
--- ----- ----- ----- -----
3 Off Off On Off
4 Off Off* Off On
5 On Off Off Off
6 Off On Off Off
The documentation states to set this for interrupt
4, but I think that is a mistake.
Note that if you have another interface card, you will need to look at
the documentation to find the I/O base address. This is specified to
the SLCD.SYS driver for DOS with the /B: parameter, so you can look at
you DOS driver setup to find the address, if necessary.
Configuring the Kernel
----------------------
You must tell the kernel where the drive is at boot time. This can be
done at the Linux boot prompt, by using LILO, or by using Bootlin.
Note that this is no substitute for HOWTOs and LILO documentation, if
you are confused please read those for info on bootline configuration
and LILO.
At the linux boot prompt, press the ALT key and add the following line
after the boot name (you can let the kernel boot, it will tell you the
default boot name while booting):
cdu31a=<base address>,<interrupt>[,PAS]
The base address needs to have "0x" in front of it, since it is in
hex. For instance, to configure a drive at address 320 on interrupt 5,
use the following:
cdu31a=0x320,5
I use the following boot line:
cdu31a=0x1f88,0,PAS
because I have a PAS-16 which does not support interrupt for the
CDU31A interface.
Adding this as an append line at the beginning of the /etc/lilo.conf
file will set it for lilo configurations. I have the following as the
first line in my lilo.conf file:
append="cdu31a=0x1f88,0"
I'm not sure how to set up Bootlin (I have never used it), if someone
would like to fill in this section please do.
Configuring as a Module
-----------------------
The driver supports loading as a module. However, you must specify
the boot address and interrupt on the boot line to insmod. You can't
use modprobe to load it, since modprobe doesn't support setting
variables.
Anyway, I use the following line to load my driver as a module
/sbin/insmod /lib/modules/`uname -r`/misc/cdu31a.o cdu31a_port=0x1f88
You can set the following variables in the driver:
cdu31a_port=<I/O address> - sets the base I/O. If hex, put 0x in
front of it. This must be specified.
cdu31a_irq=<interrupt> - Sets the interrupt number. Leaving this
off will turn interrupts off.
Driver Special Features
-----------------------
This section describes features beyond the normal audio and CD-ROM
functions of the drive.
2048 byte buffer mode
If a disk is mounted with -o block=2048, data is copied straight from
the drive data port to the buffer. Otherwise, the readahead buffer
must be involved to hold the other 1K of data when a 1K block
operation is done. Note that with 2048 byte blocks you cannot execute
files from the CD.
XA compatibility
The driver should support XA disks for both the CDU31A and CDU33A. It
does this transparently, the using program doesn't need to set it.
Multi-Session
A multi-session disk looks just like a normal disk to the user. Just
mount one normally, and all the data should be there. A special
thanks to Koen for help with this!
Raw sector I/O
Using the CDROMREADAUDIO it is possible to read raw audio and data
tracks. Both operations return 2352 bytes per sector. On the data
tracks, the first 12 bytes is not returned by the drive and the value
of that data is indeterminate.

185
Documentation/cdrom/cm206
View File

@ -1,185 +0,0 @@
This is the readme file for the driver for the Philips/LMS cdrom drive
cm206 in combination with the cm260 host adapter card.
(c) 1995 David A. van Leeuwen
Changes since version 0.99
--------------------------
- Interfacing to the kernel is routed though an extra interface layer,
cdrom.c. This allows runtime-configurable `behavior' of the cdrom-drive,
independent of the driver.
Features since version 0.33
---------------------------
- Full audio support, that is, both workman, workbone and cdp work
now reasonably. Reading TOC still takes some time. xmcd has been
reported to run successfully.
- Made auto-probe code a little better, I hope
Features since version 0.28
---------------------------
- Full speed transfer rate (300 kB/s).
- Minimum kernel memory usage for buffering (less than 3 kB).
- Multisession support.
- Tray locking.
- Statistics of driver accessible to the user.
- Module support.
- Auto-probing of adapter card's base port and irq line,
also configurable at boot time or module load time.
Decide how you are going to use the driver. There are two
options:
(a) installing the driver as a resident part of the kernel
(b) compiling the driver as a loadable module
Further, you must decide if you are going to specify the base port
address and the interrupt request line of the adapter card cm260 as
boot options for (a), module parameters for (b), use automatic
probing of these values, or hard-wire your adaptor card's settings
into the source code. If you don't care, you can choose
autoprobing, which is the default. In that case you can move on to
the next step.
Compiling the kernel
--------------------
1) move to /usr/src/linux and do a
make config
If you have chosen option (a), answer yes to CONFIG_CM206 and
CONFIG_ISO9660_FS.
If you have chosen option (b), answer yes to CONFIG_MODVERSIONS
and no (!) to CONFIG_CM206 and CONFIG_ISO9660_FS.
2) then do a
make clean; make zImage; make modules
3) do the usual things to install a new image (backup the old one, run
`rdev -R zImage 1', copy the new image in place, run lilo). Might
be `make zlilo'.
Using the driver as a module
----------------------------
If you will only occasionally use the cd-rom driver, you can choose
option (b), install as a loadable module. You may have to re-compile
the module when you upgrade the kernel to a new version.
Since version 0.96, much of the functionality has been transferred to
a generic cdrom interface in the file cdrom.c. The module cm206.o
depends on cdrom.o. If the latter is not compiled into the kernel,
you must explicitly load it before cm206.o:
insmod /usr/src/linux/modules/cdrom.o
To install the module, you use the command, as root
insmod /usr/src/linux/modules/cm206.o
You can specify the base address on the command line as well as the irq
line to be used, e.g.
insmod /usr/src/linux/modules/cm206.o cm206=0x300,11
The order of base port and irq line doesn't matter; if you specify only
one, the other will have the value of the compiled-in default. You
may also have to install the file-system module `iso9660.o', if you
didn't compile that into the kernel.
Using the driver as part of the kernel
--------------------------------------
If you have chosen option (a), you can specify the base-port
address and irq on the lilo boot command line, e.g.:
LILO: linux cm206=0x340,11
This assumes that your linux kernel image keyword is `linux'.
If you specify either IRQ (3--11) or base port (0x300--0x370),
auto probing is turned off for both settings, thus setting the
other value to the compiled-in default.
Note that you can also put these parameters in the lilo configuration file:
# linux config
image = /vmlinuz
root = /dev/hda1
label = Linux
append = "cm206=0x340,11"
read-only
If module parameters and LILO config options don't work
-------------------------------------------------------
If autoprobing does not work, you can hard-wire the default values
of the base port address (CM206_BASE) and interrupt request line
(CM206_IRQ) into the file /usr/src/linux/drivers/cdrom/cm206.h. Change
the defines of CM206_IRQ and CM206_BASE.
Mounting the cdrom
------------------
1) Make sure that the right device is installed in /dev.
mknod /dev/cm206cd b 32 0
2) Make sure there is a mount point, e.g., /cdrom
mkdir /cdrom
3) mount using a command like this (run as root):
mount -rt iso9660 /dev/cm206cd /cdrom
4) For user-mounts, add a line in /etc/fstab
/dev/cm206cd /cdrom iso9660 ro,noauto,user
This will allow users to give the commands
mount /cdrom
umount /cdrom
If things don't work
--------------------
- Try to do a `dmesg' to find out if the driver said anything about
what is going wrong during the initialization.
- Try to do a `dd if=/dev/cm206cd | od -tc | less' to read from the
CD.
- Look in the /proc directory to see if `cm206' shows up under one of
`interrupts', `ioports', `devices' or `modules' (if applicable).
DISCLAIMER
----------
I cannot guarantee that this driver works, or that the hardware will
not be harmed, although I consider it most unlikely.
I hope that you'll find this driver in some way useful.
David van Leeuwen
david@tm.tno.nl
Note for Linux CDROM vendors
-----------------------------
You are encouraged to include this driver on your Linux CDROM. If
you do, you might consider sending me a free copy of that cd-rom.
You can contact me through my e-mail address, david@tm.tno.nl.
If this driver is compiled into a kernel to boot off a cdrom,
you should actually send me a free copy of that cd-rom.
Copyright
---------
The copyright of the cm206 driver for Linux is
(c) 1995 David A. van Leeuwen
The driver is released under the conditions of the GNU general public
license, which can be found in the file COPYING in the root of this
source tree.

60
Documentation/cdrom/gscd
View File

@ -1,60 +0,0 @@
Goldstar R420 CD-Rom device driver README
For all kind of other information about the GoldStar R420 CDROM
and this Linux device driver see the WWW page:
http://linux.rz.fh-hannover.de/~raupach
If you are the editor of a Linux CD, you should
enable gscd.c within your boot floppy kernel. Please,
send me one of your CDs for free.
This current driver version 0.4a only supports reading data from the disk.
Currently we have no audio and no multisession or XA support.
The polling interface is used, no DMA.
Sometimes the GoldStar R420 is sold in a 'Reveal Multimedia Kit'. This kit's
drive interface is compatible, too.
Installation
------------
Change to '/usr/src/linux/drivers/cdrom' and edit the file 'gscd.h'. Insert
the i/o address of your interface card.
The default base address is 0x340. This will work for most applications.
Address selection is accomplished by jumpers PN801-1 to PN801-4 on the
GoldStar Interface Card.
Appropriate settings are: 0x300, 0x310, 0x320, 0x330, 0x340, 0x350, 0x360
0x370, 0x380, 0x390, 0x3A0, 0x3B0, 0x3C0, 0x3D0, 0x3E0, 0x3F0
Then go back to '/usr/src/linux/' and 'make config' to build the new
configuration for your kernel. If you want to use the GoldStar driver
like a module, don't select 'GoldStar CDROM support'. By the way, you
have to include the iso9660 filesystem.
Now start compiling the kernel with 'make zImage'.
If you want to use the driver as a module, you have to do 'make modules'
and 'make modules_install', additionally.
Install your new kernel as usual - maybe you do it with 'make zlilo'.
Before you can use the driver, you have to
mknod /dev/gscd0 b 16 0
to create the appropriate device file (you only need to do this once).
If you use modules, you can try to insert the driver.
Say: 'insmod /usr/src/linux/modules/gscd.o'
or: 'insmod /usr/src/linux/modules/gscd.o gscd=<address>'
The driver should report its results.
That's it! Mount a disk, i.e. 'mount -rt iso9660 /dev/gscd0 /cdrom'
Feel free to report errors and suggestions to the following address.
Be sure, I'm very happy to receive your comments!
Oliver Raupach Hannover, Juni 1995
(raupach@nwfs1.rz.fh-hannover.de)

100
Documentation/cdrom/isp16
View File

@ -1,100 +0,0 @@
-- Documentation/cdrom/isp16
Docs by Eric van der Maarel <H.T.M.v.d.Maarel@marin.nl>
This is the README for version 0.6 of the cdrom interface on an
ISP16, MAD16 or Mozart sound card.
The detection and configuration of this interface used to be included
in both the sjcd and optcd cdrom driver. Drives supported by these
drivers came packed with Media Magic's multi media kit, which also
included the ISP16 card. The idea (thanks Leo Spiekman)
to move it from these drivers into a separate module and moreover, not to
rely on the MAD16 sound driver, are as follows:
-duplication of code in the kernel is a waste of resources and should
be avoided;
-however, kernels and notably those included with Linux distributions
(cf Slackware 3.0 included version 0.5 of the isp16 configuration
code included in the drivers) don't always come with sound support
included. Especially when they already include a bunch of cdrom drivers.
Hence, the cdrom interface should be configurable _independently_ of
sound support.
The ISP16, MAD16 and Mozart sound cards have an OPTi 82C928 or an
OPTi 82C929 chip. The interface on these cards should work with
any cdrom attached to the card, which is 'electrically' compatible
with Sanyo/Panasonic, Sony or Mitsumi non-ide drives. However, the
command sets for any proprietary drives may differ
(and hence may not be supported in the kernel) from these four types.
For a fact I know the interface works and the way of configuration
as described in this documentation works in combination with the
sjcd (in Sanyo/Panasonic compatibility mode) cdrom drivers
(probably with the optcd (in Sony compatibility mode) as well).
If you have such an OPTi based sound card and you want to use the
cdrom interface with a cdrom drive supported by any of the other cdrom
drivers, it will probably work. Please let me know any experience you
might have).
I understand that cards based on the OPTi 82C929 chips may be configured
(hardware jumpers that is) as an IDE interface. Initialisation of such a
card in this mode is not supported (yet?).
The suggestion to configure the ISP16 etc. sound card by booting DOS and
do a warm reboot to boot Linux somehow doesn't work, at least not
on my machine (IPC P90), with the OPTi 82C928 based card.
Booting the kernel through the boot manager LILO allows the use
of some command line options on the 'LILO boot:' prompt. At boot time
press Alt or Shift while the LILO prompt is written on the screen and enter
any kernel options. Alternatively these options may be used in
the appropriate section in /etc/lilo.conf. Adding 'append="<cmd_line_options>"'
will do the trick as well.
The syntax of 'cmd_line_options' is
isp16=[<port>[,<irq>[,<dma>]]][[,]<drive_type>]
If there is no ISP16 or compatibles detected, there's probably no harm done.
These options indicate the values that your cdrom drive has been (or will be)
configured to use.
Valid values for the base i/o address are:
port=0x340,0x320,0x330,0x360
for the interrupt request number
irq=0,3,5,7,9,10,11
for the direct memory access line
dma=0,3,5,6,7
and for the type of drive
drive_type=noisp16,Sanyo,Panasonic,Sony,Mitsumi.
Note that these options are case sensitive.
The values 0 for irq and dma indicate that they are not used, and
the drive will be used in 'polling' mode. The values 5 and 7 for irq
should be avoided in order to avoid any conflicts with optional
sound card configuration.
The syntax of the command line does not allow the specification of
irq when there's nothing specified for the base address and no
specification of dma when there is no specification of irq.
The value 'noisp16' for drive_type, which may be used as the first
non-integer option value (e.g. 'isp16=noisp16'), makes sure that probing
for and subsequent configuration of an ISP16-compatible card is skipped
all together. This can be useful to overcome possible conflicts which
may arise while the kernel is probing your hardware.
The default values are
port=0x340
irq=0
dma=0
drive_type=Sanyo
reflecting my own configuration. The defaults can be changed in
the file linux/drivers/cdrom/ips16.h.
The cdrom interface can be configured at run time by loading the
initialisation driver as a module. In that case, the interface
parameters can be set by giving appropriate values on the command
line. Configuring the driver can then be done by the following
command (assuming you have iso16.o installed in a proper place):
insmod isp16.o isp16_cdrom_base=<port> isp16_cdrom_irq=<irq> \
isp16_cdrom_dma=<dma> isp16_cdrom_type=<drive_type>
where port, irq, dma and drive_type can have any of the values mentioned
above.
Have fun!

29
Documentation/cdrom/mcdx
View File

@ -1,29 +0,0 @@
If you are using the driver as a module, you can specify your ports and IRQs
like
# insmod mcdx.o mcdx=0x300,11,0x304,5
and so on ("address,IRQ" pairs).
This will override the configuration in mcdx.h.
This driver:
o handles XA and (hopefully) multi session CDs as well as
ordinary CDs;
o supports up to 5 drives (of course, you'll need free
IRQs, i/o ports and slots);
o plays audio
This version doesn't support yet:
o shared IRQs (but it seems to be possible - I've successfully
connected two drives to the same irq. So it's `only' a
problem of the driver.)
This driver never will:
o Read digital audio (i.e. copy directly), due to missing
hardware features.
heiko@lotte.sax.de

57
Documentation/cdrom/optcd
View File

@ -1,57 +0,0 @@
This is the README file for the Optics Storage 8000 AT CDROM device driver.
This is the driver for the so-called 'DOLPHIN' drive, with the 34-pin
Sony-compatible interface. For the IDE-compatible Optics Storage 8001
drive, you will want the ATAPI CDROM driver. The driver also seems to
work with the Lasermate CR328A. If you have a drive that works with
this driver, and that doesn't report itself as DOLPHIN, please drop me
a mail.
The support for multisession CDs is in ALPHA stage. If you use it,
please mail me your experiences. Multisession support can be disabled
at compile time.
You can find some older versions of the driver at
dutette.et.tudelft.nl:/pub/linux/
and at Eberhard's mirror
ftp.gwdg.de:/pub/linux/cdrom/drivers/optics/
Before you can use the driver, you have to create the device file once:
# mknod /dev/optcd0 b 17 0
To specify the base address if the driver is "compiled-in" to your kernel,
you can use the kernel command line item (LILO option)
optcd=0x340
with the right address.
If you have compiled optcd as a module, you can load it with
# insmod /usr/src/linux/modules/optcd.o
or
# insmod /usr/src/linux/modules/optcd.o optcd=0x340
with the matching address value of your interface card.
The driver employs a number of buffers to do read-ahead and block size
conversion. The number of buffers is configurable in optcd.h, and has
influence on the driver performance. For my machine (a P75), 6 buffers
seems optimal, as can be seen from this table:
#bufs kb/s %cpu
1 97 0.1
2 191 0.3
3 188 0.2
4 246 0.3
5 189 19
6 280 0.4
7 281 7.0
8 246 2.8
16 281 3.4
If you get a throughput significantly below 300 kb/s, try tweaking
N_BUFS, and don't forget to mail me your results!
I'd appreciate success/failure reports. If you find a bug, try
recompiling the driver with some strategically chosen debug options
(these can be found in optcd.h) and include the messages generated in
your bug report. Good luck.
Leo Spiekman (spiekman@dutette.et.tudelft.nl)

1061
Documentation/cdrom/sbpcd
View File

File diff suppressed because it is too large Load Diff

60
Documentation/cdrom/sjcd
View File

@ -1,60 +0,0 @@
-- Documentation/cdrom/sjcd
80% of the work takes 20% of the time,
20% of the work takes 80% of the time...
(Murphy's law)
Once started, training can not be stopped...
(Star Wars)
This is the README for the sjcd cdrom driver, version 1.6.
This file is meant as a tips & tricks edge for the usage of the SANYO CDR-H94A
cdrom drive. It will grow as the questions arise. ;-)
For info on configuring the ISP16 sound card look at Documentation/cdrom/isp16.
The driver should work with any of the Panasonic, Sony or Mitsumi style
CDROM interfaces.
The cdrom interface on Media Magic's soft configurable sound card ISP16,
which used to be included in the driver, is now supported in a separate module.
This initialisation module will probably also work with other interfaces
based on an OPTi 82C928 or 82C929 chip (like MAD16 and Mozart): see the
documentation Documentation/cdrom/isp16.
The device major for sjcd is 18, and minor is 0. Create a block special
file in your /dev directory (e.g., /dev/sjcd) with these numbers.
(For those who don't know, being root and doing the following should do
the trick:
mknod -m 644 /dev/sjcd b 18 0
and mount the cdrom by /dev/sjcd).
The default configuration parameters are:
base address 0x340
no irq
no dma
(Actually the CDR-H94A doesn't know how to use irq and dma.)
As of version 1.2, setting base address at boot time is supported
through the use of command line options: type at the "boot:" prompt:
linux sjcd=<base_address>
(where you would use the kernel labeled "linux" in lilo's configuration
file /etc/lilo.conf). You could also use 'append="sjcd=<configuration_info>"'
in the appropriate section of /etc/lilo.conf
If you're building a kernel yourself you can set your default base
i/o address with SJCD_BASE_ADDR in /usr/src/linux/drivers/cdrom/sjcd.h.
The sjcd driver supports being loaded as a module. The following
command will set the base i/o address on the fly (assuming you
have installed the module in an appropriate place).
insmod sjcd.o sjcd_base=<base_address>
Have fun!
If something is wrong, please email to vadim@rbrf.ru
or vadim@ipsun.ras.ru
or model@cecmow.enet.dec.com
or H.T.M.v.d.Maarel@marin.nl
It happens sometimes that Vadim is not reachable by mail. For these
instances, Eric van der Maarel will help too.
Vadim V. Model, Eric van der Maarel, Eberhard Moenkeberg

122
Documentation/cdrom/sonycd535
View File

@ -1,122 +0,0 @@
README FOR LINUX SONY CDU-535/531 DRIVER
========================================
This is the Sony CDU-535 (and 531) driver version 0.7 for Linux.
I do not think I have the documentation to add features like DMA support
so if anyone else wants to pursue it or help me with it, please do.
(I need to see what was done for the CDU-31A driver -- perhaps I can
steal some of that code.)
This is a Linux device driver for the Sony CDU-535 CDROM drive. This is
one of the older Sony drives with its own interface card (Sony bus).
The DOS driver for this drive is named SONY_CDU.SYS - when you boot DOS
your drive should be identified as a SONY CDU-535. The driver works
with a CDU-531 also. One user reported that the driver worked on drives
OEM'ed by Procomm, drive and interface board were labelled Procomm.
The Linux driver is based on Corey Minyard's sonycd 0.3 driver for
the CDU-31A. Ron Jeppesen just changed the commands that were sent
to the drive to correspond to the CDU-535 commands and registers.
There were enough changes to let bugs creep in but it seems to be stable.
Ron was able to tar an entire CDROM (should read all blocks) and built
ghostview and xfig off Walnut Creek's X11R5/GNU CDROM. xcdplayer and
workman work with the driver. Others have used the driver without
problems except those dealing with wait loops (fixed in third release).
Like Minyard's original driver this one uses a polled interface (this
is also the default setup for the DOS driver). It has not been tried
with interrupts or DMA enabled on the board.
REQUIREMENTS
============
- Sony CDU-535 drive, preferably without interrupts and DMA
enabled on the card.
- Drive must be set up as unit 1. Only the first unit will be
recognized
- You must enter your interface address into
/usr/src/linux/drivers/cdrom/sonycd535.h and build the
appropriate kernel or use the "kernel command line" parameter
sonycd535=0x320
with the correct interface address.
NOTES:
======
1) The drive MUST be turned on when booting or it will not be recognized!
(but see comments on modularized version below)
2) when the cdrom device is opened the eject button is disabled to keep the
user from ejecting a mounted disk and replacing it with another.
Unfortunately xcdplayer and workman also open the cdrom device so you
have to use the eject button in the software. Keep this in mind if your
cdrom player refuses to give up its disk -- exit workman or xcdplayer, or
umount the drive if it has been mounted.
THANKS
======
Many thanks to Ron Jeppesen (ronj.an@site007.saic.com) for getting
this project off the ground. He wrote the initial release
and the first two patches to this driver (0.1, 0.2, and 0.3).
Thanks also to Eberhard Moenkeberg (emoenke@gwdg.de) for prodding
me to place this code into the mainstream Linux source tree
(as of Linux version 1.1.91), as well as some patches to make
it a better device citizen. Further thanks to Joel Katz
<joelkatz@webchat.org> for his MODULE patches (see details below),
Porfiri Claudio <C.Porfiri@nisms.tei.ericsson.se> for patches
to make the driver work with the older CDU-510/515 series, and
Heiko Eissfeldt <heiko@colossus.escape.de> for pointing out that
the verify_area() checks were ignoring the results of said checks
(note: verify_area() has since been replaced by access_ok()).
(Acknowledgments from Ron Jeppesen in the 0.3 release:)
Thanks to Corey Minyard who wrote the original CDU-31A driver on which
this driver is based. Thanks to Ken Pizzini and Bob Blair who provided
patches and feedback on the first release of this driver.
Ken Pizzini
ken@halcyon.com
------------------------------------------------------------------------------
(The following is from Joel Katz <joelkatz@webchat.org>.)
To build a version of sony535.o that can be installed as a module,
use the following command:
gcc -c -D__KERNEL__ -DMODULE -O2 sonycd535.c -o sonycd535.o
To install the module, simply type:
insmod sony535.o
or
insmod sony535.o sonycd535=<address>
And to remove it:
rmmod sony535
The code checks to see if MODULE is defined and behaves as it used
to if MODULE is not defined. That means your patched file should behave
exactly as it used to if compiled into the kernel.
I have an external drive, and I usually leave it powered off. I used
to have to reboot if I needed to use the CDROM drive. Now I don't.
Even if you have an internal drive, why waste the 96K of memory
(unswappable) that the driver uses if you use your CD-ROM drive infrequently?
This driver will not install (whether compiled in or loaded as a
module) if the CDROM drive is not available during its initialization. This
means that you can have the driver compiled into the kernel and still load
the module later (assuming the driver doesn't install itself during
power-on). This only wastes 12K when you boot with the CDROM drive off.
This is what I usually do; I leave the driver compiled into the
kernel, but load it as a module if I powered the system up with the drive
off and then later decided to use the CDROM drive.
Since the driver only uses a single page to point to the chunks,
attempting to set the buffer cache to more than 2 Megabytes would be very
bad; don't do that.

32
Documentation/dvb/bt8xx.txt
View File

@ -9,19 +9,29 @@ for accessing the i2c bus and the gpio pins of the bt8xx chipset.
Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
Compiling kernel please enable:
a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux"
b.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Enable Video for Linux API 1 (DEPRECATED)"
b.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Video Capture Adapters" => "BT848 Video For Linux"
c.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
Please use the following options with care as deselection of drivers which are in fact necessary
may result in DVB devices that cannot be tuned due to lack of driver support:
You can save RAM by deselecting every frontend module that your DVB card does not need.
First please remove the static dependency of DVB card drivers on all frontend modules for all possible card variants by enabling:
d.) "Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Load and attach frontend modules as needed"
If you know the frontend driver that your card needs please enable:
e.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
=> "DVB for Linux" "DVB Core Support" "Customise DVB Frontends" => "Customise the frontend modules to build"
Then please select your card-specific frontend module.
2) Loading Modules
==================
In default cases bttv is loaded automatically.
To load the backend either place dvb-bt8xx in etc/modules, or apply manually:
$ modprobe dvb-bt8xx
All frontends will be loaded automatically.
Regular case: If the bttv driver detects a bt8xx-based DVB card, all frontend and backend modules will be loaded automatically.
Exceptions are:
- Old TwinHan DST cards or clones with or without CA slot and not containing an Eeprom.
People running udev please see Documentation/dvb/udev.txt.
In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary:
@ -30,7 +40,6 @@ In the following cases overriding the PCI type detection for dvb-bt8xx might be
------------------------------
$ modprobe bttv card=113
$ modprobe dvb-bt8xx
$ modprobe dst
Useful parameters for verbosity level and debugging the dst module:
@ -65,10 +74,9 @@ DViCO FusionHDTV 5 Lite: 135
Notice: The order of the card ID should be uprising:
Example:
$ modprobe bttv card=113 card=135
$ modprobe dvb-bt8xx
For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
In case of further problems send questions to the mailing list: www.linuxdvb.org.
In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org.
Authors: Richard Walker,
Jamie Honan,

63
Documentation/dvb/get_dvb_firmware
View File

@ -24,7 +24,8 @@ use IO::Handle;
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird");
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1");
# Check args
syntax() if (scalar(@ARGV) != 1);
@ -56,7 +57,7 @@ syntax();
sub sp8870 {
my $sourcefile = "tt_Premium_217g.zip";
my $url = "http://www.technotrend.de/new/217g/$sourcefile";
my $url = "http://www.softwarepatch.pl/9999ccd06a4813cb827dbb0005071c71/$sourcefile";
my $hash = "53970ec17a538945a6d8cb608a7b3899";
my $outfile = "dvb-fe-sp8870.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
@ -210,6 +211,45 @@ sub dec3000s {
$outfile;
}
sub opera1{
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
checkstandard();
my $fwfile1="dvb-usb-opera1-fpga-01.fw";
my $fwfile2="dvb-usb-opera-01.fw";
extract("2830SCap2.sys", 0x62e8, 55024, "$tmpdir/opera1-fpga.fw");
extract("2830SLoad2.sys",0x3178,0x3685-0x3178,"$tmpdir/fw1part1");
extract("2830SLoad2.sys",0x0980,0x3150-0x0980,"$tmpdir/fw1part2");
delzero("$tmpdir/fw1part1","$tmpdir/fw1part1-1");
delzero("$tmpdir/fw1part2","$tmpdir/fw1part2-1");
verify("$tmpdir/fw1part1-1","5e0909858fdf0b5b09ad48b9fe622e70");
verify("$tmpdir/fw1part2-1","d6e146f321427e931df2c6fcadac37a1");
verify("$tmpdir/opera1-fpga.fw","0f8133f5e9051f5f3c1928f7e5a1b07d");
my $RES1="\x01\x92\x7f\x00\x01\x00";
my $RES0="\x01\x92\x7f\x00\x00\x00";
my $DAT1="\x01\x00\xe6\x00\x01\x00";
my $DAT0="\x01\x00\xe6\x00\x00\x00";
open FW,">$tmpdir/opera.fw";
print FW "$RES1";
print FW "$DAT1";
print FW "$RES1";
print FW "$DAT1";
appendfile(FW,"$tmpdir/fw1part1-1");
print FW "$RES0";
print FW "$DAT0";
print FW "$RES1";
print FW "$DAT1";
appendfile(FW,"$tmpdir/fw1part2-1");
print FW "$RES1";
print FW "$DAT1";
print FW "$RES0";
print FW "$DAT0";
copy ("$tmpdir/opera1-fpga.fw",$fwfile1);
copy ("$tmpdir/opera.fw",$fwfile2);
$fwfile1.",".$fwfile2;
}
sub vp7041 {
my $sourcefile = "2.422.zip";
@ -440,6 +480,25 @@ sub appendfile {
close(INFILE);
}
sub delzero{
my ($infile,$outfile) =@_;
open INFILE,"<$infile";
open OUTFILE,">$outfile";
while (1){
$rcount=sysread(INFILE,$buf,22);
$len=ord(substr($buf,0,1));
print OUTFILE substr($buf,0,1);
print OUTFILE substr($buf,2,$len+3);
last if ($rcount<1);
printf OUTFILE "%c",0;
#print $len." ".length($buf)."\n";
}
close(INFILE);
close(OUTFILE);
}
sub syntax() {
print STDERR "syntax: get_dvb_firmware <component>\n";
print STDERR "Supported components:\n";

27
Documentation/dvb/opera-firmware.txt Normal file
View File

@ -0,0 +1,27 @@
To extract the firmware for the Opera DVB-S1 USB-Box
you need to copy the files:
2830SCap2.sys
2830SLoad2.sys
from the windriver disk into this directory.
Then run
./get_dvb_firware opera1
and after that you have 2 files:
dvb-usb-opera-01.fw
dvb-usb-opera1-fpga-01.fw
in here.
Copy them into /lib/firmware/ .
After that the driver can load the firmware
(if you have enabled firmware loading
in kernel config and have hotplug running).
Marco Gittler <g.marco@freenet.de>

4
Documentation/fault-injection/failcmd.sh
View File

@ -1,4 +0,0 @@
#!/bin/bash
echo 1 > /proc/self/make-it-fail
exec $*

31
Documentation/fault-injection/failmodule.sh
View File

@ -1,31 +0,0 @@
#!/bin/bash
#
# Usage: failmodule <failname> <modulename> [stacktrace-depth]
#
# <failname>: "failslab", "fail_alloc_page", or "fail_make_request"
#
# <modulename>: module name that you want to inject faults.
#
# [stacktrace-depth]: the maximum number of stacktrace walking allowed
#
STACKTRACE_DEPTH=5
if [ $# -gt 2 ]; then
STACKTRACE_DEPTH=$3
fi
if [ ! -d /debug/$1 ]; then
echo "Fault-injection $1 does not exist" >&2
exit 1
fi
if [ ! -d /sys/module/$2 ]; then
echo "Module $2 does not exist" >&2
exit 1
fi
# Disable any fault injection
echo 0 > /debug/$1/stacktrace-depth
echo `cat /sys/module/$2/sections/.text` > /debug/$1/require-start
echo `cat /sys/module/$2/sections/.exit.text` > /debug/$1/require-end
echo $STACKTRACE_DEPTH > /debug/$1/stacktrace-depth

108
Documentation/fault-injection/fault-injection.txt
View File

@ -103,6 +103,11 @@ configuration of fault-injection capabilities.
default is 'N', setting it to 'Y' will inject failures
only into non-sleep allocations (GFP_ATOMIC allocations).
- /debug/fail_page_alloc/min-order:
specifies the minimum page allocation order to be injected
failures.
o Boot option
In order to inject faults while debugfs is not available (early boot time),
@ -156,70 +161,77 @@ o add a hook to insert failures
Application Examples
--------------------
o inject slab allocation failures into module init/cleanup code
o Inject slab allocation failures into module init/exit code
------------------------------------------------------------------------------
#!/bin/bash
FAILCMD=Documentation/fault-injection/failcmd.sh
BLACKLIST="root_plug evbug"
FAILTYPE=failslab
echo Y > /debug/$FAILTYPE/task-filter
echo 10 > /debug/$FAILTYPE/probability
echo 100 > /debug/$FAILTYPE/interval
echo -1 > /debug/$FAILTYPE/times
echo 0 > /debug/$FAILTYPE/space
echo 2 > /debug/$FAILTYPE/verbose
echo 1 > /debug/$FAILTYPE/ignore-gfp-wait
FAILNAME=failslab
echo Y > /debug/$FAILNAME/task-filter
echo 10 > /debug/$FAILNAME/probability
echo 100 > /debug/$FAILNAME/interval
echo -1 > /debug/$FAILNAME/times
echo 2 > /debug/$FAILNAME/verbose
echo 1 > /debug/$FAILNAME/ignore-gfp-wait
blacklist()
faulty_system()
{
echo $BLACKLIST | grep $1 > /dev/null 2>&1
bash -c "echo 1 > /proc/self/make-it-fail && exec $*"
}
oops()
{
dmesg | grep BUG > /dev/null 2>&1
}
if [ $# -eq 0 ]
then
echo "Usage: $0 modulename [ modulename ... ]"
exit 1
fi
find /lib/modules/`uname -r` -name '*.ko' -exec basename {} .ko \; |
while read i
do
oops && exit 1
for m in $*
do
echo inserting $m...
faulty_system modprobe $m
if ! blacklist $i
then
echo inserting $i...
bash $FAILCMD modprobe $i
fi
done
lsmod | awk '{ if ($3 == 0) { print $1 } }' |
while read i
do
oops && exit 1
if ! blacklist $i
then
echo removing $i...
bash $FAILCMD modprobe -r $i
fi
done
echo removing $m...
faulty_system modprobe -r $m
done
------------------------------------------------------------------------------
o inject slab allocation failures only for a specific module
o Inject page allocation failures only for a specific module
------------------------------------------------------------------------------
#!/bin/bash
FAILMOD=Documentation/fault-injection/failmodule.sh
FAILTYPE=fail_page_alloc
module=$1
echo injecting errors into the module $1...
if [ -z $module ]
then
echo "Usage: $0 <modulename>"
exit 1
fi
modprobe $1
bash $FAILMOD failslab $1 10
echo 25 > /debug/failslab/probability
modprobe $module
------------------------------------------------------------------------------
if [ ! -d /sys/module/$module/sections ]
then
echo Module $module is not loaded
exit 1
fi
cat /sys/module/$module/sections/.text > /debug/$FAILTYPE/require-start
cat /sys/module/$module/sections/.data > /debug/$FAILTYPE/require-end
echo N > /debug/$FAILTYPE/task-filter
echo 10 > /debug/$FAILTYPE/probability
echo 100 > /debug/$FAILTYPE/interval
echo -1 > /debug/$FAILTYPE/times
echo 0 > /debug/$FAILTYPE/space
echo 2 > /debug/$FAILTYPE/verbose
echo 1 > /debug/$FAILTYPE/ignore-gfp-wait
echo 1 > /debug/$FAILTYPE/ignore-gfp-highmem
echo 10 > /debug/$FAILTYPE/stacktrace-depth
trap "echo 0 > /debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT
echo "Injecting errors into the module $module... (interrupt to stop)"
sleep 1000000

110
Documentation/feature-removal-schedule.txt
View File

@ -41,24 +41,6 @@ Who: Pavel Machek <pavel@suse.cz>
---------------------------
What: RAW driver (CONFIG_RAW_DRIVER)
When: December 2005
Why: declared obsolete since kernel 2.6.3
O_DIRECT can be used instead
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
When: June 2007
Why: Deprecated in favour of the more efficient and robust rawiso interface.
Affected are applications which use the deprecated part of libraw1394
(raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv,
raw1394_stop_iso_rcv) or bypass libraw1394.
Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
---------------------------
What: old NCR53C9x driver
When: October 2007
Why: Replaced by the much better esp_scsi driver. Actual low-level
@ -129,13 +111,6 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: drivers depending on OSS_OBSOLETE_DRIVER
When: options in 2.6.20, code in 2.6.22
Why: OSS drivers with ALSA replacements
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
(temporary transition config option provided until then)
The transition config option will also be removed at the same time.
@ -206,28 +181,6 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
When: December 2006
Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
functionally very much similar. They talk to ACPI in same way. Only
difference between them is the way they do frequency transitions.
One uses MSRs and the other one uses IO ports. Functionaliy of
speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
That means one common driver will support all Intel Enhanced Speedstep
capable CPUs. That means less confusion over name of
speedstep-centrino driver (with that driver supposed to be used on
non-centrino platforms). That means less duplication of code and
less maintenance effort and no possibility of these two drivers
going out of sync.
Current users of speedstep_centrino with ACPI hooks are requested to
switch over to acpi-cpufreq driver. speedstep-centrino will continue
to work using older non-ACPI static table based scheme even after this
date.
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
---------------------------
What: /sys/firmware/acpi/namespace
When: 2.6.21
Why: The ACPI namespace is effectively the symbol list for
@ -258,14 +211,6 @@ Who: Len Brown <len.brown@intel.com>
---------------------------
What: sk98lin network driver
When: July 2007
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
replaced by the skge driver.
Who: Stephen Hemminger <shemminger@osdl.org>
---------------------------
What: Compaq touchscreen device emulation
When: Oct 2007
Files: drivers/input/tsdev.c
@ -280,25 +225,6 @@ Who: Richard Purdie <rpurdie@rpsys.net>
---------------------------
What: Multipath cached routing support in ipv4
When: in 2.6.23
Why: Code was merged, then submitter immediately disappeared leaving
us with no maintainer and lots of bugs. The code should not have
been merged in the first place, and many aspects of it's
implementation are blocking more critical core networking
development. It's marked EXPERIMENTAL and no distribution
enables it because it cause obscure crashes due to unfixable bugs
(interfaces don't return errors so memory allocation can't be
handled, calling contexts of these interfaces make handling
errors impossible too because they get called after we've
totally commited to creating a route object, for example).
This problem has existed for years and no forward progress
has ever been made, and nobody steps up to try and salvage
this code, so we're going to finally just get rid of it.
Who: David S. Miller <davem@davemloft.net>
---------------------------
What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer)
When: December 2007
Why: These functions are a leftover from 2.4 times. They have several
@ -323,6 +249,14 @@ Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: 'time' kernel boot parameter
When: January 2008
Why: replaced by 'printk.time=<value>' so that printk timestamps can be
enabled or disabled as needed
Who: Randy Dunlap <randy.dunlap@oracle.com>
---------------------------
What: drivers depending on OSS_OBSOLETE
When: options in 2.6.23, code in 2.6.25
Why: obsolete OSS drivers
@ -348,3 +282,31 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
What: Legacy RTC drivers (under drivers/i2c/chips)
When: November 2007
Why: Obsolete. We have a RTC subsystem with better drivers.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: iptables SAME target
When: 1.1. 2008
Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h
Why: Obsolete for multiple years now, NAT core provides the same behaviour.
Unfixable broken wrt. 32/64 bit cleanness.
Who: Patrick McHardy <kaber@trash.net>
---------------------------
What: The arch/ppc and include/asm-ppc directories
When: Jun 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
platforms. Currently there are efforts underway to port the remaining
arch/ppc platforms to the merged tree. New submissions to the arch/ppc
tree have been frozen with the 2.6.22 kernel release and that tree will
remain in bug-fix only mode until its scheduled removal. Platforms
that are not ported by June 2008 will be removed due to the lack of an
interested maintainer.
Who: linuxppc-dev@ozlabs.org
---------------------------

57
Documentation/filesystems/configfs/configfs.txt
View File

@ -238,6 +238,8 @@ config_item_type.
struct config_group *(*make_group)(struct config_group *group,
const char *name);
int (*commit_item)(struct config_item *item);
void (*disconnect_notify)(struct config_group *group,
struct config_item *item);
void (*drop_item)(struct config_group *group,
struct config_item *item);
};
@ -268,6 +270,16 @@ the item in other threads, the memory is safe. It may take some time
for the item to actually disappear from the subsystem's usage. But it
is gone from configfs.
When drop_item() is called, the item's linkage has already been torn
down. It no longer has a reference on its parent and has no place in
the item hierarchy. If a client needs to do some cleanup before this
teardown happens, the subsystem can implement the
ct_group_ops->disconnect_notify() method. The method is called after
configfs has removed the item from the filesystem view but before the
item is removed from its parent group. Like drop_item(),
disconnect_notify() is void and cannot fail. Client subsystems should
not drop any references here, as they still must do it in drop_item().
A config_group cannot be removed while it still has child items. This
is implemented in the configfs rmdir(2) code. ->drop_item() will not be
called, as the item has not been dropped. rmdir(2) will fail, as the
@ -280,18 +292,18 @@ tells configfs to make the subsystem appear in the file tree.
struct configfs_subsystem {
struct config_group su_group;
struct semaphore su_sem;
struct mutex su_mutex;
};
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
A subsystem consists of a toplevel config_group and a semaphore.
A subsystem consists of a toplevel config_group and a mutex.
The group is where child config_items are created. For a subsystem,
this group is usually defined statically. Before calling
configfs_register_subsystem(), the subsystem must have initialized the
group via the usual group _init() functions, and it must also have
initialized the semaphore.
initialized the mutex.
When the register call returns, the subsystem is live, and it
will be visible via configfs. At that point, mkdir(2) can be called and
the subsystem must be ready for it.
@ -303,7 +315,7 @@ subsystem/group and the simple_child item in configfs_example.c It
shows a trivial object displaying and storing an attribute, and a simple
group creating and destroying these children.
[Hierarchy Navigation and the Subsystem Semaphore]
[Hierarchy Navigation and the Subsystem Mutex]
There is an extra bonus that configfs provides. The config_groups and
config_items are arranged in a hierarchy due to the fact that they
@ -314,19 +326,19 @@ and config_item->ci_parent structure members.
A subsystem can navigate the cg_children list and the ci_parent pointer
to see the tree created by the subsystem. This can race with configfs'
management of the hierarchy, so configfs uses the subsystem semaphore to
management of the hierarchy, so configfs uses the subsystem mutex to
protect modifications. Whenever a subsystem wants to navigate the
hierarchy, it must do so under the protection of the subsystem
semaphore.
mutex.
A subsystem will be prevented from acquiring the semaphore while a newly
A subsystem will be prevented from acquiring the mutex while a newly
allocated item has not been linked into this hierarchy. Similarly, it
will not be able to acquire the semaphore while a dropping item has not
will not be able to acquire the mutex while a dropping item has not
yet been unlinked. This means that an item's ci_parent pointer will
never be NULL while the item is in configfs, and that an item will only
be in its parent's cg_children list for the same duration. This allows
a subsystem to trust ci_parent and cg_children while they hold the
semaphore.
mutex.
[Item Aggregation Via symlink(2)]
@ -386,6 +398,33 @@ As a consequence of this, default_groups cannot be removed directly via
rmdir(2). They also are not considered when rmdir(2) on the parent
group is checking for children.
[Dependant Subsystems]
Sometimes other drivers depend on particular configfs items. For
example, ocfs2 mounts depend on a heartbeat region item. If that
region item is removed with rmdir(2), the ocfs2 mount must BUG or go
readonly. Not happy.
configfs provides two additional API calls: configfs_depend_item() and
configfs_undepend_item(). A client driver can call
configfs_depend_item() on an existing item to tell configfs that it is
depended on. configfs will then return -EBUSY from rmdir(2) for that
item. When the item is no longer depended on, the client driver calls
configfs_undepend_item() on it.
These API cannot be called underneath any configfs callbacks, as
they will conflict. They can block and allocate. A client driver
probably shouldn't calling them of its own gumption. Rather it should
be providing an API that external subsystems call.
How does this work? Imagine the ocfs2 mount process. When it mounts,
it asks for a heartbeat region item. This is done via a call into the
heartbeat code. Inside the heartbeat code, the region item is looked
up. Here, the heartbeat code calls configfs_depend_item(). If it
succeeds, then heartbeat knows the region is safe to give to ocfs2.
If it fails, it was being torn down anyway, and heartbeat can gracefully
pass up an error.
[Committable Items]
NOTE: Committable items are currently unimplemented.

2
Documentation/filesystems/configfs/configfs_example.c
View File

@ -453,7 +453,7 @@ static int __init configfs_example_init(void)
subsys = example_subsys[i];
config_group_init(&subsys->su_group);
init_MUTEX(&subsys->su_sem);
mutex_init(&subsys->su_mutex);
ret = configfs_register_subsystem(subsys);
if (ret) {
printk(KERN_ERR "Error %d while registering subsystem %s\n",

0
Documentation/ecryptfs.txt → Documentation/filesystems/ecryptfs.txt
View File

80
Documentation/filesystems/proc.txt
View File

@ -171,7 +171,9 @@ read the file /proc/PID/status:
This shows you nearly the same information you would get if you viewed it with
the ps command. In fact, ps uses the proc file system to obtain its
information. The statm file contains more detailed information about the
process memory usage. Its seven fields are explained in Table 1-2.
process memory usage. Its seven fields are explained in Table 1-2. The stat
file contains details information about the process itself. Its fields are
explained in Table 1-3.
Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
@ -188,16 +190,65 @@ Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
dt number of dirty pages (always 0 on 2.6)
..............................................................................
Table 1-3: Contents of the stat files (as of 2.6.22-rc3)
..............................................................................
Field Content
pid process id
tcomm filename of the executable
state state (R is running, S is sleeping, D is sleeping in an
uninterruptible wait, Z is zombie, T is traced or stopped)
ppid process id of the parent process
pgrp pgrp of the process
sid session id
tty_nr tty the process uses
tty_pgrp pgrp of the tty
flags task flags
min_flt number of minor faults
cmin_flt number of minor faults with child's
maj_flt number of major faults
cmaj_flt number of major faults with child's
utime user mode jiffies
stime kernel mode jiffies
cutime user mode jiffies with child's
cstime kernel mode jiffies with child's
priority priority level
nice nice level
num_threads number of threads
start_time time the process started after system boot
vsize virtual memory size
rss resident set memory size
rsslim current limit in bytes on the rss
start_code address above which program text can run
end_code address below which program text can run
start_stack address of the start of the stack
esp current value of ESP
eip current value of EIP
pending bitmap of pending signals (obsolete)
blocked bitmap of blocked signals (obsolete)
sigign bitmap of ignored signals (obsolete)
sigcatch bitmap of catched signals (obsolete)
wchan address where process went to sleep
0 (place holder)
0 (place holder)
exit_signal signal to send to parent thread on exit
task_cpu which CPU the task is scheduled on
rt_priority realtime priority
policy scheduling policy (man sched_setscheduler)
blkio_ticks time spent waiting for block IO
..............................................................................
1.2 Kernel data
---------------
Similar to the process entries, the kernel data files give information about
the running kernel. The files used to obtain this information are contained in
/proc and are listed in Table 1-3. Not all of these will be present in your
/proc and are listed in Table 1-4. Not all of these will be present in your
system. It depends on the kernel configuration and the loaded modules, which
files are there, and which are missing.
Table 1-3: Kernel info in /proc
Table 1-4: Kernel info in /proc
..............................................................................
File Content
apm Advanced power management info
@ -473,10 +524,10 @@ IDE devices:
More detailed information can be found in the controller specific
subdirectories. These are named ide0, ide1 and so on. Each of these
directories contains the files shown in table 1-4.
directories contains the files shown in table 1-5.
Table 1-4: IDE controller info in /proc/ide/ide?
Table 1-5: IDE controller info in /proc/ide/ide?
..............................................................................
File Content
channel IDE channel (0 or 1)
@ -486,11 +537,11 @@ Table 1-4: IDE controller info in /proc/ide/ide?
..............................................................................
Each device connected to a controller has a separate subdirectory in the
controllers directory. The files listed in table 1-5 are contained in these
controllers directory. The files listed in table 1-6 are contained in these
directories.
Table 1-5: IDE device information
Table 1-6: IDE device information
..............................................................................
File Content
cache The cache
@ -1297,6 +1348,21 @@ nr_hugepages configures number of hugetlb page reserved for the system.
hugetlb_shm_group contains group id that is allowed to create SysV shared
memory segment using hugetlb page.
hugepages_treat_as_movable
--------------------------
This parameter is only useful when kernelcore= is specified at boot time to
create ZONE_MOVABLE for pages that may be reclaimed or migrated. Huge pages
are not movable so are not normally allocated from ZONE_MOVABLE. A non-zero
value written to hugepages_treat_as_movable allows huge pages to be allocated
from ZONE_MOVABLE.
Once enabled, the ZONE_MOVABLE is treated as an area of memory the huge
pages pool can easily grow or shrink within. Assuming that applications are
not running that mlock() a lot of memory, it is likely the huge pages pool
can grow to the size of ZONE_MOVABLE by repeatedly entering the desired value
into nr_hugepages and triggering page reclaim.
laptop_mode
-----------

51
Documentation/filesystems/vfs.txt
View File

@ -3,7 +3,7 @@
Original author: Richard Gooch <rgooch@atnf.csiro.au>
Last updated on October 28, 2005
Last updated on June 24, 2007.
Copyright (C) 1999 Richard Gooch
Copyright (C) 2005 Pekka Enberg
@ -107,7 +107,7 @@ file /proc/filesystems.
struct file_system_type
-----------------------
This describes the filesystem. As of kernel 2.6.13, the following
This describes the filesystem. As of kernel 2.6.22, the following
members are defined:
struct file_system_type {
@ -119,6 +119,8 @@ struct file_system_type {
struct module *owner;
struct file_system_type * next;
struct list_head fs_supers;
struct lock_class_key s_lock_key;
struct lock_class_key s_umount_key;
};
name: the name of the filesystem type, such as "ext2", "iso9660",
@ -137,11 +139,12 @@ struct file_system_type {
next: for internal VFS use: you should initialize this to NULL
s_lock_key, s_umount_key: lockdep-specific
The get_sb() method has the following arguments:
struct super_block *sb: the superblock structure. This is partially
initialized by the VFS and the rest must be initialized by the
get_sb() method
struct file_system_type *fs_type: decribes the filesystem, partly initialized
by the specific filesystem code
int flags: mount flags
@ -150,12 +153,13 @@ The get_sb() method has the following arguments:
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
struct vfsmount *mnt: a vfs-internal representation of a mount point
The get_sb() method must determine if the block device specified
in the superblock contains a filesystem of the type the method
supports. On success the method returns the superblock pointer, on
failure it returns NULL.
in the dev_name and fs_type contains a filesystem of the type the method
supports. If it succeeds in opening the named block device, it initializes a
struct super_block descriptor for the filesystem contained by the block device.
On failure it returns an error.
The most interesting member of the superblock structure that the
get_sb() method fills in is the "s_op" field. This is a pointer to
@ -193,7 +197,7 @@ struct super_operations
-----------------------
This describes how the VFS can manipulate the superblock of your
filesystem. As of kernel 2.6.13, the following members are defined:
filesystem. As of kernel 2.6.22, the following members are defined:
struct super_operations {
struct inode *(*alloc_inode)(struct super_block *sb);
@ -216,8 +220,6 @@ struct super_operations {
void (*clear_inode) (struct inode *);
void (*umount_begin) (struct super_block *);
void (*sync_inodes) (struct super_block *sb,
struct writeback_control *wbc);
int (*show_options)(struct seq_file *, struct vfsmount *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
@ -300,9 +302,6 @@ or bottom half).
umount_begin: called when the VFS is unmounting a filesystem.
sync_inodes: called when the VFS is writing out dirty data associated with
a superblock.
show_options: called by the VFS to show mount options for /proc/<pid>/mounts.
quota_read: called by the VFS to read from filesystem quota file.
@ -324,7 +323,7 @@ struct inode_operations
-----------------------
This describes how the VFS can manipulate an inode in your
filesystem. As of kernel 2.6.13, the following members are defined:
filesystem. As of kernel 2.6.22, the following members are defined:
struct inode_operations {
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
@ -348,6 +347,7 @@ struct inode_operations {
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*removexattr) (struct dentry *, const char *);
void (*truncate_range)(struct inode *, loff_t, loff_t);
};
Again, all methods are called without any locks being held, unless
@ -444,6 +444,9 @@ otherwise noted.
removexattr: called by the VFS to remove an extended attribute from
a file. This method is called by removexattr(2) system call.
truncate_range: a method provided by the underlying filesystem to truncate a
range of blocks , i.e. punch a hole somewhere in a file.
The Address Space Object
========================
@ -522,7 +525,7 @@ struct address_space_operations
-------------------------------
This describes how the VFS can manipulate mapping of a file to page cache in
your filesystem. As of kernel 2.6.16, the following members are defined:
your filesystem. As of kernel 2.6.22, the following members are defined:
struct address_space_operations {
int (*writepage)(struct page *page, struct writeback_control *wbc);
@ -543,6 +546,7 @@ struct address_space_operations {
int);
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
};
writepage: called by the VM to write a dirty page to backing store.
@ -689,6 +693,10 @@ struct address_space_operations {
transfer any private data across and update any references
that it has to the page.
launder_page: Called before freeing a page - it writes back the dirty page. To
prevent redirtying the page, it is kept locked during the whole
operation.
The File Object
===============
@ -699,9 +707,10 @@ struct file_operations
----------------------
This describes how the VFS can manipulate an open file. As of kernel
2.6.17, the following members are defined:
2.6.22, the following members are defined:
struct file_operations {
struct module *owner;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
@ -728,10 +737,8 @@ struct file_operations {
int (*check_flags)(int);
int (*dir_notify)(struct file *filp, unsigned long arg);
int (*flock) (struct file *, int, struct file_lock *);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned
int);
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned
int);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
};
Again, all methods are called without any locks being held, unless

2
Documentation/firmware_class/firmware_sample_firmware_class.c
View File

@ -78,6 +78,7 @@ static CLASS_DEVICE_ATTR(loading, 0644,
firmware_loading_show, firmware_loading_store);
static ssize_t firmware_data_read(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
@ -88,6 +89,7 @@ static ssize_t firmware_data_read(struct kobject *kobj,
return count;
}
static ssize_t firmware_data_write(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);

4
Documentation/hrtimer/timer_stats.txt
View File

@ -67,3 +67,7 @@ executed on expiry.
Thomas, Ingo
Added flag to indicate 'deferrable timer' in /proc/timer_stats. A deferrable
timer will appear as follows
10D, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)

4
Documentation/i2c/busses/i2c-i801
View File

@ -5,8 +5,8 @@ Supported adapters:
'810' and '810E' chipsets)
* Intel 82801BA (ICH2 - part of the '815E' chipset)
* Intel 82801CA/CAM (ICH3)
* Intel 82801DB (ICH4) (HW PEC supported, 32 byte buffer not supported)
* Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported)
* Intel 82801DB (ICH4) (HW PEC supported)
* Intel 82801EB/ER (ICH5) (HW PEC supported)
* Intel 6300ESB
* Intel 82801FB/FR/FW/FRW (ICH6)
* Intel 82801G (ICH7)

2
Documentation/i2c/busses/i2c-piix4
View File

@ -6,7 +6,7 @@ Supported adapters:
Datasheet: Publicly available at the Intel website
* ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
Datasheet: Only available via NDA from ServerWorks
* ATI IXP200, IXP300, IXP400 and SB600 southbridges
* ATI IXP200, IXP300, IXP400, SB600 and SB700 southbridges
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com

46
Documentation/i2c/busses/i2c-taos-evm Normal file
View File

@ -0,0 +1,46 @@
Kernel driver i2c-taos-evm
Author: Jean Delvare <khali@linux-fr.org>
This is a driver for the evaluation modules for TAOS I2C/SMBus chips.
The modules include an SMBus master with limited capabilities, which can
be controlled over the serial port. Virtually all evaluation modules
are supported, but a few lines of code need to be added for each new
module to instantiate the right I2C chip on the bus. Obviously, a driver
for the chip in question is also needed.
Currently supported devices are:
* TAOS TSL2550 EVM
For addtional information on TAOS products, please see
http://www.taosinc.com/
Using this driver
-----------------
In order to use this driver, you'll need the serport driver, and the
inputattach tool, which is part of the input-utils package. The following
commands will tell the kernel that you have a TAOS EVM on the first
serial port:
# modprobe serport
# inputattach --taos-evm /dev/ttyS0
Technical details
-----------------
Only 4 SMBus transaction types are supported by the TAOS evaluation
modules:
* Receive Byte
* Send Byte
* Read Byte
* Write Byte
The communication protocol is text-based and pretty simple. It is
described in a PDF document on the CD which comes with the evaluation
module. The communication is rather slow, because the serial port has
to operate at 1200 bps. However, I don't think this is a big concern in
practice, as these modules are meant for evaluation and testing only.

2
Documentation/i2c/chips/max6875
View File

@ -99,7 +99,7 @@ And then read the data
or
count = i2c_smbus_read_i2c_block_data(fd, 0x84, buffer);
count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer);
The block read should read 16 bytes.
0x84 is the block read command.

38
Documentation/i2c/chips/x1205
View File

@ -1,38 +0,0 @@
Kernel driver x1205
===================
Supported chips:
* Xicor X1205 RTC
Prefix: 'x1205'
Addresses scanned: none
Datasheet: http://www.intersil.com/cda/deviceinfo/0,1477,X1205,00.html
Authors:
Karen Spearel <kas11@tampabay.rr.com>,
Alessandro Zummo <a.zummo@towertech.it>
Description
-----------
This module aims to provide complete access to the Xicor X1205 RTC.
Recently Xicor has merged with Intersil, but the chip is
still sold under the Xicor brand.
This chip is located at address 0x6f and uses a 2-byte register addressing.
Two bytes need to be written to read a single register, while most
other chips just require one and take the second one as the data
to be written. To prevent corrupting unknown chips, the user must
explicitely set the probe parameter.
example:
modprobe x1205 probe=0,0x6f
The module supports one more option, hctosys, which is used to set the
software clock from the x1205. On systems where the x1205 is the
only hardware rtc, this parameter could be used to achieve a correct
date/time earlier in the system boot sequence.
example:
modprobe x1205 probe=0,0x6f hctosys=1

2
Documentation/i2c/summary
View File

@ -67,7 +67,6 @@ i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers
Algorithm drivers
-----------------
i2c-algo-8xx: An algorithm for CPM's I2C device in Motorola 8xx processors (NOT BUILT BY DEFAULT)
i2c-algo-bit: A bit-banging algorithm
i2c-algo-pcf: A PCF 8584 style algorithm
i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT)
@ -81,6 +80,5 @@ i2c-pcf-epp: PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatch
i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT)
i2c-pport: Primitive parallel port adapter (uses i2c-algo-bit)
i2c-rpx: RPX board Motorola 8xx I2C device (uses i2c-algo-8xx) (NOT BUILT BY DEFAULT)
i2c-velleman: Velleman K8000 parallel port adapter (uses i2c-algo-bit)

2
Documentation/i2c/writing-clients
View File

@ -571,7 +571,7 @@ SMBus communication
u8 command, u8 length,
u8 *values);
extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
u8 command, u8 *values);
u8 command, u8 length, u8 *values);
These ones were removed in Linux 2.6.10 because they had no users, but could
be added back later if needed:

1
Documentation/i386/zero-page.txt
View File

@ -37,6 +37,7 @@ Offset Type Description
0x1d0 unsigned long EFI memory descriptor map pointer
0x1d4 unsigned long EFI memory descriptor map size
0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb
0x1e4 unsigned long Scratch field for the kernel setup code
0x1e8 char number of entries in E820MAP (below)
0x1e9 unsigned char number of entries in EDDBUF (below)
0x1ea unsigned char number of entries in EDD_MBR_SIG_BUFFER (below)

26
Documentation/ia64/aliasing-test.c
View File

@ -19,6 +19,7 @@
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <linux/pci.h>
int sum;
@ -34,13 +35,19 @@ int map_mem(char *path, off_t offset, size_t length, int touch)
return -1;
}
if (fnmatch("/proc/bus/pci/*", path, 0) == 0) {
rc = ioctl(fd, PCIIOC_MMAP_IS_MEM);
if (rc == -1)
perror("PCIIOC_MMAP_IS_MEM ioctl");
}
addr = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
if (addr == MAP_FAILED)
return 1;
if (touch) {
c = (int *) addr;
while (c < (int *) (offset + length))
while (c < (int *) (addr + length))
sum += *c++;
}
@ -54,7 +61,7 @@ int map_mem(char *path, off_t offset, size_t length, int touch)
return 0;
}
int scan_sysfs(char *path, char *file, off_t offset, size_t length, int touch)
int scan_tree(char *path, char *file, off_t offset, size_t length, int touch)
{
struct dirent **namelist;
char *name, *path2;
@ -93,7 +100,7 @@ int scan_sysfs(char *path, char *file, off_t offset, size_t length, int touch)
} else {
r = lstat(path2, &buf);
if (r == 0 && S_ISDIR(buf.st_mode)) {
rc = scan_sysfs(path2, file, offset, length, touch);
rc = scan_tree(path2, file, offset, length, touch);
if (rc < 0)
return rc;
}
@ -238,10 +245,15 @@ int main()
else
fprintf(stderr, "FAIL: /dev/mem 0x0-0x100000 not accessible\n");
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0);
scan_tree("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1);
scan_tree("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0);
scan_tree("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1);
scan_tree("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0);
scan_rom("/sys/devices", "rom");
scan_tree("/proc/bus/pci", "??.?", 0, 0xA0000, 1);
scan_tree("/proc/bus/pci", "??.?", 0xA0000, 0x20000, 0);
scan_tree("/proc/bus/pci", "??.?", 0xC0000, 0x40000, 1);
scan_tree("/proc/bus/pci", "??.?", 0, 1024*1024, 0);
}

12
Documentation/ia64/aliasing.txt
View File

@ -112,6 +112,18 @@ POTENTIAL ATTRIBUTE ALIASING CASES
The /dev/mem mmap constraints apply.
mmap of /proc/bus/pci/.../??.?
This is an MMIO mmap of PCI functions, which additionally may or
may not be requested as using the WC attribute.
If WC is requested, and the region in kern_memmap is either WC
or UC, and the EFI memory map designates the region as WC, then
the WC mapping is allowed.
Otherwise, the user mapping must use the same attribute as the
kernel mapping.
read/write of /dev/mem
This uses copy_from_user(), which implicitly uses a kernel

2
Documentation/ioctl-number.txt
View File

@ -67,7 +67,7 @@ Code Seq# Include File Comments
0x00 00-1F linux/wavefront.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
0x04 all linux/umsdos_fs.h
0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these.
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h

191
Documentation/kernel-parameters.txt
View File

@ -34,7 +34,6 @@ parameter is applicable:
APIC APIC support is enabled.
APM Advanced Power Management support is enabled.
AX25 Appropriate AX.25 support is enabled.
CD Appropriate CD support is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
EFI EFI Partitioning (GPT) is enabled
@ -223,11 +222,6 @@ and is between 256 and 4096 characters. It is defined in the file
acpi_fake_ecdt [HW,ACPI] Workaround failure due to BIOS lacking ECDT
acpi_generic_hotkey [HW,ACPI]
Allow consolidated generic hotkey driver to
override platform specific driver.
See also Documentation/acpi-hotkey.txt.
acpi_pm_good [IA-32,X86-64]
Override the pmtimer bug detection: force the kernel
to assume that this machine's pmtimer latches its value
@ -243,16 +237,9 @@ and is between 256 and 4096 characters. It is defined in the file
Disable PIN 1 of APIC timer
Can be useful to work around chipset bugs.
ad1816= [HW,OSS]
Format: <io>,<irq>,<dma>,<dma2>
See also Documentation/sound/oss/AD1816.
ad1848= [HW,OSS]
Format: <io>,<irq>,<dma>,<dma2>,<type>
adlib= [HW,OSS]
Format: <io>
advansys= [HW,SCSI]
See header of drivers/scsi/advansys.c.
@ -331,9 +318,6 @@ and is between 256 and 4096 characters. It is defined in the file
autotest [IA64]
aztcd= [HW,CD] Aztech CD268 CDROM driver
Format: <io>,0x79 (?)
baycom_epp= [HW,AX25]
Format: <io>,<mode>
@ -376,10 +360,6 @@ and is between 256 and 4096 characters. It is defined in the file
possible to determine what the correct size should be.
This option provides an override for these situations.
cdu31a= [HW,CD]
Format: <io>,<irq>[,PAS]
See header of drivers/cdrom/cdu31a.c.
chandev= [HW,NET] Generic channel device initialisation
checkreqprot [SELINUX] Set initial checkreqprot flag value.
@ -433,9 +413,6 @@ and is between 256 and 4096 characters. It is defined in the file
hpet= [IA-32,HPET] option to disable HPET and use PIT.
Format: disable
cm206= [HW,CD]
Format: { auto | [<io>,][<irq>] }
com20020= [HW,NET] ARCnet - COM20020 chipset
Format:
<io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]
@ -467,13 +444,20 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
uart,io,<addr>[,options]
uart,mmio,<addr>[,options]
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
earlycon= [KNL] Output early console device and options.
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
Format:
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
@ -665,9 +649,6 @@ and is between 256 and 4096 characters. It is defined in the file
gpt [EFI] Forces disk with valid GPT signature but
invalid Protective MBR to be treated as GPT.
gscd= [HW,CD]
Format: <io>
gvp11= [HW,SCSI]
hashdist= [KNL,NUMA] Large hashes allocated during boot
@ -831,14 +812,37 @@ and is between 256 and 4096 characters. It is defined in the file
tasks in the system -- can cause problems and
suboptimal load balancer performance.
isp16= [HW,CD]
Format: <io>,<irq>,<dma>,<setup>
iucv= [HW,NET]
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
kernelcore=nn[KMG] [KNL,IA-32,IA-64,PPC,X86-64] This parameter
specifies the amount of memory usable by the kernel
for non-movable allocations. The requested amount is
spread evenly throughout all nodes in the system. The
remaining memory in each node is used for Movable
pages. In the event, a node is too small to have both
kernelcore and Movable pages, kernelcore pages will
take priority and other nodes will have a larger number
of kernelcore pages. The Movable zone is used for the
allocation of pages that may be reclaimed or moved
by the page migration subsystem. This means that
HugeTLB pages may not be allocated from this zone.
Note that allocations like PTEs-from-HighMem still
use the HighMem zone if it exists, and the Normal
zone if it does not.
movablecore=nn[KMG] [KNL,IA-32,IA-64,PPC,X86-64] This parameter
is similar to kernelcore except it specifies the
amount of memory used for migratable allocations.
If both kernelcore and movablecore is specified,
then kernelcore will be at *least* the specified
value but may be more. If movablecore on its own
is specified, the administrator must be careful
that the amount of memory usable for all allocations
is not too small.
keepinitrd [HW,ARM]
kstack=N [IA-32,X86-64] Print N words from the kernel stack
@ -972,11 +976,6 @@ and is between 256 and 4096 characters. It is defined in the file
mcatest= [IA-64]
mcd= [HW,CD]
Format: <port>,<irq>,<mitsumi_bug_93_wait>
mcdx= [HW,CD]
mce [IA-32] Machine Check Exception
md= [HW] RAID subsystems devices and level
@ -1019,49 +1018,6 @@ and is between 256 and 4096 characters. It is defined in the file
mga= [HW,DRM]
migration_cost=
[KNL,SMP] debug: override scheduler migration costs
Format: <level-1-usecs>,<level-2-usecs>,...
This debugging option can be used to override the
default scheduler migration cost matrix. The numbers
are indexed by 'CPU domain distance'.
E.g. migration_cost=1000,2000,3000 on an SMT NUMA
box will set up an intra-core migration cost of
1 msec, an inter-core migration cost of 2 msecs,
and an inter-node migration cost of 3 msecs.
WARNING: using the wrong values here can break
scheduler performance, so it's only for scheduler
development purposes, not production environments.
migration_debug=
[KNL,SMP] migration cost auto-detect verbosity
Format=<0|1|2>
If a system's migration matrix reported at bootup
seems erroneous then this option can be used to
increase verbosity of the detection process.
We default to 0 (no extra messages), 1 will print
some more information, and 2 will be really
verbose (probably only useful if you also have a
serial console attached to the system).
migration_factor=
[KNL,SMP] multiply/divide migration costs by a factor
Format=<percent>
This debug option can be used to proportionally
increase or decrease the auto-detected migration
costs for all entries of the migration matrix.
E.g. migration_factor=150 will increase migration
costs by 50%. (and thus the scheduler will be less
eager migrating cache-hot tasks)
migration_factor=80 will decrease migration costs
by 20%. (thus the scheduler will be more eager to
migrate tasks)
WARNING: using the wrong values here can break
scheduler performance, so it's only for scheduler
development purposes, not production environments.
mousedev.tap_time=
[MOUSE] Maximum time between finger touching and
leaving touchpad surface for touch to be considered
@ -1229,6 +1185,8 @@ and is between 256 and 4096 characters. It is defined in the file
nosmp [SMP] Tells an SMP kernel to act as a UP kernel.
nosoftlockup [KNL] Disable the soft-lockup detector.
nosync [HW,M68K] Disables sync negotiation for all devices.
notsc [BUGS=IA-32] Disable Time Stamp Counter
@ -1237,20 +1195,19 @@ and is between 256 and 4096 characters. It is defined in the file
nowb [ARM]
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
one of ['zone', 'node', 'default'] can be specified
This can be set from sysctl after boot.
See Documentation/sysctl/vm.txt for details.
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
opl3= [HW,OSS]
Format: <io>
opl3sa2= [HW,OSS] Format:
<io>,<irq>,<dma>,<dma2>,<mss_io>,<mpu_io>,<ymode>,<loopback>[,<isapnp>,<multiple]
oprofile.timer= [HW]
Use timer interrupt instead of performance counters
optcd= [HW,CD]
Format: <io>
osst= [HW,SCSI] SCSI Tape Driver
Format: <buffer_size>,<write_threshold>
See also Documentation/scsi/st.txt.
@ -1429,6 +1386,15 @@ and is between 256 and 4096 characters. It is defined in the file
autoconfiguration.
Ranges are in pairs (memory base and size).
print-fatal-signals=
[KNL] debug: print fatal signals
print-fatal-signals=1: print segfault info to
the kernel console.
default: off.
printk.time= Show timing data prefixed to each printk message line
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
profile= [KNL] Enable kernel profiling via /proc/profile
Format: [schedule,]<number>
Param: "schedule" - profile schedule points.
@ -1541,6 +1507,10 @@ and is between 256 and 4096 characters. It is defined in the file
rootfstype= [KNL] Set root filesystem type
rootwait [KNL] Wait (indefinitely) for root device to show up.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
@ -1553,11 +1523,6 @@ and is between 256 and 4096 characters. It is defined in the file
sbni= [NET] Granch SBNI12 leased line adapter
sbpcd= [HW,CD] Soundblaster CD adapter
Format: <io>,<type>
See a comment before function sbpcd_setup() in
drivers/cdrom/sbpcd.c.
sc1200wdt= [HW,WDT] SC1200 WDT (watchdog) driver
Format: <io>[,<timeout>[,<isapnp>]]
@ -1610,41 +1575,41 @@ and is between 256 and 4096 characters. It is defined in the file
simeth= [IA-64]
simscsi=
sjcd= [HW,CD]
Format: <io>,<irq>,<dma>
See header of drivers/cdrom/sjcd.c.
slram= [HW,MTD]
slub_debug [MM, SLUB]
Enabling slub_debug allows one to determine the culprit
if slab objects become corrupted. Enabling slub_debug
creates guard zones around objects and poisons objects
when not in use. Also tracks the last alloc / free.
For more information see Documentation/vm/slub.txt.
slub_debug[=options[,slabs]] [MM, SLUB]
Enabling slub_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
slub_debug can create guard zones around objects and
may poison objects when not in use. Also tracks the
last alloc / free. For more information see
Documentation/vm/slub.txt.
slub_max_order= [MM, SLUB]
Determines the maximum allowed order for slabs. Setting
this too high may cause fragmentation.
For more information see Documentation/vm/slub.txt.
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
fragmentation. For more information see
Documentation/vm/slub.txt.
slub_min_objects= [MM, SLUB]
The minimum objects per slab. SLUB will increase the
slab order up to slub_max_order to generate a
sufficiently big slab to satisfy the number of objects.
The higher the number of objects the smaller the overhead
of tracking slabs.
The minimum number of objects per slab. SLUB will
increase the slab order up to slub_max_order to
generate a sufficiently large slab able to contain
the number of objects indicated. The higher the number
of objects the smaller the overhead of tracking slabs
and the less frequently locks need to be acquired.
For more information see Documentation/vm/slub.txt.
slub_min_order= [MM, SLUB]
Determines the mininum page order for slabs. Must be
lower than slub_max_order
lower than slub_max_order.
For more information see Documentation/vm/slub.txt.
slub_nomerge [MM, SLUB]
Disable merging of slabs of similar size. May be
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
allocs to different slabs.
allocs to different slabs. Debug options disable
merging on their own.
For more information see Documentation/vm/slub.txt.
smart2= [HW]
@ -1786,9 +1751,6 @@ and is between 256 and 4096 characters. It is defined in the file
snd-ymfpci= [HW,ALSA]
sonycd535= [HW,CD]
Format: <io>[,<irq>]
sonypi.*= [HW] Sony Programmable I/O Control Device driver
See Documentation/sonypi.txt
@ -1860,6 +1822,7 @@ and is between 256 and 4096 characters. It is defined in the file
Set number of hash buckets for TCP connection
time Show timing data prefixed to each printk message line
[deprecated, see 'printk.time']
tipar.timeout= [HW,PPT]
Set communications timeout in tenths of a second

7
Documentation/m68k/kernel-options.txt
View File

@ -82,13 +82,6 @@ Valid names are:
/dev/fd : -> 0x0200 (floppy disk)
/dev/xda: -> 0x0c00 (first XT disk, unused in Linux/m68k)
/dev/xdb: -> 0x0c40 (second XT disk, unused in Linux/m68k)
/dev/ada: -> 0x1c00 (first ACSI device)
/dev/adb: -> 0x1c10 (second ACSI device)
/dev/adc: -> 0x1c20 (third ACSI device)
/dev/add: -> 0x1c30 (forth ACSI device)
The last four names are available only if the kernel has been compiled
with Atari and ACSI support.
The name must be followed by a decimal number, that stands for the
partition number. Internally, the value of the number is just

3
Documentation/networking/00-INDEX
View File

@ -96,9 +96,6 @@ routing.txt
- the new routing mechanism
shaper.txt
- info on the module that can shape/limit transmitted traffic.
sk98lin.txt
- Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
Ethernet Adapter family driver info
skfp.txt
- SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
smc9.txt

9
Documentation/networking/ip-sysctl.txt
View File

@ -433,6 +433,12 @@ tcp_workaround_signed_windows - BOOLEAN
not receive a window scaling option from them.
Default: 0
tcp_dma_copybreak - INTEGER
Lower limit, in bytes, of the size of socket reads that will be
offloaded to a DMA copy engine, if one is present in the system
and CONFIG_NET_DMA is enabled.
Default: 4096
CIPSOv4 Variables:
cipso_cache_enable - BOOLEAN
@ -874,8 +880,7 @@ accept_redirects - BOOLEAN
accept_source_route - INTEGER
Accept source routing (routing extension header).
> 0: Accept routing header.
= 0: Accept only routing header type 2.
>= 0: Accept only routing header type 2.
< 0: Do not accept routing header.
Default: 0

169
Documentation/networking/l2tp.txt Normal file
View File

@ -0,0 +1,169 @@
This brief document describes how to use the kernel's PPPoL2TP driver
to provide L2TP functionality. L2TP is a protocol that tunnels one or
more PPP sessions over a UDP tunnel. It is commonly used for VPNs
(L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP
network infrastructure.
Design
======
The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by
which PPP frames carried through an L2TP session are passed through
the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all
PPP interaction with the peer. PPP network interfaces are created for
each local PPP endpoint.
The L2TP protocol http://www.faqs.org/rfcs/rfc2661.html defines L2TP
control and data frames. L2TP control frames carry messages between
L2TP clients/servers and are used to setup / teardown tunnels and
sessions. An L2TP client or server is implemented in userspace and
will use a regular UDP socket per tunnel. L2TP data frames carry PPP
frames, which may be PPP control or PPP data. The kernel's PPP
subsystem arranges for PPP control frames to be delivered to pppd,
while data frames are forwarded as usual.
Each tunnel and session within a tunnel is assigned a unique tunnel_id
and session_id. These ids are carried in the L2TP header of every
control and data packet. The pppol2tp driver uses them to lookup
internal tunnel and/or session contexts. Zero tunnel / session ids are
treated specially - zero ids are never assigned to tunnels or sessions
in the network. In the driver, the tunnel context keeps a pointer to
the tunnel UDP socket. The session context keeps a pointer to the
PPPoL2TP socket, as well as other data that lets the driver interface
to the kernel PPP subsystem.
Note that the pppol2tp kernel driver handles only L2TP data frames;
L2TP control frames are simply passed up to userspace in the UDP
tunnel socket. The kernel handles all datapath aspects of the
protocol, including data packet resequencing (if enabled).
There are a number of requirements on the userspace L2TP daemon in
order to use the pppol2tp driver.
1. Use a UDP socket per tunnel.
2. Create a single PPPoL2TP socket per tunnel bound to a special null
session id. This is used only for communicating with the driver but
must remain open while the tunnel is active. Opening this tunnel
management socket causes the driver to mark the tunnel socket as an
L2TP UDP encapsulation socket and flags it for use by the
referenced tunnel id. This hooks up the UDP receive path via
udp_encap_rcv() in net/ipv4/udp.c. PPP data frames are never passed
in this special PPPoX socket.
3. Create a PPPoL2TP socket per L2TP session. This is typically done
by starting pppd with the pppol2tp plugin and appropriate
arguments. A PPPoL2TP tunnel management socket (Step 2) must be
created before the first PPPoL2TP session socket is created.
When creating PPPoL2TP sockets, the application provides information
to the driver about the socket in a socket connect() call. Source and
destination tunnel and session ids are provided, as well as the file
descriptor of a UDP socket. See struct pppol2tp_addr in
include/linux/if_ppp.h. Note that zero tunnel / session ids are
treated specially. When creating the per-tunnel PPPoL2TP management
socket in Step 2 above, zero source and destination session ids are
specified, which tells the driver to prepare the supplied UDP file
descriptor for use as an L2TP tunnel socket.
Userspace may control behavior of the tunnel or session using
setsockopt and ioctl on the PPPoX socket. The following socket
options are supported:-
DEBUG - bitmask of debug message categories. See below.
SENDSEQ - 0 => don't send packets with sequence numbers
1 => send packets with sequence numbers
RECVSEQ - 0 => receive packet sequence numbers are optional
1 => drop receive packets without sequence numbers
LNSMODE - 0 => act as LAC.
1 => act as LNS.
REORDERTO - reorder timeout (in millisecs). If 0, don't try to reorder.
Only the DEBUG option is supported by the special tunnel management
PPPoX socket.
In addition to the standard PPP ioctls, a PPPIOCGL2TPSTATS is provided
to retrieve tunnel and session statistics from the kernel using the
PPPoX socket of the appropriate tunnel or session.
Debugging
=========
The driver supports a flexible debug scheme where kernel trace
messages may be optionally enabled per tunnel and per session. Care is
needed when debugging a live system since the messages are not
rate-limited and a busy system could be swamped. Userspace uses
setsockopt on the PPPoX socket to set a debug mask.
The following debug mask bits are available:
PPPOL2TP_MSG_DEBUG verbose debug (if compiled in)
PPPOL2TP_MSG_CONTROL userspace - kernel interface
PPPOL2TP_MSG_SEQ sequence numbers handling
PPPOL2TP_MSG_DATA data packets
Sample Userspace Code
=====================
1. Create tunnel management PPPoX socket
kernel_fd = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
if (kernel_fd >= 0) {
struct sockaddr_pppol2tp sax;
struct sockaddr_in const *peer_addr;
peer_addr = l2tp_tunnel_get_peer_addr(tunnel);
memset(&sax, 0, sizeof(sax));
sax.sa_family = AF_PPPOX;
sax.sa_protocol = PX_PROTO_OL2TP;
sax.pppol2tp.fd = udp_fd; /* fd of tunnel UDP socket */
sax.pppol2tp.addr.sin_addr.s_addr = peer_addr->sin_addr.s_addr;
sax.pppol2tp.addr.sin_port = peer_addr->sin_port;
sax.pppol2tp.addr.sin_family = AF_INET;
sax.pppol2tp.s_tunnel = tunnel_id;
sax.pppol2tp.s_session = 0; /* special case: mgmt socket */
sax.pppol2tp.d_tunnel = 0;
sax.pppol2tp.d_session = 0; /* special case: mgmt socket */
if(connect(kernel_fd, (struct sockaddr *)&sax, sizeof(sax) ) < 0 ) {
perror("connect failed");
result = -errno;
goto err;
}
}
2. Create session PPPoX data socket
struct sockaddr_pppol2tp sax;
int fd;
/* Note, the target socket must be bound already, else it will not be ready */
sax.sa_family = AF_PPPOX;
sax.sa_protocol = PX_PROTO_OL2TP;
sax.pppol2tp.fd = tunnel_fd;
sax.pppol2tp.addr.sin_addr.s_addr = addr->sin_addr.s_addr;
sax.pppol2tp.addr.sin_port = addr->sin_port;
sax.pppol2tp.addr.sin_family = AF_INET;
sax.pppol2tp.s_tunnel = tunnel_id;
sax.pppol2tp.s_session = session_id;
sax.pppol2tp.d_tunnel = peer_tunnel_id;
sax.pppol2tp.d_session = peer_session_id;
/* session_fd is the fd of the session's PPPoL2TP socket.
* tunnel_fd is the fd of the tunnel UDP socket.
*/
fd = connect(session_fd, (struct sockaddr *)&sax, sizeof(sax));
if (fd < 0 ) {
return -errno;
}
return 0;
Miscellanous
============
The PPPoL2TP driver was developed as part of the OpenL2TP project by
Katalix Systems Ltd. OpenL2TP is a full-featured L2TP client / server,
designed from the ground up to have the L2TP datapath in the
kernel. The project also implemented the pppol2tp plugin for pppd
which allows pppd to use the kernel driver. Details can be found at
http://openl2tp.sourceforge.net.

59
Documentation/networking/mac80211-injection.txt Normal file
View File

@ -0,0 +1,59 @@
How to use packet injection with mac80211
=========================================
mac80211 now allows arbitrary packets to be injected down any Monitor Mode
interface from userland. The packet you inject needs to be composed in the
following format:
[ radiotap header ]
[ ieee80211 header ]
[ payload ]
The radiotap format is discussed in
./Documentation/networking/radiotap-headers.txt.
Despite 13 radiotap argument types are currently defined, most only make sense
to appear on received packets. Currently three kinds of argument are used by
the injection code, although it knows to skip any other arguments that are
present (facilitating replay of captured radiotap headers directly):
- IEEE80211_RADIOTAP_RATE - u8 arg in 500kbps units (0x02 --> 1Mbps)
- IEEE80211_RADIOTAP_ANTENNA - u8 arg, 0x00 = ant1, 0x01 = ant2
- IEEE80211_RADIOTAP_DBM_TX_POWER - u8 arg, dBm
Here is an example valid radiotap header defining these three parameters
0x00, 0x00, // <-- radiotap version
0x0b, 0x00, // <- radiotap header length
0x04, 0x0c, 0x00, 0x00, // <-- bitmap
0x6c, // <-- rate
0x0c, //<-- tx power
0x01 //<-- antenna
The ieee80211 header follows immediately afterwards, looking for example like
this:
0x08, 0x01, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0x13, 0x22, 0x33, 0x44, 0x55, 0x66,
0x13, 0x22, 0x33, 0x44, 0x55, 0x66,
0x10, 0x86
Then lastly there is the payload.
After composing the packet contents, it is sent by send()-ing it to a logical
mac80211 interface that is in Monitor mode. Libpcap can also be used,
(which is easier than doing the work to bind the socket to the right
interface), along the following lines:
ppcap = pcap_open_live(szInterfaceName, 800, 1, 20, szErrbuf);
...
r = pcap_inject(ppcap, u8aSendBuffer, nLength);
You can also find sources for a complete inject test applet here:
http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer
Andy Green <andy@warmcat.com>

111
Documentation/networking/multiqueue.txt Normal file
View File

@ -0,0 +1,111 @@
HOWTO for multiqueue network device support
===========================================
Section 1: Base driver requirements for implementing multiqueue support
Section 2: Qdisc support for multiqueue devices
Section 3: Brief howto using PRIO or RR for multiqueue devices
Intro: Kernel support for multiqueue devices
---------------------------------------------------------
Kernel support for multiqueue devices is only an API that is presented to the
netdevice layer for base drivers to implement. This feature is part of the
core networking stack, and all network devices will be running on the
multiqueue-aware stack. If a base driver only has one queue, then these
changes are transparent to that driver.
Section 1: Base driver requirements for implementing multiqueue support
-----------------------------------------------------------------------
Base drivers are required to use the new alloc_etherdev_mq() or
alloc_netdev_mq() functions to allocate the subqueues for the device. The
underlying kernel API will take care of the allocation and deallocation of
the subqueue memory, as well as netdev configuration of where the queues
exist in memory.
The base driver will also need to manage the queues as it does the global
netdev->queue_lock today. Therefore base drivers should use the
netif_{start|stop|wake}_subqueue() functions to manage each queue while the
device is still operational. netdev->queue_lock is still used when the device
comes online or when it's completely shut down (unregister_netdev(), etc.).
Finally, the base driver should indicate that it is a multiqueue device. The
feature flag NETIF_F_MULTI_QUEUE should be added to the netdev->features
bitmap on device initialization. Below is an example from e1000:
#ifdef CONFIG_E1000_MQ
if ( (adapter->hw.mac.type == e1000_82571) ||
(adapter->hw.mac.type == e1000_82572) ||
(adapter->hw.mac.type == e1000_80003es2lan))
netdev->features |= NETIF_F_MULTI_QUEUE;
#endif
Section 2: Qdisc support for multiqueue devices
-----------------------------------------------
Currently two qdiscs support multiqueue devices. A new round-robin qdisc,
sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to
bands and queues, and will store the queue mapping into skb->queue_mapping.
Use this field in the base driver to determine which queue to send the skb
to.
sch_rr has been added for hardware that doesn't want scheduling policies from
software, so it's a straight round-robin qdisc. It uses the same syntax and
classification priomap that sch_prio uses, so it should be intuitive to
configure for people who've used sch_prio.
The PRIO qdisc naturally plugs into a multiqueue device. If PRIO has been
built with NET_SCH_PRIO_MQ, then upon load, it will make sure the number of
bands requested is equal to the number of queues on the hardware. If they
are equal, it sets a one-to-one mapping up between the queues and bands. If
they're not equal, it will not load the qdisc. This is the same behavior
for RR. Once the association is made, any skb that is classified will have
skb->queue_mapping set, which will allow the driver to properly queue skb's
to multiple queues.
Section 3: Brief howto using PRIO and RR for multiqueue devices
---------------------------------------------------------------
The userspace command 'tc,' part of the iproute2 package, is used to configure
qdiscs. To add the PRIO qdisc to your network device, assuming the device is
called eth0, run the following command:
# tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue
This will create 4 bands, 0 being highest priority, and associate those bands
to the queues on your NIC. Assuming eth0 has 4 Tx queues, the band mapping
would look like:
band 0 => queue 0
band 1 => queue 1
band 2 => queue 2
band 3 => queue 3
Traffic will begin flowing through each queue if your TOS values are assigning
traffic across the various bands. For example, ssh traffic will always try to
go out band 0 based on TOS -> Linux priority conversion (realtime traffic),
so it will be sent out queue 0. ICMP traffic (pings) fall into the "normal"
traffic classification, which is band 1. Therefore pings will be send out
queue 1 on the NIC.
Note the use of the multiqueue keyword. This is only in versions of iproute2
that support multiqueue networking devices; if this is omitted when loading
a qdisc onto a multiqueue device, the qdisc will load and operate the same
if it were loaded onto a single-queue device (i.e. - sends all traffic to
queue 0).
Another alternative to multiqueue band allocation can be done by using the
multiqueue option and specify 0 bands. If this is the case, the qdisc will
allocate the number of bands to equal the number of queues that the device
reports, and bring the qdisc online.
The behavior of tc filters remains the same, where it will override TOS priority
classification.
Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>

6
Documentation/networking/net-modules.txt
View File

@ -146,12 +146,6 @@ at1700.c:
irq = 0
(Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
atari_bionet.c:
Supports full autoprobing. (m68k/Atari)
atari_pamsnet.c:
Supports full autoprobing. (m68k/Atari)
atarilance.c:
Supports full autoprobing. (m68k/Atari)

38
Documentation/networking/netdevices.txt
View File

@ -20,6 +20,30 @@ private data which gets freed when the network device is freed. If
separately allocated data is attached to the network device
(dev->priv) then it is up to the module exit handler to free that.
MTU
===
Each network device has a Maximum Transfer Unit. The MTU does not
include any link layer protocol overhead. Upper layer protocols must
not pass a socket buffer (skb) to a device to transmit with more data
than the mtu. The MTU does not include link layer header overhead, so
for example on Ethernet if the standard MTU is 1500 bytes used, the
actual skb will contain up to 1514 bytes because of the Ethernet
header. Devices should allow for the 4 byte VLAN header as well.
Segmentation Offload (GSO, TSO) is an exception to this rule. The
upper layer protocol may pass a large socket buffer to the device
transmit routine, and the device will break that up into separate
packets based on the current MTU.
MTU is symmetrical and applies both to receive and transmit. A device
must be able to receive at least the maximum size packet allowed by
the MTU. A network device may use the MTU as mechanism to size receive
buffers, but the device should allow packets with VLAN header. With
standard Ethernet mtu of 1500 bytes, the device should allow up to
1518 byte packets (1500 + 14 header + 4 tag). The device may either:
drop, truncate, or pass up oversize packets, but dropping oversize
packets is preferred.
struct net_device synchronization rules
=======================================
@ -43,16 +67,17 @@ dev->get_stats:
dev->hard_start_xmit:
Synchronization: netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
called without holding netif_tx_lock. In this case the driver
has to lock by itself when needed. It is recommended to use a try lock
for this and return -1 when the spin lock fails.
for this and return NETDEV_TX_LOCKED when the spin lock fails.
The locking there should also properly protect against
set_multicast_list
Context: Process with BHs disabled or BH (timer).
Notes: netif_queue_stopped() is guaranteed false
Interrupts must be enabled when calling hard_start_xmit.
(Interrupts must also be enabled when enabling the BH handler.)
set_multicast_list.
Context: Process with BHs disabled or BH (timer),
will be called with interrupts disabled by netconsole.
Return codes:
o NETDEV_TX_OK everything ok.
o NETDEV_TX_BUSY Cannot transmit packet, try later
@ -74,4 +99,5 @@ dev->poll:
Synchronization: __LINK_STATE_RX_SCHED bit in dev->state. See
dev_close code and comments in net/core/dev.c for more info.
Context: softirq
will be called with interrupts disabled by netconsole.

152
Documentation/networking/radiotap-headers.txt Normal file
View File

@ -0,0 +1,152 @@
How to use radiotap headers
===========================
Pointer to the radiotap include file
------------------------------------
Radiotap headers are variable-length and extensible, you can get most of the
information you need to know on them from:
./include/net/ieee80211_radiotap.h
This document gives an overview and warns on some corner cases.
Structure of the header
-----------------------
There is a fixed portion at the start which contains a u32 bitmap that defines
if the possible argument associated with that bit is present or not. So if b0
of the it_present member of ieee80211_radiotap_header is set, it means that
the header for argument index 0 (IEEE80211_RADIOTAP_TSFT) is present in the
argument area.
< 8-byte ieee80211_radiotap_header >
[ <possible argument bitmap extensions ... > ]
[ <argument> ... ]
At the moment there are only 13 possible argument indexes defined, but in case
we run out of space in the u32 it_present member, it is defined that b31 set
indicates that there is another u32 bitmap following (shown as "possible
argument bitmap extensions..." above), and the start of the arguments is moved
forward 4 bytes each time.
Note also that the it_len member __le16 is set to the total number of bytes
covered by the ieee80211_radiotap_header and any arguments following.
Requirements for arguments
--------------------------
After the fixed part of the header, the arguments follow for each argument
index whose matching bit is set in the it_present member of
ieee80211_radiotap_header.
- the arguments are all stored little-endian!
- the argument payload for a given argument index has a fixed size. So
IEEE80211_RADIOTAP_TSFT being present always indicates an 8-byte argument is
present. See the comments in ./include/net/ieee80211_radiotap.h for a nice
breakdown of all the argument sizes
- the arguments must be aligned to a boundary of the argument size using
padding. So a u16 argument must start on the next u16 boundary if it isn't
already on one, a u32 must start on the next u32 boundary and so on.
- "alignment" is relative to the start of the ieee80211_radiotap_header, ie,
the first byte of the radiotap header. The absolute alignment of that first
byte isn't defined. So even if the whole radiotap header is starting at, eg,
address 0x00000003, still the first byte of the radiotap header is treated as
0 for alignment purposes.
- the above point that there may be no absolute alignment for multibyte
entities in the fixed radiotap header or the argument region means that you
have to take special evasive action when trying to access these multibyte
entities. Some arches like Blackfin cannot deal with an attempt to
dereference, eg, a u16 pointer that is pointing to an odd address. Instead
you have to use a kernel API get_unaligned() to dereference the pointer,
which will do it bytewise on the arches that require that.
- The arguments for a given argument index can be a compound of multiple types
together. For example IEEE80211_RADIOTAP_CHANNEL has an argument payload
consisting of two u16s of total length 4. When this happens, the padding
rule is applied dealing with a u16, NOT dealing with a 4-byte single entity.
Example valid radiotap header
-----------------------------
0x00, 0x00, // <-- radiotap version + pad byte
0x0b, 0x00, // <- radiotap header length
0x04, 0x0c, 0x00, 0x00, // <-- bitmap
0x6c, // <-- rate (in 500kHz units)
0x0c, //<-- tx power
0x01 //<-- antenna
Using the Radiotap Parser
-------------------------
If you are having to parse a radiotap struct, you can radically simplify the
job by using the radiotap parser that lives in net/wireless/radiotap.c and has
its prototypes available in include/net/cfg80211.h. You use it like this:
#include <net/cfg80211.h>
/* buf points to the start of the radiotap header part */
int MyFunction(u8 * buf, int buflen)
{
int pkt_rate_100kHz = 0, antenna = 0, pwr = 0;
struct ieee80211_radiotap_iterator iterator;
int ret = ieee80211_radiotap_iterator_init(&iterator, buf, buflen);
while (!ret) {
ret = ieee80211_radiotap_iterator_next(&iterator);
if (ret)
continue;
/* see if this argument is something we can use */
switch (iterator.this_arg_index) {
/*
* You must take care when dereferencing iterator.this_arg
* for multibyte types... the pointer is not aligned. Use
* get_unaligned((type *)iterator.this_arg) to dereference
* iterator.this_arg for type "type" safely on all arches.
*/
case IEEE80211_RADIOTAP_RATE:
/* radiotap "rate" u8 is in
* 500kbps units, eg, 0x02=1Mbps
*/
pkt_rate_100kHz = (*iterator.this_arg) * 5;
break;
case IEEE80211_RADIOTAP_ANTENNA:
/* radiotap uses 0 for 1st ant */
antenna = *iterator.this_arg);
break;
case IEEE80211_RADIOTAP_DBM_TX_POWER:
pwr = *iterator.this_arg;
break;
default:
break;
}
} /* while more rt headers */
if (ret != -ENOENT)
return TXRX_DROP;
/* discard the radiotap header part */
buf += iterator.max_length;
buflen -= iterator.max_length;
...
}
Andy Green <andy@warmcat.com>

568
Documentation/networking/sk98lin.txt
View File

@ -1,568 +0,0 @@
(C)Copyright 1999-2004 Marvell(R).
All rights reserved
===========================================================================
sk98lin.txt created 13-Feb-2004
Readme File for sk98lin v6.23
Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX
This file contains
1 Overview
2 Required Files
3 Installation
3.1 Driver Installation
3.2 Inclusion of adapter at system start
4 Driver Parameters
4.1 Per-Port Parameters
4.2 Adapter Parameters
5 Large Frame Support
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
7 Troubleshooting
===========================================================================
1 Overview
===========
The sk98lin driver supports the Marvell Yukon and SysKonnect
SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has
been tested with Linux on Intel/x86 machines.
***
2 Required Files
=================
The linux kernel source.
No additional files required.
***
3 Installation
===============
It is recommended to download the latest version of the driver from the
SysKonnect web site www.syskonnect.com. If you have downloaded the latest
driver, the Linux kernel has to be patched before the driver can be
installed. For details on how to patch a Linux kernel, refer to the
patch.txt file.
3.1 Driver Installation
------------------------
The following steps describe the actions that are required to install
the driver and to start it manually. These steps should be carried
out for the initial driver setup. Once confirmed to be ok, they can
be included in the system start.
NOTE 1: To perform the following tasks you need 'root' access.
NOTE 2: In case of problems, please read the section "Troubleshooting"
below.
The driver can either be integrated into the kernel or it can be compiled
as a module. Select the appropriate option during the kernel
configuration.
Compile/use the driver as a module
----------------------------------
To compile the driver, go to the directory /usr/src/linux and
execute the command "make menuconfig" or "make xconfig" and proceed as
follows:
To integrate the driver permanently into the kernel, proceed as follows:
1. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
with (*)
3. Build a new kernel when the configuration of the above options is
finished.
4. Install the new kernel.
5. Reboot your system.
To use the driver as a module, proceed as follows:
1. Enable 'loadable module support' in the kernel.
2. For automatic driver start, enable the 'Kernel module loader'.
3. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
with (M)
5. Execute the command "make modules".
6. Execute the command "make modules_install".
The appropriate modules will be installed.
7. Reboot your system.
Load the module manually
------------------------
To load the module manually, proceed as follows:
1. Enter "modprobe sk98lin".
2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in
your computer and you have a /proc file system, execute the command:
"ls /proc/net/sk98lin/"
This should produce an output containing a line with the following
format:
eth0 eth1 ...
which indicates that your adapter has been found and initialized.
NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx
adapter installed, the adapters will be listed as 'eth0',
'eth1', 'eth2', etc.
For each adapter, repeat steps 3 and 4 below.
NOTE 2: If you have other Ethernet adapters installed, your Marvell
Yukon or SysKonnect SK-98xx adapter will be mapped to the
next available number, e.g. 'eth1'. The mapping is executed
automatically.
The module installation message (displayed either in a system
log file or on the console) prints a line for each adapter
found containing the corresponding 'ethX'.
3. Select an IP address and assign it to the respective adapter by
entering:
ifconfig eth0 <ip-address>
With this command, the adapter is connected to the Ethernet.
SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter
is now active, the link status LED of the primary port is active and
the link status LED of the secondary port (on dual port adapters) is
blinking (if the ports are connected to a switch or hub).
SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active.
In addition, you will receive a status message on the console stating
"ethX: network connection up using port Y" and showing the selected
connection parameters (x stands for the ethernet device number
(0,1,2, etc), y stands for the port name (A or B)).
NOTE: If you are in doubt about IP addresses, ask your network
administrator for assistance.
4. Your adapter should now be fully operational.
Use 'ping <otherstation>' to verify the connection to other computers
on your network.
5. To check the adapter configuration view /proc/net/sk98lin/[devicename].
For example by executing:
"cat /proc/net/sk98lin/eth0"
Unload the module
-----------------
To stop and unload the driver modules, proceed as follows:
1. Execute the command "ifconfig eth0 down".
2. Execute the command "rmmod sk98lin".
3.2 Inclusion of adapter at system start
-----------------------------------------
Since a large number of different Linux distributions are
available, we are unable to describe a general installation procedure
for the driver module.
Because the driver is now integrated in the kernel, installation should
be easy, using the standard mechanism of your distribution.
Refer to the distribution's manual for installation of ethernet adapters.
***
4 Driver Parameters
====================
Parameters can be set at the command line after the module has been
loaded with the command 'modprobe'.
In some distributions, the configuration tools are able to pass parameters
to the driver module.
If you use the kernel module loader, you can set driver parameters
in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier).
To set the driver parameters in this file, proceed as follows:
1. Insert a line of the form :
options sk98lin ...
For "...", the same syntax is required as described for the command
line parameters of modprobe below.
2. To activate the new parameters, either reboot your computer
or
unload and reload the driver.
The syntax of the driver parameters is:
modprobe sk98lin parameter=value1[,value2[,value3...]]
where value1 refers to the first adapter, value2 to the second etc.
NOTE: All parameters are case sensitive. Write them exactly as shown
below.
Example:
Suppose you have two adapters. You want to set auto-negotiation
on the first adapter to ON and on the second adapter to OFF.
You also want to set DuplexCapabilities on the first adapter
to FULL, and on the second adapter to HALF.
Then, you must enter:
modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half
NOTE: The number of adapters that can be configured this way is
limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM).
The current limit is 16. If you happen to install
more adapters, adjust this and recompile.
4.1 Per-Port Parameters
------------------------
These settings are available for each port on the adapter.
In the following description, '?' stands for the port for
which you set the parameter (A or B).
Speed
-----
Parameter: Speed_?
Values: 10, 100, 1000, Auto
Default: Auto
This parameter is used to set the speed capabilities. It is only valid
for the SK-98xx V2.0 copper adapters.
Usually, the speed is negotiated between the two ports during link
establishment. If this fails, a port can be forced to a specific setting
with this parameter.
Auto-Negotiation
----------------
Parameter: AutoNeg_?
Values: On, Off, Sense
Default: On
The "Sense"-mode automatically detects whether the link partner supports
auto-negotiation or not.
Duplex Capabilities
-------------------
Parameter: DupCap_?
Values: Half, Full, Both
Default: Both
This parameters is only relevant if auto-negotiation for this port is
not set to "Sense". If auto-negotiation is set to "On", all three values
are possible. If it is set to "Off", only "Full" and "Half" are allowed.
This parameter is useful if your link partner does not support all
possible combinations.
Flow Control
------------
Parameter: FlowCtrl_?
Values: Sym, SymOrRem, LocSend, None
Default: SymOrRem
This parameter can be used to set the flow control capabilities the
port reports during auto-negotiation. It can be set for each port
individually.
Possible modes:
-- Sym = Symmetric: both link partners are allowed to send
PAUSE frames
-- SymOrRem = SymmetricOrRemote: both or only remote partner
are allowed to send PAUSE frames
-- LocSend = LocalSend: only local link partner is allowed
to send PAUSE frames
-- None = no link partner is allowed to send PAUSE frames
NOTE: This parameter is ignored if auto-negotiation is set to "Off".
Role in Master-Slave-Negotiation (1000Base-T only)
--------------------------------------------------
Parameter: Role_?
Values: Auto, Master, Slave
Default: Auto
This parameter is only valid for the SK-9821 and SK-9822 adapters.
For two 1000Base-T ports to communicate, one must take the role of the
master (providing timing information), while the other must be the
slave. Usually, this is negotiated between the two ports during link
establishment. If this fails, a port can be forced to a specific setting
with this parameter.
4.2 Adapter Parameters
-----------------------
Connection Type (SK-98xx V2.0 copper adapters only)
---------------
Parameter: ConType
Values: Auto, 100FD, 100HD, 10FD, 10HD
Default: Auto
The parameter 'ConType' is a combination of all five per-port parameters
within one single parameter. This simplifies the configuration of both ports
of an adapter card! The different values of this variable reflect the most
meaningful combinations of port parameters.
The following table shows the values of 'ConType' and the corresponding
combinations of the per-port parameters:
ConType | DupCap AutoNeg FlowCtrl Role Speed
----------+------------------------------------------------------
Auto | Both On SymOrRem Auto Auto
100FD | Full Off None Auto (ignored) 100
100HD | Half Off None Auto (ignored) 100
10FD | Full Off None Auto (ignored) 10
10HD | Half Off None Auto (ignored) 10
Stating any other port parameter together with this 'ConType' variable
will result in a merged configuration of those settings. This due to
the fact, that the per-port parameters (e.g. Speed_? ) have a higher
priority than the combined variable 'ConType'.
NOTE: This parameter is always used on both ports of the adapter card.
Interrupt Moderation
--------------------
Parameter: Moderation
Values: None, Static, Dynamic
Default: None
Interrupt moderation is employed to limit the maximum number of interrupts
the driver has to serve. That is, one or more interrupts (which indicate any
transmit or receive packet to be processed) are queued until the driver
processes them. When queued interrupts are to be served, is determined by the
'IntsPerSec' parameter, which is explained later below.
Possible modes:
-- None - No interrupt moderation is applied on the adapter card.
Therefore, each transmit or receive interrupt is served immediately
as soon as it appears on the interrupt line of the adapter card.
-- Static - Interrupt moderation is applied on the adapter card.
All transmit and receive interrupts are queued until a complete
moderation interval ends. If such a moderation interval ends, all
queued interrupts are processed in one big bunch without any delay.
The term 'static' reflects the fact, that interrupt moderation is
always enabled, regardless how much network load is currently
passing via a particular interface. In addition, the duration of
the moderation interval has a fixed length that never changes while
the driver is operational.
-- Dynamic - Interrupt moderation might be applied on the adapter card,
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 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
interfaces with a high network load, which - as a consequence - leads also to a
high CPU utilization. When moderation is applied in such high network load
situations, CPU load might be reduced by 20-30%.
NOTE: The drawback of using interrupt moderation is an increase of the round-
trip-time (RTT), due to the queueing and serving of interrupts at dedicated
moderation times.
Interrupts per second
---------------------
Parameter: IntsPerSec
Values: 30...40000 (interrupts per second)
Default: 2000
This parameter is only used if either static or dynamic interrupt moderation
is used on a network adapter card. Using this parameter if no moderation is
applied will lead to no action performed.
This parameter determines the length of any interrupt moderation interval.
Assuming that static interrupt moderation is to be used, an 'IntsPerSec'
parameter value of 2000 will lead to an interrupt moderation interval of
500 microseconds.
NOTE: The duration of the moderation interval is to be chosen with care.
At first glance, selecting a very long duration (e.g. only 100 interrupts per
second) seems to be meaningful, but the increase of packet-processing delay
is tremendous. On the other hand, selecting a very short moderation time might
compensate the use of any moderation being applied.
Preferred Port
--------------
Parameter: PrefPort
Values: A, B
Default: A
This is used to force the preferred port to A or B (on dual-port network
adapters). The preferred port is the one that is used if both are detected
as fully functional.
RLMT Mode (Redundant Link Management Technology)
------------------------------------------------
Parameter: RlmtMode
Values: CheckLinkState,CheckLocalPort, CheckSeg, DualNet
Default: CheckLinkState
RLMT monitors the status of the port. If the link of the active port
fails, RLMT switches immediately to the standby link. The virtual link is
maintained as long as at least one 'physical' link is up.
Possible modes:
-- CheckLinkState - Check link state only: RLMT uses the link state
reported by the adapter hardware for each individual port to
determine whether a port can be used for all network traffic or
not.
-- CheckLocalPort - In this mode, RLMT monitors the network path
between the two ports of an adapter by regularly exchanging packets
between them. This mode requires a network configuration in which
the two ports are able to "see" each other (i.e. there must not be
any router between the ports).
-- CheckSeg - Check local port and segmentation: This mode supports the
same functions as the CheckLocalPort mode and additionally checks
network segmentation between the ports. Therefore, this mode is only
to be used if Gigabit Ethernet switches are installed on the network
that have been configured to use the Spanning Tree protocol.
-- DualNet - In this mode, ports A and B are used as separate devices.
If you have a dual port adapter, port A will be configured as eth0
and port B as eth1. Both ports can be used independently with
distinct IP addresses. The preferred port setting is not used.
RLMT is turned off.
NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations
where a network path between the ports on one adapter exists.
Moreover, they are not designed to work where adapters are connected
back-to-back.
***
5 Large Frame Support
======================
The driver supports large frames (also called jumbo frames). Using large
frames can result in an improved throughput if transferring large amounts
of data.
To enable large frames, set the MTU (maximum transfer unit) of the
interface to the desired value (up to 9000), execute the following
command:
ifconfig eth0 mtu 9000
This will only work if you have two adapters connected back-to-back
or if you use a switch that supports large frames. When using a switch,
it should be configured to allow large frames and auto-negotiation should
be set to OFF. The setting must be configured on all adapters that can be
reached by the large frames. If one adapter is not set to receive large
frames, it will simply drop them.
You can switch back to the standard ethernet frame size by executing the
following command:
ifconfig eth0 mtu 1500
To permanently configure this setting, add a script with the 'ifconfig'
line to the system startup sequence (named something like "S99sk98lin"
in /etc/rc.d/rc2.d).
***
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
==================================================================
The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and
Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad.
These features are only available after installation of open source
modules available on the Internet:
For VLAN go to: http://www.candelatech.com/~greear/vlan.html
For Link Aggregation go to: http://www.st.rim.or.jp/~yumo
NOTE: SysKonnect GmbH does not offer any support for these open source
modules and does not take the responsibility for any kind of
failures or problems arising in connection with these modules.
NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may
cause problems when unloading the driver.
7 Troubleshooting
==================
If any problems occur during the installation process, check the
following list:
Problem: The SK-98xx adapter cannot be found by the driver.
Solution: In /proc/pci search for the following entry:
'Ethernet controller: SysKonnect SK-98xx ...'
If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has
been found by the system and should be operational.
If this entry does not exist or if the file '/proc/pci' is not
found, there may be a hardware problem or the PCI support may
not be enabled in your kernel.
The adapter can be checked using the diagnostics program which
is available on the SysKonnect web site:
www.syskonnect.com
Some COMPAQ machines have problems dealing with PCI under Linux.
This problem is described in the 'PCI howto' document
(included in some distributions or available from the
web, e.g. at 'www.linux.org').
Problem: Programs such as 'ifconfig' or 'route' cannot be found or the
error message 'Operation not permitted' is displayed.
Reason: You are not logged in as user 'root'.
Solution: Logout and login as 'root' or change to 'root' via 'su'.
Problem: Upon use of the command 'ping <address>' the message
"ping: sendto: Network is unreachable" is displayed.
Reason: Your route is not set correctly.
Solution: If you are using RedHat, you probably forgot to set up the
route in the 'network configuration'.
Check the existing routes with the 'route' command and check
if an entry for 'eth0' exists, and if so, if it is set correctly.
Problem: The driver can be started, the adapter is connected to the
network, but you cannot receive or transmit any packets;
e.g. 'ping' does not work.
Reason: There is an incorrect route in your routing table.
Solution: Check the routing table with the command 'route' and read the
manual help pages dealing with routes (enter 'man route').
NOTE: Although the 2.2.x kernel versions generate the routing entry
automatically, problems of this kind may occur here as well. We've
come across a situation in which the driver started correctly at
system start, but after the driver has been removed and reloaded,
the route of the adapter's network pointed to the 'dummy0'device
and had to be corrected manually.
Problem: Your computer should act as a router between multiple
IP subnetworks (using multiple adapters), but computers in
other subnetworks cannot be reached.
Reason: Either the router's kernel is not configured for IP forwarding
or the routing table and gateway configuration of at least one
computer is not working.
Problem: Upon driver start, the following error message is displayed:
"eth0: -- ERROR --
Class: internal Software error
Nr: 0xcc
Msg: SkGeInitPort() cannot init running ports"
Reason: You are using a driver compiled for single processor machines
on a multiprocessor machine with SMP (Symmetric MultiProcessor)
kernel.
Solution: Configure your kernel appropriately and recompile the kernel or
the modules.
If your problem is not listed here, please contact SysKonnect's technical
support for help (linux@syskonnect.de).
When contacting our technical support, please ensure that the following
information is available:
- System Manufacturer and HW Informations (CPU, Memory... )
- PCI-Boards in your system
- Distribution
- Kernel version
- Driver version
***
***End of Readme File***

204
Documentation/networking/spider_net.txt Normal file
View File

@ -0,0 +1,204 @@
The Spidernet Device Driver
===========================
Written by Linas Vepstas <linas@austin.ibm.com>
Version of 7 June 2007
Abstract
========
This document sketches the structure of portions of the spidernet
device driver in the Linux kernel tree. The spidernet is a gigabit
ethernet device built into the Toshiba southbridge commonly used
in the SONY Playstation 3 and the IBM QS20 Cell blade.
The Structure of the RX Ring.
=============================
The receive (RX) ring is a circular linked list of RX descriptors,
together with three pointers into the ring that are used to manage its
contents.
The elements of the ring are called "descriptors" or "descrs"; they
describe the received data. This includes a pointer to a buffer
containing the received data, the buffer size, and various status bits.
There are three primary states that a descriptor can be in: "empty",
"full" and "not-in-use". An "empty" or "ready" descriptor is ready
to receive data from the hardware. A "full" descriptor has data in it,
and is waiting to be emptied and processed by the OS. A "not-in-use"
descriptor is neither empty or full; it is simply not ready. It may
not even have a data buffer in it, or is otherwise unusable.
During normal operation, on device startup, the OS (specifically, the
spidernet device driver) allocates a set of RX descriptors and RX
buffers. These are all marked "empty", ready to receive data. This
ring is handed off to the hardware, which sequentially fills in the
buffers, and marks them "full". The OS follows up, taking the full
buffers, processing them, and re-marking them empty.
This filling and emptying is managed by three pointers, the "head"
and "tail" pointers, managed by the OS, and a hardware current
descriptor pointer (GDACTDPA). The GDACTDPA points at the descr
currently being filled. When this descr is filled, the hardware
marks it full, and advances the GDACTDPA by one. Thus, when there is
flowing RX traffic, every descr behind it should be marked "full",
and everything in front of it should be "empty". If the hardware
discovers that the current descr is not empty, it will signal an
interrupt, and halt processing.
The tail pointer tails or trails the hardware pointer. When the
hardware is ahead, the tail pointer will be pointing at a "full"
descr. The OS will process this descr, and then mark it "not-in-use",
and advance the tail pointer. Thus, when there is flowing RX traffic,
all of the descrs in front of the tail pointer should be "full", and
all of those behind it should be "not-in-use". When RX traffic is not
flowing, then the tail pointer can catch up to the hardware pointer.
The OS will then note that the current tail is "empty", and halt
processing.
The head pointer (somewhat mis-named) follows after the tail pointer.
When traffic is flowing, then the head pointer will be pointing at
a "not-in-use" descr. The OS will perform various housekeeping duties
on this descr. This includes allocating a new data buffer and
dma-mapping it so as to make it visible to the hardware. The OS will
then mark the descr as "empty", ready to receive data. Thus, when there
is flowing RX traffic, everything in front of the head pointer should
be "not-in-use", and everything behind it should be "empty". If no
RX traffic is flowing, then the head pointer can catch up to the tail
pointer, at which point the OS will notice that the head descr is
"empty", and it will halt processing.
Thus, in an idle system, the GDACTDPA, tail and head pointers will
all be pointing at the same descr, which should be "empty". All of the
other descrs in the ring should be "empty" as well.
The show_rx_chain() routine will print out the the locations of the
GDACTDPA, tail and head pointers. It will also summarize the contents
of the ring, starting at the tail pointer, and listing the status
of the descrs that follow.
A typical example of the output, for a nearly idle system, might be
net eth1: Total number of descrs=256
net eth1: Chain tail located at descr=20
net eth1: Chain head is at 20
net eth1: HW curr desc (GDACTDPA) is at 21
net eth1: Have 1 descrs with stat=x40800101
net eth1: HW next desc (GDACNEXTDA) is at 22
net eth1: Last 255 descrs with stat=xa0800000
In the above, the hardware has filled in one descr, number 20. Both
head and tail are pointing at 20, because it has not yet been emptied.
Meanwhile, hw is pointing at 21, which is free.
The "Have nnn decrs" refers to the descr starting at the tail: in this
case, nnn=1 descr, starting at descr 20. The "Last nnn descrs" refers
to all of the rest of the descrs, from the last status change. The "nnn"
is a count of how many descrs have exactly the same status.
The status x4... corresponds to "full" and status xa... corresponds
to "empty". The actual value printed is RXCOMST_A.
In the device driver source code, a different set of names are
used for these same concepts, so that
"empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa
"full" == SPIDER_NET_DESCR_FRAME_END == 0x4
"not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf
The RX RAM full bug/feature
===========================
As long as the OS can empty out the RX buffers at a rate faster than
the hardware can fill them, there is no problem. If, for some reason,
the OS fails to empty the RX ring fast enough, the hardware GDACTDPA
pointer will catch up to the head, notice the not-empty condition,
ad stop. However, RX packets may still continue arriving on the wire.
The spidernet chip can save some limited number of these in local RAM.
When this local ram fills up, the spider chip will issue an interrupt
indicating this (GHIINT0STS will show ERRINT, and the GRMFLLINT bit
will be set in GHIINT1STS). When the RX ram full condition occurs,
a certain bug/feature is triggered that has to be specially handled.
This section describes the special handling for this condition.
When the OS finally has a chance to run, it will empty out the RX ring.
In particular, it will clear the descriptor on which the hardware had
stopped. However, once the hardware has decided that a certain
descriptor is invalid, it will not restart at that descriptor; instead
it will restart at the next descr. This potentially will lead to a
deadlock condition, as the tail pointer will be pointing at this descr,
which, from the OS point of view, is empty; the OS will be waiting for
this descr to be filled. However, the hardware has skipped this descr,
and is filling the next descrs. Since the OS doesn't see this, there
is a potential deadlock, with the OS waiting for one descr to fill,
while the hardware is waiting for a different set of descrs to become
empty.
A call to show_rx_chain() at this point indicates the nature of the
problem. A typical print when the network is hung shows the following:
net eth1: Spider RX RAM full, incoming packets might be discarded!
net eth1: Total number of descrs=256
net eth1: Chain tail located at descr=255
net eth1: Chain head is at 255
net eth1: HW curr desc (GDACTDPA) is at 0
net eth1: Have 1 descrs with stat=xa0800000
net eth1: HW next desc (GDACNEXTDA) is at 1
net eth1: Have 127 descrs with stat=x40800101
net eth1: Have 1 descrs with stat=x40800001
net eth1: Have 126 descrs with stat=x40800101
net eth1: Last 1 descrs with stat=xa0800000
Both the tail and head pointers are pointing at descr 255, which is
marked xa... which is "empty". Thus, from the OS point of view, there
is nothing to be done. In particular, there is the implicit assumption
that everything in front of the "empty" descr must surely also be empty,
as explained in the last section. The OS is waiting for descr 255 to
become non-empty, which, in this case, will never happen.
The HW pointer is at descr 0. This descr is marked 0x4.. or "full".
Since its already full, the hardware can do nothing more, and thus has
halted processing. Notice that descrs 0 through 254 are all marked
"full", while descr 254 and 255 are empty. (The "Last 1 descrs" is
descr 254, since tail was at 255.) Thus, the system is deadlocked,
and there can be no forward progress; the OS thinks there's nothing
to do, and the hardware has nowhere to put incoming data.
This bug/feature is worked around with the spider_net_resync_head_ptr()
routine. When the driver receives RX interrupts, but an examination
of the RX chain seems to show it is empty, then it is probable that
the hardware has skipped a descr or two (sometimes dozens under heavy
network conditions). The spider_net_resync_head_ptr() subroutine will
search the ring for the next full descr, and the driver will resume
operations there. Since this will leave "holes" in the ring, there
is also a spider_net_resync_tail_ptr() that will skip over such holes.
As of this writing, the spider_net_resync() strategy seems to work very
well, even under heavy network loads.
The TX ring
===========
The TX ring uses a low-watermark interrupt scheme to make sure that
the TX queue is appropriately serviced for large packet sizes.
For packet sizes greater than about 1KBytes, the kernel can fill
the TX ring quicker than the device can drain it. Once the ring
is full, the netdev is stopped. When there is room in the ring,
the netdev needs to be reawakened, so that more TX packets are placed
in the ring. The hardware can empty the ring about four times per jiffy,
so its not appropriate to wait for the poll routine to refill, since
the poll routine runs only once per jiffy. The low-watermark mechanism
marks a descr about 1/4th of the way from the bottom of the queue, so
that an interrupt is generated when the descr is processed. This
interrupt wakes up the netdev, which can then refill the queue.
For large packets, this mechanism generates a relatively small number
of interrupts, about 1K/sec. For smaller packets, this will drop to zero
interrupts, as the hardware can empty the queue faster than the kernel
can fill it.
======= END OF DOCUMENT ========

16
Documentation/oops-tracing.txt
View File

@ -86,6 +86,20 @@ stuff are the values reported by the Oops - you can just cut-and-paste
and do a replace of spaces to "\x" - that's what I do, as I'm too lazy
to write a program to automate this all).
Alternatively, you can use the shell script in scripts/decodecode.
Its usage is: decodecode < oops.txt
The hex bytes that follow "Code:" may (in some architectures) have a series
of bytes that precede the current instruction pointer as well as bytes at and
following the current instruction pointer. In some cases, one instruction
byte or word is surrounded by <> or (), as in "<86>" or "(f00d)". These
<> or () markings indicate the current instruction pointer. Example from
i386, split into multiple lines for readability:
Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
Finally, if you want to see where the code comes from, you can do
cd /usr/src/linux
@ -237,6 +251,8 @@ characters, each representing a particular tainted value.
7: 'U' if a user or user application specifically requested that the
Tainted flag be set, ' ' otherwise.
8: 'D' if the kernel has died recently, i.e. there was an OOPS or BUG.
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is

8
Documentation/pci.txt
View File

@ -113,9 +113,6 @@ initialization with a pointer to a structure describing the driver
(Please see Documentation/power/pci.txt for descriptions
of PCI Power Management and the related functions.)
enable_wake Enable device to generate wake events from a low power
state.
shutdown Hook into reboot_notifier_list (kernel/sys.c).
Intended to stop any idling DMA operations.
Useful for enabling wake-on-lan (NIC) or changing
@ -299,7 +296,10 @@ If the PCI device can use the PCI Memory-Write-Invalidate transaction,
call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval
and also ensures that the cache line size register is set correctly.
Check the return value of pci_set_mwi() as not all architectures
or chip-sets may support Memory-Write-Invalidate.
or chip-sets may support Memory-Write-Invalidate. Alternatively,
if Mem-Wr-Inval would be nice to have but is not required, call
pci_try_set_mwi() to have the system do its best effort at enabling
Mem-Wr-Inval.
3.2 Request MMIO/IOP resources

160
Documentation/power/freezing-of-tasks.txt Normal file
View File

@ -0,0 +1,160 @@
Freezing of tasks
(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
I. What is the freezing of tasks?
The freezing of tasks is a mechanism by which user space processes and some
kernel threads are controlled during hibernation or system-wide suspend (on some
architectures).
II. How does it work?
There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, TIF_FREEZE
and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
PF_NOFREEZE unset (all user space processes and some kernel threads) are
regarded as 'freezable' and treated in a special way before the system enters a
suspend state as well as before a hibernation image is created (in what follows
we only consider hibernation, but the description also applies to suspend).
Namely, as the first step of the hibernation procedure the function
freeze_processes() (defined in kernel/power/process.c) is called. It executes
try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
sends a fake signal to each of them. A task that receives such a signal and has
TIF_FREEZE set, should react to it by calling the refrigerator() function
(defined in kernel/power/process.c), which sets the task's PF_FROZEN flag,
changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is
cleared for it. Then, we say that the task is 'frozen' and therefore the set of
functions handling this mechanism is called 'the freezer' (these functions are
defined in kernel/power/process.c and include/linux/freezer.h). User space
processes are generally frozen before kernel threads.
It is not recommended to call refrigerator() directly. Instead, it is
recommended to use the try_to_freeze() function (defined in
include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the
task enter refrigerator() if the flag is set.
For user space processes try_to_freeze() is called automatically from the
signal-handling code, but the freezable kernel threads need to call it
explicitly in suitable places. The code to do this may look like the following:
do {
hub_events();
wait_event_interruptible(khubd_wait,
!list_empty(&hub_event_list));
try_to_freeze();
} while (!signal_pending(current));
(from drivers/usb/core/hub.c::hub_thread()).
If a freezable kernel thread fails to call try_to_freeze() after the freezer has
set TIF_FREEZE for it, the freezing of tasks will fail and the entire
hibernation operation will be cancelled. For this reason, freezable kernel
threads must call try_to_freeze() somewhere.
After the system memory state has been restored from a hibernation image and
devices have been reinitialized, the function thaw_processes() is called in
order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
have been frozen leave refrigerator() and continue running.
III. Which kernel threads are freezable?
Kernel threads are not freezable by default. However, a kernel thread may clear
PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
directly is strongly discouraged). From this point it is regarded as freezable
and must call try_to_freeze() in a suitable place.
IV. Why do we do that?
Generally speaking, there is a couple of reasons to use the freezing of tasks:
1. The principal reason is to prevent filesystems from being damaged after
hibernation. At the moment we have no simple means of checkpointing
filesystems, so if there are any modifications made to filesystem data and/or
metadata on disks, we cannot bring them back to the state from before the
modifications. At the same time each hibernation image contains some
filesystem-related information that must be consistent with the state of the
on-disk data and metadata after the system memory state has been restored from
the image (otherwise the filesystems will be damaged in a nasty way, usually
making them almost impossible to repair). We therefore freeze tasks that might
cause the on-disk filesystems' data and metadata to be modified after the
hibernation image has been created and before the system is finally powered off.
The majority of these are user space processes, but if any of the kernel threads
may cause something like this to happen, they have to be freezable.
2. The second reason is to prevent user space processes and some kernel threads
from interfering with the suspending and resuming of devices. A user space
process running on a second CPU while we are suspending devices may, for
example, be troublesome and without the freezing of tasks we would need some
safeguards against race conditions that might occur in such a case.
Although Linus Torvalds doesn't like the freezing of tasks, he said this in one
of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
"RJW:> Why we freeze tasks at all or why we freeze kernel threads?
Linus: In many ways, 'at all'.
I _do_ realize the IO request queue issues, and that we cannot actually do
s2ram with some devices in the middle of a DMA. So we want to be able to
avoid *that*, there's no question about that. And I suspect that stopping
user threads and then waiting for a sync is practically one of the easier
ways to do so.
So in practice, the 'at all' may become a 'why freeze kernel threads?' and
freezing user threads I don't find really objectionable."
Still, there are kernel threads that may want to be freezable. For example, if
a kernel that belongs to a device driver accesses the device directly, it in
principle needs to know when the device is suspended, so that it doesn't try to
access it at that time. However, if the kernel thread is freezable, it will be
frozen before the driver's .suspend() callback is executed and it will be
thawed after the driver's .resume() callback has run, so it won't be accessing
the device while it's suspended.
3. Another reason for freezing tasks is to prevent user space processes from
realizing that hibernation (or suspend) operation takes place. Ideally, user
space processes should not notice that such a system-wide operation has occurred
and should continue running without any problems after the restore (or resume
from suspend). Unfortunately, in the most general case this is quite difficult
to achieve without the freezing of tasks. Consider, for example, a process
that depends on all CPUs being online while it's running. Since we need to
disable nonboot CPUs during the hibernation, if this process is not frozen, it
may notice that the number of CPUs has changed and may start to work incorrectly
because of that.
V. Are there any problems related to the freezing of tasks?
Yes, there are.
First of all, the freezing of kernel threads may be tricky if they depend one
on another. For example, if kernel thread A waits for a completion (in the
TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
and B is frozen in the meantime, then A will be blocked until B is thawed, which
may be undesirable. That's why kernel threads are not freezable by default.
Second, there are the following two problems related to the freezing of user
space processes:
1. Putting processes into an uninterruptible sleep distorts the load average.
2. Now that we have FUSE, plus the framework for doing device drivers in
userspace, it gets even more complicated because some userspace processes are
now doing the sorts of things that kernel threads do
(https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
The problem 1. seems to be fixable, although it hasn't been fixed so far. The
other one is more serious, but it seems that we can work around it by using
hibernation (and suspend) notifiers (in that case, though, we won't be able to
avoid the realization by the user space processes that the hibernation is taking
place).
There are also problems that the freezing of tasks tends to expose, although
they are not directly related to it. For example, if request_firmware() is
called from a device driver's .resume() routine, it will timeout and eventually
fail, because the user land process that should respond to the request is frozen
at this point. So, seemingly, the failure is due to the freezing of tasks.
Suppose, however, that the firmware file is located on a filesystem accessible
only through another device that hasn't been resumed yet. In that case,
request_firmware() will fail regardless of whether or not the freezing of tasks
is used. Consequently, the problem is not really related to the freezing of
tasks, since it generally exists anyway. [The solution to this particular
problem is to keep the firmware in memory after it's loaded for the first time
and upload if from memory to the device whenever necessary.]

40
Documentation/power/kernel_threads.txt
View File

@ -1,40 +0,0 @@
KERNEL THREADS
Freezer
Upon entering a suspended state the system will freeze all
tasks. This is done by delivering pseudosignals. This affects
kernel threads, too. To successfully freeze a kernel thread
the thread has to check for the pseudosignal and enter the
refrigerator. Code to do this looks like this:
do {
hub_events();
wait_event_interruptible(khubd_wait, !list_empty(&hub_event_list));
try_to_freeze();
} while (!signal_pending(current));
from drivers/usb/core/hub.c::hub_thread()
The Unfreezable
Some kernel threads however, must not be frozen. The kernel must
be able to finish pending IO operations and later on be able to
write the memory image to disk. Kernel threads needed to do IO
must stay awake. Such threads must mark themselves unfreezable
like this:
/*
* This thread doesn't need any user-level access,
* so get rid of all our resources.
*/
daemonize("usb-storage");
current->flags |= PF_NOFREEZE;
from drivers/usb/storage/usb.c::usb_stor_control_thread()
Such drivers are themselves responsible for staying quiet during
the actual snapshotting.

37
Documentation/power/pci.txt
View File

@ -164,7 +164,6 @@ struct pci_driver:
int (*suspend) (struct pci_dev *dev, pm_message_t state);
int (*resume) (struct pci_dev *dev);
int (*enable_wake) (struct pci_dev *dev, pci_power_t state, int enable);
suspend
@ -251,42 +250,6 @@ The driver should update the current_state field in its pci_dev structure in
this function, except for PM-capable devices when pci_set_power_state is used.
enable_wake
-----------
Usage:
if (dev->driver && dev->driver->enable_wake)
dev->driver->enable_wake(dev,state,enable);
This callback is generally only relevant for devices that support the PCI PM
spec and have the ability to generate a PME# (Power Management Event Signal)
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 Capabilities describe what power states the device supports generating a
wake event from:
+------------------+
| Bit | State |
+------------------+
| 11 | D0 |
| 12 | D1 |
| 13 | D2 |
| 14 | D3hot |
| 15 | D3cold |
+------------------+
A device can use this to enable wake events:
pci_enable_wake(dev,state,enable);
Note that to enable PME# from D3cold, a value of 4 should be passed to
pci_enable_wake (since it uses an index into a bitmask). If a driver gets
a request to enable wake events from D3, two calls should be made to
pci_enable_wake (one for both D3hot and D3cold).
A reference implementation
-------------------------

21
Documentation/power/swsusp.txt
View File

@ -140,21 +140,11 @@ should be sent to the mailing list available through the suspend2
website, and not to the Linux Kernel Mailing List. We are working
toward merging suspend2 into the mainline kernel.
Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
I found some kernel threads that don't do it, and they don't freeze
so the system can't sleep. Is this a known behavior?
A: All such kernel threads need to be fixed, one by one. Select the
place where the thread is safe to be frozen (no kernel semaphores
should be held at that point and it must be safe to sleep there), and
add:
try_to_freeze();
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 careful).
Q: What is the freezing of tasks and why are we using it?
A: The freezing of tasks is a mechanism by which user space processes and some
kernel threads are controlled during hibernation or system-wide suspend (on some
architectures). See freezing-of-tasks.txt for details.
Q: What is the difference between "platform" and "shutdown"?
@ -393,6 +383,9 @@ safest thing is to unmount all filesystems on removable media (such USB,
Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)
before suspending; then remount them after resuming.
There is a work-around for this problem. For more information, see
Documentation/usb/persist.txt.
Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
compiled with the similar configuration files. Anyway I found that
suspend to disk (and resume) is much slower on 2.6.16 compared to

167
Documentation/power_supply_class.txt Normal file
View File

@ -0,0 +1,167 @@
Linux power supply class
========================
Synopsis
~~~~~~~~
Power supply class used to represent battery, UPS, AC or DC power supply
properties to user-space.
It defines core set of attributes, which should be applicable to (almost)
every power supply out there. Attributes are available via sysfs and uevent
interfaces.
Each attribute has well defined meaning, up to unit of measure used. While
the attributes provided are believed to be universally applicable to any
power supply, specific monitoring hardware may not be able to provide them
all, so any of them may be skipped.
Power supply class is extensible, and allows to define drivers own attributes.
The core attribute set is subject to the standard Linux evolution (i.e.
if it will be found that some attribute is applicable to many power supply
types or their drivers, it can be added to the core set).
It also integrates with LED framework, for the purpose of providing
typically expected feedback of battery charging/fully charged status and
AC/USB power supply online status. (Note that specific details of the
indication (including whether to use it at all) are fully controllable by
user and/or specific machine defaults, per design principles of LED
framework).
Attributes/properties
~~~~~~~~~~~~~~~~~~~~~
Power supply class has predefined set of attributes, this eliminates code
duplication across drivers. Power supply class insist on reusing its
predefined attributes *and* their units.
So, userspace gets predictable set of attributes and their units for any
kind of power supply, and can process/present them to a user in consistent
manner. Results for different power supplies and machines are also directly
comparable.
See drivers/power/ds2760_battery.c and drivers/power/pda_power.c for the
example how to declare and handle attributes.
Units
~~~~~
Quoting include/linux/power_supply.h:
All voltages, currents, charges, energies, time and temperatures in µV,
µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
stated. It's driver's job to convert its raw values to units in which
this class operates.
Attributes/properties detailed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~
~ ~
~ Because both "charge" (µAh) and "energy" (µWh) represents "capacity" ~
~ of battery, this class distinguish these terms. Don't mix them! ~
~ ~
~ CHARGE_* attributes represents capacity in µAh only. ~
~ ENERGY_* attributes represents capacity in µWh only. ~
~ CAPACITY attribute represents capacity in *percents*, from 0 to 100. ~
~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Postfixes:
_AVG - *hardware* averaged value, use it if your hardware is really able to
report averaged values.
_NOW - momentary/instantaneous values.
STATUS - this attribute represents operating status (charging, full,
discharging (i.e. powering a load), etc.). This corresponds to
BATTERY_STATUS_* values, as defined in battery.h.
HEALTH - represents health of the battery, values corresponds to
POWER_SUPPLY_HEALTH_*, defined in battery.h.
VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and
minimal power supply voltages. Maximal/minimal means values of voltages
when battery considered "full"/"empty" at normal conditions. Yes, there is
no direct relation between voltage and battery capacity, but some dumb
batteries use voltage for very approximated calculation of capacity.
Battery driver also can use this attribute just to inform userspace
about maximal and minimal voltage thresholds of a given battery.
CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when
battery considered full/empty.
ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN - same as above but for energy.
CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value
of charge when battery became full/empty". It also could mean "value of
charge when battery considered full/empty at given conditions (temperature,
age)". I.e. these attributes represents real thresholds, not design values.
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
CAPACITY - capacity in percents.
CAPACITY_LEVEL - capacity level. This corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.
TEMP - temperature of the power supply.
TEMP_AMBIENT - ambient temperature.
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e.
while battery is charging)
Battery <-> external power supply interaction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Often power supplies are acting as supplies and supplicants at the same
time. Batteries are good example. So, batteries usually care if they're
externally powered or not.
For that case, power supply class implements notification mechanism for
batteries.
External power supply (AC) lists supplicants (batteries) names in
"supplied_to" struct member, and each power_supply_changed() call
issued by external power supply will notify supplicants via
external_power_changed callback.
QA
~~
Q: Where is POWER_SUPPLY_PROP_XYZ attribute?
A: If you cannot find attribute suitable for your driver needs, feel free
to add it and send patch along with your driver.
The attributes available currently are the ones currently provided by the
drivers written.
Good candidates to add in future: model/part#, cycle_time, manufacturer,
etc.
Q: I have some very specific attribute (e.g. battery color), should I add
this attribute to standard ones?
A: Most likely, no. Such attribute can be placed in the driver itself, if
it is useful. Of course, if the attribute in question applicable to
large set of batteries, provided by many drivers, and/or comes from
some general battery specification/standard, it may be a candidate to
be added to the core attribute set.
Q: Suppose, my battery monitoring chip/firmware does not provides capacity
in percents, but provides charge_{now,full,empty}. Should I calculate
percentage capacity manually, inside the driver, and register CAPACITY
attribute? The same question about time_to_empty/time_to_full.
A: Most likely, no. This class is designed to export properties which are
directly measurable by the specific hardware available.
Inferring not available properties using some heuristics or mathematical
model is not subject of work for a battery driver. Such functionality
should be factored out, and in fact, apm_power, the driver to serve
legacy APM API on top of power supply class, uses a simple heuristic of
approximating remaining battery capacity based on its charge, current,
voltage and so on. But full-fledged battery model is likely not subject
for kernel at all, as it would require floating point calculation to deal
with things like differential equations and Kalman filters. This is
better be handled by batteryd/libbattery, yet to be written.

40
Documentation/powerpc/booting-without-of.txt
View File

@ -42,15 +42,16 @@ Table of Contents
1) Defining child nodes of an SOC
2) Representing devices without a current OF specification
a) MDIO IO device
c) PHY nodes
b) Gianfar-compatible ethernet nodes
c) PHY nodes
d) Interrupt controllers
e) I2C
f) Freescale SOC USB controllers
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
g) Flash chip nodes
j) Flash chip nodes
k) Global Utilities Block
VII - Specifying interrupt information for devices
1) interrupts property
@ -626,6 +627,14 @@ So the node content can be summarized as a start token, a full path,
a list of properties, a list of child nodes, and an end token. Every
child node is a full node structure itself as defined above.
NOTE: The above definition requires that all property definitions for
a particular node MUST precede any subnode definitions for that node.
Although the structure would not be ambiguous if properties and
subnodes were intermingled, the kernel parser requires that the
properties come first (up until at least 2.6.22). Any tools
manipulating a flattened tree must take care to preserve this
constraint.
4) Device tree "strings" block
In order to save space, property names, which are generally redundant,
@ -1782,6 +1791,33 @@ platforms are moved over to use the flattened-device-tree model.
partition-names = "fs\0firmware";
};
k) Global Utilities Block
The global utilities block controls power management, I/O device
enabling, power-on-reset configuration monitoring, general-purpose
I/O signal configuration, alternate function selection for multiplexed
signals, and clock control.
Required properties:
- compatible : Should define the compatible device type for
global-utilities.
- reg : Offset and length of the register set for the device.
Recommended properties:
- fsl,has-rstcr : Indicates that the global utilities register set
contains a functioning "reset control register" (i.e. the board
is wired to reset upon setting the HRESET_REQ bit in this register).
Example:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices

2
Documentation/rtc.txt
View File

@ -385,7 +385,7 @@ test_PIE:
/* not all RTCs support periodic IRQs */
if (errno == ENOTTY) {
fprintf(stderr, "\nNo periodic IRQ support\n");
return 0;
goto done;
}
perror("RTC_IRQP_READ ioctl");
exit(errno);

119
Documentation/sched-design-CFS.txt Normal file
View File

@ -0,0 +1,119 @@
This is the CFS scheduler.
80% of CFS's design can be summed up in a single sentence: CFS basically
models an "ideal, precise multi-tasking CPU" on real hardware.
"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100%
physical power and which can run each task at precise equal speed, in
parallel, each at 1/nr_running speed. For example: if there are 2 tasks
running then it runs each at 50% physical power - totally in parallel.
On real hardware, we can run only a single task at once, so while that
one task runs, the other tasks that are waiting for the CPU are at a
disadvantage - the current task gets an unfair amount of CPU time. In
CFS this fairness imbalance is expressed and tracked via the per-task
p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of
time the task should now run on the CPU for it to become completely fair
and balanced.
( small detail: on 'ideal' hardware, the p->wait_runtime value would
always be zero - no task would ever get 'out of balance' from the
'ideal' share of CPU time. )
CFS's task picking logic is based on this p->wait_runtime value and it
is thus very simple: it always tries to run the task with the largest
p->wait_runtime value. In other words, CFS tries to run the task with
the 'gravest need' for more CPU time. So CFS always tries to split up
CPU time between runnable tasks as close to 'ideal multitasking
hardware' as possible.
Most of the rest of CFS's design just falls out of this really simple
concept, with a few add-on embellishments like nice levels,
multiprocessing and various algorithm variants to recognize sleepers.
In practice it works like this: the system runs a task a bit, and when
the task schedules (or a scheduler tick happens) the task's CPU usage is
'accounted for': the (small) time it just spent using the physical CPU
is deducted from p->wait_runtime. [minus the 'fair share' it would have
gotten anyway]. Once p->wait_runtime gets low enough so that another
task becomes the 'leftmost task' of the time-ordered rbtree it maintains
(plus a small amount of 'granularity' distance relative to the leftmost
task so that we do not over-schedule tasks and trash the cache) then the
new leftmost task is picked and the current task is preempted.
The rq->fair_clock value tracks the 'CPU time a runnable task would have
fairly gotten, had it been runnable during that time'. So by using
rq->fair_clock values we can accurately timestamp and measure the
'expected CPU time' a task should have gotten. All runnable tasks are
sorted in the rbtree by the "rq->fair_clock - p->wait_runtime" key, and
CFS picks the 'leftmost' task and sticks to it. As the system progresses
forwards, newly woken tasks are put into the tree more and more to the
right - slowly but surely giving a chance for every task to become the
'leftmost task' and thus get on the CPU within a deterministic amount of
time.
Some implementation details:
- the introduction of Scheduling Classes: an extensible hierarchy of
scheduler modules. These modules encapsulate scheduling policy
details and are handled by the scheduler core without the core
code assuming about them too much.
- sched_fair.c implements the 'CFS desktop scheduler': it is a
replacement for the vanilla scheduler's SCHED_OTHER interactivity
code.
I'd like to give credit to Con Kolivas for the general approach here:
he has proven via RSDL/SD that 'fair scheduling' is possible and that
it results in better desktop scheduling. Kudos Con!
The CFS patch uses a completely different approach and implementation
from RSDL/SD. My goal was to make CFS's interactivity quality exceed
that of RSDL/SD, which is a high standard to meet :-) Testing
feedback is welcome to decide this one way or another. [ and, in any
case, all of SD's logic could be added via a kernel/sched_sd.c module
as well, if Con is interested in such an approach. ]
CFS's design is quite radical: it does not use runqueues, it uses a
time-ordered rbtree to build a 'timeline' of future task execution,
and thus has no 'array switch' artifacts (by which both the vanilla
scheduler and RSDL/SD are affected).
CFS uses nanosecond granularity accounting and does not rely on any
jiffies or other HZ detail. Thus the CFS scheduler has no notion of
'timeslices' and has no heuristics whatsoever. There is only one
central tunable:
/proc/sys/kernel/sched_granularity_ns
which can be used to tune the scheduler from 'desktop' (low
latencies) to 'server' (good batching) workloads. It defaults to a
setting suitable for desktop workloads. SCHED_BATCH is handled by the
CFS scheduler module too.
Due to its design, the CFS scheduler is not prone to any of the
'attacks' that exist today against the heuristics of the stock
scheduler: fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c all
work fine and do not impact interactivity and produce the expected
behavior.
the CFS scheduler has a much stronger handling of nice levels and
SCHED_BATCH: both types of workloads should be isolated much more
agressively than under the vanilla scheduler.
( another detail: due to nanosec accounting and timeline sorting,
sched_yield() support is very simple under CFS, and in fact under
CFS sched_yield() behaves much better than under any other
scheduler i have tested so far. )
- sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler
way than the vanilla scheduler does. It uses 100 runqueues (for all
100 RT priority levels, instead of 140 in the vanilla scheduler)
and it needs no expired array.
- reworked/sanitized SMP load-balancing: the runqueue-walking
assumptions are gone from the load-balancing code now, and
iterators of the scheduling modules are used. The balancing code got
quite a bit simpler as a result.

3
Documentation/scsi/aacraid.txt
View File

@ -50,6 +50,9 @@ Supported Cards/Chipsets
9005:0285:9005:02be Adaptec 31605 (Marauder160)
9005:0285:9005:02c3 Adaptec 51205 (Voodoo120)
9005:0285:9005:02c4 Adaptec 51605 (Voodoo160)
9005:0285:9005:02ce Adaptec 51245 (Voodoo124)
9005:0285:9005:02cf Adaptec 51645 (Voodoo164)
9005:0285:9005:02d0 Adaptec 52445 (Voodoo244)
1011:0046:9005:0364 Adaptec 5400S (Mustang)
9005:0287:9005:0800 Adaptec Themisto (Jupiter)
9005:0200:9005:0200 Adaptec Themisto (Jupiter)

450
Documentation/scsi/scsi_fc_transport.txt Normal file
View File

@ -0,0 +1,450 @@
SCSI FC Tansport
=============================================
Date: 4/12/2007
Kernel Revisions for features:
rports : <<TBS>>
vports : 2.6.22 (? TBD)
Introduction
============
This file documents the features and components of the SCSI FC Transport.
It also provides documents the API between the transport and FC LLDDs.
The FC transport can be found at:
drivers/scsi/scsi_transport_fc.c
include/scsi/scsi_transport_fc.h
include/scsi/scsi_netlink_fc.h
This file is found at Documentation/scsi/scsi_fc_transport.txt
FC Remote Ports (rports)
========================================================================
<< To Be Supplied >>
FC Virtual Ports (vports)
========================================================================
Overview:
-------------------------------
New FC standards have defined mechanisms which allows for a single physical
port to appear on as multiple communication ports. Using the N_Port Id
Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric
can be assigned more than 1 N_Port_ID. Each N_Port_ID appears as a
separate port to other endpoints on the fabric, even though it shares one
physical link to the switch for communication. Each N_Port_ID can have a
unique view of the fabric based on fabric zoning and array lun-masking
(just like a normal non-NPIV adapter). Using the Virtual Fabric (VF)
mechanism, adding a fabric header to each frame allows the port to
interact with the Fabric Port to join multiple fabrics. The port will
obtain an N_Port_ID on each fabric it joins. Each fabric will have its
own unique view of endpoints and configuration parameters. NPIV may be
used together with VF so that the port can obtain multiple N_Port_IDs
on each virtual fabric.
The FC transport is now recognizing a new object - a vport. A vport is
an entity that has a world-wide unique World Wide Port Name (wwpn) and
World Wide Node Name (wwnn). The transport also allows for the FC4's to
be specified for the vport, with FCP_Initiator being the primary role
expected. Once instantiated by one of the above methods, it will have a
distinct N_Port_ID and view of fabric endpoints and storage entities.
The fc_host associated with the physical adapter will export the ability
to create vports. The transport will create the vport object within the
Linux device tree, and instruct the fc_host's driver to instantiate the
virtual port. Typically, the driver will create a new scsi_host instance
on the vport, resulting in a unique <H,C,T,L> namespace for the vport.
Thus, whether a FC port is based on a physical port or on a virtual port,
each will appear as a unique scsi_host with its own target and lun space.
Note: At this time, the transport is written to create only NPIV-based
vports. However, consideration was given to VF-based vports and it
should be a minor change to add support if needed. The remaining
discussion will concentrate on NPIV.
Note: World Wide Name assignment (and uniqueness guarantees) are left
up to an administrative entity controling the vport. For example,
if vports are to be associated with virtual machines, a XEN mgmt
utility would be responsible for creating wwpn/wwnn's for the vport,
using it's own naming authority and OUI. (Note: it already does this
for virtual MAC addresses).
Device Trees and Vport Objects:
-------------------------------
Today, the device tree typically contains the scsi_host object,
with rports and scsi target objects underneath it. Currently the FC
transport creates the vport object and places it under the scsi_host
object corresponding to the physical adapter. The LLDD will allocate
a new scsi_host for the vport and link it's object under the vport.
The remainder of the tree under the vports scsi_host is the same
as the non-NPIV case. The transport is written currently to easily
allow the parent of the vport to be something other than the scsi_host.
This could be used in the future to link the object onto a vm-specific
device tree. If the vport's parent is not the physical port's scsi_host,
a symbolic link to the vport object will be placed in the physical
port's scsi_host.
Here's what to expect in the device tree :
The typical Physical Port's Scsi_Host:
/sys/devices/.../host17/
and it has the typical decendent tree:
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
and then the vport is created on the Physical Port:
/sys/devices/.../host17/vport-17:0-0
and the vport's Scsi_Host is then created:
/sys/devices/.../host17/vport-17:0-0/host18
and then the rest of the tree progresses, such as:
/sys/devices/.../host17/vport-17:0-0/host18/rport-18:0-0/target18:0:0/18:0:0:0:
Here's what to expect in the sysfs tree :
scsi_hosts:
/sys/class/scsi_host/host17 physical port's scsi_host
/sys/class/scsi_host/host18 vport's scsi_host
fc_hosts:
/sys/class/fc_host/host17 physical port's fc_host
/sys/class/fc_host/host18 vport's fc_host
fc_vports:
/sys/class/fc_vports/vport-17:0-0 the vport's fc_vport
fc_rports:
/sys/class/fc_remote_ports/rport-17:0-0 rport on the physical port
/sys/class/fc_remote_ports/rport-18:0-0 rport on the vport
Vport Attributes:
-------------------------------
The new fc_vport class object has the following attributes
node_name: Read_Only
The WWNN of the vport
port_name: Read_Only
The WWPN of the vport
roles: Read_Only
Indicates the FC4 roles enabled on the vport.
symbolic_name: Read_Write
A string, appended to the driver's symbolic port name string, which
is registered with the switch to identify the vport. For example,
a hypervisor could set this string to "Xen Domain 2 VM 5 Vport 2",
and this set of identifiers can be seen on switch management screens
to identify the port.
vport_delete: Write_Only
When written with a "1", will tear down the vport.
vport_disable: Write_Only
When written with a "1", will transition the vport to a disabled.
state. The vport will still be instantiated with the Linux kernel,
but it will not be active on the FC link.
When written with a "0", will enable the vport.
vport_last_state: Read_Only
Indicates the previous state of the vport. See the section below on
"Vport States".
vport_state: Read_Only
Indicates the state of the vport. See the section below on
"Vport States".
vport_type: Read_Only
Reflects the FC mechanism used to create the virtual port.
Only NPIV is supported currently.
For the fc_host class object, the following attributes are added for vports:
max_npiv_vports: Read_Only
Indicates the maximum number of NPIV-based vports that the
driver/adapter can support on the fc_host.
npiv_vports_inuse: Read_Only
Indicates how many NPIV-based vports have been instantiated on the
fc_host.
vport_create: Write_Only
A "simple" create interface to instantiate a vport on an fc_host.
A "<WWPN>:<WWNN>" string is written to the attribute. The transport
then instantiates the vport object and calls the LLDD to create the
vport with the role of FCP_Initiator. Each WWN is specified as 16
hex characters and may *not* contain any prefixes (e.g. 0x, x, etc).
vport_delete: Write_Only
A "simple" delete interface to teardown a vport. A "<WWPN>:<WWNN>"
string is written to the attribute. The transport will locate the
vport on the fc_host with the same WWNs and tear it down. Each WWN
is specified as 16 hex characters and may *not* contain any prefixes
(e.g. 0x, x, etc).
Vport States:
-------------------------------
Vport instantiation consists of two parts:
- Creation with the kernel and LLDD. This means all transport and
driver data structures are built up, and device objects created.
This is equivalent to a driver "attach" on an adapter, which is
independent of the adapter's link state.
- Instantiation of the vport on the FC link via ELS traffic, etc.
This is equivalent to a "link up" and successfull link initialization.
Futher information can be found in the interfaces section below for
Vport Creation.
Once a vport has been instantiated with the kernel/LLDD, a vport state
can be reported via the sysfs attribute. The following states exist:
FC_VPORT_UNKNOWN - Unknown
An temporary state, typically set only while the vport is being
instantiated with the kernel and LLDD.
FC_VPORT_ACTIVE - Active
The vport has been successfully been created on the FC link.
It is fully functional.
FC_VPORT_DISABLED - Disabled
The vport instantiated, but "disabled". The vport is not instantiated
on the FC link. This is equivalent to a physical port with the
link "down".
FC_VPORT_LINKDOWN - Linkdown
The vport is not operational as the physical link is not operational.
FC_VPORT_INITIALIZING - Initializing
The vport is in the process of instantiating on the FC link.
The LLDD will set this state just prior to starting the ELS traffic
to create the vport. This state will persist until the vport is
successfully created (state becomes FC_VPORT_ACTIVE) or it fails
(state is one of the values below). As this state is transitory,
it will not be preserved in the "vport_last_state".
FC_VPORT_NO_FABRIC_SUPP - No Fabric Support
The vport is not operational. One of the following conditions were
encountered:
- The FC topology is not Point-to-Point
- The FC port is not connected to an F_Port
- The F_Port has indicated that NPIV is not supported.
FC_VPORT_NO_FABRIC_RSCS - No Fabric Resources
The vport is not operational. The Fabric failed FDISC with a status
indicating that it does not have sufficient resources to complete
the operation.
FC_VPORT_FABRIC_LOGOUT - Fabric Logout
The vport is not operational. The Fabric has LOGO'd the N_Port_ID
associated with the vport.
FC_VPORT_FABRIC_REJ_WWN - Fabric Rejected WWN
The vport is not operational. The Fabric failed FDISC with a status
indicating that the WWN's are not valid.
FC_VPORT_FAILED - VPort Failed
The vport is not operational. This is a catchall for all other
error conditions.
The following state table indicates the different state transitions:
State Event New State
--------------------------------------------------------------------
n/a Initialization Unknown
Unknown: Link Down Linkdown
Link Up & Loop No Fabric Support
Link Up & no Fabric No Fabric Support
Link Up & FLOGI response No Fabric Support
indicates no NPIV support
Link Up & FDISC being sent Initializing
Disable request Disable
Linkdown: Link Up Unknown
Initializing: FDISC ACC Active
FDISC LS_RJT w/ no resources No Fabric Resources
FDISC LS_RJT w/ invalid Fabric Rejected WWN
pname or invalid nport_id
FDISC LS_RJT failed for Vport Failed
other reasons
Link Down Linkdown
Disable request Disable
Disable: Enable request Unknown
Active: LOGO received from fabric Fabric Logout
Link Down Linkdown
Disable request Disable
Fabric Logout: Link still up Unknown
The following 4 error states all have the same transitions:
No Fabric Support:
No Fabric Resources:
Fabric Rejected WWN:
Vport Failed:
Disable request Disable
Link goes down Linkdown
Transport <-> LLDD Interfaces :
-------------------------------
Vport support by LLDD:
The LLDD indicates support for vports by supplying a vport_create()
function in the transport template. The presense of this function will
cause the creation of the new attributes on the fc_host. As part of
the physical port completing its initialization relative to the
transport, it should set the max_npiv_vports attribute to indicate the
maximum number of vports the driver and/or adapter supports.
Vport Creation:
The LLDD vport_create() syntax is:
int vport_create(struct fc_vport *vport, bool disable)
where:
vport: Is the newly allocated vport object
disable: If "true", the vport is to be created in a disabled stated.
If "false", the vport is to be enabled upon creation.
When a request is made to create a new vport (via sgio/netlink, or the
vport_create fc_host attribute), the transport will validate that the LLDD
can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
If not, the create request will be failed. If space remains, the transport
will increment the vport count, create the vport object, and then call the
LLDD's vport_create() function with the newly allocated vport object.
As mentioned above, vport creation is divided into two parts:
- Creation with the kernel and LLDD. This means all transport and
driver data structures are built up, and device objects created.
This is equivalent to a driver "attach" on an adapter, which is
independent of the adapter's link state.
- Instantiation of the vport on the FC link via ELS traffic, etc.
This is equivalent to a "link up" and successfull link initialization.
The LLDD's vport_create() function will not synchronously wait for both
parts to be fully completed before returning. It must validate that the
infrastructure exists to support NPIV, and complete the first part of
vport creation (data structure build up) before returning. We do not
hinge vport_create() on the link-side operation mainly because:
- The link may be down. It is not a failure if it is. It simply
means the vport is in an inoperable state until the link comes up.
This is consistent with the link bouncing post vport creation.
- The vport may be created in a disabled state.
- This is consistent with a model where: the vport equates to a
FC adapter. The vport_create is synonymous with driver attachment
to the adapter, which is independent of link state.
Note: special error codes have been defined to delineate infrastructure
failure cases for quicker resolution.
The expected behavior for the LLDD's vport_create() function is:
- Validate Infrastructure:
- If the driver or adapter cannot support another vport, whether
due to improper firmware, (a lie about) max_npiv, or a lack of
some other resource - return VPCERR_UNSUPPORTED.
- If the driver validates the WWN's against those already active on
the adapter and detects an overlap - return VPCERR_BAD_WWN.
- If the driver detects the topology is loop, non-fabric, or the
FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
- Allocate data structures. If errors are encountered, such as out
of memory conditions, return the respective negative Exxx error code.
- If the role is FCP Initiator, the LLDD is to :
- Call scsi_host_alloc() to allocate a scsi_host for the vport.
- Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
and bind it as a child of the vport device.
- Initializes the fc_host attribute values.
- Kick of further vport state transitions based on the disable flag and
link state - and return success (zero).
LLDD Implementers Notes:
- It is suggested that there be a different fc_function_templates for
the physical port and the virtual port. The physical port's template
would have the vport_create, vport_delete, and vport_disable functions,
while the vports would not.
- It is suggested that there be different scsi_host_templates
for the physical port and virtual port. Likely, there are driver
attributes, embedded into the scsi_host_template, that are applicable
for the physical port only (link speed, topology setting, etc). This
ensures that the attributes are applicable to the respective scsi_host.
Vport Disable/Enable:
The LLDD vport_disable() syntax is:
int vport_disable(struct fc_vport *vport, bool disable)
where:
vport: Is vport to to be enabled or disabled
disable: If "true", the vport is to be disabled.
If "false", the vport is to be enabled.
When a request is made to change the disabled state on a vport, the
transport will validate the request against the existing vport state.
If the request is to disable and the vport is already disabled, the
request will fail. Similarly, if the request is to enable, and the
vport is not in a disabled state, the request will fail. If the request
is valid for the vport state, the transport will call the LLDD to
change the vport's state.
Within the LLDD, if a vport is disabled, it remains instantiated with
the kernel and LLDD, but it is not active or visible on the FC link in
any way. (see Vport Creation and the 2 part instantiation discussion).
The vport will remain in this state until it is deleted or re-enabled.
When enabling a vport, the LLDD reinstantiates the vport on the FC
link - essentially restarting the LLDD statemachine (see Vport States
above).
Vport Deletion:
The LLDD vport_delete() syntax is:
int vport_delete(struct fc_vport *vport)
where:
vport: Is vport to delete
When a request is made to delete a vport (via sgio/netlink, or via the
fc_host or fc_vport vport_delete attributes), the transport will call
the LLDD to terminate the vport on the FC link, and teardown all other
datastructures and references. If the LLDD completes successfully,
the transport will teardown the vport objects and complete the vport
removal. If the LLDD delete request fails, the vport object will remain,
but will be in an indeterminate state.
Within the LLDD, the normal code paths for a scsi_host teardown should
be followed. E.g. If the vport has a FCP Initiator role, the LLDD
will call fc_remove_host() for the vports scsi_host, followed by
scsi_remove_host() and scsi_host_put() for the vports scsi_host.
Other:
fc_host port_type attribute:
There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
must be set on all vport-based fc_hosts. Normally, on a physical port,
the port_type attribute would be set to NPORT, NLPORT, etc based on the
topology type and existence of the fabric. As this is not applicable to
a vport, it makes more sense to report the FC mechanism used to create
the vport.
Driver unload:
FC drivers are required to call fc_remove_host() prior to calling
scsi_remove_host(). This allows the fc_host to tear down all remote
ports prior the scsi_host being torn down. The fc_remove_host() call
was updated to remove all vports for the fc_host as well.
Credits
=======
The following people have contributed to this document:
James Smart
james.smart@emulex.com

84
Documentation/sound/oss/AD1816
View File

@ -1,84 +0,0 @@
Documentation for the AD1816(A) sound driver
============================================
Installation:
-------------
To get your AD1816(A) based sound card work, you'll have to enable support for
experimental code ("Prompt for development and/or incomplete code/drivers")
and isapnp ("Plug and Play support", "ISA Plug and Play support"). Enable
"Sound card support", "OSS modules support" and "Support for AD1816(A) based
cards (EXPERIMENTAL)" in the sound configuration menu, too. Now build, install
and reboot the new kernel as usual.
Features:
---------
List of features supported by this driver:
- full-duplex support
- supported audio formats: unsigned 8bit, signed 16bit little endian,
signed 16bit big endian, µ-law, A-law
- supported channels: mono and stereo
- supported recording sources: Master, CD, Line, Line1, Line2, Mic
- supports phat 3d stereo circuit (Line 3)
Supported cards:
----------------
The following cards are known to work with this driver:
- Terratec Base 1
- Terratec Base 64
- HP Kayak
- Acer FX-3D
- SY-1816
- Highscreen Sound-Boostar 32 Wave 3D
- Highscreen Sound-Boostar 16
- AVM Apex Pro card
- (Aztech SC-16 3D)
- (Newcom SC-16 3D)
- (Terratec EWS64S)
Cards listed in brackets are not supported reliable. If you have such a card
you should add the extra parameter:
options=1
when loading the ad1816 module via modprobe.
Troubleshooting:
----------------
First of all you should check, if the driver has been loaded
properly.
If loading of the driver succeeds, but playback/capture fails, check
if you used the correct values for irq, dma and dma2 when loading the module.
If one of them is wrong you usually get the following error message:
Nov 6 17:06:13 tek01 kernel: Sound: DMA (output) timed out - IRQ/DRQ config error?
If playback/capture is too fast or to slow, you should have a look at
the clock chip of your sound card. The AD1816 was designed for a 33MHz
oscillator, however most sound card manufacturer use slightly
different oscillators as they are cheaper than 33MHz oscillators. If
you have such a card you have to adjust the ad1816_clockfreq parameter
above. For example: For a card using a 32.875MHz oscillator use
ad1816_clockfreq=32875 instead of ad1816_clockfreq=33000.
Updates, bugfixes and bugreports:
--------------------------------
As the driver is still experimental and under development, you should
watch out for updates. Updates of the driver are available on the
Internet from one of my home pages:
http://www.student.informatik.tu-darmstadt.de/~tek/projects/linux.html
or:
http://www.tu-darmstadt.de/~tek01/projects/linux.html
Bugreports, bugfixes and related questions should be sent via E-Mail to:
tek@rbg.informatik.tu-darmstadt.de
Thorsten Knabe <tek@rbg.informatik.tu-darmstadt.de>
Christoph Hellwig <hch@infradead.org>
Last modified: 2000/09/20

280
Documentation/sound/oss/NM256
View File

@ -1,280 +0,0 @@
=======================================================
Documentation for the NeoMagic 256AV/256ZX sound driver
=======================================================
You're looking at version 1.1 of the driver. (Woohoo!) It has been
successfully tested against the following laptop models:
Sony Z505S/Z505SX/Z505DX/Z505RX
Sony F150, F160, F180, F250, F270, F280, PCG-F26
Dell Latitude CPi, CPt (various submodels)
There are a few caveats, which is why you should read the entirety of
this document first.
This driver was developed without any support or assistance from
NeoMagic. There is no warranty, expressed, implied, or otherwise. It
is free software in the public domain; feel free to use it, sell it,
give it to your best friends, even claim that you wrote it (but why?!)
but don't go whining to me, NeoMagic, Sony, Dell, or anyone else
when it blows up your computer.
Version 1.1 contains a change to try and detect non-AC97 versions of
the hardware, and not install itself appropriately. It should also
reinitialize the hardware on an APM resume event, assuming that APM
was configured into your kernel.
============
Installation
============
Enable the sound drivers, the OSS sound drivers, and then the NM256
driver. The NM256 driver *must* be configured as a module (it won't
give you any other choice).
Next, do the usual "make modules" and "make modules_install".
Finally, insmod the soundcore, sound and nm256 modules.
When the nm256 driver module is loaded, you should see a couple of
confirmation messages in the kernel logfile indicating that it found
the device (the device does *not* use any I/O ports or DMA channels).
Now try playing a wav file, futz with the CD-ROM if you have one, etc.
The NM256 is entirely a PCI-based device, and all the necessary
information is automatically obtained from the card. It can only be
configured as a module in a vain attempt to prevent people from
hurting themselves. It works correctly if it shares an IRQ with
another device (it normally shares IRQ 9 with the builtin eepro100
ethernet on the Sony Z505 laptops).
It does not run the card in any sort of compatibility mode. It will
not work on laptops that have the SB16-compatible, AD1848-compatible
or CS4232-compatible codec/mixer; you will want to use the appropriate
compatible OSS driver with these chipsets. I cannot provide any
assistance with machines using the SB16, AD1848 or CS4232 compatible
versions. (The driver now attempts to detect the mixer version, and
will refuse to load if it believes the hardware is not
AC97-compatible.)
The sound support is very basic, but it does include simultaneous
playback and record capability. The mixer support is also quite
simple, although this is in keeping with the rather limited
functionality of the chipset.
There is no hardware synthesizer available, as the Losedows OPL-3 and
MIDI support is done via hardware emulation.
Only three recording devices are available on the Sony: the
microphone, the CD-ROM input, and the volume device (which corresponds
to the stereo output). (Other devices may be available on other
models of laptops.) The Z505 series does not have a builtin CD-ROM,
so of course the CD-ROM input doesn't work. It does work on laptops
with a builtin CD-ROM drive.
The mixer device does not appear to have any tone controls, at least
on the Z505 series. The mixer module checks for tone controls in the
AC97 mixer, and will enable them if they are available.
==============
Known problems
==============
* There are known problems with PCMCIA cards and the eepro100 ethernet
driver on the Z505S/Z505SX/Z505DX. Keep reading.
* There are also potential problems with using a virtual X display, and
also problems loading the module after the X server has been started.
Keep reading.
* The volume control isn't anywhere near linear. Sorry. This will be
fixed eventually, when I get sufficiently annoyed with it. (I doubt
it will ever be fixed now, since I've never gotten sufficiently
annoyed with it and nobody else seems to care.)
* There are reports that the CD-ROM volume is very low. Since I do not
have a CD-ROM equipped laptop, I cannot test this (it's kinda hard to
do remotely).
* Only 8 fixed-rate speeds are supported. This is mainly a chipset
limitation. It may be possible to support other speeds in the future.
* There is no support for the telephone mixer/codec. There is support
for a phonein/phoneout device in the mixer driver; whether or not
it does anything is anyone's guess. (Reports on this would be
appreciated. You'll have to figure out how to get the phone to
go off-hook before it'll work, tho.)
* This driver was not written with any cooperation or support from
NeoMagic. If you have any questions about this, see their website
for their official stance on supporting open source drivers.
============
Video memory
============
The NeoMagic sound engine uses a portion of the display memory to hold
the sound buffer. (Crazy, eh?) The NeoMagic video BIOS sets up a
special pointer at the top of video RAM to indicate where the top of
the audio buffer should be placed.
At the present time XFree86 is apparently not aware of this. It will
thus write over either the pointer or the sound buffer with abandon.
(Accelerated-X seems to do a better job here.)
This implies a few things:
* Sometimes the NM256 driver has to guess at where the buffer
should be placed, especially if the module is loaded after the
X server is started. It's usually correct, but it will consistently
fail on the Sony F250.
* Virtual screens greater than 1024x768x16 under XFree86 are
problematic on laptops with only 2.5MB of screen RAM. This
includes all of the 256AV-equipped laptops. (Virtual displays
may or may not work on the 256ZX, which has at least 4MB of
video RAM.)
If you start having problems with random noise being output either
constantly (this is the usual symptom on the F250), or when windows
are moved around (this is the usual symptom when using a virtual
screen), the best fix is to
* Don't use a virtual frame buffer.
* Make sure you load the NM256 module before the X server is
started.
On the F250, it is possible to force the driver to load properly even
after the XFree86 server is started by doing:
insmod nm256 buffertop=0x25a800
This forces the audio buffers to the correct offset in screen RAM.
One user has reported a similar problem on the Sony F270, although
others apparently aren't seeing any problems. His suggested command
is
insmod nm256 buffertop=0x272800
=================
Official WWW site
=================
The official site for the NM256 driver is:
http://www.uglx.org/sony.html
You should always be able to get the latest version of the driver there,
and the driver will be supported for the foreseeable future.
==============
Z505RX and IDE
==============
There appears to be a problem with the IDE chipset on the Z505RX; one
of the symptoms is that sound playback periodically hangs (when the
disk is accessed). The user reporting the problem also reported that
enabling all of the IDE chipset workarounds in the kernel solved the
problem, tho obviously only one of them should be needed--if someone
can give me more details I would appreciate it.
==============================
Z505S/Z505SX on-board Ethernet
==============================
If you're using the on-board Ethernet Pro/100 ethernet support on the Z505
series, I strongly encourage you to download the latest eepro100 driver from
Donald Becker's site:
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
There was a reported problem on the Z505SX that if the ethernet
interface is disabled and reenabled while the sound driver is loaded,
the machine would lock up. I have included a workaround that is
working satisfactorily. However, you may occasionally see a message
about "Releasing interrupts, over 1000 bad interrupts" which indicates
that the workaround is doing its job.
==================================
PCMCIA and the Z505S/Z505SX/Z505DX
==================================
There is also a known problem with the Sony Z505S and Z505SX hanging
if a PCMCIA card is inserted while the ethernet driver is loaded, or
in some cases if the laptop is suspended. This is caused by tons of
spurious IRQ 9s, probably generated from the PCMCIA or ACPI bridges.
There is currently no fix for the problem that works in every case.
The only known workarounds are to disable the ethernet interface
before inserting or removing a PCMCIA card, or with some cards
disabling the PCMCIA card before ejecting it will also help the
problem with the laptop hanging when the card is ejected.
One user has reported that setting the tcic's cs_irq to some value
other than 9 (like 11) fixed the problem. This doesn't work on my
Z505S, however--changing the value causes the cardmgr to stop seeing
card insertions and removals, cards don't seem to work correctly, and
I still get hangs if a card is inserted when the kernel is booted.
Using the latest ethernet driver and pcmcia package allows me to
insert an Adaptec 1480A SlimScsi card without the laptop hanging,
although I still have to shut down the card before ejecting or
powering down the laptop. However, similar experiments with a DE-660
ethernet card still result in hangs when the card is inserted. I am
beginning to think that the interrupts are CardBus-related, since the
Adaptec card is a CardBus card, and the DE-660 is not; however, I
don't have any other CardBus cards to test with.
======
Thanks
======
First, I want to thank everyone (except NeoMagic of course) for their
generous support and encouragement. I'd like to list everyone's name
here that replied during the development phase, but the list is
amazingly long.
I will be rather unfair and single out a few people, however:
Justin Maurer, for being the first random net.person to try it,
and for letting me login to his Z505SX to get it working there
Edi Weitz for trying out several different versions, and giving
me a lot of useful feedback
Greg Rumple for letting me login remotely to get the driver
functional on the 256ZX, for his assistance on tracking
down all sorts of random stuff, and for trying out Accel-X
Zach Brown, for the initial AC97 mixer interface design
Jeff Garzik, for various helpful suggestions on the AC97
interface
"Mr. Bumpy" for feedback on the Z505RX
Bill Nottingham, for generous assistance in getting the mixer ID
code working
=================
Previous versions
=================
Versions prior to 0.3 (aka `noname') had problems with weird artifacts
in the output and failed to set the recording rate properly. These
problems have long since been fixed.
Versions prior to 0.5 had problems with clicks in the output when
anything other than 16-bit stereo sound was being played, and also had
periodic clicks when recording.
Version 0.7 first incorporated support for the NM256ZX chipset, which
is found on some Dell Latitude laptops (the CPt, and apparently
some CPi models as well). It also included the generic AC97
mixer module.
Version 0.75 renamed all the functions and files with slightly more
generic names.
Note that previous versions of this document claimed that recording was
8-bit only; it actually has been working for 16-bits all along.

210
Documentation/sound/oss/OPL3-SA2
View File

@ -1,210 +0,0 @@
Documentation for the OPL3-SA2, SA3, and SAx driver (opl3sa2.o)
---------------------------------------------------------------
Scott Murray, scott@spiteful.org
January 7, 2001
NOTE: All trade-marked terms mentioned below are properties of their
respective owners.
Supported Devices
-----------------
This driver is for PnP soundcards based on the following Yamaha audio
controller chipsets:
YMF711 aka OPL3-SA2
YMF715 and YMF719 aka OPL3-SA3
Up until recently (December 2000), I'd thought the 719 to be a
different chipset, the OPL3-SAx. After an email exhange with
Yamaha, however, it turns out that the 719 is just a re-badged
715, and the chipsets are identical. The chipset detection code
has been updated to reflect this.
Anyways, all of these chipsets implement the following devices:
OPL3 FM synthesizer
Soundblaster Pro
Microsoft/Windows Sound System
MPU401 MIDI interface
Note that this driver uses the MSS device, and to my knowledge these
chipsets enforce an either/or situation with the Soundblaster Pro
device and the MSS device. Since the MSS device has better
capabilities, I have implemented the driver to use it.
Mixer Channels
--------------
Older versions of this driver (pre-December 2000) had two mixers,
an OPL3-SA2 or SA3 mixer and a MSS mixer. The OPL3-SA[23] mixer
device contained a superset of mixer channels consisting of its own
channels and all of the MSS mixer channels. To simplify the driver
considerably, and to partition functionality better, the OPL3-SA[23]
mixer device now contains has its own specific mixer channels. They
are:
Volume - Hardware master volume control
Bass - SA3 only, now supports left and right channels
Treble - SA3 only, now supports left and right channels
Microphone - Hardware microphone input volume control
Digital1 - Yamaha 3D enhancement "Wide" mixer
All other mixer channels (e.g. "PCM", "CD", etc.) now have to be
controlled via the "MS Sound System (CS4231)" mixer. To facilitate
this, the mixer device creation order has been switched so that
the MSS mixer is created first. This allows accessing the majority
of the useful mixer channels even via single mixer-aware tools
such as "aumix".
Plug 'n Play
------------
In previous kernels (2.2.x), some configuration was required to
get the driver to talk to the card. Being the new millennium and
all, the 2.4.x kernels now support auto-configuration if ISA PnP
support is configured in. Theoretically, the driver even supports
having more than one card in this case.
With the addition of PnP support to the driver, two new parameters
have been added to control it:
isapnp - set to 0 to disable ISA PnP card detection
multiple - set to 0 to disable multiple PnP card detection
Optional Parameters
-------------------
Recent (December 2000) additions to the driver (based on a patch
provided by Peter Englmaier) are two new parameters:
ymode - Set Yamaha 3D enhancement mode:
0 = Desktop/Normal 5-12 cm speakers
1 = Notebook PC (1) 3 cm speakers
2 = Notebook PC (2) 1.5 cm speakers
3 = Hi-Fi 16-38 cm speakers
loopback - Set A/D input source. Useful for echo cancellation:
0 = Mic Right channel (default)
1 = Mono output loopback
The ymode parameter has been tested and does work. The loopback
parameter, however, is untested. Any feedback on its usefulness
would be appreciated.
Manual Configuration
--------------------
If for some reason you decide not to compile ISA PnP support into
your kernel, or disabled the driver's usage of it by setting the
isapnp parameter as discussed above, then you will need to do some
manual configuration. There are two ways of doing this. The most
common is to use the isapnptools package to initialize the card, and
use the kernel module form of the sound subsystem and sound drivers.
Alternatively, some BIOS's allow manual configuration of installed
PnP devices in a BIOS menu, which should allow using the non-modular
sound drivers, i.e. built into the kernel.
I personally use isapnp and modules, and do not have access to a PnP
BIOS machine to test. If you have such a beast, configuring the
driver to be built into the kernel should just work (thanks to work
done by David Luyer <luyer@ucs.uwa.edu.au>). You will still need
to specify settings, which can be done by adding:
opl3sa2=<io>,<irq>,<dma>,<dma2>,<mssio>,<mpuio>
to the kernel command line. For example:
opl3sa2=0x370,5,0,1,0x530,0x330
If you are instead using the isapnp tools (as most people have been
before Linux 2.4.x), follow the directions in their documentation to
produce a configuration file. Here is the relevant excerpt I used to
use for my SA3 card from my isapnp.conf:
(CONFIGURE YMH0800/-1 (LD 0
# NOTE: IO 0 is for the unused SoundBlaster part of the chipset.
(IO 0 (BASE 0x0220))
(IO 1 (BASE 0x0530))
(IO 2 (BASE 0x0388))
(IO 3 (BASE 0x0330))
(IO 4 (BASE 0x0370))
(INT 0 (IRQ 5 (MODE +E)))
(DMA 0 (CHANNEL 0))
(DMA 1 (CHANNEL 1))
Here, note that:
Port Acceptable Range Purpose
---- ---------------- -------
IO 0 0x0220 - 0x0280 SB base address, unused.
IO 1 0x0530 - 0x0F48 MSS base address
IO 2 0x0388 - 0x03F8 OPL3 base address
IO 3 0x0300 - 0x0334 MPU base address
IO 4 0x0100 - 0x0FFE card's own base address for its control I/O ports
The IRQ and DMA values can be any that are considered acceptable for a
MSS. Assuming you've got isapnp all happy, then you should be able to
do something like the following (which matches up with the isapnp
configuration above):
modprobe mpu401
modprobe ad1848
modprobe opl3sa2 io=0x370 mss_io=0x530 mpu_io=0x330 irq=5 dma=0 dma2=1
modprobe opl3 io=0x388
See the section "Automatic Module Loading" below for how to set up
/etc/modprobe.conf to automate this.
An important thing to remember that the opl3sa2 module's io argument is
for it's own control port, which handles the card's master mixer for
volume (on all cards), and bass and treble (on SA3 cards).
Troubleshooting
---------------
If all goes well and you see no error messages, you should be able to
start using the sound capabilities of your system. If you get an
error message while trying to insert the opl3sa2 module, then make
sure that the values of the various arguments match what you specified
in your isapnp configuration file, and that there is no conflict with
another device for an I/O port or interrupt. Checking the contents of
/proc/ioports and /proc/interrupts can be useful to see if you're
butting heads with another device.
If you still cannot get the module to load, look at the contents of
your system log file, usually /var/log/messages. If you see the
message "opl3sa2: Unknown Yamaha audio controller version", then you
have a different chipset version than I've encountered so far. Look
for all messages in the log file that start with "opl3sa2: " and see
if they provide any clues. If you do not see the chipset version
message, and none of the other messages present in the system log are
helpful, email me some details and I'll try my best to help.
Automatic Module Loading
------------------------
Lastly, if you're using modules and want to set up automatic module
loading with kmod, the kernel module loader, here is the section I
currently use in my modprobe.conf file:
# Sound
alias sound-slot-0 opl3sa2
options opl3sa2 io=0x370 mss_io=0x530 mpu_io=0x330 irq=7 dma=0 dma2=3
options opl3 io=0x388
That's all it currently takes to get an OPL3-SA3 card working on my
system. Once again, if you have any other problems, email me at the
address listed above.
Scott

43
Documentation/sound/oss/VIA-chipset
View File

@ -1,43 +0,0 @@
Running sound cards on VIA chipsets
o There are problems with VIA chipsets and sound cards that appear to
lock the hardware solidly. Test programs under DOS have verified the
problem exists on at least some (but apparently not all) VIA boards
o VIA have so far failed to bother to answer support mail on the subject
so if you are a VIA engineer feeling aggrieved as you read this
document go chase your own people. If there is a workaround please
let us know so we can implement it.
Certain patterns of ISA DMA access used for most PC sound cards cause the
VIA chipsets to lock up. From the collected reports this appears to cover a
wide range of boards. Some also lock up with sound cards under Win* as well.
Linux implements a workaround providing your chipset is PCI and you compiled
with PCI Quirks enabled. If so you will see a message
"Activating ISA DMA bug workarounds"
during booting. If you have a VIA PCI chipset that hangs when you use the
sound and is not generating this message even with PCI quirks enabled
please report the information to the linux-kernel list (see REPORTING-BUGS).
If you are one of the tiny number of unfortunates with a 486 ISA/VLB VIA
chipset board you need to do the following to build a special kernel for
your board
edit linux/include/asm-i386/dma.h
change
#define isa_dma_bridge_buggy (0)
to
#define isa_dma_bridge_buggy (1)
and rebuild a kernel without PCI quirk support.
Other than this particular glitch the VIA [M]VP* chipsets appear to work
perfectly with Linux.

138
Documentation/sound/oss/cs46xx
View File

@ -1,138 +0,0 @@
Documentation for the Cirrus Logic/Crystal SoundFusion cs46xx/cs4280 audio
controller chips (2001/05/11)
The cs46xx audio driver supports the DSP line of Cirrus controllers.
Specifically, the cs4610, cs4612, cs4614, cs4622, cs4624, cs4630 and the cs4280
products. This driver uses the generic ac97_codec driver for AC97 codec
support.
Features:
Full Duplex Playback/Capture supported from 8k-48k.
16Bit Signed LE & 8Bit Unsigned, with Mono or Stereo supported.
APM/PM - 2.2.x PM is enabled and functional. APM can also
be enabled for 2.4.x by modifying the CS46XX_ACPI_SUPPORT macro
definition.
DMA playback buffer size is configurable from 16k (defaultorder=2) up to 2Meg
(defaultorder=11). DMA capture buffer size is fixed at a single 4k page as
two 2k fragments.
MMAP seems to work well with QuakeIII, and test XMMS plugin.
Myth2 works, but the polling logic is not fully correct, but is functional.
The 2.4.4-ac6 gameport code in the cs461x joystick driver has been tested
with a Microsoft Sidewinder joystick (cs461x.o and sidewinder.o). This
audio driver must be loaded prior to the joystick driver to enable the
DSP task image supporting the joystick device.
Limitations:
SPDIF is currently not supported.
Primary codec support only. No secondary codec support is implemented.
NOTES:
Hercules Game Theatre XP - the EGPIO2 pin controls the external Amp,
and has been tested.
Module parameter hercules_egpio_disable set to 1, will force a 0 to EGPIODR
to disable the external amplifier.
VTB Santa Cruz - the GPIO7/GPIO8 on the Secondary Codec control
the external amplifier for the "back" speakers, since we do not
support the secondary codec then this external amp is not
turned on. The primary codec external amplifier is supported but
note that the AC97 EAPD bit is inverted logic (amp_voyetra()).
DMA buffer size - there are issues with many of the Linux applications
concerning the optimal buffer size. Several applications request a
certain fragment size and number and then do not verify that the driver
has the ability to support the requested configuration.
SNDCTL_DSP_SETFRAGMENT ioctl is used to request a fragment size and
number of fragments. Some applications exit if an error is returned
on this particular ioctl. Therefore, in alignment with the other OSS audio
drivers, no error is returned when a SETFRAGs IOCTL is received, but the
values passed from the app are not used in any buffer calculation
(ossfragshift/ossmaxfrags are not used).
Use the "defaultorder=N" module parameter to change the buffer size if
you have an application that requires a specific number of fragments
or a specific buffer size (see below).
Debug Interface
---------------
There is an ioctl debug interface to allow runtime modification of the
debug print levels. This debug interface code can be disabled from the
compilation process with commenting the following define:
#define CSDEBUG_INTERFACE 1
There is also a debug print methodolgy to select printf statements from
different areas of the driver. A debug print level is also used to allow
additional printfs to be active. Comment out the following line in the
driver to disable compilation of the CS_DBGOUT print statements:
#define CSDEBUG 1
Please see the definitions for cs_debuglevel and cs_debugmask for additional
information on the debug levels and sections.
There is also a csdbg executable to allow runtime manipulation of these
parameters. for a copy email: twoller@crystal.cirrus.com
MODULE_PARMS definitions
------------------------
module_param(defaultorder, ulong, 0);
defaultorder=N
where N is a value from 1 to 12
The buffer order determines the size of the dma buffer for the driver.
under Linux, a smaller buffer allows more responsiveness from many of the
applications (e.g. games). A larger buffer allows some of the apps (esound)
to not underrun the dma buffer as easily. As default, use 32k (order=3)
rather than 64k as some of the games work more responsively.
(2^N) * PAGE_SIZE = allocated buffer size
module_param(cs_debuglevel, ulong, 0644);
module_param(cs_debugmask, ulong, 0644);
cs_debuglevel=N
cs_debugmask=0xMMMMMMMM
where N is a value from 0 (no debug printfs), to 9 (maximum)
0xMMMMMMMM is a debug mask corresponding to the CS_xxx bits (see driver source).
module_param(hercules_egpio_disable, ulong, 0);
hercules_egpio_disable=N
where N is a 0 (enable egpio), or a 1 (disable egpio support)
module_param(initdelay, ulong, 0);
initdelay=N
This value is used to determine the millescond delay during the initialization
code prior to powering up the PLL. On laptops this value can be used to
assist with errors on resume, mostly with IBM laptops. Basically, if the
system is booted under battery power then the mdelay()/udelay() functions fail to
properly delay the required time. Also, if the system is booted under AC power
and then the power removed, the mdelay()/udelay() functions will not delay properly.
module_param(powerdown, ulong, 0);
powerdown=N
where N is 0 (disable any powerdown of the internal blocks) or 1 (enable powerdown)
module_param(external_amp, bool, 0);
external_amp=1
if N is set to 1, then force enabling the EAPD support in the primary AC97 codec.
override the detection logic and force the external amp bit in the AC97 0x26 register
to be reset (0). EAPD should be 0 for powerup, and 1 for powerdown. The VTB Santa Cruz
card has inverted logic, so there is a special function for these cards.
module_param(thinkpad, bool, 0);
thinkpad=1
if N is set to 1, then force enabling the clkrun functionality.
Currently, when the part is being used, then clkrun is disabled for the entire system,
but re-enabled when the driver is released or there is no outstanding open count.

69
Documentation/spi/spi-lm70llp Normal file
View File

@ -0,0 +1,69 @@
spi_lm70llp : LM70-LLP parport-to-SPI adapter
==============================================
Supported board/chip:
* National Semiconductor LM70 LLP evaluation board
Datasheet: http://www.national.com/pf/LM/LM70.html
Author:
Kaiwan N Billimoria <kaiwan@designergraphix.com>
Description
-----------
This driver provides glue code connecting a National Semiconductor LM70 LLP
temperature sensor evaluation board to the kernel's SPI core subsystem.
In effect, this driver turns the parallel port interface on the eval board
into a SPI bus with a single device, which will be driven by the generic
LM70 driver (drivers/hwmon/lm70.c).
The hardware interfacing on the LM70 LLP eval board is as follows:
Parallel LM70 LLP
Port Direction JP2 Header
----------- --------- ----------------
D0 2 - -
D1 3 --> V+ 5
D2 4 --> V+ 5
D3 5 --> V+ 5
D4 6 --> V+ 5
D5 7 --> nCS 8
D6 8 --> SCLK 3
D7 9 --> SI/O 5
GND 25 - GND 7
Select 13 <-- SI/O 1
----------- --------- ----------------
Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin
is connected to both pin D7 (as Master Out) and Select (as Master In)
using an arrangment that lets either the parport or the LM70 pull the
pin low. This can't be shared with true SPI devices, but other 3-wire
devices might share the same SI/SO pin.
The bitbanger routine in this driver (lm70_txrx) is called back from
the bound "hwmon/lm70" protocol driver through its sysfs hook, using a
spi_write_then_read() call. It performs Mode 0 (SPI/Microwire) bitbanging.
The lm70 driver then inteprets the resulting digital temperature value
and exports it through sysfs.
A "gotcha": National Semiconductor's LM70 LLP eval board circuit schematic
shows that the SI/O line from the LM70 chip is connected to the base of a
transistor Q1 (and also a pullup, and a zener diode to D7); while the
collector is tied to VCC.
Interpreting this circuit, when the LM70 SI/O line is High (or tristate
and not grounded by the host via D7), the transistor conducts and switches
the collector to zero, which is reflected on pin 13 of the DB25 parport
connector. When SI/O is Low (driven by the LM70 or the host) on the other
hand, the transistor is cut off and the voltage tied to it's collector is
reflected on pin 13 as a High level.
So: the getmiso inline routine in this driver takes this fact into account,
inverting the value read at pin 13.
Thanks to
---------
o David Brownell for mentoring the SPI-side driver development.
o Dr.Craig Hollabaugh for the (early) "manual" bitbanging driver version.
o Nadir Billimoria for help interpreting the circuit schematic.

20
Documentation/spinlocks.txt
View File

@ -1,7 +1,12 @@
UPDATE March 21 2005 Amit Gud <gud@eth.net>
SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED defeat lockdep state tracking and
are hence deprecated.
Macros SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated and will be
removed soon. So for any new code dynamic initialization should be used:
Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
initialization.
Dynamic initialization, when necessary, may be performed as
demonstrated below.
spinlock_t xxx_lock;
rwlock_t xxx_rw_lock;
@ -15,12 +20,9 @@ removed soon. So for any new code dynamic initialization should be used:
module_init(xxx_init);
Reasons for deprecation
- it hurts automatic lock validators
- it becomes intrusive for the realtime preemption patches
Following discussion is still valid, however, with the dynamic initialization
of spinlocks instead of static.
The following discussion is still valid, however, with the dynamic
initialization of spinlocks or with DEFINE_SPINLOCK, etc., used
instead of SPIN_LOCK_UNLOCKED.
-----------------------

22
Documentation/sysctl/ctl_unnumbered.txt Normal file
View File

@ -0,0 +1,22 @@
Except for a few extremely rare exceptions user space applications do not use
the binary sysctl interface. Instead everyone uses /proc/sys/... with
readable ascii names.
Recently the kernel has started supporting setting the binary sysctl value to
CTL_UNNUMBERED so we no longer need to assign a binary sysctl path to allow
sysctls to show up in /proc/sys.
Assigning binary sysctl numbers is an endless source of conflicts in sysctl.h,
breaking of the user space ABI (because of those conflicts), and maintenance
problems. A complete pass through all of the sysctl users revealed multiple
instances where the sysctl binary interface was broken and had gone undetected
for years.
So please do not add new binary sysctl numbers. They are unneeded and
problematic.
If you really need a new binary sysctl number please first merge your sysctl
into the kernel and then as a separate patch allocate a binary sysctl number.
(ebiederm@xmission.com, June 2007)

63
Documentation/sysctl/vm.txt
View File

@ -31,12 +31,15 @@ Currently, these files are in /proc/sys/vm:
- min_unmapped_ratio
- min_slab_ratio
- panic_on_oom
- mmap_min_address
- numa_zonelist_order
==============================================================
dirty_ratio, dirty_background_ratio, dirty_expire_centisecs,
dirty_writeback_centisecs, vfs_cache_pressure, laptop_mode,
block_dump, swap_token_timeout, drop-caches:
block_dump, swap_token_timeout, drop-caches,
hugepages_treat_as_movable:
See Documentation/filesystems/proc.txt
@ -216,3 +219,61 @@ above-mentioned.
The default value is 0.
1 and 2 are for failover of clustering. Please select either
according to your policy of failover.
==============================================================
mmap_min_addr
This file indicates the amount of address space which a user process will
be restricted from mmaping. Since kernel null dereference bugs could
accidentally operate based on the information in the first couple of pages
of memory userspace processes should not be allowed to write to them. By
default this value is set to 0 and no protections will be enforced by the
security module. Setting this value to something like 64k will allow the
vast majority of applications to work correctly and provide defense in depth
against future potential kernel bugs.
==============================================================
numa_zonelist_order
This sysctl is only for NUMA.
'where the memory is allocated from' is controlled by zonelists.
(This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation.
you may be able to read ZONE_DMA as ZONE_DMA32...)
In non-NUMA case, a zonelist for GFP_KERNEL is ordered as following.
ZONE_NORMAL -> ZONE_DMA
This means that a memory allocation request for GFP_KERNEL will
get memory from ZONE_DMA only when ZONE_NORMAL is not available.
In NUMA case, you can think of following 2 types of order.
Assume 2 node NUMA and below is zonelist of Node(0)'s GFP_KERNEL
(A) Node(0) ZONE_NORMAL -> Node(0) ZONE_DMA -> Node(1) ZONE_NORMAL
(B) Node(0) ZONE_NORMAL -> Node(1) ZONE_NORMAL -> Node(0) ZONE_DMA.
Type(A) offers the best locality for processes on Node(0), but ZONE_DMA
will be used before ZONE_NORMAL exhaustion. This increases possibility of
out-of-memory(OOM) of ZONE_DMA because ZONE_DMA is tend to be small.
Type(B) cannot offer the best locality but is more robust against OOM of
the DMA zone.
Type(A) is called as "Node" order. Type (B) is "Zone" order.
"Node order" orders the zonelists by node, then by zone within each node.
Specify "[Nn]ode" for zone order
"Zone Order" orders the zonelists by zone type, then by node within each
zone. Specify "[Zz]one"for zode order.
Specify "[Dd]efault" to request automatic configuration. Autoconfiguration
will select "node" order in following case.
(1) if the DMA zone does not exist or
(2) if the DMA zone comprises greater than 50% of the available memory or
(3) if any node's DMA zone comprises greater than 60% of its local memory and
the amount of local memory is big enough.
Otherwise, "zone" order will be selected. Default order is recommended unless
this is causing problems for your system/application.

166
Documentation/sysfs-rules.txt Normal file
View File

@ -0,0 +1,166 @@
Rules on how to access information in the Linux kernel sysfs
The kernel exported sysfs exports internal kernel implementation-details
and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable
internal API. As sysfs is a direct export of kernel internal
structures, the sysfs interface can not provide a stable interface eighter,
it may always change along with internal kernel changes.
To minimize the risk of breaking users of sysfs, which are in most cases
low-level userspace applications, with a new kernel release, the users
of sysfs must follow some rules to use an as abstract-as-possible way to
access this filesystem. The current udev and HAL programs already
implement this and users are encouraged to plug, if possible, into the
abstractions these programs provide instead of accessing sysfs
directly.
But if you really do want or need to access sysfs directly, please follow
the following rules and then your programs should work with future
versions of the sysfs interface.
- Do not use libsysfs
It makes assumptions about sysfs which are not true. Its API does not
offer any abstraction, it exposes all the kernel driver-core
implementation details in its own API. Therefore it is not better than
reading directories and opening the files yourself.
Also, it is not actively maintained, in the sense of reflecting the
current kernel-development. The goal of providing a stable interface
to sysfs has failed, it causes more problems, than it solves. It
violates many of the rules in this document.
- sysfs is always at /sys
Parsing /proc/mounts is a waste of time. Other mount points are a
system configuration bug you should not try to solve. For test cases,
possibly support a SYSFS_PATH environment variable to overwrite the
applications behavior, but never try to search for sysfs. Never try
to mount it, if you are not an early boot script.
- devices are only "devices"
There is no such thing like class-, bus-, physical devices,
interfaces, and such that you can rely on in userspace. Everything is
just simply a "device". Class-, bus-, physical, ... types are just
kernel implementation details, which should not be expected by
applications that look for devices in sysfs.
The properties of a device are:
o devpath (/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0)
- identical to the DEVPATH value in the event sent from the kernel
at device creation and removal
- the unique key to the device at that point in time
- the kernels path to the device-directory without the leading
/sys, and always starting with with a slash
- all elements of a devpath must be real directories. Symlinks
pointing to /sys/devices must always be resolved to their real
target, and the target path must be used to access the device.
That way the devpath to the device matches the devpath of the
kernel used at event time.
- using or exposing symlink values as elements in a devpath string
is a bug in the application
o kernel name (sda, tty, 0000:00:1f.2, ...)
- a directory name, identical to the last element of the devpath
- applications need to handle spaces and characters like '!' in
the name
o subsystem (block, tty, pci, ...)
- simple string, never a path or a link
- retrieved by reading the "subsystem"-link and using only the
last element of the target path
o driver (tg3, ata_piix, uhci_hcd)
- a simple string, which may contain spaces, never a path or a
link
- it is retrieved by reading the "driver"-link and using only the
last element of the target path
- devices which do not have "driver"-link, just do not have a
driver; copying the driver value in a child device context, is a
bug in the application
o attributes
- the files in the device directory or files below a subdirectories
of the same device directory
- accessing attributes reached by a symlink pointing to another device,
like the "device"-link, is a bug in the application
Everything else is just a kernel driver-core implementation detail,
that should not be assumed to be stable across kernel releases.
- Properties of parent devices never belong into a child device.
Always look at the parent devices themselves for determining device
context properties. If the device 'eth0' or 'sda' does not have a
"driver"-link, then this device does not have a driver. Its value is empty.
Never copy any property of the parent-device into a child-device. Parent
device-properties may change dynamically without any notice to the
child device.
- Hierarchy in a single device-tree
There is only one valid place in sysfs where hierarchy can be examined
and this is below: /sys/devices.
It is planned, that all device directories will end up in the tree
below this directory.
- Classification by subsystem
There are currently three places for classification of devices:
/sys/block, /sys/class and /sys/bus. It is planned that these will
not contain any device-directories themselves, but only flat lists of
symlinks pointing to the unified /sys/devices tree.
All three places have completely different rules on how to access
device information. It is planned to merge all three
classification-directories into one place at /sys/subsystem,
following the layout of the bus-directories. All buses and
classes, including the converted block-subsystem, will show up
there.
The devices belonging to a subsystem will create a symlink in the
"devices" directory at /sys/subsystem/<name>/devices.
If /sys/subsystem exists, /sys/bus, /sys/class and /sys/block can be
ignored. If it does not exist, you have always to scan all three
places, as the kernel is free to move a subsystem from one place to
the other, as long as the devices are still reachable by the same
subsystem name.
Assuming /sys/class/<subsystem> and /sys/bus/<subsystem>, or
/sys/block and /sys/class/block are not interchangeable, is a bug in
the application.
- Block
The converted block-subsystem at /sys/class/block, or
/sys/subsystem/block will contain the links for disks and partitions
at the same level, never in a hierarchy. Assuming the block-subsytem to
contain only disks and not partition-devices in the same flat list is
a bug in the application.
- "device"-link and <subsystem>:<kernel name>-links
Never depend on the "device"-link. The "device"-link is a workaround
for the old layout, where class-devices are not created in
/sys/devices/ like the bus-devices. If the link-resolving of a
device-directory does not end in /sys/devices/, you can use the
"device"-link to find the parent devices in /sys/devices/. That is the
single valid use of the "device"-link, it must never appear in any
path as an element. Assuming the existence of the "device"-link for
a device in /sys/devices/ is a bug in the application.
Accessing /sys/class/net/eth0/device is a bug in the application.
Never depend on the class-specific links back to the /sys/class
directory. These links are also a workaround for the design mistake
that class-devices are not created in /sys/devices. If a device
directory does not contain directories for child devices, these links
may be used to find the child devices in /sys/class. That is the single
valid use of these links, they must never appear in any path as an
element. Assuming the existence of these links for devices which are
real child device directories in the /sys/devices tree, is a bug in
the application.
It is planned to remove all these links when when all class-device
directories live in /sys/devices.
- Position of devices along device chain can change.
Never depend on a specific parent device position in the devpath,
or the chain of parent devices. The kernel is free to insert devices into
the chain. You must always request the parent device you are looking for
by its subsystem value. You need to walk up the chain until you find
the device that matches the expected subsystem. Depending on a specific
position of a parent device, or exposing relative paths, using "../" to
access the chain of parents, is a bug in the application.

52
Documentation/usb/dma.txt
View File

@ -32,12 +32,15 @@ ELIMINATING COPIES
It's good to avoid making CPUs copy data needlessly. The costs can add up,
and effects like cache-trashing can impose subtle penalties.
- When you're allocating a buffer for DMA purposes anyway, use the buffer
primitives. Think of them as kmalloc and kfree that give you the right
kind of addresses to store in urb->transfer_buffer and urb->transfer_dma,
while guaranteeing that no hidden copies through DMA "bounce" buffers will
slow things down. You'd also set URB_NO_TRANSFER_DMA_MAP in
urb->transfer_flags:
- If you're doing lots of small data transfers from the same buffer all
the time, that can really burn up resources on systems which use an
IOMMU to manage the DMA mappings. It can cost MUCH more to set up and
tear down the IOMMU mappings with each request than perform the I/O!
For those specific cases, USB has primitives to allocate less expensive
memory. They work like kmalloc and kfree versions that give you the right
kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:
void *usb_buffer_alloc (struct usb_device *dev, size_t size,
int mem_flags, dma_addr_t *dma);
@ -45,6 +48,10 @@ and effects like cache-trashing can impose subtle penalties.
void usb_buffer_free (struct usb_device *dev, size_t size,
void *addr, dma_addr_t dma);
Most drivers should *NOT* be using these primitives; they don't need
to use this type of memory ("dma-coherent"), and memory returned from
kmalloc() will work just fine.
For control transfers you can use the buffer primitives or not for each
of the transfer buffer and setup buffer independently. Set the flag bits
URB_NO_TRANSFER_DMA_MAP and URB_NO_SETUP_DMA_MAP to indicate which
@ -54,29 +61,39 @@ and effects like cache-trashing can impose subtle penalties.
The memory buffer returned is "dma-coherent"; sometimes you might need to
force a consistent memory access ordering by using memory barriers. It's
not using a streaming DMA mapping, so it's good for small transfers on
systems where the I/O would otherwise tie up an IOMMU mapping. (See
systems where the I/O would otherwise thrash an IOMMU mapping. (See
Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming"
DMA mappings.)
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
space-efficient.
On most systems the memory returned will be uncached, because the
semantics of dma-coherent memory require either bypassing CPU caches
or using cache hardware with bus-snooping support. While x86 hardware
has such bus-snooping, many other systems use software to flush cache
lines to prevent DMA conflicts.
- Devices on some EHCI controllers could handle DMA to/from high memory.
Driver probe() routines can notice this using a generic DMA call, then
tell higher level code (network, scsi, etc) about it like this:
if (dma_supported (&intf->dev, 0xffffffffffffffffULL))
net->features |= NETIF_F_HIGHDMA;
Unfortunately, the current Linux DMA infrastructure doesn't have a sane
way to expose these capabilities ... and in any case, HIGHMEM is mostly a
design wart specific to x86_32. So your best bet is to ensure you never
pass a highmem buffer into a USB driver. That's easy; it's the default
behavior. Just don't override it; e.g. with NETIF_F_HIGHDMA.
That can eliminate dma bounce buffering of requests that originate (or
terminate) in high memory, in cases where the buffers aren't allocated
with usb_buffer_alloc() but instead are dma-mapped.
This may force your callers to do some bounce buffering, copying from
high memory to "normal" DMA memory. If you can come up with a good way
to fix this issue (for x86_32 machines with over 1 GByte of memory),
feel free to submit patches.
WORKING WITH EXISTING BUFFERS
Existing buffers aren't usable for DMA without first being mapped into the
DMA address space of the device.
DMA address space of the device. However, most buffers passed to your
driver can safely be used with such DMA mapping. (See the first section
of DMA-mapping.txt, titled "What memory is DMA-able?")
- When you're using scatterlists, you can map everything at once. On some
systems, this kicks in an IOMMU and turns the scatterlists into single
@ -114,3 +131,8 @@ DMA address space of the device.
The calls manage urb->transfer_dma for you, and set URB_NO_TRANSFER_DMA_MAP
so that usbcore won't map or unmap the buffer. The same goes for
urb->setup_dma and URB_NO_SETUP_DMA_MAP for control requests.
Note that several of those interfaces are currently commented out, since
they don't have current users. See the source code. Other than the dmasync
calls (where the underlying DMA primitives have changed), most of them can
easily be commented back in if you want to use them.

156
Documentation/usb/persist.txt Normal file
View File

@ -0,0 +1,156 @@
USB device persistence during system suspend
Alan Stern <stern@rowland.harvard.edu>
September 2, 2006 (Updated May 29, 2007)
What is the problem?
According to the USB specification, when a USB bus is suspended the
bus must continue to supply suspend current (around 1-5 mA). This
is so that devices can maintain their internal state and hubs can
detect connect-change events (devices being plugged in or unplugged).
The technical term is "power session".
If a USB device's power session is interrupted then the system is
required to behave as though the device has been unplugged. It's a
conservative approach; in the absence of suspend current the computer
has no way to know what has actually happened. Perhaps the same
device is still attached or perhaps it was removed and a different
device plugged into the port. The system must assume the worst.
By default, Linux behaves according to the spec. If a USB host
controller loses power during a system suspend, then when the system
wakes up all the devices attached to that controller are treated as
though they had disconnected. This is always safe and it is the
"officially correct" thing to do.
For many sorts of devices this behavior doesn't matter in the least.
If the kernel wants to believe that your USB keyboard was unplugged
while the system was asleep and a new keyboard was plugged in when the
system woke up, who cares? It'll still work the same when you type on
it.
Unfortunately problems _can_ arise, particularly with mass-storage
devices. The effect is exactly the same as if the device really had
been unplugged while the system was suspended. If you had a mounted
filesystem on the device, you're out of luck -- everything in that
filesystem is now inaccessible. This is especially annoying if your
root filesystem was located on the device, since your system will
instantly crash.
Loss of power isn't the only mechanism to worry about. Anything that
interrupts a power session will have the same effect. For example,
even though suspend current may have been maintained while the system
was asleep, on many systems during the initial stages of wakeup the
firmware (i.e., the BIOS) resets the motherboard's USB host
controllers. Result: all the power sessions are destroyed and again
it's as though you had unplugged all the USB devices. Yes, it's
entirely the BIOS's fault, but that doesn't do _you_ any good unless
you can convince the BIOS supplier to fix the problem (lots of luck!).
On many systems the USB host controllers will get reset after a
suspend-to-RAM. On almost all systems, no suspend current is
available during hibernation (also known as swsusp or suspend-to-disk).
You can check the kernel log after resuming to see if either of these
has happened; look for lines saying "root hub lost power or was reset".
In practice, people are forced to unmount any filesystems on a USB
device before suspending. If the root filesystem is on a USB device,
the system can't be suspended at all. (All right, it _can_ be
suspended -- but it will crash as soon as it wakes up, which isn't
much better.)
What is the solution?
Setting CONFIG_USB_PERSIST will cause the kernel to work around these
issues. It enables a mode in which the core USB device data
structures are allowed to persist across a power-session disruption.
It works like this. If the kernel sees that a USB host controller is
not in the expected state during resume (i.e., if the controller was
reset or otherwise had lost power) then it applies a persistence check
to each of the USB devices below that controller for which the
"persist" attribute is set. It doesn't try to resume the device; that
can't work once the power session is gone. Instead it issues a USB
port reset and then re-enumerates the device. (This is exactly the
same thing that happens whenever a USB device is reset.) If the
re-enumeration shows that the device now attached to that port has the
same descriptors as before, including the Vendor and Product IDs, then
the kernel continues to use the same device structure. In effect, the
kernel treats the device as though it had merely been reset instead of
unplugged.
If no device is now attached to the port, or if the descriptors are
different from what the kernel remembers, then the treatment is what
you would expect. The kernel destroys the old device structure and
behaves as though the old device had been unplugged and a new device
plugged in, just as it would without the CONFIG_USB_PERSIST option.
The end result is that the USB device remains available and usable.
Filesystem mounts and memory mappings are unaffected, and the world is
now a good and happy place.
Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
will be applied only to those devices for which it is enabled. You
can enable the feature by doing (as root):
echo 1 >/sys/bus/usb/devices/.../power/persist
where the "..." should be filled in the with the device's ID. Disable
the feature by writing 0 instead of 1. For hubs the feature is
automatically and permanently enabled, so you only have to worry about
setting it for devices where it really matters.
Is this the best solution?
Perhaps not. Arguably, keeping track of mounted filesystems and
memory mappings across device disconnects should be handled by a
centralized Logical Volume Manager. Such a solution would allow you
to plug in a USB flash device, create a persistent volume associated
with it, unplug the flash device, plug it back in later, and still
have the same persistent volume associated with the device. As such
it would be more far-reaching than CONFIG_USB_PERSIST.
On the other hand, writing a persistent volume manager would be a big
job and using it would require significant input from the user. This
solution is much quicker and easier -- and it exists now, a giant
point in its favor!
Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
just mass-storage devices. It might turn out to be equally useful for
other device types, such as network interfaces.
WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
When recovering an interrupted power session the kernel does its best
to make sure the USB device hasn't been changed; that is, the same
device is still plugged into the port as before. But the checks
aren't guaranteed to be 100% accurate.
If you replace one USB device with another of the same type (same
manufacturer, same IDs, and so on) there's an excellent chance the
kernel won't detect the change. Serial numbers and other strings are
not compared. In many cases it wouldn't help if they were, because
manufacturers frequently omit serial numbers entirely in their
devices.
Furthermore it's quite possible to leave a USB device exactly the same
while changing its media. If you replace the flash memory card in a
USB card reader while the system is asleep, the kernel will have no
way to know you did it. The kernel will assume that nothing has
happened and will continue to use the partition tables, inodes, and
memory mappings for the old card.
If the kernel gets fooled in this way, it's almost certain to cause
data corruption and to crash your system. You'll have no one to blame
but yourself.
YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!
That having been said, most of the time there shouldn't be any trouble
at all. The "persist" feature can be extremely useful. Make the most
of it.

4
Documentation/video4linux/CARDLIST.bttv
View File

@ -66,7 +66,7 @@
65 -> Lifeview FlyVideo 2000S LR90
66 -> Terratec TValueRadio [153b:1135,153b:ff3b]
67 -> IODATA GV-BCTV4/PCI [10fc:4050]
68 -> 3Dfx VoodooTV FM (Euro), VoodooTV 200 (USA) [121a:3000,10b4:2637]
68 -> 3Dfx VoodooTV FM (Euro) [10b4:2637]
69 -> Active Imaging AIMMS
70 -> Prolink Pixelview PV-BT878P+ (Rev.4C,8E)
71 -> Lifeview FlyVideo 98EZ (capture only) LR51 [1851:1851]
@ -145,3 +145,5 @@
144 -> MagicTV
145 -> SSAI Security Video Interface [4149:5353]
146 -> SSAI Ultrasound Video Interface [414a:5353]
147 -> VoodooTV 200 (USA) [121a:3000]
148 -> DViCO FusionHDTV 2 [dbc0:d200]

1
Documentation/video4linux/CARDLIST.cx88
View File

@ -55,3 +55,4 @@
54 -> Norwood Micro TV Tuner
55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980]
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390]

1
Documentation/video4linux/CARDLIST.saa7134
View File

@ -114,3 +114,4 @@
113 -> Elitegroup ECS TVP3XP FM1246 Tuner Card (PAL,FM) [1019:4cb6]
114 -> KWorld DVB-T 210 [17de:7250]
115 -> Sabrent PCMCIA TV-PCB05 [0919:2003]
116 -> 10MOONS TM300 TV Card [1131:2304]

3
Documentation/video4linux/CARDLIST.tuner
View File

@ -40,7 +40,7 @@ tuner=38 - Philips PAL/SECAM multi (FM1216ME MK3)
tuner=39 - LG NTSC (newer TAPC series)
tuner=40 - HITACHI V7-J180AT
tuner=41 - Philips PAL_MK (FI1216 MK)
tuner=42 - Philips 1236D ATSC/NTSC dual in
tuner=42 - Philips FCV1236D ATSC/NTSC dual in
tuner=43 - Philips NTSC MK3 (FM1236MK3 or FM1236/F)
tuner=44 - Philips 4 in 1 (ATI TV Wonder Pro/Conexant)
tuner=45 - Microtune 4049 FM5
@ -72,3 +72,4 @@ tuner=70 - Samsung TCPN 2121P30A
tuner=71 - Xceive xc3028
tuner=72 - Thomson FE6600
tuner=73 - Samsung TCPG 6121P30A
tuner=75 - Philips TEA5761 FM Radio

3
Documentation/video4linux/sn9c102.txt
View File

@ -436,7 +436,7 @@ HV7131D Hynix Semiconductor | Yes No No No
HV7131R Hynix Semiconductor | No Yes Yes Yes
MI-0343 Micron Technology | Yes No No No
MI-0360 Micron Technology | No Yes Yes Yes
OV7630 OmniVision Technologies | Yes Yes No No
OV7630 OmniVision Technologies | Yes Yes Yes Yes
OV7660 OmniVision Technologies | No No Yes Yes
PAS106B PixArt Imaging | Yes No No No
PAS202B PixArt Imaging | Yes Yes No No
@ -583,6 +583,7 @@ order):
- Bertrik Sikken, who reverse-engineered and documented the Huffman compression
algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and
implemented the first decoder;
- Ronny Standke for the donation of a webcam;
- Mizuno Takafumi for the donation of a webcam;
- an "anonymous" donator (who didn't want his name to be revealed) for the
donation of a webcam.

2
Documentation/video4linux/zr364xx.txt
View File

@ -62,4 +62,4 @@ Vendor Product Distributor Model
0x0784 0x0040 Traveler Slimline X5
0x06d6 0x0034 Trust Powerc@m 750
0x0a17 0x0062 Pentax Optio 50L
0x06d6 0x003b Trust Powerc@m 970Z

10
Documentation/vm/hugetlbpage.txt
View File

@ -77,8 +77,9 @@ If the user applications are going to request hugepages using mmap system
call, then it is required that system administrator mount a file system of
type hugetlbfs:
mount none /mnt/huge -t hugetlbfs <uid=value> <gid=value> <mode=value>
<size=value> <nr_inodes=value>
mount -t hugetlbfs \
-o uid=<value>,gid=<value>,mode=<value>,size=<value>,nr_inodes=<value> \
none /mnt/huge
This command mounts a (pseudo) filesystem of type hugetlbfs on the directory
/mnt/huge. Any files created on /mnt/huge uses hugepages. The uid and gid
@ -88,11 +89,10 @@ mode of root of file system to value & 0777. This value is given in octal.
By default the value 0755 is picked. The size option sets the maximum value of
memory (huge pages) allowed for that filesystem (/mnt/huge). The size is
rounded down to HPAGE_SIZE. The option nr_inodes sets the maximum number of
inodes that /mnt/huge can use. If the size or nr_inodes options are not
inodes that /mnt/huge can use. If the size or nr_inodes option is not
provided on command line then no limits are set. For size and nr_inodes
options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For
example, size=2K has the same meaning as size=2048. An example is given at
the end of this document.
example, size=2K has the same meaning as size=2048.
read and write system calls are not supported on files that reside on hugetlb
file systems.

139
Documentation/vm/slub.txt
View File

@ -41,6 +41,8 @@ Possible debug options are
P Poisoning (object and padding)
U User tracking (free and alloc)
T Trace (please only use on single slabs)
- Switch all debugging off (useful if the kernel is
configured with CONFIG_SLUB_DEBUG_ON)
F.e. in order to boot just with sanity checks and red zoning one would specify:
@ -125,13 +127,20 @@ SLUB Debug output
Here is a sample of slub debug output:
*** SLUB kmalloc-8: Redzone Active@0xc90f6d20 slab 0xc528c530 offset=3360 flags=0x400000c3 inuse=61 freelist=0xc90f6d58
Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005
Redzone 0xc90f6d28: 00 cc cc cc .
FreePointer 0xc90f6d2c -> 0xc90f6d58
Last alloc: get_modalias+0x61/0xf5 jiffies_ago=53 cpu=1 pid=554
Filler 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
====================================================================
BUG kmalloc-8: Redzone overwritten
--------------------------------------------------------------------
INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc
INFO: Slab 0xc528c530 flags=0x400000c3 inuse=61 fp=0xc90f6d58
INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58
INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554
Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005
Redzone 0xc90f6d28: 00 cc cc cc .
Padding 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[<c010523d>] dump_trace+0x63/0x1eb
[<c01053df>] show_trace_log_lvl+0x1a/0x2f
[<c010601d>] show_trace+0x12/0x14
@ -153,74 +162,108 @@ Filler 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[<c0104112>] sysenter_past_esp+0x5f/0x99
[<b7f7b410>] 0xb7f7b410
=======================
@@@ SLUB kmalloc-8: Restoring redzone (0xcc) from 0xc90f6d28-0xc90f6d2b
FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc
If SLUB encounters a corrupted object (full detection requires the kernel
to be booted with slub_debug) then the following output will be dumped
into the syslog:
If SLUB encounters a corrupted object then it will perform the following
actions:
1. Isolation and report of the issue
1. Description of the problem encountered
This will be a message in the system log starting with
*** SLUB <slab cache affected>: <What went wrong>@<object address>
offset=<offset of object into slab> flags=<slabflags>
inuse=<objects in use in this slab> freelist=<first free object in slab>
===============================================
BUG <slab cache affected>: <What went wrong>
-----------------------------------------------
2. Report on how the problem was dealt with in order to ensure the continued
operation of the system.
INFO: <corruption start>-<corruption_end> <more info>
INFO: Slab <address> <slab information>
INFO: Object <address> <object information>
INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by
cpu> pid=<pid of the process>
INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>
pid=<pid of the process>
These are messages in the system log beginning with
(Object allocation / free information is only available if SLAB_STORE_USER is
set for the slab. slub_debug sets that option)
@@@ SLUB <slab cache affected>: <corrective action taken>
2. The object contents if an object was involved.
In the above sample SLUB found that the Redzone of an active object has
been overwritten. Here a string of 8 characters was written into a slab that
has the length of 8 characters. However, a 8 character string needs a
terminating 0. That zero has overwritten the first byte of the Redzone field.
After reporting the details of the issue encountered the @@@ SLUB message
tell us that SLUB has restored the redzone to its proper value and then
system operations continue.
Various types of lines can follow the @@@ SLUB line:
Various types of lines can follow the BUG SLUB line:
Bytes b4 <address> : <bytes>
Show a few bytes before the object where the problem was detected.
Shows a few bytes before the object where the problem was detected.
Can be useful if the corruption does not stop with the start of the
object.
Object <address> : <bytes>
The bytes of the object. If the object is inactive then the bytes
typically contain poisoning values. Any non-poison value shows a
typically contain poison values. Any non-poison value shows a
corruption by a write after free.
Redzone <address> : <bytes>
The redzone following the object. The redzone is used to detect
The Redzone following the object. The Redzone is used to detect
writes after the object. All bytes should always have the same
value. If there is any deviation then it is due to a write after
the object boundary.
Freepointer
The pointer to the next free object in the slab. May become
corrupted if overwriting continues after the red zone.
(Redzone information is only available if SLAB_RED_ZONE is set.
slub_debug sets that option)
Last alloc:
Last free:
Shows the address from which the object was allocated/freed last.
We note the pid, the time and the CPU that did so. This is usually
the most useful information to figure out where things went wrong.
Here get_modalias() did an kmalloc(8) instead of a kmalloc(9).
Filler <address> : <bytes>
Padding <address> : <bytes>
Unused data to fill up the space in order to get the next object
properly aligned. In the debug case we make sure that there are
at least 4 bytes of filler. This allow for the detection of writes
at least 4 bytes of padding. This allows the detection of writes
before the object.
Following the filler will be a stackdump. That stackdump describes the
location where the error was detected. The cause of the corruption is more
likely to be found by looking at the information about the last alloc / free.
3. A stackdump
Christoph Lameter, <clameter@sgi.com>, May 23, 2007
The stackdump describes the location where the error was detected. The cause
of the corruption is may be more likely found by looking at the function that
allocated or freed the object.
4. Report on how the problem was dealt with in order to ensure the continued
operation of the system.
These are messages in the system log beginning with
FIX <slab cache affected>: <corrective action taken>
In the above sample SLUB found that the Redzone of an active object has
been overwritten. Here a string of 8 characters was written into a slab that
has the length of 8 characters. However, a 8 character string needs a
terminating 0. That zero has overwritten the first byte of the Redzone field.
After reporting the details of the issue encountered the FIX SLUB message
tell us that SLUB has restored the Redzone to its proper value and then
system operations continue.
Emergency operations:
---------------------
Minimal debugging (sanity checks alone) can be enabled by booting with
slub_debug=F
This will be generally be enough to enable the resiliency features of slub
which will keep the system running even if a bad kernel component will
keep corrupting objects. This may be important for production systems.
Performance will be impacted by the sanity checks and there will be a
continual stream of error messages to the syslog but no additional memory
will be used (unlike full debugging).
No guarantees. The kernel component still needs to be fixed. Performance
may be optimized further by locating the slab that experiences corruption
and enabling debugging only for that cache
I.e.
slub_debug=F,dentry
If the corruption occurs by writing after the end of the object then it
may be advisable to enable a Redzone to avoid corrupting the beginning
of other objects.
slub_debug=FZ,dentry
Christoph Lameter, <clameter@sgi.com>, May 30, 2007

119
Documentation/volatile-considered-harmful.txt Normal file
View File

@ -0,0 +1,119 @@
Why the "volatile" type class should not be used
------------------------------------------------
C programmers have often taken volatile to mean that the variable could be
changed outside of the current thread of execution; as a result, they are
sometimes tempted to use it in kernel code when shared data structures are
being used. In other words, they have been known to treat volatile types
as a sort of easy atomic variable, which they are not. The use of volatile in
kernel code is almost never correct; this document describes why.
The key point to understand with regard to volatile is that its purpose is
to suppress optimization, which is almost never what one really wants to
do. In the kernel, one must protect shared data structures against
unwanted concurrent access, which is very much a different task. The
process of protecting against unwanted concurrency will also avoid almost
all optimization-related problems in a more efficient way.
Like volatile, the kernel primitives which make concurrent access to data
safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent
unwanted optimization. If they are being used properly, there will be no
need to use volatile as well. If volatile is still necessary, there is
almost certainly a bug in the code somewhere. In properly-written kernel
code, volatile can only serve to slow things down.
Consider a typical block of kernel code:
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);
If all the code follows the locking rules, the value of shared_data cannot
change unexpectedly while the_lock is held. Any other code which might
want to play with that data will be waiting on the lock. The spinlock
primitives act as memory barriers - they are explicitly written to do so -
meaning that data accesses will not be optimized across them. So the
compiler might think it knows what will be in shared_data, but the
spin_lock() call, since it acts as a memory barrier, will force it to
forget anything it knows. There will be no optimization problems with
accesses to that data.
If shared_data were declared volatile, the locking would still be
necessary. But the compiler would also be prevented from optimizing access
to shared_data _within_ the critical section, when we know that nobody else
can be working with it. While the lock is held, shared_data is not
volatile. When dealing with shared data, proper locking makes volatile
unnecessary - and potentially harmful.
The volatile storage class was originally meant for memory-mapped I/O
registers. Within the kernel, register accesses, too, should be protected
by locks, but one also does not want the compiler "optimizing" register
accesses within a critical section. But, within the kernel, I/O memory
accesses are always done through accessor functions; accessing I/O memory
directly through pointers is frowned upon and does not work on all
architectures. Those accessors are written to prevent unwanted
optimization, so, once again, volatile is unnecessary.
Another situation where one might be tempted to use volatile is
when the processor is busy-waiting on the value of a variable. The right
way to perform a busy wait is:
while (my_variable != what_i_want)
cpu_relax();
The cpu_relax() call can lower CPU power consumption or yield to a
hyperthreaded twin processor; it also happens to serve as a memory barrier,
so, once again, volatile is unnecessary. Of course, busy-waiting is
generally an anti-social act to begin with.
There are still a few rare situations where volatile makes sense in the
kernel:
- The above-mentioned accessor functions might use volatile on
architectures where direct I/O memory access does work. Essentially,
each accessor call becomes a little critical section on its own and
ensures that the access happens as expected by the programmer.
- Inline assembly code which changes memory, but which has no other
visible side effects, risks being deleted by GCC. Adding the volatile
keyword to asm statements will prevent this removal.
- The jiffies variable is special in that it can have a different value
every time it is referenced, but it can be read without any special
locking. So jiffies can be volatile, but the addition of other
variables of this type is strongly frowned upon. Jiffies is considered
to be a "stupid legacy" issue (Linus's words) in this regard; fixing it
would be more trouble than it is worth.
- Pointers to data structures in coherent memory which might be modified
by I/O devices can, sometimes, legitimately be volatile. A ring buffer
used by a network adapter, where that adapter changes pointers to
indicate which descriptors have been processed, is an example of this
type of situation.
For most code, none of the above justifications for volatile apply. As a
result, the use of volatile is likely to be seen as a bug and will bring
additional scrutiny to the code. Developers who are tempted to use
volatile should take a step back and think about what they are truly trying
to accomplish.
Patches to remove volatile variables are generally welcome - as long as
they come with a justification which shows that the concurrency issues have
been properly thought through.
NOTES
-----
[1] http://lwn.net/Articles/233481/
[2] http://lwn.net/Articles/233482/
CREDITS
-------
Original impetus and research by Randy Dunlap
Written by Jonathan Corbet
Improvements via coments from Satyam Sharma, Johannes Stezenbach, Jesper
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
Richter.

170
MAINTAINERS
View File

@ -194,13 +194,6 @@ M: jes@trained-monkey.org
L: linux-acenic@sunsite.dk
S: Maintained
ACI MIXER DRIVER
P: Robert Siemer
M: Robert.Siemer@gmx.de
L: linux-sound@vger.kernel.org
W: http://www.stud.uni-karlsruhe.de/~uh1b/
S: Maintained
IPS SCSI RAID DRIVER
P: Adaptec OEM Raid Solutions
M: aacraid@adaptec.com
@ -272,21 +265,6 @@ L: linux-acpi@vger.kernel.org
W: http://acpi.sourceforge.net/
S: Supported
AD1816 SOUND DRIVER
P: Thorsten Knabe
M: Thorsten Knabe <linux@thorsten-knabe.de>
W: http://linux.thorsten-knabe.de
S: Maintained
AD1889 SOUND DRIVER
P: Kyle McMartin
M: kyle@parisc-linux.org
P: Thibaut Varene
M: T-Bone@parisc-linux.org
W: http://wiki.parisc-linux.org/AD1889
L: parisc-linux@lists.parisc-linux.org
S: Maintained
ADM1025 HARDWARE MONITOR DRIVER
P: Jean Delvare
M: khali@linux-fr.org
@ -315,10 +293,9 @@ M: zippel@linux-m68k.org
S: Maintained
AGPGART DRIVER
P: Dave Jones
M: davej@codemonkey.org.uk
W: http://www.codemonkey.org.uk/projects/agp/
T: git kernel.org:/pub/scm/linux/kernel/git/davej/agpgart.git
P: David Airlie
M: airlied@linux.ie
T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
S: Maintained
AHA152X SCSI DRIVER
@ -371,7 +348,7 @@ P: Tom Tucker
M: tom@opengridcomputing.com
P: Steve Wise
M: swise@opengridcomputing.com
L: openib-general@openib.org
L: general@lists.openfabrics.org
S: Maintained
AOA (Apple Onboard Audio) ALSA DRIVER
@ -936,6 +913,12 @@ M: mchan@broadcom.com
L: netdev@vger.kernel.org
S: Supported
BSG (block layer generic sg v4 driver)
P: FUJITA Tomonori
M: fujita.tomonori@lab.ntt.co.jp
L: linux-scsi@vger.kernel.org
S: Supported
BTTV VIDEO4LINUX DRIVER
P: Mauro Carvalho Chehab
M: mchehab@infradead.org
@ -1277,6 +1260,12 @@ M: tori@unhappy.mine.nu
L: netdev@vger.kernel.org
S: Maintained
DMA GENERIC MEMCPY SUBSYSTEM
P: Shannon Nelson
M: shannon.nelson@intel.com
L: linux-kernel@vger.kernel.org
S: Maintained
DOCBOOK FOR DOCUMENTATION
P: Randy Dunlap
M: rdunlap@xenotime.net
@ -1396,16 +1385,9 @@ P: Hoang-Nam Nguyen
M: hnguyen@de.ibm.com
P: Christoph Raisch
M: raisch@de.ibm.com
L: openib-general@openib.org
L: general@lists.openfabrics.org
S: Supported
EMU10K1 SOUND DRIVER
P: James Courtier-Dutton
M: James@superbug.demon.co.uk
L: emu10k1-devel@lists.sourceforge.net
W: http://sourceforge.net/projects/emu10k1/
S: Maintained
EMULEX LPFC FC SCSI DRIVER
P: James Smart
M: james.smart@emulex.com
@ -1750,14 +1732,15 @@ T: http://www.harbaum.org/till/i2c_tiny_usb
S: Maintained
i386 BOOT CODE
P: Riley H. Williams
M: Riley@Williams.Name
P: H. Peter Anvin
M: hpa@zytor.com
L: Linux-Kernel@vger.kernel.org
S: Maintained
i386 SETUP CODE / CPU ERRATA WORKAROUNDS
P: H. Peter Anvin
M: hpa@zytor.com
T: git.kernel.org:/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
S: Maintained
IA64 (Itanium) PLATFORM
@ -1850,13 +1833,13 @@ M: rolandd@cisco.com
P: Sean Hefty
M: mshefty@ichips.intel.com
P: Hal Rosenstock
M: halr@voltaire.com
L: openib-general@openib.org
M: hal.rosenstock@gmail.com
L: general@lists.openfabrics.org
W: http://www.openib.org/
T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
S: Supported
INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVERS
INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS
P: Dmitry Torokhov
M: dmitry.torokhov@gmail.com
M: dtor@mail.ru
@ -1901,6 +1884,12 @@ P: Tigran Aivazian
M: tigran@aivazian.fsnet.co.uk
S: Maintained
INTEL I/OAT DMA DRIVER
P: Shannon Nelson
M: shannon.nelson@intel.com
L: linux-kernel@vger.kernel.org
S: Supported
INTEL IXP4XX RANDOM NUMBER GENERATOR SUPPORT
P: Deepak Saxena
M: dsaxena@plexity.net
@ -1989,9 +1978,10 @@ M: jjciarla@raiz.uncu.edu.ar
S: Maintained
IPATH DRIVER:
P: Bryan O'Sullivan
M: support@pathscale.com
L: openib-general@openib.org
P: Arthur Jones
M: infinipath@qlogic.com
L: general@lists.openfabrics.org
T: git git://git.qlogic.com/ipath-linux-2.6
S: Supported
IPMI SUBSYSTEM
@ -2101,7 +2091,7 @@ S: Maintained
KERNEL JANITORS
P: Several
L: kernel-janitors@lists.linux-foundation.org
L: kernel-janitors@vger.kernel.org
W: http://www.kerneljanitors.org/
S: Maintained
@ -2297,6 +2287,14 @@ M: matthew@wil.cx
L: linux-scsi@vger.kernel.org
S: Maintained
M32R ARCHITECTURE
P: Hirokazu Takata
M: takata@linux-m32r.org
L: linux-m32r@ml.linux-m32r.org
L: linux-m32r-ja@ml.linux-m32r.org (in Japanese)
W: http://www.linux-m32r.org/
S: Maintained
M68K ARCHITECTURE
P: Geert Uytterhoeven
M: geert@linux-m68k.org
@ -2330,6 +2328,12 @@ W: http://linuxwireless.org/
T: git kernel.org:/pub/scm/linux/kernel/git/jbenc/mac80211.git
S: Maintained
MACVLAN DRIVER
P: Patrick McHardy
M: kaber@trash.net
L: netdev@vger.kernel.org
S: Maintained
MARVELL YUKON / SYSKONNECT DRIVER
P: Mirko Lindner
M: mlindner@syskonnect.de
@ -2390,7 +2394,7 @@ P: Artem Bityutskiy
M: dedekind@infradead.org
W: http://www.linux-mtd.infradead.org/
L: linux-mtd@lists.infradead.org
T: git git://git.infradead.org/ubi-2.6.git
T: git git://git.infradead.org/~dedekind/ubi-2.6.git
S: Maintained
MICROTEK X6 SCANNER
@ -2616,12 +2620,6 @@ M: yokota@netlab.is.tsukuba.ac.jp
W: http://www.netlab.is.tsukuba.ac.jp/~yokota/izumi/ninja/
S: Maintained
NON-IDE/NON-SCSI CDROM DRIVERS [GENERAL] (come on, crew - mark your responsibility)
P: Eberhard Moenkeberg
M: emoenke@gwdg.de
L: linux-kernel@vger.kernel.org
S: Maintained
NTFS FILESYSTEM
P: Anton Altaparmakov
M: aia21@cantab.net
@ -2704,12 +2702,6 @@ L: osst-users@lists.sourceforge.net
L: linux-scsi@vger.kernel.org
S: Maintained
OPL3-SA2, SA3, and SAx DRIVER
P: Zwane Mwaikambo
M: zwane@arm.linux.org.uk
L: linux-sound@vger.kernel.org
S: Maintained
OPROFILE
P: Philippe Elie
M: phil.el@wanadoo.fr
@ -2814,11 +2806,6 @@ P: Kristen Carlson Accardi
M: kristen.c.accardi@intel.com
S: Supported
PCI HOTPLUG COMPAQ DRIVER
P: Greg Kroah-Hartman
M: greg@kroah.com
S: Maintained
PCIE HOTPLUG DRIVER
P: Kristen Carlson Accardi
M: kristen.c.accardi@intel.com
@ -2868,6 +2855,16 @@ M: george@mvista.com
L: linux-kernel@vger.kernel.org
S: Supported
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
P: Anton Vorontsov
M: cbou@mail.ru
P: David Woodhouse
M: dwmw2@infradead.org
L: linux-kernel@vger.kernel.org
L: kernel-discuss@handhelds.org
T: git git.infradead.org/battery-2.6.git
S: Maintained
POWERPC 4xx EMAC DRIVER
P: Eugene Surovegin
M: ebs@ebshome.net
@ -2903,6 +2900,11 @@ P: Michal Ostrowski
M: mostrows@speakeasy.net
S: Maintained
PPP OVER L2TP
P: James Chapman
M: jchapman@katalix.com
S: Maintained
PREEMPTIBLE KERNEL
P: Robert Love
M: rml@tech9.net
@ -2930,6 +2932,13 @@ M: mikpe@it.uu.se
L: linux-ide@vger.kernel.org
S: Maintained
PS3 NETWORK SUPPORT
P: Masakazu Mokuno
M: mokuno@sm.sony.co.jp
L: netdev@vger.kernel.org
L: cbe-oss-dev@ozlabs.org
S: Supported
PS3 PLATFORM SUPPORT
P: Geoff Levand
M: geoffrey.levand@am.sony.com
@ -3049,6 +3058,16 @@ S: Maintained
RISCOM8 DRIVER
S: Orphan
RTL818X WIRELESS DRIVER
P: Michael Wu
M: flamingice@sourmilk.net
P: Andrea Merello
M: andreamrl@tiscali.it
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
T: git kernel.org:/pub/scm/linux/kernel/git/mwu/mac80211-drivers.git
S: Maintained
S3 SAVAGE FRAMEBUFFER DRIVER
P: Antonino Daplas
M: adaplas@gmail.com
@ -3087,12 +3106,6 @@ M: michael@mihu.de
W: http://www.mihu.de/linux/saa7146
S: Maintained
SBPCD CDROM DRIVER
P: Eberhard Moenkeberg
M: emoenke@gwdg.de
L: linux-kernel@vger.kernel.org
S: Maintained
SC1200 WDT DRIVER
P: Zwane Mwaikambo
M: zwane@arm.linux.org.uk
@ -3618,7 +3631,7 @@ W: http://www.kroah.com/linux-usb/
USB DAVICOM DM9601 DRIVER
P: Peter Korsgaard
M: jacmet@sunsite.dk
L: linux-usb-devel@lists.sourceforge.net
L: netdev@vger.kernel.org
W: http://www.linux-usb.org/usbnet
S: Maintained
@ -3702,23 +3715,23 @@ S: Maintained
USB PEGASUS DRIVER
P: Petko Manolov
M: petkan@users.sourceforge.net
L: linux-usb-users@lists.sourceforge.net
L: linux-usb-devel@lists.sourceforge.net
L: netdev@vger.kernel.org
W: http://pegasus2.sourceforge.net/
S: Maintained
USB PRINTER DRIVER
P: Vojtech Pavlik
M: vojtech@suse.cz
USB PRINTER DRIVER (usblp)
P: Pete Zaitcev
M: zaitcev@redhat.com
L: linux-usb-users@lists.sourceforge.net
L: linux-usb-devel@lists.sourceforge.net
S: Maintained
S: Supported
USB RTL8150 DRIVER
P: Petko Manolov
M: petkan@users.sourceforge.net
L: linux-usb-users@lists.sourceforge.net
L: linux-usb-devel@lists.sourceforge.net
L: netdev@vger.kernel.org
W: http://pegasus2.sourceforge.net/
S: Maintained
@ -3829,7 +3842,7 @@ S: Maintained
USB "USBNET" DRIVER FRAMEWORK
P: David Brownell
M: dbrownell@users.sourceforge.net
L: linux-usb-devel@lists.sourceforge.net
L: netdev@vger.kernel.org
W: http://www.linux-usb.org/usbnet
S: Maintained
@ -4098,6 +4111,11 @@ W: http://www.polyware.nl/~middelin/En/hobbies.html
W: http://www.polyware.nl/~middelin/hobbies.html
S: Maintained
ZS DECSTATION Z85C30 SERIAL DRIVER
P: Maciej W. Rozycki
M: macro@linux-mips.org
S: Maintained
THE REST
P: Linus Torvalds
S: Buried alive in reporters

Some files were not shown because too many files have changed in this diff Show More