00019260 D pqr_state
Do you have /sys/fs/resctrl mounted? This variable is read on every context
switch.
If your benchmark does a lot of context switching and this now shares a cache
line
with something different (especially something that is sometimes modified from
another
CPU
On Mon, Jan 11, 2021 at 02:11:56PM -0800, Andy Lutomirski wrote:
>
> > On Jan 11, 2021, at 1:45 PM, Tony Luck wrote:
> >
> > Recovery action when get_user() triggers a machine check uses the fixup
> > path to make get_user() return -EFAULT. Also queue_task_work() sets up
> > so that kill_me_ma
On Tue, Jan 12, 2021 at 09:00:14AM -0800, Andy Lutomirski wrote:
> > On Jan 11, 2021, at 2:21 PM, Luck, Tony wrote:
> >
> > On Mon, Jan 11, 2021 at 02:11:56PM -0800, Andy Lutomirski wrote:
> >>
> >>>> On Jan 11, 2021, at 1:45 PM, Tony Luck wrote:
On Tue, Jan 12, 2021 at 09:21:21AM -0800, Andy Lutomirski wrote:
> Well, we need to do *something* when the first __get_user() trips the
> #MC. It would be nice if we could actually fix up the page tables
> inside the #MC handler, but, if we're in a pagefault_disable() context
> we might have lock
On Tue, Jan 12, 2021 at 10:57:07AM -0800, Andy Lutomirski wrote:
> On Tue, Jan 12, 2021 at 10:24 AM Luck, Tony wrote:
> >
> > On Tue, Jan 12, 2021 at 09:21:21AM -0800, Andy Lutomirski wrote:
> > > Well, we need to do *something* when the first __get_user() trips the
>
On Tue, Jan 12, 2021 at 02:04:55PM -0800, Andy Lutomirski wrote:
> > But we know that the fault happend in a get_user() or copy_from_user() call
> > (i.e. an RIP with an extable recovery address). Does context switch
> > access user memory?
>
> No, but NMI can.
>
> The case that would be very ve
> I think you guys have veered off into the weeds with this. The current
> solution - modulo error messages not destined for humans :) - is not soo
> bad, considering the whole MCA trainwreck.
>
> Or am I missing something completely unacceptable?
Maybe the other difference in approach between And
>> Maybe the other difference in approach between Andy and me is whether to
>> go for a solution that covers all the corner cases, or just make an
>> incremental
>> improvement that allows for recover in some useful subset of remaining fatal
>> cases, but still dies in other cases.
>
> Does that m
On Tue, Jan 19, 2021 at 11:56:32AM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 03:23:46PM -0800, Luck, Tony wrote:
> > On Fri, Jan 15, 2021 at 12:51:03PM -0800, Luck, Tony wrote:
> > > static void kill_me_now(struct callback_head *ch)
> > >
> I think this is horrid; why can't we have it return something different
> then -EFAULT instead?
I did consider this ... but it appears that architectures aren't unified in the
return value from get_user()
Here's another function involved in the futex call chain leading to this:
static int get_
> Yeah, saw that, but that should be trivially fixable I'm thinking.
Trivial, maybe ... but then follows the audit of other get_user() calls:
git grep get_user\( | wc -l
2003
:-(
-Tony
On Thu, Jan 14, 2021 at 09:22:13PM +0100, Borislav Petkov wrote:
> On Mon, Jan 11, 2021 at 01:44:50PM -0800, Tony Luck wrote:
> > @@ -1431,8 +1433,11 @@ noinstr void do_machine_check(struct pt_regs *regs)
> > mce_panic("Failed kernel mode recovery", &m,
> > msg);
> >
> Yeah, into
>
> fd258dc4442c ("x86/mce: Add Skylake quirk for patrol scrub reported errors")
Thanks ... my memory is failing, and I forgot that the patch had been improved
and
moved from core.c (where I looked for it) into severity.c
-Tony
> What is the justifucation for making this rate limit per UID and not
> per task, per process or systemwide?
The concern is that a malicious user is running a workload that loops
obtaining the buslock. This brings the whole system to its knees.
Limiting per task doesn't help. The user can just
On Thu, Mar 04, 2021 at 02:45:24PM +0800, Aili Yao wrote:
> > > if your methods works, should it be like this?
> > >
> > > 1582 pteval =
> > > swp_entry_to_pte(make_hwpoison_entry(subpage));
> > > 1583 if (PageHuge(page)) {
> > > 1584
> From the walk, it seems we have got the virtual address, can we just send a
> SIGBUS with it?
If the walk wins the race and the pte for the poisoned page is still valid,
then yes.
But we could have:
CPU1CPU2
memory_failure sets poison
bit for struct page
rmap fi
This whole page table walking patch is trying to work around the
races caused by multiple calls to memory_failure() for the same
page.
Maybe better to just avoid the races. The comment right above
memory_failure says:
* Must run in process context (e.g. a work queue) with interrupts
* enabled
On Fri, Feb 26, 2021 at 10:59:15AM +0800, Aili Yao wrote:
> Hi naoya, tony:
> > >
> > > Idea for what we should do next ... Now that x86 is calling
> > > memory_failure()
> > > from user context ... maybe parallel calls for the same page should
> > > be blocked until the first caller completes so
> For error address with sigbus, i think this is not an issue resulted by the
> patch i post, before my patch, the issue is already there.
> I don't find a realizable way to get the correct address for same reason ---
> we don't know whether the page mapping is there or not when
> we got to kill_
>> Nothing new - just the next spammer attempt.
> But this was a new class of Spam. So far i got only mass mailing... This was
> personalized based on my previous e-Mail (did not include this part in my
> mail)
Somewhat new - combining trawling of public mailing lists for addresses with
a phis
On Fri, Mar 12, 2021 at 11:48:31PM +, Luck, Tony wrote:
> Thanks to the decode of the instruction we do have the virtual address. So we
> just need
> a safe walk of pgd->p4d->pud->pmd->pte (truncated if we hit a huge page) with
> a write
> of a "not-present&
- set_bit(MCE_OVERFLOW, (unsigned long *)&mcelog->flags);
+ mcelog->flags |= BIT(MCE_OVERFLOW);
set_bit() is an atomic operation because it might race with the code to
get and clear this bit:
do {
flags = mcelog->flags;
> So what I'm missing with all this fun is, yeah, sure, we have this
> facility out there but who's using it? Is anyone even using it at all?
Even if no applications ever do anything with it, it is still useful to avoid
crashing the whole system and just terminate one application/guest.
> If so,
On Wed, Mar 31, 2021 at 07:25:40PM +0800, Aili Yao wrote:
> When the page is already poisoned, another memory_failure() call in the
> same page now return 0, meaning OK. For nested memory mce handling, this
> behavior may lead to one mce looping, Example:
>
> 1.When LCME is enabled, and there are
>> Combined with my "mutex" patch (to get rid of races where 2nd process returns
>> early, but first process is still looking for mappings to unmap and tasks
>> to signal) this patch moves forward a bit. But I think it needs an
>> additional change here in kill_me_maybe() to just "return" if there
>> But there are places in the kernel where the code assumes that this
>> EFAULT return was simply because of a page fault. The code takes some
>> action to fix that, and then retries the access. This results in a second
>> machine check.
>
> What about return EHWPOISON instead of EFAULT and update
> ../drivers/edac/igen6_edac.c: In function 'ecclog_nmi_handler':
> ../drivers/edac/igen6_edac.c:525:10: error: 'NMI_DONE' undeclared (first use
> in this function); did you mean 'DMI_NONE'?
>return NMI_DONE;
This driver has a #include
But inside that file it says:
#if defined(CONFIG_HAVE_
> Programs that get a signal might expect that the RIP that the signal
> frame points to is the instruction that caused the signal and that the
> instruction faulted without side effects. For SIGSEGV, I would be
> especially nervous about this. Maybe SIGBUS is safer. For SIGSEGV,
> it's entirely
>> I think the "sapphire_rapids" is the code name for the server platform.
>
> If that's really the case, then:
>
> #define INTEL_FAM6_SAPPHIRERAPIDS_X 0x8F
>
> is wrong, those things should be uarch name, not platform name. Tony?
0x8F is the model number of the CPU that is named Sapphire Rapi
> Sorry to interrupt as I am really confused here:
> If it's a copyin case, has the page been mapped for the current process?
Yes. The kernel has the current process mapped to the low address range
and code like get_user(), put_user() "simply" reaches down to those addresses
(maybe not so simply,
>> will memory_failure() find it and unmap it? if succeed, then the current
>> will be
>> signaled with correct vaddr and shift?
>
> That's a very good question. I didn't see a SIGBUS when I first wrote this
> code,
> hence all the p->mce_vaddr. But now I'm
> a) not sure why there wasn't a sign
> Yah, some printk sprinkling might be a good start. But debugging in that
> atomic context is always nasty. ;-\
Some very light printk sprinkling (one message in queue_task_work() in atomic
context, one each in kill_me_now() and kill_me_maybe() to check when task_work
actually called them.
Cases
> I think we need to at least fix the existing bug before we add more
> signals. AFAICS the MCE_IN_KERNEL_COPYIN code is busted for kernel
> threads.
Can a kernel thread do get_user() or copy_from_user()? Do we have kernel
threads
that have an associated user address space to copy from?
-Tony
> I guess that p->mce_vaddr stores the virtual address of the error here.
> If so, sending SIGBUS with the address looks enough as we do now, so why
> do you walk page table to find the error virtual address?
p->mce_vaddr only has the virtual address for the COPYIN case. In that code
path we decod
> Some programs may use read(2), write(2), etc as ways to check if
> memory is valid without getting a signal. They might not want
> signals, which means that this feature might need to be configurable.
That sounds like an appalling hack. If users need such a mechanism
we should create some bette
> Can you point me at that SIGBUS code in a current kernel?
It is in kill_me_maybe(). mce_vaddr is setup when we disassemble whatever
get_user()
or copy from user variant was in use in the kernel when the poison memory was
consumed.
if (p->mce_vaddr != (void __user *)-1l) {
>> So it should be safe to grab and hold a mutex. See patch below.
>
> The mutex approach looks simpler and safer, so I'm fine with it.
Thanks. Is that an "Acked-by:"?
>> /**
>> * memory_failure - Handle memory failure of a page.
>> * @pfn: Page Number of the corrupted page
>> @@ -1424,12
There can be races when multiple CPUs consume poison from the same
page. The first into memory_failure() atomically sets the HWPoison
page flag and begins hunting for tasks that map this page. Eventually
it invalidates those mappings and may send a SIGBUS to the affected
tasks.
But while all that
On Wed, Jan 20, 2021 at 01:18:12PM +0100, Borislav Petkov wrote:
> On Tue, Jan 19, 2021 at 03:57:59PM -0800, Luck, Tony wrote:
> > But the real validation folks took my patch and found that it has
> > destabilized cases 1 & 2 (and case 3 also chokes if you repeat a few
>
On Tue, Mar 09, 2021 at 08:28:24AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Tue, Mar 09, 2021 at 02:35:34PM +0800, Aili Yao wrote:
> > When the page is already poisoned, another memory_failure() call in the
> > same page now return 0, meaning OK. For nested memory mce handling, this
> > behavior m
On Fri, Feb 05, 2021 at 01:03:18PM -0700, Shuah Khan wrote:
> On 2/5/21 2:58 AM, Greg KH wrote:
> > On Wed, Feb 03, 2021 at 11:11:57AM -0700, Shuah Khan wrote:
> > > +static inline u32 seqnum32_inc(struct seqnum32 *seq)
> > > +{
> > > + atomic_t val = ATOMIC_INIT(seq->seqnum);
> > > +
> > > + seq->
> I have not received any reply from the ia64 maintainers, I assume they were
> both out of office for Christmas.
I'm back in the office ... but have no working ia64 machines, nor time to look
at patches :-(
Should drop me from the MAINTAINTERS file.
-Tony
On Fri, Jan 15, 2021 at 04:27:54PM +0100, Borislav Petkov wrote:
> On Thu, Jan 14, 2021 at 04:38:17PM -0800, Tony Luck wrote:
> > Add a "mce_busy" counter so that task_work_add() is only called once
> > per faulty page in this task.
>
> Yeah, that sentence can be removed now too.
I will update wi
Recovery action when get_user() triggers a machine check uses the fixup
path to make get_user() return -EFAULT. Also queue_task_work() sets up
so that kill_me_maybe() will be called on return to user mode to send a
SIGBUS to the current process.
But there are places in the kernel where the code a
On Fri, Jan 15, 2021 at 12:51:03PM -0800, Luck, Tony wrote:
> static void kill_me_now(struct callback_head *ch)
> {
> + p->mce_count = 0;
> force_sig(SIGBUS);
> }
Brown paper bag time ... I just pasted that line from kill_me_maybe()
and I thought I did a re-compile
On Thu, Jan 21, 2021 at 01:09:59PM -0800, Luck, Tony wrote:
> On Wed, Jan 20, 2021 at 01:18:12PM +0100, Borislav Petkov wrote:
> But, on a whim, I changed the type of mce_count from "int" to "atomic_t" and
> fixeed up the increment & clear to use atomic_inc_return(
On Tue, Jan 26, 2021 at 12:03:14PM +0100, Borislav Petkov wrote:
> On Mon, Jan 25, 2021 at 02:55:09PM -0800, Luck, Tony wrote:
> > And now I've changed it back to non-atomic (but keeping the
> > slightly cleaner looking code style that I used for the atomic
> > version)
On Tue, Jan 05, 2021 at 02:17:41PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 4, 2021 at 5:00 PM Luck, Tony wrote:
> >
> > > I have not received any reply from the ia64 maintainers, I assume they
> > > were
> > > both out of office for Christmas.
> >
> The "Timeout: Not all CPUs entered broadcast exception handler" message
> will appear from time to time given enough systems, but this message does
> not identify which CPUs failed to enter the broadcast exception handler.
> This information would be valuable if available, for example, in order t
On Wed, Jan 06, 2021 at 11:17:08AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 06, 2021 at 06:39:30PM +0000, Luck, Tony wrote:
> > > The "Timeout: Not all CPUs entered broadcast exception handler" message
> > > will appear from time to time given enough systems,
But that's a useful improvement (eliminating the other three sockets on this
system).
Tested-by: Tony Luck
-Tony
Firmware is not required to maintain alignment of SMBIOS entries,
so we should take care accessing fields within these structures.
Use "get_unaligned()" to avoid problems.
Signed-off-by: Tony Luck
---
Ingo: belongs on top of the patches already in x86/mce branch
Found on ia64 (which grumbles abo
When I added support for ACPI5 I made the assumption that
injected processor errors would just need to know the APICID,
memory errors just the address and mask, and PCIe errors just the
segment/bus/device/function. So I had the code check the type of injection
and multiplex the "param1" value appro
When I added support for ACPI5 I made the assumption that
injected processor errors would just need to know the APICID,
memory errors just the address and mask, and PCIe errors just the
segment/bus/device/function. So I had the code check the type of injection
and multiplex the "param1" value appro
> Usage is simple: 1) write a file path to be scanned into the interface,
> and 2) read 64-bit entries, each of which is associated with the page on
> each page index.
Do we have other interfaces that work like that? I suppose this is file is
only open
to "root", so it may be safe to assume that
> (I'm c/c Tony here, as he also shared the same concern that I had on a
> previous feedback about using I2C to talk with the DIMM).
Correct - I've heard the same issues that reads on I2C can be misinterpreted
as writes ... and oops, you have a brick.
What is the larger context/ What problem ar
> NV-DIMM control registers are exposed via i2c, presumably because
> trying to access them through the memory pins would be a giant mess.
> So, one way or another, something needs to be able to initiate
> transactions to access those registers. BIOS will do some initial
> setup, but the OS will n
Mikulas:
>> Here I'm sending some ia64 patches to make it work in the ski emulator.
>> This has been broken for a long time.
Thanks - There are questions from time to time on how to test ia64
for those people who do not have hardware.
Mikael:
> Thanks. I've recently started running 3.x kernels
The following changes since commit dcb99fd9b08cfe1afe426af4d8d3cbc429190f15:
Linux 3.14-rc7 (2014-03-16 18:51:24 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git
tags/please-pull-pstore
for you to fetch changes up to e32634f5d57f1d
+ for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
+ irq = __this_cpu_read(vector_irq[vector]);
+ if (irq >= 0) {
+ desc = irq_to_desc(irq);
+ data = irq_desc_get_irq_data(desc);
+
Randconfig build by Fengguang's robot army reported:
drivers/built-in.o: In function `extlog_print':
>> acpi_extlog.c:(.text+0xcc719): undefined reference to
>> `boot_cpu_physical_apicid'
The config had CONFIG_SMP=n so we picked up this defintion from :
#define cpu_physical_id(cpu)
> Does Itanium permit speculative stores? For example, on Itanium what are
> the permitted outcomes of the following litmus test, where both x and y
> are initially zero?
We have a complier visible speculative read via the "ld.s" and "chk"
instructions. But
there is no speculative write ("st.s")
> So the point we're having a discussion on is if any architecture has
> visible speculative STORES and if there's an architecture that doesn't
> have control dependencies.
>
> On the visible speculative STORES; can, if in the above example we have
> regular loads/stores:
>
> LOAD r1, x
> Where by "May not function correctly" you mean "May crash the system"?
> I'm a little uneasy having this run by default if enabled, even if it's
> disabled by default in the config.
There's also an "either/or" choice between using efi-capsule with pstore, and
the
traditional kexec/kdump metho
> Are there any changes with regards to that, like some enforcement policy
> for BIOS manufacturers to make it right?
I am using a cricket bat to beat BIOS teams that implement eMCA to make
sure they get the labels in SMBIOS right. :-)
It's a non-trivial implementation effort to get all the decod
> Also, I suspect that, if an error happens to affect more than one DIMM
> (e. g. part of the location is not available for a given error),
> that the DIMM label will also not be properly shown.
There are a couple of cases here:
1) There are a number of DIMMs behind some flaky h/w that introduces
> There's also a third case: mirrored memories.
Mirrors are currently something of a mess - we don't get any useful
notification when one breaks.
We do need to fix this - and make sure reporting is properly integrated with
everything else - I'm
just not sure how to do this.
-Tony
--
To unsubscr
> Hmm, that's a good question you raise: but the more important question
> is, do you guys - Gong and Tony - want to replace the logging we're
> already doing, i.e. mce_log() with extlog or not.
Long term ... I'd be happy to see mce_log() go away. But we need to have
a robust, well tested replace
@@ -154,6 +154,10 @@ void mce_log(struct mce *mce)
/* Emit the trace record: */
trace_mce_record(mce);
+ if (mce_ext_err_print)
+ if (mce_ext_err_print(NULL, m.extcpu, i))
+ return;
+
ret = atomic_notifier_call_chain(&x86_mce_decod
>> [56005.785981] {3}physical_address: 0x000851fe
>> [56005.786027] {3}DIMM location: Memriser1 CHANNEL A DIMM 0
>
> Very good guys, I've been waiting for years for this to be possible,
> good job! :-)
It's such a simple goal - I can't believe it took this long to get here :-)
> Btw, what
cper.c contains code to decode and print "Common Platform Error Records".
Originally added under drivers/acpi/apei because the only user was in that
same directory - but now we have another consumer, and we shouldn't have
to force CONFIG_ACPI_APEI get access to this code.
Since CPER is defined in
The following changes since commit 56507694de3453076d73e0e9813349586ee67e59:
EDAC, GHES: Update ghes error record info (2013-10-23 10:11:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
tags/please-pull-move-cper
for you to fetch c
> 1. checking type, id, psi, count and timespec when finding duplicate entries.
> 2. adding count and timestamp for differentiating.
Ah - I was expecting that the backend driver would have a unique "id" for
each record stored ... but is seems that this isn't true for efivars.
I just tried this p
> So, do you mean efivars should fix to use the "id" in a proper way?
It would avoid the need for all these tests, and additions to the filename to
guarantee
uniqueness.
Not sure what options efivars has to create a unique, persistent "id" for each
record. It's a fundamental part of how ERST wo
>> 1. combine timestamp, count and part into "id".
>>for now, in efi-pstore.c, *id = part. and we could simply change it
>>to unique one. F.E. *id = (timestamp * 100 + part) * 100 + count.
>
> My opinion close to 1.
> But, the "*id" should not be the complex one like (timestamp * 100 + part
Sure - the bits there worked once - but have been stale for several releases.
With nobody actively
supporting this things will only get worse.
-Tony
-Original Message-
From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Sent: Tuesday, December 03, 2013 10:13 AM
To: Luck, Tony
> Adjust Kconfig and build logic so that the bad dependency gets avoided.
Has this been exposed to a randconfig test robot? Moving cper.c has already
dropped a few e-mails into my mailbox ... I'm now wary about the corner cases.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe
> Tony, if it is ok with you, I will modify the patch and will not select
> ACPI_LEGACY_TABLES_LOOKUP on IA64, I'm waiting for your final confirmation.
Confirmed. Thanks Peter for catching this.
-Tony
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z�
> > > 1) Handle CPU hot-addition event
> > > 1.a) gather platform specific information
> > > 1.b) associate hot-added CPU with a node
> > > 1.c) create CPU device
> > > 2) User online hot-added CPUs through sysfs:
> > > 2.a) cpu_up()
> > > 2.b) ->try_online_node()
> > > 2.c)
>> The BIOS always sends CPU hot-addition events before memory
>> hot-addition events, so it's hard to change the order.
>> And we couldn't completely solve this performance penalty because the
>> affected code tries to allocate memory for all possible
>> CPUs instead of onlined CPUs.
>
>
The following changes since commit 9a3c4145af32125c5ee39c0272662b47307a8323:
Linux 3.16-rc6 (2014-07-20 21:04:16 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
tags/please-pull-apei
for you to fetch changes up to 594c7255dce7a13cac5
> How about get uptime by get_monotonic_boottime() directly, which's
> the same as /proc/uptime.
I don't know. get_monotonic_boottime() had existed for many releases
at the point the uptime trace clock was added - so it was an available
choice. Maybe not noticed by
Is this function safe to call
- atomic_inc(&mce_entry);
-
I have used this in the past (in conjunction with an external debugger) to
diagnose problems (not all cpus showing up in the machine check handler).
But I suppose these can also be diagnosed from the "Timeout synchronizing ..."
message from mce_timed_out() [thoug
> I mean, does the machine even recover after some of the cores have gone
> into the weeds in #MC? Provided, of course, we don't have a no-way-out
> MCE and we can resume execution.
I doubt there is any hope for recovery if not all processors show up ... things
have to be already very broken for t
> Another problem, maybe we should use get_jiffies_64() instead of jiffies
> directly here OR we'll meet wraparound problems on 32bit system. But a
> same problem is that the jiffies_lock is not safe in NMI context...
To quote Winnie the Pooh - "Bother".
Can someone think of a clever way to get a
>All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It
>is changed from sizeof(unsigned long) to sizeof(unsigned long long).
>By investigation, 64bit Linux kernel build is LP64 compliant, i.e.,
>sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to
>
> - a bitmap based matrix vector allocator, but that shouldn't be rocket
> science to write one.
Not rocket science - but some tricky corner cases to make sure all the
allocations will fit. MSI needs blocks of irqs that start on a power-of-two
boundary so the h/w can just fiddle with low order
When we suspend a laptop we offline all but one processor. But
the mce code registers on a notify chain so it can clean up
some sysfs entries. Part of that code calls device_unregister()
which will fire kobject_uevent() which might wake up some user
code that is watching for such things.
Patch bel
The "uptime" tracer added in:
commit 8aacf017b065a805d27467843490c976835eb4a5
tracing: Add "uptime" trace clock that uses jiffies
has wraparound problems when the system has been up more
than 1 hour 11 minutes and 34 seconds. It converts jiffies
to nanoseconds using:
(u64)jiffies_to
>> Btw, this driver is polling, AFAICT. Doesn't e3-12xx support the CMCI
>> interrupt which you can feed into this driver directly and thus not need
>> the polling at all?
>
> On the system with the ce and ue events that I'm testing on, I don't see
> 'MCE' nudge above 0, in /proc/interrupts. So I t
>> Why not put it into sb_edac - it is small enough and if you're lucky,
>> you might even share functionality?
>
> By quickly looking at the driver (sorry Jason, no proper review yet :( )
> it's a very different beast. Tony, any insights on why?
The E3-12xx processors connect out to a different (
> Unfortunately, the box reporting the ue errors just went into transit (so
> that I can better examine this issue), so I will probably not be able to
> run this experiment on that specific box until next week.
Do you have any other logs from this machine. Is there something
logged in one (or mor
> So when the driver sees uncorrected errors, I'm also seeing them in my
> memory scanning program - so they correspond nicely. I didn't see anything
> logged in /var/log/mcelog, but I will update to the latest when possible.
I wonder if there are some BIOS options to enable reporting via CMCI/MCE
> Even though those nvram devices are fragile and can only stomach a
> limited amount of writes, wouldn't it be a nifty feature to have a
> kernel cmdline param of the sort "put_dmesg_in_nvram_this_one_time_only"
> which logs to nvram only once for debugging purposes.
Speed is also a factor ... wa
> (1) The backend (ramoops) provides servel memory regions staticly. Each region
> is a ring buffer, which does not connect with certain PSTORE_TYPE_ID. So no
> one
> can modify or use it before allocation.
>
> (2) A pstore user allocs a memory region, pstore will return a pstore_type_id.
>
>
> BTW, I note that "extern struct pstore_info *psinfo" locates in
> fs/pstore/internal.h. So users out of directory "fs/pstore/" can not use
> pstore to
> record messages. We do not want other kernel users to use pstore, right? And
> can we
> break this?
Yes we can make some interface visible t
>> There's a logbuf_lock in printk. If logbuf_lock is held by other cpu,
>> it'll lead to an infinity spin here. Isn't it?
>
> Yes, but we want to take the risk and print something out before the
> machine dies instead of waiting to get into printk-safe context first
> and maybe corrupt state.
Not
>> Not all machine checks are fatal - it would be bad for us to go into
>> an infinite spin instead of executing the recovery code.
>
> Then for the time being extlog shouldn't hook into the decoder chain
> but into mce_process_work, i.e. the last should call it. Or maybe add
> another notifier whi
The following changes since commit 4d4c9cc839a308be3289a361ccba4447ee140552:
tracing: Add __field_struct macro for TRACE_EVENT() (2014-06-21 00:18:42
-0400)
[Note this base commit was pulled by Linus between 3.16-rc2 and -rc3]
are available in the git repository at:
git://git.kernel.org/pu
> The CMCI storm handler previously called cmci_reenable() when exiting a
> CMCI storm. However, when entering a CMCI storm the bank ownership was
> not relinquished by the affected CPUs. The CMCIs were only disabled via
> cmci_storm_disable_banks(). The handler was updated to instead call a
> new
501 - 600 of 1172 matches
Mail list logo
