Date: Fri, 08 Feb 2019 07:15:36 +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-YLe9FV5Bws@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 Rajesh <rajfbsd@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rajfbsd@gmail.com --- Comment #6 from Rajesh <rajfbsd@gmail.com> --- I face the same issue, but only when I enable a EMMC device which is enumer= ated by ACPI. Debugged whether the ACPI device is conflicting with the PCI MMIO space using the ACPI DSDT tables, but seems they are not conflicting. What I understand is, when we have hw.pci.mcfg=3D0, seems FreeBSD does port-mapped access to PCI config space, rather than memory mapped access. H= ow this is related to the multi-function device theory mentioned here? pciconf(8) man page says, "If the most significant bit of the header type register is set for functio= n 0 of a PCI device, it is a multi-function device, which contains several (sim= ilar or independent) functions on one chip." In my pciconf output, I don't see any device with the MSB bit set. But I see multi-function devices listed. I assume the pciconf output should be read as "driver@pci<unit>.<bus>.<device>.<function>". So, Is pciconf output not proper? How can we debug which multi-function dev= ice creates the problem here? --=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-YLe9FV5Bws>