https://bugzilla.kernel.org/show_bug.cgi?id=206553
Rafael J. Wysocki (r...@rjwysocki.net) changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
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.
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=206553
Jan Engelhardt (ej+...@inai.de) changed:
What|Removed |Added
Attachment #287651|1 |0
is patch|
https://bugzilla.kernel.org/show_bug.cgi?id=206553
Jan Engelhardt (ej+...@inai.de) changed:
What|Removed |Added
Attachment #287517|0 |1
is obsolete|
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
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
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
>
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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=206553
Erik Schmauss (erik.schma...@intel.com) changed:
What|Removed |Added
Status|ASSIGNED|NEEDINFO
---
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
https://bugzilla.kernel.org/show_bug.cgi?id=206553
Jan Engelhardt (ej+...@inai.de) changed:
What|Removed |Added
Attachment #287433|0 |1
is obsolete|
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
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,
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]
https://bugzilla.kernel.org/show_bug.cgi?id=206553
Robert Moore (robert.mo...@intel.com) changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
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
24 matches
Mail list logo
