Bug 214718 - x86bios panics at boot if it cannot obtain memory
Summary: x86bios panics at boot if it cannot obtain memory
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-21 20:07 UTC by Ed Maste
Modified: 2019-01-21 19:44 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2016-11-21 20:07:36 UTC
Due to an LLD issue (http://llvm.org/pr30891) my kernel was linked at 0x1000, not 0x200000, meaning that no < 640K memory was available when the system started up. In this case x86bios panics on boot, because it does an M_WAITOK allocation when it is not permissible:


ACPI APIC Table: <OVMF   OVMFEDK2>
panic: vm_wait in early boot
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff81e0ca40
vpanic() at vpanic+0x182/frame 0xffffffff81e0cac0
panic() at panic+0x43/frame 0xffffffff81e0cb20
vm_wait() at vm_wait+0xd6/frame 0xffffffff81e0cb40
kmem_alloc_contig() at kmem_alloc_contig+0x1bd/frame 0xffffffff81e0cc00
contigmalloc() at contigmalloc+0x33/frame 0xffffffff81e0cc40
x86bios_modevent() at x86bios_modevent+0x244/frame 0xffffffff81e0cc60
module_register_init() at module_register_init+0xb0/frame 0xffffffff81e0cc90
mi_startup() at mi_startip+0x118/frame 0xffffffff81e0ccb0
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why

I was quite surprised to find that if I disable x86bios the system boots and runs successfully in this (linked at 0x1000) configuration.
Comment 1 Ed Maste freebsd_committer freebsd_triage 2016-11-21 23:23:33 UTC
A change to allow an LLD-linked kernel to boot is in https://reviews.freebsd.org/D8610, but x86bios should still be fixed to avoid panicking if its allocation fails.
Comment 2 commit-hook freebsd_committer freebsd_triage 2016-11-25 18:57:20 UTC
A commit references this bug:

Author: emaste
Date: Fri Nov 25 18:57:14 UTC 2016
New revision: 309151
URL: https://svnweb.freebsd.org/changeset/base/309151

Log:
  Use explicit 0x200000 instead of MAXPAGESIZE for the amd64 kernel physaddr

  MAXPAGESIZE is not well defined by the GNU ld documentation.
  Different linkers, and different versions of the same linker, use
  different MAXPAGESIZE values. Current versions of GNU gold and LLVM's
  lld use 4K. When set to 4K the kernel panics at boot due to an issue
  with x86bios.

  Here we want the kernel physaddr to be the amd64 superpage size, so use
  that value (2MB) explicitly. With this change GNU gold and LLVM lld can
  link a working amd64 kernel.

  PR:		214718 (x86bios)
  Differential Revision:	https://reviews.freebsd.org/D8610

Changes:
  head/sys/conf/ldscript.amd64
Comment 3 commit-hook freebsd_committer freebsd_triage 2017-10-11 00:32:33 UTC
A commit references this bug:

Author: emaste
Date: Wed Oct 11 00:31:54 UTC 2017
New revision: 324510
URL: https://svnweb.freebsd.org/changeset/base/324510

Log:
  MFC r309151: Use explicit 0x200000 for the amd64 kernel physaddr

  (instead of MAXPAGESIZE)

  MAXPAGESIZE is not well defined by the GNU ld documentation.
  Different linkers, and different versions of the same linker, use
  different MAXPAGESIZE values. Current versions of GNU gold and LLVM's
  lld use 4K. When set to 4K the kernel panics at boot due to an issue
  with x86bios.

  Here we want the kernel physaddr to be the amd64 superpage size, so use
  that value (2MB) explicitly. With this change GNU gold and LLVM lld can
  link a working amd64 kernel.

  PR:		214718 (x86bios)
  Sponsored by:	The FreeBSD Foundation

Changes:
_U  stable/11/
  stable/11/sys/conf/ldscript.amd64
Comment 4 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-21 19:23:28 UTC
There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved.

Thanks
Comment 5 Ed Maste freebsd_committer freebsd_triage 2019-01-21 19:44:27 UTC
This one has a workaround committed but the underlying problem still exists.