Hi,
While booting v4.13-rc1 on an arm64 system, I noticed some messages
that clutter the boot log without providing any useful
information. This series trims some of the obvious offenders.
The patches are spread across a few sub-systems - arm64/mm, mailbox,
APEI and xen, and can be independently merged.
Thanks,
Punit
Punit Agrawal (4):
arm64/numa: Drop duplicate message
mailbox: pcc: Drop uninformative output during boot
ACPI / APEI: Drop uninformative messages during boot
xen: Drop un-informative message during boot
arch/arm64/mm/numa.c | 7 +------
drivers/acpi/apei/ghes.c | 9 +--------
drivers/mailbox/pcc.c | 4 +---
drivers/xen/xenfs/super.c | 1 -
4 files changed, 3 insertions(+), 18 deletions(-)
--
2.11.0
When booting linux on a system without CONFIG_NUMA enabled, the
following messages are printed during boot -
NUMA: Faking a node at [mem 0x0000000000000000-0x00000083ffffffff]
NUMA: Adding memblock [0x8000000000 - 0x8000e7ffff] on node 0
NUMA: Adding memblock [0x8000e80000 - 0x83f65cffff] on node 0
NUMA: Adding memblock [0x83f65d0000 - 0x83f665ffff] on node 0
NUMA: Adding memblock [0x83f6660000 - 0x83f676ffff] on node 0
NUMA: Adding memblock [0x83f6770000 - 0x83f678ffff] on node 0
NUMA: Adding memblock [0x83f6790000 - 0x83fb82ffff] on node 0
NUMA: Adding memblock [0x83fb830000 - 0x83fbc0ffff] on node 0
NUMA: Adding memblock [0x83fbc10000 - 0x83fbdfffff] on node 0
NUMA: Adding memblock [0x83fbe00000 - 0x83fbffffff] on node 0
NUMA: Adding memblock [0x83fc000000 - 0x83fffbffff] on node 0
NUMA: Adding memblock [0x83fffc0000 - 0x83fffdffff] on node 0
NUMA: Adding memblock [0x83fffe0000 - 0x83ffffffff] on node 0
NUMA: Initmem setup node 0 [mem 0x8000000000-0x83ffffffff]
NUMA: NODE_DATA [mem 0x83fffec500-0x83fffedfff]
The information is then duplicated by core kernel messages right after
the above output.
Early memory node ranges
node 0: [mem 0x0000008000000000-0x0000008000e7ffff]
node 0: [mem 0x0000008000e80000-0x00000083f65cffff]
node 0: [mem 0x00000083f65d0000-0x00000083f665ffff]
node 0: [mem 0x00000083f6660000-0x00000083f676ffff]
node 0: [mem 0x00000083f6770000-0x00000083f678ffff]
node 0: [mem 0x00000083f6790000-0x00000083fb82ffff]
node 0: [mem 0x00000083fb830000-0x00000083fbc0ffff]
node 0: [mem 0x00000083fbc10000-0x00000083fbdfffff]
node 0: [mem 0x00000083fbe00000-0x00000083fbffffff]
node 0: [mem 0x00000083fc000000-0x00000083fffbffff]
node 0: [mem 0x00000083fffc0000-0x00000083fffdffff]
node 0: [mem 0x00000083fffe0000-0x00000083ffffffff]
Initmem setup node 0 [mem 0x0000008000000000-0x00000083ffffffff]
Remove the duplication of memblock layout information printed during
boot by dropping the messages from arm64 numa initialisation.
Signed-off-by: Punit Agrawal <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
---
arch/arm64/mm/numa.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index b388a99fea7b..dad128ba98bf 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -208,8 +208,6 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
}
node_set(nid, numa_nodes_parsed);
- pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
- start, (end - 1), nid);
return ret;
}
@@ -223,10 +221,7 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
void *nd;
int tnid;
- if (start_pfn < end_pfn)
- pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n", nid,
- start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
- else
+ if (start_pfn >= end_pfn)
pr_info("Initmem setup node %d [<memory-less node>]\n", nid);
nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
--
2.11.0
When booting an ACPI enabled system that does not provide the hardware
error source table (HEST), the ghes driver prints the following message
in the kernel log -
[ 3.460067] GHES: HEST is not enabled!
which is not helpful.
The message is also output when HEST is explicitly disabled using kernel
command line parameter.
Drop this message. While we are touching this code, also drop similar
message when GHES is disabled using the module parameter.
Signed-off-by: Punit Agrawal <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Borislav Petkov <[email protected]>
---
drivers/acpi/apei/ghes.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d661d452b238..3ddd1bd714fc 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1265,15 +1265,8 @@ static int __init ghes_init(void)
if (acpi_disabled)
return -ENODEV;
- if (hest_disable) {
- pr_info(GHES_PFX "HEST is not enabled!\n");
+ if (hest_disable || ghes_disable)
return -EINVAL;
- }
-
- if (ghes_disable) {
- pr_info(GHES_PFX "GHES is not enabled!\n");
- return -EINVAL;
- }
ghes_nmi_init_cxt();
--
2.11.0
On systems that are not booted as a Xen domain, the xenfs driver prints
the following message during boot.
[ 3.460595] xenfs: not registering filesystem on non-xen platform
As the user chose not to boot a Xen domain, this message does not
provide useful information. Drop this message.
Signed-off-by: Punit Agrawal <[email protected]>
Cc: Boris Ostrovsky <[email protected]>
Cc: Juergen Gross <[email protected]>
---
drivers/xen/xenfs/super.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 967f069385d0..71ddfb4cf61c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -87,7 +87,6 @@ static int __init xenfs_init(void)
if (xen_domain())
return register_filesystem(&xenfs_type);
- pr_info("not registering filesystem on non-xen platform\n");
return 0;
}
--
2.11.0
When booting on an ACPI enabled system that does not provide the
Platform Communications Channel Table (PCCT), the pcc mailbox driver
prints -
[ 0.484261] PCCT header not found.
during probe before returning -ENODEV.
This message clutters the bootlog and doesn't provide any useful
information. Drop this message.
Signed-off-by: Punit Agrawal <[email protected]>
Cc: Jassi Brar <[email protected]>
---
drivers/mailbox/pcc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index ac91fd0d62c6..3d83cdc11ab5 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -457,10 +457,8 @@ static int __init acpi_pcc_probe(void)
/* Search for PCCT */
status = acpi_get_table(ACPI_SIG_PCCT, 0, &pcct_tbl);
- if (ACPI_FAILURE(status) || !pcct_tbl) {
- pr_warn("PCCT header not found.\n");
+ if (ACPI_FAILURE(status) || !pcct_tbl)
return -ENODEV;
- }
count = acpi_table_parse_entries(ACPI_SIG_PCCT,
sizeof(struct acpi_table_pcct),
--
2.11.0
On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
> When booting an ACPI enabled system that does not provide the hardware
> error source table (HEST), the ghes driver prints the following message
> in the kernel log -
>
> [ 3.460067] GHES: HEST is not enabled!
>
> which is not helpful.
>
> The message is also output when HEST is explicitly disabled using kernel
> command line parameter.
>
> Drop this message. While we are touching this code, also drop similar
> message when GHES is disabled using the module parameter.
No.
To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
booting. See
dba648300e89 ("ACPI / einj: Make error paths more talkative")
for a good example why.
If anything, you should do the total opposite patch and add more
printks to the error paths so that it is obvious why GHES startup fails.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Hi Borislav,
Borislav Petkov <[email protected]> writes:
> On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
>> When booting an ACPI enabled system that does not provide the hardware
>> error source table (HEST), the ghes driver prints the following message
>> in the kernel log -
>>
>> [ 3.460067] GHES: HEST is not enabled!
>>
>> which is not helpful.
>>
>> The message is also output when HEST is explicitly disabled using kernel
>> command line parameter.
>>
>> Drop this message. While we are touching this code, also drop similar
>> message when GHES is disabled using the module parameter.
>
> No.
>
> To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
> booting. See
>
> dba648300e89 ("ACPI / einj: Make error paths more talkative")
>
> for a good example why.
einj verbosity can't be used as a model here. einj by it's definition is
for development and testing. It can also be loaded as a module.
>
> If anything, you should do the total opposite patch and add more
>printks to the error paths so that it is obvious why GHES startup
>fails.
As mentioned in the commit log, the platform doesn't provide the HEST
(or any of the APEI tables for that matter). So it's not useful to see a
message complaining that HEST is not enabled. For such platforms, this
message at best adds no value and at worse gives the impression of
something gone wrong during boot.
I agree that where there is a genuine problem, relevant messages can
help to diagnose the problem. But what's printed now doesn't fit the
criteria.
Hope that makes sense.
Thanks,
Punit
>
> -- Regards/Gruss, Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Thu, Jul 20, 2017 at 01:29:17PM +0100, Punit Agrawal wrote:
> I agree that where there is a genuine problem, relevant messages can
> help to diagnose the problem. But what's printed now doesn't fit the
> criteria.
So make it fit the criteria. Change the code to not issue that message
when the platform doesn't have those tables. But keep it in the
remaining cases, when the tables are there.
You can't be removing useful error messages just because your platform
doesn't have the tables.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Borislav Petkov <[email protected]> writes:
> On Thu, Jul 20, 2017 at 01:29:17PM +0100, Punit Agrawal wrote:
>> I agree that where there is a genuine problem, relevant messages can
>> help to diagnose the problem. But what's printed now doesn't fit the
>> criteria.
>
> So make it fit the criteria. Change the code to not issue that message
> when the platform doesn't have those tables. But keep it in the
> remaining cases, when the tables are there.
>
> You can't be removing useful error messages just because your platform
> doesn't have the tables.
Fair point! I'll focus on quiescing the messages when the tables are not
present.
Inspired by your suggestion, I tried the following diff instead of
$SUBJECT.
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 456b488eb1df..f7784d9514e1 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -233,8 +233,9 @@ void __init acpi_hest_init(void)
status = acpi_get_table(ACPI_SIG_HEST, 0,
(struct acpi_table_header **)&hest_tab);
if (status == AE_NOT_FOUND)
- goto err;
- else if (ACPI_FAILURE(status)) {
+ return;
+
+ if (ACPI_FAILURE(status)) {
const char *msg = acpi_format_exception(status);
pr_err(HEST_PFX "Failed to get table, %s\n", msg);
rc = -EINVAL;
This landed me a new message not seen before -
[ 3.232940] GHES: Failed to enable APEI firmware first mode.
On further digging, this message is printed on platforms not supporting
the legacy WHEA stuff, when the APEI Support bit is not set in the
platform wide _OSC capabilities.
To make this message a bit less alarming, I can modify it to something
like -
"Firmware does not support APEI firmware first mode"
Thoughts?
On 07/20/2017 07:04 AM, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
>
> [ 3.460595] xenfs: not registering filesystem on non-xen platform
>
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Cc: Boris Ostrovsky <[email protected]>
> Cc: Juergen Gross <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Boris Ostrovsky <[email protected]> writes:
> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>> On systems that are not booted as a Xen domain, the xenfs driver prints
>> the following message during boot.
>>
>> [ 3.460595] xenfs: not registering filesystem on non-xen platform
>>
>> As the user chose not to boot a Xen domain, this message does not
>> provide useful information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Cc: Boris Ostrovsky <[email protected]>
>> Cc: Juergen Gross <[email protected]>
>
> Reviewed-by: Boris Ostrovsky <[email protected]>
Thanks Boris.
Juergen, I assume you'll pick this up for the next round of xen
updates.
>
>
> _______________________________________________
> Xen-devel mailing list
> [email protected]
> https://lists.xen.org/xen-devel
On 21/07/17 12:12, Punit Agrawal wrote:
> Boris Ostrovsky <[email protected]> writes:
>
>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>> the following message during boot.
>>>
>>> [ 3.460595] xenfs: not registering filesystem on non-xen platform
>>>
>>> As the user chose not to boot a Xen domain, this message does not
>>> provide useful information. Drop this message.
>>>
>>> Signed-off-by: Punit Agrawal <[email protected]>
>>> Cc: Boris Ostrovsky <[email protected]>
>>> Cc: Juergen Gross <[email protected]>
>>
>> Reviewed-by: Boris Ostrovsky <[email protected]>
>
> Thanks Boris.
>
> Juergen, I assume you'll pick this up for the next round of xen
> updates.
Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
there is no need to hurry.
Juergen
Juergen Gross <[email protected]> writes:
> On 21/07/17 12:12, Punit Agrawal wrote:
>> Boris Ostrovsky <[email protected]> writes:
>>
>>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>>> the following message during boot.
>>>>
>>>> [ 3.460595] xenfs: not registering filesystem on non-xen platform
>>>>
>>>> As the user chose not to boot a Xen domain, this message does not
>>>> provide useful information. Drop this message.
>>>>
>>>> Signed-off-by: Punit Agrawal <[email protected]>
>>>> Cc: Boris Ostrovsky <[email protected]>
>>>> Cc: Juergen Gross <[email protected]>
>>>
>>> Reviewed-by: Boris Ostrovsky <[email protected]>
>>
>> Thanks Boris.
>>
>> Juergen, I assume you'll pick this up for the next round of xen
>> updates.
>
> Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
> there is no need to hurry.
Agreed! Thanks for confirming.
On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote:
> "Firmware does not support APEI firmware first mode"
>
> Thoughts?
I guess the simplest would be to add a third state to that hest_disable
to denote "HEST table not found" and then exit ghes_init() early, based on
checking it.
Otherwise ghes_init() inits a bunch of things which you probably don't
want on a platform which doesn't support APEI.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Hi Boris,
Apologies for the delayed response. I somehow managed to lose updates on
this thread.
Borislav Petkov <[email protected]> writes:
> On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote:
>> "Firmware does not support APEI firmware first mode"
>>
>> Thoughts?
>
> I guess the simplest would be to add a third state to that hest_disable
> to denote "HEST table not found" and then exit ghes_init() early, based on
> checking it.
Although simple, won't it make the already convoluted code flow more
so. Instead in addition to not setting hest_disable when the table is
not found ...
>
> Otherwise ghes_init() inits a bunch of things which you probably don't
> want on a platform which doesn't support APEI.
... would you be open to a patch re-working the ghes driver
initialisation to only do the platform driver registration. The the rest
of the initialisation (including the apei_osc_setup and related
messages) can be performed when the first ghes device gets probed.
Does that sound like a better alternative?
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote:
> ... would you be open to a patch re-working the ghes driver
> initialisation to only do the platform driver registration. The the rest
> of the initialisation (including the apei_osc_setup and related
> messages) can be performed when the first ghes device gets probed.
>
> Does that sound like a better alternative?
If you split it by doing one logical change per patch so that it is
obvious what's going on and you don't break existing usage, I don't see
why not.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Borislav Petkov <[email protected]> writes:
> On Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote:
>> ... would you be open to a patch re-working the ghes driver
>> initialisation to only do the platform driver registration. The the rest
>> of the initialisation (including the apei_osc_setup and related
>> messages) can be performed when the first ghes device gets probed.
>>
>> Does that sound like a better alternative?
>
> If you split it by doing one logical change per patch so that it is
> obvious what's going on and you don't break existing usage, I don't see
> why not.
Good! I'll try and get the patches out in the next few days.
Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On 20/07/17 13:04, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
>
> [ 3.460595] xenfs: not registering filesystem on non-xen platform
>
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Cc: Boris Ostrovsky <[email protected]>
> Cc: Juergen Gross <[email protected]>
Committed to: xen/tip.git for-linus-4.13b
Thanks,
Juergen
[CC'ing Rafael J. Wysocki, who picks patches for pcc.c]
On Mon, Jul 31, 2017 at 3:22 PM, Punit Agrawal <[email protected]> wrote:
> Punit Agrawal <[email protected]> writes:
>
>> When booting on an ACPI enabled system that does not provide the
>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>> prints -
>>
>> [ 0.484261] PCCT header not found.
>>
>> during probe before returning -ENODEV.
>>
>> This message clutters the bootlog and doesn't provide any useful
>> information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Cc: Jassi Brar <[email protected]>
>> ---
>> drivers/mailbox/pcc.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> index ac91fd0d62c6..3d83cdc11ab5 100644
>> --- a/drivers/mailbox/pcc.c
>> +++ b/drivers/mailbox/pcc.c
>> @@ -457,10 +457,8 @@ static int __init acpi_pcc_probe(void)
>> /* Search for PCCT */
>> status = acpi_get_table(ACPI_SIG_PCCT, 0, &pcct_tbl);
>>
>> - if (ACPI_FAILURE(status) || !pcct_tbl) {
>> - pr_warn("PCCT header not found.\n");
>> + if (ACPI_FAILURE(status) || !pcct_tbl)
>> return -ENODEV;
>> - }
>>
>> count = acpi_table_parse_entries(ACPI_SIG_PCCT,
>> sizeof(struct acpi_table_pcct),
>
> Ping! Any comments/concerns with dropping the message?
>
> Thanks.
(keeping Rafael in c/c per Jassi suggestion)
On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <[email protected]> wrote:
> When booting on an ACPI enabled system that does not provide the
> Platform Communications Channel Table (PCCT), the pcc mailbox driver
> prints -
>
> [ 0.484261] PCCT header not found.
Ah. I thought this was already removed ages ago. Thanks for removing this.
> during probe before returning -ENODEV.
>
> This message clutters the bootlog and doesn't provide any useful
> information. Drop this message.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Cc: Jassi Brar <[email protected]>
Acked-by: Alexey Klimov <[email protected]>
On 7/31/2017 7:47 PM, Alexey Klimov wrote:
> (keeping Rafael in c/c per Jassi suggestion)
>
> On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <[email protected]> wrote:
>> When booting on an ACPI enabled system that does not provide the
>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>> prints -
>>
>> [ 0.484261] PCCT header not found.
> Ah. I thought this was already removed ages ago. Thanks for removing this.
>
>> during probe before returning -ENODEV.
>>
>> This message clutters the bootlog and doesn't provide any useful
>> information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Cc: Jassi Brar <[email protected]>
> Acked-by: Alexey Klimov <[email protected]>
>
Please resend this, including all applicable tags, with a CC to
[email protected] for easier processing.
Thanks,
Rafael
"Rafael J. Wysocki" <[email protected]> writes:
> On 7/31/2017 7:47 PM, Alexey Klimov wrote:
>> (keeping Rafael in c/c per Jassi suggestion)
>>
>> On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <[email protected]> wrote:
>>> When booting on an ACPI enabled system that does not provide the
>>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>>> prints -
>>>
>>> [ 0.484261] PCCT header not found.
>> Ah. I thought this was already removed ages ago. Thanks for removing this.
>>
>>> during probe before returning -ENODEV.
>>>
>>> This message clutters the bootlog and doesn't provide any useful
>>> information. Drop this message.
>>>
>>> Signed-off-by: Punit Agrawal <[email protected]>
>>> Cc: Jassi Brar <[email protected]>
>> Acked-by: Alexey Klimov <[email protected]>
>>
> Please resend this, including all applicable tags, with a CC to
> [email protected] for easier processing.
Thanks Jassi for adding the appropriate folks on this
patch. get_maintainer.pl threw me off on this one. ;)
I'll add the tags (Thanks, Alexey) and re-send.
>
> Thanks,
>
> Rafael