Bug 173722 - [xhci] [suspend/resume] xhci driver bug after suspend to RAM (ACPI S3 mode)
Summary: [xhci] [suspend/resume] xhci driver bug after suspend to RAM (ACPI S3 mode)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 9.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
Depends on:
Reported: 2012-11-19 15:40 UTC by Florian Jung
Modified: 2017-12-31 22:24 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Jung 2012-11-19 15:40:00 UTC
After entering and waking up from suspend to ram aka ACPI S3 state, the dmesg get flooded with "xhci_interrupt: host controller halted", and my USB3.0 device stops working.

(It is a external hard disk drive, and the device node just vanished and won't re-appear)

My USB2.0 and 1.x devices however do still work.

It seems that i can provoke the generation of these "xhci_interrupt: host controller halted" messages by typing on my USB-2.0-Keyboard or by moving my USB-2.0-Mouse.

How-To-Repeat: - Start up FreeBSD
- Plug in USB3.0 Harddisk
- It will work.
- sudo acpiconf -S 3
- re-awake the computer
- ls /dev/ tells you that the harddisk is gone
- dmesg tells you the "xhci_interrupt: host controller halted" messages.
- replug the harddisk
- it still does not work.
Comment 1 Hans Petter Selasky 2012-11-19 18:21:13 UTC
If you unplug the harddisk before the suspend, does it work afterwards then?

Comment 2 Florian Jung 2012-11-19 19:21:47 UTC
No, that causes the same problem.
I don't even need to attach it: boot freebsd, enter acpi s3, wake up,
and then plug in the disk leads to the same problem.

i have found out that compiling XHCI has loadable module, and unloading
it before suspend and re-loading it afterwards solves the problem.

the "xhci_interrupt: host controller halted"-messages don't appear, and
i can use my harddisk afterwards.

looks like xhci is failing to reinitalize properly after suspend?

Comment 3 Hans Petter Selasky 2012-11-19 19:52:35 UTC

Do you have a USB 3.0 compatible BIOS?

I think we might need to halt the XHCI as part of the resume process. Can you 
try this patch:

diff --git a/sys/dev/usb/controller/xhci.c b/sys/dev/usb/controller/xhci.c
index 756b1ed..576ed71 100644
--- a/sys/dev/usb/controller/xhci.c
+++ b/sys/dev/usb/controller/xhci.c
@@ -578,6 +578,8 @@ xhci_set_hw_power_sleep(struct usb_bus *bus, uint32_t 
        case USB_HW_POWER_RESUME:
+               DPRINTF("Halting the XHCI\n");
+               xhci_halt_controller(sc);
                DPRINTF("Starting the XHCI\n");

Comment 4 Florian Jung 2012-11-19 21:07:12 UTC

i have a USB3.0-compatible BIOS.

uhm, i am unable to apply this patch. my xhci.c file looks pretty
different, there is no xhci_set_hw_power_sleep function, but there are
xhci_suspend() and xhci_resume(). both are empty and contain only a /*

uname -r now reports 9.0-RELEASE-p4, btw, i must have mistyped that :/

i've set up my freebsd system ~2 months ago, and ran freebsd-update
fetch install today. that are the kernel sources i'm using.
there is a line: __FBSDID("$FreeBSD:
release/9.0.0/sys/dev/usb/controller/xhci.c 226904 2011-10-29 12:39:05Z
hselasky $");

do i have to download different sources (how?), or did you diff against
the wrong kernel tree?

(sorry, i'm a freeBSD-newbie ;) )

Comment 5 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:36 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped