similar to: Divide error in kvm_unlock_kick()

Chris Webb <chris at arachsys.com> wrote: > My CPU flags inside the crashing guest look like this: > > fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush > mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl > extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt aes xsave > avx f16c hypervisor lahf_lm

Chris Webb <chris at arachsys.com> wrote: > My CPU flags inside the crashing guest look like this: > > fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush > mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl > extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt aes xsave > avx f16c hypervisor lahf_lm

Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 29/05/2014 19:45, Chris Webb ha scritto: >> Chris Webb <chris at arachsys.com> wrote: >> >>> My CPU flags inside the crashing guest look like this: >>> >>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >>> mmx fxsr sse sse2 ht syscall nx mmxext

Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 29/05/2014 19:45, Chris Webb ha scritto: >> Chris Webb <chris at arachsys.com> wrote: >> >>> My CPU flags inside the crashing guest look like this: >>> >>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >>> mmx fxsr sse sse2 ht syscall nx mmxext

Il 29/05/2014 19:45, Chris Webb ha scritto: > Chris Webb <chris at arachsys.com> wrote: > >> My CPU flags inside the crashing guest look like this: >> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >> mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl >> extd_apicid pni pclmulqdq ssse3 fma cx16

Even though Doug's out of the office, I'm submitting a patch to the ifcpu[|64].c32 COMBOOT32 modules for testing. Also available for perusal with a web browser at: http://git.zytor.com/?p=users/sha0/syslinux.git;a=commitdiff;h=cc70d0fa5 5e35fabf250f4dccbaed2fa44f56da7 - Shao Miller --- >From cc70d0fa55e35fabf250f4dccbaed2fa44f56da7 Mon Sep 17 00:00:00 2001 From: Shao

Hi all, Does Xen dom0 mask CPU flags or what? I execute "cat /proc/cpuinfo" on bare-metal linux ,and get: +------------------------------------------------------------------------------------------------- | | flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 | clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm | 3dnowext

I had a series of kernel hardware error reports today while I was away from my computer: Message from syslogd at fcshome at Aug 12 10:12:24 ... kernel:[Hardware Error]: MC2 Error: VB Data ECC or parity error. Message from syslogd at fcshome at Aug 12 10:12:24 ... kernel:[Hardware Error]: Error Status: Corrected error, no action required. Message from syslogd at fcshome at Aug 12 10:12:24 ...

Hi, I was womdering, if anyone has experienced the same issues. When I run the tests after compiling 2.3.5, the following 4 tests fail: http payload echo (ssl): sequential .................................. : ok http payload echo (ssl): pipeline .................................... : ok http payload echo (ssl): parallel .................................... : FAILED: Test is hanging http payload

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/thread.html#30694 I made a few changes in v2 but overall decided to keep the now unused gcaps_arch_min_version capability. This doesn't preclude removing it in future if we think it's never going to be useful. I changed patch 1 so that to remove the long comment about how the field is used, anticipating the

LKP framework can guarantee that all the software environment are same on AMD and INTEL platform. INTEL platform always work well, after revert this patch, AMD works well. we tried below commit on AMD. 1) 25de7691a0e27c29c8d783a22373cc265571f5e9: bad 2) a82235843b102202766115e10003c9465a8b83ae: good the error logs(build/CMakeFiles/CMakeError.log) has no difference b/w 1) and 2) on AMD platform

Hi we observed that below errors occur on AMD platform since 25de7691a0e27c29c8d783a22373cc265571f5e9 root at lkp-opteron1 /opt/rootfs/llvm_project/src/build# cmake -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/opt/cross/ -- clang project is enabled -- clang-tools-extra project is disabled -- compiler-rt project is disabled

On Tue, Sep 18, 2018 at 09:52:26AM +0200, Thomas Gleixner wrote: > On Mon, 17 Sep 2018, John Stultz wrote: > > On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski <luto at kernel.org> wrote: > > > Also, I'm not entirely convinced that this "last" thing is needed at > > > all. John, what's the scenario under which we need it? > > > > So

On Tue, Sep 18, 2018 at 09:52:26AM +0200, Thomas Gleixner wrote: > On Mon, 17 Sep 2018, John Stultz wrote: > > On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski <luto at kernel.org> wrote: > > > Also, I'm not entirely convinced that this "last" thing is needed at > > > all. John, what's the scenario under which we need it? > > > > So

On Tue, 18 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > Your memory serves you right. That's indeed observable on CPUs which > > > lack TSC_ADJUST. > > > > But, if the gtod code can observe this, then why doesn't the code that > > checks the sync? > > Because it depends where the involved CPUs are in the

On Tue, 18 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > Your memory serves you right. That's indeed observable on CPUs which > > > lack TSC_ADJUST. > > > > But, if the gtod code can observe this, then why doesn't the code that > > checks the sync? > > Because it depends where the involved CPUs are in the

Hello, I made an interesting observation related to the "Clocksource tsc unstable (delta = -2999660320319 ns)" problem. In the log of ntpd I found: Oct 5 03:46:35 greenville-dom0 ntpd[4020]: kernel time sync status change 6001 Oct 5 04:03:41 greenville-dom0 ntpd[4020]: kernel time sync status change 2001 Oct 5 05:29:03 greenville-dom0 ntpd[4020]: kernel time sync status change

Hello everybody, First a big thanks for tinc-vpn I am still using it next to wireguard and openvpn. I am having a setup where the tinc debian appliance is at 100% cpu load doing about 7.5MB/s. Compression = 9 PMTU = 1400 PMTUDiscovery = yes Cipher = aes-128-cbc How can I pick a cipher that is the fasted for my CPU and don't create a CPU bottleneck at 100%. Kind regards, Jelle de Jong

On 06/13/2013 10:11 PM, Michael Giardino wrote: > Hi, > > I'm running libvert on a Debian 7 system. I have upgraded libvert and qemu > from source (v1.06 and 1.5.0 respectively) and the problem persists. The > guest OS is also a Debian 7 system running a non-SMP kernel. The error > message from virt-manager is > > Error starting domain: unsupported configuration:

Intel recently release a new tsc adjust feature at latest SDM 17.13.3. CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported. Basically it is used to simplify TSC synchronization, operation of IA32_TSC_ADJUST MSR is as follows: 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0; 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts) value X from the