summaryrefslogtreecommitdiffstats
path: root/drivers/edac
Commit message (Collapse)AuthorAgeFilesLines
* edac: Do alignment logic properly in edac_align_ptr()Chris Metcalf2012-06-111-1/+1
| | | | | | | | | | | | | The logic was checking the sizeof the structure being allocated to determine whether an alignment fixup was required. This isn't right; what we actually care about is the alignment of the actual pointer that's about to be returned. This became an issue recently because struct edac_mc_layer has a size that is not zero modulo eight, so we were taking the correctly-aligned pointer and forcing it to be misaligned. On Tile this caused an alignment exception. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* mpc85xx_edac: fix error: too few arguments to function 'edac_mc_alloc'Kim Phillips2012-06-111-1/+2
| | | | | | | | | | | | | | commit ca0907b "edac: Remove the legacy EDAC ABI" broke mpc85xx_edac in the following manner: mpc85xx_edac.c:983:35: error: too few arguments to function 'edac_mc_alloc' this patch puts back the missing 'layers' argument. [mchehab@redhat.com: As Ben sent a similar fix, I added his SOB on this patch] Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Ben Collins <bcollins@ubuntu.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* edac: fix the error about memory type detection on SandyBridgeChen Gong2012-06-111-1/+1
| | | | | | | | On SandyBridge, DDRIOA(Dev: 17 Func: 0 Offset: 328) is used to detect whether DIMM is RDIMM/LRDIMM, not TA(Dev: 15 Func: 0). Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* edac: avoid mce decoding crash after edac driver unloadedChen Gong2012-06-112-15/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some edac drivers register themselves as mce decoders via notifier_chain. But in current notifier_chain implementation logic, it doesn't accept same notifier registered twice. If so, it will be wrong when adding/removing the element from the list. For example, on one SandyBridge platform, remove module sb_edac and then trigger one error, it will hit oops because it has no mce decoder registered but related notifier_chain still points to an invalid callback function. Here is an example: Call Trace: [<ffffffff8150ef6a>] atomic_notifier_call_chain+0x1a/0x20 [<ffffffff8102b936>] mce_log+0x46/0x180 [<ffffffff8102eaea>] apei_mce_report_mem_error+0x4a/0x60 [<ffffffff812e19d2>] ghes_do_proc+0x192/0x210 [<ffffffff812e2066>] ghes_proc+0x46/0x70 [<ffffffff812e20d8>] ghes_notify_sci+0x48/0x80 [<ffffffff8150ef05>] notifier_call_chain+0x55/0x80 [<ffffffff81076f1a>] __blocking_notifier_call_chain+0x5a/0x80 [<ffffffff812aea11>] ? acpi_os_wait_events_complete+0x23/0x23 [<ffffffff81076f56>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff812ddc4d>] acpi_hed_notify+0x19/0x1b [<ffffffff812b16bd>] acpi_device_notify+0x19/0x1b [<ffffffff812beb38>] acpi_ev_notify_dispatch+0x67/0x7f [<ffffffff812aea3a>] acpi_os_execute_deferred+0x29/0x36 [<ffffffff81069dc2>] process_one_work+0x132/0x450 [<ffffffff8106bbcb>] worker_thread+0x17b/0x3c0 [<ffffffff8106ba50>] ? manage_workers+0x120/0x120 [<ffffffff81070aee>] kthread+0x9e/0xb0 [<ffffffff81514724>] kernel_thread_helper+0x4/0x10 [<ffffffff81070a50>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff81514720>] ? gs_change+0x13/0x13 Code: f3 49 89 d4 45 85 ed 4d 89 c6 48 8b 0f 74 48 48 85 c9 75 17 eb 41 0f 1f 80 00 00 00 00 41 83 ed 01 4c 89 f9 74 22 4d 85 ff 74 1d <4c> 8b 79 08 4c 89 e2 48 89 de 48 89 cf ff 11 4d 85 f6 74 04 41 RIP [<ffffffff8150eef6>] notifier_call_chain+0x46/0x80 RSP <ffff88042868fb20> CR2: ffffffffa01af838 ---[ end trace 0100930068e73e6f ]--- BUG: unable to handle kernel paging request at fffffffffffffff8 IP: [<ffffffff810705b0>] kthread_data+0x10/0x20 PGD 1a0d067 PUD 1a0e067 PMD 0 Oops: 0000 [#2] SMP Only i7core_edac and sb_edac have such issues because they have more than one memory controller which means they have to register mce decoder many times. Cc: <stable@vger.kernel.org> # 3.2 and upper Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* Merge branch 'x86/trampoline' into x86/urgentH. Peter Anvin2012-05-3031-1446/+1821
|\ | | | | | | | | | | | | x86/trampoline contains an urgent commit which is necessarily on a newer baseline. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edacLinus Torvalds2012-05-2931-1446/+1821
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull EDAC internal API changes from Mauro Carvalho Chehab: "This changeset is the first part of a series of patches that fixes the EDAC sybsystem. On this set, it changes the Kernel EDAC API in order to properly represent the Intel i3/i5/i7, Xeon 3xxx/5xxx/7xxx, and Intel E5-xxxx memory controllers. The EDAC core used to assume that: - the DRAM chip select pin is directly accessed by the memory controller - when multiple channels are used, they're all filled with the same type of memory. None of the above premises is true on Intel memory controllers since 2002, when RAMBUS and FB-DIMMs were introduced, and Advanced Memory Buffer or by some similar technologies hides the direct access to the DRAM pins. So, the existing drivers for those chipsets had to lie to the EDAC core, in general telling that just one channel is filled. That produces some hard to understand error messages like: EDAC MC0: CE row 3, channel 0, label "DIMM1": 1 Unknown error(s): memory read error on FATAL area : cpu=0 Err=0008:00c2 (ch=2), addr = 0xad1f73480 => socket=0, Channel=0(mask=2), rank=1 The location information there (row3 channel 0) is completely bogus: it has no physical meaning, and are just some random values that the driver uses to talk with the EDAC core. The error actually happened at CPU socket 0, channel 0, slot 1, but this is not reported anywhere, as the EDAC core doesn't know anything about the memory layout. So, only advanced users that know how the EDAC driver works and that tests their systems to see how DIMMs are mapped can actually benefit for such error logs. This patch series fixes the error report logic, in order to allow the EDAC to expose the memory architecture used by them to the EDAC core. So, as the EDAC core now understands how the memory is organized, it can provide an useful report: EDAC MC0: CE memory read error on DIMM1 (channel:0 slot:1 page:0x364b1b offset:0x600 grain:32 syndrome:0x0 - count:1 area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:4) The location of the DIMM where the error happened is reported by "MC0" (cpu socket #0), at "channel:0 slot:1" location, and matches the physical location of the DIMM. There are two remaining issues not covered by this patch series: - The EDAC sysfs API will still report bogus values. So, userspace tools like edac-utils will still use the bogus data; - Add a new tracepoint-based way to get the binary information about the errors. Those are on a second series of patches (also at -next), but will probably miss the train for 3.5, due to the slow review process." Fix up trivial conflict (due to spelling correction of removed code) in drivers/edac/edac_device.c * git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac: (42 commits) i7core: fix ranks information at the per-channel struct i5000: Fix the fatal error handling i5100_edac: Fix a warning when compiled with 32 bits i82975x_edac: Test nr_pages earlier to save a few CPU cycles e752x_edac: provide more info about how DIMMS/ranks are mapped i5000_edac: Fix the logic that retrieves memory information i5400_edac: improve debug messages to better represent the filled memory edac: Cleanup the logs for i7core and sb edac drivers edac: Initialize the dimm label with the known information edac: Remove the legacy EDAC ABI x38_edac: convert driver to use the new edac ABI tile_edac: convert driver to use the new edac ABI sb_edac: convert driver to use the new edac ABI r82600_edac: convert driver to use the new edac ABI ppc4xx_edac: convert driver to use the new edac ABI pasemi_edac: convert driver to use the new edac ABI mv64x60_edac: convert driver to use the new edac ABI mpc85xx_edac: convert driver to use the new edac ABI i82975x_edac: convert driver to use the new edac ABI i82875p_edac: convert driver to use the new edac ABI ...
| | * i7core: fix ranks information at the per-channel structMauro Carvalho Chehab2012-05-281-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a flag at the per-channel struct that indicates if there are any 4R dimm on it. The way the presence of this flag were reported is not ok, as it might give the false idea that the channel were filled with 2R memories: [ 580.588701] EDAC DEBUG: get_dimm_config: Ch1 phy rd1, wr1 (0x063f7431): 2 ranks, UDIMMs [ 580.588704] EDAC DEBUG: get_dimm_config: dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 (in this case, just one 1R memory is filled on channel 1) So, use a better way to represent the per-channel ranks information. After the patch, it will show: [ 2002.233978] EDAC DEBUG: get_dimm_config: Ch0 phy rd0, wr0 (0x063f7431): UDIMMs [ 2002.233982] EDAC DEBUG: get_dimm_config: dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 [ 2002.233988] EDAC DEBUG: get_dimm_config: dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400 (in this case, there isn't any 4R memories) Reported-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5000: Fix the fatal error handlingMauro Carvalho Chehab2012-05-281-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The fatal error channel bits point to a single channel, and not to a range of channels. Fix the code to properly report it, instead of printing messages like: kernel: EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4) Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5100_edac: Fix a warning when compiled with 32 bitsMauro Carvalho Chehab2012-05-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/edac/i5100_edac.c: In function ‘i5100_init_csrows’: drivers/edac/i5100_edac.c:862:3: warning: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 5 has type ‘long unsigned int’ [-Wformat] Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i82975x_edac: Test nr_pages earlier to save a few CPU cyclesMauro Carvalho Chehab2012-05-281-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid test nr_pages twice, and initializing some data that won't be used. Cleanup patch only. Reported-by: Aristeu Rozanski Filho <arozansk@redhat.com> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * e752x_edac: provide more info about how DIMMS/ranks are mappedMauro Carvalho Chehab2012-05-281-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | No funtional changes here. Only the comments got updated. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Cc: Mark Gross <mark.gross@intel.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5000_edac: Fix the logic that retrieves memory informationMauro Carvalho Chehab2012-05-281-71/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic there is broken: it basically creates two csrows for each DIMM and assumes that all DIMM's are dual rank. Only one of the csrows will contain the entire DIMM size. If single rank memories are found, they'll be marked with 0 bytes. The check if the AMB is present were also wrong. Yet, as the error reports don't use the memory size in order to credit an error to the right DIMM, that part of the driver seems to work. That's why probably nobody detected the issue yet. After this patch, the memory layout is now properly reported, when debug mode is enabled, and the number of ranks per dimm is now shown: calculate_dimm_size: ---------------------------------------------------------- calculate_dimm_size: slot 3 0 MB | 0 MB | 0 MB | 0 MB | calculate_dimm_size: slot 2 0 MB | 0 MB | 0 MB | 0 MB | calculate_dimm_size: ---------------------------------------------------------- calculate_dimm_size: slot 1 0 MB | 0 MB | 0 MB | 0 MB | calculate_dimm_size: slot 0 512 MB 1R| 512 MB 1R| 512 MB 1R| 512 MB 1R| calculate_dimm_size: ---------------------------------------------------------- calculate_dimm_size: channel 0 | channel 1 | channel 2 | channel 3 | calculate_dimm_size: branch 0 | branch 1 | (1R above means that all memories on my test machine are single-ranked) Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5400_edac: improve debug messages to better represent the filled memoryMauro Carvalho Chehab2012-05-281-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improves the debug output message, in order to better represent the memory controller hierarchy, when outputing the debug messages. No functional changes when debug is disabled. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Cleanup the logs for i7core and sb edac driversMauro Carvalho Chehab2012-05-282-31/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove some information that it is duplicated at the MCE log, and don't have much usage for the error. Those data will be added again, when creating a trace function that outputs both memory errors and MCE fields. Cc: Aristeu Rozanski <arozansk@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Initialize the dimm label with the known informationMauro Carvalho Chehab2012-05-282-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: <OUT OF SPEC> 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 <arozansk@redhat.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Remove the legacy EDAC ABIMauro Carvalho Chehab2012-05-2827-151/+32
| | | | | | | | | | | | | | | | | | | | | | | | Now that all drivers got converted to use the new ABI, we can drop the old one. Acked-by: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * x38_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * tile_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Acked-by: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * sb_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-103/+56
| | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * r82600_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Tim Small <tim@buttersideup.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * ppc4xx_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Josh Boyer <jwboyer@gmail.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * pasemi_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Olof Johansson <olof@lixom.net> Cc: Egor Martovetsky <egor@pasemi.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * mv64x60_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * mpc85xx_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Shaohui Xie <Shaohui.Xie@freescale.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i82975x_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i82875p_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-8/+21
| | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i82860_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-13/+29
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i82443bxgx_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Tim Small <tim@buttersideup.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i7core_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-152/+50
| | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i7300_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-48/+30
| | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5400_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-98/+119
| | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5100_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-50/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i5000_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-21/+39
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i3200_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Hitoshi Mitake <h.mitake@gmail.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * i3000_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Jason Uhlenkott <juhlenko@akamai.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * e7xxx_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-7/+30
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * e752x_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-15/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Mark Gross <mark.gross@intel.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * cpc925_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * cell_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Jiri Kosina <jkosina@suse.cz> Cc: Joe Perches <joe@perches.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * amd76x_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * amd64_edac: convert driver to use the new edac ABIMauro Carvalho Chehab2012-05-281-45/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy edac ABI is going to be removed. Port the driver to use and benefit from the new API functionality. Cc: Doug Thompson <norsk5@yahoo.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Change internal representation to work with layersMauro Carvalho Chehab2012-05-282-274/+527
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <arozansk@redhat.com> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Mark Gross <mark.gross@intel.com> Cc: Jason Uhlenkott <juhlenko@akamai.com> Cc: Tim Small <tim@buttersideup.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Cc: Olof Johansson <olof@lixom.net> Cc: Egor Martovetsky <egor@pasemi.com> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Joe Perches <joe@perches.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hitoshi Mitake <h.mitake@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Shaohui Xie <Shaohui.Xie@freescale.com> Cc: Josh Boyer <jwboyer@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: rewrite edac_align_ptr()Mauro Carvalho Chehab2012-05-284-31/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The edac_align_ptr() function is used to prepare data for a single memory allocation kzalloc() call. It counts how many bytes are needed by some data structure. Using it as-is is not that trivial, as the quantity of memory elements reserved is not there, but, instead, it is on a next call. In order to avoid mistakes when using it, move the number of allocated elements into it, making easier to use it. Reviewed-by: Borislav Petkov <bp@amd64.org> Cc: Aristeu Rozanski <arozansk@redhat.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: move nr_pages to dimm structMauro Carvalho Chehab2012-05-2827-113/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The number of pages is a dimm property. Move it to the dimm struct. After this change, it is possible to add sysfs nodes for the DIMM's that will properly represent the DIMM stick properties, including its size. A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when the memory controller represents the memory via chip select rows. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Acked-by: Borislav Petkov <borislav.petkov@amd.com> Acked-by: Chris Metcalf <cmetcalf@tilera.com> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Mark Gross <mark.gross@intel.com> Cc: Jason Uhlenkott <juhlenko@akamai.com> Cc: Tim Small <tim@buttersideup.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Cc: Olof Johansson <olof@lixom.net> Cc: Egor Martovetsky <egor@pasemi.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Joe Perches <joe@perches.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hitoshi Mitake <h.mitake@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Shaohui Xie <Shaohui.Xie@freescale.com> Cc: Josh Boyer <jwboyer@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Don't initialize csrow's first_page & friends when not neededMauro Carvalho Chehab2012-05-2812-78/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all edac drivers initialize csrow_info->first_page, csrow_info->last_page and csrow_info->page_mask. Those vars are used inside the EDAC core, in order to calculate the csrow affected by an error, by using the routine edac_mc_find_csrow_by_page(). However, very few drivers actually use it: e752x_edac.c e7xxx_edac.c i3000_edac.c i82443bxgx_edac.c i82860_edac.c i82875p_edac.c i82975x_edac.c r82600_edac.c There also a few other drivers that have their own calculus formula internally using those vars. All the others are just wasting time by initializing those data. While initializing data without using them won't cause any troubles, as those information is stored at the wrong place (at csrows structure), it is better to remove what is unused, in order to simplify the next patch. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Acked-by: Borislav Petkov <borislav.petkov@amd.com> Acked-by: Chris Metcalf <cmetcalf@tilera.com> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Hitoshi Mitake <h.mitake@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Josh Boyer <jwboyer@gmail.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: move dimm properties to struct dimm_infoMauro Carvalho Chehab2012-05-2827-249/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On systems based on chip select rows, all channels need to use memories with the same properties, otherwise the memories on channels A and B won't be recognized. However, such assumption is not true for all types of memory controllers. Controllers for FB-DIMM's don't have such requirements. Also, modern Intel controllers seem to be capable of handling such differences. So, we need to get rid of storing the DIMM information into a per-csrow data, storing it, instead at the right place. The first step is to move grain, mtype, dtype and edac_mode to the per-dimm struct. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Reviewed-by: Borislav Petkov <borislav.petkov@amd.com> Acked-by: Chris Metcalf <cmetcalf@tilera.com> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Mark Gross <mark.gross@intel.com> Cc: Jason Uhlenkott <juhlenko@akamai.com> Cc: Tim Small <tim@buttersideup.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Cc: Olof Johansson <olof@lixom.net> Cc: Egor Martovetsky <egor@pasemi.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Joe Perches <joe@perches.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hitoshi Mitake <h.mitake@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: James Bottomley <James.Bottomley@parallels.com> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Cc: Shaohui Xie <Shaohui.Xie@freescale.com> Cc: Josh Boyer <jwboyer@gmail.com> Cc: Mike Williams <mike@mikebwilliams.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| | * edac: Create a dimm struct and move the labels into itMauro Carvalho Chehab2012-05-286-27/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way a DIMM is currently represented implies that they're linked into a per-csrow struct. However, some drivers don't see csrows, as they're ridden behind some chip like the AMB's on FBDIMM's, for example. This forced drivers to fake^Wvirtualize a csrow struct, and to create a mess under csrow/channel original's concept. Move the DIMM labels into a per-DIMM struct, and add there the real location of the socket, in terms of csrow/channel. Latter patches will modify the location to properly represent the memory architecture. All other drivers will use a per-csrow type of location. Some of those drivers will require a latter conversion, as they also fake the csrows internally. TODO: While this patch doesn't change the existing behavior, on csrows-based memory controllers, a csrow/channel pair points to a memory rank. There's a known bug at the EDAC core that allows having different labels for the same DIMM, if it has more than one rank. A latter patch is need to merge the several ranks for a DIMM into the same dimm_info struct, in order to avoid having different labels for the same DIMM. The edac_mc_alloc() will now contain a per-dimm initialization loop that will be changed by latter patches in order to match other types of memory architectures. Reviewed-by: Aristeu Rozanski <arozansk@redhat.com> Reviewed-by: Borislav Petkov <borislav.petkov@amd.com> Cc: Doug Thompson <norsk5@yahoo.com> Cc: Ranganathan Desikan <ravi@jetztechnologies.com> Cc: "Arvind R." <arvino55@gmail.com> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* | | Merge branch 'x86/mce' into x86/urgentIngo Molnar2012-05-301-2/+0
|\ \ \ | |/ / |/| | | | | | | | | | | Merge in these fixlets. Signed-off-by: Ingo Molnar <mingo@kernel.org>
| * | x86/bitops: Move BIT_64() for a wider useBorislav Petkov2012-05-231-2/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Needed for shifting 64-bit values on 32-bit, like MSR values, for example. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frank Arnold <frank.arnold@amd.com> Link: http://lkml.kernel.org/r/1337684026-19740-1-git-send-email-bp@amd64.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | edac, mips: don't change code that has been removed in edac/mips treeJiri Kosina2012-05-222-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is a partial revert of 15ed103a9800 ("edac: Fix spelling errors") 6997991ab0db ("mips: Fix printk typos in arc/mips") which change code that doesn't exist any more in edac/mips trees. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-27 01:17:17 +0000