Hi Pat
Thanks for your suggestions.

confirmed memory is 2048MB
tried numa=off
confirmed virtio and qxl
confirmed BIOS is F8

I'll try resetting BIOS and doing a memory test over the weekend.

I have an SL7.5 guest which I am setting up with Kolab, so I will probably switch to that soon and ditch SL6.9

Thanks again for spending time on this.
Cheers
Bill
 
-----Original message-----
> From:Pat Riehecky <[log in to unmask]>
> Sent: Friday 25th May 2018 6:11
> To: Bill Maidment <[log in to unmask]>; [log in to unmask]
> Subject: Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> Hmmmm.... this error seems to point to a memory/instruction mapping 
> issue.....
> 
>   Do you have a base8 amount of RAM in the VMs?
>   Can I have you try adding 'numa=off' to the boot line?
>   Are things using virtio/qxl/etc?
> 
> 
> While I doubt this is it, you may want to be sure you've got the F8 
> bios[1].  If you can I'd consider setting the values back to defaults 
> and then re-activating the hardware VM acceleration after that.
> 
> Pat
> 
> [1] https://www.gigabyte.com/Motherboard/GA-990FXA-D3-rev-1x#support-dl-bios
> 
> On 05/24/2018 12:40 AM, Bill Maidment wrote:
> > Hi Pat
> > The full error message is:
> > PANIC: early exception 0d rip 10:ffffffff810462b6 error 0 cr2 0
> >
> > These are my specs:
> >
> > Mobo GA-990FXA-D3
> > CPU AMD FX-8120
> > Host 8 CPU 16GB RAM running SL 7.5 with kernel 3.10.0-862.3.2
> > Guest 2 CPU 2GB RAM running SL 6.9 with kernel 2.6.32.30.1
> > 5 other guests running SL 7.5 with kernel 3.10.0-862.3.2 run OK
> >
> > SL 6.9 kernel re-installed but still the same error
> > previous kernel 2.6.32-696.28.1 runs OK
> >
> > The SL 6.9 machine is my internal mail server running zarafa and mysql
> >
> > Is there anything else you need to know?
> >
> > Cheers
> > Bill
> >
> >   
> >   
> > -----Original message-----
> >> From:Pat Riehecky <[log in to unmask]>
> >> Sent: Wednesday 23rd May 2018 23:25
> >> To: Bill Maidment <[log in to unmask]>; [log in to unmask]
> >> Subject: Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL6.x i386/x86_64
> >>
> >> Hi Bill,
> >>
> >> Our internal test VMs are KVM guests on SL 6.9 with an AMD server. I'm
> >> not seeing this problem there.
> >>
> >> Are there any more details you can share?
> >>
> >> Pat
> >>
> >> On 05/22/2018 09:20 PM, Bill Maidment wrote:
> >>> Hi
> >>> The new kernel caused
> >>> PANIC early exception 0d 10 ..... error 0 rc2
> >>> on a KVM SL 6.9 x86_64 guest
> >>> AMD server and all other guests running SL7.5 are all runn ing OK on their new kernel
> >>>
> >>> Reverting to the previous SL 6.9 kernel gave me back my guest machine
> >>> Cheers
> >>> Bill
> >>>     
> >>>     
> >>> -----Original message-----
> >>>> From:Scott Reid <[log in to unmask]>
> >>>> Sent: Wednesday 23rd May 2018 4:33
> >>>> To: [log in to unmask]
> >>>> Subject: Security ERRATA Important: kernel on SL6.x i386/x86_64
> >>>>
> >>>> Synopsis:          Important: kernel security and bug fix update
> >>>> Advisory ID:       SLSA-2018:1651-1
> >>>> Issue Date:        2018-05-22
> >>>> CVE Numbers:       CVE-2018-3639
> >>>> --
> >>>>
> >>>> Security Fix(es):
> >>>>
> >>>> * An industry-wide issue was found in the way many modern microprocessor
> >>>> designs have implemented speculative execution of Load & Store
> >>>> instructions (a commonly used performance optimization). It relies on the
> >>>> presence of a precisely-defined instruction sequence in the privileged
> >>>> code as well as the fact that memory read from address to which a recent
> >>>> memory write has occurred may see an older value and subsequently cause an
> >>>> update into the microprocessor's data cache even for speculatively
> >>>> executed instructions that never actually commit (retire). As a result, an
> >>>> unprivileged attacker could use this flaw to read privileged memory by
> >>>> conducting targeted cache side-channel attacks. (CVE-2018-3639)
> >>>>
> >>>> Note: This issue is present in hardware and cannot be fully fixed via
> >>>> software update. The updated kernel packages provide software side of the
> >>>> mitigation for this hardware issue. To be fully functional, up-to-date CPU
> >>>> microcode applied on the system is required.
> >>>>
> >>>> In this update mitigations for x86 (both 32 and 64 bit) architecture are
> >>>> provided.
> >>>>
> >>>> Bug Fix(es):
> >>>>
> >>>> * Previously, an erroneous code in the x86 kexec system call path caused a
> >>>> memory corruption. As a consequence, the system became unresponsive with
> >>>> the following kernel stack trace:
> >>>>
> >>>> 'WARNING: CPU: 13 PID: 36409 at lib/list_debug.c:59
> >>>> __list_del_entry+0xa1/0xd0 list_del corruption. prev->next should be
> >>>> ffffdd03fddeeca0, but was (null)'
> >>>>
> >>>> This update ensures that the code does not corrupt memory. As a result,
> >>>> the operating system no longer hangs.
> >>>> --
> >>>>
> >>>> SL6
> >>>>      x86_64
> >>>>        kernel-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-debug-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debug-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debug-devel-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debuginfo-common-x86_64-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-devel-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        kernel-headers-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        perf-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        python-perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>        python-perf-2.6.32-696.30.1.el6.x86_64.rpm
> >>>>      i386
> >>>>        kernel-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debug-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-devel-2.6.32-696.30.1.el6.i686.rpm
> >>>>        kernel-headers-2.6.32-696.30.1.el6.i686.rpm
> >>>>        perf-2.6.32-696.30.1.el6.i686.rpm
> >>>>        perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
> >>>>        python-perf-2.6.32-696.30.1.el6.i686.rpm
> >>>>      noarch
> >>>>        kernel-abi-whitelists-2.6.32-696.30.1.el6.noarch.rpm
> >>>>        kernel-doc-2.6.32-696.30.1.el6.noarch.rpm
> >>>>        kernel-firmware-2.6.32-696.30.1.el6.noarch.rpm
> >>>>
> >>>> - Scientific Linux Development Team
> >>>>
> >>>>
> >> -- 
> >> Pat Riehecky
> >>
> >> Fermi National Accelerator Laboratory
> >> www.fnal.gov
> >> www.scientificlinux.org
> >>
> >>
> 
> -- 
> Pat Riehecky
> 
> Fermi National Accelerator Laboratory
> www.fnal.gov
> www.scientificlinux.org
> 
>