---

yaml
---
r: 32542
b: refs/heads/master
c: d608ab9
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a23f4636c9ae7f1f15c448080f1552864b404136
+refs/heads/master: d608ab9917fbe9926704c07b27df72ac78133870

trunk/CREDITS

@@ -528,11 +528,11 @@ S: Oxford
 S: United Kingdom
 
 N: Luiz Fernando N. Capitulino
-E: lcapitulino@mandriva.com.br
-E: lcapitulino@gmail.com
-W: http://www.cpu.eti.br
-D: misc kernel hacking
-S: Mandriva
+E: lcapitulino@terra.com.br
+E: lcapitulino@prefeitura.sp.gov.br
+W: http://www.telecentros.sp.gov.br
+D: Little fixes and a lot of janitorial work
+S: E-GOV Telecentros SP
 S: Brazil
 
 N: Remy Card

trunk/Documentation/RCU/whatisRCU.txt

@@ -687,9 +687,8 @@ diff shows how closely related RCU and reader-writer locking can be.
 	+	spin_lock(&listmutex);
 		list_for_each_entry(p, head, lp) {
 			if (p->key == key) {
-	-			list_del(&p->list);
+				list_del(&p->list);
 	-			write_unlock(&listmutex);
-	+			list_del_rcu(&p->list);
 	+			spin_unlock(&listmutex);
 	+			synchronize_rcu();
 				kfree(p);
@@ -737,7 +736,7 @@ Or, for those who prefer a side-by-side listing:
  5   write_lock(&listmutex);            5   spin_lock(&listmutex);
  6   list_for_each_entry(p, head, lp) { 6   list_for_each_entry(p, head, lp) {
  7     if (p->key == key) {             7     if (p->key == key) {
- 8       list_del(&p->list);            8       list_del_rcu(&p->list);
+ 8       list_del(&p->list);            8       list_del(&p->list);
  9       write_unlock(&listmutex);      9       spin_unlock(&listmutex);
                                        10       synchronize_rcu();
 10       kfree(p);                     11       kfree(p);

trunk/Documentation/SubmitChecklist

@@ -1,63 +1,57 @@
 Linux Kernel patch sumbittal checklist
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Here are some basic things that developers should do if they want to see their
-kernel patch submissions accepted more quickly.
+Here are some basic things that developers should do if they
+want to see their kernel patch submittals accepted quicker.
 
-These are all above and beyond the documentation that is provided in
-Documentation/SubmittingPatches and elsewhere regarding submitting Linux
-kernel patches.
+These are all above and beyond the documentation that is provided
+in Documentation/SubmittingPatches and elsewhere about submitting
+Linux kernel patches.
 
 
 
-1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
-   =n.  No gcc warnings/errors, no linker warnings/errors.
+- Builds cleanly with applicable or modified CONFIG options =y, =m, and =n.
+  No gcc warnings/errors, no linker warnings/errors.
 
-2: Passes allnoconfig, allmodconfig
+- Passes allnoconfig, allmodconfig
 
-3: Builds on multiple CPU architectures by using local cross-compile tools
-   or something like PLM at OSDL.
+- Builds on multiple CPU arch-es by using local cross-compile tools
+  or something like PLM at OSDL.
 
-4: ppc64 is a good architecture for cross-compilation checking because it
-   tends to use `unsigned long' for 64-bit quantities.
+- ppc64 is a good architecture for cross-compilation checking because it
+  tends to use `unsigned long' for 64-bit quantities.
 
-5: Matches kernel coding style(!)
+- Matches kernel coding style(!)
 
-6: Any new or modified CONFIG options don't muck up the config menu.
+- Any new or modified CONFIG options don't muck up the config menu.
 
-7: All new Kconfig options have help text.
+- All new Kconfig options have help text.
 
-8: Has been carefully reviewed with respect to relevant Kconfig
-   combinations.  This is very hard to get right with testing -- brainpower
-   pays off here.
+- Has been carefully reviewed with respect to relevant Kconfig
+  combinations.  This is very hard to get right with testing --
+  brainpower pays off here.
 
-9: Check cleanly with sparse.
+- Check cleanly with sparse.
 
-10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
-    that they find.  Note: checkstack does not point out problems explicitly,
-    but any one function that uses more than 512 bytes on the stack is a
-    candidate for change.
+- Use 'make checkstack' and 'make namespacecheck' and fix any
+  problems that they find.  Note:  checkstack does not point out
+  problems explicitly, but any one function that uses more than
+  512 bytes on the stack is a candidate for change.
 
-11: Include kernel-doc to document global kernel APIs.  (Not required for
-    static functions, but OK there also.) Use 'make htmldocs' or 'make
-    mandocs' to check the kernel-doc and fix any issues.
+- Include kernel-doc to document global kernel APIs.  (Not required
+  for static functions, but OK there also.)  Use 'make htmldocs'
+  or 'make mandocs' to check the kernel-doc and fix any issues.
 
-12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
-    CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
-    CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
-    enabled.
+- Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
+  CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
+  CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
+  enabled.
 
-13: Has been build- and runtime tested with and without CONFIG_SMP and
-    CONFIG_PREEMPT.
+- Has been build- and runtime tested with and without CONFIG_SMP and
+  CONFIG_PREEMPT.
 
-14: If the patch affects IO/Disk, etc: has been tested with and without
-    CONFIG_LBD.
+- If the patch affects IO/Disk, etc: has been tested with and without
+  CONFIG_LBD.
 
-15: All codepaths have been exercised with all lockdep features enabled.
 
-16: All new /proc entries are documented under Documentation/
-
-17: All new kernel boot parameters are documented in
-    Documentation/kernel-parameters.txt.
-
-18: All new module parameters are documented with MODULE_PARM_DESC()
+2006-APR-27

trunk/Documentation/drivers/edac/edac.txt

@@ -35,14 +35,15 @@ the vendor should tie the parity status bits to 0 if they do not intend
 to generate parity.  Some vendors do not do this, and thus the parity bit
 can "float" giving false positives.
 
-[There are patches in the kernel queue which will allow for storage of
-quirks of PCI devices reporting false parity positives. The 2.6.18
-kernel should have those patches included. When that becomes available,
-then EDAC will be patched to utilize that information to "skip" such
-devices.]
+The PCI Parity EDAC device has the ability to "skip" known flaky
+cards during the parity scan. These are set by the parity "blacklist"
+interface in the sysfs for PCI Parity. (See the PCI section in the sysfs
+section below.) There is also a parity "whitelist" which is used as
+an explicit list of devices to scan, while the blacklist is a list
+of devices to skip.
 
-EDAC will have future error detectors that will be integrated with
-EDAC or added to it, in the following list:
+EDAC will have future error detectors that will be added or integrated
+into EDAC in the following list:
 
 	MCE	Machine Check Exception
 	MCA	Machine Check Architecture
@@ -92,24 +93,22 @@ EDAC lives in the /sys/devices/system/edac directory. Within this directory
 there currently reside 2 'edac' components:
 
 	mc	memory controller(s) system
-	pci	PCI control and status system
+	pci	PCI status system
 
 
 ============================================================================
 Memory Controller (mc) Model
 
 First a background on the memory controller's model abstracted in EDAC.
-Each 'mc' device controls a set of DIMM memory modules. These modules are
+Each mc device controls a set of DIMM memory modules. These modules are
 laid out in a Chip-Select Row (csrowX) and Channel table (chX). There can
-be multiple csrows and multiple channels.
+be multiple csrows and two channels.
 
 Memory controllers allow for several csrows, with 8 csrows being a typical value.
 Yet, the actual number of csrows depends on the electrical "loading"
 of a given motherboard, memory controller and DIMM characteristics.
 
 Dual channels allows for 128 bit data transfers to the CPU from memory.
-Some newer chipsets allow for more than 2 channels, like Fully Buffered DIMMs
-(FB-DIMMs). The following example will assume 2 channels:
 
 
 		Channel 0	Channel 1
@@ -235,15 +234,23 @@ Polling period control file:
 	The time period, in milliseconds, for polling for error information.
 	Too small a value wastes resources.  Too large a value might delay
 	necessary handling of errors and might loose valuable information for
-	locating the error.  1000 milliseconds (once each second) is the current
-	default. Systems which require all the bandwidth they can get, may
-	increase this.
+	locating the error.  1000 milliseconds (once each second) is about
+	right for most uses.
 
 	LOAD TIME: module/kernel parameter: poll_msec=[0|1]
 
 	RUN TIME: echo "1000" >/sys/devices/system/edac/mc/poll_msec
 
 
+Module Version read-only attribute file:
+
+	'mc_version'
+
+	The EDAC CORE module's version and compile date are shown here to
+	indicate what EDAC is running.
+
+
+
 ============================================================================
 'mcX' DIRECTORIES
 
@@ -277,6 +284,35 @@ Seconds since last counter reset control file:
 
 
 
+DIMM capability attribute file:
+
+	'edac_capability'
+
+	The EDAC (Error Detection and Correction) capabilities/modes of
+	the memory controller hardware.
+
+
+DIMM Current Capability attribute file:
+
+	'edac_current_capability'
+
+	The EDAC capabilities available with the hardware
+	configuration.  This may not be the same as "EDAC capability"
+	if the correct memory is not used.  If a memory controller is
+	capable of EDAC, but DIMMs without check bits are in use, then
+	Parity, SECDED, S4ECD4ED capabilities will not be available
+	even though the memory controller might be capable of those
+	modes with the proper memory loaded.
+
+
+Memory Type supported on this controller attribute file:
+
+	'supported_mem_type'
+
+	This attribute file displays the memory type, usually
+	buffered and unbuffered DIMMs.
+
+
 Memory Controller name attribute file:
 
 	'mc_name'
@@ -285,6 +321,16 @@ Memory Controller name attribute file:
 	that is being utilized.
 
 
+Memory Controller Module name attribute file:
+
+	'module_name'
+
+	This attribute file displays the memory controller module name,
+	version and date built.  The name of the memory controller
+	hardware - some drivers work with multiple controllers and
+	this field shows which hardware is present.
+
+
 Total memory managed by this memory controller attribute file:
 
 	'size_mb'
@@ -386,9 +432,6 @@ Memory Type attribute file:
 
 	This attribute file will display what type of memory is currently
 	on this csrow. Normally, either buffered or unbuffered memory.
-	Examples:
-		Registered-DDR
-		Unbuffered-DDR
 
 
 EDAC Mode of operation attribute file:
@@ -403,13 +446,8 @@ Device type attribute file:
 
 	'dev_type'
 
-	This attribute file will display what type of DRAM device is
-	being utilized on this DIMM.
-	Examples:
-		x1
-		x2
-		x4
-		x8
+	This attribute file will display what type of DIMM device is
+	being utilized. Example:  x4
 
 
 Channel 0 CE Count attribute file:
@@ -484,10 +522,10 @@ SYSTEM LOGGING
 If logging for UEs and CEs are enabled then system logs will have
 error notices indicating errors that have been detected:
 
-EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0,
+MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0,
 channel 1 "DIMM_B1": amd76x_edac
 
-EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0,
+MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0,
 channel 1 "DIMM_B1": amd76x_edac
 
 
@@ -572,4 +610,64 @@ Parity Count:
 
 
 
+PCI Device Whitelist:
+
+	'pci_parity_whitelist'
+
+	This control file allows for an explicit list of PCI devices to be
+	scanned for parity errors. Only devices found on this list will
+	be examined.  The list is a line of hexadecimal VENDOR and DEVICE
+	ID tuples:
+
+	1022:7450,1434:16a6
+
+	One or more can be inserted, separated by a comma.
+
+	To write the above list doing the following as one command line:
+
+	echo "1022:7450,1434:16a6"
+		> /sys/devices/system/edac/pci/pci_parity_whitelist
+
+
+
+	To display what the whitelist is, simply 'cat' the same file.
+
+
+PCI Device Blacklist:
+
+	'pci_parity_blacklist'
+
+	This control file allows for a list of PCI devices to be
+	skipped for scanning.
+	The list is a line of hexadecimal VENDOR and DEVICE ID tuples:
+
+	1022:7450,1434:16a6
+
+	One or more can be inserted, separated by a comma.
+
+	To write the above list doing the following as one command line:
+
+	echo "1022:7450,1434:16a6"
+		> /sys/devices/system/edac/pci/pci_parity_blacklist
+
+
+	To display what the whitelist currently contains,
+	simply 'cat' the same file.
+
 =======================================================================
+
+PCI Vendor and Devices IDs can be obtained with the lspci command. Using
+the -n option lspci will display the vendor and device IDs. The system
+administrator will have to determine which devices should be scanned or
+skipped.
+
+
+
+The two lists (white and black) are prioritized. blacklist is the lower
+priority and will NOT be utilized when a whitelist has been set.
+Turn OFF a whitelist by an empty echo command:
+
+	echo > /sys/devices/system/edac/pci/pci_parity_whitelist
+
+and any previous blacklist will be utilized.
+