linux-toradex.git/include/linux/edac.h, branch v3.7

edac: allow specifying the error count with fake_inject

2012-06-27T12:01:30+00:00

In order to test if the error counters are properly incremented,
add a way to specify how many errors were generated by a trace.

Signed-off-by: Mauro Carvalho Chehab

edac: change the mem allocation scheme to make Documentation/kobject.txt happy

2012-06-11T16:23:45+00:00

Kernel kobjects have rigid rules: each container object should be
dynamically allocated, and can't be allocated into a single kmalloc.

EDAC never obeyed this rule: it has a single malloc function that
allocates all needed data into a single kzalloc.

As this is not accepted anymore, change the allocation schema of the
EDAC *_info structs to enforce this Kernel standard.

Acked-by: Chris Metcalf 
Cc: Aristeu Rozanski 
Cc: Doug Thompson 
Cc: Greg K H 
Cc: Borislav Petkov 
Cc: Mark Gross 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Olof Johansson 
Cc: Egor Martovetsky 
Cc: Michal Marek 
Cc: Jiri Kosina 
Cc: Dmitry Eremin-Solenikov 
Cc: Benjamin Herrenschmidt 
Cc: Hitoshi Mitake 
Cc: Andrew Morton 
Cc: Shaohui Xie 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab

edac: Add debufs nodes to allow doing fake error inject

2012-06-11T16:23:43+00:00

Sometimes, it is useful to have a mechanism that generates fake
errors, in order to test the EDAC core code, and the userspace
tools.

Provide such mechanism by adding a few debugfs nodes.

Reviewed-by: Aristeu Rozanski 
Cc: Doug Thompson 
Signed-off-by: Mauro Carvalho Chehab

edac: Get rid of the old kobj's from the edac mc code

2012-06-11T16:23:41+00:00

Now that al users for the old kobj raw access are gone,
we can get rid of the legacy kobj-based structures and
data.

Reviewed-by: Aristeu Rozanski 
Cc: Doug Thompson 
Cc: Michal Marek 
Signed-off-by: Mauro Carvalho Chehab

edac: rewrite the sysfs code to use struct device

2012-06-11T16:23:30+00:00

The EDAC subsystem uses the old struct sysdev approach,
creating all nodes using the raw sysfs API. This is bad,
as the API is deprecated.

As we'll be changing the EDAC API, let's first port the existing
code to struct device.

There's one drawback on this patch: driver-specific sysfs
nodes, used by mpc85xx_edac, amd64_edac and i7core_edac
 won't be created anymore. While it would be possible to
also port the device-specific code, that would mix kobj with
struct device, with is not recommended. Also, it is easier and nicer
to move the code to the drivers, instead, as the core can get rid
of some complex logic that just emulates what the device_add()
and device_create_file() already does.

The next patches will convert the driver-specific code to use
the device-specific calls. Then, the remaining bits of the old
sysfs API will be removed.

NOTE: a per-MC bus is required, otherwise devices with more than
one memory controller will hit a bug like the one below:

