> The stack trace would help.  This is probably a kernel issue; Gentoo may
> have enabled a little-used feature and it may not work correctly under
> coreboot.  Need the trace to debug further.

Completely on the same page with Timothy. Without the logs nothing could be achieved. Please, could you post the logs?

I will give you couple of hints. You should have in GRUB both gentoo and Fedora kernels (I am using Fedora for years, and completely switched two months ago to Fedora 25 (today, it comes out as Final Release). Even I am experimenting with rawhide (soon to be Fedora 26, with kernels 4.9.0 rc5 x86_64).

Here: when your gentoo kernel crashes, while rebooting, please, switch to Fedora kernel, bring it up, and do the following:
journalctl -b -1 (latest log to shutdown).

For education: https://wiki.archlinux.org/index.php?title=Systemd&redirect=no#Journal

I would like also to peak in them/latest gentoo logs (with Ooooops). ;-)

Thank you,
Zoran

On Mon, Nov 21, 2016 at 5:04 PM, Timothy Pearson <tpearson@raptorengineering.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/20/2016 01:29 PM, Taiidan@gmx.com wrote:
> I have tried booting with multiple gentoo kernels but every time it
> either hangs on amd_pmu_init ("amd performance counters") with a stack
> trace or simply black screens and reboots quickly.

The stack trace would help.  This is probably a kernel issue; Gentoo may
have enabled a little-used feature and it may not work correctly under
coreboot.  Need the trace to debug further.

>
> + (if anyone knows) How come I have to run fancontrol/pwmconfig to get
> the fans to slow down? The proprietary bios had the same issue until I
> found an option for "whisper" fan control mode.

The KGPE-D16 is a server board; as such, it is appropriate to set fans
to full speed until the OS-based thermal management controls can take
over.  Without this feature, a system that overheated (e.g. if fans were
set to a low RPM incorrectly) may either get stuck in a reboot loop or
power down entirely in a remote location.  Needless to say, requiring
physical intervention over this type of fault is undesirable in a server
system.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYMxrwAAoJEK+E3vEXDOFbDNYH/RsdQpFNUgioa7GRuL49Zddf
48P+RpeB15RnuQq1D+8DzaI2oTEpfTRVK9IvRoHKFpCF8LmAPaBBzYqTCDlyqYCn
TlV6OCUClhL3L7uOElvj1lZQYU+rwrCxvqHxbYOhi2dMovsx6JBGnLdyash5IO7S
8bNnNzdQQ+vWqB+MeD5xUTo+4jFS1U1j8jMbPicOwAtizPgnB9eLjYhTcKRe0sZg
Elvvm8g9gTBIAb+JkDs2WAkKN3g4MLYiR/ShgJ3Bhk7tM3Qeh0DTmO7RyLG3M4eT
JI7pGrh+85pAttgDIUrf3sTmLGubUSn5D3yFeJ3u8uGOJDXcnxuCzx8IGE9jDr0=
=khHr
-----END PGP SIGNATURE-----

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot