[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Rafael J. Wysocki (r...@rjwysocki.net) changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE --- Comment #27 from Rafael J. Wysocki (r...@rjwysocki.net) --- Sounds good to me. Jan, please send this patch to linux-acpi, thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #26 from Erik Kaneda (erik.kan...@intel.com) --- @Rafael, what do you think about taking the patch from comment 22 for Linux? -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #25 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287659 --> https://bugzilla.kernel.org/attachment.cgi?id=287659=edit Fragment for idea from comment 22 -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #24 from Jan Engelhardt (ej+...@inai.de) --- FreeBSD "accidentally" fixed the issue at some point. commit fccbffe7d83251aeb28395fd853f38f45bf3782d Author: jkim Date: Fri Feb 10 23:30:29 2012 + De-obfuscate acpi_acquire_global_lock(). It seems the function was directly translated from i386 assembly version. - return ((new < GL_BIT_MASK) ? GL_ACQUIRED : GL_BUSY); + return ((new & GL_BIT_PENDING) == 0); -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553
--- Comment #23 from Jan Engelhardt (ej+...@inai.de) ---
My patch from comment 22 ignores the bits 2-31 that are marked reserved by the
spec, https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf .
Looking at FreeBSD's acpi_acquire_global_lock shows they are even ignoring bits
1-31 (which coincides with my first observation in this bugreport that FreeBSD
is booting without issues):
int acpi_acquire_global_lock(volatile uint32_t *lock)
{
uint32_tnew, old;
do {
old = *lock;
new = (old & ~ACPI_GLOCK_PENDING) | ACPI_GLOCK_OWNED;
if ((old & ACPI_GLOCK_OWNED) != 0)
new |= ACPI_GLOCK_PENDING;
} while (atomic_cmpset_32(lock, old, new) == 0);
return ((new & ACPI_GLOCK_PENDING) == 0);
}
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #22 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287653 --> https://bugzilla.kernel.org/attachment.cgi?id=287653=edit Patch from a completely different angle The real bug is in __acpi_acquire_global_lock. The firmware is fine (well, mostly). The FACS table contains some garbage bits, which __acpi_acquire_global_lock fails to deal with. This patch also makes the system boot successfully. This opens up another consideration though: if the FACS table were to contain 0x in the GL register, then acquiring the lock would always fail logically, even if the firmware is actually performing properly. IOW, I think we need to add a facs->global_lock&=~0x3 statement right after loading the FACS as well, just to reset that register to a sane value. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Jan Engelhardt (ej+...@inai.de) changed: What|Removed |Added Attachment #287651|1 |0 is patch|| -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Jan Engelhardt (ej+...@inai.de) changed: What|Removed |Added Attachment #287517|0 |1 is obsolete|| --- Comment #21 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287651 --> https://bugzilla.kernel.org/attachment.cgi?id=287651=edit Updated patch -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #20 from Jan Engelhardt (ej+...@inai.de) --- Your patch is faulty; 1. AE_TIME is emitted from the function, which is incorrect. We want to execute a similar pattern such as the "Make sure that a global lock actually exists." branch a few lines above. 1b. The caller at exfield.c:394 (see comment 2) ignores the AE_TIME return value, which causes some more problems down the line because things pretend the lock was taken when it's not. Eventually the system hangs again at some point. 2. Due to "break;", the acpi_os_acquire_lock call is skipped but not the acpi_os_release_lock after the loop. This leads to a release of a mutex that is not locked. New patch follows. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #19 from Erik Schmauss (erik.schma...@intel.com) --- Created attachment 287637 --> https://bugzilla.kernel.org/attachment.cgi?id=287637=edit patch to detect bad global lock please try this patch -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #18 from Erik Schmauss (erik.schma...@intel.com) --- (In reply to Jan Engelhardt from comment #13) > >There's definitely something holding the lock. > > Did you observe comment 8? It's not the lock, it's a OS-level semaphore that > is initialized to 0, and the hardware never emits events needed to "up" it > to 1, hence the first "down" call is the one that hangs. Sorry, I wasn't reading that closely when I initially read the report. This definitely sounds like a hardware bug. Since we can't trust the global lock, we should not use it if we deem this as broken. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #17 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287635 --> https://bugzilla.kernel.org/attachment.cgi?id=287635=edit dmesg as per comment 12 item 3, with patch from comment 14 -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #15 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287631 --> https://bugzilla.kernel.org/attachment.cgi?id=287631=edit dmesg as per comment 12 item 1, with patch from comment 14 The kernel used was v5.5.5, the only extra being the patch from comment 14 (which is line number preserving). -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #16 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287633 --> https://bugzilla.kernel.org/attachment.cgi?id=287633=edit dmesg as per comment 12 item 2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #14 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287629 --> https://bugzilla.kernel.org/attachment.cgi?id=287629=edit Alternate patch to comment 9. Diagnostic patch. This patch kills off the unbounded wait on acpi_gbl_global_lock_semaphore. Needless to say unbounded waits are kinda bad. It is here replaced with a 44ms wait (just something that will stand out in logs). Observations from running this patch on the hardware: 1. ACPI_ACQUIRE_GLOBAL_LOCK never succeeds in acquiring acpi_gbl_FACS. Looking at what that macro does, this may turn out to be a hardware bug that can only be worked around. Upgrading the firmware is not an option -- there is no upgrade to be found on the manufacturer's website. 2. (as before) acpi_gbl_global_lock_semaphore never gets posted either, so acpi_ex_system_wait_semaphore will never complete in a stock kernel. Unlike comment 9, this patch does not skip nearly as much locking code, so the dmesg should be better. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #13 from Jan Engelhardt (ej+...@inai.de) --- >There's definitely something holding the lock. Did you observe comment 8? It's not the lock, it's a OS-level semaphore that is initialized to 0, and the hardware never emits events needed to "up" it to 1, hence the first "down" call is the one that hangs. >without any patches of a kernel 5.0 ... 1) plain dmesg Without any patches, that is going to be impossible. ACPI is so early that an external observer is required, like a serial console (for which laptops have not had a port since a long time), netconsole is going to be impossible because stupid manufacturers have also removed that port, and I can't reach userspace to dump dmesg to a disk, because obviously there's the hang. I can do a video capture, but then someone will have to sift through something like 2 hours of non-text material. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Erik Schmauss (erik.schma...@intel.com) changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Comment #12 from Erik Schmauss (erik.schma...@intel.com) --- Thanks for the report. At this time, we need more debug information. If you could build a custom kernel, please build with CONFIG_ACPI_DEBUG=y without any patches of a kernel 5.0 or newer.. Please provide the full following dmesg: 1) plain dmesg 2) dmesg booting with the parameters "acpi.debug_level=0x8 acpi.debug_layer=0x" 3) dmesg booting with parameters "acpi.debug_level=0x0100 acpi.debug_layer=0x4" There's definitely something holding the lock. We just don't know what's holding it and why it's not releasing it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #11 from Jan Engelhardt (ej+...@inai.de) --- Another possibility (without comment 9 patch) is to simply enable CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y in .config, as this also will skip evglock.c code. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Jan Engelhardt (ej+...@inai.de) changed: What|Removed |Added Attachment #287433|0 |1 is obsolete|| --- Comment #10 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287559 --> https://bugzilla.kernel.org/attachment.cgi?id=287559=edit Full ACPI table dump -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #9 from Jan Engelhardt (ej+...@inai.de) --- Created attachment 287517 --> https://bugzilla.kernel.org/attachment.cgi?id=287517=edit Cure/Workaround Using this ad-hoc patch, I can successfully boot userspace. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #8 from Jan Engelhardt (ej+...@inai.de) --- I find that acpi_gbl_global_lock_semaphore is initialized with 0 units (nsaccess.c): /* Create additional counting semaphore for global lock */ status = acpi_os_create_semaphore(1, 0, _gbl_global_lock_semaphore); and that the acpi_ev_global_lock_handler function (evglock.c) that would send a unit never gets called, which leads me to believe the hardware is not generating any ACPI_EVENT_GLOBAL events. But should it, and when? -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 --- Comment #6 from Jan Engelhardt (ej+...@inai.de) --- I do not get such an error, at least not in a reasonable time. The longest I observed the console is about 50 minutes - the hung task checker kicks in after about 16min, though. [138.837] ACPI: EC: Boot ECDT EC used to handle transactions [1115.250] INFO: task swapper/0:1 blocked for more than 491 seconds. Given the execution is stuck with ACPI_WAIT_FOREVER (jiffies==MAX_SCHEDULE_TIMEOUT), I also see no possibility for down_timeout to return anytime soon to give parent functions a chance to return AE_ABORT_METHOD anywhere. Due to exfield.c:394 ignoring the return code from acpi_ex_acquire_global_lock, AE_TIME also never propagates further upwards. Furthermore, grepping for AE_ABORT_METHOD yields only one place which can return it, dbxface.c:222. This depends on acpi_gbl_abort_method being set, but this variable is never set to "true" anywhere from the looks of it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Robert Moore (robert.mo...@intel.com) changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Robert Moore (robert.mo...@intel.com) --- Do you eventually get a timeout error (like below:) ACPI Error: Aborting method \_SB.PCI0.LPCB.EC0.RRAM due to previous error (AE_AML_LOOP_TIMEOUT) -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 206553] Linux hangs at ACPI init on Medion/Akoya P15648 MD63490
https://bugzilla.kernel.org/show_bug.cgi?id=206553 Jan Engelhardt (ej+...@inai.de) changed: What|Removed |Added Summary|Linux hangs at ACPI init on |Linux hangs at ACPI init on |Medion P15648 MD63490 |Medion/Akoya P15648 MD63490 -- You are receiving this mail because: You are watching the assignee of the bug. ___ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
