mirror of
https://github.com/armbian/linux-cix.git
synced 2026-01-06 12:30:45 -08:00
Merge branch 'linux-2.6' into for-2.6.22
This commit is contained in:
Paul Mackerras
2
.mailmap
2
.mailmap
@@ -67,6 +67,8 @@ Koushik <raghavendra.koushik@neterion.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Michael Buesch <mb@bu3sch.de>
|
||||
Michael Buesch <mbuesch@freenet.de>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Mitesh shah <mshah@teja.com>
|
||||
Morten Welinder <terra@gnome.org>
|
||||
|
||||
22
CREDITS
22
CREDITS
@@ -317,6 +317,12 @@ S: 2322 37th Ave SW
|
||||
S: Seattle, Washington 98126-2010
|
||||
S: USA
|
||||
|
||||
N: Johannes Berg
|
||||
E: johannes@sipsolutions.net
|
||||
W: http://johannes.sipsolutions.net/
|
||||
P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5
|
||||
D: powerpc & 802.11 hacker
|
||||
|
||||
N: Stephen R. van den Berg (AKA BuGless)
|
||||
E: berg@pool.informatik.rwth-aachen.de
|
||||
D: General kernel, gcc, and libc hacker
|
||||
@@ -2286,14 +2292,14 @@ S: D-90453 Nuernberg
|
||||
S: Germany
|
||||
|
||||
N: Arnaldo Carvalho de Melo
|
||||
E: acme@mandriva.com
|
||||
E: acme@ghostprotocols.net
|
||||
E: arnaldo.melo@gmail.com
|
||||
E: acme@redhat.com
|
||||
W: http://oops.ghostprotocols.net:81/blog/
|
||||
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
||||
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
||||
S: Mandriva
|
||||
S: R. Tocantins, 89 - Cristo Rei
|
||||
S: 80050-430 - Curitiba - Paraná
|
||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||
S: 80240-060 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Karsten Merker
|
||||
@@ -3295,6 +3301,14 @@ S: 12725 SW Millikan Way, Suite 400
|
||||
S: Beaverton, Oregon 97005
|
||||
S: USA
|
||||
|
||||
N: Li Yang
|
||||
E: leoli@freescale.com
|
||||
D: Freescale Highspeed USB device driver
|
||||
D: Freescale QE SoC support and Ethernet driver
|
||||
S: B-1206 Jingmao Guojigongyu
|
||||
S: 16 Baliqiao Nanjie, Beijing 101100
|
||||
S: People's Repulic of China
|
||||
|
||||
N: Marcelo Tosatti
|
||||
E: marcelo@kvack.org
|
||||
D: v2.4 kernel maintainer
|
||||
|
||||
41
Documentation/ABI/testing/sysfs-bus-usb
Normal file
41
Documentation/ABI/testing/sysfs-bus-usb
Normal file
@@ -0,0 +1,41 @@
|
||||
What: /sys/bus/usb/devices/.../power/autosuspend
|
||||
Date: March 2007
|
||||
KernelVersion: 2.6.21
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
Each USB device directory will contain a file named
|
||||
power/autosuspend. This file holds the time (in seconds)
|
||||
the device must be idle before it will be autosuspended.
|
||||
0 means the device will be autosuspended as soon as
|
||||
possible. Negative values will prevent the device from
|
||||
being autosuspended at all, and writing a negative value
|
||||
will resume the device if it is already suspended.
|
||||
|
||||
The autosuspend delay for newly-created devices is set to
|
||||
the value of the usbcore.autosuspend module parameter.
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/level
|
||||
Date: March 2007
|
||||
KernelVersion: 2.6.21
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
Each USB device directory will contain a file named
|
||||
power/level. This file holds a power-level setting for
|
||||
the device, one of "on", "auto", or "suspend".
|
||||
|
||||
"on" means that the device is not allowed to autosuspend,
|
||||
although normal suspends for system sleep will still
|
||||
be honored. "auto" means the device will autosuspend
|
||||
and autoresume in the usual manner, according to the
|
||||
capabilities of its driver. "suspend" means the device
|
||||
is forced into a suspended state and it will not autoresume
|
||||
in response to I/O requests. However remote-wakeup requests
|
||||
from the device may still be enabled (the remote-wakeup
|
||||
setting is controlled separately by the power/wakeup
|
||||
attribute).
|
||||
|
||||
During normal use, devices should be left in the "auto"
|
||||
level. The other levels are meant for administrative uses.
|
||||
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.
|
||||
@@ -6,6 +6,18 @@ be removed from this file.
|
||||
|
||||
---------------------------
|
||||
|
||||
What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP
|
||||
When: October 2007
|
||||
Why: Broken attempt to set MPEG compression parameters. These ioctls are
|
||||
not able to implement the wide variety of parameters that can be set
|
||||
by hardware MPEG encoders. A new MPEG control mechanism was created
|
||||
in kernel 2.6.18 that replaces these ioctls. See the V4L2 specification
|
||||
(section 1.9: Extended controls) for more information on this topic.
|
||||
Who: Hans Verkuil <hverkuil@xs4all.nl> and
|
||||
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /sys/devices/.../power/state
|
||||
dev->power.power_state
|
||||
dpm_runtime_{suspend,resume)()
|
||||
@@ -134,15 +146,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: mount/umount uevents
|
||||
When: February 2007
|
||||
Why: These events are not correct, and do not properly let userspace know
|
||||
when a file system has been mounted or unmounted. Userspace should
|
||||
poll the /proc/mounts file instead to detect this properly.
|
||||
Who: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: USB driver API moves to EXPORT_SYMBOL_GPL
|
||||
When: February 2008
|
||||
Files: include/linux/usb.h, drivers/usb/core/driver.c
|
||||
@@ -211,15 +214,6 @@ Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: IPv4 only connection tracking/NAT/helpers
|
||||
When: 2.6.22
|
||||
Why: The new layer 3 independant connection tracking replaces the old
|
||||
IPv4 only version. After some stabilization of the new code the
|
||||
old one will be removed.
|
||||
Who: Patrick McHardy <kaber@trash.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
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
|
||||
@@ -294,18 +288,6 @@ Who: Richard Purdie <rpurdie@rpsys.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Wireless extensions over netlink (CONFIG_NET_WIRELESS_RTNETLINK)
|
||||
When: with the merge of wireless-dev, 2.6.22 or later
|
||||
Why: The option/code is
|
||||
* not enabled on most kernels
|
||||
* not required by any userspace tools (except an experimental one,
|
||||
and even there only for some parts, others use ioctl)
|
||||
* pointless since wext is no longer evolving and the ioctl
|
||||
interface needs to be kept
|
||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i8xx_tco watchdog driver
|
||||
When: in 2.6.22
|
||||
Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt
|
||||
@@ -313,3 +295,22 @@ Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt
|
||||
Who: Wim Van Sebroeck <wim@iguana.be>
|
||||
|
||||
---------------------------
|
||||
|
||||
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>
|
||||
|
||||
---------------------------
|
||||
|
||||
@@ -1,31 +1,82 @@
|
||||
====================
|
||||
kAFS: AFS FILESYSTEM
|
||||
====================
|
||||
|
||||
ABOUT
|
||||
Contents:
|
||||
|
||||
- Overview.
|
||||
- Usage.
|
||||
- Mountpoints.
|
||||
- Proc filesystem.
|
||||
- The cell database.
|
||||
- Security.
|
||||
- Examples.
|
||||
|
||||
|
||||
========
|
||||
OVERVIEW
|
||||
========
|
||||
|
||||
This filesystem provides a fairly simple secure AFS filesystem driver. It is
|
||||
under development and does not yet provide the full feature set. The features
|
||||
it does support include:
|
||||
|
||||
(*) Security (currently only AFS kaserver and KerberosIV tickets).
|
||||
|
||||
(*) File reading.
|
||||
|
||||
(*) Automounting.
|
||||
|
||||
It does not yet support the following AFS features:
|
||||
|
||||
(*) Write support.
|
||||
|
||||
(*) Local caching.
|
||||
|
||||
(*) pioctl() system call.
|
||||
|
||||
|
||||
===========
|
||||
COMPILATION
|
||||
===========
|
||||
|
||||
The filesystem should be enabled by turning on the kernel configuration
|
||||
options:
|
||||
|
||||
CONFIG_AF_RXRPC - The RxRPC protocol transport
|
||||
CONFIG_RXKAD - The RxRPC Kerberos security handler
|
||||
CONFIG_AFS - The AFS filesystem
|
||||
|
||||
Additionally, the following can be turned on to aid debugging:
|
||||
|
||||
CONFIG_AF_RXRPC_DEBUG - Permit AF_RXRPC debugging to be enabled
|
||||
CONFIG_AFS_DEBUG - Permit AFS debugging to be enabled
|
||||
|
||||
They permit the debugging messages to be turned on dynamically by manipulating
|
||||
the masks in the following files:
|
||||
|
||||
/sys/module/af_rxrpc/parameters/debug
|
||||
/sys/module/afs/parameters/debug
|
||||
|
||||
|
||||
=====
|
||||
|
||||
This filesystem provides a fairly simple AFS filesystem driver. It is under
|
||||
development and only provides very basic facilities. It does not yet support
|
||||
the following AFS features:
|
||||
|
||||
(*) Write support.
|
||||
(*) Communications security.
|
||||
(*) Local caching.
|
||||
(*) pioctl() system call.
|
||||
(*) Automatic mounting of embedded mountpoints.
|
||||
|
||||
|
||||
USAGE
|
||||
=====
|
||||
|
||||
When inserting the driver modules the root cell must be specified along with a
|
||||
list of volume location server IP addresses:
|
||||
|
||||
insmod rxrpc.o
|
||||
insmod af_rxrpc.o
|
||||
insmod rxkad.o
|
||||
insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
|
||||
The first module is a driver for the RxRPC remote operation protocol, and the
|
||||
second is the actual filesystem driver for the AFS filesystem.
|
||||
The first module is the AF_RXRPC network protocol driver. This provides the
|
||||
RxRPC remote operation protocol and may also be accessed from userspace. See:
|
||||
|
||||
Documentation/networking/rxrpc.txt
|
||||
|
||||
The second module is the kerberos RxRPC security driver, and the third module
|
||||
is the actual filesystem driver for the AFS filesystem.
|
||||
|
||||
Once the module has been loaded, more modules can be added by the following
|
||||
procedure:
|
||||
@@ -33,7 +84,7 @@ procedure:
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
|
||||
|
||||
Where the parameters to the "add" command are the name of a cell and a list of
|
||||
volume location servers within that cell.
|
||||
volume location servers within that cell, with the latter separated by colons.
|
||||
|
||||
Filesystems can be mounted anywhere by commands similar to the following:
|
||||
|
||||
@@ -42,11 +93,6 @@ Filesystems can be mounted anywhere by commands similar to the following:
|
||||
mount -t afs "#root.afs." /afs
|
||||
mount -t afs "#root.cell." /afs/cambridge
|
||||
|
||||
NB: When using this on Linux 2.4, the mount command has to be different,
|
||||
since the filesystem doesn't have access to the device name argument:
|
||||
|
||||
mount -t afs none /afs -ovol="#root.afs."
|
||||
|
||||
Where the initial character is either a hash or a percent symbol depending on
|
||||
whether you definitely want a R/W volume (hash) or whether you'd prefer a R/O
|
||||
volume, but are willing to use a R/W volume instead (percent).
|
||||
@@ -60,55 +106,66 @@ named volume will be looked up in the cell specified during insmod.
|
||||
Additional cells can be added through /proc (see later section).
|
||||
|
||||
|
||||
===========
|
||||
MOUNTPOINTS
|
||||
===========
|
||||
|
||||
AFS has a concept of mountpoints. These are specially formatted symbolic links
|
||||
(of the same form as the "device name" passed to mount). kAFS presents these
|
||||
to the user as directories that have special properties:
|
||||
AFS has a concept of mountpoints. In AFS terms, these are specially formatted
|
||||
symbolic links (of the same form as the "device name" passed to mount). kAFS
|
||||
presents these to the user as directories that have a follow-link capability
|
||||
(ie: symbolic link semantics). If anyone attempts to access them, they will
|
||||
automatically cause the target volume to be mounted (if possible) on that site.
|
||||
|
||||
(*) They cannot be listed. Running a program like "ls" on them will incur an
|
||||
EREMOTE error (Object is remote).
|
||||
Automatically mounted filesystems will be automatically unmounted approximately
|
||||
twenty minutes after they were last used. Alternatively they can be unmounted
|
||||
directly with the umount() system call.
|
||||
|
||||
(*) Other objects can't be looked up inside of them. This also incurs an
|
||||
EREMOTE error.
|
||||
Manually unmounting an AFS volume will cause any idle submounts upon it to be
|
||||
culled first. If all are culled, then the requested volume will also be
|
||||
unmounted, otherwise error EBUSY will be returned.
|
||||
|
||||
(*) They can be queried with the readlink() system call, which will return
|
||||
the name of the mountpoint to which they point. The "readlink" program
|
||||
will also work.
|
||||
This can be used by the administrator to attempt to unmount the whole AFS tree
|
||||
mounted on /afs in one go by doing:
|
||||
|
||||
(*) They can be mounted on (which symbolic links can't).
|
||||
umount /afs
|
||||
|
||||
|
||||
===============
|
||||
PROC FILESYSTEM
|
||||
===============
|
||||
|
||||
The rxrpc module creates a number of files in various places in the /proc
|
||||
filesystem:
|
||||
|
||||
(*) Firstly, some information files are made available in a directory called
|
||||
"/proc/net/rxrpc/". These list the extant transport endpoint, peer,
|
||||
connection and call records.
|
||||
|
||||
(*) Secondly, some control files are made available in a directory called
|
||||
"/proc/sys/rxrpc/". Currently, all these files can be used for is to
|
||||
turn on various levels of tracing.
|
||||
|
||||
The AFS modules creates a "/proc/fs/afs/" directory and populates it:
|
||||
|
||||
(*) A "cells" file that lists cells currently known to the afs module.
|
||||
(*) A "cells" file that lists cells currently known to the afs module and
|
||||
their usage counts:
|
||||
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cells
|
||||
USE NAME
|
||||
3 cambridge.redhat.com
|
||||
|
||||
(*) A directory per cell that contains files that list volume location
|
||||
servers, volumes, and active servers known within that cell.
|
||||
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/servers
|
||||
USE ADDR STATE
|
||||
4 172.16.18.91 0
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/vlservers
|
||||
ADDRESS
|
||||
172.16.18.91
|
||||
[root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/volumes
|
||||
USE STT VLID[0] VLID[1] VLID[2] NAME
|
||||
1 Val 20000000 20000001 20000002 root.afs
|
||||
|
||||
|
||||
=================
|
||||
THE CELL DATABASE
|
||||
=================
|
||||
|
||||
The filesystem maintains an internal database of all the cells it knows and
|
||||
the IP addresses of the volume location servers for those cells. The cell to
|
||||
which the computer belongs is added to the database when insmod is performed
|
||||
by the "rootcell=" argument.
|
||||
The filesystem maintains an internal database of all the cells it knows and the
|
||||
IP addresses of the volume location servers for those cells. The cell to which
|
||||
the system belongs is added to the database when insmod is performed by the
|
||||
"rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on
|
||||
the kernel command line.
|
||||
|
||||
Further cells can be added by commands similar to the following:
|
||||
|
||||
@@ -118,20 +175,65 @@ Further cells can be added by commands similar to the following:
|
||||
No other cell database operations are available at this time.
|
||||
|
||||
|
||||
========
|
||||
SECURITY
|
||||
========
|
||||
|
||||
Secure operations are initiated by acquiring a key using the klog program. A
|
||||
very primitive klog program is available at:
|
||||
|
||||
http://people.redhat.com/~dhowells/rxrpc/klog.c
|
||||
|
||||
This should be compiled by:
|
||||
|
||||
make klog LDLIBS="-lcrypto -lcrypt -lkrb4 -lkeyutils"
|
||||
|
||||
And then run as:
|
||||
|
||||
./klog
|
||||
|
||||
Assuming it's successful, this adds a key of type RxRPC, named for the service
|
||||
and cell, eg: "afs@<cellname>". This can be viewed with the keyctl program or
|
||||
by cat'ing /proc/keys:
|
||||
|
||||
[root@andromeda ~]# keyctl show
|
||||
Session Keyring
|
||||
-3 --alswrv 0 0 keyring: _ses.3268
|
||||
2 --alswrv 0 0 \_ keyring: _uid.0
|
||||
111416553 --als--v 0 0 \_ rxrpc: afs@CAMBRIDGE.REDHAT.COM
|
||||
|
||||
Currently the username, realm, password and proposed ticket lifetime are
|
||||
compiled in to the program.
|
||||
|
||||
It is not required to acquire a key before using AFS facilities, but if one is
|
||||
not acquired then all operations will be governed by the anonymous user parts
|
||||
of the ACLs.
|
||||
|
||||
If a key is acquired, then all AFS operations, including mounts and automounts,
|
||||
made by a possessor of that key will be secured with that key.
|
||||
|
||||
If a file is opened with a particular key and then the file descriptor is
|
||||
passed to a process that doesn't have that key (perhaps over an AF_UNIX
|
||||
socket), then the operations on the file will be made with key that was used to
|
||||
open the file.
|
||||
|
||||
|
||||
========
|
||||
EXAMPLES
|
||||
========
|
||||
|
||||
Here's what I use to test this. Some of the names and IP addresses are local
|
||||
to my internal DNS. My "root.afs" partition has a mount point within it for
|
||||
Here's what I use to test this. Some of the names and IP addresses are local
|
||||
to my internal DNS. My "root.afs" partition has a mount point within it for
|
||||
some public volumes volumes.
|
||||
|
||||
insmod -S /tmp/rxrpc.o
|
||||
insmod -S /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
|
||||
insmod /tmp/rxrpc.o
|
||||
insmod /tmp/rxkad.o
|
||||
insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91
|
||||
|
||||
mount -t afs \%root.afs. /afs
|
||||
mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/
|
||||
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
|
||||
echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
|
||||
mount -t afs "#grand.central.org:root.cell." /afs/grand.central.org/
|
||||
mount -t afs "#grand.central.org:root.archive." /afs/grand.central.org/archive
|
||||
mount -t afs "#grand.central.org:root.contrib." /afs/grand.central.org/contrib
|
||||
@@ -141,15 +243,7 @@ mount -t afs "#grand.central.org:root.service." /afs/grand.central.org/service
|
||||
mount -t afs "#grand.central.org:root.software." /afs/grand.central.org/software
|
||||
mount -t afs "#grand.central.org:root.user." /afs/grand.central.org/user
|
||||
|
||||
umount /afs/grand.central.org/user
|
||||
umount /afs/grand.central.org/software
|
||||
umount /afs/grand.central.org/service
|
||||
umount /afs/grand.central.org/project
|
||||
umount /afs/grand.central.org/doc
|
||||
umount /afs/grand.central.org/contrib
|
||||
umount /afs/grand.central.org/archive
|
||||
umount /afs/grand.central.org
|
||||
umount /afs/cambridge.redhat.com
|
||||
umount /afs
|
||||
rmmod kafs
|
||||
rmmod rxkad
|
||||
rmmod rxrpc
|
||||
|
||||
@@ -1421,6 +1421,15 @@ fewer messages that will be written. Message_burst controls when messages will
|
||||
be dropped. The default settings limit warning messages to one every five
|
||||
seconds.
|
||||
|
||||
warnings
|
||||
--------
|
||||
|
||||
This controls console messages from the networking stack that can occur because
|
||||
of problems on the network like duplicate address or bad checksums. Normally,
|
||||
this should be enabled, but if the problem persists the messages can be
|
||||
disabled.
|
||||
|
||||
|
||||
netdev_max_backlog
|
||||
------------------
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ The exact capabilities of GPIOs vary between systems. Common options:
|
||||
- Output values are writable (high=1, low=0). Some chips also have
|
||||
options about how that value is driven, so that for example only one
|
||||
value might be driven ... supporting "wire-OR" and similar schemes
|
||||
for the other value.
|
||||
for the other value (notably, "open drain" signaling).
|
||||
|
||||
- Input values are likewise readable (1, 0). Some chips support readback
|
||||
of pins configured as "output", which is very useful in such "wire-OR"
|
||||
@@ -247,6 +247,35 @@ with gpio_get_value(), for example to initialize or update driver state
|
||||
when the IRQ is edge-triggered.
|
||||
|
||||
|
||||
Emulating Open Drain Signals
|
||||
----------------------------
|
||||
Sometimes shared signals need to use "open drain" signaling, where only the
|
||||
low signal level is actually driven. (That term applies to CMOS transistors;
|
||||
"open collector" is used for TTL.) A pullup resistor causes the high signal
|
||||
level. This is sometimes called a "wire-AND"; or more practically, from the
|
||||
negative logic (low=true) perspective this is a "wire-OR".
|
||||
|
||||
One common example of an open drain signal is a shared active-low IRQ line.
|
||||
Also, bidirectional data bus signals sometimes use open drain signals.
|
||||
|
||||
Some GPIO controllers directly support open drain outputs; many don't. When
|
||||
you need open drain signaling but your hardware doesn't directly support it,
|
||||
there's a common idiom you can use to emulate it with any GPIO pin that can
|
||||
be used as either an input or an output:
|
||||
|
||||
LOW: gpio_direction_output(gpio, 0) ... this drives the signal
|
||||
and overrides the pullup.
|
||||
|
||||
HIGH: gpio_direction_input(gpio) ... this turns off the output,
|
||||
so the pullup (or some other device) controls the signal.
|
||||
|
||||
If you are "driving" the signal high but gpio_get_value(gpio) reports a low
|
||||
value (after the appropriate rise time passes), you know some other component
|
||||
is driving the shared signal low. That's not necessarily an error. As one
|
||||
common example, that's how I2C clocks are stretched: a slave that needs a
|
||||
slower clock delays the rising edge of SCK, and the I2C master adjusts its
|
||||
signaling rate accordingly.
|
||||
|
||||
|
||||
What do these conventions omit?
|
||||
===============================
|
||||
|
||||
@@ -91,6 +91,14 @@ Sending MADs
|
||||
if (ret != sizeof *mad + mad_length)
|
||||
perror("write");
|
||||
|
||||
Transaction IDs
|
||||
|
||||
Users of the umad devices can use the lower 32 bits of the
|
||||
transaction ID field (that is, the least significant half of the
|
||||
field in network byte order) in MADs being sent to match
|
||||
request/response pairs. The upper 32 bits are reserved for use by
|
||||
the kernel and will be overwritten before a MAD is sent.
|
||||
|
||||
Setting IsSM Capability Bit
|
||||
|
||||
To set the IsSM capability bit for a port, simply open the
|
||||
|
||||
@@ -1792,7 +1792,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
for newly-detected USB devices (default 2). This
|
||||
is the time required before an idle device will be
|
||||
autosuspended. Devices for which the delay is set
|
||||
to 0 won't be autosuspended at all.
|
||||
to a negative value won't be autosuspended at all.
|
||||
|
||||
usbhid.mousepoll=
|
||||
[USBHID] The interval which mice are to be polled at.
|
||||
|
||||
@@ -859,6 +859,18 @@ payload contents" for more information.
|
||||
void unregister_key_type(struct key_type *type);
|
||||
|
||||
|
||||
Under some circumstances, it may be desirable to desirable to deal with a
|
||||
bundle of keys. The facility provides access to the keyring type for managing
|
||||
such a bundle:
|
||||
|
||||
struct key_type key_type_keyring;
|
||||
|
||||
This can be used with a function such as request_key() to find a specific
|
||||
keyring in a process's keyrings. A keyring thus found can then be searched
|
||||
with keyring_search(). Note that it is not possible to use request_key() to
|
||||
search a specific keyring, so using keyrings in this way is of limited utility.
|
||||
|
||||
|
||||
===================================
|
||||
NOTES ON ACCESSING PAYLOAD CONTENTS
|
||||
===================================
|
||||
|
||||
@@ -920,40 +920,9 @@ options, you may wish to use the "max_bonds" module parameter,
|
||||
documented above.
|
||||
|
||||
To create multiple bonding devices with differing options, it
|
||||
is necessary to load the bonding driver multiple times. Note that
|
||||
current versions of the sysconfig network initialization scripts
|
||||
handle this automatically; if your distro uses these scripts, no
|
||||
special action is needed. See the section Configuring Bonding
|
||||
Devices, above, if you're not sure about your network initialization
|
||||
scripts.
|
||||
is necessary to use bonding parameters exported by sysfs, documented
|
||||
in the section below.
|
||||
|
||||
To load multiple instances of the module, it is necessary to
|
||||
specify a different name for each instance (the module loading system
|
||||
requires that every loaded module, even multiple instances of the same
|
||||
module, have a unique name). This is accomplished by supplying
|
||||
multiple sets of bonding options in /etc/modprobe.conf, for example:
|
||||
|
||||
alias bond0 bonding
|
||||
options bond0 -o bond0 mode=balance-rr miimon=100
|
||||
|
||||
alias bond1 bonding
|
||||
options bond1 -o bond1 mode=balance-alb miimon=50
|
||||
|
||||
will load the bonding module two times. The first instance is
|
||||
named "bond0" and creates the bond0 device in balance-rr mode with an
|
||||
miimon of 100. The second instance is named "bond1" and creates the
|
||||
bond1 device in balance-alb mode with an miimon of 50.
|
||||
|
||||
In some circumstances (typically with older distributions),
|
||||
the above does not work, and the second bonding instance never sees
|
||||
its options. In that case, the second options line can be substituted
|
||||
as follows:
|
||||
|
||||
install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
|
||||
mode=balance-alb miimon=50
|
||||
|
||||
This may be repeated any number of times, specifying a new and
|
||||
unique name in place of bond1 for each subsequent instance.
|
||||
|
||||
3.4 Configuring Bonding Manually via Sysfs
|
||||
------------------------------------------
|
||||
|
||||
@@ -57,6 +57,16 @@ DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
|
||||
coverage value are also acceptable. The higher the number, the more
|
||||
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
|
||||
|
||||
The following two options apply to CCID 3 exclusively and are getsockopt()-only.
|
||||
In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
|
||||
DCCP_SOCKOPT_CCID_RX_INFO
|
||||
Returns a `struct tfrc_rx_info' in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_rx_info).
|
||||
DCCP_SOCKOPT_CCID_TX_INFO
|
||||
Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_tx_info).
|
||||
|
||||
|
||||
Sysctl variables
|
||||
================
|
||||
Several DCCP default parameters can be managed by the following sysctls
|
||||
|
||||
@@ -179,11 +179,31 @@ tcp_fin_timeout - INTEGER
|
||||
because they eat maximum 1.5K of memory, but they tend
|
||||
to live longer. Cf. tcp_max_orphans.
|
||||
|
||||
tcp_frto - BOOLEAN
|
||||
tcp_frto - INTEGER
|
||||
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
|
||||
timeouts. It is particularly beneficial in wireless environments
|
||||
where packet loss is typically due to random radio interference
|
||||
rather than intermediate router congestion.
|
||||
rather than intermediate router congestion. If set to 1, basic
|
||||
version is enabled. 2 enables SACK enhanced F-RTO, which is
|
||||
EXPERIMENTAL. The basic version can be used also when SACK is
|
||||
enabled for a flow through tcp_sack sysctl.
|
||||
|
||||
tcp_frto_response - INTEGER
|
||||
When F-RTO has detected that a TCP retransmission timeout was
|
||||
spurious (i.e, the timeout would have been avoided had TCP set a
|
||||
longer retransmission timeout), TCP has several options what to do
|
||||
next. Possible values are:
|
||||
0 Rate halving based; a smooth and conservative response,
|
||||
results in halved cwnd and ssthresh after one RTT
|
||||
1 Very conservative response; not recommended because even
|
||||
though being valid, it interacts poorly with the rest of
|
||||
Linux TCP, halves cwnd and ssthresh immediately
|
||||
2 Aggressive response; undoes congestion control measures
|
||||
that are now known to be unnecessary (ignoring the
|
||||
possibility of a lost retransmission that would require
|
||||
TCP to be more cautious), cwnd and ssthresh are restored
|
||||
to the values prior timeout
|
||||
Default: 0 (rate halving based)
|
||||
|
||||
tcp_keepalive_time - INTEGER
|
||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
||||
@@ -851,6 +871,15 @@ accept_redirects - BOOLEAN
|
||||
Functional default: enabled if local forwarding is disabled.
|
||||
disabled if local forwarding is enabled.
|
||||
|
||||
accept_source_route - INTEGER
|
||||
Accept source routing (routing extension header).
|
||||
|
||||
> 0: Accept routing header.
|
||||
= 0: Accept only routing header type 2.
|
||||
< 0: Do not accept routing header.
|
||||
|
||||
Default: 0
|
||||
|
||||
autoconf - BOOLEAN
|
||||
Autoconfigure addresses using Prefix Information in Router
|
||||
Advertisements.
|
||||
@@ -986,7 +1015,12 @@ bridge-nf-call-ip6tables - BOOLEAN
|
||||
Default: 1
|
||||
|
||||
bridge-nf-filter-vlan-tagged - BOOLEAN
|
||||
1 : pass bridged vlan-tagged ARP/IP traffic to arptables/iptables.
|
||||
1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables.
|
||||
0 : disable this.
|
||||
Default: 1
|
||||
|
||||
bridge-nf-filter-pppoe-tagged - BOOLEAN
|
||||
1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
|
||||
0 : disable this.
|
||||
Default: 1
|
||||
|
||||
|
||||
859
Documentation/networking/rxrpc.txt
Normal file
859
Documentation/networking/rxrpc.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -250,7 +250,6 @@ PRODUCT COMPONENTS AND RELATED FILES
|
||||
sdladrv.h SDLA support module API definitions
|
||||
sdlasfm.h SDLA firmware module definitions
|
||||
if_wanpipe.h WANPIPE Socket definitions
|
||||
if_wanpipe_common.h WANPIPE Socket/Driver common definitions.
|
||||
sdlapci.h WANPIPE PCI definitions
|
||||
|
||||
|
||||
|
||||
@@ -1,83 +0,0 @@
|
||||
crypto-API support for z990 Message Security Assist (MSA) instructions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
AUTHOR: Thomas Spatzier (tspat@de.ibm.com)
|
||||
|
||||
|
||||
1. Introduction crypto-API
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
See Documentation/crypto/api-intro.txt for an introduction/description of the
|
||||
kernel crypto API.
|
||||
According to api-intro.txt support for z990 crypto instructions has been added
|
||||
in the algorithm api layer of the crypto API. Several files containing z990
|
||||
optimized implementations of crypto algorithms are placed in the
|
||||
arch/s390/crypto directory.
|
||||
|
||||
|
||||
2. Probing for availability of MSA
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
It should be possible to use Kernels with the z990 crypto implementations both
|
||||
on machines with MSA available and on those without MSA (pre z990 or z990
|
||||
without MSA). Therefore a simple probing mechanism has been implemented:
|
||||
In the init function of each crypto module the availability of MSA and of the
|
||||
respective crypto algorithm in particular will be tested. If the algorithm is
|
||||
available the module will load and register its algorithm with the crypto API.
|
||||
|
||||
If the respective crypto algorithm is not available, the init function will
|
||||
return -ENOSYS. In that case a fallback to the standard software implementation
|
||||
of the crypto algorithm must be taken ( -> the standard crypto modules are
|
||||
also built when compiling the kernel).
|
||||
|
||||
|
||||
3. Ensuring z990 crypto module preference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
If z990 crypto instructions are available the optimized modules should be
|
||||
preferred instead of standard modules.
|
||||
|
||||
3.1. compiled-in modules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
For compiled-in modules it has to be ensured that the z990 modules are linked
|
||||
before the standard crypto modules. Then, on system startup the init functions
|
||||
of z990 crypto modules will be called first and query for availability of z990
|
||||
crypto instructions. If instruction is available, the z990 module will register
|
||||
its crypto algorithm implementation -> the load of the standard module will fail
|
||||
since the algorithm is already registered.
|
||||
If z990 crypto instruction is not available the load of the z990 module will
|
||||
fail -> the standard module will load and register its algorithm.
|
||||
|
||||
3.2. dynamic modules
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
A system administrator has to take care of giving preference to z990 crypto
|
||||
modules. If MSA is available appropriate lines have to be added to
|
||||
/etc/modprobe.conf.
|
||||
|
||||
Example: z990 crypto instruction for SHA1 algorithm is available
|
||||
|
||||
add the following line to /etc/modprobe.conf (assuming the
|
||||
z990 crypto modules for SHA1 is called sha1_z990):
|
||||
|
||||
alias sha1 sha1_z990
|
||||
|
||||
-> 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 probing mechanism
|
||||
something like 'probe sha1 sha1_z990 sha1' in modprobe.conf
|
||||
-> try module sha1_z990, if it fails to load standard module sha1
|
||||
the 'probe' statement is currently not supported in modprobe.conf
|
||||
|
||||
|
||||
4. Currently implemented z990 crypto algorithms
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The following crypto algorithms with z990 MSA support are currently implemented.
|
||||
The name of each algorithm under which it is registered in crypto API and the
|
||||
name of the respective module is given in square brackets.
|
||||
|
||||
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
|
||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
||||
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
||||
|
||||
87
Documentation/s390/zfcpdump.txt
Normal file
87
Documentation/s390/zfcpdump.txt
Normal file
@@ -0,0 +1,87 @@
|
||||
s390 SCSI dump tool (zfcpdump)
|
||||
|
||||
System z machines (z900 or higher) provide hardware support for creating system
|
||||
dumps on SCSI disks. The dump process is initiated by booting a dump tool, which
|
||||
has to create a dump of the current (probably crashed) Linux image. In order to
|
||||
not overwrite memory of the crashed Linux with data of the dump tool, the
|
||||
hardware saves some memory plus the register sets of the boot cpu before the
|
||||
dump tool is loaded. There exists an SCLP hardware interface to obtain the saved
|
||||
memory afterwards. Currently 32 MB are saved.
|
||||
|
||||
This zfcpdump implementation consists of a Linux dump kernel together with
|
||||
a userspace dump tool, which are loaded together into the saved memory region
|
||||
below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in
|
||||
the s390-tools package) to make the device bootable. The operator of a Linux
|
||||
system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump
|
||||
resides on.
|
||||
|
||||
The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem",
|
||||
which exports memory and registers of the crashed Linux in an s390
|
||||
standalone dump format. It can be used in the same way as e.g. /dev/mem. The
|
||||
dump format defines a 4K header followed by plain uncompressed memory. The
|
||||
register sets are stored in the prefix pages of the respective cpus. To build a
|
||||
dump enabled kernel with the zcore driver, the kernel config option
|
||||
CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of
|
||||
memory, which has been saved by hardware is read by the driver via the SCLP
|
||||
hardware interface. The second part is just copied from the non overwritten real
|
||||
memory.
|
||||
|
||||
The userspace application of zfcpdump can reside e.g. in an intitramfs or an
|
||||
initrd. It reads from zcore/mem and writes the system dump to a file on a
|
||||
SCSI disk.
|
||||
|
||||
To build a zfcpdump kernel use the following settings in your kernel
|
||||
configuration:
|
||||
* CONFIG_ZFCPDUMP=y
|
||||
* Enable ZFCP driver
|
||||
* Enable SCSI driver
|
||||
* Enable ext2 and ext3 filesystems
|
||||
* Disable as many features as possible to keep the kernel small.
|
||||
E.g. network support is not needed at all.
|
||||
|
||||
To use the zfcpdump userspace application in an initramfs you have to do the
|
||||
following:
|
||||
|
||||
* Copy the zfcpdump executable somewhere into your Linux tree.
|
||||
E.g. to "arch/s390/boot/zfcpdump. If you do not want to include
|
||||
shared libraries, compile the tool with the "-static" gcc option.
|
||||
* If you want to include e2fsck, add it to your source tree, too. The zfcpdump
|
||||
application attempts to start /sbin/e2fsck from the ramdisk.
|
||||
* Use an initramfs config file like the following:
|
||||
|
||||
dir /dev 755 0 0
|
||||
nod /dev/console 644 0 0 c 5 1
|
||||
nod /dev/null 644 0 0 c 1 3
|
||||
nod /dev/sda1 644 0 0 b 8 1
|
||||
nod /dev/sda2 644 0 0 b 8 2
|
||||
nod /dev/sda3 644 0 0 b 8 3
|
||||
nod /dev/sda4 644 0 0 b 8 4
|
||||
nod /dev/sda5 644 0 0 b 8 5
|
||||
nod /dev/sda6 644 0 0 b 8 6
|
||||
nod /dev/sda7 644 0 0 b 8 7
|
||||
nod /dev/sda8 644 0 0 b 8 8
|
||||
nod /dev/sda9 644 0 0 b 8 9
|
||||
nod /dev/sda10 644 0 0 b 8 10
|
||||
nod /dev/sda11 644 0 0 b 8 11
|
||||
nod /dev/sda12 644 0 0 b 8 12
|
||||
nod /dev/sda13 644 0 0 b 8 13
|
||||
nod /dev/sda14 644 0 0 b 8 14
|
||||
nod /dev/sda15 644 0 0 b 8 15
|
||||
file /init arch/s390/boot/zfcpdump 755 0 0
|
||||
file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0
|
||||
dir /proc 755 0 0
|
||||
dir /sys 755 0 0
|
||||
dir /mnt 755 0 0
|
||||
dir /sbin 755 0 0
|
||||
|
||||
* Issue "make image" to build the zfcpdump image with initramfs.
|
||||
|
||||
In a Linux distribution the zfcpdump enabled kernel image must be copied to
|
||||
/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the
|
||||
dump kernel when preparing a SCSI dump disk.
|
||||
|
||||
If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd".
|
||||
|
||||
For more information on how to use zfcpdump refer to the s390 'Using the Dump
|
||||
Tools book', which is available from
|
||||
http://www.ibm.com/developerworks/linux/linux390.
|
||||
@@ -16,7 +16,7 @@ situation as with tcpdump.
|
||||
|
||||
Unlike the packet socket, usbmon has an interface which provides traces
|
||||
in a text format. This is used for two purposes. First, it serves as a
|
||||
common trace exchange format for tools while most sophisticated formats
|
||||
common trace exchange format for tools while more sophisticated formats
|
||||
are finalized. Second, humans can read it in case tools are not available.
|
||||
|
||||
To collect a raw text trace, execute following steps.
|
||||
@@ -34,7 +34,7 @@ if usbmon is built into the kernel.
|
||||
Verify that bus sockets are present.
|
||||
|
||||
# ls /sys/kernel/debug/usbmon
|
||||
1s 1t 2s 2t 3s 3t 4s 4t
|
||||
1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
|
||||
#
|
||||
|
||||
2. Find which bus connects to the desired device
|
||||
@@ -54,7 +54,7 @@ Bus=03 means it's bus 3.
|
||||
|
||||
3. Start 'cat'
|
||||
|
||||
# cat /sys/kernel/debug/usbmon/3t > /tmp/1.mon.out
|
||||
# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out
|
||||
|
||||
This process will be reading until killed. Naturally, the output can be
|
||||
redirected to a desirable location. This is preferred, because it is going
|
||||
@@ -75,46 +75,80 @@ that the file size is not excessive for your favourite editor.
|
||||
|
||||
* Raw text data format
|
||||
|
||||
The '1t' type data consists of a stream of events, such as URB submission,
|
||||
Two formats are supported currently: the original, or '1t' format, and
|
||||
the '1u' format. The '1t' format is deprecated in kernel 2.6.21. The '1u'
|
||||
format adds a few fields, such as ISO frame descriptors, interval, etc.
|
||||
It produces slightly longer lines, but otherwise is a perfect superset
|
||||
of '1t' format.
|
||||
|
||||
If it is desired to recognize one from the other in a program, look at the
|
||||
"address" word (see below), where '1u' format adds a bus number. If 2 colons
|
||||
are present, it's the '1t' format, otherwise '1u'.
|
||||
|
||||
Any text format data consists of a stream of events, such as URB submission,
|
||||
URB callback, submission error. Every event is a text line, which consists
|
||||
of whitespace separated words. The number or position of words may depend
|
||||
on the event type, but there is a set of words, common for all types.
|
||||
|
||||
Here is the list of words, from left to right:
|
||||
|
||||
- URB Tag. This is used to identify URBs is normally a kernel mode address
|
||||
of the URB structure in hexadecimal.
|
||||
|
||||
- Timestamp in microseconds, a decimal number. The timestamp's resolution
|
||||
depends on available clock, and so it can be much worse than a microsecond
|
||||
(if the implementation uses jiffies, for example).
|
||||
|
||||
- Event Type. This type refers to the format of the event, not URB type.
|
||||
Available types are: S - submission, C - callback, E - submission error.
|
||||
- "Pipe". The pipe concept is deprecated. This is a composite word, used to
|
||||
be derived from information in pipes. It consists of three fields, separated
|
||||
by colons: URB type and direction, Device address, Endpoint number.
|
||||
|
||||
- "Address" word (formerly a "pipe"). It consists of four fields, separated by
|
||||
colons: URB type and direction, Bus number, Device address, Endpoint number.
|
||||
Type and direction are encoded with two bytes in the following manner:
|
||||
Ci Co Control input and output
|
||||
Zi Zo Isochronous input and output
|
||||
Ii Io Interrupt input and output
|
||||
Bi Bo Bulk input and output
|
||||
Device address and Endpoint number are 3-digit and 2-digit (respectively)
|
||||
decimal numbers, with leading zeroes.
|
||||
- URB Status. In most cases, this field contains a number, sometimes negative,
|
||||
which represents a "status" field of the URB. This field makes no sense for
|
||||
submissions, but is present anyway to help scripts with parsing. When an
|
||||
error occurs, the field contains the error code. In case of a submission of
|
||||
a Control packet, this field contains a Setup Tag instead of an error code.
|
||||
It is easy to tell whether the Setup Tag is present because it is never a
|
||||
number. Thus if scripts find a number in this field, they proceed to read
|
||||
Data Length. If they find something else, like a letter, they read the setup
|
||||
packet before reading the Data Length.
|
||||
Bus number, Device address, and Endpoint are decimal numbers, but they may
|
||||
have leading zeros, for the sake of human readers.
|
||||
|
||||
- URB Status word. This is either a letter, or several numbers separated
|
||||
by colons: URB status, interval, start frame, and error count. Unlike the
|
||||
"address" word, all fields save the status are optional. Interval is printed
|
||||
only for interrupt and isochronous URBs. Start frame is printed only for
|
||||
isochronous URBs. Error count is printed only for isochronous callback
|
||||
events.
|
||||
|
||||
The status field is a decimal number, sometimes negative, which represents
|
||||
a "status" field of the URB. This field makes no sense for submissions, but
|
||||
is present anyway to help scripts with parsing. When an error occurs, the
|
||||
field contains the error code.
|
||||
|
||||
In case of a submission of a Control packet, this field contains a Setup Tag
|
||||
instead of an group of numbers. It is easy to tell whether the Setup Tag is
|
||||
present because it is never a number. Thus if scripts find a set of numbers
|
||||
in this word, they proceed to read Data Length (except for isochronous URBs).
|
||||
If they find something else, like a letter, they read the setup packet before
|
||||
reading the Data Length or isochronous descriptors.
|
||||
|
||||
- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
|
||||
bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
|
||||
These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
|
||||
packet was present, but not captured, and the fields contain filler.
|
||||
|
||||
- Number of isochronous frame descriptors and descriptors themselves.
|
||||
If an Isochronous transfer event has a set of descriptors, a total number
|
||||
of them in an URB is printed first, then a word per descriptor, up to a
|
||||
total of 5. The word consists of 3 colon-separated decimal numbers for
|
||||
status, offset, and length respectively. For submissions, initial length
|
||||
is reported. For callbacks, actual length is reported.
|
||||
|
||||
- Data Length. For submissions, this is the requested length. For callbacks,
|
||||
this is the actual length.
|
||||
|
||||
- Data tag. The usbmon may not always capture data, even if length is nonzero.
|
||||
The data words are present only if this tag is '='.
|
||||
|
||||
- Data words follow, in big endian hexadecimal format. Notice that they are
|
||||
not machine words, but really just a byte stream split into words to make
|
||||
it easier to read. Thus, the last word may contain from one to four bytes.
|
||||
@@ -153,20 +187,18 @@ class ParsedLine {
|
||||
}
|
||||
}
|
||||
|
||||
This format may be changed in the future.
|
||||
|
||||
Examples:
|
||||
|
||||
An input control transfer to get a port status.
|
||||
|
||||
d5ea89a0 3575914555 S Ci:001:00 s a3 00 0000 0003 0004 4 <
|
||||
d5ea89a0 3575914560 C Ci:001:00 0 4 = 01050000
|
||||
d5ea89a0 3575914555 S Ci:1:001:0 s a3 00 0000 0003 0004 4 <
|
||||
d5ea89a0 3575914560 C Ci:1:001:0 0 4 = 01050000
|
||||
|
||||
An output bulk transfer to send a SCSI command 0x5E in a 31-byte Bulk wrapper
|
||||
to a storage device at address 5:
|
||||
|
||||
dd65f0e8 4128379752 S Bo:005:02 -115 31 = 55534243 5e000000 00000000 00000600 00000000 00000000 00000000 000000
|
||||
dd65f0e8 4128379808 C Bo:005:02 0 31 >
|
||||
dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 5e000000 00000000 00000600 00000000 00000000 00000000 000000
|
||||
dd65f0e8 4128379808 C Bo:1:005:2 0 31 >
|
||||
|
||||
* Raw binary format and API
|
||||
|
||||
|
||||
@@ -143,3 +143,5 @@
|
||||
142 -> Sabrent TV-FM (bttv version)
|
||||
143 -> Hauppauge ImpactVCB (bt878) [0070:13eb]
|
||||
144 -> MagicTV
|
||||
145 -> SSAI Security Video Interface [4149:5353]
|
||||
146 -> SSAI Ultrasound Video Interface [414a:5353]
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
36 -> AVerTV 303 (M126) [1461:000a]
|
||||
37 -> Hauppauge Nova-S-Plus DVB-S [0070:9201,0070:9202]
|
||||
38 -> Hauppauge Nova-SE2 DVB-S [0070:9200]
|
||||
39 -> KWorld DVB-S 100 [17de:08b2]
|
||||
39 -> KWorld DVB-S 100 [17de:08b2,1421:0341]
|
||||
40 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid [0070:9400,0070:9402]
|
||||
41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802]
|
||||
42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019]
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user