Date: Fri, 08 Feb 2019 07:15:36 +0000 From: bugzilla-noreply@freebsd.org To: bugs@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-227-5KvtMbx8iC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-231760-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760 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 enumerated 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=0, seems FreeBSD does port-mapped access to PCI config space, rather than memory mapped access. How 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 function 0 of a PCI device, it is a multi-function device, which contains several (similar 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 device creates the problem here? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231760-227-5KvtMbx8iC>