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