Re: port-amd64/52596 (Another netbsd-8 panic)

[Dominik Bialy <dmb%yenn.ulegend.net@localhost>]

On Thu, Oct 12, 2017 at 06:15:01AM +0000, Dominik Bialy wrote:
> The following reply was made to PR port-amd64/52596; it has been noted by GNATS.
> 
> From: Dominik Bialy <dmb%yenn.ulegend.net@localhost>
> To: coypu%sdf.org@localhost
> Cc: Dominik Bialy <dmb%yenn.ulegend.net@localhost>, gnats-bugs%NetBSD.org@localhost
> Subject: Re: port-amd64/52596 (Another netbsd-8 panic)
> Date: Thu, 12 Oct 2017 08:14:19 +0200
> 
>  On Thu, Oct 12, 2017 at 12:18:29AM +0000, coypu%sdf.org@localhost wrote:
>  > Complete shot in the dark, this is an errata workaround for similar
>  > AMD machines:
>  > 
>  > The SWAPGS instruction fails to cause an input dependency on the GS
>  > segment register. If the GS segment register has been recently
>  > changed via a MOV or POP segment register instruction, SWAPGS may
>  > incorrectly save the old value of GS base into the KernelGSbase MSR.
>  > 
>  > Index: arch/amd64/amd64/locore.S
>  > ===================================================================
>  > RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v
>  > retrieving revision 1.131
>  > diff -u -r1.131 locore.S
>  > --- arch/amd64/amd64/locore.S	30 Sep 2017 11:43:57 -0000	1.131
>  > +++ arch/amd64/amd64/locore.S	12 Oct 2017 00:12:08 -0000
>  > @@ -1165,6 +1165,7 @@
>  >  	CLI(cx)
>  >  	SWAPGS
>  >  	movw	%ax,%gs
>  > +	mfence
>  >  	SWAPGS
>  >  	STI(cx)
>  >  
>  > @@ -1199,6 +1200,7 @@
>  >  	CLI(ax)
>  >  	SWAPGS
>  >  	movw	TF_GS(%rbx),%gs
>  > +	mfence
>  >  	SWAPGS
>  >  	STI(ax)
>  >  #else
>  > 
>  I remembered today, that while doing the upgrade to -8,
>  I also enabled some AMD PowerNow settings in the BIOS.
>  Yesterday I toggled them off, enabled ACPI 3.0, and
>  it booted OK, and now has ~20 hours uptime.
>  
>  I have a theory that these settings were causing some
>  CPU instability.
>  
>  Now there's no warning in the dmesg about errors in
>  setting CPU frequency.
>  
>  I'm planning to see if it can keep 2 weeks of uptime,
>  because the farthest it went so far was 13 days, and let
>  you know. OK?
>  
>  Dominik
>  

Please close this one.

It was apparently caused by a setting in the BIOS setup,
devoted for single core CPU's, which I mistakenly enabled
just before the upgrade to NetBSD-8. Of course the CPU
is dual-core, so it was causing this instability.

Now the uptime is 15 days, and everything looks OK.  Before,
it was panicing 2-3 times a day.

Thank you for your interest, it is great to have such responsive
developers.

And I apologise for this false positive.

Thank you,
	Dominik