Re: port-amd64/52596

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

On Wed, Oct 11, 2017 at 04:50:16PM +0900, Masanobu SAITOH wrote:
> Hi, Dominik.
> 
> On 2017/10/11 6:40, 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: gnats-bugs%NetBSD.org@localhost
> > Cc: port-amd64-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
> > 	netbsd-bugs%netbsd.org@localhost, dmb%yenn.ulegend.net@localhost
> > Subject: Re: port-amd64/52596
> > Date: Tue, 10 Oct 2017 23:36:38 +0200
> > 
> >   On Tue, Oct 10, 2017 at 08:50:01PM +0000, coypu%sdf.org@localhost wrote:
> >   > The following reply was made to PR port-amd64/52596; it has been noted by GNATS.
> >   >
> >   > From: coypu%sdf.org@localhost
> >   > To: gnats-bugs%netbsd.org@localhost
> >   > Cc:
> >   > Subject: Re: port-amd64/52596
> >   > Date: Tue, 10 Oct 2017 20:48:28 +0000
> >   >
> >   >  Hi,
> >   >
> >   >  NetBSD should be doing the following thing almost constantly:
> >   >  if (x86_xsave_features != 0) {
> >   >  	xsave()
> >   >
> >   >  which for your machine can be read as:
> >   >  if (x86_xsave_features != 0) {
> >   >  	panic("complain about xsave")
> >   >
> >   >  x86_xsave_features is only written to at boot.
> >   >  If it doesn't panic instantly, something is likely corrupting its value.
> >   >
> >   >  The ACPI functions are unrelated, it's silly about what the last
> >   >  function it prints at a backtrace is (it's after vpanic).
> >   >
> >   >  With DEBUG/DIAGNOSTIC and some other options you might have a chance of
> >   >  tracking down the cause too
> >   >
> >   >  can you share a kernel that caused this panic?
> >   >
> >   https://yenn.ulegend.net/~dmb/crash/
> >   But just now I've noticed in the dmesg:
> >   WARNING: 2 errors while detecting hardware; check system log.
> 
> This two are from:
> 
> > acpicpu0: failed to set frequency to 1800 (err 35)
> > acpicpu0: failed to set frequency to 1800 (err 35)
> 
> These two were from trying to set cpu frequency to 1800 in acpicpu_pstate_set().
> 
> > acpicpu0 at cpu0: ACPI CPU
> > acpicpu0: C1: HLT, lat   0 us, pow     0 mW
> > acpicpu0: P0: FFH, lat 100 us, pow 25000 mW, 2100 MHz
> > acpicpu0: P1: FFH, lat 100 us, pow 22902 mW, 2000 MHz
> > acpicpu0: P2: FFH, lat 100 us, pow 19027 mW, 1800 MHz <====== This one.
> > acpicpu0: P3: FFH, lat 100 us, pow  8523 mW, 1000 MHz
> > acpicpu0: T0: I/O, lat   1 us, pow     0 mW, 100 %
> 
> I don't know why this error happened.
> This problem is not related to the first panic, but I'd like to know
> why this error occurred. Could you show put the output of
> "acpidump -dt" to the same location? (~dmb/crash)
> 
yenn# acpidump -dt
acpidump: Can't find ACPI information

O_O I don't know what's happening, but as I said, NetBSD 6
worked with ACPI 3, but NetBSD 8 was rebooting just when
the bootloader was starting the kernel, so I switched
to ACPI 2 in the BIOS setup, and this looked like working OK.

I'll also try to poke around the CPU settings in BIOS,
because it might be that there is just a bug in the BIOS.

>  Thanks in advance.
> 
> 
> >   so might be that something is dying in the hardware...
> >   Also, the panic in the dmesg (from today) is unrelated,
> >   as it was after applying the patch from this PR --
> >   the load was increasing for a few hours until like 250,
> >   and then that panic happened.
> >   Hardware problem is possible, but it would be a funny
> >   coincidence, since it started at the time of the upgrade
> >   from NetBSD 6 to NetBSD 8.
> >   I'll bring it down tomorrow and run memtest86+
> >   Dominik
> > 
>