mirror of
https://gitee.com/bianbu-linux/linux-6.6
synced 2025-04-24 14:07:52 -04:00
Linux 5.9-rc1
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl85kWkeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGGPwIAJpEmEBkMoQ+KARK PaaVDQW9fwAlC1nThMpGv/m8Ym7KbfLkTgEJQiQyNv3pDDhyLP8jvcZcscIkfs4s 56IMjFndRHWNeCVu9YPXWmAEp/WycZNC7YVPu0j1bI9VgvaHvbHOqUWzxB716RbY K4TFprJEA3sotNm0vdda2NgSlSup/0NVKiP2LwQPjkwH+Kf6/Ol1j2uxbWywEo75 BdW5LreDtUoJ7W5BeX8GJ0IVgWdyxBV61eVbaINNY3EOPc7+uMGOgR9oHeGWRceH V4ELYww5yjizUDtKFvVTc/k0tj+Rq73mtOADdaF0YWItqxtDBvAcdKIpC0KYzVaa 2fB+rts= =9Pnj -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXzvIXwAKCRDj7w1vZxhR xYXLAQC80uF6JkpBeNyuewyY7CDadDG1qDchDmYquwGVDnO+HwEAmvL84csLcxBy ah3UMOKUyWz5Sahlg48ZIaaUhRaulwE= =Lu/B -----END PGP SIGNATURE----- Merge v5.9-rc1 into drm-misc-next Sam needs 5.9-rc1 to have dev_err_probe in to merge some patches. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This commit is contained in:
Maxime Ripard
commit
d85ddd1318
11673 changed files with 405555 additions and 192654 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -44,6 +44,7 @@
|
|||
*.tab.[ch]
|
||||
*.tar
|
||||
*.xz
|
||||
*.zst
|
||||
Module.symvers
|
||||
modules.builtin
|
||||
modules.order
|
||||
|
|
|
|||
19
.mailmap
19
.mailmap
|
|
@ -2,11 +2,16 @@
|
|||
# This list is used by git-shortlog to fix a few botched name translations
|
||||
# in the git archive, either because the author's full name was messed up
|
||||
# and/or not always written the same way, making contributions from the
|
||||
# same person appearing not to be so or badly displayed.
|
||||
# same person appearing not to be so or badly displayed. Also allows for
|
||||
# old email addresses to map to new email addresses.
|
||||
#
|
||||
# For format details, see "MAPPING AUTHORS" in "man git-shortlog".
|
||||
#
|
||||
# Please keep this list dictionary sorted.
|
||||
#
|
||||
# This comment is parsed by git-shortlog:
|
||||
# repo-abbrev: /pub/scm/linux/kernel/git/
|
||||
#
|
||||
|
||||
Aaron Durbin <adurbin@google.com>
|
||||
Adam Oldham <oldhamca@gmail.com>
|
||||
Adam Radford <aradford@gmail.com>
|
||||
|
|
@ -18,6 +23,9 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
|||
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
|
||||
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
|
||||
|
|
@ -96,6 +104,7 @@ Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@linux.vnet.ibm.com>
|
|||
Greg Kroah-Hartman <greg@echidna.(none)>
|
||||
Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
|
||||
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
|
||||
Hanjun Guo <guohanjun@huawei.com> <hanjun.guo@linaro.org>
|
||||
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
|
||||
|
|
@ -134,6 +143,11 @@ Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
|||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.cz>
|
||||
Jiri Slaby <jirislaby@kernel.org> <xslaby@fi.muni.cz>
|
||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
|
|
@ -151,6 +165,7 @@ Kamil Konieczny <k.konieczny@samsung.com> <k.konieczny@partner.samsung.com>
|
|||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
|
||||
|
|
|
|||
72
CREDITS
72
CREDITS
|
|
@ -34,7 +34,7 @@ S: Romania
|
|||
|
||||
N: Mark Adler
|
||||
E: madler@alumni.caltech.edu
|
||||
W: http://alumnus.caltech.edu/~madler/
|
||||
W: https://alumnus.caltech.edu/~madler/
|
||||
D: zlib decompression
|
||||
|
||||
N: Monalisa Agrawal
|
||||
|
|
@ -62,7 +62,7 @@ S: United Kingdom
|
|||
|
||||
N: Werner Almesberger
|
||||
E: werner@almesberger.net
|
||||
W: http://www.almesberger.net/
|
||||
W: https://www.almesberger.net/
|
||||
D: dosfs, LILO, some fd features, ATM, various other hacks here and there
|
||||
S: Buenos Aires
|
||||
S: Argentina
|
||||
|
|
@ -96,7 +96,7 @@ S: USA
|
|||
|
||||
N: Erik Andersen
|
||||
E: andersen@codepoet.org
|
||||
W: http://www.codepoet.org/
|
||||
W: https://www.codepoet.org/
|
||||
P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057
|
||||
D: Maintainer of ide-cd and Uniform CD-ROM driver,
|
||||
D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update.
|
||||
|
|
@ -114,7 +114,7 @@ S: Canada K2P 0X3
|
|||
|
||||
N: H. Peter Anvin
|
||||
E: hpa@zytor.com
|
||||
W: http://www.zytor.com/~hpa/
|
||||
W: https://www.zytor.com/~hpa/
|
||||
P: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
|
||||
D: Author of the SYSLINUX boot loader, maintainer of the linux.* news
|
||||
D: hierarchy and the Linux Device List; various kernel hacks
|
||||
|
|
@ -124,7 +124,7 @@ S: USA
|
|||
|
||||
N: Andrea Arcangeli
|
||||
E: andrea@suse.de
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/andrea/
|
||||
W: https://www.kernel.org/pub/linux/kernel/people/andrea/
|
||||
P: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43
|
||||
P: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5
|
||||
D: Parport hacker
|
||||
|
|
@ -339,7 +339,7 @@ S: Haifa, Israel
|
|||
|
||||
N: Johannes Berg
|
||||
E: johannes@sipsolutions.net
|
||||
W: http://johannes.sipsolutions.net/
|
||||
W: https://johannes.sipsolutions.net/
|
||||
P: 4096R/7BF9099A C0EB C440 F6DA 091C 884D 8532 E0F3 73F3 7BF9 099A
|
||||
D: powerpc & 802.11 hacker
|
||||
|
||||
|
|
@ -376,7 +376,7 @@ D: Original author of the Linux networking code
|
|||
|
||||
N: Anton Blanchard
|
||||
E: anton@samba.org
|
||||
W: http://samba.org/~anton/
|
||||
W: https://samba.org/~anton/
|
||||
P: 1024/8462A731 4C 55 86 34 44 59 A7 99 2B 97 88 4A 88 9A 0D 97
|
||||
D: sun4 port, Sparc hacker
|
||||
|
||||
|
|
@ -509,7 +509,7 @@ S: Sweden
|
|||
|
||||
N: Paul Bristow
|
||||
E: paul@paulbristow.net
|
||||
W: http://paulbristow.net/linux/idefloppy.html
|
||||
W: https://paulbristow.net/linux/idefloppy.html
|
||||
D: Maintainer of IDE/ATAPI floppy driver
|
||||
|
||||
N: Stefano Brivio
|
||||
|
|
@ -518,7 +518,7 @@ D: Broadcom B43 driver
|
|||
|
||||
N: Dominik Brodowski
|
||||
E: linux@brodo.de
|
||||
W: http://www.brodo.de/
|
||||
W: https://www.brodo.de/
|
||||
P: 1024D/725B37C6 190F 3E77 9C89 3B6D BECD 46EE 67C3 0308 725B 37C6
|
||||
D: parts of CPUFreq code, ACPI bugfixes, PCMCIA rewrite, cpufrequtils
|
||||
S: Tuebingen, Germany
|
||||
|
|
@ -865,7 +865,7 @@ D: Promise DC4030VL caching HD controller drivers
|
|||
|
||||
N: Todd J. Derr
|
||||
E: tjd@fore.com
|
||||
W: http://www.wordsmith.org/~tjd
|
||||
W: https://www.wordsmith.org/~tjd
|
||||
D: Random console hacks and other miscellaneous stuff
|
||||
S: 3000 FORE Drive
|
||||
S: Warrendale, Pennsylvania 15086
|
||||
|
|
@ -894,8 +894,8 @@ S: USA
|
|||
|
||||
N: Matt Domsch
|
||||
E: Matt_Domsch@dell.com
|
||||
W: http://www.dell.com/linux
|
||||
W: http://domsch.com/linux
|
||||
W: https://www.dell.com/linux
|
||||
W: https://domsch.com/linux
|
||||
D: Linux/IA-64
|
||||
D: Dell PowerEdge server, SCSI layer, misc drivers, and other patches
|
||||
S: Dell Inc.
|
||||
|
|
@ -992,7 +992,7 @@ S: USA
|
|||
|
||||
N: Randy Dunlap
|
||||
E: rdunlap@infradead.org
|
||||
W: http://www.infradead.org/~rdunlap/
|
||||
W: https://www.infradead.org/~rdunlap/
|
||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||
D: x86 SMP, ACPI, bootflag hacking
|
||||
D: documentation, builds
|
||||
|
|
@ -1157,7 +1157,7 @@ S: Germany
|
|||
|
||||
N: Jeremy Fitzhardinge
|
||||
E: jeremy@goop.org
|
||||
W: http://www.goop.org/~jeremy
|
||||
W: https://www.goop.org/~jeremy
|
||||
D: author of userfs filesystem
|
||||
D: Improved mmap and munmap handling
|
||||
D: General mm minor tidyups
|
||||
|
|
@ -1460,7 +1460,7 @@ S: The Netherlands
|
|||
|
||||
N: Oliver Hartkopp
|
||||
E: oliver.hartkopp@volkswagen.de
|
||||
W: http://www.volkswagen.de
|
||||
W: https://www.volkswagen.de
|
||||
D: Controller Area Network (network layer core)
|
||||
S: Brieffach 1776
|
||||
S: 38436 Wolfsburg
|
||||
|
|
@ -1599,13 +1599,13 @@ S: Germany
|
|||
|
||||
N: Kenji Hollis
|
||||
E: kenji@bitgate.com
|
||||
W: http://www.bitgate.com/
|
||||
W: https://www.bitgate.com/
|
||||
D: Berkshire PC Watchdog Driver
|
||||
D: Small/Industrial Driver Project
|
||||
|
||||
N: Nick Holloway
|
||||
E: Nick.Holloway@pyrites.org.uk
|
||||
W: http://www.pyrites.org.uk/
|
||||
W: https://www.pyrites.org.uk/
|
||||
P: 1024/36115A04 F4E1 3384 FCFD C055 15D6 BA4C AB03 FBF8 3611 5A04
|
||||
D: Occasional Linux hacker...
|
||||
S: (ask for current address)
|
||||
|
|
@ -1655,7 +1655,7 @@ S: USA
|
|||
|
||||
N: Harald Hoyer
|
||||
E: harald@redhat.com
|
||||
W: http://www.harald-hoyer.de
|
||||
W: https://www.harald-hoyer.de
|
||||
D: ip_masq_quake
|
||||
D: md boot support
|
||||
S: Am Strand 5
|
||||
|
|
@ -1856,7 +1856,7 @@ E: kas@fi.muni.cz
|
|||
D: Author of the COSA/SRP sync serial board driver.
|
||||
D: Port of the syncppp.c from the 2.0 to the 2.1 kernel.
|
||||
P: 1024/D3498839 0D 99 A7 FB 20 66 05 D7 8B 35 FC DE 05 B1 8A 5E
|
||||
W: http://www.fi.muni.cz/~kas/
|
||||
W: https://www.fi.muni.cz/~kas/
|
||||
S: c/o Faculty of Informatics, Masaryk University
|
||||
S: Botanicka' 68a
|
||||
S: 602 00 Brno
|
||||
|
|
@ -2017,7 +2017,7 @@ S: Prague, Czech Republic
|
|||
|
||||
N: Gene Kozin
|
||||
E: 74604.152@compuserve.com
|
||||
W: http://www.sangoma.com
|
||||
W: https://www.sangoma.com
|
||||
D: WAN Router & Sangoma WAN drivers
|
||||
S: Sangoma Technologies Inc.
|
||||
S: 7170 Warden Avenue, Unit 2
|
||||
|
|
@ -2112,7 +2112,7 @@ D: Original author of software suspend
|
|||
|
||||
N: Jaroslav Kysela
|
||||
E: perex@perex.cz
|
||||
W: http://www.perex.cz
|
||||
W: https://www.perex.cz
|
||||
D: Original Author and Maintainer for HP 10/100 Mbit Network Adapters
|
||||
D: ISA PnP
|
||||
S: Sindlovy Dvory 117
|
||||
|
|
@ -2316,7 +2316,7 @@ S: Finland
|
|||
|
||||
N: Daniel J. Maas
|
||||
E: dmaas@dcine.com
|
||||
W: http://www.maasdigital.com
|
||||
W: https://www.maasdigital.com
|
||||
D: dv1394
|
||||
|
||||
N: Hamish Macdonald
|
||||
|
|
@ -2647,7 +2647,7 @@ D: bug fixes, documentation, minor hackery
|
|||
|
||||
N: Paul Moore
|
||||
E: paul@paul-moore.com
|
||||
W: http://www.paul-moore.com
|
||||
W: https://www.paul-moore.com
|
||||
D: NetLabel, SELinux, audit
|
||||
|
||||
N: James Morris
|
||||
|
|
@ -2786,7 +2786,7 @@ N: David C. Niemi
|
|||
E: niemi@tux.org
|
||||
W: http://www.tux.org/~niemi/
|
||||
D: Assistant maintainer of Mtools, fdutils, and floppy driver
|
||||
D: Administrator of Tux.Org Linux Server, http://www.tux.org
|
||||
D: Administrator of Tux.Org Linux Server, https://www.tux.org
|
||||
S: 2364 Old Trail Drive
|
||||
S: Reston, Virginia 20191
|
||||
S: USA
|
||||
|
|
@ -2850,7 +2850,7 @@ S: USA
|
|||
|
||||
N: Mikulas Patocka
|
||||
E: mikulas@artax.karlin.mff.cuni.cz
|
||||
W: http://artax.karlin.mff.cuni.cz/~mikulas/
|
||||
W: https://artax.karlin.mff.cuni.cz/~mikulas/
|
||||
P: 1024/BB11D2D5 A0 F1 28 4A C4 14 1E CF 92 58 7A 8F 69 BC A4 D3
|
||||
D: Read/write HPFS filesystem
|
||||
S: Weissova 8
|
||||
|
|
@ -2872,7 +2872,7 @@ D: RFC2385 Support for TCP
|
|||
|
||||
N: Barak A. Pearlmutter
|
||||
E: bap@cs.unm.edu
|
||||
W: http://www.cs.unm.edu/~bap/
|
||||
W: https://www.cs.unm.edu/~bap/
|
||||
P: 512/602D785D 9B A1 83 CD EE CB AD 93 20 C6 4C B7 F5 E9 60 D4
|
||||
D: Author of mark-and-sweep GC integrated by Alan Cox
|
||||
S: Computer Science Department
|
||||
|
|
@ -3035,7 +3035,7 @@ S: United Kingdom
|
|||
|
||||
N: Daniel Quinlan
|
||||
E: quinlan@pathname.com
|
||||
W: http://www.pathname.com/~quinlan/
|
||||
W: https://www.pathname.com/~quinlan/
|
||||
D: FSSTND coordinator; FHS editor
|
||||
D: random Linux documentation, patches, and hacks
|
||||
S: 4390 Albany Drive #41A
|
||||
|
|
@ -3130,7 +3130,7 @@ S: France
|
|||
|
||||
N: Rik van Riel
|
||||
E: riel@redhat.com
|
||||
W: http://www.surriel.com/
|
||||
W: https://www.surriel.com/
|
||||
D: Linux-MM site, Documentation/admin-guide/sysctl/*, swap/mm readaround
|
||||
D: kswapd fixes, random kernel hacker, rmap VM,
|
||||
D: nl.linux.org administrator, minor scheduler additions
|
||||
|
|
@ -3246,7 +3246,7 @@ S: Germany
|
|||
|
||||
N: Paul `Rusty' Russell
|
||||
E: rusty@rustcorp.com.au
|
||||
W: http://ozlabs.org/~rusty
|
||||
W: https://ozlabs.org/~rusty
|
||||
D: Ruggedly handsome.
|
||||
D: netfilter, ipchains with Michael Neuling.
|
||||
S: 52 Moore St
|
||||
|
|
@ -3369,7 +3369,7 @@ S: Germany
|
|||
|
||||
N: Robert Schwebel
|
||||
E: robert@schwebel.de
|
||||
W: http://www.schwebel.de
|
||||
W: https://www.schwebel.de
|
||||
D: Embedded hacker and book author,
|
||||
D: AMD Elan support for Linux
|
||||
S: Pengutronix
|
||||
|
|
@ -3545,7 +3545,7 @@ S: Australia
|
|||
N: Henrik Storner
|
||||
E: storner@image.dk
|
||||
W: http://www.image.dk/~storner/
|
||||
W: http://www.sslug.dk/
|
||||
W: https://www.sslug.dk/
|
||||
D: Configure script: Invented tristate for module-configuration
|
||||
D: vfat/msdos integration, kerneld docs, Linux promotion
|
||||
D: Miscellaneous bug-fixes
|
||||
|
|
@ -3579,7 +3579,7 @@ S: USA
|
|||
|
||||
N: Eugene Surovegin
|
||||
E: ebs@ebshome.net
|
||||
W: http://kernel.ebshome.net/
|
||||
W: https://kernel.ebshome.net/
|
||||
P: 1024D/AE5467F1 FF22 39F1 6728 89F6 6E6C 2365 7602 F33D AE54 67F1
|
||||
D: Embedded PowerPC 4xx: EMAC, I2C, PIC and random hacks/fixes
|
||||
S: Sunnyvale, California 94085
|
||||
|
|
@ -3609,7 +3609,7 @@ S: France
|
|||
|
||||
N: Urs Thuermann
|
||||
E: urs.thuermann@volkswagen.de
|
||||
W: http://www.volkswagen.de
|
||||
W: https://www.volkswagen.de
|
||||
D: Controller Area Network (network layer core)
|
||||
S: Brieffach 1776
|
||||
S: 38436 Wolfsburg
|
||||
|
|
@ -3656,7 +3656,7 @@ S: Canada K2L 1S2
|
|||
|
||||
N: Andrew Tridgell
|
||||
E: tridge@samba.org
|
||||
W: http://samba.org/tridge/
|
||||
W: https://samba.org/tridge/
|
||||
D: dosemu, networking, samba
|
||||
S: 3 Ballow Crescent
|
||||
S: MacGregor A.C.T 2615
|
||||
|
|
@ -3894,7 +3894,7 @@ D: The Linux Support Team Erlangen
|
|||
N: David Weinehall
|
||||
E: tao@acc.umu.se
|
||||
P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16
|
||||
W: http://www.acc.umu.se/~tao/
|
||||
W: https://www.acc.umu.se/~tao/
|
||||
D: v2.0 kernel maintainer
|
||||
D: Fixes for the NE/2-driver
|
||||
D: Miscellaneous MCA-support
|
||||
|
|
@ -3919,7 +3919,7 @@ S: USA
|
|||
N: Harald Welte
|
||||
E: laforge@netfilter.org
|
||||
P: 1024D/30F48BFF DBDE 6912 8831 9A53 879B 9190 5DA5 C655 30F4 8BFF
|
||||
W: http://gnumonks.org/users/laforge
|
||||
W: https://gnumonks.org/users/laforge
|
||||
D: netfilter: new nat helper infrastructure
|
||||
D: netfilter: ULOG, ECN, DSCP target
|
||||
D: netfilter: TTL match
|
||||
|
|
|
|||
|
|
@ -1,47 +1,47 @@
|
|||
What: sys/bus/dsa/devices/dsa<m>/version
|
||||
What: /sys/bus/dsa/devices/dsa<m>/version
|
||||
Date: Apr 15, 2020
|
||||
KernelVersion: 5.8.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The hardware version number.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/cdev_major
|
||||
What: /sys/bus/dsa/devices/dsa<m>/cdev_major
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The major number that the character device driver assigned to
|
||||
this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/errors
|
||||
What: /sys/bus/dsa/devices/dsa<m>/errors
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The error information for this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_batch_size
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_batch_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The largest number of work descriptors in a batch.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_work_queues_size
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum work queue size supported by this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_engines
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_engines
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum number of engines supported by this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_groups
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_groups
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum number of groups can be created under this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_tokens
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_tokens
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
@ -50,7 +50,7 @@ Description: The total number of bandwidth tokens supported by this device.
|
|||
implementation, and these resources are allocated by engines to
|
||||
support operations.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_transfer_size
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
@ -58,57 +58,57 @@ Description: The number of bytes to be read from the source address to
|
|||
perform the operation. The maximum transfer size is dependent on
|
||||
the workqueue the descriptor was submitted to.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/max_work_queues
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum work queue number that this device supports.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/numa_node
|
||||
What: /sys/bus/dsa/devices/dsa<m>/numa_node
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The numa node number for this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/op_cap
|
||||
What: /sys/bus/dsa/devices/dsa<m>/op_cap
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The operation capability bit mask specify the operation types
|
||||
supported by the this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/state
|
||||
What: /sys/bus/dsa/devices/dsa<m>/state
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The state information of this device. It can be either enabled
|
||||
or disabled.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/group<m>.<n>
|
||||
What: /sys/bus/dsa/devices/dsa<m>/group<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned group under this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/engine<m>.<n>
|
||||
What: /sys/bus/dsa/devices/dsa<m>/engine<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned engine under this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/wq<m>.<n>
|
||||
What: /sys/bus/dsa/devices/dsa<m>/wq<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned work queue under this device.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/configurable
|
||||
What: /sys/bus/dsa/devices/dsa<m>/configurable
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: To indicate if this device is configurable or not.
|
||||
|
||||
What: sys/bus/dsa/devices/dsa<m>/token_limit
|
||||
What: /sys/bus/dsa/devices/dsa<m>/token_limit
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
@ -116,19 +116,19 @@ Description: The maximum number of bandwidth tokens that may be in use at
|
|||
one time by operations that access low bandwidth memory in the
|
||||
device.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/group_id
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The group id that this work queue belongs to.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/size
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The work queue size for this work queue.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/type
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/type
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
@ -136,20 +136,20 @@ Description: The type of this work queue, it can be "kernel" type for work
|
|||
queue usages in the kernel space or "user" type for work queue
|
||||
usages by applications in user space.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/cdev_minor
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/cdev_minor
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The minor number assigned to this work queue by the character
|
||||
device driver.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/mode
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/mode
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The work queue mode type for this work queue.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/priority
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/priority
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
@ -157,20 +157,20 @@ Description: The priority value of this work queue, it is a vlue relative to
|
|||
other work queue in the same group to control quality of service
|
||||
for dispatching work from multiple workqueues in the same group.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/state
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/state
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The current state of the work queue.
|
||||
|
||||
What: sys/bus/dsa/devices/wq<m>.<n>/threshold
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/threshold
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The number of entries in this work queue that may be filled
|
||||
via a limited portal.
|
||||
|
||||
What: sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
|
|
|||
|
|
@ -206,3 +206,20 @@ Description: This file exposes the firmware version of burnable voltage
|
|||
regulator devices.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version_min
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version_min
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min
|
||||
Date: July 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD part numbers and minor
|
||||
versions have been burned CPLD devices equipped on a
|
||||
system.
|
||||
|
||||
The files are read only.
|
||||
|
|
|
|||
9
Documentation/ABI/testing/debugfs-turris-mox-rwtm
Normal file
9
Documentation/ABI/testing/debugfs-turris-mox-rwtm
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
What: /sys/kernel/debug/turris-mox-rwtm/do_sign
|
||||
Date: Jun 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Marek Behún <marek.behun@nic.cz>
|
||||
Description: (W) Message to sign with the ECDSA private key stored in
|
||||
device's OTP. The message must be exactly 64 bytes (since
|
||||
this is intended for SHA-512 hashes).
|
||||
(R) The resulting signature, 136 bytes. This contains the R and
|
||||
S values of the ECDSA signature, both in big-endian format.
|
||||
|
|
@ -56,6 +56,17 @@ Description: The /dev/kmsg character device node provides userspace access
|
|||
seek after the last record available at the time
|
||||
the last SYSLOG_ACTION_CLEAR was issued.
|
||||
|
||||
Other seek operations or offsets are not supported because of
|
||||
the special behavior this device has. The device allows to read
|
||||
or write only whole variable length messages (records) that are
|
||||
stored in a ring buffer.
|
||||
|
||||
Because of the non-standard behavior also the error values are
|
||||
non-standard. -ESPIPE is returned for non-zero offset. -EINVAL
|
||||
is returned for other operations, e.g. SEEK_CUR. This behavior
|
||||
and values are historical and could not be modified without the
|
||||
risk of breaking userspace.
|
||||
|
||||
The output format consists of a prefix carrying the syslog
|
||||
prefix including priority and facility, the 64 bit message
|
||||
sequence number and the monotonic timestamp in microseconds,
|
||||
|
|
|
|||
|
|
@ -273,6 +273,24 @@ Description:
|
|||
device ("host-aware" or "host-managed" zone model). For regular
|
||||
block devices, the value is always 0.
|
||||
|
||||
What: /sys/block/<disk>/queue/max_active_zones
|
||||
Date: July 2020
|
||||
Contact: Niklas Cassel <niklas.cassel@wdc.com>
|
||||
Description:
|
||||
For zoned block devices (zoned attribute indicating
|
||||
"host-managed" or "host-aware"), the sum of zones belonging to
|
||||
any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
|
||||
is limited by this value. If this value is 0, there is no limit.
|
||||
|
||||
What: /sys/block/<disk>/queue/max_open_zones
|
||||
Date: July 2020
|
||||
Contact: Niklas Cassel <niklas.cassel@wdc.com>
|
||||
Description:
|
||||
For zoned block devices (zoned attribute indicating
|
||||
"host-managed" or "host-aware"), the sum of zones belonging to
|
||||
any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN,
|
||||
is limited by this value. If this value is 0, there is no limit.
|
||||
|
||||
What: /sys/block/<disk>/queue/chunk_sectors
|
||||
Date: September 2016
|
||||
Contact: Hannes Reinecke <hare@suse.com>
|
||||
|
|
|
|||
|
|
@ -43,6 +43,13 @@ Description: read only
|
|||
This sysfs interface exposes the number of cores per chip
|
||||
present in the system.
|
||||
|
||||
What: /sys/devices/hv_24x7/interface/cpumask
|
||||
Date: July 2020
|
||||
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
Description: read only
|
||||
This sysfs file exposes the cpumask which is designated to make
|
||||
HCALLs to retrieve hv-24x7 pmu event counter data.
|
||||
|
||||
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
|
||||
Date: February 2014
|
||||
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
|
|
|
|||
|
|
@ -1569,7 +1569,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
|
|||
KernelVersion: 4.3
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) percentage reading of a substance.
|
||||
Raw (unscaled no offset etc.) reading of a substance. Units
|
||||
after application of scale and offset are percents.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
|
||||
|
|
|
|||
20
Documentation/ABI/testing/sysfs-bus-iio-icm42600
Normal file
20
Documentation/ABI/testing/sysfs-bus-iio-icm42600
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
|
||||
KernelVersion: 5.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Hardware applied calibration offset (assumed to fix production
|
||||
inaccuracies). Values represent a real physical offset expressed
|
||||
in SI units (m/s^2 for accelerometer and rad/s for gyroscope).
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available
|
||||
KernelVersion: 5.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Range of available values for hardware offset. Values in SI
|
||||
units (m/s^2 for accelerometer and rad/s for gyroscope).
|
||||
34
Documentation/ABI/testing/sysfs-bus-iio-scd30
Normal file
34
Documentation/ABI/testing/sysfs-bus-iio-scd30
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/calibration_auto_enable
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Contaminants build-up in the measurement chamber or optical
|
||||
elements deterioration leads to sensor drift.
|
||||
|
||||
One can compensate for sensor drift by using automatic self
|
||||
calibration procedure (asc).
|
||||
|
||||
Writing 1 or 0 to this attribute will respectively activate or
|
||||
deactivate asc.
|
||||
|
||||
Upon reading current asc status is returned.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Contaminants build-up in the measurement chamber or optical
|
||||
elements deterioration leads to sensor drift.
|
||||
|
||||
One can compensate for sensor drift by using forced
|
||||
recalibration (frc). This is useful in case there's known
|
||||
co2 reference available nearby the sensor.
|
||||
|
||||
Picking value from the range [400 1 2000] and writing it to the
|
||||
sensor will set frc.
|
||||
|
||||
Upon reading current frc value is returned. Note that after
|
||||
power cycling default value (i.e 400) is returned even though
|
||||
internally sensor had recalibrated itself.
|
||||
|
|
@ -202,6 +202,25 @@ Description:
|
|||
functions. See the section named 'NVDIMM Root Device _DSMs' in
|
||||
the ACPI specification.
|
||||
|
||||
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
|
||||
Date: Apr, 2020
|
||||
KernelVersion: v5.8
|
||||
Contact: linux-nvdimm@lists.01.org
|
||||
Description:
|
||||
(RW) The Intel platform implementation of firmware activate
|
||||
support exposes an option let the platform force idle devices in
|
||||
the system over the activation event, or trust that the OS will
|
||||
do it. The safe default is to let the platform force idle
|
||||
devices since the kernel is already in a suspend state, and on
|
||||
the chance that a driver does not properly quiesce bus-mastering
|
||||
after a suspend callback the platform will handle it. However,
|
||||
the activation might abort if, for example, platform firmware
|
||||
determines that the activation time exceeds the max PCI-E
|
||||
completion timeout. Since the platform does not know whether the
|
||||
OS is running the activation from a suspend context it aborts,
|
||||
but if the system owner trusts driver suspend callback to be
|
||||
sufficient then 'firmware_activation_noidle' can be
|
||||
enabled to bypass the activation abort.
|
||||
|
||||
What: /sys/bus/nd/devices/regionX/nfit/range_index
|
||||
Date: Jun, 2015
|
||||
|
|
|
|||
2
Documentation/ABI/testing/sysfs-bus-nvdimm
Normal file
2
Documentation/ABI/testing/sysfs-bus-nvdimm
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
The libnvdimm sub-system implements a common sysfs interface for
|
||||
platform nvdimm resources. See Documentation/driver-api/nvdimm/.
|
||||
8
Documentation/ABI/testing/sysfs-bus-optee-devices
Normal file
8
Documentation/ABI/testing/sysfs-bus-optee-devices
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/bus/tee/devices/optee-ta-<uuid>/
|
||||
Date: May 2020
|
||||
KernelVersion 5.8
|
||||
Contact: op-tee@lists.trustedfirmware.org
|
||||
Description:
|
||||
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
|
||||
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
|
||||
are free to create needed API under optee-ta-<uuid> directory.
|
||||
|
|
@ -25,3 +25,30 @@ Description:
|
|||
NVDIMM have been scrubbed.
|
||||
* "locked" : Indicating that NVDIMM contents cant
|
||||
be modified until next power cycle.
|
||||
|
||||
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
|
||||
Date: May, 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
|
||||
Description:
|
||||
(RO) Report various performance stats related to papr-scm NVDIMM
|
||||
device. Each stat is reported on a new line with each line
|
||||
composed of a stat-identifier followed by it value. Below are
|
||||
currently known dimm performance stats which are reported:
|
||||
|
||||
* "CtlResCt" : Controller Reset Count
|
||||
* "CtlResTm" : Controller Reset Elapsed Time
|
||||
* "PonSecs " : Power-on Seconds
|
||||
* "MemLife " : Life Remaining
|
||||
* "CritRscU" : Critical Resource Utilization
|
||||
* "HostLCnt" : Host Load Count
|
||||
* "HostSCnt" : Host Store Count
|
||||
* "HostSDur" : Host Store Duration
|
||||
* "HostLDur" : Host Load Duration
|
||||
* "MedRCnt " : Media Read Count
|
||||
* "MedWCnt " : Media Write Count
|
||||
* "MedRDur " : Media Read Duration
|
||||
* "MedWDur " : Media Write Duration
|
||||
* "CchRHCnt" : Cache Read Hit Count
|
||||
* "CchWHCnt" : Cache Write Hit Count
|
||||
* "FastWCnt" : Fast Write Count
|
||||
|
|
@ -18,3 +18,13 @@ Description:
|
|||
devices to opt-out of driver binding using a driver_override
|
||||
name such as "none". Only a single driver may be specified in
|
||||
the override, there is no support for parsing delimiters.
|
||||
|
||||
What: /sys/bus/platform/devices/.../numa_node
|
||||
Date: June 2020
|
||||
Contact: Barry Song <song.bao.hua@hisilicon.com>
|
||||
Description:
|
||||
This file contains the NUMA node to which the platform device
|
||||
is attached. It won't be visible if the node is unknown. The
|
||||
value comes from an ACPI _PXM method or a similar firmware
|
||||
source. Initial users for this file would be devices like
|
||||
arm smmu which are populated by arm64 acpi_iort.
|
||||
|
|
|
|||
|
|
@ -178,11 +178,18 @@ KernelVersion: 4.13
|
|||
Contact: thunderbolt-software@lists.01.org
|
||||
Description: When new NVM image is written to the non-active NVM
|
||||
area (through non_activeX NVMem device), the
|
||||
authentication procedure is started by writing 1 to
|
||||
this file. If everything goes well, the device is
|
||||
authentication procedure is started by writing to
|
||||
this file.
|
||||
If everything goes well, the device is
|
||||
restarted with the new NVM firmware. If the image
|
||||
verification fails an error code is returned instead.
|
||||
|
||||
This file will accept writing values "1" or "2"
|
||||
- Writing "1" will flush the image to the storage
|
||||
area and authenticate the image in one action.
|
||||
- Writing "2" will run some basic validation on the image
|
||||
and flush it to the storage area.
|
||||
|
||||
When read holds status of the last authentication
|
||||
operation if an error occurred during the process. This
|
||||
is directly the status value from the DMA configuration
|
||||
|
|
@ -236,3 +243,49 @@ KernelVersion: 4.15
|
|||
Contact: thunderbolt-software@lists.01.org
|
||||
Description: This contains XDomain service specific settings as
|
||||
bitmask. Format: %x
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/device
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: Retimer device identifier read from the hardware.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/nvm_authenticate
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: When new NVM image is written to the non-active NVM
|
||||
area (through non_activeX NVMem device), the
|
||||
authentication procedure is started by writing 1 to
|
||||
this file. If everything goes well, the device is
|
||||
restarted with the new NVM firmware. If the image
|
||||
verification fails an error code is returned instead.
|
||||
|
||||
When read holds status of the last authentication
|
||||
operation if an error occurred during the process.
|
||||
Format: %x.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/nvm_version
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: Holds retimer NVM version number. Format: %x.%x, major.minor.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/vendor
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: Retimer vendor identifier read from the hardware.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mario Limonciello <mario.limonciello@dell.com>
|
||||
Description: For supported devices, automatically authenticate the new Thunderbolt
|
||||
image when the device is disconnected from the host system.
|
||||
|
||||
This file will accept writing values "1" or "2"
|
||||
- Writing "1" will flush the image to the storage
|
||||
area and prepare the device for authentication on disconnect.
|
||||
- Writing "2" will run some basic validation on the image
|
||||
and flush it to the storage area.
|
||||
|
|
|
|||
|
|
@ -108,3 +108,15 @@ Description:
|
|||
frequency requested by governors and min_freq.
|
||||
The max_freq overrides min_freq because max_freq may be
|
||||
used to throttle devices to avoid overheating.
|
||||
|
||||
What: /sys/class/devfreq/.../timer
|
||||
Date: July 2020
|
||||
Contact: Chanwoo Choi <cw00.choi@samsung.com>
|
||||
Description:
|
||||
This ABI shows and stores the kind of work timer by users.
|
||||
This work timer is used by devfreq workqueue in order to
|
||||
monitor the device status such as utilization. The user
|
||||
can change the work timer on runtime according to their demand
|
||||
as following:
|
||||
echo deferrable > /sys/class/devfreq/.../timer
|
||||
echo delayed > /sys/class/devfreq/.../timer
|
||||
|
|
|
|||
126
Documentation/ABI/testing/sysfs-class-devlink
Normal file
126
Documentation/ABI/testing/sysfs-class-devlink
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
What: /sys/class/devlink/.../
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
Provide a place in sysfs for the device link objects in the
|
||||
kernel at any given time. The name of a device link directory,
|
||||
denoted as ... above, is of the form <supplier>--<consumer>
|
||||
where <supplier> is the supplier device name and <consumer> is
|
||||
the consumer device name.
|
||||
|
||||
What: /sys/class/devlink/.../auto_remove_on
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file indicates if the device link will ever be
|
||||
automatically removed by the driver core when the consumer and
|
||||
supplier devices themselves are still present.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'consumer unbind'
|
||||
'supplier unbind'
|
||||
'never'
|
||||
|
||||
'consumer unbind' means the device link will be removed when
|
||||
the consumer's driver is unbound from the consumer device.
|
||||
|
||||
'supplier unbind' means the device link will be removed when
|
||||
the supplier's driver is unbound from the supplier device.
|
||||
|
||||
'never' means the device link will not be automatically removed
|
||||
when as long as the supplier and consumer devices themselves
|
||||
are still present.
|
||||
|
||||
What: /sys/class/devlink/.../consumer
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file is a symlink to the consumer device's sysfs directory.
|
||||
|
||||
What: /sys/class/devlink/.../runtime_pm
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file indicates if the device link has any impact on the
|
||||
runtime power management behavior of the consumer and supplier
|
||||
devices. For example: Making sure the supplier doesn't enter
|
||||
runtime suspend while the consumer is active.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'0' - Does not affect runtime power management
|
||||
'1' - Affects runtime power management
|
||||
|
||||
What: /sys/class/devlink/.../status
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file indicates the status of the device link. The status
|
||||
of a device link is affected by whether the supplier and
|
||||
consumer devices have been bound to their corresponding
|
||||
drivers. The status of a device link also affects the binding
|
||||
and unbinding of the supplier and consumer devices with their
|
||||
drivers and also affects whether the software state of the
|
||||
supplier device is synced with the hardware state of the
|
||||
supplier device after boot up.
|
||||
See also: sysfs-devices-state_synced.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'not tracked'
|
||||
'dormant'
|
||||
'available'
|
||||
'consumer probing'
|
||||
'active'
|
||||
'supplier unbinding'
|
||||
'unknown'
|
||||
|
||||
'not tracked' means this device link does not track the status
|
||||
and has no impact on the binding, unbinding and syncing the
|
||||
hardware and software device state.
|
||||
|
||||
'dormant' means the supplier and the consumer devices have not
|
||||
bound to their driver.
|
||||
|
||||
'available' means the supplier has bound to its driver and is
|
||||
available to supply resources to the consumer device.
|
||||
|
||||
'consumer probing' means the consumer device is currently
|
||||
trying to bind to its driver.
|
||||
|
||||
'active' means the supplier and consumer devices have both
|
||||
bound successfully to their drivers.
|
||||
|
||||
'supplier unbinding' means the supplier devices is currently in
|
||||
the process of unbinding from its driver.
|
||||
|
||||
'unknown' means the state of the device link is not any of the
|
||||
above. If this is ever the value, there's a bug in the kernel.
|
||||
|
||||
What: /sys/class/devlink/.../supplier
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file is a symlink to the supplier device's sysfs directory.
|
||||
|
||||
What: /sys/class/devlink/.../sync_state_only
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
This file indicates if the device link is limited to only
|
||||
affecting the syncing of the hardware and software state of the
|
||||
supplier device.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'0'
|
||||
'1' - Affects runtime power management
|
||||
|
||||
'0' means the device link can affect other device behaviors
|
||||
like binding/unbinding, suspend/resume, runtime power
|
||||
management, etc.
|
||||
|
||||
'1' means the device link will only affect the syncing of
|
||||
hardware and software state of the supplier device after boot
|
||||
up and doesn't not affect other behaviors of the devices.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
What: /sys/class/leds/<led>/device/brightness
|
||||
Date: July 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Marek Behún <marek.behun@nic.cz>
|
||||
Description: (RW) On the front panel of the Turris Omnia router there is also
|
||||
a button which can be used to control the intensity of all the
|
||||
LEDs at once, so that if they are too bright, user can dim them.
|
||||
|
||||
The microcontroller cycles between 8 levels of this global
|
||||
brightness (from 100% to 0%), but this setting can have any
|
||||
integer value between 0 and 100. It is therefore convenient to be
|
||||
able to change this setting from software.
|
||||
|
||||
Format: %i
|
||||
35
Documentation/ABI/testing/sysfs-class-led-multicolor
Normal file
35
Documentation/ABI/testing/sysfs-class-led-multicolor
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
What: /sys/class/leds/<led>/brightness
|
||||
Date: March 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Dan Murphy <dmurphy@ti.com>
|
||||
Description: read/write
|
||||
Writing to this file will update all LEDs within the group to a
|
||||
calculated percentage of what each color LED intensity is set
|
||||
to. The percentage is calculated for each grouped LED via the
|
||||
equation below:
|
||||
|
||||
led_brightness = brightness * multi_intensity/max_brightness
|
||||
|
||||
For additional details please refer to
|
||||
Documentation/leds/leds-class-multicolor.rst.
|
||||
|
||||
The value of the LED is from 0 to
|
||||
/sys/class/leds/<led>/max_brightness.
|
||||
|
||||
What: /sys/class/leds/<led>/multi_index
|
||||
Date: March 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Dan Murphy <dmurphy@ti.com>
|
||||
Description: read
|
||||
The multi_index array, when read, will output the LED colors
|
||||
as an array of strings as they are indexed in the
|
||||
multi_intensity file.
|
||||
|
||||
What: /sys/class/leds/<led>/multi_intensity
|
||||
Date: March 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Dan Murphy <dmurphy@ti.com>
|
||||
Description: read/write
|
||||
This file contains array of integers. Order of components is
|
||||
described by the multi_index array. The maximum intensity should
|
||||
not exceed /sys/class/leds/<led>/max_brightness.
|
||||
|
|
@ -90,3 +90,16 @@ Description: Display trc status register content
|
|||
The ME FW writes Glitch Detection HW (TRC)
|
||||
status information into trc status register
|
||||
for BIOS and OS to monitor fw health.
|
||||
|
||||
What: /sys/class/mei/meiN/kind
|
||||
Date: Jul 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Tomas Winkler <tomas.winkler@intel.com>
|
||||
Description: Display kind of the device
|
||||
|
||||
Generic devices are marked as "mei"
|
||||
while special purpose have their own
|
||||
names.
|
||||
Available options:
|
||||
- mei: generic mei device.
|
||||
- itouch: itouch (ipts) mei device.
|
||||
|
|
|
|||
|
|
@ -33,3 +33,14 @@ Date: January 2018
|
|||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
Give access the global mmio area for the AFU
|
||||
|
||||
What: /sys/class/ocxl/<afu name>/reload_on_reset
|
||||
Date: February 2020
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
Control whether the FPGA is reloaded on a link reset. Enabled
|
||||
through a vendor-specific logic block on the FPGA.
|
||||
0 Do not reload FPGA image from flash
|
||||
1 Reload FPGA image from flash
|
||||
unavailable
|
||||
The device does not support this capability
|
||||
|
|
|
|||
|
|
@ -205,7 +205,8 @@ Description:
|
|||
Valid values: "Unknown", "Good", "Overheat", "Dead",
|
||||
"Over voltage", "Unspecified failure", "Cold",
|
||||
"Watchdog timer expire", "Safety timer expire",
|
||||
"Over current", "Calibration required"
|
||||
"Over current", "Calibration required", "Warm",
|
||||
"Cool", "Hot"
|
||||
|
||||
What: /sys/class/power_supply/<supply_name>/precharge_current
|
||||
Date: June 2017
|
||||
|
|
|
|||
|
|
@ -14,6 +14,10 @@ Description:
|
|||
Charging begins when level drops below
|
||||
charge_control_start_threshold, and ceases when
|
||||
level is above charge_control_end_threshold.
|
||||
Long Life: Customized charge rate for last longer battery life.
|
||||
On Wilco device this mode is pre-configured in the factory
|
||||
through EC's private PID. Swiching to a different mode will
|
||||
be denied by Wilco EC when Long Life mode is enabled.
|
||||
|
||||
What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold
|
||||
Date: April 2019
|
||||
|
|
|
|||
8
Documentation/ABI/testing/sysfs-devices-consumer
Normal file
8
Documentation/ABI/testing/sysfs-devices-consumer
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/devices/.../consumer:<consumer>
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
The /sys/devices/.../consumer:<consumer> are symlinks to device
|
||||
links where this device is the supplier. <consumer> denotes the
|
||||
name of the consumer in that device link. There can be zero or
|
||||
more of these symlinks for a given device.
|
||||
33
Documentation/ABI/testing/sysfs-devices-mapping
Normal file
33
Documentation/ABI/testing/sysfs-devices-mapping
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
What: /sys/devices/uncore_iio_x/dieX
|
||||
Date: February 2020
|
||||
Contact: Roman Sudarikov <roman.sudarikov@linux.intel.com>
|
||||
Description:
|
||||
Each IIO stack (PCIe root port) has its own IIO PMON block, so
|
||||
each dieX file (where X is die number) holds "Segment:Root Bus"
|
||||
for PCIe root port, which can be monitored by that IIO PMON
|
||||
block.
|
||||
For example, on 4-die Xeon platform with up to 6 IIO stacks per
|
||||
die and, therefore, 6 IIO PMON blocks per die, the mapping of
|
||||
IIO PMON block 0 exposes as the following:
|
||||
|
||||
$ ls /sys/devices/uncore_iio_0/die*
|
||||
-r--r--r-- /sys/devices/uncore_iio_0/die0
|
||||
-r--r--r-- /sys/devices/uncore_iio_0/die1
|
||||
-r--r--r-- /sys/devices/uncore_iio_0/die2
|
||||
-r--r--r-- /sys/devices/uncore_iio_0/die3
|
||||
|
||||
$ tail /sys/devices/uncore_iio_0/die*
|
||||
==> /sys/devices/uncore_iio_0/die0 <==
|
||||
0000:00
|
||||
==> /sys/devices/uncore_iio_0/die1 <==
|
||||
0000:40
|
||||
==> /sys/devices/uncore_iio_0/die2 <==
|
||||
0000:80
|
||||
==> /sys/devices/uncore_iio_0/die3 <==
|
||||
0000:c0
|
||||
|
||||
Which means:
|
||||
IIO PMU 0 on die 0 belongs to PCI RP on bus 0x00, domain 0x0000
|
||||
IIO PMU 0 on die 1 belongs to PCI RP on bus 0x40, domain 0x0000
|
||||
IIO PMU 0 on die 2 belongs to PCI RP on bus 0x80, domain 0x0000
|
||||
IIO PMU 0 on die 3 belongs to PCI RP on bus 0xc0, domain 0x0000
|
||||
|
|
@ -126,3 +126,39 @@ Description:
|
|||
1 no action
|
||||
0 firmware record the notify code defined
|
||||
in b[15:0].
|
||||
|
||||
What: /sys/devices/platform/stratix10-rsu.0/dcmf0
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Richard Gong <richard.gong@linux.intel.com>
|
||||
Description:
|
||||
(RO) Decision firmware copy 0 version information.
|
||||
|
||||
What: /sys/devices/platform/stratix10-rsu.0/dcmf1
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Richard Gong <richard.gong@linux.intel.com>
|
||||
Description:
|
||||
(RO) Decision firmware copy 1 version information.
|
||||
|
||||
What: /sys/devices/platform/stratix10-rsu.0/dcmf2
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Richard Gong <richard.gong@linux.intel.com>
|
||||
Description:
|
||||
(RO) Decision firmware copy 2 version information.
|
||||
|
||||
What: /sys/devices/platform/stratix10-rsu.0/dcmf3
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Richard Gong <richard.gong@linux.intel.com>
|
||||
Description:
|
||||
(RO) Decision firmware copy 3 version information.
|
||||
|
||||
What: /sys/devices/platform/stratix10-rsu.0/max_retry
|
||||
Date: June 2020
|
||||
KernelVersion: 5.8
|
||||
Contact: Richard Gong <richard.gong@linux.intel.com>
|
||||
Description:
|
||||
(RO) max retry parameter is stored in the firmware
|
||||
decision IO section, as a byte located at offset 0x18c.
|
||||
|
|
|
|||
|
|
@ -26,6 +26,30 @@ Description:
|
|||
Read-only attribute common to all SoCs. Contains SoC family name
|
||||
(e.g. DB8500).
|
||||
|
||||
On many of ARM based silicon with SMCCC v1.2+ compliant firmware
|
||||
this will contain the JEDEC JEP106 manufacturer’s identification
|
||||
code. The format is "jep106:XXYY" where XX is identity code and
|
||||
YY is continuation code.
|
||||
|
||||
This manufacturer’s identification code is defined by one
|
||||
or more eight (8) bit fields, each consisting of seven (7)
|
||||
data bits plus one (1) odd parity bit. It is a single field,
|
||||
limiting the possible number of vendors to 126. To expand
|
||||
the maximum number of identification codes, a continuation
|
||||
scheme has been defined.
|
||||
|
||||
The specified mechanism is that an identity code of 0x7F
|
||||
represents the "continuation code" and implies the presence
|
||||
of an additional identity code field, and this mechanism
|
||||
may be extended to multiple continuation codes followed
|
||||
by the manufacturer's identity code.
|
||||
|
||||
For example, ARM has identity code 0x7F 0x7F 0x7F 0x7F 0x3B,
|
||||
which is code 0x3B on the fifth 'page'. This is shortened
|
||||
as JEP106 identity code of 0x3B and a continuation code of
|
||||
0x4 to represent the four continuation codes preceding the
|
||||
identity code.
|
||||
|
||||
What: /sys/devices/socX/serial_number
|
||||
Date: January 2019
|
||||
contact: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
|
|
@ -40,6 +64,12 @@ Description:
|
|||
Read-only attribute supported by most SoCs. In the case of
|
||||
ST-Ericsson's chips this contains the SoC serial number.
|
||||
|
||||
On many of ARM based silicon with SMCCC v1.2+ compliant firmware
|
||||
this will contain the SOC ID appended to the family attribute
|
||||
to ensure there is no conflict in this namespace across various
|
||||
vendors. The format is "jep106:XXYY:ZZZZ" where XX is identity
|
||||
code, YY is continuation code and ZZZZ is the SOC ID.
|
||||
|
||||
What: /sys/devices/socX/revision
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
|
|
|
|||
24
Documentation/ABI/testing/sysfs-devices-state_synced
Normal file
24
Documentation/ABI/testing/sysfs-devices-state_synced
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
What: /sys/devices/.../state_synced
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
The /sys/devices/.../state_synced attribute is only present for
|
||||
devices whose bus types or driver provides the .sync_state()
|
||||
callback. The number read from it (0 or 1) reflects the value
|
||||
of the device's 'state_synced' field. A value of 0 means the
|
||||
.sync_state() callback hasn't been called yet. A value of 1
|
||||
means the .sync_state() callback has been called.
|
||||
|
||||
Generally, if a device has sync_state() support and has some of
|
||||
the resources it provides enabled at the time the kernel starts
|
||||
(Eg: enabled by hardware reset or bootloader or anything that
|
||||
run before the kernel starts), then it'll keep those resources
|
||||
enabled and in a state that's compatible with the state they
|
||||
were in at the start of the kernel. The device will stop doing
|
||||
this only when the sync_state() callback has been called --
|
||||
which happens only when all its consumer devices are registered
|
||||
and have probed successfully. Resources that were left disabled
|
||||
at the time the kernel starts are not affected or limited in
|
||||
any way by sync_state() callbacks.
|
||||
|
||||
|
||||
8
Documentation/ABI/testing/sysfs-devices-supplier
Normal file
8
Documentation/ABI/testing/sysfs-devices-supplier
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/devices/.../supplier:<supplier>
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
The /sys/devices/.../supplier:<supplier> are symlinks to device
|
||||
links where this device is the consumer. <supplier> denotes the
|
||||
name of the supplier in that device link. There can be zero or
|
||||
more of these symlinks for a given device.
|
||||
17
Documentation/ABI/testing/sysfs-devices-waiting_for_supplier
Normal file
17
Documentation/ABI/testing/sysfs-devices-waiting_for_supplier
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
What: /sys/devices/.../waiting_for_supplier
|
||||
Date: May 2020
|
||||
Contact: Saravana Kannan <saravanak@google.com>
|
||||
Description:
|
||||
The /sys/devices/.../waiting_for_supplier attribute is only
|
||||
present when fw_devlink kernel command line option is enabled
|
||||
and is set to something stricter than "permissive". It is
|
||||
removed once a device probes successfully (because the
|
||||
information is no longer relevant). The number read from it (0
|
||||
or 1) reflects whether the device is waiting for one or more
|
||||
suppliers to be added and then linked to using device links
|
||||
before the device can probe.
|
||||
|
||||
A value of 0 means the device is not waiting for any suppliers
|
||||
to be added before it can probe. A value of 1 means the device
|
||||
is waiting for one or more suppliers to be added before it can
|
||||
probe.
|
||||
15
Documentation/ABI/testing/sysfs-driver-input-exc3000
Normal file
15
Documentation/ABI/testing/sysfs-driver-input-exc3000
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/bus/i2c/devices/xxx/fw_version
|
||||
Date: Aug 2020
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: Reports the firmware version provided by the touchscreen, for example "00_T6" on a EXC80H60
|
||||
|
||||
Access: Read
|
||||
Valid values: Represented as string
|
||||
|
||||
What: /sys/bus/i2c/devices/xxx/model
|
||||
Date: Aug 2020
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: Reports the model identification provided by the touchscreen, for example "Orion_1320" on a EXC80H60
|
||||
|
||||
Access: Read
|
||||
Valid values: Represented as string
|
||||
|
|
@ -883,3 +883,139 @@ Contact: Subhash Jadavani <subhashj@codeaurora.org>
|
|||
Description: This entry shows the target state of an UFS UIC link
|
||||
for the chosen system power management level.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows if preserve user-space was configured
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the shared allocated units of WB buffer
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the configured WB type.
|
||||
0x1 for shared buffer mode. 0x0 for dedicated buffer mode.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the total user-space decrease in shared
|
||||
buffer mode.
|
||||
The value of this parameter is 3 for TLC NAND when SLC mode
|
||||
is used as WriteBooster Buffer. 2 for MLC NAND.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the Maximum total WriteBooster Buffer size
|
||||
which is supported by the entire device.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the maximum number of luns that can support
|
||||
WriteBooster.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: The supportability of user space reduction mode
|
||||
and preserve user space mode.
|
||||
00h: WriteBooster Buffer can be configured only in
|
||||
user space reduction type.
|
||||
01h: WriteBooster Buffer can be configured only in
|
||||
preserve user space type.
|
||||
02h: Device can be configured in either user space
|
||||
reduction type or preserve user space type.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: The supportability of WriteBooster Buffer type.
|
||||
00h: LU based WriteBooster Buffer configuration
|
||||
01h: Single shared WriteBooster Buffer
|
||||
configuration
|
||||
02h: Supporting both LU based WriteBooster
|
||||
Buffer and Single shared WriteBooster Buffer
|
||||
configuration
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the status of WriteBooster.
|
||||
0: WriteBooster is not enabled.
|
||||
1: WriteBooster is enabled
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows if flush is enabled.
|
||||
0: Flush operation is not performed.
|
||||
1: Flush operation is performed.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: Flush WriteBooster Buffer during hibernate state.
|
||||
0: Device is not allowed to flush the
|
||||
WriteBooster Buffer during link hibernate
|
||||
state.
|
||||
1: Device is allowed to flush the
|
||||
WriteBooster Buffer during link hibernate
|
||||
state
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the amount of unused WriteBooster buffer
|
||||
available.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the amount of unused current buffer.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the flush operation status.
|
||||
00h: idle
|
||||
01h: Flush operation in progress
|
||||
02h: Flush operation stopped prematurely.
|
||||
03h: Flush operation completed successfully
|
||||
04h: Flush operation general failure
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows an indication of the WriteBooster Buffer
|
||||
lifetime based on the amount of performed program/erase cycles
|
||||
01h: 0% - 10% WriteBooster Buffer life time used
|
||||
...
|
||||
0Ah: 90% - 100% WriteBooster Buffer life time used
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units
|
||||
Date: June 2020
|
||||
Contact: Asutosh Das <asutoshd@codeaurora.org>
|
||||
Description: This entry shows the configured size of WriteBooster buffer.
|
||||
0400h corresponds to 4GB.
|
||||
The file is read only.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Description:
|
|||
to device min/max capabilities. Values are integer as they are
|
||||
stored in a 8bit register in the device. Lowest value is
|
||||
automatically put to TL. Once set, alarms could be search at
|
||||
master level, refer to Documentation/w1/w1_generic.rst for
|
||||
master level, refer to Documentation/w1/w1-generic.rst for
|
||||
detailed information
|
||||
Users: any user space application which wants to communicate with
|
||||
w1_term device
|
||||
|
|
|
|||
|
|
@ -229,7 +229,9 @@ Date: August 2017
|
|||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description: Do background GC agressively when set. When gc_urgent = 1,
|
||||
background thread starts to do GC by given gc_urgent_sleep_time
|
||||
interval. It is set to 0 by default.
|
||||
interval. When gc_urgent = 2, F2FS will lower the bar of
|
||||
checking idle in order to process outstanding discard commands
|
||||
and GC a little bit aggressively. It is set to 0 by default.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
|
||||
Date: August 2017
|
||||
|
|
|
|||
26
Documentation/PCI/endpoint/function/binding/pci-test.rst
Normal file
26
Documentation/PCI/endpoint/function/binding/pci-test.rst
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================
|
||||
PCI Test Endpoint Function
|
||||
==========================
|
||||
|
||||
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
|
||||
|
||||
Configurable Fields:
|
||||
|
||||
================ ===========================================================
|
||||
vendorid should be 0x104c
|
||||
deviceid should be 0xb500 for DRA74x and 0xb501 for DRA72x
|
||||
revid don't care
|
||||
progif_code don't care
|
||||
subclass_code don't care
|
||||
baseclass_code should be 0xff
|
||||
cache_line_size don't care
|
||||
subsys_vendor_id don't care
|
||||
subsys_id don't care
|
||||
interrupt_pin Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
||||
msi_interrupts Should be 1 to 32 depending on the number of MSI interrupts
|
||||
to test
|
||||
msix_interrupts Should be 1 to 2048 depending on the number of MSI-X
|
||||
interrupts to test
|
||||
================ ===========================================================
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
PCI TEST ENDPOINT FUNCTION
|
||||
|
||||
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
|
||||
|
||||
Configurable Fields:
|
||||
vendorid : should be 0x104c
|
||||
deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x
|
||||
revid : don't care
|
||||
progif_code : don't care
|
||||
subclass_code : don't care
|
||||
baseclass_code : should be 0xff
|
||||
cache_line_size : don't care
|
||||
subsys_vendor_id : don't care
|
||||
subsys_id : don't care
|
||||
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
||||
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
|
||||
to test
|
||||
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
|
||||
interrupts to test
|
||||
|
|
@ -11,3 +11,5 @@ PCI Endpoint Framework
|
|||
pci-endpoint-cfs
|
||||
pci-test-function
|
||||
pci-test-howto
|
||||
|
||||
function/binding/pci-test
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Directory Structure
|
|||
|
||||
The pci_ep configfs has two directories at its root: controllers and
|
||||
functions. Every EPC device present in the system will have an entry in
|
||||
the *controllers* directory and and every EPF driver present in the system
|
||||
the *controllers* directory and every EPF driver present in the system
|
||||
will have an entry in the *functions* directory.
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ pci-ep-cfs.c can be used as reference for using these APIs.
|
|||
* pci_epf_create()
|
||||
|
||||
Create a new PCI EPF device by passing the name of the PCI EPF device.
|
||||
This name will be used to bind the the EPF device to a EPF driver.
|
||||
This name will be used to bind the EPF device to a EPF driver.
|
||||
|
||||
* pci_epf_destroy()
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ This structure has the form::
|
|||
|
||||
struct pci_error_handlers
|
||||
{
|
||||
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
|
||||
int (*error_detected)(struct pci_dev *dev, pci_channel_state_t);
|
||||
int (*mmio_enabled)(struct pci_dev *dev);
|
||||
int (*slot_reset)(struct pci_dev *dev);
|
||||
void (*resume)(struct pci_dev *dev);
|
||||
|
|
@ -87,11 +87,11 @@ This structure has the form::
|
|||
|
||||
The possible channel states are::
|
||||
|
||||
enum pci_channel_state {
|
||||
typedef enum {
|
||||
pci_channel_io_normal, /* I/O channel is in normal state */
|
||||
pci_channel_io_frozen, /* I/O to channel is blocked */
|
||||
pci_channel_io_perm_failure, /* PCI card is dead */
|
||||
};
|
||||
} pci_channel_state_t;
|
||||
|
||||
Possible return values are::
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ STEP 4: Slot Reset
|
|||
------------------
|
||||
|
||||
In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
|
||||
the platform will perform a slot reset on the requesting PCI device(s).
|
||||
platform will perform a slot reset on the requesting PCI device(s).
|
||||
The actual steps taken by a platform to perform a slot reset
|
||||
will be platform-dependent. Upon completion of slot reset, the
|
||||
platform will call the device slot_reset() callback.
|
||||
|
|
@ -348,7 +348,7 @@ STEP 6: Permanent Failure
|
|||
-------------------------
|
||||
A "permanent failure" has occurred, and the platform cannot recover
|
||||
the device. The platform will call error_detected() with a
|
||||
pci_channel_state value of pci_channel_io_perm_failure.
|
||||
pci_channel_state_t value of pci_channel_io_perm_failure.
|
||||
|
||||
The device driver should, at this point, assume the worst. It should
|
||||
cancel all pending I/O, refuse all new I/O, returning -EIO to
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ PCI device drivers.
|
|||
A more complete resource is the third edition of "Linux Device Drivers"
|
||||
by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman.
|
||||
LDD3 is available for free (under Creative Commons License) from:
|
||||
http://lwn.net/Kernel/LDD3/.
|
||||
https://lwn.net/Kernel/LDD3/.
|
||||
|
||||
However, keep in mind that all documents are subject to "bit rot".
|
||||
Refer to the source code if things are not working as described here.
|
||||
|
|
@ -209,12 +209,12 @@ the PCI device by calling pci_enable_device(). This will:
|
|||
OS BUG: we don't check resource allocations before enabling those
|
||||
resources. The sequence would make more sense if we called
|
||||
pci_request_resources() before calling pci_enable_device().
|
||||
Currently, the device drivers can't detect the bug when when two
|
||||
Currently, the device drivers can't detect the bug when two
|
||||
devices have been allocated the same range. This is not a common
|
||||
problem and unlikely to get fixed soon.
|
||||
|
||||
This has been discussed before but not changed as of 2.6.19:
|
||||
http://lkml.org/lkml/2006/3/2/194
|
||||
https://lore.kernel.org/r/20060302180025.GC28895@flint.arm.linux.org.uk/
|
||||
|
||||
|
||||
pci_set_master() will enable DMA by setting the bus master bit
|
||||
|
|
@ -265,7 +265,7 @@ Set the DMA mask size
|
|||
---------------------
|
||||
.. note::
|
||||
If anything below doesn't make sense, please refer to
|
||||
Documentation/DMA-API.txt. This section is just a reminder that
|
||||
:doc:`/core-api/dma-api`. This section is just a reminder that
|
||||
drivers need to indicate DMA capabilities of the device and is not
|
||||
an authoritative source for DMA interfaces.
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are
|
|||
Setup shared control data
|
||||
-------------------------
|
||||
Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared)
|
||||
memory. See Documentation/DMA-API.txt for a full description of
|
||||
memory. See :doc:`/core-api/dma-api` for a full description of
|
||||
the DMA APIs. This section is just a reminder that it needs to be done
|
||||
before enabling DMA on the device.
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ owners if there is one.
|
|||
|
||||
Then clean up "consistent" buffers which contain the control data.
|
||||
|
||||
See Documentation/DMA-API.txt for details on unmapping interfaces.
|
||||
See :doc:`/core-api/dma-api` for details on unmapping interfaces.
|
||||
|
||||
|
||||
Unregister from other subsystems
|
||||
|
|
@ -514,9 +514,8 @@ your driver if they're helpful, or just use plain hex constants.
|
|||
The device IDs are arbitrary hex numbers (vendor controlled) and normally used
|
||||
only in a single location, the pci_device_id table.
|
||||
|
||||
Please DO submit new vendor/device IDs to http://pci-ids.ucw.cz/.
|
||||
There are mirrors of the pci.ids file at http://pciids.sourceforge.net/
|
||||
and https://github.com/pciutils/pciids.
|
||||
Please DO submit new vendor/device IDs to https://pci-ids.ucw.cz/.
|
||||
There's a mirror of the pci.ids file at https://github.com/pciutils/pciids.
|
||||
|
||||
|
||||
Obsolete functions
|
||||
|
|
|
|||
|
|
@ -463,7 +463,7 @@ again without disrupting RCU readers.
|
|||
This guarantee was only partially premeditated. DYNIX/ptx used an
|
||||
explicit memory barrier for publication, but had nothing resembling
|
||||
``rcu_dereference()`` for subscription, nor did it have anything
|
||||
resembling the ``smp_read_barrier_depends()`` that was later subsumed
|
||||
resembling the dependency-ordering barrier that was later subsumed
|
||||
into ``rcu_dereference()`` and later still into ``READ_ONCE()``. The
|
||||
need for these operations made itself known quite suddenly at a
|
||||
late-1990s meeting with the DEC Alpha architects, back in the days when
|
||||
|
|
@ -2583,7 +2583,12 @@ not work to have these markers in the trampoline itself, because there
|
|||
would need to be instructions following ``rcu_read_unlock()``. Although
|
||||
``synchronize_rcu()`` would guarantee that execution reached the
|
||||
``rcu_read_unlock()``, it would not be able to guarantee that execution
|
||||
had completely left the trampoline.
|
||||
had completely left the trampoline. Worse yet, in some situations
|
||||
the trampoline's protection must extend a few instructions *prior* to
|
||||
execution reaching the trampoline. For example, these few instructions
|
||||
might calculate the address of the trampoline, so that entering the
|
||||
trampoline would be pre-ordained a surprisingly long time before execution
|
||||
actually reached the trampoline itself.
|
||||
|
||||
The solution, in the form of `Tasks
|
||||
RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side
|
||||
|
|
|
|||
|
|
@ -1,4 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================================
|
||||
Review Checklist for RCU Patches
|
||||
================================
|
||||
|
||||
|
||||
This document contains a checklist for producing and reviewing patches
|
||||
|
|
@ -411,18 +415,21 @@ over a rather long period of time, but improvements are always welcome!
|
|||
__rcu sparse checks to validate your RCU code. These can help
|
||||
find problems as follows:
|
||||
|
||||
CONFIG_PROVE_LOCKING: check that accesses to RCU-protected data
|
||||
CONFIG_PROVE_LOCKING:
|
||||
check that accesses to RCU-protected data
|
||||
structures are carried out under the proper RCU
|
||||
read-side critical section, while holding the right
|
||||
combination of locks, or whatever other conditions
|
||||
are appropriate.
|
||||
|
||||
CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the
|
||||
CONFIG_DEBUG_OBJECTS_RCU_HEAD:
|
||||
check that you don't pass the
|
||||
same object to call_rcu() (or friends) before an RCU
|
||||
grace period has elapsed since the last time that you
|
||||
passed that same object to call_rcu() (or friends).
|
||||
|
||||
__rcu sparse checks: tag the pointer to the RCU-protected data
|
||||
__rcu sparse checks:
|
||||
tag the pointer to the RCU-protected data
|
||||
structure with __rcu, and sparse will warn you if you
|
||||
access that pointer without the services of one of the
|
||||
variants of rcu_dereference().
|
||||
|
|
@ -442,8 +449,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||
|
||||
You instead need to use one of the barrier functions:
|
||||
|
||||
o call_rcu() -> rcu_barrier()
|
||||
o call_srcu() -> srcu_barrier()
|
||||
- call_rcu() -> rcu_barrier()
|
||||
- call_srcu() -> srcu_barrier()
|
||||
|
||||
However, these barrier functions are absolutely -not- guaranteed
|
||||
to wait for a grace period. In fact, if there are no call_rcu()
|
||||
|
|
@ -1,3 +1,5 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. _rcu_concepts:
|
||||
|
||||
============
|
||||
|
|
@ -8,10 +10,17 @@ RCU concepts
|
|||
:maxdepth: 3
|
||||
|
||||
arrayRCU
|
||||
checklist
|
||||
lockdep
|
||||
lockdep-splat
|
||||
rcubarrier
|
||||
rcu_dereference
|
||||
whatisRCU
|
||||
rcu
|
||||
rculist_nulls
|
||||
rcuref
|
||||
torture
|
||||
stallwarn
|
||||
listRCU
|
||||
NMI-RCU
|
||||
UP
|
||||
|
|
|
|||
|
|
@ -1,3 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
Lockdep-RCU Splat
|
||||
=================
|
||||
|
||||
Lockdep-RCU was added to the Linux kernel in early 2010
|
||||
(http://lwn.net/Articles/371986/). This facility checks for some common
|
||||
misuses of the RCU API, most notably using one of the rcu_dereference()
|
||||
|
|
@ -12,55 +18,54 @@ overwriting or worse. There can of course be false positives, this
|
|||
being the real world and all that.
|
||||
|
||||
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
|
||||
has long since been fixed:
|
||||
has long since been fixed::
|
||||
|
||||
=============================
|
||||
WARNING: suspicious RCU usage
|
||||
-----------------------------
|
||||
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
|
||||
=============================
|
||||
WARNING: suspicious RCU usage
|
||||
-----------------------------
|
||||
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
|
||||
|
||||
other info that might help us debug this:
|
||||
other info that might help us debug this::
|
||||
|
||||
rcu_scheduler_active = 1, debug_locks = 0
|
||||
3 locks held by scsi_scan_6/1552:
|
||||
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
|
||||
scsi_scan_host_selected+0x5a/0x150
|
||||
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
|
||||
elevator_exit+0x22/0x60
|
||||
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
|
||||
cfq_exit_queue+0x43/0x190
|
||||
|
||||
rcu_scheduler_active = 1, debug_locks = 0
|
||||
3 locks held by scsi_scan_6/1552:
|
||||
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
|
||||
scsi_scan_host_selected+0x5a/0x150
|
||||
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
|
||||
elevator_exit+0x22/0x60
|
||||
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
|
||||
cfq_exit_queue+0x43/0x190
|
||||
stack backtrace:
|
||||
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
|
||||
Call Trace:
|
||||
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
|
||||
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
|
||||
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
|
||||
[<ffffffff812a5046>] elevator_exit+0x36/0x60
|
||||
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
|
||||
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
|
||||
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
|
||||
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
|
||||
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
|
||||
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
|
||||
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
|
||||
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
|
||||
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
|
||||
[<ffffffff8145f170>] do_scan_async+0x20/0x160
|
||||
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
|
||||
[<ffffffff810975b6>] kthread+0xa6/0xb0
|
||||
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
|
||||
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
|
||||
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
|
||||
[<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
|
||||
[<ffffffff817db150>] ? gs_change+0xb/0xb
|
||||
|
||||
stack backtrace:
|
||||
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
|
||||
Call Trace:
|
||||
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
|
||||
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
|
||||
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
|
||||
[<ffffffff812a5046>] elevator_exit+0x36/0x60
|
||||
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
|
||||
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
|
||||
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
|
||||
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
|
||||
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
|
||||
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
|
||||
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
|
||||
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
|
||||
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
|
||||
[<ffffffff8145f170>] do_scan_async+0x20/0x160
|
||||
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
|
||||
[<ffffffff810975b6>] kthread+0xa6/0xb0
|
||||
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
|
||||
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
|
||||
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
|
||||
[<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
|
||||
[<ffffffff817db150>] ? gs_change+0xb/0xb
|
||||
|
||||
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
|
||||
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows::
|
||||
|
||||
if (rcu_dereference(ioc->ioc_data) == cic) {
|
||||
|
||||
|
|
@ -70,7 +75,7 @@ case. Instead, we hold three locks, one of which might be RCU related.
|
|||
And maybe that lock really does protect this reference. If so, the fix
|
||||
is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
|
||||
take the struct request_queue "q" from cfq_exit_queue() as an argument,
|
||||
which would permit us to invoke rcu_dereference_protected as follows:
|
||||
which would permit us to invoke rcu_dereference_protected as follows::
|
||||
|
||||
if (rcu_dereference_protected(ioc->ioc_data,
|
||||
lockdep_is_held(&q->queue_lock)) == cic) {
|
||||
|
|
@ -85,7 +90,7 @@ On the other hand, perhaps we really do need an RCU read-side critical
|
|||
section. In this case, the critical section must span the use of the
|
||||
return value from rcu_dereference(), or at least until there is some
|
||||
reference count incremented or some such. One way to handle this is to
|
||||
add rcu_read_lock() and rcu_read_unlock() as follows:
|
||||
add rcu_read_lock() and rcu_read_unlock() as follows::
|
||||
|
||||
rcu_read_lock();
|
||||
if (rcu_dereference(ioc->ioc_data) == cic) {
|
||||
|
|
@ -102,7 +107,7 @@ above lockdep-RCU splat.
|
|||
But in this particular case, we don't actually dereference the pointer
|
||||
returned from rcu_dereference(). Instead, that pointer is just compared
|
||||
to the cic pointer, which means that the rcu_dereference() can be replaced
|
||||
by rcu_access_pointer() as follows:
|
||||
by rcu_access_pointer() as follows::
|
||||
|
||||
if (rcu_access_pointer(ioc->ioc_data) == cic) {
|
||||
|
||||
|
|
@ -1,4 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================
|
||||
RCU and lockdep checking
|
||||
========================
|
||||
|
||||
All flavors of RCU have lockdep checking available, so that lockdep is
|
||||
aware of when each task enters and leaves any flavor of RCU read-side
|
||||
|
|
@ -8,7 +12,7 @@ tracking to include RCU state, which can sometimes help when debugging
|
|||
deadlocks and the like.
|
||||
|
||||
In addition, RCU provides the following primitives that check lockdep's
|
||||
state:
|
||||
state::
|
||||
|
||||
rcu_read_lock_held() for normal RCU.
|
||||
rcu_read_lock_bh_held() for RCU-bh.
|
||||
|
|
@ -63,7 +67,7 @@ checking of rcu_dereference() primitives:
|
|||
The rcu_dereference_check() check expression can be any boolean
|
||||
expression, but would normally include a lockdep expression. However,
|
||||
any boolean expression can be used. For a moderately ornate example,
|
||||
consider the following:
|
||||
consider the following::
|
||||
|
||||
file = rcu_dereference_check(fdt->fd[fd],
|
||||
lockdep_is_held(&files->file_lock) ||
|
||||
|
|
@ -82,7 +86,7 @@ RCU read-side critical sections, in case (2) the ->file_lock prevents
|
|||
any change from taking place, and finally, in case (3) the current task
|
||||
is the only task accessing the file_struct, again preventing any change
|
||||
from taking place. If the above statement was invoked only from updater
|
||||
code, it could instead be written as follows:
|
||||
code, it could instead be written as follows::
|
||||
|
||||
file = rcu_dereference_protected(fdt->fd[fd],
|
||||
lockdep_is_held(&files->file_lock) ||
|
||||
|
|
@ -105,7 +109,7 @@ false and they are called from outside any RCU read-side critical section.
|
|||
|
||||
For example, the workqueue for_each_pwq() macro is intended to be used
|
||||
either within an RCU read-side critical section or with wq->mutex held.
|
||||
It is thus implemented as follows:
|
||||
It is thus implemented as follows::
|
||||
|
||||
#define for_each_pwq(pwq, wq)
|
||||
list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,
|
||||
200
Documentation/RCU/rculist_nulls.rst
Normal file
200
Documentation/RCU/rculist_nulls.rst
Normal file
|
|
@ -0,0 +1,200 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================================================
|
||||
Using RCU hlist_nulls to protect list and objects
|
||||
=================================================
|
||||
|
||||
This section describes how to use hlist_nulls to
|
||||
protect read-mostly linked lists and
|
||||
objects using SLAB_TYPESAFE_BY_RCU allocations.
|
||||
|
||||
Please read the basics in Documentation/RCU/listRCU.rst
|
||||
|
||||
Using 'nulls'
|
||||
=============
|
||||
|
||||
Using special makers (called 'nulls') is a convenient way
|
||||
to solve following problem :
|
||||
|
||||
A typical RCU linked list managing objects which are
|
||||
allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can
|
||||
use following algos :
|
||||
|
||||
1) Lookup algo
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
rcu_read_lock()
|
||||
begin:
|
||||
obj = lockless_lookup(key);
|
||||
if (obj) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
/*
|
||||
* Because a writer could delete object, and a writer could
|
||||
* reuse these object before the RCU grace period, we
|
||||
* must check key after getting the reference on object
|
||||
*/
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
}
|
||||
rcu_read_unlock();
|
||||
|
||||
Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
|
||||
but a version with an additional memory barrier (smp_rmb())
|
||||
|
||||
::
|
||||
|
||||
lockless_lookup(key)
|
||||
{
|
||||
struct hlist_node *node, *next;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
}
|
||||
|
||||
And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb()::
|
||||
|
||||
struct hlist_node *node;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ prefetch(pos->next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(pos->next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
|
||||
Quoting Corey Minyard::
|
||||
|
||||
"If the object is moved from one list to another list in-between the
|
||||
time the hash is calculated and the next field is accessed, and the
|
||||
object has moved to the end of a new list, the traversal will not
|
||||
complete properly on the list it should have, since the object will
|
||||
be on the end of the new list and there's not a way to tell it's on a
|
||||
new list and restart the list traversal. I think that this can be
|
||||
solved by pre-fetching the "next" field (with proper barriers) before
|
||||
checking the key."
|
||||
|
||||
2) Insert algo
|
||||
--------------
|
||||
|
||||
We need to make sure a reader cannot read the new 'obj->obj_next' value
|
||||
and previous value of 'obj->key'. Or else, an item could be deleted
|
||||
from a chain, and inserted into another chain. If new chain was empty
|
||||
before the move, 'next' pointer is NULL, and lockless reader can
|
||||
not detect it missed following items in original chain.
|
||||
|
||||
::
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(...);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
/*
|
||||
* we need to make sure obj->key is updated before obj->next
|
||||
* or obj->refcnt
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
hlist_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
||||
|
||||
3) Remove algo
|
||||
--------------
|
||||
Nothing special here, we can use a standard RCU hlist deletion.
|
||||
But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
|
||||
very very fast (before the end of RCU grace period)
|
||||
|
||||
::
|
||||
|
||||
if (put_last_reference_on(obj) {
|
||||
lock_chain(); // typically a spin_lock()
|
||||
hlist_del_init_rcu(&obj->obj_node);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
kmem_cache_free(cachep, obj);
|
||||
}
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Avoiding extra smp_rmb()
|
||||
========================
|
||||
|
||||
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
|
||||
and extra smp_wmb() in insert function.
|
||||
|
||||
For example, if we choose to store the slot number as the 'nulls'
|
||||
end-of-list marker for each slot of the hash table, we can detect
|
||||
a race (some writer did a delete and/or a move of an object
|
||||
to another chain) checking the final 'nulls' value if
|
||||
the lookup met the end of chain. If final 'nulls' value
|
||||
is not the slot number, then we must restart the lookup at
|
||||
the beginning. If the object was moved to the same chain,
|
||||
then the reader doesn't care : It might eventually
|
||||
scan the list again without harm.
|
||||
|
||||
|
||||
1) lookup algo
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
head = &table[slot];
|
||||
rcu_read_lock();
|
||||
begin:
|
||||
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
|
||||
if (obj->key == key) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
goto out;
|
||||
}
|
||||
/*
|
||||
* if the nulls value we got at the end of this lookup is
|
||||
* not the expected one, we must restart lookup.
|
||||
* We probably met an item that was moved to another chain.
|
||||
*/
|
||||
if (get_nulls_value(node) != slot)
|
||||
goto begin;
|
||||
obj = NULL;
|
||||
|
||||
out:
|
||||
rcu_read_unlock();
|
||||
|
||||
2) Insert function
|
||||
------------------
|
||||
|
||||
::
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(cachep);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
/*
|
||||
* changes to obj->key must be visible before refcnt one
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
/*
|
||||
* insert obj in RCU way (readers might be traversing chain)
|
||||
*/
|
||||
hlist_nulls_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
|
@ -1,172 +0,0 @@
|
|||
Using hlist_nulls to protect read-mostly linked lists and
|
||||
objects using SLAB_TYPESAFE_BY_RCU allocations.
|
||||
|
||||
Please read the basics in Documentation/RCU/listRCU.rst
|
||||
|
||||
Using special makers (called 'nulls') is a convenient way
|
||||
to solve following problem :
|
||||
|
||||
A typical RCU linked list managing objects which are
|
||||
allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can
|
||||
use following algos :
|
||||
|
||||
1) Lookup algo
|
||||
--------------
|
||||
rcu_read_lock()
|
||||
begin:
|
||||
obj = lockless_lookup(key);
|
||||
if (obj) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
/*
|
||||
* Because a writer could delete object, and a writer could
|
||||
* reuse these object before the RCU grace period, we
|
||||
* must check key after getting the reference on object
|
||||
*/
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
}
|
||||
rcu_read_unlock();
|
||||
|
||||
Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
|
||||
but a version with an additional memory barrier (smp_rmb())
|
||||
|
||||
lockless_lookup(key)
|
||||
{
|
||||
struct hlist_node *node, *next;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
|
||||
And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb() :
|
||||
|
||||
struct hlist_node *node;
|
||||
for (pos = rcu_dereference((head)->first);
|
||||
pos && ({ prefetch(pos->next); 1; }) &&
|
||||
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||
pos = rcu_dereference(pos->next))
|
||||
if (obj->key == key)
|
||||
return obj;
|
||||
return NULL;
|
||||
}
|
||||
|
||||
Quoting Corey Minyard :
|
||||
|
||||
"If the object is moved from one list to another list in-between the
|
||||
time the hash is calculated and the next field is accessed, and the
|
||||
object has moved to the end of a new list, the traversal will not
|
||||
complete properly on the list it should have, since the object will
|
||||
be on the end of the new list and there's not a way to tell it's on a
|
||||
new list and restart the list traversal. I think that this can be
|
||||
solved by pre-fetching the "next" field (with proper barriers) before
|
||||
checking the key."
|
||||
|
||||
2) Insert algo :
|
||||
----------------
|
||||
|
||||
We need to make sure a reader cannot read the new 'obj->obj_next' value
|
||||
and previous value of 'obj->key'. Or else, an item could be deleted
|
||||
from a chain, and inserted into another chain. If new chain was empty
|
||||
before the move, 'next' pointer is NULL, and lockless reader can
|
||||
not detect it missed following items in original chain.
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(...);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
/*
|
||||
* we need to make sure obj->key is updated before obj->next
|
||||
* or obj->refcnt
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
hlist_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
||||
|
||||
3) Remove algo
|
||||
--------------
|
||||
Nothing special here, we can use a standard RCU hlist deletion.
|
||||
But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
|
||||
very very fast (before the end of RCU grace period)
|
||||
|
||||
if (put_last_reference_on(obj) {
|
||||
lock_chain(); // typically a spin_lock()
|
||||
hlist_del_init_rcu(&obj->obj_node);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
kmem_cache_free(cachep, obj);
|
||||
}
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
|
||||
and extra smp_wmb() in insert function.
|
||||
|
||||
For example, if we choose to store the slot number as the 'nulls'
|
||||
end-of-list marker for each slot of the hash table, we can detect
|
||||
a race (some writer did a delete and/or a move of an object
|
||||
to another chain) checking the final 'nulls' value if
|
||||
the lookup met the end of chain. If final 'nulls' value
|
||||
is not the slot number, then we must restart the lookup at
|
||||
the beginning. If the object was moved to the same chain,
|
||||
then the reader doesn't care : It might eventually
|
||||
scan the list again without harm.
|
||||
|
||||
|
||||
1) lookup algo
|
||||
|
||||
head = &table[slot];
|
||||
rcu_read_lock();
|
||||
begin:
|
||||
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
|
||||
if (obj->key == key) {
|
||||
if (!try_get_ref(obj)) // might fail for free objects
|
||||
goto begin;
|
||||
if (obj->key != key) { // not the object we expected
|
||||
put_ref(obj);
|
||||
goto begin;
|
||||
}
|
||||
goto out;
|
||||
}
|
||||
/*
|
||||
* if the nulls value we got at the end of this lookup is
|
||||
* not the expected one, we must restart lookup.
|
||||
* We probably met an item that was moved to another chain.
|
||||
*/
|
||||
if (get_nulls_value(node) != slot)
|
||||
goto begin;
|
||||
obj = NULL;
|
||||
|
||||
out:
|
||||
rcu_read_unlock();
|
||||
|
||||
2) Insert function :
|
||||
--------------------
|
||||
|
||||
/*
|
||||
* Please note that new inserts are done at the head of list,
|
||||
* not in the middle or end.
|
||||
*/
|
||||
obj = kmem_cache_alloc(cachep);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
/*
|
||||
* changes to obj->key must be visible before refcnt one
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
/*
|
||||
* insert obj in RCU way (readers might be traversing chain)
|
||||
*/
|
||||
hlist_nulls_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
|
@ -1,4 +1,8 @@
|
|||
Reference-count design for elements of lists/arrays protected by RCU.
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====================================================================
|
||||
Reference-count design for elements of lists/arrays protected by RCU
|
||||
====================================================================
|
||||
|
||||
|
||||
Please note that the percpu-ref feature is likely your first
|
||||
|
|
@ -12,32 +16,33 @@ please read on.
|
|||
Reference counting on elements of lists which are protected by traditional
|
||||
reader/writer spinlocks or semaphores are straightforward:
|
||||
|
||||
CODE LISTING A:
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object read_lock(&list_lock);
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); atomic_inc(&el->rc);
|
||||
write_lock(&list_lock); ...
|
||||
add_element read_unlock(&list_lock);
|
||||
... ...
|
||||
write_unlock(&list_lock); }
|
||||
}
|
||||
CODE LISTING A::
|
||||
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... write_lock(&list_lock);
|
||||
if(atomic_dec_and_test(&el->rc)) ...
|
||||
kfree(el);
|
||||
... remove_element
|
||||
} write_unlock(&list_lock);
|
||||
...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
kfree(el);
|
||||
...
|
||||
}
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object read_lock(&list_lock);
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); atomic_inc(&el->rc);
|
||||
write_lock(&list_lock); ...
|
||||
add_element read_unlock(&list_lock);
|
||||
... ...
|
||||
write_unlock(&list_lock); }
|
||||
}
|
||||
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... write_lock(&list_lock);
|
||||
if(atomic_dec_and_test(&el->rc)) ...
|
||||
kfree(el);
|
||||
... remove_element
|
||||
} write_unlock(&list_lock);
|
||||
...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
kfree(el);
|
||||
...
|
||||
}
|
||||
|
||||
If this list/array is made lock free using RCU as in changing the
|
||||
write_lock() in add() and delete() to spin_lock() and changing read_lock()
|
||||
|
|
@ -46,34 +51,35 @@ search_and_reference() could potentially hold reference to an element which
|
|||
has already been deleted from the list/array. Use atomic_inc_not_zero()
|
||||
in this scenario as follows:
|
||||
|
||||
CODE LISTING B:
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) {
|
||||
spin_lock(&list_lock); rcu_read_unlock();
|
||||
return FAIL;
|
||||
add_element }
|
||||
... ...
|
||||
spin_unlock(&list_lock); rcu_read_unlock();
|
||||
} }
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... spin_lock(&list_lock);
|
||||
if (atomic_dec_and_test(&el->rc)) ...
|
||||
call_rcu(&el->head, el_free); remove_element
|
||||
... spin_unlock(&list_lock);
|
||||
} ...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
call_rcu(&el->head, el_free);
|
||||
...
|
||||
}
|
||||
CODE LISTING B::
|
||||
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) {
|
||||
spin_lock(&list_lock); rcu_read_unlock();
|
||||
return FAIL;
|
||||
add_element }
|
||||
... ...
|
||||
spin_unlock(&list_lock); rcu_read_unlock();
|
||||
} }
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... spin_lock(&list_lock);
|
||||
if (atomic_dec_and_test(&el->rc)) ...
|
||||
call_rcu(&el->head, el_free); remove_element
|
||||
... spin_unlock(&list_lock);
|
||||
} ...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
call_rcu(&el->head, el_free);
|
||||
...
|
||||
}
|
||||
|
||||
Sometimes, a reference to the element needs to be obtained in the
|
||||
update (write) stream. In such cases, atomic_inc_not_zero() might be
|
||||
update (write) stream. In such cases, atomic_inc_not_zero() might be
|
||||
overkill, since we hold the update-side spinlock. One might instead
|
||||
use atomic_inc() in such cases.
|
||||
|
||||
|
|
@ -82,39 +88,40 @@ search_and_reference() code path. In such cases, the
|
|||
atomic_dec_and_test() may be moved from delete() to el_free()
|
||||
as follows:
|
||||
|
||||
CODE LISTING C:
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); atomic_inc(&el->rc);
|
||||
spin_lock(&list_lock); ...
|
||||
CODE LISTING C::
|
||||
|
||||
add_element rcu_read_unlock();
|
||||
... }
|
||||
spin_unlock(&list_lock); 4.
|
||||
} delete()
|
||||
3. {
|
||||
release_referenced() spin_lock(&list_lock);
|
||||
{ ...
|
||||
... remove_element
|
||||
if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock);
|
||||
kfree(el); ...
|
||||
... call_rcu(&el->head, el_free);
|
||||
} ...
|
||||
5. }
|
||||
void el_free(struct rcu_head *rhp)
|
||||
{
|
||||
release_referenced();
|
||||
}
|
||||
1. 2.
|
||||
add() search_and_reference()
|
||||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); atomic_inc(&el->rc);
|
||||
spin_lock(&list_lock); ...
|
||||
|
||||
add_element rcu_read_unlock();
|
||||
... }
|
||||
spin_unlock(&list_lock); 4.
|
||||
} delete()
|
||||
3. {
|
||||
release_referenced() spin_lock(&list_lock);
|
||||
{ ...
|
||||
... remove_element
|
||||
if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock);
|
||||
kfree(el); ...
|
||||
... call_rcu(&el->head, el_free);
|
||||
} ...
|
||||
5. }
|
||||
void el_free(struct rcu_head *rhp)
|
||||
{
|
||||
release_referenced();
|
||||
}
|
||||
|
||||
The key point is that the initial reference added by add() is not removed
|
||||
until after a grace period has elapsed following removal. This means that
|
||||
search_and_reference() cannot find this element, which means that the value
|
||||
of el->rc cannot increase. Thus, once it reaches zero, there are no
|
||||
readers that can or ever will be able to reference the element. The
|
||||
element can therefore safely be freed. This in turn guarantees that if
|
||||
readers that can or ever will be able to reference the element. The
|
||||
element can therefore safely be freed. This in turn guarantees that if
|
||||
any reader finds the element, that reader may safely acquire a reference
|
||||
without checking the value of the reference counter.
|
||||
|
||||
|
|
@ -130,21 +137,21 @@ the eventual invocation of kfree(), which is usually not a problem on
|
|||
modern computer systems, even the small ones.
|
||||
|
||||
In cases where delete() can sleep, synchronize_rcu() can be called from
|
||||
delete(), so that el_free() can be subsumed into delete as follows:
|
||||
delete(), so that el_free() can be subsumed into delete as follows::
|
||||
|
||||
4.
|
||||
delete()
|
||||
{
|
||||
spin_lock(&list_lock);
|
||||
...
|
||||
remove_element
|
||||
spin_unlock(&list_lock);
|
||||
...
|
||||
synchronize_rcu();
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
kfree(el);
|
||||
...
|
||||
}
|
||||
4.
|
||||
delete()
|
||||
{
|
||||
spin_lock(&list_lock);
|
||||
...
|
||||
remove_element
|
||||
spin_unlock(&list_lock);
|
||||
...
|
||||
synchronize_rcu();
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
kfree(el);
|
||||
...
|
||||
}
|
||||
|
||||
As additional examples in the kernel, the pattern in listing C is used by
|
||||
reference counting of struct pid, while the pattern in listing B is used by
|
||||
|
|
@ -1,4 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==============================
|
||||
Using RCU's CPU Stall Detector
|
||||
==============================
|
||||
|
||||
This document first discusses what sorts of issues RCU's CPU stall
|
||||
detector can locate, and then discusses kernel parameters and Kconfig
|
||||
|
|
@ -7,39 +11,40 @@ this document explains the stall detector's "splat" format.
|
|||
|
||||
|
||||
What Causes RCU CPU Stall Warnings?
|
||||
===================================
|
||||
|
||||
So your kernel printed an RCU CPU stall warning. The next question is
|
||||
"What caused it?" The following problems can result in RCU CPU stall
|
||||
warnings:
|
||||
|
||||
o A CPU looping in an RCU read-side critical section.
|
||||
- A CPU looping in an RCU read-side critical section.
|
||||
|
||||
o A CPU looping with interrupts disabled.
|
||||
- A CPU looping with interrupts disabled.
|
||||
|
||||
o A CPU looping with preemption disabled.
|
||||
- A CPU looping with preemption disabled.
|
||||
|
||||
o A CPU looping with bottom halves disabled.
|
||||
- A CPU looping with bottom halves disabled.
|
||||
|
||||
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
|
||||
- For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
|
||||
without invoking schedule(). If the looping in the kernel is
|
||||
really expected and desirable behavior, you might need to add
|
||||
some calls to cond_resched().
|
||||
|
||||
o Booting Linux using a console connection that is too slow to
|
||||
- Booting Linux using a console connection that is too slow to
|
||||
keep up with the boot-time console-message rate. For example,
|
||||
a 115Kbaud serial console can be -way- too slow to keep up
|
||||
with boot-time message rates, and will frequently result in
|
||||
RCU CPU stall warning messages. Especially if you have added
|
||||
debug printk()s.
|
||||
|
||||
o Anything that prevents RCU's grace-period kthreads from running.
|
||||
- Anything that prevents RCU's grace-period kthreads from running.
|
||||
This can result in the "All QSes seen" console-log message.
|
||||
This message will include information on when the kthread last
|
||||
ran and how often it should be expected to run. It can also
|
||||
result in the "rcu_.*kthread starved for" console-log message,
|
||||
result in the ``rcu_.*kthread starved for`` console-log message,
|
||||
which will include additional debugging information.
|
||||
|
||||
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
||||
- A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
||||
happen to preempt a low-priority task in the middle of an RCU
|
||||
read-side critical section. This is especially damaging if
|
||||
that low-priority task is not permitted to run on any other CPU,
|
||||
|
|
@ -48,7 +53,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
|||
While the system is in the process of running itself out of
|
||||
memory, you might see stall-warning messages.
|
||||
|
||||
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
|
||||
- A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
|
||||
is running at a higher priority than the RCU softirq threads.
|
||||
This will prevent RCU callbacks from ever being invoked,
|
||||
and in a CONFIG_PREEMPT_RCU kernel will further prevent
|
||||
|
|
@ -63,7 +68,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
|
|||
can increase your system's context-switch rate and thus degrade
|
||||
performance.
|
||||
|
||||
o A periodic interrupt whose handler takes longer than the time
|
||||
- A periodic interrupt whose handler takes longer than the time
|
||||
interval between successive pairs of interrupts. This can
|
||||
prevent RCU's kthreads and softirq handlers from running.
|
||||
Note that certain high-overhead debugging options, for example
|
||||
|
|
@ -71,20 +76,27 @@ o A periodic interrupt whose handler takes longer than the time
|
|||
considerably longer than normal, which can in turn result in
|
||||
RCU CPU stall warnings.
|
||||
|
||||
o Testing a workload on a fast system, tuning the stall-warning
|
||||
- Testing a workload on a fast system, tuning the stall-warning
|
||||
timeout down to just barely avoid RCU CPU stall warnings, and then
|
||||
running the same workload with the same stall-warning timeout on a
|
||||
slow system. Note that thermal throttling and on-demand governors
|
||||
can cause a single system to be sometimes fast and sometimes slow!
|
||||
|
||||
o A hardware or software issue shuts off the scheduler-clock
|
||||
- A hardware or software issue shuts off the scheduler-clock
|
||||
interrupt on a CPU that is not in dyntick-idle mode. This
|
||||
problem really has happened, and seems to be most likely to
|
||||
result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels.
|
||||
|
||||
o A bug in the RCU implementation.
|
||||
- A hardware or software issue that prevents time-based wakeups
|
||||
from occurring. These issues can range from misconfigured or
|
||||
buggy timer hardware through bugs in the interrupt or exception
|
||||
path (whether hardware, firmware, or software) through bugs
|
||||
in Linux's timer subsystem through bugs in the scheduler, and,
|
||||
yes, even including bugs in RCU itself.
|
||||
|
||||
o A hardware failure. This is quite unlikely, but has occurred
|
||||
- A bug in the RCU implementation.
|
||||
|
||||
- A hardware failure. This is quite unlikely, but has occurred
|
||||
at least once in real life. A CPU failed in a running system,
|
||||
becoming unresponsive, but not causing an immediate crash.
|
||||
This resulted in a series of RCU CPU stall warnings, eventually
|
||||
|
|
@ -109,6 +121,7 @@ see include/trace/events/rcu.h.
|
|||
|
||||
|
||||
Fine-Tuning the RCU CPU Stall Detector
|
||||
======================================
|
||||
|
||||
The rcuupdate.rcu_cpu_stall_suppress module parameter disables RCU's
|
||||
CPU stall detector, which detects conditions that unduly delay RCU grace
|
||||
|
|
@ -118,6 +131,7 @@ The stall detector's idea of what constitutes "unduly delayed" is
|
|||
controlled by a set of kernel configuration variables and cpp macros:
|
||||
|
||||
CONFIG_RCU_CPU_STALL_TIMEOUT
|
||||
----------------------------
|
||||
|
||||
This kernel configuration parameter defines the period of time
|
||||
that RCU will wait from the beginning of a grace period until it
|
||||
|
|
@ -137,6 +151,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
RCU_STALL_DELAY_DELTA
|
||||
---------------------
|
||||
|
||||
Although the lockdep facility is extremely useful, it does add
|
||||
some overhead. Therefore, under CONFIG_PROVE_RCU, the
|
||||
|
|
@ -145,6 +160,7 @@ RCU_STALL_DELAY_DELTA
|
|||
macro, not a kernel configuration parameter.)
|
||||
|
||||
RCU_STALL_RAT_DELAY
|
||||
-------------------
|
||||
|
||||
The CPU stall detector tries to make the offending CPU print its
|
||||
own warnings, as this often gives better-quality stack traces.
|
||||
|
|
@ -155,6 +171,7 @@ RCU_STALL_RAT_DELAY
|
|||
parameter.)
|
||||
|
||||
rcupdate.rcu_task_stall_timeout
|
||||
-------------------------------
|
||||
|
||||
This boot/sysfs parameter controls the RCU-tasks stall warning
|
||||
interval. A value of zero or less suppresses RCU-tasks stall
|
||||
|
|
@ -168,9 +185,10 @@ rcupdate.rcu_task_stall_timeout
|
|||
|
||||
|
||||
Interpreting RCU's CPU Stall-Detector "Splats"
|
||||
==============================================
|
||||
|
||||
For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling,
|
||||
it will print a message similar to the following:
|
||||
it will print a message similar to the following::
|
||||
|
||||
INFO: rcu_sched detected stalls on CPUs/tasks:
|
||||
2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0
|
||||
|
|
@ -223,7 +241,7 @@ an estimate of the total number of RCU callbacks queued across all CPUs
|
|||
(625 in this case).
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
|
||||
for each CPU:
|
||||
for each CPU::
|
||||
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 dyntick_enabled: 1
|
||||
|
||||
|
|
@ -235,7 +253,7 @@ processing is enabled.
|
|||
|
||||
If the grace period ends just as the stall warning starts printing,
|
||||
there will be a spurious stall-warning message, which will include
|
||||
the following:
|
||||
the following::
|
||||
|
||||
INFO: Stall ended before state dump start
|
||||
|
||||
|
|
@ -248,7 +266,7 @@ which is overkill for this sort of problem.
|
|||
|
||||
If all CPUs and tasks have passed through quiescent states, but the
|
||||
grace period has nevertheless failed to end, the stall-warning splat
|
||||
will include something like the following:
|
||||
will include something like the following::
|
||||
|
||||
All QSes seen, last rcu_preempt kthread activity 23807 (4297905177-4297881370), jiffies_till_next_fqs=3, root ->qsmask 0x0
|
||||
|
||||
|
|
@ -261,7 +279,7 @@ which is way less than 23807. Finally, the root rcu_node structure's
|
|||
|
||||
If the relevant grace-period kthread has been unable to run prior to
|
||||
the stall warning, as was the case in the "All QSes seen" line above,
|
||||
the following additional line is printed:
|
||||
the following additional line is printed::
|
||||
|
||||
kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5
|
||||
|
||||
|
|
@ -276,6 +294,7 @@ kthread last ran on CPU 5.
|
|||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
================================
|
||||
|
||||
If a stall lasts long enough, multiple stall-warning messages will be
|
||||
printed for it. The second and subsequent messages are printed at
|
||||
|
|
@ -285,9 +304,10 @@ of the stall and the first message.
|
|||
|
||||
|
||||
Stall Warnings for Expedited Grace Periods
|
||||
==========================================
|
||||
|
||||
If an expedited grace period detects a stall, it will place a message
|
||||
like the following in dmesg:
|
||||
like the following in dmesg::
|
||||
|
||||
INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 7-... } 21119 jiffies s: 73 root: 0x2/.
|
||||
|
||||
|
|
@ -1,7 +1,12 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================
|
||||
RCU Torture Test Operation
|
||||
==========================
|
||||
|
||||
|
||||
CONFIG_RCU_TORTURE_TEST
|
||||
=======================
|
||||
|
||||
The CONFIG_RCU_TORTURE_TEST config option is available for all RCU
|
||||
implementations. It creates an rcutorture kernel module that can
|
||||
|
|
@ -13,9 +18,10 @@ when the module is loaded, and stops when the module is unloaded.
|
|||
Module parameters are prefixed by "rcutorture." in
|
||||
Documentation/admin-guide/kernel-parameters.txt.
|
||||
|
||||
OUTPUT
|
||||
Output
|
||||
======
|
||||
|
||||
The statistics output is as follows:
|
||||
The statistics output is as follows::
|
||||
|
||||
rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
|
||||
rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
|
||||
|
|
@ -36,53 +42,53 @@ automatic determination as to whether RCU operated correctly.
|
|||
|
||||
The entries are as follows:
|
||||
|
||||
o "rtc": The hexadecimal address of the structure currently visible
|
||||
* "rtc": The hexadecimal address of the structure currently visible
|
||||
to readers.
|
||||
|
||||
o "ver": The number of times since boot that the RCU writer task
|
||||
* "ver": The number of times since boot that the RCU writer task
|
||||
has changed the structure visible to readers.
|
||||
|
||||
o "tfle": If non-zero, indicates that the "torture freelist"
|
||||
* "tfle": If non-zero, indicates that the "torture freelist"
|
||||
containing structures to be placed into the "rtc" area is empty.
|
||||
This condition is important, since it can fool you into thinking
|
||||
that RCU is working when it is not. :-/
|
||||
|
||||
o "rta": Number of structures allocated from the torture freelist.
|
||||
* "rta": Number of structures allocated from the torture freelist.
|
||||
|
||||
o "rtaf": Number of allocations from the torture freelist that have
|
||||
* "rtaf": Number of allocations from the torture freelist that have
|
||||
failed due to the list being empty. It is not unusual for this
|
||||
to be non-zero, but it is bad for it to be a large fraction of
|
||||
the value indicated by "rta".
|
||||
|
||||
o "rtf": Number of frees into the torture freelist.
|
||||
* "rtf": Number of frees into the torture freelist.
|
||||
|
||||
o "rtmbe": A non-zero value indicates that rcutorture believes that
|
||||
* "rtmbe": A non-zero value indicates that rcutorture believes that
|
||||
rcu_assign_pointer() and rcu_dereference() are not working
|
||||
correctly. This value should be zero.
|
||||
|
||||
o "rtbe": A non-zero value indicates that one of the rcu_barrier()
|
||||
* "rtbe": A non-zero value indicates that one of the rcu_barrier()
|
||||
family of functions is not working correctly.
|
||||
|
||||
o "rtbke": rcutorture was unable to create the real-time kthreads
|
||||
* "rtbke": rcutorture was unable to create the real-time kthreads
|
||||
used to force RCU priority inversion. This value should be zero.
|
||||
|
||||
o "rtbre": Although rcutorture successfully created the kthreads
|
||||
* "rtbre": Although rcutorture successfully created the kthreads
|
||||
used to force RCU priority inversion, it was unable to set them
|
||||
to the real-time priority level of 1. This value should be zero.
|
||||
|
||||
o "rtbf": The number of times that RCU priority boosting failed
|
||||
* "rtbf": The number of times that RCU priority boosting failed
|
||||
to resolve RCU priority inversion.
|
||||
|
||||
o "rtb": The number of times that rcutorture attempted to force
|
||||
* "rtb": The number of times that rcutorture attempted to force
|
||||
an RCU priority inversion condition. If you are testing RCU
|
||||
priority boosting via the "test_boost" module parameter, this
|
||||
value should be non-zero.
|
||||
|
||||
o "nt": The number of times rcutorture ran RCU read-side code from
|
||||
* "nt": The number of times rcutorture ran RCU read-side code from
|
||||
within a timer handler. This value should be non-zero only
|
||||
if you specified the "irqreader" module parameter.
|
||||
|
||||
o "Reader Pipe": Histogram of "ages" of structures seen by readers.
|
||||
* "Reader Pipe": Histogram of "ages" of structures seen by readers.
|
||||
If any entries past the first two are non-zero, RCU is broken.
|
||||
And rcutorture prints the error flag string "!!!" to make sure
|
||||
you notice. The age of a newly allocated structure is zero,
|
||||
|
|
@ -94,14 +100,14 @@ o "Reader Pipe": Histogram of "ages" of structures seen by readers.
|
|||
RCU. If you want to see what it looks like when broken, break
|
||||
it yourself. ;-)
|
||||
|
||||
o "Reader Batch": Another histogram of "ages" of structures seen
|
||||
* "Reader Batch": Another histogram of "ages" of structures seen
|
||||
by readers, but in terms of counter flips (or batches) rather
|
||||
than in terms of grace periods. The legal number of non-zero
|
||||
entries is again two. The reason for this separate view is that
|
||||
it is sometimes easier to get the third entry to show up in the
|
||||
"Reader Batch" list than in the "Reader Pipe" list.
|
||||
|
||||
o "Free-Block Circulation": Shows the number of torture structures
|
||||
* "Free-Block Circulation": Shows the number of torture structures
|
||||
that have reached a given point in the pipeline. The first element
|
||||
should closely correspond to the number of structures allocated,
|
||||
the second to the number that have been removed from reader view,
|
||||
|
|
@ -112,7 +118,7 @@ o "Free-Block Circulation": Shows the number of torture structures
|
|||
|
||||
Different implementations of RCU can provide implementation-specific
|
||||
additional information. For example, Tree SRCU provides the following
|
||||
additional line:
|
||||
additional line::
|
||||
|
||||
srcud-torture: Tree SRCU per-CPU(idx=0): 0(35,-21) 1(-4,24) 2(1,1) 3(-26,20) 4(28,-47) 5(-9,4) 6(-10,14) 7(-14,11) T(1,6)
|
||||
|
||||
|
|
@ -123,15 +129,15 @@ using a dynamically allocated srcu_struct (hence "srcud-" rather than
|
|||
"old" and "current" values to the underlying array, and is useful for
|
||||
debugging. The final "T" entry contains the totals of the counters.
|
||||
|
||||
|
||||
USAGE ON SPECIFIC KERNEL BUILDS
|
||||
Usage on Specific Kernel Builds
|
||||
===============================
|
||||
|
||||
It is sometimes desirable to torture RCU on a specific kernel build,
|
||||
for example, when preparing to put that kernel build into production.
|
||||
In that case, the kernel should be built with CONFIG_RCU_TORTURE_TEST=m
|
||||
so that the test can be started using modprobe and terminated using rmmod.
|
||||
|
||||
For example, the following script may be used to torture RCU:
|
||||
For example, the following script may be used to torture RCU::
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
|
@ -148,7 +154,8 @@ two are self-explanatory, while the last indicates that while there
|
|||
were no RCU failures, CPU-hotplug problems were detected.
|
||||
|
||||
|
||||
USAGE ON MAINLINE KERNELS
|
||||
Usage on Mainline Kernels
|
||||
=========================
|
||||
|
||||
When using rcutorture to test changes to RCU itself, it is often
|
||||
necessary to build a number of kernels in order to test that change
|
||||
|
|
@ -180,16 +187,16 @@ to Tree SRCU might run only the SRCU-N and SRCU-P scenarios using the
|
|||
--configs argument to kvm.sh as follows: "--configs 'SRCU-N SRCU-P'".
|
||||
Large systems can run multiple copies of of the full set of scenarios,
|
||||
for example, a system with 448 hardware threads can run five instances
|
||||
of the full set concurrently. To make this happen:
|
||||
of the full set concurrently. To make this happen::
|
||||
|
||||
kvm.sh --cpus 448 --configs '5*CFLIST'
|
||||
|
||||
Alternatively, such a system can run 56 concurrent instances of a single
|
||||
eight-CPU scenario:
|
||||
eight-CPU scenario::
|
||||
|
||||
kvm.sh --cpus 448 --configs '56*TREE04'
|
||||
|
||||
Or 28 concurrent instances of each of two eight-CPU scenarios:
|
||||
Or 28 concurrent instances of each of two eight-CPU scenarios::
|
||||
|
||||
kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04'
|
||||
|
||||
|
|
@ -199,14 +206,14 @@ values for memory may require disabling the callback-flooding tests
|
|||
using the --bootargs parameter discussed below.
|
||||
|
||||
Sometimes additional debugging is useful, and in such cases the --kconfig
|
||||
parameter to kvm.sh may be used, for example, "--kconfig 'CONFIG_KASAN=y'".
|
||||
parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_KASAN=y'``.
|
||||
|
||||
Kernel boot arguments can also be supplied, for example, to control
|
||||
rcutorture's module parameters. For example, to test a change to RCU's
|
||||
CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'".
|
||||
This will of course result in the scripting reporting a failure, namely
|
||||
the resuling RCU CPU stall warning. As noted above, reducing memory may
|
||||
require disabling rcutorture's callback-flooding tests:
|
||||
require disabling rcutorture's callback-flooding tests::
|
||||
|
||||
kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
|
||||
--bootargs 'rcutorture.fwd_progress=0'
|
||||
|
|
@ -225,7 +232,7 @@ is listed at the end of the kvm.sh output, which you really should redirect
|
|||
to a file. The build products and console output of each run is kept in
|
||||
tools/testing/selftests/rcutorture/res in timestamped directories. A
|
||||
given directory can be supplied to kvm-find-errors.sh in order to have
|
||||
it cycle you through summaries of errors and full error logs. For example:
|
||||
it cycle you through summaries of errors and full error logs. For example::
|
||||
|
||||
tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \
|
||||
tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23
|
||||
|
|
@ -245,38 +252,42 @@ that was tested and any uncommitted changes in diff format.
|
|||
|
||||
The most frequently used files in each per-scenario-run directory are:
|
||||
|
||||
.config: This file contains the Kconfig options.
|
||||
.config:
|
||||
This file contains the Kconfig options.
|
||||
|
||||
Make.out: This contains build output for a specific scenario.
|
||||
Make.out:
|
||||
This contains build output for a specific scenario.
|
||||
|
||||
console.log: This contains the console output for a specific scenario.
|
||||
console.log:
|
||||
This contains the console output for a specific scenario.
|
||||
This file may be examined once the kernel has booted, but
|
||||
it might not exist if the build failed.
|
||||
|
||||
vmlinux: This contains the kernel, which can be useful with tools like
|
||||
vmlinux:
|
||||
This contains the kernel, which can be useful with tools like
|
||||
objdump and gdb.
|
||||
|
||||
A number of additional files are available, but are less frequently used.
|
||||
Many are intended for debugging of rcutorture itself or of its scripting.
|
||||
|
||||
As of v5.4, a successful run with the default set of scenarios produces
|
||||
the following summary at the end of the run on a 12-CPU system:
|
||||
the following summary at the end of the run on a 12-CPU system::
|
||||
|
||||
SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ]
|
||||
SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ]
|
||||
SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ]
|
||||
SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ]
|
||||
TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ]
|
||||
TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ]
|
||||
TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ]
|
||||
TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198
|
||||
TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631
|
||||
TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ]
|
||||
TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844
|
||||
TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497
|
||||
CPU count limited from 16 to 12
|
||||
TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961
|
||||
TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997
|
||||
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
|
||||
CPU count limited from 16 to 12
|
||||
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
|
||||
SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ]
|
||||
SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ]
|
||||
SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ]
|
||||
SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ]
|
||||
TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ]
|
||||
TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ]
|
||||
TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ]
|
||||
TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198
|
||||
TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631
|
||||
TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ]
|
||||
TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844
|
||||
TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497
|
||||
CPU count limited from 16 to 12
|
||||
TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961
|
||||
TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997
|
||||
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
|
||||
CPU count limited from 16 to 12
|
||||
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
|
||||
|
|
@ -19,9 +19,10 @@ attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
|
|||
etc) to extract additional credentials and continue to expand the scope
|
||||
of their attack without resorting to user-assisted phishing.
|
||||
|
||||
This is not a theoretical problem. SSH session hijacking
|
||||
(http://www.storm.net.nz/projects/7) and arbitrary code injection
|
||||
(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
|
||||
This is not a theoretical problem. `SSH session hijacking
|
||||
<https://www.blackhat.com/presentations/bh-usa-05/bh-us-05-boileau.pdf>`_
|
||||
and `arbitrary code injection
|
||||
<https://c-skills.blogspot.com/2007/05/injectso.html>`_ attacks already
|
||||
exist and remain possible if ptrace is allowed to operate as before.
|
||||
Since ptrace is not commonly used by non-developers and non-admins, system
|
||||
builders should be allowed the option to disable this debugging system.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Description
|
|||
clusters and in this context, is a "drop-in" replacement for shared
|
||||
storage. Simplistically, you could see it as a network RAID 1.
|
||||
|
||||
Please visit http://www.drbd.org to find out more.
|
||||
Please visit https://www.drbd.org to find out more.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ FAQ list:
|
|||
=========
|
||||
|
||||
A FAQ list may be found in the fdutils package (see below), and also
|
||||
at <http://fdutils.linux.lu/faq.html>.
|
||||
at <https://fdutils.linux.lu/faq.html>.
|
||||
|
||||
|
||||
LILO configuration options (Thinkpad users, read this)
|
||||
|
|
@ -220,11 +220,11 @@ It also contains additional documentation about the floppy driver.
|
|||
|
||||
The latest version can be found at fdutils homepage:
|
||||
|
||||
http://fdutils.linux.lu
|
||||
https://fdutils.linux.lu
|
||||
|
||||
The fdutils releases can be found at:
|
||||
|
||||
http://fdutils.linux.lu/download.html
|
||||
https://fdutils.linux.lu/download.html
|
||||
|
||||
http://www.tux.org/pub/knaff/fdutils/
|
||||
|
||||
|
|
|
|||
|
|
@ -71,6 +71,16 @@ For example,::
|
|||
foo = bar, baz
|
||||
foo = qux # !ERROR! we can not re-define same key
|
||||
|
||||
If you want to update the value, you must use the override operator
|
||||
``:=`` explicitly. For example::
|
||||
|
||||
foo = bar, baz
|
||||
foo := qux
|
||||
|
||||
then, the ``qux`` is assigned to ``foo`` key. This is useful for
|
||||
overriding the default value by adding (partial) custom bootconfigs
|
||||
without parsing the default bootconfig.
|
||||
|
||||
If you want to append the value to existing key as an array member,
|
||||
you can use ``+=`` operator. For example::
|
||||
|
||||
|
|
@ -84,6 +94,7 @@ For example, following config is NOT allowed.::
|
|||
|
||||
foo = value1
|
||||
foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist
|
||||
foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed.
|
||||
|
||||
|
||||
Comments
|
||||
|
|
|
|||
|
|
@ -114,4 +114,4 @@ Following resources can be accounted by rdma controller.
|
|||
|
||||
(d) Delete resource limit::
|
||||
|
||||
echo echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
|
||||
echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
|
||||
|
|
|
|||
|
|
@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
|
|||
Amount of memory used for storing in-kernel data
|
||||
structures.
|
||||
|
||||
percpu
|
||||
Amount of memory used for storing per-cpu kernel
|
||||
data structures.
|
||||
|
||||
sock
|
||||
Amount of memory used in network transmission buffers
|
||||
|
||||
|
|
@ -1483,8 +1487,7 @@ IO Interface Files
|
|||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
io.stat
|
||||
A read-only nested-keyed file which exists on non-root
|
||||
cgroups.
|
||||
A read-only nested-keyed file.
|
||||
|
||||
Lines are keyed by $MAJ:$MIN device numbers and not ordered.
|
||||
The following nested keys are defined.
|
||||
|
|
@ -1684,9 +1687,9 @@ per-cgroup dirty memory states are examined and the more restrictive
|
|||
of the two is enforced.
|
||||
|
||||
cgroup writeback requires explicit support from the underlying
|
||||
filesystem. Currently, cgroup writeback is implemented on ext2, ext4
|
||||
and btrfs. On other filesystems, all writeback IOs are attributed to
|
||||
the root cgroup.
|
||||
filesystem. Currently, cgroup writeback is implemented on ext2, ext4,
|
||||
btrfs, f2fs, and xfs. On other filesystems, all writeback IOs are
|
||||
attributed to the root cgroup.
|
||||
|
||||
There are inherent differences in memory and writeback management
|
||||
which affects how cgroup ownership is tracked. Memory is tracked per
|
||||
|
|
@ -2043,7 +2046,7 @@ RDMA
|
|||
----
|
||||
|
||||
The "rdma" controller regulates the distribution and accounting of
|
||||
of RDMA resources.
|
||||
RDMA resources.
|
||||
|
||||
RDMA Interface Files
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ x) Finish support for SMB3.1.1 compression
|
|||
Known Bugs
|
||||
==========
|
||||
|
||||
See http://bugzilla.samba.org - search on product "CifsVFS" for
|
||||
See https://bugzilla.samba.org - search on product "CifsVFS" for
|
||||
current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS)
|
||||
|
||||
1) existing symbolic links (Windows reparse points) are recognized but
|
||||
|
|
|
|||
|
|
@ -16,8 +16,7 @@ standard for interoperating between Macs and Windows and major NAS appliances.
|
|||
|
||||
Please see
|
||||
MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification)
|
||||
http://protocolfreedom.org/ and
|
||||
http://samba.org/samba/PFIF/
|
||||
or https://samba.org/samba/PFIF/
|
||||
for more details.
|
||||
|
||||
|
||||
|
|
@ -32,7 +31,7 @@ Build instructions
|
|||
|
||||
For Linux:
|
||||
|
||||
1) Download the kernel (e.g. from http://www.kernel.org)
|
||||
1) Download the kernel (e.g. from https://www.kernel.org)
|
||||
and change directory into the top of the kernel directory tree
|
||||
(e.g. /usr/src/linux-2.5.73)
|
||||
2) make menuconfig (or make xconfig)
|
||||
|
|
@ -831,7 +830,7 @@ the active sessions and the shares that are mounted.
|
|||
Enabling Kerberos (extended security) works but requires version 1.2 or later
|
||||
of the helper program cifs.upcall to be present and to be configured in the
|
||||
/etc/request-key.conf file. The cifs.upcall helper program is from the Samba
|
||||
project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not
|
||||
project(https://www.samba.org). NTLM and NTLMv2 and LANMAN support do not
|
||||
require this helper. Note that NTLMv2 security (which does not require the
|
||||
cifs.upcall helper program), instead of using Kerberos, is sufficient for
|
||||
some use cases.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
#
|
||||
|
||||
while(<>) {
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Please go to http://support.dell.com register and you can find info on
|
|||
OpenManage and Dell Update packages (DUP).
|
||||
|
||||
Libsmbios can also be used to update BIOS on Dell systems go to
|
||||
http://linux.dell.com/libsmbios/ for details.
|
||||
https://linux.dell.com/libsmbios/ for details.
|
||||
|
||||
Dell_RBU driver supports BIOS update using the monolithic image and packetized
|
||||
image methods. In case of monolithic the driver allocates a contiguous chunk
|
||||
|
|
|
|||
|
|
@ -69,10 +69,11 @@ Create the dm-dust device:
|
|||
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096'
|
||||
|
||||
Check the status of the read behavior ("bypass" indicates that all I/O
|
||||
will be passed through to the underlying device)::
|
||||
will be passed through to the underlying device; "verbose" indicates that
|
||||
bad block additions, removals, and remaps will be verbosely logged)::
|
||||
|
||||
$ sudo dmsetup status dust1
|
||||
0 33552384 dust 252:17 bypass
|
||||
0 33552384 dust 252:17 bypass verbose
|
||||
|
||||
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct
|
||||
128+0 records in
|
||||
|
|
@ -164,7 +165,7 @@ following message command::
|
|||
A message will print with the number of bad blocks currently
|
||||
configured on the device::
|
||||
|
||||
kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found
|
||||
countbadblocks: 895 badblock(s) found
|
||||
|
||||
Querying for specific bad blocks
|
||||
--------------------------------
|
||||
|
|
@ -176,11 +177,11 @@ following message command::
|
|||
|
||||
The following message will print if the block is in the list::
|
||||
|
||||
device-mapper: dust: queryblock: block 72 found in badblocklist
|
||||
dust_query_block: block 72 found in badblocklist
|
||||
|
||||
The following message will print if the block is not in the list::
|
||||
|
||||
device-mapper: dust: queryblock: block 72 not found in badblocklist
|
||||
dust_query_block: block 72 not found in badblocklist
|
||||
|
||||
The "queryblock" message command will work in both the "enabled"
|
||||
and "disabled" modes, allowing the verification of whether a block
|
||||
|
|
@ -198,12 +199,28 @@ following message command::
|
|||
|
||||
After clearing the bad block list, the following message will appear::
|
||||
|
||||
kernel: device-mapper: dust: clearbadblocks: badblocks cleared
|
||||
dust_clear_badblocks: badblocks cleared
|
||||
|
||||
If there were no bad blocks to clear, the following message will
|
||||
appear::
|
||||
|
||||
kernel: device-mapper: dust: clearbadblocks: no badblocks found
|
||||
dust_clear_badblocks: no badblocks found
|
||||
|
||||
Listing the bad block list
|
||||
--------------------------
|
||||
|
||||
To list all bad blocks in the bad block list (using an example device
|
||||
with blocks 1 and 2 in the bad block list), run the following message
|
||||
command::
|
||||
|
||||
$ sudo dmsetup message dust1 0 listbadblocks
|
||||
1
|
||||
2
|
||||
|
||||
If there are no bad blocks in the bad block list, the command will
|
||||
execute with no output::
|
||||
|
||||
$ sudo dmsetup message dust1 0 listbadblocks
|
||||
|
||||
Message commands list
|
||||
---------------------
|
||||
|
|
@ -223,6 +240,7 @@ Single argument message commands::
|
|||
|
||||
countbadblocks
|
||||
clearbadblocks
|
||||
listbadblocks
|
||||
disable
|
||||
enable
|
||||
quiet
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ To use the target for the first time:
|
|||
will format the device
|
||||
3. unload the dm-integrity target
|
||||
4. read the "provided_data_sectors" value from the superblock
|
||||
5. load the dm-integrity target with the the target size
|
||||
5. load the dm-integrity target with the target size
|
||||
"provided_data_sectors"
|
||||
6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target
|
||||
with the size "provided_data_sectors"
|
||||
|
|
@ -99,7 +99,7 @@ interleave_sectors:number
|
|||
the superblock is used.
|
||||
|
||||
meta_device:device
|
||||
Don't interleave the data and metadata on on device. Use a
|
||||
Don't interleave the data and metadata on the device. Use a
|
||||
separate device for metadata.
|
||||
|
||||
buffer_sectors:number
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ The target is named "raid" and it accepts the following parameters::
|
|||
============= ===============================================================
|
||||
|
||||
Reference: Chapter 4 of
|
||||
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
https://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
|
||||
<#raid_params>: The number of parameters that follow.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ host-aware zoned block devices.
|
|||
For a more detailed description of the zoned block device models and
|
||||
their constraints see (for SCSI devices):
|
||||
|
||||
http://www.t10.org/drafts.htm#ZBC_Family
|
||||
https://www.t10.org/drafts.htm#ZBC_Family
|
||||
|
||||
and (for ATA devices):
|
||||
|
||||
|
|
|
|||
|
|
@ -83,6 +83,10 @@ restart_on_corruption
|
|||
not compatible with ignore_corruption and requires user space support to
|
||||
avoid restart loops.
|
||||
|
||||
panic_on_corruption
|
||||
Panic the device when a corrupted block is discovered. This option is
|
||||
not compatible with ignore_corruption and restart_on_corruption.
|
||||
|
||||
ignore_zero_blocks
|
||||
Do not verify blocks that are expected to contain zeroes and always return
|
||||
zeroes instead. This may be useful if the partition contains unused blocks
|
||||
|
|
|
|||
|
|
@ -375,8 +375,9 @@
|
|||
239 = /dev/uhid User-space I/O driver support for HID subsystem
|
||||
240 = /dev/userio Serio driver testing device
|
||||
241 = /dev/vhost-vsock Host kernel driver for virtio vsock
|
||||
242 = /dev/rfkill Turning off radio transmissions (rfkill)
|
||||
|
||||
242-254 Reserved for local use
|
||||
243-254 Reserved for local use
|
||||
255 Reserved for MISC_DYNAMIC_MINOR
|
||||
|
||||
11 char Raw keyboard device (Linux/SPARC only)
|
||||
|
|
@ -1442,7 +1443,7 @@
|
|||
...
|
||||
|
||||
The driver and documentation may be obtained from
|
||||
http://www.winradio.com/
|
||||
https://www.winradio.com/
|
||||
|
||||
82 block I2O hard disk
|
||||
0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk
|
||||
|
|
@ -1656,7 +1657,7 @@
|
|||
dynamically, so there is no fixed mapping from subdevice
|
||||
pathnames to minor numbers.
|
||||
|
||||
See http://www.comedi.org/ for information about the Comedi
|
||||
See https://www.comedi.org/ for information about the Comedi
|
||||
project.
|
||||
|
||||
98 block User-mode virtual block device
|
||||
|
|
@ -1723,7 +1724,7 @@
|
|||
implementations a kernel presence for caching and easy
|
||||
mounting. For more information about the project,
|
||||
write to <arla-drinkers@stacken.kth.se> or see
|
||||
http://www.stacken.kth.se/project/arla/
|
||||
https://www.stacken.kth.se/project/arla/
|
||||
|
||||
103 block Audit device
|
||||
0 = /dev/audit Audit device
|
||||
|
|
|
|||
|
|
@ -70,10 +70,10 @@ statements via::
|
|||
|
||||
nullarbor:~ # cat <debugfs>/dynamic_debug/control
|
||||
# filename:lineno [module]function flags format
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012"
|
||||
net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
|
||||
net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012"
|
||||
net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012"
|
||||
net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012"
|
||||
...
|
||||
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ the debug statement callsites with any non-default flags::
|
|||
|
||||
nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control
|
||||
# filename:lineno [module]function flags format
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
|
||||
net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
|
||||
|
||||
Command Language Reference
|
||||
==========================
|
||||
|
|
@ -156,6 +156,7 @@ against. Possible keywords are:::
|
|||
``line-range`` cannot contain space, e.g.
|
||||
"1-30" is valid range but "1 - 30" is not.
|
||||
|
||||
``module=foo`` combined keyword=value form is interchangably accepted
|
||||
|
||||
The meanings of each keyword are:
|
||||
|
||||
|
|
@ -164,15 +165,18 @@ func
|
|||
of each callsite. Example::
|
||||
|
||||
func svc_tcp_accept
|
||||
func *recv* # in rfcomm, bluetooth, ping, tcp
|
||||
|
||||
file
|
||||
The given string is compared against either the full pathname, the
|
||||
src-root relative pathname, or the basename of the source file of
|
||||
each callsite. Examples::
|
||||
The given string is compared against either the src-root relative
|
||||
pathname, or the basename of the source file of each callsite.
|
||||
Examples::
|
||||
|
||||
file svcsock.c
|
||||
file kernel/freezer.c
|
||||
file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
|
||||
file kernel/freezer.c # ie column 1 of control file
|
||||
file drivers/usb/* # all callsites under it
|
||||
file inode.c:start_* # parse :tail as a func (above)
|
||||
file inode.c:1-100 # parse :tail as a line-range (above)
|
||||
|
||||
module
|
||||
The given string is compared against the module name
|
||||
|
|
@ -182,6 +186,7 @@ module
|
|||
|
||||
module sunrpc
|
||||
module nfsd
|
||||
module drm* # both drm, drm_kms_helper
|
||||
|
||||
format
|
||||
The given string is searched for in the dynamic debug format
|
||||
|
|
@ -251,8 +256,8 @@ the syntax described above, but must not exceed 1023 characters. Your
|
|||
bootloader may impose lower limits.
|
||||
|
||||
These ``dyndbg`` params are processed just after the ddebug tables are
|
||||
processed, as part of the arch_initcall. Thus you can enable debug
|
||||
messages in all code run after this arch_initcall via this boot
|
||||
processed, as part of the early_initcall. Thus you can enable debug
|
||||
messages in all code run after this early_initcall via this boot
|
||||
parameter.
|
||||
|
||||
On an x86 system for example ACPI enablement is a subsys_initcall and::
|
||||
|
|
|
|||
|
|
@ -395,6 +395,13 @@ When mounting an ext4 filesystem, the following option are accepted:
|
|||
Documentation/filesystems/dax.txt. Note that this option is
|
||||
incompatible with data=journal.
|
||||
|
||||
inlinecrypt
|
||||
When possible, encrypt/decrypt the contents of encrypted files using the
|
||||
blk-crypto framework rather than filesystem-layer encryption. This
|
||||
allows the use of inline encryption hardware. The on-disk format is
|
||||
unaffected. For more details, see
|
||||
Documentation/block/inline-encryption.rst.
|
||||
|
||||
Data Mode
|
||||
=========
|
||||
There are 3 different data modes:
|
||||
|
|
@ -611,7 +618,7 @@ kernel source: <file:fs/ext4/>
|
|||
|
||||
programs: http://e2fsprogs.sourceforge.net/
|
||||
|
||||
useful links: http://fedoraproject.org/wiki/ext3-devel
|
||||
useful links: https://fedoraproject.org/wiki/ext3-devel
|
||||
http://www.bullopensource.org/ext4/
|
||||
http://ext4.wiki.kernel.org/index.php/Main_Page
|
||||
http://fedoraproject.org/wiki/Features/Ext4
|
||||
https://fedoraproject.org/wiki/Features/Ext4
|
||||
|
|
|
|||
|
|
@ -80,6 +80,10 @@ The possible values in this file are:
|
|||
- The processor is not vulnerable.
|
||||
* - KVM: Mitigation: Split huge pages
|
||||
- Software changes mitigate this issue.
|
||||
* - KVM: Mitigation: VMX unsupported
|
||||
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is not supported.
|
||||
* - KVM: Mitigation: VMX disabled
|
||||
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is disabled.
|
||||
* - KVM: Vulnerable
|
||||
- The processor is vulnerable, but no mitigation enabled
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ to the core through the special register mechanism that is susceptible
|
|||
to MDS attacks.
|
||||
|
||||
Affected processors
|
||||
--------------------
|
||||
-------------------
|
||||
Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may
|
||||
be affected.
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ executed on another core or sibling thread using MDS techniques.
|
|||
|
||||
|
||||
Mitigation mechanism
|
||||
-------------------
|
||||
--------------------
|
||||
Intel will release microcode updates that modify the RDRAND, RDSEED, and
|
||||
EGETKEY instructions to overwrite secret special register data in the shared
|
||||
staging buffer before the secret data can be accessed by another logical
|
||||
|
|
@ -118,7 +118,7 @@ with the option "srbds=". The option for this is:
|
|||
============= =============================================================
|
||||
|
||||
SRBDS System Information
|
||||
-----------------------
|
||||
------------------------
|
||||
The Linux kernel provides vulnerability status information through sysfs. For
|
||||
SRBDS this can be accessed by the following sysfs file:
|
||||
/sys/devices/system/cpu/vulnerabilities/srbds
|
||||
|
|
|
|||
|
|
@ -41,6 +41,7 @@ problems and bugs in particular.
|
|||
init
|
||||
kdump/index
|
||||
perf/index
|
||||
pstore-blk
|
||||
|
||||
This is the beginning of a section with information of interest to
|
||||
application developers. Documents covering various aspects of the kernel
|
||||
|
|
|
|||
|
|
@ -93,6 +93,11 @@ It exists in the sparse memory mapping model, and it is also somewhat
|
|||
similar to the mem_map variable, both of them are used to translate an
|
||||
address.
|
||||
|
||||
MAX_PHYSMEM_BITS
|
||||
----------------
|
||||
|
||||
Defines the maximum supported physical address space memory.
|
||||
|
||||
page
|
||||
----
|
||||
|
||||
|
|
@ -399,6 +404,17 @@ KERNELPACMASK
|
|||
The mask to extract the Pointer Authentication Code from a kernel virtual
|
||||
address.
|
||||
|
||||
TCR_EL1.T1SZ
|
||||
------------
|
||||
|
||||
Indicates the size offset of the memory region addressed by TTBR1_EL1.
|
||||
The region size is 2^(64-T1SZ) bytes.
|
||||
|
||||
TTBR1_EL1 is the table base address register specified by ARMv8-A
|
||||
architecture which is used to lookup the page-tables for the Virtual
|
||||
addresses in the higher VA range (refer to ARMv8 ARM document for
|
||||
more details).
|
||||
|
||||
arm
|
||||
===
|
||||
|
||||
|
|
|
|||
|
|
@ -703,6 +703,11 @@
|
|||
cpufreq.off=1 [CPU_FREQ]
|
||||
disable the cpufreq sub-system
|
||||
|
||||
cpufreq.default_governor=
|
||||
[CPU_FREQ] Name of the default cpufreq governor or
|
||||
policy to use. This governor must be registered in the
|
||||
kernel before the cpufreq driver probes.
|
||||
|
||||
cpu_init_udelay=N
|
||||
[X86] Delay for N microsec between assert and de-assert
|
||||
of APIC INIT to start processors. This delay occurs
|
||||
|
|
@ -719,7 +724,7 @@
|
|||
memory region [offset, offset + size] for that kernel
|
||||
image. If '@offset' is omitted, then a suitable offset
|
||||
is selected automatically.
|
||||
[KNL, x86_64] select a region under 4G first, and
|
||||
[KNL, X86-64] Select a region under 4G first, and
|
||||
fall back to reserve region above 4G when '@offset'
|
||||
hasn't been specified.
|
||||
See Documentation/admin-guide/kdump/kdump.rst for further details.
|
||||
|
|
@ -732,14 +737,14 @@
|
|||
Documentation/admin-guide/kdump/kdump.rst for an example.
|
||||
|
||||
crashkernel=size[KMG],high
|
||||
[KNL, x86_64] range could be above 4G. Allow kernel
|
||||
[KNL, X86-64] range could be above 4G. Allow kernel
|
||||
to allocate physical memory region from top, so could
|
||||
be above 4G if system have more than 4G ram installed.
|
||||
Otherwise memory region will be allocated below 4G, if
|
||||
available.
|
||||
It will be ignored if crashkernel=X is specified.
|
||||
crashkernel=size[KMG],low
|
||||
[KNL, x86_64] range under 4G. When crashkernel=X,high
|
||||
[KNL, X86-64] range under 4G. When crashkernel=X,high
|
||||
is passed, kernel could allocate physical memory region
|
||||
above 4G, that cause second kernel crash on system
|
||||
that require some amount of low memory, e.g. swiotlb
|
||||
|
|
@ -827,6 +832,21 @@
|
|||
useful to also enable the page_owner functionality.
|
||||
on: enable the feature
|
||||
|
||||
debugfs= [KNL] This parameter enables what is exposed to userspace
|
||||
and debugfs internal clients.
|
||||
Format: { on, no-mount, off }
|
||||
on: All functions are enabled.
|
||||
no-mount:
|
||||
Filesystem is not registered but kernel clients can
|
||||
access APIs and a crashkernel can be used to read
|
||||
its content. There is nothing to mount.
|
||||
off: Filesystem is not registered and clients
|
||||
get a -EPERM as result when trying to register files
|
||||
or directories within debugfs.
|
||||
This is equivalent of the runtime functionality if
|
||||
debugfs was not enabled in the kernel at all.
|
||||
Default value is set in build-time with a kernel configuration.
|
||||
|
||||
debugpat [X86] Enable PAT debugging
|
||||
|
||||
decnet.addr= [HW,NET]
|
||||
|
|
@ -896,6 +916,10 @@
|
|||
disable_radix [PPC]
|
||||
Disable RADIX MMU mode on POWER9
|
||||
|
||||
radix_hcall_invalidate=on [PPC/PSERIES]
|
||||
Disable RADIX GTSE feature and use hcall for TLB
|
||||
invalidate.
|
||||
|
||||
disable_tlbie [PPC]
|
||||
Disable TLBIE instruction. Currently does not work
|
||||
with KVM, with HASH MMU, or with coherent accelerators.
|
||||
|
|
@ -1207,26 +1231,28 @@
|
|||
Format: {"off" | "on" | "skip[mbr]"}
|
||||
|
||||
efi= [EFI]
|
||||
Format: { "old_map", "nochunk", "noruntime", "debug",
|
||||
"nosoftreserve", "disable_early_pci_dma",
|
||||
"no_disable_early_pci_dma" }
|
||||
old_map [X86-64]: switch to the old ioremap-based EFI
|
||||
runtime services mapping. [Needs CONFIG_X86_UV=y]
|
||||
Format: { "debug", "disable_early_pci_dma",
|
||||
"nochunk", "noruntime", "nosoftreserve",
|
||||
"novamap", "no_disable_early_pci_dma",
|
||||
"old_map" }
|
||||
debug: enable misc debug output.
|
||||
disable_early_pci_dma: disable the busmaster bit on all
|
||||
PCI bridges while in the EFI boot stub.
|
||||
nochunk: disable reading files in "chunks" in the EFI
|
||||
boot stub, as chunking can cause problems with some
|
||||
firmware implementations.
|
||||
noruntime : disable EFI runtime services support
|
||||
debug: enable misc debug output
|
||||
nosoftreserve: The EFI_MEMORY_SP (Specific Purpose)
|
||||
attribute may cause the kernel to reserve the
|
||||
memory range for a memory mapping driver to
|
||||
claim. Specify efi=nosoftreserve to disable this
|
||||
reservation and treat the memory by its base type
|
||||
(i.e. EFI_CONVENTIONAL_MEMORY / "System RAM").
|
||||
disable_early_pci_dma: Disable the busmaster bit on all
|
||||
PCI bridges while in the EFI boot stub
|
||||
novamap: do not call SetVirtualAddressMap().
|
||||
no_disable_early_pci_dma: Leave the busmaster bit set
|
||||
on all PCI bridges while in the EFI boot stub
|
||||
old_map [X86-64]: switch to the old ioremap-based EFI
|
||||
runtime services mapping. [Needs CONFIG_X86_UV=y]
|
||||
|
||||
efi_no_storage_paranoia [EFI; X86]
|
||||
Using this parameter you can use more than 50% of
|
||||
|
|
@ -1401,7 +1427,7 @@
|
|||
|
||||
gamma= [HW,DRM]
|
||||
|
||||
gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
|
||||
gart_fix_e820= [X86-64] disable the fix e820 for K8 GART
|
||||
Format: off | on
|
||||
default: on
|
||||
|
||||
|
|
@ -1788,7 +1814,7 @@
|
|||
Format: 0 | 1
|
||||
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
|
||||
|
||||
init_pkru= [x86] Specify the default memory protection keys rights
|
||||
init_pkru= [X86] Specify the default memory protection keys rights
|
||||
register contents for all processes. 0x55555554 by
|
||||
default (disallow access to all but pkey 0). Can
|
||||
override in debugfs after boot.
|
||||
|
|
@ -1796,7 +1822,7 @@
|
|||
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
|
||||
Format: <irq>
|
||||
|
||||
int_pln_enable [x86] Enable power limit notification interrupt
|
||||
int_pln_enable [X86] Enable power limit notification interrupt
|
||||
|
||||
integrity_audit=[IMA]
|
||||
Format: { "0" | "1" }
|
||||
|
|
@ -1814,7 +1840,7 @@
|
|||
bypassed by not enabling DMAR with this option. In
|
||||
this case, gfx device will use physical address for
|
||||
DMA.
|
||||
forcedac [x86_64]
|
||||
forcedac [X86-64]
|
||||
With this option iommu will not optimize to look
|
||||
for io virtual address below 32-bit forcing dual
|
||||
address cycle on pci bus for cards supporting greater
|
||||
|
|
@ -1899,7 +1925,7 @@
|
|||
strict regions from userspace.
|
||||
relaxed
|
||||
|
||||
iommu= [x86]
|
||||
iommu= [X86]
|
||||
off
|
||||
force
|
||||
noforce
|
||||
|
|
@ -1909,8 +1935,8 @@
|
|||
merge
|
||||
nomerge
|
||||
soft
|
||||
pt [x86]
|
||||
nopt [x86]
|
||||
pt [X86]
|
||||
nopt [X86]
|
||||
nobypass [PPC/POWERNV]
|
||||
Disable IOMMU bypass, using IOMMU for PCI devices.
|
||||
|
||||
|
|
@ -2053,21 +2079,21 @@
|
|||
|
||||
iucv= [HW,NET]
|
||||
|
||||
ivrs_ioapic [HW,X86_64]
|
||||
ivrs_ioapic [HW,X86-64]
|
||||
Provide an override to the IOAPIC-ID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map IOAPIC-ID decimal 10 to
|
||||
PCI device 00:14.0 write the parameter as:
|
||||
ivrs_ioapic[10]=00:14.0
|
||||
|
||||
ivrs_hpet [HW,X86_64]
|
||||
ivrs_hpet [HW,X86-64]
|
||||
Provide an override to the HPET-ID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map HPET-ID decimal 0 to
|
||||
PCI device 00:14.0 write the parameter as:
|
||||
ivrs_hpet[0]=00:14.0
|
||||
|
||||
ivrs_acpihid [HW,X86_64]
|
||||
ivrs_acpihid [HW,X86-64]
|
||||
Provide an override to the ACPI-HID:UID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map UART-HID:UID AMD0020:0 to
|
||||
|
|
@ -2344,7 +2370,7 @@
|
|||
lapic [X86-32,APIC] Enable the local APIC even if BIOS
|
||||
disabled it.
|
||||
|
||||
lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline
|
||||
lapic= [X86,APIC] "notscdeadline" Do not use TSC deadline
|
||||
value for LAPIC timer one-shot implementation. Default
|
||||
back to the programmable timer unit in the LAPIC.
|
||||
|
||||
|
|
@ -2786,7 +2812,7 @@
|
|||
touchscreen support is not enabled in the mainstream
|
||||
kernel as of 2.6.30, a preliminary port can be found
|
||||
in the "bleeding edge" mini2440 support kernel at
|
||||
http://repo.or.cz/w/linux-2.6/mini2440.git
|
||||
https://repo.or.cz/w/linux-2.6/mini2440.git
|
||||
|
||||
mitigations=
|
||||
[X86,PPC,S390,ARM64] Control optional mitigations for
|
||||
|
|
@ -3079,6 +3105,8 @@
|
|||
no5lvl [X86-64] Disable 5-level paging mode. Forces
|
||||
kernel to use 4-level paging instead.
|
||||
|
||||
nofsgsbase [X86] Disables FSGSBASE instructions.
|
||||
|
||||
no_console_suspend
|
||||
[HW] Never suspend the console
|
||||
Disable suspending of consoles during suspend and
|
||||
|
|
@ -3160,12 +3188,12 @@
|
|||
register save and restore. The kernel will only save
|
||||
legacy floating-point registers on task switch.
|
||||
|
||||
nohugeiomap [KNL,x86,PPC] Disable kernel huge I/O mappings.
|
||||
nohugeiomap [KNL,X86,PPC] Disable kernel huge I/O mappings.
|
||||
|
||||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||
Equivalent to smt=1.
|
||||
|
||||
[KNL,x86] Disable symmetric multithreading (SMT).
|
||||
[KNL,X86] Disable symmetric multithreading (SMT).
|
||||
nosmt=force: Force disable SMT, cannot be undone
|
||||
via the sysfs control file.
|
||||
|
||||
|
|
@ -3927,7 +3955,7 @@
|
|||
pt. [PARIDE]
|
||||
See Documentation/admin-guide/blockdev/paride.rst.
|
||||
|
||||
pti= [X86_64] Control Page Table Isolation of user and
|
||||
pti= [X86-64] Control Page Table Isolation of user and
|
||||
kernel address spaces. Disabling this feature
|
||||
removes hardening, but improves performance of
|
||||
system calls and interrupts.
|
||||
|
|
@ -3939,7 +3967,7 @@
|
|||
|
||||
Not specifying this option is equivalent to pti=auto.
|
||||
|
||||
nopti [X86_64]
|
||||
nopti [X86-64]
|
||||
Equivalent to pti=off
|
||||
|
||||
pty.legacy_count=
|
||||
|
|
@ -4038,6 +4066,14 @@
|
|||
latencies, which will choose a value aligned
|
||||
with the appropriate hardware boundaries.
|
||||
|
||||
rcutree.rcu_min_cached_objs= [KNL]
|
||||
Minimum number of objects which are cached and
|
||||
maintained per one CPU. Object size is equal
|
||||
to PAGE_SIZE. The cache allows to reduce the
|
||||
pressure to page allocator, also it makes the
|
||||
whole algorithm to behave better in low memory
|
||||
condition.
|
||||
|
||||
rcutree.jiffies_till_first_fqs= [KNL]
|
||||
Set delay from grace-period initialization to
|
||||
first attempt to force quiescent states.
|
||||
|
|
@ -4258,6 +4294,20 @@
|
|||
Set time (jiffies) between CPU-hotplug operations,
|
||||
or zero to disable CPU-hotplug testing.
|
||||
|
||||
rcutorture.read_exit= [KNL]
|
||||
Set the number of read-then-exit kthreads used
|
||||
to test the interaction of RCU updaters and
|
||||
task-exit processing.
|
||||
|
||||
rcutorture.read_exit_burst= [KNL]
|
||||
The number of times in a given read-then-exit
|
||||
episode that a set of read-then-exit kthreads
|
||||
is spawned.
|
||||
|
||||
rcutorture.read_exit_delay= [KNL]
|
||||
The delay, in seconds, between successive
|
||||
read-then-exit testing episodes.
|
||||
|
||||
rcutorture.shuffle_interval= [KNL]
|
||||
Set task-shuffle interval (s). Shuffling tasks
|
||||
allows some CPUs to go into dyntick-idle mode
|
||||
|
|
@ -4407,6 +4457,45 @@
|
|||
reboot_cpu is s[mp]#### with #### being the processor
|
||||
to be used for rebooting.
|
||||
|
||||
refscale.holdoff= [KNL]
|
||||
Set test-start holdoff period. The purpose of
|
||||
this parameter is to delay the start of the
|
||||
test until boot completes in order to avoid
|
||||
interference.
|
||||
|
||||
refscale.loops= [KNL]
|
||||
Set the number of loops over the synchronization
|
||||
primitive under test. Increasing this number
|
||||
reduces noise due to loop start/end overhead,
|
||||
but the default has already reduced the per-pass
|
||||
noise to a handful of picoseconds on ca. 2020
|
||||
x86 laptops.
|
||||
|
||||
refscale.nreaders= [KNL]
|
||||
Set number of readers. The default value of -1
|
||||
selects N, where N is roughly 75% of the number
|
||||
of CPUs. A value of zero is an interesting choice.
|
||||
|
||||
refscale.nruns= [KNL]
|
||||
Set number of runs, each of which is dumped onto
|
||||
the console log.
|
||||
|
||||
refscale.readdelay= [KNL]
|
||||
Set the read-side critical-section duration,
|
||||
measured in microseconds.
|
||||
|
||||
refscale.scale_type= [KNL]
|
||||
Specify the read-protection implementation to test.
|
||||
|
||||
refscale.shutdown= [KNL]
|
||||
Shut down the system at the end of the performance
|
||||
test. This defaults to 1 (shut it down) when
|
||||
rcuperf is built into the kernel and to 0 (leave
|
||||
it running) when rcuperf is built as a module.
|
||||
|
||||
refscale.verbose= [KNL]
|
||||
Enable additional printk() statements.
|
||||
|
||||
relax_domain_level=
|
||||
[KNL, SMP] Set scheduler's default relax_domain_level.
|
||||
See Documentation/admin-guide/cgroup-v1/cpusets.rst.
|
||||
|
|
@ -4604,7 +4693,7 @@
|
|||
fragmentation. Defaults to 1 for systems with
|
||||
more than 32MB of RAM, 0 otherwise.
|
||||
|
||||
slub_debug[=options[,slabs]] [MM, SLUB]
|
||||
slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
|
||||
Enabling slub_debug allows one to determine the
|
||||
culprit if slab objects become corrupted. Enabling
|
||||
slub_debug can create guard zones around objects and
|
||||
|
|
@ -5082,6 +5171,13 @@
|
|||
Prevent the CPU-hotplug component of torturing
|
||||
until after init has spawned.
|
||||
|
||||
torture.ftrace_dump_at_shutdown= [KNL]
|
||||
Dump the ftrace buffer at torture-test shutdown,
|
||||
even if there were no errors. This can be a
|
||||
very costly operation when many torture tests
|
||||
are running concurrently, especially on systems
|
||||
with rotating-rust storage.
|
||||
|
||||
tp720= [HW,PS2]
|
||||
|
||||
tpm_suspend_pcr=[HW,TPM]
|
||||
|
|
@ -5712,8 +5808,9 @@
|
|||
panic() code such as dumping handler.
|
||||
|
||||
xen_nopvspin [X86,XEN]
|
||||
Disables the ticketlock slowpath using Xen PV
|
||||
optimizations.
|
||||
Disables the qspinlock slowpath using Xen PV optimizations.
|
||||
This parameter is obsoleted by "nopvspin" parameter, which
|
||||
has equivalent effect for XEN platform.
|
||||
|
||||
xen_nopv [X86]
|
||||
Disables the PV optimizations forcing the HVM guest to
|
||||
|
|
@ -5739,6 +5836,11 @@
|
|||
as generic guest with no PV drivers. Currently support
|
||||
XEN HVM, KVM, HYPER_V and VMWARE guest.
|
||||
|
||||
nopvspin [X86,XEN,KVM]
|
||||
Disables the qspinlock slow path using PV optimizations
|
||||
which allow the hypervisor to 'idle' the guest on lock
|
||||
contention.
|
||||
|
||||
xirc2ps_cs= [NET,PCMCIA]
|
||||
Format:
|
||||
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ single project which, although still considered experimental, is fit
|
|||
for use. Please feel free to add projects that have been the victims
|
||||
of my ignorance.
|
||||
|
||||
- http://www.thinkwiki.org/wiki/HDAPS
|
||||
- https://www.thinkwiki.org/wiki/HDAPS
|
||||
|
||||
See this page for information about Linux support of the hard disk
|
||||
active protection system as implemented in IBM/Lenovo Thinkpads.
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Bugs:
|
|||
different way to adjust the backlighting of the screen. There
|
||||
is a userspace utility to adjust the brightness on those models,
|
||||
which can be downloaded from
|
||||
http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2
|
||||
https://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2
|
||||
|
||||
- since all development was done by reverse engineering, there is
|
||||
*absolutely no guarantee* that this driver will not crash your
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ detailed description):
|
|||
- WAN enable and disable
|
||||
- UWB enable and disable
|
||||
- LCD Shadow (PrivacyGuard) enable and disable
|
||||
- Lap mode sensor
|
||||
|
||||
A compatibility table by model and feature is maintained on the web
|
||||
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
|
||||
|
|
@ -904,7 +905,7 @@ temperatures:
|
|||
The mapping of thermal sensors to physical locations varies depending on
|
||||
system-board model (and thus, on ThinkPad model).
|
||||
|
||||
http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that
|
||||
https://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that
|
||||
tries to track down these locations for various models.
|
||||
|
||||
Most (newer?) models seem to follow this pattern:
|
||||
|
|
@ -925,7 +926,7 @@ For the R51 (source: Thomas Gruber):
|
|||
- 3: Internal HDD
|
||||
|
||||
For the T43, T43/p (source: Shmidoax/Thinkwiki.org)
|
||||
http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
|
||||
https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
|
||||
|
||||
- 2: System board, left side (near PCMCIA slot), reported as HDAPS temp
|
||||
- 3: PCMCIA slot
|
||||
|
|
@ -935,7 +936,7 @@ http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
|
|||
- 11: Power regulator, underside of system board, below F2 key
|
||||
|
||||
The A31 has a very atypical layout for the thermal sensors
|
||||
(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31)
|
||||
(source: Milos Popovic, https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31)
|
||||
|
||||
- 1: CPU
|
||||
- 2: Main Battery: main sensor
|
||||
|
|
@ -1432,6 +1433,20 @@ The first command ensures the best viewing angle and the latter one turns
|
|||
on the feature, restricting the viewing angles.
|
||||
|
||||
|
||||
DYTC Lapmode sensor
|
||||
------------------
|
||||
|
||||
sysfs: dytc_lapmode
|
||||
|
||||
Newer thinkpads and mobile workstations have the ability to determine if
|
||||
the device is in deskmode or lapmode. This feature is used by user space
|
||||
to decide if WWAN transmission can be increased to maximum power and is
|
||||
also useful for understanding the different thermal modes available as
|
||||
they differ between desk and lap mode.
|
||||
|
||||
The property is read-only. If the platform doesn't have support the sysfs
|
||||
class is not created.
|
||||
|
||||
EXPERIMENTAL: UWB
|
||||
-----------------
|
||||
|
||||
|
|
@ -1470,6 +1485,23 @@ For more details about which buttons will appear depending on the mode, please
|
|||
review the laptop's user guide:
|
||||
http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf
|
||||
|
||||
Battery charge control
|
||||
----------------------
|
||||
|
||||
sysfs attributes:
|
||||
/sys/class/power_supply/BAT*/charge_control_{start,end}_threshold
|
||||
|
||||
These two attributes are created for those batteries that are supported by the
|
||||
driver. They enable the user to control the battery charge thresholds of the
|
||||
given battery. Both values may be read and set. `charge_control_start_threshold`
|
||||
accepts an integer between 0 and 99 (inclusive); this value represents a battery
|
||||
percentage level, below which charging will begin. `charge_control_end_threshold`
|
||||
accepts an integer between 1 and 100 (inclusive); this value represents a battery
|
||||
percentage level, above which charging will stop.
|
||||
|
||||
The exact semantics of the attributes may be found in
|
||||
Documentation/ABI/testing/sysfs-class-power.
|
||||
|
||||
Multiple Commands, Module Parameters
|
||||
------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -426,6 +426,10 @@ All md devices contain:
|
|||
The accepted values when writing to this file are ``ppl`` and ``resync``,
|
||||
used to enable and disable PPL.
|
||||
|
||||
uuid
|
||||
This indicates the UUID of the array in the following format:
|
||||
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
|
||||
|
||||
|
||||
As component devices are added to an md array, they appear in the ``md``
|
||||
directory as new directories named::
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ built as modules.
|
|||
Those GPU-specific drivers are selected via the ``Graphics support``
|
||||
menu, under ``Device Drivers``.
|
||||
|
||||
When a GPU driver supports supports HDMI CEC, it will automatically
|
||||
When a GPU driver supports HDMI CEC, it will automatically
|
||||
enable the CEC core support at the media subsystem.
|
||||
|
||||
Media dependencies
|
||||
|
|
@ -244,7 +244,7 @@ functionality.
|
|||
If you have an hybrid card, you may need to enable both ``Analog TV``
|
||||
and ``Digital TV`` at the menu.
|
||||
|
||||
When using this option, the defaults for the the media support core
|
||||
When using this option, the defaults for the media support core
|
||||
functionality are usually good enough to provide the basic functionality
|
||||
for the driver. Yet, you could manually enable some desired extra (optional)
|
||||
functionality using the settings under each of the following
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
The Samsung S5P/EXYNOS4 FIMC driver
|
||||
The Samsung S5P/Exynos4 FIMC driver
|
||||
===================================
|
||||
|
||||
Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
|
||||
|
|
@ -19,7 +19,7 @@ drivers/media/platform/exynos4-is directory.
|
|||
Supported SoCs
|
||||
--------------
|
||||
|
||||
S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
|
||||
S5PC100 (mem-to-mem only), S5PV210, Exynos4210
|
||||
|
||||
Supported features
|
||||
------------------
|
||||
|
|
@ -45,7 +45,7 @@ Media device interface
|
|||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The driver supports Media Controller API as defined at :ref:`media_controller`.
|
||||
The media device driver name is "SAMSUNG S5P FIMC".
|
||||
The media device driver name is "Samsung S5P FIMC".
|
||||
|
||||
The purpose of this interface is to allow changing assignment of FIMC instances
|
||||
to the SoC peripheral camera input at runtime and optionally to control internal
|
||||
|
|
|
|||
|
|
@ -293,6 +293,15 @@ all configurable using the following module options:
|
|||
- 0: vmalloc
|
||||
- 1: dma-contig
|
||||
|
||||
- cache_hints:
|
||||
|
||||
specifies if the device should set queues' user-space cache and memory
|
||||
consistency hint capability (V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS).
|
||||
The hints are valid only when using MMAP streaming I/O. Default is 0.
|
||||
|
||||
- 0: forbid hints
|
||||
- 1: allow hints
|
||||
|
||||
Taken together, all these module options allow you to precisely customize
|
||||
the driver behavior and test your application with all sorts of permutations.
|
||||
It is also very suitable to emulate hardware that is not yet available, e.g.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ physical memory (demand paging) and provides a mechanism for the
|
|||
protection and controlled sharing of data between processes.
|
||||
|
||||
With virtual memory, each and every memory access uses a virtual
|
||||
address. When the CPU decodes the an instruction that reads (or
|
||||
address. When the CPU decodes an instruction that reads (or
|
||||
writes) from (or to) the system memory, it translates the `virtual`
|
||||
address encoded in that instruction to a `physical` address that the
|
||||
memory controller can understand.
|
||||
|
|
|
|||
|
|
@ -101,37 +101,48 @@ be specified in bytes with optional scale suffix [kKmMgG]. The default huge
|
|||
page size may be selected with the "default_hugepagesz=<size>" boot parameter.
|
||||
|
||||
Hugetlb boot command line parameter semantics
|
||||
hugepagesz - Specify a huge page size. Used in conjunction with hugepages
|
||||
|
||||
hugepagesz
|
||||
Specify a huge page size. Used in conjunction with hugepages
|
||||
parameter to preallocate a number of huge pages of the specified
|
||||
size. Hence, hugepagesz and hugepages are typically specified in
|
||||
pairs such as:
|
||||
pairs such as::
|
||||
|
||||
hugepagesz=2M hugepages=512
|
||||
|
||||
hugepagesz can only be specified once on the command line for a
|
||||
specific huge page size. Valid huge page sizes are architecture
|
||||
dependent.
|
||||
hugepages - Specify the number of huge pages to preallocate. This typically
|
||||
hugepages
|
||||
Specify the number of huge pages to preallocate. This typically
|
||||
follows a valid hugepagesz or default_hugepagesz parameter. However,
|
||||
if hugepages is the first or only hugetlb command line parameter it
|
||||
implicitly specifies the number of huge pages of default size to
|
||||
allocate. If the number of huge pages of default size is implicitly
|
||||
specified, it can not be overwritten by a hugepagesz,hugepages
|
||||
parameter pair for the default size.
|
||||
For example, on an architecture with 2M default huge page size:
|
||||
|
||||
For example, on an architecture with 2M default huge page size::
|
||||
|
||||
hugepages=256 hugepagesz=2M hugepages=512
|
||||
|
||||
will result in 256 2M huge pages being allocated and a warning message
|
||||
indicating that the hugepages=512 parameter is ignored. If a hugepages
|
||||
parameter is preceded by an invalid hugepagesz parameter, it will
|
||||
be ignored.
|
||||
default_hugepagesz - Specify the default huge page size. This parameter can
|
||||
default_hugepagesz
|
||||
pecify the default huge page size. This parameter can
|
||||
only be specified once on the command line. default_hugepagesz can
|
||||
optionally be followed by the hugepages parameter to preallocate a
|
||||
specific number of huge pages of default size. The number of default
|
||||
sized huge pages to preallocate can also be implicitly specified as
|
||||
mentioned in the hugepages section above. Therefore, on an
|
||||
architecture with 2M default huge page size:
|
||||
architecture with 2M default huge page size::
|
||||
|
||||
hugepages=256
|
||||
default_hugepagesz=2M hugepages=256
|
||||
hugepages=256 default_hugepagesz=2M
|
||||
|
||||
will all result in 256 2M huge pages being allocated. Valid default
|
||||
huge page size is architecture dependent.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ the Linux memory management.
|
|||
idle_page_tracking
|
||||
ksm
|
||||
memory-hotplug
|
||||
nommu-mmap
|
||||
numa_memory_policy
|
||||
numaperf
|
||||
pagemap
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Overview
|
|||
|
||||
KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y,
|
||||
added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation,
|
||||
and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/
|
||||
and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/
|
||||
|
||||
KSM was originally developed for use with KVM (where it was known as
|
||||
Kernel Shared Memory), to fit more virtual machines into physical memory,
|
||||
|
|
@ -52,7 +52,7 @@ with EAGAIN, but more probably arousing the Out-Of-Memory killer.
|
|||
If KSM is not configured into the running kernel, madvise MADV_MERGEABLE
|
||||
and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was
|
||||
built with CONFIG_KSM=y, those calls will normally succeed: even if the
|
||||
the KSM daemon is not currently running, MADV_MERGEABLE still registers
|
||||
KSM daemon is not currently running, MADV_MERGEABLE still registers
|
||||
the range for whenever the KSM daemon is started; even if the range
|
||||
cannot contain any pages which KSM could actually merge; even if
|
||||
MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ will create the following directory::
|
|||
|
||||
/sys/devices/system/node/nodeX/memory_side_cache/
|
||||
|
||||
If that directory is not present, the system either does not not provide
|
||||
If that directory is not present, the system either does not provide
|
||||
a memory-side cache, or that information is not accessible to the kernel.
|
||||
|
||||
The attributes for each level of cache is provided under its cache
|
||||
|
|
|
|||
|
|
@ -65,8 +65,8 @@ migrated onto another server by means of the special "fs_locations"
|
|||
attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and
|
||||
`Implementation Guide for Referrals in NFSv4`_.
|
||||
|
||||
.. _RFC3530 Section 6\: Filesystem Migration and Replication: http://tools.ietf.org/html/rfc3530#section-6
|
||||
.. _Implementation Guide for Referrals in NFSv4: http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00
|
||||
.. _RFC3530 Section 6\: Filesystem Migration and Replication: https://tools.ietf.org/html/rfc3530#section-6
|
||||
.. _Implementation Guide for Referrals in NFSv4: https://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00
|
||||
|
||||
The fs_locations information can take the form of either an ip address and
|
||||
a path, or a DNS hostname and a path. The latter requires the NFS client to
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ use with NFS/RDMA.
|
|||
If the version is less than 1.1.2 or the command does not exist,
|
||||
you should install the latest version of nfs-utils.
|
||||
|
||||
Download the latest package from: http://www.kernel.org/pub/linux/utils/nfs
|
||||
Download the latest package from: https://www.kernel.org/pub/linux/utils/nfs
|
||||
|
||||
Uncompress the package and follow the installation instructions.
|
||||
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ They depend on various facilities being available:
|
|||
access to the floppy drive device, /dev/fd0
|
||||
|
||||
For more information on syslinux, including how to create bootdisks
|
||||
for prebuilt kernels, see http://syslinux.zytor.com/
|
||||
for prebuilt kernels, see https://syslinux.zytor.com/
|
||||
|
||||
.. note::
|
||||
Previously it was possible to write a kernel directly to
|
||||
|
|
@ -292,7 +292,7 @@ They depend on various facilities being available:
|
|||
cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso
|
||||
|
||||
For more information on isolinux, including how to create bootdisks
|
||||
for prebuilt kernels, see http://syslinux.zytor.com/
|
||||
for prebuilt kernels, see https://syslinux.zytor.com/
|
||||
|
||||
- Using LILO
|
||||
|
||||
|
|
@ -346,7 +346,7 @@ They depend on various facilities being available:
|
|||
see Documentation/admin-guide/serial-console.rst for more information.
|
||||
|
||||
For more information on isolinux, including how to create bootdisks
|
||||
for prebuilt kernels, see http://syslinux.zytor.com/
|
||||
for prebuilt kernels, see https://syslinux.zytor.com/
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ to handling all the metadata access to the NFS export also hands out layouts
|
|||
to the clients to directly access the underlying block devices that are
|
||||
shared with the client.
|
||||
|
||||
To use pNFS block layouts with with the Linux NFS server the exported file
|
||||
To use pNFS block layouts with the Linux NFS server the exported file
|
||||
system needs to support the pNFS block layouts (currently just XFS), and the
|
||||
file system must sit on shared storage (typically iSCSI) that is accessible
|
||||
to the clients in addition to the MDS. As of now the file system needs to
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ which in addition to handling all the metadata access to the NFS export,
|
|||
also hands out layouts to the clients so that they can directly access the
|
||||
underlying SCSI LUNs that are shared with the client.
|
||||
|
||||
To use pNFS SCSI layouts with with the Linux NFS server, the exported file
|
||||
To use pNFS SCSI layouts with the Linux NFS server, the exported file
|
||||
system needs to support the pNFS SCSI layouts (currently just XFS), and the
|
||||
file system must sit on a SCSI LUN that is accessible to the clients in
|
||||
addition to the MDS. As of now the file system needs to sit directly on the
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Crosspoint PMU events require "xp" (index), "bus" (bus number)
|
|||
and "vc" (virtual channel ID).
|
||||
|
||||
Crosspoint watchpoint-based events (special "event" value 0xfe)
|
||||
require "xp" and "vc" as as above plus "port" (device port index),
|
||||
require "xp" and "vc" as above plus "port" (device port index),
|
||||
"dir" (transmit/receive direction), comparator values ("cmp_l"
|
||||
and "cmp_h") and "mask", being index of the comparator mask.
|
||||
|
||||
|
|
|
|||
|
|
@ -147,9 +147,9 @@ CPUs in it.
|
|||
|
||||
The next major initialization step for a new policy object is to attach a
|
||||
scaling governor to it (to begin with, that is the default scaling governor
|
||||
determined by the kernel configuration, but it may be changed later
|
||||
via ``sysfs``). First, a pointer to the new policy object is passed to the
|
||||
governor's ``->init()`` callback which is expected to initialize all of the
|
||||
determined by the kernel command line or configuration, but it may be changed
|
||||
later via ``sysfs``). First, a pointer to the new policy object is passed to
|
||||
the governor's ``->init()`` callback which is expected to initialize all of the
|
||||
data structures necessary to handle the given policy and, possibly, to add
|
||||
a governor ``sysfs`` interface to it. Next, the governor is started by
|
||||
invoking its ``->start()`` callback.
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ base performance profile (which is performance level 0).
|
|||
Lock/Unlock status
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Even if there are multiple performance profiles, it is possible that that they
|
||||
Even if there are multiple performance profiles, it is possible that they
|
||||
are locked. If they are locked, users cannot issue a command to change the
|
||||
performance state. It is possible that there is a BIOS setup to unlock or check
|
||||
with your system vendor.
|
||||
|
|
@ -883,7 +883,7 @@ To enable Intel(R) SST-TF, execute::
|
|||
enable:success
|
||||
|
||||
In this case, the option "-a" is optional. If set, it enables Intel(R) SST-TF
|
||||
feature and also sets the CPUs to high and and low priority using Intel Speed
|
||||
feature and also sets the CPUs to high and low priority using Intel Speed
|
||||
Select Technology Core Power (Intel(R) SST-CP) features. The CPU numbers passed
|
||||
with "-c" arguments are marked as high priority, including its siblings.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,10 +54,13 @@ registered (see `below <status_attr_>`_).
|
|||
Operation Modes
|
||||
===============
|
||||
|
||||
``intel_pstate`` can operate in three different modes: in the active mode with
|
||||
or without hardware-managed P-states support and in the passive mode. Which of
|
||||
them will be in effect depends on what kernel command line options are used and
|
||||
on the capabilities of the processor.
|
||||
``intel_pstate`` can operate in two different modes, active or passive. In the
|
||||
active mode, it uses its own internal performance scaling governor algorithm or
|
||||
allows the hardware to do preformance scaling by itself, while in the passive
|
||||
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
|
||||
a certain performance scaling algorithm. Which of them will be in effect
|
||||
depends on what kernel command line options are used and on the capabilities of
|
||||
the processor.
|
||||
|
||||
Active Mode
|
||||
-----------
|
||||
|
|
@ -194,10 +197,11 @@ This is the default operation mode of ``intel_pstate`` for processors without
|
|||
hardware-managed P-states (HWP) support. It is always used if the
|
||||
``intel_pstate=passive`` argument is passed to the kernel in the command line
|
||||
regardless of whether or not the given processor supports HWP. [Note that the
|
||||
``intel_pstate=no_hwp`` setting implies ``intel_pstate=passive`` if it is used
|
||||
without ``intel_pstate=active``.] Like in the active mode without HWP support,
|
||||
in this mode ``intel_pstate`` may refuse to work with processors that are not
|
||||
recognized by it.
|
||||
``intel_pstate=no_hwp`` setting causes the driver to start in the passive mode
|
||||
if it is not combined with ``intel_pstate=active``.] Like in the active mode
|
||||
without HWP support, in this mode ``intel_pstate`` may refuse to work with
|
||||
processors that are not recognized by it if HWP is prevented from being enabled
|
||||
through the kernel command line.
|
||||
|
||||
If the driver works in this mode, the ``scaling_driver`` policy attribute in
|
||||
``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
|
||||
|
|
@ -318,10 +322,9 @@ manuals need to be consulted to get to it too.
|
|||
|
||||
For this reason, there is a list of supported processors in ``intel_pstate`` and
|
||||
the driver initialization will fail if the detected processor is not in that
|
||||
list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to
|
||||
obtain all of the information listed above is the same for all of the processors
|
||||
supporting the HWP feature, which is why they all are supported by
|
||||
``intel_pstate``.]
|
||||
list, unless it supports the HWP feature. [The interface to obtain all of the
|
||||
information listed above is the same for all of the processors supporting the
|
||||
HWP feature, which is why ``intel_pstate`` works with all of them.]
|
||||
|
||||
|
||||
User Space Interface in ``sysfs``
|
||||
|
|
@ -425,11 +428,16 @@ argument is passed to the kernel in the command line.
|
|||
as well as the per-policy ones) are then reset to their default
|
||||
values, possibly depending on the target operation mode.]
|
||||
|
||||
That only is supported in some configurations, though (for example, if
|
||||
the `HWP feature is enabled in the processor <Active Mode With HWP_>`_,
|
||||
the operation mode of the driver cannot be changed), and if it is not
|
||||
supported in the current configuration, writes to this attribute will
|
||||
fail with an appropriate error.
|
||||
``energy_efficiency``
|
||||
This attribute is only present on platforms with CPUs matching the Kaby
|
||||
Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
|
||||
optimizations are disabled on these CPU models if HWP is enabled.
|
||||
Enabling energy-efficiency optimizations may limit maximum operating
|
||||
frequency with or without the HWP feature. With HWP enabled, the
|
||||
optimizations are done only in the turbo frequency range. Without it,
|
||||
they are done in the entire available frequency range. Setting this
|
||||
attribute to "1" enables the energy-efficiency optimizations and setting
|
||||
to "0" disables them.
|
||||
|
||||
Interpretation of Policy Attributes
|
||||
-----------------------------------
|
||||
|
|
@ -473,8 +481,8 @@ Next, the following policy attributes have special meaning if
|
|||
policy for the time interval between the last two invocations of the
|
||||
driver's utilization update callback by the CPU scheduler for that CPU.
|
||||
|
||||
One more policy attribute is present if the `HWP feature is enabled in the
|
||||
processor <Active Mode With HWP_>`_:
|
||||
One more policy attribute is present if the HWP feature is enabled in the
|
||||
processor:
|
||||
|
||||
``base_frequency``
|
||||
Shows the base frequency of the CPU. Any frequency above this will be
|
||||
|
|
@ -515,11 +523,11 @@ on the following rules, regardless of the current operation mode of the driver:
|
|||
|
||||
3. The global and per-policy limits can be set independently.
|
||||
|
||||
If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
|
||||
resulting effective values are written into its registers whenever the limits
|
||||
change in order to request its internal P-state selection logic to always set
|
||||
P-states within these limits. Otherwise, the limits are taken into account by
|
||||
scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
|
||||
In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
|
||||
resulting effective values are written into hardware registers whenever the
|
||||
limits change in order to request its internal P-state selection logic to always
|
||||
set P-states within these limits. Otherwise, the limits are taken into account
|
||||
by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
|
||||
every time before setting a new P-state for a CPU.
|
||||
|
||||
Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
|
||||
|
|
@ -530,12 +538,11 @@ at all and the only way to set the limits is by using the policy attributes.
|
|||
Energy vs Performance Hints
|
||||
---------------------------
|
||||
|
||||
If ``intel_pstate`` works in the `active mode with the HWP feature enabled
|
||||
<Active Mode With HWP_>`_ in the processor, additional attributes are present
|
||||
in every ``CPUFreq`` policy directory in ``sysfs``. They are intended to allow
|
||||
user space to help ``intel_pstate`` to adjust the processor's internal P-state
|
||||
selection logic by focusing it on performance or on energy-efficiency, or
|
||||
somewhere between the two extremes:
|
||||
If the hardware-managed P-states (HWP) is enabled in the processor, additional
|
||||
attributes, intended to allow user space to help ``intel_pstate`` to adjust the
|
||||
processor's internal P-state selection logic by focusing it on performance or on
|
||||
energy-efficiency, or somewhere between the two extremes, are present in every
|
||||
``CPUFreq`` policy directory in ``sysfs``. They are :
|
||||
|
||||
``energy_performance_preference``
|
||||
Current value of the energy vs performance hint for the given policy
|
||||
|
|
@ -554,7 +561,11 @@ somewhere between the two extremes:
|
|||
Strings written to the ``energy_performance_preference`` attribute are
|
||||
internally translated to integer values written to the processor's
|
||||
Energy-Performance Preference (EPP) knob (if supported) or its
|
||||
Energy-Performance Bias (EPB) knob.
|
||||
Energy-Performance Bias (EPB) knob. It is also possible to write a positive
|
||||
integer value between 0 to 255, if the EPP feature is present. If the EPP
|
||||
feature is not present, writing integer value to this attribute is not
|
||||
supported. In this case, user can use
|
||||
"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
|
||||
|
||||
[Note that tasks may by migrated from one CPU to another by the scheduler's
|
||||
load-balancing algorithm and if different energy vs performance hints are
|
||||
|
|
@ -635,12 +646,14 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
|
|||
Do not register ``intel_pstate`` as the scaling driver even if the
|
||||
processor is supported by it.
|
||||
|
||||
``active``
|
||||
Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
|
||||
with.
|
||||
|
||||
``passive``
|
||||
Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
|
||||
start with.
|
||||
|
||||
This option implies the ``no_hwp`` one described below.
|
||||
|
||||
``force``
|
||||
Register ``intel_pstate`` as the scaling driver instead of
|
||||
``acpi-cpufreq`` even if the latter is preferred on the given system.
|
||||
|
|
@ -655,13 +668,12 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
|
|||
driver is used instead of ``acpi-cpufreq``.
|
||||
|
||||
``no_hwp``
|
||||
Do not enable the `hardware-managed P-states (HWP) feature
|
||||
<Active Mode With HWP_>`_ even if it is supported by the processor.
|
||||
Do not enable the hardware-managed P-states (HWP) feature even if it is
|
||||
supported by the processor.
|
||||
|
||||
``hwp_only``
|
||||
Register ``intel_pstate`` as the scaling driver only if the
|
||||
`hardware-managed P-states (HWP) feature <Active Mode With HWP_>`_ is
|
||||
supported by the processor.
|
||||
hardware-managed P-states (HWP) feature is supported by the processor.
|
||||
|
||||
``support_acpi_ppc``
|
||||
Take ACPI ``_PPC`` performance limits into account.
|
||||
|
|
@ -708,7 +720,7 @@ core (for the policies with other scaling governors).
|
|||
|
||||
The ``ftrace`` interface can be used for low-level diagnostics of
|
||||
``intel_pstate``. For example, to check how often the function to set a
|
||||
P-state is called, the ``ftrace`` filter can be set to to
|
||||
P-state is called, the ``ftrace`` filter can be set to
|
||||
:c:func:`intel_pstate_set_pstate`::
|
||||
|
||||
# cd /sys/kernel/debug/tracing/
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue