[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F31CB9150@ORSMSX106.amr.corp.intel.com>
Date: Tue, 13 Aug 2013 20:13:56 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
Mauro Carvalho Chehab <m.chehab@...sung.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"rjw@...k.pl" <rjw@...k.pl>,
"lance.ortiz@...com" <lance.ortiz@...com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/3] mce: acpi/apei: trace: Enable ghes memory error
trace event
> What about sending tracepoint data over serial and/or network? I agree
> that dmesg over serial would be helpful but we need a similar sure-fire
> way for carrying error info out.
Generic tracepoints are architected to be able to fire at very high rates and
log huge amounts of information. So we'd need something special to say
just log these special tracepoints to network/serial.
> Which reminds me, pstore could also be a good thing to use, in addition.
> Only put error info there as it is limited anyway.
Yes - space is very limited. I don't know how to assign priority for logging
the dmesg data vs. some error logs.
If we just "printk()" the most important parts - then that data will automatically
flow to the serial console and to pstore. Then we have multiple paths for the
critical bits of the error log - and the tracepoints give us more details for the
cases where the machine doesn't spontaneously explode.
-Tony
Powered by blists - more mailing lists