Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Nov 2014 17:14:51 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-acpi@FreeBSD.org
Subject:   [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state
Message-ID:  <bug-194884-13733-vdceFaedSa@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>
References:  <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884

--- Comment #7 from commit-hook@freebsd.org ---
A commit references this bug:

Author: adrian
Date: Tue Nov 11 17:14:12 UTC 2014
New revision: 274386
URL: https://svnweb.freebsd.org/changeset/base/274386

Log:
  Use the correct device (child) when asking the bus layer about which power
  state said device should go into.

  This was a snafu introduced in the ACPI/PCI awareness separation.

  When putting a device into a power state, the bus (and thus firmware,
  eg ACPI) should be asked before hand to check whether the device
  can indeed go into that power state.

  There's a set of nodes in ACPI under each device - the _SxD nodes - which
  state which ACPI power state to put the device into when the system is
  going into power save state 'x'.  So when going into S3, the existence
  of an _S3D node would override whatever the system was trying to do.

  By default the PCI code wants to put devices into D3 before suspending.

  I have a laptop here (Asus Zenbook - check the PR) whose EHCI controller
  really wants to be in D2 during suspend, not D3.  So if we put it into
  D3 and then try to enter S3, everything hangs.  The device itself
  can go into D3 - it just can't be there when the call to ACPI to enter
  S3 occurs.  The PCI patch fixes this.

  jkim@ noticed that the same is needed for the ACPI child device
  enumeration.

  Thankyou to Matt Dillon (the programmer, not the actor) for buying me
  this particular laptop so I could debug the issues with the Atheros
  AR9485 that is in it.  It's his fault that I ended up with this
  laptop and was sufficiently annoyed by the lack of USB suspend
  to go down this rabbit hole.

  Tested:

  * Thinkpad T400
  * Thinkpad X230
  * Thinkpad T42
  * Thinkpad T60
  * Asus Zenbook (see PR)
  * Asus EEEPC 701
  * Asus EEEPC 1001PX

  TODO:

  * Figure out what we should do about devices we unload drivers for
    that want to be in a specific state when entering S3 / S4 -
    the "put devices into D3 if they're not bound to a driver" option
    may also mess with things.

  PR:        kern/194884
  Reviewed by:    jhb, jkim
  MFC after:    1 week
  Relnotes:    yes
  Sponsored by:    Matt Dillon <dillon@apollo.backplane.com> (hardware)

Changes:
  head/sys/dev/acpica/acpi.c
  head/sys/dev/pci/pci.c

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194884-13733-vdceFaedSa>