Bug 240881

Summary: acpi_lid: dev.acpi_lid.0.state: 0 after resume (lid opened)
Product: Base System Reporter: Johannes Lundberg <johalun>
Component: kernAssignee: Hans Petter Selasky <hselasky>
Status: Closed FIXED    
Severity: Affects Some People CC: acpi, hselasky, yuripv
Priority: --- Flags: koobs: mfc-stable12?
koobs: mfc-stable11?
Version: CURRENT   
Hardware: Any   
OS: Any   
URL: https://reviews.freebsd.org/D23724

Description Johannes Lundberg freebsd_committer freebsd_triage 2019-09-27 20:36:10 UTC
As the title says, state remains = 0 after resume by opening the lid.

This happens when I suspend with command 'acpiconf -s3' and the lid is already closed (for example suspending while an external screen is connected)

Dell Latitude 2018 laptop
FreeBSD 13-CURRENT as of this date.
Comment 1 Johannes Lundberg freebsd_committer freebsd_triage 2019-09-27 21:15:26 UTC
Some more consistent test results.

If lid switch does nothing, dev.acpi_lid.0.state updates as it should on lid open/close.

If lid switch suspends, or if I wake up from suspend by opening the lid, state remains 0.
Comment 2 commit-hook freebsd_committer freebsd_triage 2020-02-21 09:52:29 UTC
A commit references this bug:

Author: hselasky
Date: Fri Feb 21 09:52:21 UTC 2020
New revision: 358219
URL: https://svnweb.freebsd.org/changeset/base/358219

Log:
  Make sure the ACPI lid state is updated during boot and after resume.
  While at it update the sysctl(9) description for the lid state.

  Differential Revision:	https://reviews.freebsd.org/D23724
  PR:		240881
  Submitted by:	Yuri Pankov <yuripv@yuripv.me>
  MFC after:	1 week
  Sponsored by:	Mellanox Technologies

Changes:
  head/sys/dev/acpica/acpi_lid.c
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2020-02-22 03:48:34 UTC
Thanks for this Hans. Can/will this go to stable/11 ?
Comment 4 Hans Petter Selasky freebsd_committer freebsd_triage 2020-02-22 08:57:20 UTC
I think so.
Comment 5 commit-hook freebsd_committer freebsd_triage 2020-02-24 09:31:46 UTC
A commit references this bug:

Author: hselasky
Date: Mon Feb 24 09:31:31 UTC 2020
New revision: 358270
URL: https://svnweb.freebsd.org/changeset/base/358270

Log:
  Always check return value from acpi_GetInteger() after r358219.
  If a failure happens reading the lid state, assume the lid is opened.

  Suggested by:	cem @
  Differential Revision:	https://reviews.freebsd.org/D23724
  PR:		240881
  MFC after:	1 week
  Sponsored by:	Mellanox Technologies

Changes:
  head/sys/dev/acpica/acpi_lid.c
Comment 6 commit-hook freebsd_committer freebsd_triage 2020-03-02 09:09:55 UTC
A commit references this bug:

Author: hselasky
Date: Mon Mar  2 09:09:17 UTC 2020
New revision: 358534
URL: https://svnweb.freebsd.org/changeset/base/358534

Log:
  MFC r358219 and r358270:
  Make sure the ACPI lid state is updated during boot and after resume.
  While at it update the sysctl(9) description for the lid state.

  Always check return value from acpi_GetInteger().
  If a failure happens reading the lid state, assume the lid is opened.

  Differential Revision:	https://reviews.freebsd.org/D23724
  PR:		240881
  Submitted by:	Yuri Pankov <yuripv@yuripv.me>
  Sponsored by:	Mellanox Technologies

Changes:
_U  stable/12/
  stable/12/sys/dev/acpica/acpi_lid.c
Comment 7 commit-hook freebsd_committer freebsd_triage 2020-03-02 09:16:57 UTC
A commit references this bug:

Author: hselasky
Date: Mon Mar  2 09:16:49 UTC 2020
New revision: 358536
URL: https://svnweb.freebsd.org/changeset/base/358536

Log:
  MFC r358219 and r358270:
  Make sure the ACPI lid state is updated during boot and after resume.
  While at it update the sysctl(9) description for the lid state.

  Always check return value from acpi_GetInteger().
  If a failure happens reading the lid state, assume the lid is opened.

  Differential Revision:	https://reviews.freebsd.org/D23724
  PR:		240881
  Submitted by:	Yuri Pankov <yuripv@yuripv.me>
  Sponsored by:	Mellanox Technologies

Changes:
_U  stable/11/
  stable/11/sys/dev/acpica/acpi_lid.c
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2023-07-25 18:28:16 UTC
Apparently committed Mon Mar  2 09:16:49 UTC 2020.