similar to: Reentrant NMIs, MCEs and interrupt stack tables.

xen/arch/x86/crash.c | 116 ++++++++++++++++++++++++++++++++++----- xen/arch/x86/machine_kexec.c | 19 ++++++ xen/arch/x86/x86_64/entry.S | 34 +++++++++++ xen/include/asm-x86/desc.h | 45 +++++++++++++++ xen/include/asm-x86/processor.h | 4 + 5 files changed, 203 insertions(+), 15 deletions(-) Experimentally, certain crash kernels will triple fault very early

I have an Intel e1000e NIC which I put into passthrough for an HVM domain under Xen 4.2. All the corresponding hardware protections are enabled on my system (DMA + Interrupt remapping), however, once in a while I get a SERR NMI in dom0 (NMI - PCI sys error (SERR) in xl dmesg). I am wondering about its exact reason. I am thinking in the following way: [+] Under Intel VT-x, interrupts are

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

Howdy folks, this email is a follow-on to a 3-month-old thread about kernel page faults from the bce driver[0]. 0: http://lists.freebsd.org/pipermail/freebsd-stable/2013-March/072713.html Sorry to revive such an old thread, but a couple of bits of new information has come to light here that may be useful for others. The header splitting suggestion that Marius Strobl made[1] did fix the kernel

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

I am working with some survival data with missing values. I am using the mice package to do multiple imputation. I have found code in this thread which handles pooling of the MI results: https://stat.ethz.ch/pipermail/r-help/2007-May/132180.html Now I would like to plot a survival curve using the pooled results. Here is a reproducible example: require(survival) require(mice) set.seed(2) dt

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the > vCPU when it reaches IRET. This patch is overcomplicated IMO. Just do the magic incantation in C from do_nmi or from here: /* * For ease of testing, unmask

R-helpers: I have a dataset that has 168 subjects and 12 variables. Some of the variables have missing data and I want to use the multiple imputation capabilities of the "mice" package to address the missing data. Given that mice only supports linear models and generalized linear models (via the lm.mids and glm.mids functions) and that I need to fit Cox models, I followed the previous

I have recently upgraded to 2.6.18-194.3.1.el5 and within several days the machine crashed with the following error (repeating in mcelog): MCE 0 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 2 BANK 8 MISC 41 MCG status: MCi status: Error overflow Uncorrected error MCi_MISC register valid Processor context corrupt MCA: MEMORY CONTROLLER AC_CHANNEL0_ERR

Hi everyone, Does anyone here has experience using MICE to impute missing value? I am having problem to pool the imputed dataset for a MANOVA test, could you give me some advice please? Here is my code: > library(mice) >

Intercept guest reads of MSR_IA32_MCG_CAP and limit the number of memory banks reported to one. This prevents us from trying to read status of non-existent banks when migrated to a machine with fewer banks. Signed-off-by: Ben Guthro Signed-off-by: David Lively <dlively@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, i build mysql (currently v5.0.22) on OSX 10.4.7 w/ threading enabled. i.e., i build the reentrant libs: libmysqlclient_r.dylib rather than the 'usual': libmysqlclient.dylib currently, to make Dovecot 'play nice' and recognize the reentrant libs, I: perl -pi -e

Dear alltogether, I experience very strange behavior of imputation of NA's with the NORM library. I use R 2.2.0, win32. The code is below and the same dataset was also tried with MICE and aregImpute() from HMISC _without_ any problem. The problem is as follows: (1) using the whole dataset results in very strange imputations - values far beyond the maximum of the respective column, >

Hi, I've seen that this commit never got MFC'd: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/realpath.c?rev=1.14&content-type=text/x-cvsweb-markup Would it be possible to do that or are there any objections out there ? Martin Martin Blapp, <mb@imp.ch> <mbr@FreeBSD.org> ------------------------------------------------------------------ ImproWare AG, UNIXSP

Hi Folks: I run into a problem when enabling Xen in next generation server platforms with Xen c/s is 21380. Xen reported "CPU Not responding" when booting up 32 CPUs( 2 sockets with 8 cores/16threads total). The log files belonging showed something wrong with APCI. So I added x2apic=0 in the xen grub line, but the symptom remained. However, Native RHEL5.5 can

Hi, I''ve not tried pv_ops for a long time but just got a new system (Supermicro X9DRL-iF) so decided to try 3.5.0 with the latest Xen 4.2-unstable, unfortunately the system crashes immediately after loading dom0: traps.c:486:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] I''ve tried loading both bzImage and vmlinuz (gzip compressed vmlinuz) with the same

I don't know if __thread is well-supported enough on compilers to use in LLVM core code. LLVM has its own support class: ThreadLocal http://llvm.org/doxygen/classllvm_1_1sys_1_1ThreadLocal.html And if randr_r() is obsolete, I'm not sure we should be using it. What platforms have you tested this on? Is it available on Windows, Mac, BSDs? If not touching global state is important

If we're keeping the state locally now, perhaps we should store it in a per-thread variable. I know rand() isn't thread safe to begin with, but it seems like rand_r() can be since it should keep no external state. On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Dear all, > > In our LLVM-based compiler pipeline a major part of code

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at