Em 07-05-2012 10:32, Borislav Petkov escreveu:
breaking thread because it grew too big.
On Fri, May 04, 2012 at 07:48:42AM -0300, Mauro Carvalho Chehab wrote:
[ … ]
+memset(pos, 0, sizeof(pos));
+row = 0;
+chn = 0;
+debugf4(%s: initializing %d %s\n, __func__, tot_dimms
Em 04-05-2012 06:52, Borislav Petkov escreveu:
On Thu, May 03, 2012 at 11:16:54AM -0300, Mauro Carvalho Chehab wrote:
+ bool enable_filter,
+ unsigned pos[EDAC_MAX_LAYERS])
Passing the whole array as an argument instead of only
Em 04-05-2012 07:16, Borislav Petkov escreveu:
On Thu, May 03, 2012 at 11:16:54AM -0300, Mauro Carvalho Chehab wrote:
edac: Change internal representation to work with layers
...
/**
- * edac_mc_alloc: Allocate a struct mem_ctl_info structure
- * @size_pvt: size of private storage
Em 30-04-2012 05:15, Borislav Petkov escreveu:
On Sun, Apr 29, 2012 at 10:49:44AM -0300, Mauro Carvalho Chehab wrote:
[ 10.486440] EDAC MC: DCT0 chip selects:
[ 10.486443] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[ 10.486445] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[ 10.486448] EDAC amd64
Em 30-04-2012 04:59, Borislav Petkov escreveu:
On Sun, Apr 29, 2012 at 11:16:53AM -0300, Mauro Carvalho Chehab wrote:
Hey, are you looking at compiled code or at source code? Because I'm
looking at source code, and it is a pretty safe bet the majority of the
people here do that too.
What I
Em 30-04-2012 05:15, Borislav Petkov escreveu:
On Sun, Apr 29, 2012 at 10:49:44AM -0300, Mauro Carvalho Chehab wrote:
[ 10.486440] EDAC MC: DCT0 chip selects:
[ 10.486443] EDAC amd64: MC: 0: 2048MB 1: 2048MB
[ 10.486445] EDAC amd64: MC: 2: 2048MB 3: 2048MB
[ 10.486448] EDAC amd64
Em 30-04-2012 08:11, Borislav Petkov escreveu:
On Mon, Apr 30, 2012 at 07:58:33AM -0300, Mauro Carvalho Chehab wrote:
For example, this is the mapping used by the second memory controller of the
SB machine
I'm using on my tests:
[52803.640043] EDAC DEBUG: sbridge_probe: Registering MC#1 (2
Em 30-04-2012 09:38, Borislav Petkov escreveu:
On Mon, Apr 30, 2012 at 08:45:09AM -0300, Mauro Carvalho Chehab wrote:
Em 30-04-2012 08:11, Borislav Petkov escreveu:
On Mon, Apr 30, 2012 at 07:58:33AM -0300, Mauro Carvalho Chehab wrote:
This way it says initializing 12 dimms and the user
Em 30-04-2012 10:00, Mauro Carvalho Chehab escreveu:
Em 30-04-2012 09:38, Borislav Petkov escreveu:
On Mon, Apr 30, 2012 at 08:45:09AM -0300, Mauro Carvalho Chehab wrote:
Em 30-04-2012 08:11, Borislav Petkov escreveu:
On Mon, Apr 30, 2012 at 07:58:33AM -0300, Mauro Carvalho Chehab wrote
Em 28-04-2012 06:05, Borislav Petkov escreveu:
On Fri, Apr 27, 2012 at 12:36:12PM -0300, Mauro Carvalho Chehab wrote:
The fix for it were in another patch[1], as calling them as rank is
needed also at the sysfs API.
No, this doesn't fix it either:
[ 10.486440] EDAC MC: DCT0 chip selects
Em 28-04-2012 14:07, Joe Perches escreveu:
On Sat, 2012-04-28 at 11:16 +0200, Borislav Petkov wrote:
On Fri, Apr 27, 2012 at 02:52:35PM -0300, Mauro Carvalho Chehab wrote:
All those local variables should be sorted in a reverse christmas tree
order:
u32 this_is_the_longest_array_name
Em 28-04-2012 06:16, Borislav Petkov escreveu:
On Fri, Apr 27, 2012 at 02:52:35PM -0300, Mauro Carvalho Chehab wrote:
Also, is it valid to have n_layers == 0? The memcpy call below
will do nothing.
Changed to:
BUG_ON(n_layers EDAC_MAX_LAYERS || n_layers == 0);
Really? Look below
Em 28-04-2012 05:52, Borislav Petkov escreveu:
On Fri, Apr 27, 2012 at 01:07:38PM -0300, Mauro Carvalho Chehab wrote:
Yes. This is a common issue at the EDAC core: on several places, it calls the
edac debug macros (DEBUGF0...DEBUGF4) passing a __func__ as an argument,
while
the debug macros
Em 27-04-2012 10:33, Borislav Petkov escreveu:
Btw,
this patch gives
[8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
(0:0:0): row 0, chan 0
[8.287594] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 1: dimm1
(0:1:0): row 0, chan 1
[8.296784] EDAC
Em 27-04-2012 11:11, Joe Perches escreveu:
On Fri, 2012-04-27 at 15:33 +0200, Borislav Petkov wrote:
this patch gives
[8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
(0:0:0): row 0, chan 0
One too many __func__'s in some combination of the
pr_fmt and/or dbg call
Em 27-04-2012 15:11, Luck, Tony escreveu:
+ for (i = 0; i dimm-mci-n_layers; i++) {
+ printk(KERN_CONT %d, dimm-location[i]);
+ if (i dimm-mci-n_layers - 1)
+ printk(KERN_CONT .);
+ }
+ printk(KERN_CONT \n);
This looks hacky but I don't have a good
...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche
Hi Joe,
Em 17-04-2012 18:17, Joe Perches escreveu:
On Mon, 2012-04-16 at 17:38 -0300, Mauro Carvalho Chehab wrote:
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
...@suse.cz
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Shaohui Xie shaohui@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho
Em 17-04-2012 18:40, Borislav Petkov escreveu:
On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
Ok. well, we can either multiply nr_pages by channel_count or to let it
clear that this is per channel. I prefer the last option (see the enclosed
patch).
@@ -2152,6 +2146,7
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
v14: Fix two debug messages to properly report the number of pages
drivers/edac/amd64_edac.c | 14 ---
drivers/edac/amd76x_edac.c |6 ++--
drivers/edac/cell_edac.c |8
...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche
Em 17-04-2012 15:48, Borislav Petkov escreveu:
On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
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
Minor nitpick
...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche
: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/amd64_edac.c | 12 +++--
drivers/edac/amd76x_edac.c |6 ++--
drivers/edac/cell_edac.c |8 --
drivers/edac/cpc925_edac.c |8 --
drivers/edac/e752x_edac.c
The legacy edac ABI is going to be removed. Port the driver to use
and benefit from the new API functionality.
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac
: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Shaohui Xie shaohui@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche
: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/amd64_edac.c |2
theirs?
I'm happy for this to go through a single tree.
Me too.
With respect to the patches I was c/c (patches 13, 14, 31):
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
Thanks,
Mauro.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Peter Hüwe wrote:
From: Peter Huewe peterhu...@gmx.de
This patch adds a missing include linux/delay.h to prevent
build failures[1-5]
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
Forwarded to linux-next mailing list -
breakage still exists in linux-next of 20100514 - please apply
Mike Isely wrote:
Acked-By: Mike Isely is...@pobox.com
(in the context of the pvrusb2 driver related changes)
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
-Mike
On Mon, 22 Mar 2010, Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found
Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe. Prevents further
key xxx not in .data bug-reports. Although some attributes could probably be
converted to static ones, this is left for people having hardware to test.
Found by this semantic patch:
@ init @
On Wed, 19 Mar 2008 21:21:21 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Thu, 20 Mar 2008 14:39:53 +1100 Stephen Rothwell wrote:
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(tar balls at
Em Ter, 2007-07-03 às 04:01 -0500, Kumar Gala escreveu:
Andrew,
I was hoping to get your input on how to handle patches that cross
maintainers. I've got a patch that is pretty PPC specific, but
happens to touch some drivers as well.
Here's the diffstat to get a rough idea:
201 - 234 of 234 matches
Mail list logo
