You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' into upstream
This commit is contained in:
Jeff Garzik
@@ -1620,7 +1620,8 @@ D: fbdev hacking
|
||||
|
||||
N: Jesper Juhl
|
||||
E: jesper.juhl@gmail.com
|
||||
D: Various fixes, cleanups and minor features.
|
||||
D: Various fixes, cleanups and minor features all over the tree.
|
||||
D: Wrote initial version of the hdaps driver (since passed on to others).
|
||||
S: Lemnosvej 1, 3.tv
|
||||
S: 2300 Copenhagen S.
|
||||
S: Denmark
|
||||
@@ -2477,7 +2478,8 @@ S: Derbyshire DE4 3RL
|
||||
S: United Kingdom
|
||||
|
||||
N: Ian S. Nelson
|
||||
E: ian.nelson@echostar.com
|
||||
E: nelsonis@earthlink.net
|
||||
P: 1024D/00D3D983 3EFD 7B86 B888 D7E2 29B6 9E97 576F 1B97 00D3 D983
|
||||
D: Minor mmap and ide hacks
|
||||
S: 1370 Atlantis Ave.
|
||||
S: Lafayette CO, 80026
|
||||
|
||||
@@ -532,6 +532,40 @@ appears outweighs the potential value of the hint that tells gcc to do
|
||||
something it would have done anyway.
|
||||
|
||||
|
||||
Chapter 16: Function return values and names
|
||||
|
||||
Functions can return values of many different kinds, and one of the
|
||||
most common is a value indicating whether the function succeeded or
|
||||
failed. Such a value can be represented as an error-code integer
|
||||
(-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure,
|
||||
non-zero = success).
|
||||
|
||||
Mixing up these two sorts of representations is a fertile source of
|
||||
difficult-to-find bugs. If the C language included a strong distinction
|
||||
between integers and booleans then the compiler would find these mistakes
|
||||
for us... but it doesn't. To help prevent such bugs, always follow this
|
||||
convention:
|
||||
|
||||
If the name of a function is an action or an imperative command,
|
||||
the function should return an error-code integer. If the name
|
||||
is a predicate, the function should return a "succeeded" boolean.
|
||||
|
||||
For example, "add work" is a command, and the add_work() function returns 0
|
||||
for success or -EBUSY for failure. In the same way, "PCI device present" is
|
||||
a predicate, and the pci_dev_present() function returns 1 if it succeeds in
|
||||
finding a matching device or 0 if it doesn't.
|
||||
|
||||
All EXPORTed functions must respect this convention, and so should all
|
||||
public functions. Private (static) functions need not, but it is
|
||||
recommended that they do.
|
||||
|
||||
Functions whose return value is the actual result of a computation, rather
|
||||
than an indication of whether the computation succeeded, are not subject to
|
||||
this rule. Generally they indicate failure by returning some out-of-range
|
||||
result. Typical examples would be functions that return pointers; they use
|
||||
NULL or the ERR_PTR mechanism to report failure.
|
||||
|
||||
|
||||
|
||||
Appendix I: References
|
||||
|
||||
|
||||
@@ -181,27 +181,6 @@ X!Ilib/string.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="proc">
|
||||
<title>The proc filesystem</title>
|
||||
|
||||
<sect1><title>sysctl interface</title>
|
||||
!Ekernel/sysctl.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>proc filesystem interface</title>
|
||||
!Ifs/proc/base.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="debugfs">
|
||||
<title>The debugfs filesystem</title>
|
||||
|
||||
<sect1><title>debugfs interface</title>
|
||||
!Efs/debugfs/inode.c
|
||||
!Efs/debugfs/file.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="vfs">
|
||||
<title>The Linux VFS</title>
|
||||
<sect1><title>The Filesystem types</title>
|
||||
@@ -234,6 +213,50 @@ X!Ilib/string.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="proc">
|
||||
<title>The proc filesystem</title>
|
||||
|
||||
<sect1><title>sysctl interface</title>
|
||||
!Ekernel/sysctl.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>proc filesystem interface</title>
|
||||
!Ifs/proc/base.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="sysfs">
|
||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
!Efs/sysfs/symlink.c
|
||||
!Efs/sysfs/bin.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="debugfs">
|
||||
<title>The debugfs filesystem</title>
|
||||
|
||||
<sect1><title>debugfs interface</title>
|
||||
!Efs/debugfs/inode.c
|
||||
!Efs/debugfs/file.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="relayfs">
|
||||
<title>relay interface support</title>
|
||||
|
||||
<para>
|
||||
Relay interface support
|
||||
is designed to provide an efficient mechanism for tools and
|
||||
facilities to relay large amounts of data from kernel space to
|
||||
user space.
|
||||
</para>
|
||||
|
||||
<sect1><title>relay interface</title>
|
||||
!Ekernel/relay.c
|
||||
!Ikernel/relay.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="netcore">
|
||||
<title>Linux Networking</title>
|
||||
<sect1><title>Networking Base Types</title>
|
||||
@@ -349,13 +372,6 @@ X!Earch/i386/kernel/mca.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="sysfs">
|
||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||
!Efs/sysfs/file.c
|
||||
!Efs/sysfs/symlink.c
|
||||
!Efs/sysfs/bin.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="security">
|
||||
<title>Security Framework</title>
|
||||
!Esecurity/security.c
|
||||
@@ -386,6 +402,7 @@ X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/class.c
|
||||
!Edrivers/base/firmware_class.c
|
||||
!Edrivers/base/transport_class.c
|
||||
!Edrivers/base/dmapool.c
|
||||
@@ -437,6 +454,11 @@ X!Edrivers/pnp/system.c
|
||||
!Eblock/ll_rw_blk.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="chrdev">
|
||||
<title>Char devices</title>
|
||||
!Efs/char_dev.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="miscdev">
|
||||
<title>Miscellaneous Devices</title>
|
||||
!Edrivers/char/misc.c
|
||||
|
||||
@@ -61,3 +61,6 @@ kernel patches.
|
||||
Documentation/kernel-parameters.txt.
|
||||
|
||||
18: All new module parameters are documented with MODULE_PARM_DESC()
|
||||
|
||||
19: All new userspace interfaces are documented in Documentation/ABI/.
|
||||
See Documentation/ABI/README for more information.
|
||||
|
||||
@@ -59,11 +59,11 @@ Copyright: The copyright owner must agree to use of GPL.
|
||||
are the same person/entity. If not, the name of
|
||||
the person/entity authorizing use of GPL should be
|
||||
listed in case it's necessary to verify the will of
|
||||
the copright owner.
|
||||
the copyright owner.
|
||||
|
||||
Interfaces: If your driver uses existing interfaces and behaves like
|
||||
other drivers in the same class it will be much more likely
|
||||
to be accepted than if it invents gratuitous new ones.
|
||||
to be accepted than if it invents gratuitous new ones.
|
||||
If you need to implement a common API over Linux and NT
|
||||
drivers do it in userspace.
|
||||
|
||||
@@ -88,7 +88,7 @@ Clarity: It helps if anyone can see how to fix the driver. It helps
|
||||
it will go in the bitbucket.
|
||||
|
||||
Control: In general if there is active maintainance of a driver by
|
||||
the author then patches will be redirected to them unless
|
||||
the author then patches will be redirected to them unless
|
||||
they are totally obvious and without need of checking.
|
||||
If you want to be the contact and update point for the
|
||||
driver it is a good idea to state this in the comments,
|
||||
@@ -100,7 +100,7 @@ What Criteria Do Not Determine Acceptance
|
||||
Vendor: Being the hardware vendor and maintaining the driver is
|
||||
often a good thing. If there is a stable working driver from
|
||||
other people already in the tree don't expect 'we are the
|
||||
vendor' to get your driver chosen. Ideally work with the
|
||||
vendor' to get your driver chosen. Ideally work with the
|
||||
existing driver author to build a single perfect driver.
|
||||
|
||||
Author: It doesn't matter if a large Linux company wrote the driver,
|
||||
@@ -116,17 +116,13 @@ Linux kernel master tree:
|
||||
ftp.??.kernel.org:/pub/linux/kernel/...
|
||||
?? == your country code, such as "us", "uk", "fr", etc.
|
||||
|
||||
Linux kernel mailing list:
|
||||
Linux kernel mailing list:
|
||||
linux-kernel@vger.kernel.org
|
||||
[mail majordomo@vger.kernel.org to subscribe]
|
||||
|
||||
Linux Device Drivers, Third Edition (covers 2.6.10):
|
||||
http://lwn.net/Kernel/LDD3/ (free version)
|
||||
|
||||
Kernel traffic:
|
||||
Weekly summary of kernel list activity (much easier to read)
|
||||
http://www.kerneltraffic.org/kernel-traffic/
|
||||
|
||||
LWN.net:
|
||||
Weekly summary of kernel development activity - http://lwn.net/
|
||||
2.6 API changes:
|
||||
@@ -145,11 +141,8 @@ KernelNewbies:
|
||||
Linux USB project:
|
||||
http://www.linux-usb.org/
|
||||
|
||||
How to NOT write kernel driver by arjanv@redhat.com
|
||||
http://people.redhat.com/arjanv/olspaper.pdf
|
||||
How to NOT write kernel driver by Arjan van de Ven:
|
||||
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
|
||||
|
||||
Kernel Janitor:
|
||||
http://janitor.kernelnewbies.org/
|
||||
|
||||
--
|
||||
Last updated on 17 Nov 2005.
|
||||
|
||||
@@ -173,15 +173,15 @@ For small patches you may want to CC the Trivial Patch Monkey
|
||||
trivial@kernel.org managed by Adrian Bunk; which collects "trivial"
|
||||
patches. Trivial patches must qualify for one of the following rules:
|
||||
Spelling fixes in documentation
|
||||
Spelling fixes which could break grep(1).
|
||||
Spelling fixes which could break grep(1)
|
||||
Warning fixes (cluttering with useless warnings is bad)
|
||||
Compilation fixes (only if they are actually correct)
|
||||
Runtime fixes (only if they actually fix things)
|
||||
Removing use of deprecated functions/macros (eg. check_region).
|
||||
Removing use of deprecated functions/macros (eg. check_region)
|
||||
Contact detail and documentation fixes
|
||||
Non-portable code replaced by portable code (even in arch-specific,
|
||||
since people copy, as long as it's trivial)
|
||||
Any fix by the author/maintainer of the file. (ie. patch monkey
|
||||
Any fix by the author/maintainer of the file (ie. patch monkey
|
||||
in re-transmission mode)
|
||||
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
|
||||
|
||||
@@ -209,6 +209,19 @@ Exception: If your mailer is mangling patches then someone may ask
|
||||
you to re-send them using MIME.
|
||||
|
||||
|
||||
WARNING: Some mailers like Mozilla send your messages with
|
||||
---- message header ----
|
||||
Content-Type: text/plain; charset=us-ascii; format=flowed
|
||||
---- message header ----
|
||||
The problem is that "format=flowed" makes some of the mailers
|
||||
on receiving side to replace TABs with spaces and do similar
|
||||
changes. Thus the patches from you can look corrupted.
|
||||
|
||||
To fix this just make your mozilla defaults/pref/mailnews.js file to look like:
|
||||
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
|
||||
pref("mailnews.display.disable_format_flowed_support", true);
|
||||
|
||||
|
||||
|
||||
7) E-mail size.
|
||||
|
||||
@@ -245,13 +258,13 @@ updated change.
|
||||
It is quite common for Linus to "drop" your patch without comment.
|
||||
That's the nature of the system. If he drops your patch, it could be
|
||||
due to
|
||||
* Your patch did not apply cleanly to the latest kernel version
|
||||
* Your patch did not apply cleanly to the latest kernel version.
|
||||
* Your patch was not sufficiently discussed on linux-kernel.
|
||||
* A style issue (see section 2),
|
||||
* An e-mail formatting issue (re-read this section)
|
||||
* A technical problem with your change
|
||||
* He gets tons of e-mail, and yours got lost in the shuffle
|
||||
* You are being annoying (See Figure 1)
|
||||
* A style issue (see section 2).
|
||||
* An e-mail formatting issue (re-read this section).
|
||||
* A technical problem with your change.
|
||||
* He gets tons of e-mail, and yours got lost in the shuffle.
|
||||
* You are being annoying.
|
||||
|
||||
When in doubt, solicit comments on linux-kernel mailing list.
|
||||
|
||||
@@ -476,10 +489,10 @@ SECTION 3 - REFERENCES
|
||||
Andrew Morton, "The perfect patch" (tpp).
|
||||
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
|
||||
|
||||
Jeff Garzik, "Linux kernel patch submission format."
|
||||
Jeff Garzik, "Linux kernel patch submission format".
|
||||
<http://linux.yyz.us/patch-format.html>
|
||||
|
||||
Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
|
||||
Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
||||
<http://www.kroah.com/log/2005/03/31/>
|
||||
<http://www.kroah.com/log/2005/07/08/>
|
||||
<http://www.kroah.com/log/2005/10/19/>
|
||||
@@ -488,9 +501,9 @@ Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
|
||||
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
|
||||
|
||||
Kernel Documentation/CodingStyle
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
|
||||
|
||||
Linus Torvald's mail on the canonical patch format:
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
--
|
||||
|
||||
@@ -217,11 +217,11 @@ exclusive cpuset. Also, the use of a Linux virtual file system (vfs)
|
||||
to represent the cpuset hierarchy provides for a familiar permission
|
||||
and name space for cpusets, with a minimum of additional kernel code.
|
||||
|
||||
The cpus file in the root (top_cpuset) cpuset is read-only.
|
||||
It automatically tracks the value of cpu_online_map, using a CPU
|
||||
hotplug notifier. If and when memory nodes can be hotplugged,
|
||||
we expect to make the mems file in the root cpuset read-only
|
||||
as well, and have it track the value of node_online_map.
|
||||
The cpus and mems files in the root (top_cpuset) cpuset are
|
||||
read-only. The cpus file automatically tracks the value of
|
||||
cpu_online_map using a CPU hotplug notifier, and the mems file
|
||||
automatically tracks the value of node_online_map using the
|
||||
cpuset_track_online_nodes() hook.
|
||||
|
||||
|
||||
1.4 What are exclusive cpusets ?
|
||||
|
||||
@@ -1,16 +1,19 @@
|
||||
Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver
|
||||
Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
|
||||
================================================================
|
||||
|
||||
A. Introduction
|
||||
This is a framebuffer driver for various Intel 810/815 compatible
|
||||
This is a framebuffer driver for various Intel 8xx/9xx compatible
|
||||
graphics devices. These would include:
|
||||
|
||||
Intel 830M
|
||||
Intel 810E845G
|
||||
Intel 845G
|
||||
Intel 852GM
|
||||
Intel 855GM
|
||||
Intel 865G
|
||||
Intel 915G
|
||||
Intel 915GM
|
||||
Intel 945G
|
||||
Intel 945GM
|
||||
|
||||
B. List of available options
|
||||
|
||||
@@ -78,7 +81,7 @@ C. Kernel booting
|
||||
Separate each option/option-pair by commas (,) and the option from its value
|
||||
with an equals sign (=) as in the following:
|
||||
|
||||
video=i810fb:option1,option2=value2
|
||||
video=intelfb:option1,option2=value2
|
||||
|
||||
Sample Usage
|
||||
------------
|
||||
|
||||
@@ -46,17 +46,8 @@ Who: Jody McIntyre <scjody@modernduck.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sbp2: module parameter "force_inquiry_hack"
|
||||
When: July 2006
|
||||
Why: Superceded by parameter "workarounds". Both parameters are meant to be
|
||||
used ad-hoc and for single devices only, i.e. not in modprobe.conf,
|
||||
therefore the impact of this feature replacement should be low.
|
||||
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
||||
When: July 2006
|
||||
When: December 2006
|
||||
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
|
||||
series. The old API have lots of drawbacks and don't provide enough
|
||||
means to work with all video and audio standards. The newer API is
|
||||
|
||||
@@ -39,6 +39,8 @@ Table of Contents
|
||||
2.9 Appletalk
|
||||
2.10 IPX
|
||||
2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem
|
||||
2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score
|
||||
2.13 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Preface
|
||||
@@ -1962,6 +1964,22 @@ a queue must be less or equal then msg_max.
|
||||
maximum message size value (it is every message queue's attribute set during
|
||||
its creation).
|
||||
|
||||
2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score
|
||||
------------------------------------------------------
|
||||
|
||||
This file can be used to adjust the score used to select which processes
|
||||
should be killed in an out-of-memory situation. Giving it a high score will
|
||||
increase the likelihood of this process being killed by the oom-killer. Valid
|
||||
values are in the range -16 to +15, plus the special value -17, which disables
|
||||
oom-killing altogether for this process.
|
||||
|
||||
2.13 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
-------------------------------------------------------------
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
This file can be used to check the current score used by the oom-killer is for
|
||||
any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which
|
||||
process should be killed in an out-of-memory situation.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Summary
|
||||
|
||||
+47
-14
@@ -13,12 +13,25 @@ Supported chips:
|
||||
from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/
|
||||
* IT8716F
|
||||
Prefix: 'it8716'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.ZIP
|
||||
* IT8718F
|
||||
Prefix: 'it8718'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
|
||||
* SiS950 [clone of IT8705F]
|
||||
Prefix: 'it87'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: No longer be available
|
||||
|
||||
Author: Christophe Gauthron <chrisg@0-in.com>
|
||||
Authors:
|
||||
Christophe Gauthron <chrisg@0-in.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
|
||||
Module Parameters
|
||||
@@ -43,26 +56,46 @@ Module Parameters
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the IT8705F, IT8712F and SiS950 chips.
|
||||
|
||||
This driver also supports IT8712F, which adds SMBus access, and a VID
|
||||
input, used to report the Vcore voltage of the Pentium processor.
|
||||
The IT8712F additionally features VID inputs.
|
||||
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
||||
IT8718F and SiS950 chips.
|
||||
|
||||
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
||||
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
||||
include an 'environment controller' with 3 temperature sensors, 3 fan
|
||||
rotation speed sensors, 8 voltage sensors, and associated alarms.
|
||||
|
||||
The IT8712F and IT8716F additionally feature VID inputs, used to report
|
||||
the Vcore voltage of the processor. The early IT8712F have 5 VID pins,
|
||||
the IT8716F and late IT8712F have 6. They are shared with other functions
|
||||
though, so the functionality may not be available on a given system.
|
||||
The driver dumbly assume it is there.
|
||||
|
||||
The IT8718F also features VID inputs (up to 8 pins) but the value is
|
||||
stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
this value can currently only be read once at initialization time, so
|
||||
the driver won't notice and report changes in the VID value. The two
|
||||
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
||||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
||||
2 additional fans. They are not yet supported by the driver.
|
||||
|
||||
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
|
||||
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
|
||||
clock divider mess) but not compatible with the older chips and
|
||||
revisions. For now, the driver only uses the 16-bit mode on the
|
||||
IT8716F and IT8718F.
|
||||
|
||||
Temperatures are measured in degrees Celsius. An alarm is triggered once
|
||||
when the Overtemperature Shutdown limit is crossed.
|
||||
|
||||
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
|
||||
triggered if the rotation speed has dropped below a programmable limit. Fan
|
||||
readings can be divided by a programmable divider (1, 2, 4 or 8) to give the
|
||||
readings more range or accuracy. Not all RPM values can accurately be
|
||||
represented, so some rounding is done. With a divider of 2, the lowest
|
||||
representable value is around 2600 RPM.
|
||||
triggered if the rotation speed has dropped below a programmable limit. When
|
||||
16-bit tachometer counters aren't used, fan readings can be divided by
|
||||
a programmable divider (1, 2, 4 or 8) to give the readings more range or
|
||||
accuracy. With a divider of 2, the lowest representable value is around
|
||||
2600 RPM. Not all RPM values can accurately be represented, so some rounding
|
||||
is done.
|
||||
|
||||
Voltage sensors (also known as IN sensors) report their values in volts. An
|
||||
alarm is triggered if the voltage has crossed a programmable minimum or
|
||||
@@ -71,9 +104,9 @@ zero'; this is important for negative voltage measurements. All voltage
|
||||
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
||||
0.016 volt. The battery voltage in8 does not have limit registers.
|
||||
|
||||
The VID lines (IT8712F only) encode the core voltage value: the voltage
|
||||
level your processor should work with. This is hardcoded by the mainboard
|
||||
and/or processor itself. It is a value in volts.
|
||||
The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value:
|
||||
the voltage level your processor should work with. This is hardcoded by
|
||||
the mainboard and/or processor itself. It is a value in volts.
|
||||
|
||||
If an alarm triggers, it will remain triggered until the hardware register
|
||||
is read at least once. This means that the cause for the alarm may already
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
Kernel driver k8temp
|
||||
====================
|
||||
|
||||
Supported chips:
|
||||
* AMD K8 CPU
|
||||
Prefix: 'k8temp'
|
||||
Addresses scanned: PCI space
|
||||
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
|
||||
|
||||
Author: Rudolf Marek
|
||||
Contact: Rudolf Marek <r.marek@sh.cvut.cz>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
|
||||
Official documentation says that it works from revision F of K8 core, but
|
||||
in fact it seems to be implemented for all revisions of K8 except the first
|
||||
two revisions (SH-B0 and SH-B3).
|
||||
|
||||
There can be up to four temperature sensors inside single CPU. The driver
|
||||
will auto-detect the sensors and will display only temperatures from
|
||||
implemented sensors.
|
||||
|
||||
Mapping of /sys files is as follows:
|
||||
|
||||
temp1_input - temperature of Core 0 and "place" 0
|
||||
temp2_input - temperature of Core 0 and "place" 1
|
||||
temp3_input - temperature of Core 1 and "place" 0
|
||||
temp4_input - temperature of Core 1 and "place" 1
|
||||
|
||||
Temperatures are measured in degrees Celsius and measurement resolution is
|
||||
1 degree C. It is expected that future CPU will have better resolution. The
|
||||
temperature is updated once a second. Valid temperatures are from -49 to
|
||||
206 degrees C.
|
||||
|
||||
Temperature known as TCaseMax was specified for processors up to revision E.
|
||||
This temperature is defined as temperature between heat-spreader and CPU
|
||||
case, so the internal CPU temperature supplied by this driver can be higher.
|
||||
There is no easy way how to measure the temperature which will correlate
|
||||
with TCaseMax temperature.
|
||||
|
||||
For newer revisions of CPU (rev F, socket AM2) there is a mathematically
|
||||
computed temperature called TControl, which must be lower than TControlMax.
|
||||
|
||||
The relationship is following:
|
||||
|
||||
temp1_input - TjOffset*2 < TControlMax,
|
||||
|
||||
TjOffset is not yet exported by the driver, TControlMax is usually
|
||||
70 degrees C. The rule of the thumb -> CPU temperature should not cross
|
||||
60 degrees C too much.
|
||||
@@ -0,0 +1,206 @@
|
||||
Kernel driver vt1211
|
||||
====================
|
||||
|
||||
Supported chips:
|
||||
* VIA VT1211
|
||||
Prefix: 'vt1211'
|
||||
Addresses scanned: none, address read from Super-I/O config space
|
||||
Datasheet: Provided by VIA upon request and under NDA
|
||||
|
||||
Authors: Juerg Haefliger <juergh@gmail.com>
|
||||
|
||||
This driver is based on the driver for kernel 2.4 by Mark D. Studebaker and
|
||||
its port to kernel 2.6 by Lars Ekman.
|
||||
|
||||
Thanks to Joseph Chan and Fiona Gatt from VIA for providing documentation and
|
||||
technical support.
|
||||
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
* uch_config: int Override the BIOS default universal channel (UCH)
|
||||
configuration for channels 1-5.
|
||||
Legal values are in the range of 0-31. Bit 0 maps to
|
||||
UCH1, bit 1 maps to UCH2 and so on. Setting a bit to 1
|
||||
enables the thermal input of that particular UCH and
|
||||
setting a bit to 0 enables the voltage input.
|
||||
|
||||
* int_mode: int Override the BIOS default temperature interrupt mode.
|
||||
The only possible value is 0 which forces interrupt
|
||||
mode 0. In this mode, any pending interrupt is cleared
|
||||
when the status register is read but is regenerated as
|
||||
long as the temperature stays above the hysteresis
|
||||
limit.
|
||||
|
||||
Be aware that overriding BIOS defaults might cause some unwanted side effects!
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The VIA VT1211 Super-I/O chip includes complete hardware monitoring
|
||||
capabilities. It monitors 2 dedicated temperature sensor inputs (temp1 and
|
||||
temp2), 1 dedicated voltage (in5) and 2 fans. Additionally, the chip
|
||||
implements 5 universal input channels (UCH1-5) that can be individually
|
||||
programmed to either monitor a voltage or a temperature.
|
||||
|
||||
This chip also provides manual and automatic control of fan speeds (according
|
||||
to the datasheet). The driver only supports automatic control since the manual
|
||||
mode doesn't seem to work as advertised in the datasheet. In fact I couldn't
|
||||
get manual mode to work at all! Be aware that automatic mode hasn't been
|
||||
tested very well (due to the fact that my EPIA M10000 doesn't have the fans
|
||||
connected to the PWM outputs of the VT1211 :-().
|
||||
|
||||
The following table shows the relationship between the vt1211 inputs and the
|
||||
sysfs nodes.
|
||||
|
||||
Sensor Voltage Mode Temp Mode Default Use (from the datasheet)
|
||||
------ ------------ --------- --------------------------------
|
||||
Reading 1 temp1 Intel thermal diode
|
||||
Reading 3 temp2 Internal thermal diode
|
||||
UCH1/Reading2 in0 temp3 NTC type thermistor
|
||||
UCH2 in1 temp4 +2.5V
|
||||
UCH3 in2 temp5 VccP (processor core)
|
||||
UCH4 in3 temp6 +5V
|
||||
UCH5 in4 temp7 +12V
|
||||
+3.3V in5 Internal VCC (+3.3V)
|
||||
|
||||
|
||||
Voltage Monitoring
|
||||
------------------
|
||||
|
||||
Voltages are sampled by an 8-bit ADC with a LSB of ~10mV. The supported input
|
||||
range is thus from 0 to 2.60V. Voltage values outside of this range need
|
||||
external scaling resistors. This external scaling needs to be compensated for
|
||||
via compute lines in sensors.conf, like:
|
||||
|
||||
compute inx @*(1+R1/R2), @/(1+R1/R2)
|
||||
|
||||
The board level scaling resistors according to VIA's recommendation are as
|
||||
follows. And this is of course totally dependent on the actual board
|
||||
implementation :-) You will have to find documentation for your own
|
||||
motherboard and edit sensors.conf accordingly.
|
||||
|
||||
Expected
|
||||
Voltage R1 R2 Divider Raw Value
|
||||
-----------------------------------------------
|
||||
+2.5V 2K 10K 1.2 2083 mV
|
||||
VccP --- --- 1.0 1400 mV (1)
|
||||
+5V 14K 10K 2.4 2083 mV
|
||||
+12V 47K 10K 5.7 2105 mV
|
||||
+3.3V (int) 2K 3.4K 1.588 3300 mV (2)
|
||||
+3.3V (ext) 6.8K 10K 1.68 1964 mV
|
||||
|
||||
(1) Depending on the CPU (1.4V is for a VIA C3 Nehemiah).
|
||||
(2) R1 and R2 for 3.3V (int) are internal to the VT1211 chip and the driver
|
||||
performs the scaling and returns the properly scaled voltage value.
|
||||
|
||||
Each measured voltage has an associated low and high limit which triggers an
|
||||
alarm when crossed.
|
||||
|
||||
|
||||
Temperature Monitoring
|
||||
----------------------
|
||||
|
||||
Temperatures are reported in millidegree Celsius. Each measured temperature
|
||||
has a high limit which triggers an alarm if crossed. There is an associated
|
||||
hysteresis value with each temperature below which the temperature has to drop
|
||||
before the alarm is cleared (this is only true for interrupt mode 0). The
|
||||
interrupt mode can be forced to 0 in case the BIOS doesn't do it
|
||||
automatically. See the 'Module Parameters' section for details.
|
||||
|
||||
All temperature channels except temp2 are external. Temp2 is the VT1211
|
||||
internal thermal diode and the driver does all the scaling for temp2 and
|
||||
returns the temperature in millidegree Celsius. For the external channels
|
||||
temp1 and temp3-temp7, scaling depends on the board implementation and needs
|
||||
to be performed in userspace via sensors.conf.
|
||||
|
||||
Temp1 is an Intel-type thermal diode which requires the following formula to
|
||||
convert between sysfs readings and real temperatures:
|
||||
|
||||
compute temp1 (@-Offset)/Gain, (@*Gain)+Offset
|
||||
|
||||
According to the VIA VT1211 BIOS porting guide, the following gain and offset
|
||||
values should be used:
|
||||
|
||||
Diode Type Offset Gain
|
||||
---------- ------ ----
|
||||
Intel CPU 88.638 0.9528
|
||||
65.000 0.9686 *)
|
||||
VIA C3 Ezra 83.869 0.9528
|
||||
VIA C3 Ezra-T 73.869 0.9528
|
||||
|
||||
*) This is the formula from the lm_sensors 2.10.0 sensors.conf file. I don't
|
||||
know where it comes from or how it was derived, it's just listed here for
|
||||
completeness.
|
||||
|
||||
Temp3-temp7 support NTC thermistors. For these channels, the driver returns
|
||||
the voltages as seen at the individual pins of UCH1-UCH5. The voltage at the
|
||||
pin (Vpin) is formed by a voltage divider made of the thermistor (Rth) and a
|
||||
scaling resistor (Rs):
|
||||
|
||||
Vpin = 2200 * Rth / (Rs + Rth) (2200 is the ADC max limit of 2200 mV)
|
||||
|
||||
The equation for the thermistor is as follows (google it if you want to know
|
||||
more about it):
|
||||
|
||||
Rth = Ro * exp(B * (1 / T - 1 / To)) (To is 298.15K (25C) and Ro is the
|
||||
nominal resistance at 25C)
|
||||
|
||||
Mingling the above two equations and assuming Rs = Ro and B = 3435 yields the
|
||||
following formula for sensors.conf:
|
||||
|
||||
compute tempx 1 / (1 / 298.15 - (` (2200 / @ - 1)) / 3435) - 273.15,
|
||||
2200 / (1 + (^ (3435 / 298.15 - 3435 / (273.15 + @))))
|
||||
|
||||
|
||||
Fan Speed Control
|
||||
-----------------
|
||||
|
||||
The VT1211 provides 2 programmable PWM outputs to control the speeds of 2
|
||||
fans. Writing a 2 to any of the two pwm[1-2]_enable sysfs nodes will put the
|
||||
PWM controller in automatic mode. There is only a single controller that
|
||||
controls both PWM outputs but each PWM output can be individually enabled and
|
||||
disabled.
|
||||
|
||||
Each PWM has 4 associated distinct output duty-cycles: full, high, low and
|
||||
off. Full and off are internally hard-wired to 255 (100%) and 0 (0%),
|
||||
respectively. High and low can be programmed via
|
||||
pwm[1-2]_auto_point[2-3]_pwm. Each PWM output can be associated with a
|
||||
different thermal input but - and here's the weird part - only one set of
|
||||
thermal thresholds exist that controls both PWMs output duty-cycles. The
|
||||
thermal thresholds are accessible via pwm[1-2]_auto_point[1-4]_temp. Note
|
||||
that even though there are 2 sets of 4 auto points each, they map to the same
|
||||
registers in the VT1211 and programming one set is sufficient (actually only
|
||||
the first set pwm1_auto_point[1-4]_temp is writable, the second set is
|
||||
read-only).
|
||||
|
||||
PWM Auto Point PWM Output Duty-Cycle
|
||||
------------------------------------------------
|
||||
pwm[1-2]_auto_point4_pwm full speed duty-cycle (hard-wired to 255)
|
||||
pwm[1-2]_auto_point3_pwm high speed duty-cycle
|
||||
pwm[1-2]_auto_point2_pwm low speed duty-cycle
|
||||
pwm[1-2]_auto_point1_pwm off duty-cycle (hard-wired to 0)
|
||||
|
||||
Temp Auto Point Thermal Threshold
|
||||
---------------------------------------------
|
||||
pwm[1-2]_auto_point4_temp full speed temp
|
||||
pwm[1-2]_auto_point3_temp high speed temp
|
||||
pwm[1-2]_auto_point2_temp low speed temp
|
||||
pwm[1-2]_auto_point1_temp off temp
|
||||
|
||||
Long story short, the controller implements the following algorithm to set the
|
||||
PWM output duty-cycle based on the input temperature:
|
||||
|
||||
Thermal Threshold Output Duty-Cycle
|
||||
(Rising Temp) (Falling Temp)
|
||||
----------------------------------------------------------
|
||||
full speed duty-cycle full speed duty-cycle
|
||||
full speed temp
|
||||
high speed duty-cycle full speed duty-cycle
|
||||
high speed temp
|
||||
low speed duty-cycle high speed duty-cycle
|
||||
low speed temp
|
||||
off duty-cycle low speed duty-cycle
|
||||
off temp
|
||||
@@ -0,0 +1,85 @@
|
||||
Kernel driver w83627ehf
|
||||
=======================
|
||||
|
||||
Supported chips:
|
||||
* Winbond W83627EHF/EHG (ISA access ONLY)
|
||||
Prefix: 'w83627ehf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
|
||||
|
||||
Authors:
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
Yuan Mu (Winbond)
|
||||
Rudolf Marek <r.marek@sh.cvut.cz>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Winbond W83627EHF and W83627EHG
|
||||
super I/O chips. We will refer to them collectively as Winbond chips.
|
||||
|
||||
The chips implement three temperature sensors, five fan rotation
|
||||
speed sensors, ten analog voltage sensors, alarms with beep warnings (control
|
||||
unimplemented), and some automatic fan regulation strategies (plus manual
|
||||
fan control mode).
|
||||
|
||||
Temperatures are measured in degrees Celsius and measurement resolution is 1
|
||||
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
|
||||
the temperature gets higher than high limit; it stays on until the temperature
|
||||
falls below the Hysteresis value.
|
||||
|
||||
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
|
||||
triggered if the rotation speed has dropped below a programmable limit. Fan
|
||||
readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or
|
||||
128) to give the readings more range or accuracy. The driver sets the most
|
||||
suitable fan divisor itself. Some fans might not be present because they
|
||||
share pins with other functions.
|
||||
|
||||
Voltage sensors (also known as IN sensors) report their values in millivolts.
|
||||
An alarm is triggered if the voltage has crossed a programmable minimum
|
||||
or maximum limit.
|
||||
|
||||
The driver supports automatic fan control mode known as Thermal Cruise.
|
||||
In this mode, the chip attempts to keep the measured temperature in a
|
||||
predefined temperature range. If the temperature goes out of range, fan
|
||||
is driven slower/faster to reach the predefined range again.
|
||||
|
||||
The mode works for fan1-fan4. Mapping of temperatures to pwm outputs is as
|
||||
follows:
|
||||
|
||||
temp1 -> pwm1
|
||||
temp2 -> pwm2
|
||||
temp3 -> pwm3
|
||||
prog -> pwm4 (the programmable setting is not supported by the driver)
|
||||
|
||||
/sys files
|
||||
----------
|
||||
|
||||
pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
|
||||
0 (stop) to 255 (full)
|
||||
|
||||
pwm[1-4]_enable - this file controls mode of fan/temperature control:
|
||||
* 1 Manual Mode, write to pwm file any value 0-255 (full speed)
|
||||
* 2 Thermal Cruise
|
||||
|
||||
Thermal Cruise mode
|
||||
-------------------
|
||||
|
||||
If the temperature is in the range defined by:
|
||||
|
||||
pwm[1-4]_target - set target temperature, unit millidegree Celcius
|
||||
(range 0 - 127000)
|
||||
pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000)
|
||||
|
||||
there are no changes to fan speed. Once the temperature leaves the interval,
|
||||
fan speed increases (temp is higher) or decreases if lower than desired.
|
||||
There are defined steps and times, but not exported by the driver yet.
|
||||
|
||||
pwm[1-4]_min_output - minimum fan speed (range 1 - 255), when the temperature
|
||||
is below defined range.
|
||||
pwm[1-4]_stop_time - how many milliseconds [ms] must elapse to switch
|
||||
corresponding fan off. (when the temperature was below
|
||||
defined range).
|
||||
|
||||
Note: last two functions are influenced by other control bits, not yet exported
|
||||
by the driver, so a change might not have any effect.
|
||||
+37
-30
@@ -5,7 +5,7 @@ Supported chips:
|
||||
* Winbond W83791D
|
||||
Prefix: 'w83791d'
|
||||
Addresses scanned: I2C 0x2c - 0x2f
|
||||
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791Da.pdf
|
||||
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791D_W83791Gb.pdf
|
||||
|
||||
Author: Charles Spirakis <bezaur@gmail.com>
|
||||
|
||||
@@ -20,6 +20,9 @@ Credits:
|
||||
Chunhao Huang <DZShen@Winbond.com.tw>,
|
||||
Rudolf Marek <r.marek@sh.cvut.cz>
|
||||
|
||||
Additional contributors:
|
||||
Sven Anders <anders@anduras.de>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
@@ -46,7 +49,8 @@ Module Parameters
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Winbond W83791D chip.
|
||||
This driver implements support for the Winbond W83791D chip. The W83791G
|
||||
chip appears to be the same as the W83791D but is lead free.
|
||||
|
||||
Detection of the chip can sometimes be foiled because it can be in an
|
||||
internal state that allows no clean access (Bank with ID register is not
|
||||
@@ -71,34 +75,36 @@ Voltage sensors (also known as IN sensors) report their values in millivolts.
|
||||
An alarm is triggered if the voltage has crossed a programmable minimum
|
||||
or maximum limit.
|
||||
|
||||
Alarms are provided as output from a "realtime status register". The
|
||||
following bits are defined:
|
||||
The bit ordering for the alarm "realtime status register" and the
|
||||
"beep enable registers" are different.
|
||||
|
||||
bit - alarm on:
|
||||
0 - Vcore
|
||||
1 - VINR0
|
||||
2 - +3.3VIN
|
||||
3 - 5VDD
|
||||
4 - temp1
|
||||
5 - temp2
|
||||
6 - fan1
|
||||
7 - fan2
|
||||
8 - +12VIN
|
||||
9 - -12VIN
|
||||
10 - -5VIN
|
||||
11 - fan3
|
||||
12 - chassis
|
||||
13 - temp3
|
||||
14 - VINR1
|
||||
15 - reserved
|
||||
16 - tart1
|
||||
17 - tart2
|
||||
18 - tart3
|
||||
19 - VSB
|
||||
20 - VBAT
|
||||
21 - fan4
|
||||
22 - fan5
|
||||
23 - reserved
|
||||
in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001
|
||||
in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch
|
||||
in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004
|
||||
in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008
|
||||
in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100
|
||||
in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200
|
||||
in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400
|
||||
in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch
|
||||
in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch
|
||||
in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000
|
||||
temp1 : alarms: 0x000010 beep_enable: 0x000010
|
||||
temp2 : alarms: 0x000020 beep_enable: 0x000020
|
||||
temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch
|
||||
fan1 : alarms: 0x000040 beep_enable: 0x000040
|
||||
fan2 : alarms: 0x000080 beep_enable: 0x000080
|
||||
fan3 : alarms: 0x000800 beep_enable: 0x000800
|
||||
fan4 : alarms: 0x200000 beep_enable: 0x200000
|
||||
fan5 : alarms: 0x400000 beep_enable: 0x400000
|
||||
tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch
|
||||
tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch
|
||||
tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch
|
||||
case_open : alarms: 0x001000 beep_enable: 0x001000
|
||||
user_enable : alarms: -------- beep_enable: 0x800000
|
||||
|
||||
*** NOTE: It is the responsibility of user-space code to handle the fact
|
||||
that the beep enable and alarm bits are in different positions when using that
|
||||
feature of the chip.
|
||||
|
||||
When an alarm goes off, you can be warned by a beeping signal through your
|
||||
computer speaker. It is possible to enable all beeping globally, or only
|
||||
@@ -109,5 +115,6 @@ often will do no harm, but will return 'old' values.
|
||||
|
||||
W83791D TODO:
|
||||
---------------
|
||||
Provide a patch for per-file alarms as discussed on the mailing list
|
||||
Provide a patch for per-file alarms and beep enables as defined in the hwmon
|
||||
documentation (Documentation/hwmon/sysfs-interface)
|
||||
Provide a patch for smart-fan control (still need appropriate motherboard/fans)
|
||||
|
||||
@@ -110,6 +110,13 @@ be entered as an environment variable, whereas its absence indicates that
|
||||
it will appear as a kernel argument readable via /proc/cmdline by programs
|
||||
running once the system is up.
|
||||
|
||||
The number of kernel parameters is not limited, but the length of the
|
||||
complete command line (parameters including spaces etc.) is limited to
|
||||
a fixed number of characters. This limit depends on the architecture
|
||||
and is between 256 and 4096 characters. It is defined in the file
|
||||
./include/asm/setup.h as COMMAND_LINE_SIZE.
|
||||
|
||||
|
||||
53c7xx= [HW,SCSI] Amiga SCSI controllers
|
||||
See header of drivers/scsi/53c7xx.c.
|
||||
See also Documentation/scsi/ncr53c7xx.txt.
|
||||
@@ -1324,7 +1331,7 @@ running once the system is up.
|
||||
pt. [PARIDE]
|
||||
See Documentation/paride.txt.
|
||||
|
||||
quiet= [KNL] Disable log messages
|
||||
quiet [KNL] Disable most log messages
|
||||
|
||||
r128= [HW,DRM]
|
||||
|
||||
|
||||
@@ -100,6 +100,7 @@ Examples:
|
||||
are: IPSRC_RND #IP Source is random (between min/max),
|
||||
IPDST_RND, UDPSRC_RND,
|
||||
UDPDST_RND, MACSRC_RND, MACDST_RND
|
||||
MPLS_RND, VID_RND, SVID_RND
|
||||
|
||||
pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then
|
||||
cycle through the port range.
|
||||
@@ -125,6 +126,21 @@ Examples:
|
||||
|
||||
pgset "mpls 0" turn off mpls (or any invalid argument works too!)
|
||||
|
||||
pgset "vlan_id 77" set VLAN ID 0-4095
|
||||
pgset "vlan_p 3" set priority bit 0-7 (default 0)
|
||||
pgset "vlan_cfi 0" set canonical format identifier 0-1 (default 0)
|
||||
|
||||
pgset "svlan_id 22" set SVLAN ID 0-4095
|
||||
pgset "svlan_p 3" set priority bit 0-7 (default 0)
|
||||
pgset "svlan_cfi 0" set canonical format identifier 0-1 (default 0)
|
||||
|
||||
pgset "vlan_id 9999" > 4095 remove vlan and svlan tags
|
||||
pgset "svlan 9999" > 4095 remove svlan tag
|
||||
|
||||
|
||||
pgset "tos XX" set former IPv4 TOS field (e.g. "tos 28" for AF11 no ECN, default 00)
|
||||
pgset "traffic_class XX" set former IPv6 TRAFFIC CLASS (e.g. "traffic_class B8" for EF no ECN, default 00)
|
||||
|
||||
pgset stop aborts injection. Also, ^C aborts generator.
|
||||
|
||||
|
||||
|
||||
@@ -1,97 +0,0 @@
|
||||
BSD Secure Levels Linux Security Module
|
||||
Michael A. Halcrow <mike@halcrow.us>
|
||||
|
||||
|
||||
Introduction
|
||||
|
||||
Under the BSD Secure Levels security model, sets of policies are
|
||||
associated with levels. Levels range from -1 to 2, with -1 being the
|
||||
weakest and 2 being the strongest. These security policies are
|
||||
enforced at the kernel level, so not even the superuser is able to
|
||||
disable or circumvent them. This hardens the machine against attackers
|
||||
who gain root access to the system.
|
||||
|
||||
|
||||
Levels and Policies
|
||||
|
||||
Level -1 (Permanently Insecure):
|
||||
- Cannot increase the secure level
|
||||
|
||||
Level 0 (Insecure):
|
||||
- Cannot ptrace the init process
|
||||
|
||||
Level 1 (Default):
|
||||
- /dev/mem and /dev/kmem are read-only
|
||||
- IMMUTABLE and APPEND extended attributes, if set, may not be unset
|
||||
- Cannot load or unload kernel modules
|
||||
- Cannot write directly to a mounted block device
|
||||
- Cannot perform raw I/O operations
|
||||
- Cannot perform network administrative tasks
|
||||
- Cannot setuid any file
|
||||
|
||||
Level 2 (Secure):
|
||||
- Cannot decrement the system time
|
||||
- Cannot write to any block device, whether mounted or not
|
||||
- Cannot unmount any mounted filesystems
|
||||
|
||||
|
||||
Compilation
|
||||
|
||||
To compile the BSD Secure Levels LSM, seclvl.ko, enable the
|
||||
SECURITY_SECLVL configuration option. This is found under Security
|
||||
options -> BSD Secure Levels in the kernel configuration menu.
|
||||
|
||||
|
||||
Basic Usage
|
||||
|
||||
Once the machine is in a running state, with all the necessary modules
|
||||
loaded and all the filesystems mounted, you can load the seclvl.ko
|
||||
module:
|
||||
|
||||
# insmod seclvl.ko
|
||||
|
||||
The module defaults to secure level 1, except when compiled directly
|
||||
into the kernel, in which case it defaults to secure level 0. To raise
|
||||
the secure level to 2, the administrator writes ``2'' to the
|
||||
seclvl/seclvl file under the sysfs mount point (assumed to be /sys in
|
||||
these examples):
|
||||
|
||||
# echo -n "2" > /sys/seclvl/seclvl
|
||||
|
||||
Alternatively, you can initialize the module at secure level 2 with
|
||||
the initlvl module parameter:
|
||||
|
||||
# insmod seclvl.ko initlvl=2
|
||||
|
||||
At this point, it is impossible to remove the module or reduce the
|
||||
secure level. If the administrator wishes to have the option of doing
|
||||
so, he must provide a module parameter, sha1_passwd, that specifies
|
||||
the SHA1 hash of the password that can be used to reduce the secure
|
||||
level to 0.
|
||||
|
||||
To generate this SHA1 hash, the administrator can use OpenSSL:
|
||||
|
||||
# echo -n "boogabooga" | openssl sha1
|
||||
abeda4e0f33defa51741217592bf595efb8d289c
|
||||
|
||||
In order to use password-instigated secure level reduction, the SHA1
|
||||
crypto module must be loaded or compiled into the kernel:
|
||||
|
||||
# insmod sha1.ko
|
||||
|
||||
The administrator can then insmod the seclvl module, including the
|
||||
SHA1 hash of the password:
|
||||
|
||||
# insmod seclvl.ko
|
||||
sha1_passwd=abeda4e0f33defa51741217592bf595efb8d289c
|
||||
|
||||
To reduce the secure level, write the password to seclvl/passwd under
|
||||
your sysfs mount point:
|
||||
|
||||
# echo -n "boogabooga" > /sys/seclvl/passwd
|
||||
|
||||
The September 2004 edition of Sys Admin Magazine has an article about
|
||||
the BSD Secure Levels LSM. I encourage you to refer to that article
|
||||
for a more in-depth treatment of this security module:
|
||||
|
||||
http://www.samag.com/documents/s=9304/sam0409a/0409a.htm
|
||||
@@ -7,10 +7,10 @@
|
||||
6 -> AverTV Studio 303 (M126) [1461:000b]
|
||||
7 -> MSI TV-@nywhere Master [1462:8606]
|
||||
8 -> Leadtek Winfast DV2000 [107d:6620]
|
||||
9 -> Leadtek PVR 2000 [107d:663b,107d:663C]
|
||||
9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632]
|
||||
10 -> IODATA GV-VCP3/PCI [10fc:d003]
|
||||
11 -> Prolink PlayTV PVR
|
||||
12 -> ASUS PVR-416 [1043:4823]
|
||||
12 -> ASUS PVR-416 [1043:4823,1461:c111]
|
||||
13 -> MSI TV-@nywhere
|
||||
14 -> KWorld/VStream XPert DVB-T [17de:08a6]
|
||||
15 -> DViCO FusionHDTV DVB-T1 [18ac:db00]
|
||||
@@ -51,3 +51,7 @@
|
||||
50 -> NPG Tech Real TV FM Top 10 [14f1:0842]
|
||||
51 -> WinFast DTV2000 H [107d:665e]
|
||||
52 -> Geniatech DVB-S [14f1:0084]
|
||||
53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404]
|
||||
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]
|
||||
|
||||
@@ -58,7 +58,7 @@
|
||||
57 -> Avermedia AVerTV GO 007 FM [1461:f31f]
|
||||
58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370]
|
||||
59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
|
||||
60 -> LifeView/Typhoon FlyDVB-T Duo Cardbus [5168:0502,4e42:0502]
|
||||
60 -> LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [5168:0502,4e42:0502,1489:0502]
|
||||
61 -> Philips TOUGH DVB-T reference design [1131:2004]
|
||||
62 -> Compro VideoMate TV Gold+II
|
||||
63 -> Kworld Xpert TV PVR7134
|
||||
@@ -83,7 +83,7 @@
|
||||
82 -> MSI TV@Anywhere plus [1462:6231]
|
||||
83 -> Terratec Cinergy 250 PCI TV [153b:1160]
|
||||
84 -> LifeView FlyDVB Trio [5168:0319]
|
||||
85 -> AverTV DVB-T 777 [1461:2c05]
|
||||
85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05]
|
||||
86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301]
|
||||
87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421]
|
||||
88 -> Tevion/KWorld DVB-T 220RF [17de:7201]
|
||||
@@ -94,3 +94,6 @@
|
||||
93 -> Medion 7134 Bridge #2 [16be:0005]
|
||||
94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502]
|
||||
95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138]
|
||||
96 -> Medion Md8800 Quadro [16be:0007,16be:0008]
|
||||
97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300]
|
||||
98 -> Proteus Pro 2309 [0919:2003]
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user