[  819.094946] EDAC DEBUG: find_mci_by_dev: find_mci_by_dev()
[  819.094948] EDAC DEBUG: edac_create_sysfs_mci_device: edac_create_sysfs_mci_device() idx=1
[  819.094952] EDAC DEBUG: edac_create_sysfs_mci_device: edac_create_sysfs_mci_device(): creating device mc1
[  819.094967] EDAC DEBUG: edac_create_sysfs_mci_device: edac_create_sysfs_mci_device creating dimm0, located at channel 0 slot 0
[  819.094984] ------------[ cut here ]------------
[  819.100142] WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xc1/0xf0()
[  819.107282] Hardware name: S2600CP
[  819.111078] sysfs: cannot create duplicate filename '/bus/edac/devices/dimm0'
[  819.119062] Modules linked in: sb_edac(+) edac_core ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc sunrpc binfmt_misc dm_mirror dm_region_hash dm_log vhost_net macvtap macvlan tun kvm microcode pcspkr iTCO_wdt iTCO_vendor_support igb i2c_i801 i2c_core sg ioatdma dca sr_mod cdrom sd_mod crc_t10dif ahci libahci isci libsas libata scsi_transport_sas scsi_mod wmi dm_mod [last unloaded: scsi_wait_scan]
[  819.175748] Pid: 10902, comm: modprobe Not tainted 3.3.0-0.11.el7.v12.2.x86_64 #1
[  819.184113] Call Trace:
[  819.186868]  [] warn_slowpath_common+0x7f/0xc0
[  819.193573]  [] warn_slowpath_fmt+0x46/0x50
[  819.200000]  [] sysfs_add_one+0xc1/0xf0
[  819.206025]  [] sysfs_do_create_link+0x135/0x220
[  819.212944]  [] ? sysfs_create_group+0x13/0x20
[  819.219656]  [] sysfs_create_link+0x13/0x20
[  819.226109]  [] bus_add_device+0xe6/0x1b0
[  819.232350]  [] device_add+0x2db/0x460
[  819.238300]  [] edac_create_dimm_object+0x84/0xf0 [edac_core]
[  819.246460]  [] edac_create_sysfs_mci_device+0xe8/0x290 [edac_core]
[  819.255215]  [] edac_mc_add_mc+0x5a/0x2c0 [edac_core]
[  819.262611]  [] sbridge_register_mci+0x1bc/0x279 [sb_edac]
[  819.270493]  [] sbridge_probe+0xef/0x175 [sb_edac]
[  819.277630]  [] ? pm_runtime_enable+0x58/0x90
[  819.284268]  [] local_pci_probe+0x5c/0xd0
[  819.290508]  [] __pci_device_probe+0xf1/0x100
[  819.297117]  [] pci_device_probe+0x3a/0x60
[  819.303457]  [] really_probe+0x73/0x270
[  819.309496]  [] driver_probe_device+0x4e/0xb0
[  819.316104]  [] __driver_attach+0xab/0xb0
[  819.322337]  [] ? driver_probe_device+0xb0/0xb0
[  819.329151]  [] bus_for_each_dev+0x56/0x90
[  819.335489]  [] driver_attach+0x1e/0x20
[  819.341534]  [] bus_add_driver+0x1b0/0x2a0
[  819.347884]  [] ? 0xffffffffa0346fff
[  819.353641]  [] driver_register+0x76/0x140
[  819.359980]  [] ? printk+0x51/0x53
[  819.365524]  [] ? 0xffffffffa0346fff
[  819.371291]  [] __pci_register_driver+0x56/0xd0
[  819.378096]  [] sbridge_init+0x54/0x1000 [sb_edac]
[  819.385231]  [] do_one_initcall+0x3f/0x170
[  819.391577]  [] sys_init_module+0xbe/0x230
[  819.397926]  [] system_call_fastpath+0x16/0x1b
[  819.404633] ---[ end trace 1654fdd39556689f ]---

This happens because the bus is not being properly initialized.
Instead of putting the memory sub-devices inside the memory controller,
it is putting everything under the same directory:

$ tree /sys/bus/edac/
/sys/bus/edac/
├── devices
│   ├── all_channel_counts -> ../../../devices/system/edac/mc/mc0/all_channel_counts
│   ├── csrow0 -> ../../../devices/system/edac/mc/mc0/csrow0
│   ├── csrow1 -> ../../../devices/system/edac/mc/mc0/csrow1
│   ├── csrow2 -> ../../../devices/system/edac/mc/mc0/csrow2
│   ├── dimm0 -> ../../../devices/system/edac/mc/mc0/dimm0
│   ├── dimm1 -> ../../../devices/system/edac/mc/mc0/dimm1
│   ├── dimm3 -> ../../../devices/system/edac/mc/mc0/dimm3
│   ├── dimm6 -> ../../../devices/system/edac/mc/mc0/dimm6
│   ├── inject_addrmatch -> ../../../devices/system/edac/mc/mc0/inject_addrmatch
│   ├── mc -> ../../../devices/system/edac/mc
│   └── mc0 -> ../../../devices/system/edac/mc/mc0
├── drivers
├── drivers_autoprobe
├── drivers_probe
└── uevent

On a multi-memory controller system, the names "csrow%d" and "dimm%d"
should be under "mc%d", and not at the main hierarchy level.

So, we need to create a per-MC bus, in order to have its own namespace.

Reviewed-by: Aristeu Rozanski 
Cc: Doug Thompson 
Cc: Greg K H 
Signed-off-by: Mauro Carvalho Chehab

edac: use Documentation-nano format for some data structs

2012-06-11T14:56:07+00:00

No functional changes. Just comment improvements.

Reviewed-by: Aristeu Rozanski 
Cc: Doug Thompson 
Signed-off-by: Mauro Carvalho Chehab

edac: Rename the parent dev to pdev

2012-06-11T14:56:06+00:00

As EDAC doesn't use struct device itself, it created a parent dev
pointer called as "pdev".  Now that we'll be converting it to use
struct device, instead of struct devsys, this needs to be fixed.

No functional changes.

Reviewed-by: Aristeu Rozanski 
Acked-by: Chris Metcalf 
Cc: Doug Thompson 
Cc: Borislav Petkov 
Cc: Mark Gross 
Cc: Jason Uhlenkott 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Olof Johansson 
Cc: Egor Martovetsky 
Cc: Michal Marek 
Cc: Jiri Kosina 
Cc: Joe Perches 
Cc: Dmitry Eremin-Solenikov 
Cc: Benjamin Herrenschmidt 
Cc: Hitoshi Mitake 
Cc: Andrew Morton 
Cc: "Niklas Söderlund" 
Cc: Shaohui Xie 
Cc: Josh Boyer 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab

edac: Initialize the dimm label with the known information

2012-05-28T22:13:50+00:00

