Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Aug 2019 00:36:20 +0000
From:      bugzilla-noreply@freebsd.org
To:        acpi@FreeBSD.org
Subject:   [Bug 231760] FreeBSD 12.0-ALPHA7 Installations Halts at ACPI on 4 different AMD Ryzen Laptops (HP, DELL, Huawei)
Message-ID:  <bug-231760-16045-bRz6Uu09IZ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-231760-16045@https.bugs.freebsd.org/bugzilla/>
References:  <bug-231760-16045@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231760

--- Comment #23 from commit-hook@freebsd.org ---
A commit references this bug:

Author: jhb
Date: Sat Aug 24 00:36:01 UTC 2019
New revision: 351449
URL: https://svnweb.freebsd.org/changeset/base/351449

Log:
  MFC 350551:
  Don't reset memory attributes when mapping physical addresses for ACPI.

  Previously, AcpiOsMemory was using pmap_mapbios which would always map
  the requested address Write-Back (WB).  For several AMD Ryzen laptops,
  the BIOS uses AcpiOsMemory to directly access the PCI MCFG region in
  order to access PCI config registers.  This has the side effect of
  remapping the MCFG region in the direct map as WB instead of UC
  hanging the laptops during boot.

  On the one laptop I examined in detail, the _PIC global method used to
  switch from 8259A PICs to I/O APICs uses a pair of PCI config space
  registers at offset 0x84 in the device at 0:0:0 to as a pair of
  address/data registers to access an indirect register in the chipset
  and clear a single bit to switch modes.

  To fix, alter the semantics of pmap_mapbios() such that it does not
  modify the attributes of any existing mappings and instead uses the
  existing attributes.  If a new mapping is created, this new mapping
  uses WB (the default memory attribute).

  Special thanks to the gentleman whose name I don't have who brought
  two affected laptops to the hacker lounge at BSDCan.  Direct access to
  the affected systems permitted finding the root cause within an hour
  or so.

  PR:           231760, 236899

Changes:
_U  stable/11/
  stable/11/sys/amd64/amd64/pmap.c
  stable/11/sys/i386/i386/pmap.c
_U  stable/12/
  stable/12/sys/amd64/amd64/pmap.c
  stable/12/sys/i386/i386/pmap.c

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231760-16045-bRz6Uu09IZ>