From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "Shaohui Xie" <Shaohui.Xie@freescale.com>,
"Jason Uhlenkott" <juhlenko@akamai.com>,
"Aristeu Rozanski" <arozansk@redhat.com>,
"Hitoshi Mitake" <h.mitake@gmail.com>,
"Mark Gross" <mark.gross@intel.com>,
"Dmitry Eremin-Solenikov" <dbaryshkov@gmail.com>,
"Ranganathan Desikan" <ravi@jetztechnologies.com>,
"Egor Martovetsky" <egor@pasemi.com>,
"Niklas Söderlund" <niklas.soderlund@ericsson.com>,
"Tim Small" <tim@buttersideup.com>,
"Arvind R." <arvino55@gmail.com>,
"Chris Metcalf" <cmetcalf@tilera.com>,
"Olof Johansson" <olof@lixom.net>,
"Doug Thompson" <norsk5@yahoo.com>,
"Linux Edac Mailing List" <linux-edac@vger.kernel.org>,
"Michal Marek" <mmarek@suse.cz>, "Jiri Kosina" <jkosina@suse.cz>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Joe Perches" <joe@perches.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Date: Mon, 30 Apr 2012 08:45:09 -0300 [thread overview]
Message-ID: <4F9E7B45.8010908@redhat.com> (raw)
In-Reply-To: <20120430111126.GD9303@aftab.osrc.amd.com>
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 of 2)
>> ...
>> [52803.640062] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc(): allocating 7196 bytes for mci data (12 dimms, 12 csrows/channels)
>> [52803.640070] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: initializing 12 dimms
>> [52803.640072] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 0: dimm0 (0:0:0): row 0, chan 0
>> [52803.640074] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 1: dimm1 (0:1:0): row 0, chan 1
>> [52803.640077] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 2: dimm2 (0:2:0): row 0, chan 2
>> [52803.640080] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 3: dimm3 (1:0:0): row 0, chan 3
>> [52803.640083] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 4: dimm4 (1:1:0): row 1, chan 0
>> [52803.640086] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 5: dimm5 (1:2:0): row 1, chan 1
>> [52803.640089] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 6: dimm6 (2:0:0): row 1, chan 2
>> [52803.640092] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 7: dimm7 (2:1:0): row 1, chan 3
>> [52803.640095] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 8: dimm8 (2:2:0): row 2, chan 0
>> [52803.640098] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 9: dimm9 (3:0:0): row 2, chan 1
>> [52803.640101] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 10: dimm10 (3:1:0): row 2, chan 2
>> [52803.640104] EDAC DEBUG: edac_mc_alloc: edac_mc_alloc: 11: dimm11 (3:2:0): row 2, chan 3
>>
>> With the above info, it is clear that the DIMM located at mc#1, channel#3 slot#2 is
>> called "dimm11" at the new API, and corresponds to "csrow 2, channel 3" for a legacy
>> EDAC API call.
>
> Are all those DIMM slots above populated? What happens if they're not,
> are you issuing the same dimm0-dimm11 lines for slots which aren't even
> populated?
>
> I have a much better idea: Generally, this debug info should come from
> the specific driver that allocates the dimm descriptors, not from the
> EDAC core. This way, you know in the driver which slots are populated
> and those which are not should be omitted.
The drivers don't allocate the dimm descriptors. They're allocated by the
core.
> This way it says "initializing 12 dimms" and the user thinks there are
> 12 DIMMs on his system where this might not be true.
I'm OK to remove the "initializing 12 dimms" message. It doesn't add anything
new.
With regards do the other messages, if the debug messages are not clear,
then let's fix them, instead of removing. What if we print, instead,
on a message like:
"row 1, chan 1 will represent dimm5 (1:2:0) if not empty"
Regards,
Mauro
next prev parent reply other threads:[~2012-04-30 11:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1335289087-11337-1-git-send-email-mchehab@redhat.com>
2012-04-24 18:15 ` [PATCH EDACv16 1/2] edac: Change internal representation to work with layers Mauro Carvalho Chehab
2012-04-27 13:33 ` Borislav Petkov
2012-04-27 14:11 ` Joe Perches
2012-04-27 15:12 ` Borislav Petkov
2012-04-27 16:07 ` Mauro Carvalho Chehab
2012-04-28 8:52 ` Borislav Petkov
2012-04-28 20:38 ` Joe Perches
2012-04-29 14:25 ` Mauro Carvalho Chehab
2012-04-29 15:11 ` Mauro Carvalho Chehab
2012-04-29 16:03 ` Joe Perches
2012-04-29 17:18 ` Mauro Carvalho Chehab
2012-04-27 15:36 ` Mauro Carvalho Chehab
2012-04-28 9:05 ` Borislav Petkov
2012-04-29 13:49 ` Mauro Carvalho Chehab
2012-04-30 8:15 ` Borislav Petkov
2012-04-30 10:58 ` Mauro Carvalho Chehab
2012-04-30 11:11 ` Borislav Petkov
2012-04-30 11:45 ` Mauro Carvalho Chehab [this message]
2012-04-30 12:38 ` Borislav Petkov
2012-04-30 13:00 ` Mauro Carvalho Chehab
2012-04-30 13:53 ` Mauro Carvalho Chehab
2012-04-30 11:37 ` Mauro Carvalho Chehab
2012-04-27 17:52 ` Mauro Carvalho Chehab
2012-04-27 18:11 ` Luck, Tony
2012-04-27 19:24 ` Mauro Carvalho Chehab
2012-04-28 8:58 ` Borislav Petkov
2012-04-28 9:16 ` Borislav Petkov
2012-04-28 17:07 ` Joe Perches
2012-04-29 14:02 ` Mauro Carvalho Chehab
2012-04-29 14:16 ` Mauro Carvalho Chehab
2012-04-30 7:59 ` Borislav Petkov
2012-04-30 11:23 ` Mauro Carvalho Chehab
2012-04-30 12:51 ` Borislav Petkov
2012-05-02 13:30 Borislav Petkov
2012-05-03 14:16 ` Mauro Carvalho Chehab
2012-05-04 9:52 ` Borislav Petkov
2012-05-04 10:15 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F9E7B45.8010908@redhat.com \
--to=mchehab@redhat.com \
--cc=Shaohui.Xie@freescale.com \
--cc=akpm@linux-foundation.org \
--cc=arozansk@redhat.com \
--cc=arvino55@gmail.com \
--cc=bp@amd64.org \
--cc=cmetcalf@tilera.com \
--cc=dbaryshkov@gmail.com \
--cc=egor@pasemi.com \
--cc=h.mitake@gmail.com \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=juhlenko@akamai.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.gross@intel.com \
--cc=mmarek@suse.cz \
--cc=niklas.soderlund@ericsson.com \
--cc=norsk5@yahoo.com \
--cc=olof@lixom.net \
--cc=ravi@jetztechnologies.com \
--cc=tim@buttersideup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).