While userspace doesn't fill the dimm labels, add there the dimm location,
as described by the used memory model. This could eventually match what
is described at the dmidecode, making easier for people to identify the
memory.

For example, on an Intel motherboard where the DMI table is reliable,
the first memory stick is described as:

Memory Device
	Array Handle: 0x0029
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: 1
	Locator: A1_DIMM0
	Bank Locator: A1_Node0_Channel0_Dimm0
	Type: 
	Type Detail: Synchronous
	Speed: 800 MHz
	Manufacturer: A1_Manufacturer0
	Serial Number: A1_SerNum0
	Asset Tag: A1_AssetTagNum0
	Part Number: A1_PartNum0

The memory named as "A1_DIMM0" is physically located at the first
memory controller (node 0), at channel 0, dimm slot 0.

After this patch, the memory label will be filled with:
	/sys/devices/system/edac/mc/csrow0/ch0_dimm_label:mc#0channel#0slot#0

And (after the new EDAC API patches) as:
	/sys/devices/system/edac/mc/mc0/dimm0/dimm_label:mc#0channel#0slot#0

So, even if the memory label is not initialized on userspace, an useful
information with the error location is filled there, expecially since
several systems/motherboards are provided with enough info to map from
channel/slot (or branch/channel/slot) into the DIMM label. So, letting the
EDAC core fill it by default is a good thing.

It should noticed that, as the label filling happens at the
edac_mc_alloc(), drivers can override it to better describe the memories
(and some actually do it).

Cc: Aristeu Rozanski 
Cc: Doug Thompson 
Signed-off-by: Mauro Carvalho Chehab

edac: Change internal representation to work with layers

2012-05-28T22:10:59+00:00

Change the EDAC internal representation to work with non-csrow
based memory controllers.

There are lots of those memory controllers nowadays, and more
are coming. So, the EDAC internal representation needs to be
changed, in order to work with those memory controllers, while
preserving backward compatibility with the old ones.

The edac core was written with the idea that memory controllers
are able to directly access csrows.

This is not true for FB-DIMM and RAMBUS memory controllers.

Also, some recent advanced memory controllers don't present a per-csrows
view. Instead, they view memories as DIMMs, instead of ranks.

So, change the allocation and error report routines to allow
them to work with all types of architectures.

This will allow the removal of several hacks with FB-DIMM and RAMBUS
memory controllers.

Also, several tests were done on different platforms using different
x86 drivers.

TODO: a multi-rank DIMMs are currently represented by multiple DIMM
entries in struct dimm_info. That means that changing a label for one
rank won't change the same label for the other ranks at the same DIMM.
This bug is present since the beginning of the EDAC, so it is not a big
deal. However, on several drivers, it is possible to fix this issue, but
it should be a per-driver fix, as the csrow => DIMM arrangement may not
be equal for all. So, don't try to fix it here yet.

I tried to make this patch as short as possible, preceding it with
several other patches that simplified the logic here. Yet, as the
internal API changes, all drivers need changes. The changes are
generally bigger in the drivers for FB-DIMMs.

Cc: Aristeu Rozanski 
Cc: Doug Thompson 
Cc: Borislav Petkov 
Cc: Mark Gross 
Cc: Jason Uhlenkott 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Olof Johansson 
Cc: Egor Martovetsky 
Cc: Chris Metcalf 
Cc: Michal Marek 
Cc: Jiri Kosina 
Cc: Joe Perches 
Cc: Dmitry Eremin-Solenikov 
Cc: Benjamin Herrenschmidt 
Cc: Hitoshi Mitake 
Cc: Andrew Morton 
Cc: "Niklas Söderlund" 
Cc: Shaohui Xie 
Cc: Josh Boyer 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab

edac.h: Add generic layers for describing a memory location

2012-05-28T22:10:59+00:00

The edac core were written with the idea that memory controllers
are able to directly access csrows, and that the channels are
used inside a csrows select.

This is not true for FB-DIMM and RAMBUS memory controllers.

Also, some recent advanced memory controllers don't present a per-csrows
view. Instead, they view memories as DIMMs, instead of ranks, accessed
via csrow/channel.

So, changes are needed in order to allow the EDAC core to
work with all types of architectures.

In preparation for handling non-csrows based memory controllers,
add some memory structs and a macro:

enum hw_event_mc_err_type: describes the type of error
			   (corrected, uncorrected, fatal)

To be used by the new edac_mc_handle_error function;

enum edac_mc_layer: describes the type of a given memory
architecture layer (branch, channel, slot, csrow).

struct edac_mc_layer: describes the properties of a memory
		      layer (type, size, and if the layer
		      will be used on a virtual csrow.

EDAC_DIMM_PTR() - as the number of layers can vary from 1 to 3,
this macro converts from an address with up to 3 layers into
a linear address.

Reviewed-by: Borislav Petkov 
Cc: Doug Thompson 
Signed-off-by: Mauro Carvalho Chehab