Fix typos in Documentation/: 'N'-'P'
This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letters 'N'-'P'. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>wifi-calibration
Matt LaPlante
Adrian Bunk
parent
2fe0ae78c6
commit
992caacf11
|
|
@ -38,7 +38,7 @@ MTD
|
|||
---
|
||||
|
||||
The NAND and NOR support has been merged from the linux-mtd project.
|
||||
Any prolbems, see http://www.linux-mtd.infradead.org/ for more
|
||||
Any problems, see http://www.linux-mtd.infradead.org/ for more
|
||||
information or up-to-date versions of linux-mtd.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller
|
|||
at a time during a write batch. It is this characteristic that can make
|
||||
the anticipatory scheduler perform anomalously with controllers supporting
|
||||
TCQ, or with hardware striped RAID devices. Setting the antic_expire
|
||||
queue paramter (see below) to zero disables this behavior, and the anticipatory
|
||||
scheduler behaves essentially like the deadline scheduler.
|
||||
queue parameter (see below) to zero disables this behavior, and the
|
||||
anticipatory scheduler behaves essentially like the deadline scheduler.
|
||||
|
||||
When read anticipation is enabled (antic_expire is not zero), reads
|
||||
are dispatched to the disk controller one at a time.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case
|
|||
of ii. Just keeping issue order suffices. Ancient SCSI
|
||||
controllers/drives and IDE drives are in this category.
|
||||
|
||||
2. Forced flushing to physcial medium
|
||||
2. Forced flushing to physical medium
|
||||
|
||||
Again, if you're not gonna do synchronization with disk drives (dang,
|
||||
it sounds even more appealing now!), the reason you use I/O barriers
|
||||
|
|
|
|||
|
|
@ -137,11 +137,11 @@ have to be made in a row before the CPU frequency is actually lower.
|
|||
If set to '1' then the frequency decreases as quickly as it increases,
|
||||
if set to '2' it decreases at half the rate of the increase.
|
||||
|
||||
ignore_nice_load: this parameter takes a value of '0' or '1', when set
|
||||
to '0' (its default) then all processes are counted towards towards the
|
||||
'cpu utilisation' value. When set to '1' then processes that are
|
||||
ignore_nice_load: this parameter takes a value of '0' or '1'. When
|
||||
set to '0' (its default), all processes are counted towards the
|
||||
'cpu utilisation' value. When set to '1', the processes that are
|
||||
run with a 'nice' value will not count (and thus be ignored) in the
|
||||
overal usage calculation. This is useful if you are running a CPU
|
||||
overall usage calculation. This is useful if you are running a CPU
|
||||
intensive calculation on your laptop that you do not care how long it
|
||||
takes to complete as you can 'nice' it and prevent it from taking part
|
||||
in the deciding process of whether to increase your CPU frequency.
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ echo packet > /sys/devices/platform/dell_rbu/image_type
|
|||
In packet update mode the packet size has to be given before any packets can
|
||||
be downloaded. It is done as below
|
||||
echo XXXX > /sys/devices/platform/dell_rbu/packet_size
|
||||
In the packet update mechanism, the user neesd to create a new file having
|
||||
In the packet update mechanism, the user needs to create a new file having
|
||||
packets of data arranged back to back. It can be done as follows
|
||||
The user creates packets header, gets the chunk of the BIOS image and
|
||||
places it next to the packetheader; now, the packetheader + BIOS image chunk
|
||||
|
|
@ -93,8 +93,8 @@ read back the image downloaded.
|
|||
NOTE:
|
||||
This driver requires a patch for firmware_class.c which has the modified
|
||||
request_firmware_nowait function.
|
||||
Also after updating the BIOS image an user mdoe application neeeds to execute
|
||||
code which message the BIOS update request to the BIOS. So on the next reboot
|
||||
the BIOS knows about the new image downloaded and it updates it self.
|
||||
Also don't unload the rbu drive if the image has to be updated.
|
||||
Also after updating the BIOS image a user mode application needs to execute
|
||||
code which sends the BIOS update request to the BIOS. So on the next reboot
|
||||
the BIOS knows about the new image downloaded and it updates itself.
|
||||
Also don't unload the rbu driver if the image has to be updated.
|
||||
|
||||
|
|
|
|||
|
|
@ -2005,7 +2005,7 @@ Your cooperation is appreciated.
|
|||
116 char Advanced Linux Sound Driver (ALSA)
|
||||
|
||||
116 block MicroMemory battery backed RAM adapter (NVRAM)
|
||||
Supports 16 boards, 15 paritions each.
|
||||
Supports 16 boards, 15 partitions each.
|
||||
Requested by neilb at cse.unsw.edu.au.
|
||||
|
||||
0 = /dev/umem/d0 Whole of first board
|
||||
|
|
@ -3094,7 +3094,7 @@ Your cooperation is appreciated.
|
|||
This major is reserved to assist the expansion to a
|
||||
larger number space. No device nodes with this major
|
||||
should ever be created on the filesystem.
|
||||
(This is probaly not true anymore, but I'll leave it
|
||||
(This is probably not true anymore, but I'll leave it
|
||||
for now /Torben)
|
||||
|
||||
---LARGE MAJORS!!!!!---
|
||||
|
|
|
|||
|
|
@ -45,9 +45,9 @@ Assumptions and Introduction
|
|||
by circuitry on the card and is often presented uncompressed.
|
||||
For a PAL TV signal encoded at a resolution of 768x576 24-bit
|
||||
color pixels over 25 frames per second - a fair amount of data
|
||||
is generated and must be proceesed by the PC before it can be
|
||||
is generated and must be processed by the PC before it can be
|
||||
displayed on the video monitor screen. Some Analogue TV cards
|
||||
for PC's have onboard MPEG2 encoders which permit the raw
|
||||
for PCs have onboard MPEG2 encoders which permit the raw
|
||||
digital data stream to be presented to the PC in an encoded
|
||||
and compressed form - similar to the form that is used in
|
||||
Digital TV.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Some very frequently asked questions about linuxtv-dvb
|
|||
It's not a bug, it's a feature. Because the frontends have
|
||||
significant power requirements (and hence get very hot), they
|
||||
are powered down if they are unused (i.e. if the frontend device
|
||||
is closed). The dvb-core.o module paramter "dvb_shutdown_timeout"
|
||||
is closed). The dvb-core.o module parameter "dvb_shutdown_timeout"
|
||||
allow you to change the timeout (default 5 seconds). Setting the
|
||||
timeout to 0 disables the timeout feature.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ struct eisa_driver {
|
|||
|
||||
id_table : an array of NULL terminated EISA id strings,
|
||||
followed by an empty string. Each string can
|
||||
optionnaly be paired with a driver-dependant value
|
||||
optionally be paired with a driver-dependant value
|
||||
(driver_data).
|
||||
|
||||
driver : a generic driver, such as described in
|
||||
|
|
|
|||
|
|
@ -72,8 +72,8 @@ Module Usage
|
|||
|
||||
Kernel/Modules Options
|
||||
|
||||
You can pass some otions to sstfb module, and via the kernel command
|
||||
line when the driver is compiled in :
|
||||
You can pass some options to the sstfb module, and via the kernel
|
||||
command line when the driver is compiled in:
|
||||
for module : insmod sstfb.o option1=value1 option2=value2 ...
|
||||
in kernel : video=sstfb:option1,option2:value2,option3 ...
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ He has been working on the code since Aug 13, 2001. See the changelog for
|
|||
details.
|
||||
|
||||
Original Author: Makoto Kato <m_kato@ga2.so-net.ne.jp>
|
||||
His orriginal code can still be found at:
|
||||
His original code can still be found at:
|
||||
<http://hp.vector.co.jp/authors/VA008030/bfs/>
|
||||
Does anyone know of a more current email address for Makoto? He doesn't
|
||||
respond to the address given above...
|
||||
|
|
@ -39,7 +39,7 @@ Which is it, BFS or BEFS?
|
|||
================
|
||||
Be, Inc said, "BeOS Filesystem is officially called BFS, not BeFS".
|
||||
But Unixware Boot Filesystem is called bfs, too. And they are already in
|
||||
the kernel. Because of this nameing conflict, on Linux the BeOS
|
||||
the kernel. Because of this naming conflict, on Linux the BeOS
|
||||
filesystem is called befs.
|
||||
|
||||
HOW TO INSTALL
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ Reserved Space
|
|||
|
||||
In ext2, there is a mechanism for reserving a certain number of blocks
|
||||
for a particular user (normally the super-user). This is intended to
|
||||
allow for the system to continue functioning even if non-priveleged users
|
||||
allow for the system to continue functioning even if non-privileged users
|
||||
fill up all the space available to them (this is independent of filesystem
|
||||
quotas). It also keeps the filesystem from filling up entirely which
|
||||
helps combat fragmentation.
|
||||
|
|
|
|||
|
|
@ -359,7 +359,7 @@ ERRORS
|
|||
EFAULT npc is not a valid pointer or status is neither NULL nor a valid
|
||||
pointer.
|
||||
|
||||
EINTR A signal occured while spu_run was in progress. The npc value
|
||||
EINTR A signal occurred while spu_run was in progress. The npc value
|
||||
has been updated to the new program counter value if necessary.
|
||||
|
||||
EINVAL fd is not a file descriptor returned from spu_create(2).
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ several reasons why such integration is hard/impossible:
|
|||
high-res timers.
|
||||
|
||||
- the unpredictable [O(N)] overhead of cascading leads to delays which
|
||||
necessiate a more complex handling of high resolution timers, which
|
||||
necessitate a more complex handling of high resolution timers, which
|
||||
in turn decreases robustness. Such a design still led to rather large
|
||||
timing inaccuracies. Cascading is a fundamental property of the timer
|
||||
wheel concept, it cannot be 'designed out' without unevitably
|
||||
|
|
|
|||
|
|
@ -465,8 +465,8 @@ more parallel ports.
|
|||
|
||||
There are two options specific to PSX driver portion. gamecon.psx_delay sets
|
||||
the command delay when talking to the controllers. The default of 25 should
|
||||
work but you can try lowering it for better performace. If your pads don't
|
||||
respond try raising it untill they work. Setting the type to 8 allows the
|
||||
work but you can try lowering it for better performance. If your pads don't
|
||||
respond try raising it until they work. Setting the type to 8 allows the
|
||||
driver to be used with Dance Dance Revolution or similar games. Arrow keys are
|
||||
registered as key presses instead of X and Y axes.
|
||||
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ Proof of 100% correctness:
|
|||
|
||||
The validator achieves perfect, mathematical 'closure' (proof of locking
|
||||
correctness) in the sense that for every simple, standalone single-task
|
||||
locking sequence that occured at least once during the lifetime of the
|
||||
locking sequence that occurred at least once during the lifetime of the
|
||||
kernel, the validator proves it with a 100% certainty that no
|
||||
combination and timing of these locking sequences can cause any class of
|
||||
lock related deadlock. [*]
|
||||
|
|
|
|||
|
|
@ -330,7 +330,7 @@ Each directory contains:
|
|||
This gives the role that the device has in the array. It will
|
||||
either be 'none' if the device is not active in the array
|
||||
(i.e. is a spare or has failed) or an integer less than the
|
||||
'raid_disks' number for the array indicating which possition
|
||||
'raid_disks' number for the array indicating which position
|
||||
it currently fills. This can only be set while assembling an
|
||||
array. A device for which this is set is assumed to be working.
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ in the array. These are named
|
|||
|
||||
rdNN
|
||||
|
||||
where 'NN' is the possition in the array, starting from 0.
|
||||
where 'NN' is the position in the array, starting from 0.
|
||||
So for a 3 drive array there will be rd0, rd1, rd2.
|
||||
These are symbolic links to the appropriate 'dev-XXX' entry.
|
||||
Thus, for example,
|
||||
|
|
|
|||
|
|
@ -79,8 +79,8 @@ Rate Estimator:
|
|||
|
||||
0) Prepare an estimator attribute. Most likely this would be in user
|
||||
space. The value of this TLV should contain a tc_estimator structure.
|
||||
As usual, such a TLV nees to be 32 bit aligned and therefore the
|
||||
length needs to be appropriately set etc. The estimator interval
|
||||
As usual, such a TLV needs to be 32 bit aligned and therefore the
|
||||
length needs to be appropriately set, etc. The estimator interval
|
||||
and ewma log need to be converted to the appropriate values.
|
||||
tc_estimator.c::tc_setup_estimator() is advisable to be used as the
|
||||
conversion routine. It does a few clever things. It takes a time
|
||||
|
|
|
|||
|
|
@ -278,7 +278,7 @@ an i386 kernel's memory size is limited to 1GiB.
|
|||
All memory allocations are not freed until the socket is closed. The memory
|
||||
allocations are done with GFP_KERNEL priority, this basically means that
|
||||
the allocation can wait and swap other process' memory in order to allocate
|
||||
the nececessary memory, so normally limits can be reached.
|
||||
the necessary memory, so normally limits can be reached.
|
||||
|
||||
Other constraints
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ 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 paramaters of modprobe below.
|
||||
line parameters of modprobe below.
|
||||
2. To activate the new parameters, either reboot your computer
|
||||
or
|
||||
unload and reload the driver.
|
||||
|
|
@ -364,9 +364,9 @@ 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 paramter if no moderation is
|
||||
applied, will lead to no action performed.
|
||||
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'
|
||||
|
|
|
|||
|
|
@ -359,13 +359,13 @@ steps you should take:
|
|||
|
||||
Eliminate some variables: try different cards, different
|
||||
computers, different cables, different ports on the switch/hub,
|
||||
different versions of the kernel or ofthe driver, etc.
|
||||
different versions of the kernel or of the driver, etc.
|
||||
|
||||
- OK, it's a driver problem.
|
||||
|
||||
You need to generate a report. Typically this is an email to the
|
||||
maintainer and/or linux-net@vger.kernel.org. The maintainer's
|
||||
email address will be inthe driver source or in the MAINTAINERS file.
|
||||
email address will be in the driver source or in the MAINTAINERS file.
|
||||
|
||||
- The contents of your report will vary a lot depending upon the
|
||||
problem. If it's a kernel crash then you should refer to the
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ PRODUCT COMPONENTS AND RELATED FILES
|
|||
/usr/local/wanrouter/patches/kdrivers:
|
||||
Sources of the latest WANPIPE device drivers.
|
||||
These are used to UPGRADE the linux kernel to the newest
|
||||
version if the kernel source has already been pathced with
|
||||
version if the kernel source has already been patched with
|
||||
WANPIPE drivers.
|
||||
|
||||
/usr/local/wanrouter/samples:
|
||||
|
|
@ -438,7 +438,7 @@ beta1-2.1.5 Nov 15 2000
|
|||
2.2.X kernels only
|
||||
|
||||
o Secured the driver UDP debugging calls
|
||||
- All illegal netowrk debugging calls are reported to
|
||||
- All illegal network debugging calls are reported to
|
||||
the log.
|
||||
- Defined a set of allowed commands, all other denied.
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ beta1-2.1.5 Nov 15 2000
|
|||
|
||||
o Keyboard Led Monitor/Debugger
|
||||
- A new utilty /usr/sbin/wpkbdmon uses keyboard leds
|
||||
to convey operatinal statistic information of the
|
||||
to convey operational statistic information of the
|
||||
Sangoma WANPIPE cards.
|
||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
||||
CAPS_LOCK = Tx data (On=transmitting, Off=no tx data)
|
||||
|
|
@ -470,7 +470,7 @@ beta1-2.1.5 Nov 15 2000
|
|||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
||||
compatible with libpcap libraries. Meaning, tcpdump, snort,
|
||||
ethereal, and all other packet sniffers and debuggers work on
|
||||
all WANPIPE netowrk interfaces.
|
||||
all WANPIPE network interfaces.
|
||||
- Set the network interface encoding type to ARPHRD_PPP.
|
||||
This tell the sniffers that data obtained from the
|
||||
network interface is in pure IP format.
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
|
|||
still frozen when the device is being closed).
|
||||
|
||||
Currently it is assumed that the userland utilities reading/writing the
|
||||
snapshot image from/to the kernel will use a swap parition, called the resume
|
||||
snapshot image from/to the kernel will use a swap partition, called the resume
|
||||
partition, as storage space. However, this is not really required, as they
|
||||
can use, for example, a special (blank) suspend partition or a file on a partition
|
||||
that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and mounted afterwards.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ problem for S1 standby, because hardware should retain its state over
|
|||
that.
|
||||
|
||||
We either have to run video BIOS during early resume, or interpret it
|
||||
using vbetool later, or maybe nothing is neccessary on particular
|
||||
using vbetool later, or maybe nothing is necessary on particular
|
||||
system because video state is preserved. Unfortunately different
|
||||
methods work on different systems, and no known method suits all of
|
||||
them.
|
||||
|
|
|
|||
|
|
@ -630,12 +630,11 @@ like address space bits, you'll have to add a bus translator to the
|
|||
prom_parse.c file of the recent kernels for your bus type.
|
||||
|
||||
The "reg" property only defines addresses and sizes (if #size-cells
|
||||
is
|
||||
non-0) within a given bus. In order to translate addresses upward
|
||||
is non-0) within a given bus. In order to translate addresses upward
|
||||
(that is into parent bus addresses, and possibly into cpu physical
|
||||
addresses), all busses must contain a "ranges" property. If the
|
||||
"ranges" property is missing at a given level, it's assumed that
|
||||
translation isn't possible. The format of the "ranges" proprety for a
|
||||
translation isn't possible. The format of the "ranges" property for a
|
||||
bus is a list of:
|
||||
|
||||
bus address, parent bus address, size
|
||||
|
|
|
|||
|
|
@ -366,8 +366,8 @@ Register Usage & Stackframes on Linux for s/390 & z/Architecture
|
|||
Overview:
|
||||
---------
|
||||
This is the code that gcc produces at the top & the bottom of
|
||||
each function, it usually is fairly consistent & similar from
|
||||
function to function & if you know its layout you can probalby
|
||||
each function. It usually is fairly consistent & similar from
|
||||
function to function & if you know its layout you can probably
|
||||
make some headway in finding the ultimate cause of a problem
|
||||
after a crash without a source level debugger.
|
||||
|
||||
|
|
@ -1703,7 +1703,7 @@ concentrate on data processing.
|
|||
IOP's can use one or more links ( known as channel paths ) to talk to each
|
||||
IO device. It first checks for path availability & chooses an available one,
|
||||
then starts ( & sometimes terminates IO ).
|
||||
There are two types of channel path ESCON & the Paralell IO interface.
|
||||
There are two types of channel path: ESCON & the Parallel IO interface.
|
||||
|
||||
IO devices are attached to control units, control units provide the
|
||||
logic to interface the channel paths & channel path IO protocols to
|
||||
|
|
@ -1742,11 +1742,11 @@ controllers or a control unit which connects to 1000 3270 terminals ).
|
|||
|
||||
The 390 IO systems come in 2 flavours the current 390 machines support both
|
||||
|
||||
The Older 360 & 370 Interface,sometimes called the paralell I/O interface,
|
||||
The Older 360 & 370 Interface,sometimes called the Parallel I/O interface,
|
||||
sometimes called Bus-and Tag & sometimes Original Equipment Manufacturers
|
||||
Interface (OEMI).
|
||||
|
||||
This byte wide paralell channel path/bus has parity & data on the "Bus" cable
|
||||
This byte wide Parallel channel path/bus has parity & data on the "Bus" cable
|
||||
& control lines on the "Tag" cable. These can operate in byte multiplex mode for
|
||||
sharing between several slow devices or burst mode & monopolize the channel for the
|
||||
whole burst. Upto 256 devices can be addressed on one of these cables. These cables are
|
||||
|
|
@ -1776,7 +1776,7 @@ Consoles 3270 & 3215 ( a teletype emulated under linux for a line mode console )
|
|||
DASD's direct access storage devices ( otherwise known as hard disks ).
|
||||
Tape Drives.
|
||||
CTC ( Channel to Channel Adapters ),
|
||||
ESCON or Paralell Cables used as a very high speed serial link
|
||||
ESCON or Parallel Cables used as a very high speed serial link
|
||||
between 2 machines. We use 2 cables under linux to do a bi-directional serial link.
|
||||
|
||||
|
||||
|
|
@ -1802,8 +1802,8 @@ OSA 7C09 ON OSA 7C09 SUBCHANNEL = 0001
|
|||
OSA 7C14 ON OSA 7C14 SUBCHANNEL = 0002
|
||||
OSA 7C15 ON OSA 7C15 SUBCHANNEL = 0003
|
||||
|
||||
If you have a guest with certain priviliges you may be able to see devices
|
||||
which don't belong to you to avoid this do add the option V.
|
||||
If you have a guest with certain privileges you may be able to see devices
|
||||
which don't belong to you. To avoid this, add the option V.
|
||||
e.g.
|
||||
Q V OSA
|
||||
|
||||
|
|
|
|||
|
|
@ -177,11 +177,11 @@ This routine returns the characteristics for the device specified.
|
|||
The function is meant to be called with an irq handler in place; that is,
|
||||
at earliest during set_online() processing.
|
||||
|
||||
While the request is procesed synchronously, the device interrupt
|
||||
While the request is processed synchronously, the device interrupt
|
||||
handler is called for final ending status. In case of error situations the
|
||||
interrupt handler may recover appropriately. The device irq handler can
|
||||
recognize the corresponding interrupts by the interruption parameter be
|
||||
0x00524443.The ccw_device must not be locked prior to calling read_dev_chars().
|
||||
0x00524443. The ccw_device must not be locked prior to calling read_dev_chars().
|
||||
|
||||
The function may be called enabled or disabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -61,9 +61,9 @@ Example: z990 crypto instruction for SHA1 algorithm is available
|
|||
-> when the sha1 algorithm is requested through the crypto API
|
||||
(which has a module autoloader) the z990 module will be loaded.
|
||||
|
||||
TBD: a userspace module probin mechanism
|
||||
TBD: a userspace module probing mechanism
|
||||
something like 'probe sha1 sha1_z990 sha1' in modprobe.conf
|
||||
-> try module sha1_z990, if it fails to load load standard module sha1
|
||||
-> try module sha1_z990, if it fails to load standard module sha1
|
||||
the 'probe' statement is currently not supported in modprobe.conf
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -83,8 +83,8 @@ Example:
|
|||
It is also possible to deactivate the debug feature globally for every
|
||||
debug log. You can change the behavior using 2 sysctl parameters in
|
||||
/proc/sys/s390dbf:
|
||||
There are currently 2 possible triggers, which stop the debug feature
|
||||
globally. The first possbility is to use the "debug_active" sysctl. If
|
||||
There are currently 2 possible triggers, which stop the debug feature
|
||||
globally. The first possibility is to use the "debug_active" sysctl. If
|
||||
set to 1 the debug feature is running. If "debug_active" is set to 0 the
|
||||
debug feature is turned off.
|
||||
The second trigger which stops the debug feature is an kernel oops.
|
||||
|
|
|
|||
|
|
@ -59,10 +59,10 @@ $ emacs Makefile
|
|||
...
|
||||
$ make
|
||||
|
||||
[5] Copy nsp_cs.o to suitable plase, like /lib/modules/<Kernel version>/pcmcia/ .
|
||||
[5] Copy nsp_cs.ko to suitable place, like /lib/modules/<Kernel version>/pcmcia/ .
|
||||
|
||||
[6] Add these lines to /etc/pcmcia/config .
|
||||
If you yse pcmcia-cs-3.1.8 or later, we can use "nsp_cs.conf" file.
|
||||
If you use pcmcia-cs-3.1.8 or later, we can use "nsp_cs.conf" file.
|
||||
So, you don't need to edit file. Just copy to /etc/pcmcia/ .
|
||||
|
||||
-------------------------------------
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ The following information is available in this file:
|
|||
- Add support for scsi_report_device_reset() found in
|
||||
2.5.X kernels.
|
||||
- Add 7901B support.
|
||||
- Simplify handling of the packtized lun Rev A workaround.
|
||||
- Simplify handling of the packetized lun Rev A workaround.
|
||||
- Correct and simplify handling of the ignore wide residue
|
||||
message. The previous code would fail to report a residual
|
||||
if the transaction data length was even and we received
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Parameters
|
|||
----------
|
||||
The driver uses the settings from the EEPROM set in the SCSI BIOS
|
||||
setup. If there is no EEPROM, the driver uses default values.
|
||||
Both can be overriden by command line parameters (module or kernel
|
||||
Both can be overridden by command line parameters (module or kernel
|
||||
parameters).
|
||||
|
||||
The following parameters are available:
|
||||
|
|
|
|||
|
|
@ -1086,7 +1086,7 @@
|
|||
|
||||
Q: "Reset SCSI-devices at boottime" halts the system at boottime, why?
|
||||
A: This is only tested with the IBM SCSI Adapter w/cache. It is not
|
||||
yet prooved to run on other adapters, however you may be lucky.
|
||||
yet proven to run on other adapters, however you may be lucky.
|
||||
In version 3.1d this has been hugely improved and should work better,
|
||||
now. Normally you really won't need to activate this flag in the
|
||||
kernel configuration, as all post 1989 SCSI-devices should accept
|
||||
|
|
|
|||
|
|
@ -631,8 +631,8 @@ string variable using 'insmod'.
|
|||
|
||||
A boot setup command for the ncr53c8xx (sym53c8xx) driver begins with the
|
||||
driver name "ncr53c8xx="(sym53c8xx). The kernel syntax parser then expects
|
||||
an optionnal list of integers separated with comma followed by an optional
|
||||
list of comma-separated strings. Example of boot setup command under lilo
|
||||
an optional list of integers separated with comma followed by an optional
|
||||
list of comma-separated strings. Example of boot setup command under lilo
|
||||
prompt:
|
||||
|
||||
lilo: linux root=/dev/hda2 ncr53c8xx=tags:4,sync:10,debug:0x200
|
||||
|
|
@ -899,7 +899,7 @@ boot setup can be:
|
|||
ncr53c8xx=safe:y,mpar:y
|
||||
ncr53c8xx=safe:y
|
||||
|
||||
My personnal system works flawlessly with the following equivalent setup:
|
||||
My personal system works flawlessly with the following equivalent setup:
|
||||
|
||||
ncr53c8xx=mpar:y,spar:y,disc:y,specf:1,fsn:n,ultra:2,fsn:n,revprob:n,verb:1\
|
||||
tags:32,sync:12,debug:0,burst:7,led:1,wide:1,settle:2,diff:0,irqm:0
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ changers. But it allows to handle nearly all possible cases. It knows
|
|||
media transport - this one shuffles around the media, i.e. the
|
||||
transport arm. Also known as "picker".
|
||||
storage - a slot which can hold a media.
|
||||
import/export - the same as above, but is accessable from outside,
|
||||
import/export - the same as above, but is accessible from outside,
|
||||
i.e. there the operator (you !) can use this to
|
||||
fill in and remove media from the changer.
|
||||
Sometimes named "mailslot".
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ in alsa-lib. For example, you can play a WAV file with 6 channels like
|
|||
|
||||
% aplay -Dsurround51 sixchannels.wav
|
||||
|
||||
For programmin the 4/6 channel playback, you need to specify the PCM
|
||||
For programming the 4/6 channel playback, you need to specify the PCM
|
||||
channels as you like and set the format S16LE. For example, for playback
|
||||
with 4 channels,
|
||||
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ the bits necessary to run your device. The most commonly
|
|||
used members of this structure, and their typical usage,
|
||||
will be detailed below.
|
||||
|
||||
Here is a piece of skeleton code for perofming a device
|
||||
probe in an SBUS driverunder Linux:
|
||||
Here is a piece of skeleton code for performing a device
|
||||
probe in an SBUS driver under Linux:
|
||||
|
||||
static int __devinit mydevice_probe_one(struct sbus_dev *sdev)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -2031,7 +2031,7 @@
|
|||
there are multiple COWs associated with a backing file, a -d merge of
|
||||
one of them will invalidate all of the others. However, it is
|
||||
convenient if you're short of disk space, and it should also be
|
||||
noticably faster than a non-destructive merge.
|
||||
noticeably faster than a non-destructive merge.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ Digi AccelePort Driver
|
|||
work under SMP with the uhci driver.
|
||||
|
||||
The driver is generally working, though we still have a few more ioctls
|
||||
to implement and final testing and debugging to do. The paralled port
|
||||
to implement and final testing and debugging to do. The parallel port
|
||||
on the USB 2 is supported as a serial to parallel converter; in other
|
||||
words, it appears as another USB serial port on Linux, even though
|
||||
physically it is really a parallel port. The Digi Acceleport USB 8
|
||||
|
|
|
|||
|
|
@ -280,7 +280,7 @@ Param[0]
|
|||
Param[1]
|
||||
Unknown, but leaving this to 0 seems to work best. Indications are that
|
||||
this might have to do with USB support, although passing anything but 0
|
||||
onl breaks things.
|
||||
only breaks things.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Index
|
|||
5. Supported devices
|
||||
6. Module dependencies
|
||||
7. Module loading
|
||||
8. Module paramaters
|
||||
8. Module parameters
|
||||
9. Contact information
|
||||
10. Credits
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue