Re: Hyper-V protection fault trap on i386 with 5.9
On Mon, Jul 25, 2016 at 10:59:45AM +0200, Franco Fichtner wrote: > > > On 22 Jul 2016, at 7:58 PM, Mike Larkin wrote: > > > > What is your Hyper-V server host environment? Server 2012 R2? And I > > need a full dmesg from when this worked, please. > > It's a Windows Server 2012 Datacenter Hyper-V failover cluster, controlled > by System Center 2012 Virtual Machine Manager. All of it is up-to-date as > of July 2016. > > Will a dmesg of a patched (bootable) 5.9 suffice or should it be the 5.7 one? > > > Cheers, > Franco > Server 2012 or Server 2012 R2? I just tested both Server 2012 R2 and Windows 10 client Hyper-V on -current, and both worked without any problem (OpenBSD-current i386). -ml
Re: Hyper-V protection fault trap on i386 with 5.9
> On 22 Jul 2016, at 7:58 PM, Mike Larkin wrote: > > What is your Hyper-V server host environment? Server 2012 R2? And I > need a full dmesg from when this worked, please. It's a Windows Server 2012 Datacenter Hyper-V failover cluster, controlled by System Center 2012 Virtual Machine Manager. All of it is up-to-date as of July 2016. Will a dmesg of a patched (bootable) 5.9 suffice or should it be the 5.7 one? Cheers, Franco
Re: Hyper-V protection fault trap on i386 with 5.9
On Fri, Jul 22, 2016 at 03:26:01PM +0200, Franco Fichtner wrote: > Hi, > > With a client we're running into the following boot panic > since upgrading from 5.7 to 5.9 on a specific Hyper-V guest: > > cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz > cpu0: > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF > LUSH,MMX,FXSR,SSE,SSE2,SS,HTT,NXE,LONG,SSE3,SSSE3,CX16,SSE5.1,XSAVE,HV,LAHF > [...] > kernel: protection fault trap, code=0 > Stopped at cpu_paenable+0x20: movl %edi,%cr3 > > This happens consistently, but we have other clients that > run Hyper-V without a problem on 5.9 now. > > Looking for a clue I dug through the commits and found that > reviving pmap_bootstrap_pae() in April 2015 caused this, and > reverting boots said Hyper-V guest just fine. > > Hyper-V is on the latest version and we could not find a > reason why said guest / host pair behaves that way. > > I have two questions: > > (1) Since NX/PAE is pretty much standard on all hardware from > the last +15 years and is now used to enforce W^X, are there > going to be problems *not* running that code either now or in > the future? > > (2) Could this be something to be fixed in the i386 assembler > code in cpu_paenable? > > It's difficult to get dumps / screen caps from the system or > run commands in ddb, but if there's interest I will try to > provide the requested info. > > > Cheers, > Franco Certainly odd. I'll try to reproduce this (since I was the one who brought PAE/NX back into the i386 picture last year). It should work fine (this is the first report I've seen about crashing there). What is your Hyper-V server host environment? Server 2012 R2? And I need a full dmesg from when this worked, please. It's also possible this is a Hyper-V bug. We've seen those as well and had to work around them also. -ml
Hyper-V protection fault trap on i386 with 5.9
Hi, With a client we're running into the following boot panic since upgrading from 5.7 to 5.9 on a specific Hyper-V guest: cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,MMX,FXSR,SSE,SSE2,SS,HTT,NXE,LONG,SSE3,SSSE3,CX16,SSE5.1,XSAVE,HV,LAHF [...] kernel: protection fault trap, code=0 Stopped at cpu_paenable+0x20: movl %edi,%cr3 This happens consistently, but we have other clients that run Hyper-V without a problem on 5.9 now. Looking for a clue I dug through the commits and found that reviving pmap_bootstrap_pae() in April 2015 caused this, and reverting boots said Hyper-V guest just fine. Hyper-V is on the latest version and we could not find a reason why said guest / host pair behaves that way. I have two questions: (1) Since NX/PAE is pretty much standard on all hardware from the last +15 years and is now used to enforce W^X, are there going to be problems *not* running that code either now or in the future? (2) Could this be something to be fixed in the i386 assembler code in cpu_paenable? It's difficult to get dumps / screen caps from the system or run commands in ddb, but if there's interest I will try to provide the requested info. Cheers, Franco