Date: Sat, 15 Dec 2018 14:34:06 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Sascha Klauder <sascha@hosting.ntag.de> Cc: freebsd-stable@FreeBSD.org Subject: Re: boot hang with certain Phenom II cpu models Message-ID: <a37ff3b3-e4c7-5d9d-29e0-ada95c2cbe82@FreeBSD.org> In-Reply-To: <20181214193741.GA18201@hosting.ntag.de> References: <20181213105616.GA27140@hosting.ntag.de> <218c8702-9b64-0211-74ba-6944f98d4471@FreeBSD.org> <20181214193741.GA18201@hosting.ntag.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/12/2018 21:37, Sascha Klauder wrote: > On Fri, 2018-12-14 11:56 +0200, Andriy Gapon wrote: >> On 13/12/2018 12:56, Sascha Klauder wrote: >>> So far, I tried (unsuccessfully) to disable obvious ACPI sub- >>> systems (cpu, mwait, quirks) and debug settings (acpi.cpu_unordered, >>> acpi.max_threads). Anyone got a hint where to look or debug this >>> further? >> Are you able to identify if you have a hardware or a software hang? >> E.g., are you able to enter ddb? > > Hardware; can't enter ddb and can't toggle caps lock. I could > probably setup remote GDB (serial) but would need some pointer > how to proceed from there. The only idea I have is to boot to ddb (boot_ddb="YES" or boot -d), set a breakpoint in a function from which the last printed line comes[*], continue until the breakpoint is hit and then step from there trying to narrow down a function (or even an instruction) where the hang happens. [*] - seems to be pcie_cfgregopen() -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a37ff3b3-e4c7-5d9d-29e0-ada95c2cbe82>