- May 29, 2012
-
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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 <bp@amd64.org> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
Mauro Carvalho Chehab authored
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>
-
- May 21, 2012
-
-
Linus Torvalds authored
-
- May 20, 2012
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6Linus Torvalds authored
Pull PA-RISC fixes from James Bottomley: "This is a set of three bug fixes that gets parisc running again on systems with PA1.1 processors. Two fix regressions introduced in 2.6.39 and one fixes a prefetch bug that only affects PA7300LC processors. We also have another pending fix to do with the sectional arrangement of vmlinux.lds, but there's a query on it during testing on one particular system type, so I'll hold off sending it in for now." * tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6: [PARISC] fix panic on prefetch(NULL) on PA7300LC [PARISC] fix crash in flush_icache_page_asm on PA1.1 [PARISC] fix PA1.1 oops on boot
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 linker bug workarounds from Peter Anvin. GNU ld-2.22.52.0.[12] (*) has an unfortunate bug where it incorrectly turns certain relocation entries absolute. Section-relative symbols that are part of otherwise empty sections are silently changed them to absolute. We rely on section-relative symbols staying section-relative, and actually have several sections in the linker script solely for this purpose. See for example http://sourceware.org/bugzilla/show_bug.cgi?id=14052 We could just black-list the buggy linker, but it appears that it got shipped in at least F17, and possibly other distros too, so it's sadly not some rare unusual case. This backports the workaround from the x86/trampoline branch, and as Peter says: "This is not a minimal fix, not at all, but it is a tested code base." * 'x86/ld-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, relocs: When printing an error, say relative or absolute x86, relocs: Workaround for binutils 2.22.52.0.1 section bug x86, realmode: 16-bit real-mode code support for relocs tool (*) That's a manly release numbering system. Stupid, sure. But manly.
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block layer fixes from Jens Axboe: "A few small, but important fixes. Most of them are marked for stable as well - Fix failure to release a semaphore on error path in mtip32xx. - Fix crashable condition in bio_get_nr_vecs(). - Don't mark end-of-disk buffers as mapped, limit it to i_size. - Fix for build problem with CONFIG_BLOCK=n on arm at least. - Fix for a buffer overlow on UUID partition printing. - Trivial removal of unused variables in dac960." * 'for-linus' of git://git.kernel.dk/linux-block: block: fix buffer overflow when printing partition UUIDs Fix blkdev.h build errors when BLOCK=n bio allocation failure due to bio_get_nr_vecs() block: don't mark buffers beyond end of disk as mapped mtip32xx: release the semaphore on an error path dac960: Remove unused variables from DAC960_CreateProcEntries()
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull one more networking bug-fix from David Miller: "One last straggler. Eric Dumazet's pktgen unload oops fix was not entirely complete, but all the cases should be handled properly now.... fingers crossed." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: pktgen: fix module unload for good
-
Hugh Dickins authored
Occasionally, testing memcg's move_charge_at_immigrate on rc7 shows a flurry of hundreds of warnings at kernel/res_counter.c:96, where res_counter_uncharge_locked() does WARN_ON(counter->usage < val). The first trace of each flurry implicates __mem_cgroup_cancel_charge() of mc.precharge, and an audit of mc.precharge handling points to mem_cgroup_move_charge_pte_range()'s THP handling in commit 12724850 ("memcg: avoid THP split in task migration"). Checking !mc.precharge is good everywhere else, when a single page is to be charged; but here the "mc.precharge -= HPAGE_PMD_NR" likely to follow, is liable to result in underflow (a lot can change since the precharge was estimated). Simply check against HPAGE_PMD_NR: there's probably a better alternative, trying precharge for more, splitting if unsuccessful; but this one-liner is safer for now - no kernel/res_counter.c:96 warnings seen in 26 hours. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- May 19, 2012
-
-
H. Peter Anvin authored
When the relocs tool throws an error, let the error message say if it is an absolute or relative symbol. This should make it a lot more clear what action the programmer needs to take and should help us find the reason if additional symbol bugs show up. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: <stable@vger.kernel.org>
-