Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards, so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- drivers/usb/core/hub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..efd6374ccd1d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3480,6 +3480,7 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) if (PMSG_IS_AUTO(msg)) goto err_wakeup; } + usb_enable_remote_wakeup(udev->bus->root_hub); }
/* disable USB2 hardware LPM */ @@ -3543,8 +3544,10 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) /* Try to enable USB2 hardware LPM again */ usb_enable_usb2_hardware_lpm(udev);
- if (udev->do_remote_wakeup) + if (udev->do_remote_wakeup) { (void) usb_disable_remote_wakeup(udev); + (void) usb_disable_remote_wakeup(udev->bus->root_hub); + } err_wakeup:
/* System sleep transitions should never fail */
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards, so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn
What commit id does this fix?
drivers/usb/core/hub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..efd6374ccd1d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3480,6 +3480,7 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) if (PMSG_IS_AUTO(msg)) goto err_wakeup; }
usb_enable_remote_wakeup(udev->bus->root_hub);/* disable USB2 hardware LPM */ @@ -3543,8 +3544,10 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) /* Try to enable USB2 hardware LPM again */ usb_enable_usb2_hardware_lpm(udev);
if (udev->do_remote_wakeup)
if (udev->do_remote_wakeup) { (void) usb_disable_remote_wakeup(udev);(void) usb_disable_remote_wakeup(udev->bus->root_hub);
This feels wrong, what about all of the devices inbetween this device and the root hub?
thanks,
greg k-h
Hi, Greg,
On Fri, Jan 31, 2025 at 6:49 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards, so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn
What commit id does this fix?
It seems this problem exist from the first place (at least >=4.19).
drivers/usb/core/hub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..efd6374ccd1d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3480,6 +3480,7 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) if (PMSG_IS_AUTO(msg)) goto err_wakeup; }
usb_enable_remote_wakeup(udev->bus->root_hub); } /* disable USB2 hardware LPM */@@ -3543,8 +3544,10 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) /* Try to enable USB2 hardware LPM again */ usb_enable_usb2_hardware_lpm(udev);
if (udev->do_remote_wakeup)
if (udev->do_remote_wakeup) { (void) usb_disable_remote_wakeup(udev);(void) usb_disable_remote_wakeup(udev->bus->root_hub);This feels wrong, what about all of the devices inbetween this device and the root hub?
Yes, if there are other hubs between the root hub and keyboard, this patch still cannot fix the wakeup problem. I have tried to enable every hub in the link, but failed. Because I found many hubs lost power during suspend. So this patch can only fixes the most usual cases.
Huacai
thanks,
greg k-h
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards,
Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working?
so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices.
You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do?
Alan Stern
Hi, Alan,
On Fri, Jan 31, 2025 at 11:17 PM Alan Stern stern@rowland.harvard.edu wrote:
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards,
Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working?
so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices.
You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do?
OK, let me tell a long story:
At first, someone reported that on Loongson platform we cannot wake up S3 with a USB keyboard, but no problem on x86. At that time we thought this was a platform-specific problem.
After that we have done many experiments, then we found that if the keyboard is connected to a XHCI controller, it can wake up, but cannot wake up if it is connected to a non-XHCI controller, no matter on x86 or on Loongson. We are not familiar with USB protocol, this is just observed from experiments.
You are probably right that enabling remote wakeup on a hub means it can generate wakeup requests rather than forward downstream devices' requests. But from experiments we found that if we enable the "wakeup" knob of the root_hub via sysfs, then a keyboard becomes able to wake up S3 (for non-XHCI controllers). So we guess that the enablement also enables forwarding. So maybe this is an implementation-specific problem (but most implementations have problems)?
This patch itself just emulates the enablement of root_hub's remote wakeup automatically (then we needn't operate on sysfs).
Huacai
Alan Stern
On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote:
Hi, Alan,
On Fri, Jan 31, 2025 at 11:17 PM Alan Stern stern@rowland.harvard.edu wrote:
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards,
Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working?
so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices.
You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do?
OK, let me tell a long story:
At first, someone reported that on Loongson platform we cannot wake up S3 with a USB keyboard, but no problem on x86. At that time we thought this was a platform-specific problem.
After that we have done many experiments, then we found that if the keyboard is connected to a XHCI controller, it can wake up, but cannot wake up if it is connected to a non-XHCI controller, no matter on x86 or on Loongson. We are not familiar with USB protocol, this is just observed from experiments.
You are probably right that enabling remote wakeup on a hub means it can generate wakeup requests rather than forward downstream devices' requests. But from experiments we found that if we enable the "wakeup" knob of the root_hub via sysfs, then a keyboard becomes able to wake up S3 (for non-XHCI controllers). So we guess that the enablement also enables forwarding. So maybe this is an implementation-specific problem (but most implementations have problems)?
This patch itself just emulates the enablement of root_hub's remote wakeup automatically (then we needn't operate on sysfs).
I'll run some experiments on my system. Maybe you're right about the problem, but your proposed solution looks wrong.
Alan Stern
On Sun, Feb 2, 2025 at 12:55 AM Alan Stern stern@rowland.harvard.edu wrote:
On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote:
Hi, Alan,
On Fri, Jan 31, 2025 at 11:17 PM Alan Stern stern@rowland.harvard.edu wrote:
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards,
Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working?
so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices.
You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do?
OK, let me tell a long story:
At first, someone reported that on Loongson platform we cannot wake up S3 with a USB keyboard, but no problem on x86. At that time we thought this was a platform-specific problem.
After that we have done many experiments, then we found that if the keyboard is connected to a XHCI controller, it can wake up, but cannot wake up if it is connected to a non-XHCI controller, no matter on x86 or on Loongson. We are not familiar with USB protocol, this is just observed from experiments.
You are probably right that enabling remote wakeup on a hub means it can generate wakeup requests rather than forward downstream devices' requests. But from experiments we found that if we enable the "wakeup" knob of the root_hub via sysfs, then a keyboard becomes able to wake up S3 (for non-XHCI controllers). So we guess that the enablement also enables forwarding. So maybe this is an implementation-specific problem (but most implementations have problems)?
This patch itself just emulates the enablement of root_hub's remote wakeup automatically (then we needn't operate on sysfs).
I'll run some experiments on my system. Maybe you're right about the problem, but your proposed solution looks wrong.
OK, I'm glad to see a better solution. :)
Huacai
Alan Stern
On Sat, Feb 01, 2025 at 11:55:03AM -0500, Alan Stern wrote:
On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote:
Hi, Alan,
On Fri, Jan 31, 2025 at 11:17 PM Alan Stern stern@rowland.harvard.edu wrote:
On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
Now we only enable the remote wakeup function for the USB wakeup source itself at usb_port_suspend(). But on pre-XHCI controllers this is not enough to enable the S3 wakeup function for USB keyboards,
Why do you say this? It was enough on my system with an EHCI/UHCI controller when I wrote that code. What hardware do you have that isn't working?
so we also enable the root_hub's remote wakeup (and disable it on error). Frankly this is unnecessary for XHCI, but enable it unconditionally make code simple and seems harmless.
This does not make sense. For hubs (including root hubs), enabling remote wakeup means that the hub will generate a wakeup request when there is a connect, disconnect, or over-current change. That's not what you want to do, is it? And it has nothing to do with how the hub handles wakeup requests received from downstream devices.
You need to explain what's going on here in much more detail. What exactly is going wrong, and why? What is the hardware actually doing, as compared to what we expect it to do?
OK, let me tell a long story:
At first, someone reported that on Loongson platform we cannot wake up S3 with a USB keyboard, but no problem on x86. At that time we thought this was a platform-specific problem.
After that we have done many experiments, then we found that if the keyboard is connected to a XHCI controller, it can wake up, but cannot wake up if it is connected to a non-XHCI controller, no matter on x86 or on Loongson. We are not familiar with USB protocol, this is just observed from experiments.
You are probably right that enabling remote wakeup on a hub means it can generate wakeup requests rather than forward downstream devices' requests. But from experiments we found that if we enable the "wakeup" knob of the root_hub via sysfs, then a keyboard becomes able to wake up S3 (for non-XHCI controllers). So we guess that the enablement also enables forwarding. So maybe this is an implementation-specific problem (but most implementations have problems)?
This patch itself just emulates the enablement of root_hub's remote wakeup automatically (then we needn't operate on sysfs).
I'll run some experiments on my system. Maybe you're right about the problem, but your proposed solution looks wrong.
I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI.
So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend?
Alan Stern
Hi Alan, Huacai,
<snip>
I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI.
So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend?
Just to chime in with my own test results. I was looking at this with Huacai a few days back and we suspected that this had something to do with particular systems, as you have found; we also suspected that if a keyboard was connected to a non-xHCI controller, it would fail to wake up the system.
I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not come with any USB 3.0 port. Here are my findings:
1. With upstream code, the system would not wake up with neither the internal nor the external keyboards. One exception being the Fn key on the internal keyboard, which would wake up the system (but I suspect that this is EC behaviour). This behaviour is consistent across any USB port on the laptop and, regardless if the external keyboard was connected to the laptop itself or via a hub.
2. With Huacai's code, I was able to wake up the laptop with an external keyboard in all the scenarios listed in (1). The internal keyboard still failed to wake up the system unless I strike the Fn key.
I should note, however, that the internal keyboard is not connected via USB so it's probably irrelevant information anyway.
As for mice, it seems that the kernel disables wake-up via USB mice and enables wake-up via USB keyboards. This is also consistent with your findings.
Best Regards, Mingcong Bai
Alan Stern
On Tue, Feb 04, 2025 at 12:01:37AM +0800, Mingcong Bai wrote:
Hi Alan, Huacai,
<snip>
I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI.
So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend?
Just to chime in with my own test results. I was looking at this with Huacai a few days back and we suspected that this had something to do with particular systems, as you have found; we also suspected that if a keyboard was connected to a non-xHCI controller, it would fail to wake up the system.
I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not come with any USB 3.0 port. Here are my findings:
What sort of USB controller does the X200s have? Is the controller enabled for wakeup?
What happens with runtime suspend rather than S3 suspend?
- With upstream code, the system would not wake up with neither the
internal nor the external keyboards. One exception being the Fn key on the internal keyboard, which would wake up the system (but I suspect that this is EC behaviour). This behaviour is consistent across any USB port on the laptop and, regardless if the external keyboard was connected to the laptop itself or via a hub.
- With Huacai's code, I was able to wake up the laptop with an external
keyboard in all the scenarios listed in (1). The internal keyboard still failed to wake up the system unless I strike the Fn key.
I should note, however, that the internal keyboard is not connected via USB so it's probably irrelevant information anyway.
As for mice, it seems that the kernel disables wake-up via USB mice and enables wake-up via USB keyboards. This is also consistent with your findings.
Yes, and of course you can manually change the default wakeup settings whenever you want.
Alan Stern
Hi Alan,
在 2025/2/4 00:15, Alan Stern 写道:
On Tue, Feb 04, 2025 at 12:01:37AM +0800, Mingcong Bai wrote:
Hi Alan, Huacai,
<snip>
I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI.
So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend?
Just to chime in with my own test results. I was looking at this with Huacai a few days back and we suspected that this had something to do with particular systems, as you have found; we also suspected that if a keyboard was connected to a non-xHCI controller, it would fail to wake up the system.
I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not come with any USB 3.0 port. Here are my findings:
What sort of USB controller does the X200s have? Is the controller enabled for wakeup?
What happens with runtime suspend rather than S3 suspend?
It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub.
Sorry but the record here is going to get a bit messy... But let's start with a kernel with Huacai's patch.
=== Kernel + Huacai's Patch ===
1. If I plug in the external keyboard via the hub, /sys/bus/usb/devices/usb1, power/state is set to enabled. For the hub, corresponding to usb1/1-1, power/wakeup is set to disabled.
2. If I plug the keyboard directly into the chassis, usb1/power/wakeup is set to disabled, but usb1/1-1/power/wakeup is set to enabled.
The system wakes up via external keyboard plugged directly into the chassis **or** the hub either way, regardless if I used S3 or runtime suspend (which I assume to be echo freeze > /sys/power/state).
=== Kernel w/o Huacai's Patch ===
The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and the hub, corresponding to usb1/1-1, their power/wakeup entries are both set to disabled. Same for when I have the patch applied.
However, if I plug the external keyboard into the chassis, it would fail to wakeup regardless of S3/runtime suspend (freeze). If I plug the external keyboard via that USB Hub though, it would wake up the machine. The findings are consistent between S3/freeze.
- With upstream code, the system would not wake up with neither the
internal nor the external keyboards. One exception being the Fn key on the internal keyboard, which would wake up the system (but I suspect that this is EC behaviour). This behaviour is consistent across any USB port on the laptop and, regardless if the external keyboard was connected to the laptop itself or via a hub.
- With Huacai's code, I was able to wake up the laptop with an external
keyboard in all the scenarios listed in (1). The internal keyboard still failed to wake up the system unless I strike the Fn key.
I should note, however, that the internal keyboard is not connected via USB so it's probably irrelevant information anyway.
As for mice, it seems that the kernel disables wake-up via USB mice and enables wake-up via USB keyboards. This is also consistent with your findings.
Yes, and of course you can manually change the default wakeup settings whenever you want.
Alan Stern
Best Regards, Mingcong Bai
On Wed, Feb 05, 2025 at 01:59:24PM +0800, Mingcong Bai wrote:
在 2025/2/4 00:15, Alan Stern 写道:
What sort of USB controller does the X200s have? Is the controller enabled for wakeup?
What happens with runtime suspend rather than S3 suspend?
It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI
UHCI, not UCHI.
controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub.
There is no such thing as an xHCI hub -- xHCI is a host controller technology, not a hub technology. Perhaps you mean that it is a USB-3 hub.
Sorry but the record here is going to get a bit messy... But let's start with a kernel with Huacai's patch.
=== Kernel + Huacai's Patch ===
- If I plug in the external keyboard via the hub,
/sys/bus/usb/devices/usb1,
/sys/bus/usb/devices/usb1 is the root hub, which is an emulated device that is closely tied to the host controller. The external Genesys Logic hub is /sys/bus/usb/devices/1-1.
power/state is set to enabled. For the hub,
You mean power/wakeup, not power/state. In fact, there is no power/state file for USB devices in sysfs.
corresponding to usb1/1-1, power/wakeup is set to disabled.
- If I plug the keyboard directly into the chassis, usb1/power/wakeup is
set to disabled, but usb1/1-1/power/wakeup is set to enabled.
Why is usb1/power/wakeup set to disabled? Doesn't Huacai's patch set it to enabled?
Is 1-1 the keyboard device? That is, did you plug the keyboard into the port that the Genesys Logic hub was using previously?
The system wakes up via external keyboard plugged directly into the chassis **or** the hub either way, regardless if I used S3 or runtime suspend (which I assume to be echo freeze > /sys/power/state).
No. Runtime suspend has no relation to /sys/power. It is controlled by /sys/bus/usb/devices/.../power/control. If you write "auto" to this file for the device and for all the hubs above it (including the root hub) then they will be put into runtime suspend a few seconds after you stop using them, assuming no other USB devices are plugged into the same hubs.
=== Kernel w/o Huacai's Patch ===
The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and
/sys/bus/usb/devices/usb1 is the root hub, not the controller. The two are related but they are not the same thing. The controller is the parent device of the root hub; it lies under /sys/bus/pci/devices/.
the hub, corresponding to usb1/1-1, their power/wakeup entries are both set to disabled. Same for when I have the patch applied.
However, if I plug the external keyboard into the chassis, it would fail to wakeup regardless of S3/runtime suspend (freeze). If I plug the external keyboard via that USB Hub though, it would wake up the machine. The findings are consistent between S3/freeze.
This means there's something different between the way the keyboard sends its wakeup signal and the way the Genesys Logic hub sends its wakeup signal.
Can you post the output from "lsusb -t" for this system?
Also, can you enable dynamic debugging for usbcore by doing:
echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
and then post the dmesg log for a suspend/resume cycle?
Alan Stern
Hi Alan,
在 2025/2/6 02:25, Alan Stern 写道:
On Wed, Feb 05, 2025 at 01:59:24PM +0800, Mingcong Bai wrote:
在 2025/2/4 00:15, Alan Stern 写道:
What sort of USB controller does the X200s have? Is the controller enabled for wakeup?
What happens with runtime suspend rather than S3 suspend?
It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI
UHCI, not UCHI.
controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub.
There is no such thing as an xHCI hub -- xHCI is a host controller technology, not a hub technology. Perhaps you mean that it is a USB-3 hub.
Sorry but the record here is going to get a bit messy... But let's start with a kernel with Huacai's patch.
=== Kernel + Huacai's Patch ===
- If I plug in the external keyboard via the hub,
/sys/bus/usb/devices/usb1,
/sys/bus/usb/devices/usb1 is the root hub, which is an emulated device that is closely tied to the host controller. The external Genesys Logic hub is /sys/bus/usb/devices/1-1.
power/state is set to enabled. For the hub,
You mean power/wakeup, not power/state. In fact, there is no power/state file for USB devices in sysfs.
Sorry for the typos and terminology issues above. You are correct on all counts. Yes, I meant to say a USB 3.0 hub.
corresponding to usb1/1-1, power/wakeup is set to disabled.
- If I plug the keyboard directly into the chassis, usb1/power/wakeup is
set to disabled, but usb1/1-1/power/wakeup is set to enabled.
Why is usb1/power/wakeup set to disabled? Doesn't Huacai's patch set it to enabled?
No idea on my end either, I have double checked and that is indeed how it is (and wakeup does work).
Is 1-1 the keyboard device? That is, did you plug the keyboard into the port that the Genesys Logic hub was using previously?
The system wakes up via external keyboard plugged directly into the chassis **or** the hub either way, regardless if I used S3 or runtime suspend (which I assume to be echo freeze > /sys/power/state).
No. Runtime suspend has no relation to /sys/power. It is controlled by /sys/bus/usb/devices/.../power/control. If you write "auto" to this file for the device and for all the hubs above it (including the root hub) then they will be put into runtime suspend a few seconds after you stop using them, assuming no other USB devices are plugged into the same hubs.
Got it.
On both unpatched and patched kernels, I have set power/control to "auto" for both the root hub and the external hub and left the keyboard for 60 seconds. Regardless if I plug the keyboard into the chassis or the external hub, the keyboard continues to work from the first key strike (no delay or lost input).
=== Kernel w/o Huacai's Patch ===
The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and
/sys/bus/usb/devices/usb1 is the root hub, not the controller. The two are related but they are not the same thing. The controller is the parent device of the root hub; it lies under /sys/bus/pci/devices/.
the hub, corresponding to usb1/1-1, their power/wakeup entries are both set to disabled. Same for when I have the patch applied.
However, if I plug the external keyboard into the chassis, it would fail to wakeup regardless of S3/runtime suspend (freeze). If I plug the external keyboard via that USB Hub though, it would wake up the machine. The findings are consistent between S3/freeze.
This means there's something different between the way the keyboard sends its wakeup signal and the way the Genesys Logic hub sends its wakeup signal.
Can you post the output from "lsusb -t" for this system?
Keyboard plugged into the chassis:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Keyboard plugged into the hub:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 001: Dev 004, If 0, Class=Vendor Specific Class, Driver=r8152, 480M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Also, can you enable dynamic debugging for usbcore by doing:
echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
and then post the dmesg log for a suspend/resume cycle?
Keyboard plugged into the chassis (does not wake up via the external keyboard, needed to strike Fn on the internal keyboard):
[ 362.886330] PM: suspend entry (deep) [ 363.286839] Filesystems sync: 0.400 seconds [ 363.323106] Freezing user space processes [ 363.324899] Freezing user space processes completed (elapsed 0.001 seconds) [ 363.324909] OOM killer disabled. [ 363.324912] Freezing remaining freezable tasks [ 363.326107] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 363.326479] printk: Suspending console(s) (use no_console_suspend to debug) [ 363.331241] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 363.333294] usb 1-1: usb suspend, wakeup 1 [ 363.344205] usb usb8: usb auto-resume [ 363.344302] usb usb7: usb auto-resume [ 363.344380] usb usb6: usb auto-resume [ 363.344460] usb usb5: usb auto-resume [ 363.345267] usb usb3: usb auto-resume [ 363.345305] hub 3-0:1.0: hub_resume [ 363.345370] usb usb2: usb auto-resume [ 363.345426] hub 1-0:1.0: hub_suspend [ 363.345447] usb usb4: usb auto-resume [ 363.345562] usb usb1: bus suspend, wakeup 0 [ 363.345744] hub 3-0:1.0: hub_suspend [ 363.345763] usb usb3: bus suspend, wakeup 0 [ 363.345927] ata1.00: Entering standby power mode [ 363.353452] e1000e: EEE TX LPI TIMER: 00000000 [ 363.365259] hub 5-0:1.0: hub_resume [ 363.365294] hub 6-0:1.0: hub_resume [ 363.365320] hub 8-0:1.0: hub_resume [ 363.365401] hub 6-0:1.0: hub_suspend [ 363.365419] hub 5-0:1.0: hub_suspend [ 363.365435] hub 8-0:1.0: hub_suspend [ 363.365456] usb usb6: bus suspend, wakeup 0 [ 363.365487] usb usb5: bus suspend, wakeup 0 [ 363.365513] usb usb8: bus suspend, wakeup 0 [ 363.365626] hub 7-0:1.0: hub_resume [ 363.365675] hub 7-0:1.0: hub_suspend [ 363.365693] usb usb7: bus suspend, wakeup 0 [ 363.366246] hub 2-0:1.0: hub_resume [ 363.366348] hub 2-0:1.0: hub_suspend [ 363.366366] usb usb2: bus suspend, wakeup 0 [ 363.366428] hub 4-0:1.0: hub_resume [ 363.366470] hub 4-0:1.0: hub_suspend [ 363.366485] usb usb4: bus suspend, wakeup 0 [ 363.682065] ACPI: EC: interrupt blocked [ 363.682633] ehci-pci 0000:00:1d.7: wakeup: 1 [ 363.682714] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 363.682719] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 363.682757] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 363.682760] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 363.682796] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 363.682849] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 363.683087] ehci-pci 0000:00:1a.7: wakeup: 1 [ 363.683153] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 363.683215] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 363.683254] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 363.683257] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 363.683293] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 363.683338] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 363.694561] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 363.694597] ehci-pci 0000:00:1d.7: --> PCI D3hot [ 363.694767] ACPI: PM: Preparing to enter system sleep state S3 [ 363.707378] ACPI: EC: event blocked [ 363.707382] ACPI: EC: EC stopped [ 363.707383] ACPI: PM: Saving platform NVS memory [ 363.709032] Disabling non-boot CPUs ... [ 363.709032] ACPI: PM: Low-level resume complete [ 363.709032] ACPI: EC: EC started [ 363.709032] ACPI: PM: Restoring platform NVS memory [ 363.709558] ACPI: PM: Waking up from system sleep state S3 [ 363.735865] ACPI: EC: interrupt unblocked [ 363.744280] usb usb1: root hub lost power or was reset [ 363.744731] ACPI: EC: event unblocked [ 363.745248] usb usb4: root hub lost power or was reset [ 363.745456] usb usb5: root hub lost power or was reset [ 363.745679] usb usb6: root hub lost power or was reset [ 363.745740] usb usb7: root hub lost power or was reset [ 363.745797] usb usb8: root hub lost power or was reset [ 363.745872] usb usb3: usb resume [ 363.745906] hub 3-0:1.0: hub_resume [ 363.745973] usb usb4: usb resume [ 363.745982] hub 4-0:1.0: hub_reset_resume [ 363.745985] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 363.746459] usb usb5: usb resume [ 363.746469] hub 5-0:1.0: hub_reset_resume [ 363.746473] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 363.747116] usb usb6: usb resume [ 363.747126] hub 6-0:1.0: hub_reset_resume [ 363.747130] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 363.748764] usb usb7: usb resume [ 363.748775] hub 7-0:1.0: hub_reset_resume [ 363.748779] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 363.748952] usb usb1: usb resume [ 363.748961] hub 1-0:1.0: hub_reset_resume [ 363.748965] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 363.749036] usb usb8: usb resume [ 363.749045] hub 8-0:1.0: hub_reset_resume [ 363.749048] hub 8-0:1.0: trying to enable port power on non-switchable hub [ 363.750378] usb usb2: usb resume [ 363.751222] usb usb1-port1: status 0301 change 0003 [ 363.771214] hub 2-0:1.0: hub_resume [ 363.870210] usb 1-1: Waited 0ms for CONNECT [ 363.870217] usb 1-1: finish reset-resume [ 364.067770] ata2: SATA link down (SStatus 0 SControl 300) [ 364.126263] usb 1-1: reset low-speed USB device number 3 using uhci_hcd [ 364.859239] pcieport 0000:00:1c.0: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 364.859262] pcieport 0000:00:1c.1: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 364.859343] pcieport 0000:00:1c.3: pciehp: Timeout on hotplug command 0x0018 (issued 1122 msec ago) [ 364.868343] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 364.983337] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 365.212241] tpm tpm0: TPM is disabled/deactivated (0x6) [ 365.220350] ACPI: _SB_.PCI0.SATA.SCND.MSTR: docking [ 365.220462] ACPI: _SB_.PCI0.SATA.SCND.MSTR: Unable to dock! [ 365.220694] OOM killer enabled. [ 365.220702] Restarting tasks ... [ 365.222080] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 365.222105] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222120] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222134] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222148] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222205] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 365.222220] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 365.222233] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002 [ 365.222266] hub 3-0:1.0: hub_suspend [ 365.222412] usb usb3: bus auto-suspend, wakeup 1 [ 365.222459] hub 6-0:1.0: hub_suspend [ 365.222511] hub 5-0:1.0: hub_suspend [ 365.222533] usb usb6: bus auto-suspend, wakeup 1 [ 365.222567] hub 8-0:1.0: hub_suspend [ 365.222580] usb usb5: bus auto-suspend, wakeup 1 [ 365.222612] hub 7-0:1.0: hub_suspend [ 365.222630] usb usb8: bus auto-suspend, wakeup 1 [ 365.222664] hub 2-0:1.0: hub_suspend [ 365.222677] usb usb7: bus auto-suspend, wakeup 1 [ 365.222708] hub 4-0:1.0: hub_suspend [ 365.222726] usb usb2: bus auto-suspend, wakeup 1 [ 365.222767] usb usb4: bus auto-suspend, wakeup 1 [ 365.237576] done. [ 365.273727] video LNXVIDEO:00: Restoring backlight state [ 365.281300] PM: suspend exit
Keyboard plugged into the hub:
[ 300.631522] PM: suspend entry (deep) [ 300.918836] Filesystems sync: 0.287 seconds [ 300.958743] Freezing user space processes [ 300.960270] Freezing user space processes completed (elapsed 0.001 seconds) [ 300.960279] OOM killer disabled. [ 300.960282] Freezing remaining freezable tasks [ 300.961290] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 300.961619] printk: Suspending console(s) (use no_console_suspend to debug) [ 300.965734] usb 2-1.4: usb suspend, wakeup 1 [ 300.966220] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 300.975608] r8152-cfgselector 2-1.1: usb suspend, wakeup 1 [ 300.983969] usb usb8: usb auto-resume [ 300.984000] usb usb7: usb auto-resume [ 300.984027] usb usb6: usb auto-resume [ 300.984056] usb usb5: usb auto-resume [ 300.984189] usb usb4: usb auto-resume [ 300.984281] usb usb3: usb auto-resume [ 300.984317] hub 3-0:1.0: hub_resume [ 300.984469] hub 3-0:1.0: hub_suspend [ 300.984485] usb usb3: bus suspend, wakeup 0 [ 300.984598] usb usb1: usb auto-resume [ 300.986240] hub 2-1:1.0: hub_suspend [ 300.988228] usb 2-1: usb suspend, wakeup 0 [ 300.991730] e1000e: EEE TX LPI TIMER: 00000000 [ 300.999224] hub 2-0:1.0: hub_suspend [ 300.999246] usb usb2: bus suspend, wakeup 0 [ 301.002231] ata1.00: Entering standby power mode [ 301.004222] hub 8-0:1.0: hub_resume [ 301.004275] hub 8-0:1.0: hub_suspend [ 301.004293] usb usb8: bus suspend, wakeup 0 [ 301.004371] hub 6-0:1.0: hub_resume [ 301.004410] hub 6-0:1.0: hub_suspend [ 301.004424] usb usb6: bus suspend, wakeup 0 [ 301.004495] hub 7-0:1.0: hub_resume [ 301.004534] hub 7-0:1.0: hub_suspend [ 301.004548] usb usb7: bus suspend, wakeup 0 [ 301.004620] hub 5-0:1.0: hub_resume [ 301.004658] hub 5-0:1.0: hub_suspend [ 301.004672] usb usb5: bus suspend, wakeup 0 [ 301.005220] hub 4-0:1.0: hub_resume [ 301.005260] hub 4-0:1.0: hub_suspend [ 301.005275] usb usb4: bus suspend, wakeup 0 [ 301.005351] hub 1-0:1.0: hub_resume [ 301.005389] hub 1-0:1.0: hub_suspend [ 301.005403] usb usb1: bus suspend, wakeup 0 [ 301.320060] ACPI: EC: interrupt blocked [ 301.320521] ehci-pci 0000:00:1d.7: wakeup: 1 [ 301.320603] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 301.320608] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 301.320644] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 301.320648] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 301.320683] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 301.320738] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 301.320967] ehci-pci 0000:00:1a.7: wakeup: 1 [ 301.321032] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 301.321081] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 301.321119] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 301.321122] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 301.321157] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 301.321211] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 301.332213] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 301.332287] ehci-pci 0000:00:1d.7: --> PCI D3hot [ 301.333259] ACPI: PM: Preparing to enter system sleep state S3 [ 301.345826] ACPI: EC: event blocked [ 301.345829] ACPI: EC: EC stopped [ 301.345831] ACPI: PM: Saving platform NVS memory [ 301.347482] Disabling non-boot CPUs ... [ 301.358452] ACPI: PM: Low-level resume complete [ 301.358492] ACPI: EC: EC started [ 301.358494] ACPI: PM: Restoring platform NVS memory [ 301.360029] ACPI: PM: Waking up from system sleep state S3 [ 301.384290] ACPI: EC: interrupt unblocked [ 301.386938] usb usb7: root hub lost power or was reset [ 301.386996] usb usb8: root hub lost power or was reset [ 301.387109] usb usb1: root hub lost power or was reset [ 301.387451] usb usb1: usb resume [ 301.387810] hub 1-0:1.0: hub_reset_resume [ 301.388174] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 301.388828] usb usb6: root hub lost power or was reset [ 301.389860] usb usb4: root hub lost power or was reset [ 301.390026] usb usb5: root hub lost power or was reset [ 301.391115] usb usb3: usb resume [ 301.391150] hub 3-0:1.0: hub_resume [ 301.391312] usb usb2: usb resume [ 301.391371] hub 2-0:1.0: hub_resume [ 301.393298] usb usb2-port1: status 0507 change 0000 [ 301.393517] usb usb4: usb resume [ 301.393526] hub 4-0:1.0: hub_reset_resume [ 301.393529] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 301.393572] usb usb5: usb resume [ 301.393580] hub 5-0:1.0: hub_reset_resume [ 301.393583] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 301.393651] usb usb6: usb resume [ 301.393659] hub 6-0:1.0: hub_reset_resume [ 301.393661] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 301.394042] ACPI: EC: event unblocked [ 301.394380] usb usb7: usb resume [ 301.394390] hub 7-0:1.0: hub_reset_resume [ 301.394393] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 301.394846] usb usb8: usb resume [ 301.394856] hub 8-0:1.0: hub_reset_resume [ 301.394859] hub 8-0:1.0: trying to enable port power on non-switchable hub [ 301.395151] usb 2-1: usb resume [ 301.407569] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 301.446267] usb 2-1: Waited 0ms for CONNECT [ 301.446274] usb 2-1: finish resume [ 301.446496] hub 2-1:1.0: hub_resume [ 301.446738] usb 2-1-port1: status 0507 change 0000 [ 301.447487] usb 2-1-port4: status 0303 change 0004 [ 301.448488] r8152-cfgselector 2-1.1: usb resume [ 301.459266] usb 2-1.4: Waited 0ms for CONNECT [ 301.459272] usb 2-1.4: finish resume [ 301.500260] r8152-cfgselector 2-1.1: Waited 0ms for CONNECT [ 301.500267] r8152-cfgselector 2-1.1: finish resume [ 301.703719] ata2: SATA link down (SStatus 0 SControl 300) [ 302.231255] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 302.231260] clocksource: 'hpet' wd_nsec: 686990643 wd_now: e82aa5 wd_last: 5212fe mask: ffffffff [ 302.231265] clocksource: 'tsc' cs_nsec: 495997904 cs_now: 5f58466b cs_last: 360f1164 mask: ffffffffffffffff [ 302.231269] clocksource: Clocksource 'tsc' skewed -190992739 ns (-190 ms) over watchdog 'hpet' interval of 686990643 ns (686 ms) [ 302.231274] clocksource: 'tsc' is current clocksource. [ 302.231279] tsc: Marking TSC unstable due to clocksource watchdog [ 302.231309] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 302.231312] sched_clock: Marking unstable (302218066766, 1180678)<-(302494932176, -263623254) [ 302.219394] clocksource: Not enough CPUs to check clocksource 'tsc'. [ 302.219425] clocksource: Switched to clocksource hpet [ 302.494221] pcieport 0000:00:1c.1: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.494250] pcieport 0000:00:1c.0: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.494327] pcieport 0000:00:1c.3: pciehp: Timeout on hotplug command 0x0018 (issued 1123 msec ago) [ 302.503313] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 302.618321] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 302.660241] tpm tpm0: TPM is disabled/deactivated (0x6) [ 302.670557] OOM killer enabled. [ 302.670566] Restarting tasks ... [ 302.670842] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 302.670880] hub 3-0:1.0: hub_suspend [ 302.670924] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671024] hub 8-0:1.0: hub_suspend [ 302.671052] usb usb8: bus auto-suspend, wakeup 1 [ 302.671088] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671106] hub 6-0:1.0: hub_suspend [ 302.671128] usb usb6: bus auto-suspend, wakeup 1 [ 302.671161] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671179] hub 7-0:1.0: hub_suspend [ 302.671216] usb usb7: bus auto-suspend, wakeup 1 [ 302.671248] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671266] hub 5-0:1.0: hub_suspend [ 302.671287] usb usb5: bus auto-suspend, wakeup 1 [ 302.671317] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671334] hub 4-0:1.0: hub_suspend [ 302.671356] usb usb4: bus auto-suspend, wakeup 1 [ 302.671386] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 302.671403] hub 1-0:1.0: hub_suspend [ 302.671424] usb usb1: bus auto-suspend, wakeup 1 [ 302.671455] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 302.671469] hub 2-1:1.0: state 7 ports 4 chg 0000 evt 0010 [ 302.671493] usb usb3: bus auto-suspend, wakeup 1 [ 302.679716] done. [ 302.715864] video LNXVIDEO:00: Restoring backlight state [ 302.723732] PM: suspend exit
Alan Stern
Best Regards, Mingcong Bai
On Thu, Feb 06, 2025 at 11:49:49AM +0800, Mingcong Bai wrote:
On both unpatched and patched kernels, I have set power/control to "auto" for both the root hub and the external hub and left the keyboard for 60 seconds. Regardless if I plug the keyboard into the chassis or the external hub, the keyboard continues to work from the first key strike (no delay or lost input).
It's not necessary to wait 60 seconds; 10 seconds would be enough.
For the case where the keyboard is plugged into the hub, it would be best if you removed the r8152 device (network or wifi, I guess). Leaving it plugged in will prevent the external hub from going into runtime suspend unless the network interface is turned off.
You can check whether these devices have gone into runtime suspend by looking at the contents of the .../power/runtime_status attribute file. There are a couple of ways you can do this without disturbing the keyboard's status, such as by using ssh or by doing something like:
sleep 10 ; cat .../power/runtime_status
Or if you want to see the status of all your USB devices,
sleep 10 ; grep . /sys/bus/usb/devices/*/power/runtime_status
This means there's something different between the way the keyboard sends its wakeup signal and the way the Genesys Logic hub sends its wakeup signal.
Can you post the output from "lsusb -t" for this system?
Keyboard plugged into the chassis:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Keyboard plugged into the hub:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 001: Dev 004, If 0, Class=Vendor Specific Class, Driver=r8152, 480M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
Ah, okay, there's an important difference. The hub connects to an EHCI controller whereas the keyboard by itself connects to UHCI.
Also the output from "grep . /sys/bus/usb/devices/*/serial"?
And the contents of /sys/kernel/debug/usb/uhci/0000:00:1d.0?
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Also, can you enable dynamic debugging for usbcore by doing:
echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
and then post the dmesg log for a suspend/resume cycle?
Keyboard plugged into the chassis (does not wake up via the external keyboard, needed to strike Fn on the internal keyboard):
These logs are pretty much what I would expect, except for one thing:
[ 363.682633] ehci-pci 0000:00:1d.7: wakeup: 1 [ 363.682714] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 363.682719] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 363.682757] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 363.682760] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 363.682796] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 363.682849] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 363.683087] ehci-pci 0000:00:1a.7: wakeup: 1 [ 363.683153] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 363.683215] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 363.683254] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 363.683257] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 363.683293] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 363.683338] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 363.694561] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 363.694597] ehci-pci 0000:00:1d.7: --> PCI D3hot
Why do the 1d.1, 1d.2, and 1a.1 UHCI controllers remain in D0 during suspend, whereas the 1d.0, 1a.0, and 1a.2 controllers get put in D2? That's odd.
Can you send the output from "lspci -vv -s 1d.0" and "lspci -vv -s 1d.1", running as root? It may explain this behavior.
Reading through the source code, I found a comment in the UHCI driver (drivers/usb/host/uhci-hcd.c, line 328) which is highly relevant:
/* * UHCI doesn't distinguish between wakeup requests from downstream * devices and local connect/disconnect events. There's no way to * enable one without the other; both are controlled by EGSM. Thus * if wakeups are disallowed then EGSM must be turned off -- in which * case remote wakeup requests from downstream during system sleep * will be lost. * ...
Most likely this explains what you are seeing. In particular, it explains why the keyboard (when plugged directly into the computer) can't wake up the system unless wakeup is enabled on the root hub. It even explains why wakeup from runtime suspend works, because wakeup is always enabled on all USB devices during runtime suspend regardless of the setting in .../power/wakeup.
(UHCI was the first USB host controller technology to be developed; the spec is from 1996. It is very primitive compared to later controllers, in many ways. Perhaps it shouldn't be surprising that UHCI controllers can't do all that we want them to.)
Alan Stern
Hi Alan,
在 2025/2/7 05:20, Alan Stern 写道:
On Thu, Feb 06, 2025 at 11:49:49AM +0800, Mingcong Bai wrote:
On both unpatched and patched kernels, I have set power/control to "auto" for both the root hub and the external hub and left the keyboard for 60 seconds. Regardless if I plug the keyboard into the chassis or the external hub, the keyboard continues to work from the first key strike (no delay or lost input).
It's not necessary to wait 60 seconds; 10 seconds would be enough.
For the case where the keyboard is plugged into the hub, it would be best if you removed the r8152 device (network or wifi, I guess). Leaving it plugged in will prevent the external hub from going into runtime suspend unless the network interface is turned off.
You can check whether these devices have gone into runtime suspend by looking at the contents of the .../power/runtime_status attribute file. There are a couple of ways you can do this without disturbing the keyboard's status, such as by using ssh or by doing something like:
sleep 10 ; cat .../power/runtime_status
Or if you want to see the status of all your USB devices,
sleep 10 ; grep . /sys/bus/usb/devices/*/power/runtime_status
Got it, thanks for the tip.
This means there's something different between the way the keyboard sends its wakeup signal and the way the Genesys Logic hub sends its wakeup signal.
Can you post the output from "lsusb -t" for this system?
Keyboard plugged into the chassis:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Keyboard plugged into the hub:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 001: Dev 004, If 0, Class=Vendor Specific Class, Driver=r8152, 480M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
Ah, okay, there's an important difference. The hub connects to an EHCI controller whereas the keyboard by itself connects to UHCI.
Also the output from "grep . /sys/bus/usb/devices/*/serial"?
And the contents of /sys/kernel/debug/usb/uhci/0000:00:1d.0?
The enumerated USB tree changed (now to a controller at 1a.0) so I have reproduced a new set of outputs (also for the log you requested below).
`lsusb -t`:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
`grep . /sys/bus/usb/devices/*/serial`:
/sys/bus/usb/devices/usb1/serial:0000:00:1a.7 /sys/bus/usb/devices/usb2/serial:0000:00:1d.7 /sys/bus/usb/devices/usb3/serial:0000:00:1a.0 /sys/bus/usb/devices/usb4/serial:0000:00:1a.1 /sys/bus/usb/devices/usb5/serial:0000:00:1a.2 /sys/bus/usb/devices/usb6/serial:0000:00:1d.0 /sys/bus/usb/devices/usb7/serial:0000:00:1d.1 /sys/bus/usb/devices/usb8/serial:0000:00:1d.2
`cat /sys/kernel/debug/usb/uhci/0000:00:1a.0`: Root-hub state: running FSBR: 0 HC status usbcmd = 00c1 Maxp64 CF RS usbstat = 0000 usbint = 000f usbfrnum = (1)c14 flbaseadd = 03147c14 sof = 40 stat1 = 01a5 LowSpeed Enabled Connected stat2 = 0080 Most recent frame: 6fe6f (623) Last ISO frame: 6fe6f (623) Periodic load table 0 0 0 0 118 0 0 0 0 0 0 0 118 0 0 0 0 0 0 0 118 0 0 0 0 0 0 0 118 0 0 0 Total: 472, #INT: 1, #ISO: 0
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
Also, can you enable dynamic debugging for usbcore by doing:
echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
and then post the dmesg log for a suspend/resume cycle?
Keyboard plugged into the chassis (does not wake up via the external keyboard, needed to strike Fn on the internal keyboard):
These logs are pretty much what I would expect, except for one thing:
[ 363.682633] ehci-pci 0000:00:1d.7: wakeup: 1 [ 363.682714] uhci_hcd 0000:00:1d.2: wakeup: 1 [ 363.682719] uhci_hcd 0000:00:1d.2: --> PCI D0 [ 363.682757] uhci_hcd 0000:00:1d.1: wakeup: 1 [ 363.682760] uhci_hcd 0000:00:1d.1: --> PCI D0 [ 363.682796] uhci_hcd 0000:00:1d.0: wakeup: 1 [ 363.682849] uhci_hcd 0000:00:1d.0: --> PCI D2 [ 363.683087] ehci-pci 0000:00:1a.7: wakeup: 1 [ 363.683153] uhci_hcd 0000:00:1a.2: wakeup: 1 [ 363.683215] uhci_hcd 0000:00:1a.2: --> PCI D2 [ 363.683254] uhci_hcd 0000:00:1a.1: wakeup: 1 [ 363.683257] uhci_hcd 0000:00:1a.1: --> PCI D0 [ 363.683293] uhci_hcd 0000:00:1a.0: wakeup: 1 [ 363.683338] uhci_hcd 0000:00:1a.0: --> PCI D2 [ 363.694561] ehci-pci 0000:00:1a.7: --> PCI D3hot [ 363.694597] ehci-pci 0000:00:1d.7: --> PCI D3hot
Why do the 1d.1, 1d.2, and 1a.1 UHCI controllers remain in D0 during suspend, whereas the 1d.0, 1a.0, and 1a.2 controllers get put in D2? That's odd.
Can you send the output from "lspci -vv -s 1d.0" and "lspci -vv -s 1d.1", running as root? It may explain this behavior.
`lspci -vv -s 1d.0`:
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo ThinkPad T400 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 20 Region 4: I/O ports at 1860 [size=32] Capabilities: [50] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: uhci_hcd
`lspci -vv -s 1d.1`:
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo ThinkPad T400 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 21 Region 4: I/O ports at 1880 [size=32] Capabilities: [50] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: uhci_hcd
Reading through the source code, I found a comment in the UHCI driver (drivers/usb/host/uhci-hcd.c, line 328) which is highly relevant:
/* * UHCI doesn't distinguish between wakeup requests from downstream * devices and local connect/disconnect events. There's no way to * enable one without the other; both are controlled by EGSM. Thus * if wakeups are disallowed then EGSM must be turned off -- in which * case remote wakeup requests from downstream during system sleep * will be lost. * ...
Most likely this explains what you are seeing. In particular, it explains why the keyboard (when plugged directly into the computer) can't wake up the system unless wakeup is enabled on the root hub. It even explains why wakeup from runtime suspend works, because wakeup is always enabled on all USB devices during runtime suspend regardless of the setting in .../power/wakeup.
(UHCI was the first USB host controller technology to be developed; the spec is from 1996. It is very primitive compared to later controllers, in many ways. Perhaps it shouldn't be surprising that UHCI controllers can't do all that we want them to.)
This all makes sense. Since Huacai's patch was originally intended to fix Loongson's OHCI implementation, I was beginning to suspect if it exists for OHCI implementations found on older x86 platforms, say, AMD's SB600/700 series south bridges. Also to see if this issue is shared between OHCI and UHCI.
I have purchased a motherboard to test this and will report back as soon as I get my hands on it.
Alan Stern
Best Regards, Mingcong Bai
Hi Alan,
<snip>
This all makes sense. Since Huacai's patch was originally intended to fix Loongson's OHCI implementation, I was beginning to suspect if it exists for OHCI implementations found on older x86 platforms, say, AMD's SB600/700 series south bridges. Also to see if this issue is shared between OHCI and UHCI.
I have purchased a motherboard to test this and will report back as soon as I get my hands on it.
I have since purchased a Gigabyte GA-78LMT-S2 motherboard with an SB710 south bridge, the USB OHCI controllers and USB device tree are as follows:
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 00:12.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller [1002:4398] 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 00:13.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller [1002:4398] 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub |__ Port 002: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 17ef:6099 Lenovo |__ Port 003: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 046d:c077 Logitech, Inc. Mouse /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/2p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub
Long story short - wake from keyboard via OHCI works (as opposed to what we have found with the Loongson XA61200 motherboard, which also has an OHCI controller, but in its 7A2000 bridge chip).
Huacai, I suspect that we are looking at a Loongson-specific issue.
For your reference, here are the equivalent logs which I have supplied for the ThinkPad X200s (which, according to my previous testing, failed to wake up from an external keyboard plugged into its UHCI interface). The OHCI to which the keyboard is connected to on this motherboard corresponds to PCI device 0000:00:13.1:
`grep . /sys/bus/usb/devices/*/serial`:
/sys/bus/usb/devices/usb1/serial:0000:00:12.0 /sys/bus/usb/devices/usb2/serial:0000:00:12.2 /sys/bus/usb/devices/usb3/serial:0000:00:13.2 /sys/bus/usb/devices/usb4/serial:0000:00:12.1 /sys/bus/usb/devices/usb5/serial:0000:00:13.0 /sys/bus/usb/devices/usb6/serial:0000:00:13.1 /sys/bus/usb/devices/usb7/serial:0000:00:14.5
`cat /sys/kernel/debug/usb/ohci/0000:00:13.1/*`:
size = 32 0 [117]: ed8/00000000dd878181 (ls dev4 ep1in-int qlen 1 max 8 00083084) 1 [ 92]: ed8/000000001f1ee77f (ls dev3 ep1in-int qlen 1 max 4 00043083) 8 [117]: ed8/00000000dd878181 9 [ 92]: ed8/000000001f1ee77f 16 [117]: ed8/00000000dd878181 17 [ 92]: ed8/000000001f1ee77f 24 [117]: ed8/00000000dd878181 25 [ 92]: ed8/000000001f1ee77f bus pci, device 0000:00:13.1 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x28f RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x00000 SOC=0 intrstatus 0x00000024 FNO SF intrenable 0x8000005a MIE RHSC UE RD WDH ed_controlhead 0108d0e0 hcca frame 0x6d8a fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001dd1 FRT FR=0x1dd1 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000b03 POTPGT=2 OCPM NPS PSM NDP=3(3) roothub.b 00000000 PPCM=0000 DR=0000 roothub.status 00008000 DRWE roothub.portstatus [0] 0x00000100 PPS roothub.portstatus [1] 0x00000303 LSDA PPS PES CCS roothub.portstatus [2] 0x00000303 LSDA PPS PES CCS
`lspci -vv -s 13.0`:
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller (prog-if 10 [OHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-78/880-series motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 NUMA node: 0 Region 0: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci
`lspci -vv -s 13.1`:
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller (prog-if 10 [OHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-MA78GM-S2H motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 NUMA node: 0 Region 0: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci
Best Regards, Mingcong Bai
Hi again,
Oops. I missed the dmesg.
在 2025/2/9 18:19, Mingcong Bai 写道:
Hi Alan,
<snip>
This all makes sense. Since Huacai's patch was originally intended to fix Loongson's OHCI implementation, I was beginning to suspect if it exists for OHCI implementations found on older x86 platforms, say, AMD's SB600/700 series south bridges. Also to see if this issue is shared between OHCI and UHCI.
I have purchased a motherboard to test this and will report back as soon as I get my hands on it.
I have since purchased a Gigabyte GA-78LMT-S2 motherboard with an SB710 south bridge, the USB OHCI controllers and USB device tree are as follows:
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 00:12.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller [1002:4398] 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 00:13.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller [1002:4398] 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/6p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/3p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub |__ Port 002: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 17ef:6099 Lenovo |__ Port 003: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ID 046d:c077 Logitech, Inc. Mouse /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/2p, 12M ID 1d6b:0001 Linux Foundation 1.1 root hub
Long story short - wake from keyboard via OHCI works (as opposed to what we have found with the Loongson XA61200 motherboard, which also has an OHCI controller, but in its 7A2000 bridge chip).
Huacai, I suspect that we are looking at a Loongson-specific issue.
For your reference, here are the equivalent logs which I have supplied for the ThinkPad X200s (which, according to my previous testing, failed to wake up from an external keyboard plugged into its UHCI interface). The OHCI to which the keyboard is connected to on this motherboard corresponds to PCI device 0000:00:13.1:
`grep . /sys/bus/usb/devices/*/serial`:
/sys/bus/usb/devices/usb1/serial:0000:00:12.0 /sys/bus/usb/devices/usb2/serial:0000:00:12.2 /sys/bus/usb/devices/usb3/serial:0000:00:13.2 /sys/bus/usb/devices/usb4/serial:0000:00:12.1 /sys/bus/usb/devices/usb5/serial:0000:00:13.0 /sys/bus/usb/devices/usb6/serial:0000:00:13.1 /sys/bus/usb/devices/usb7/serial:0000:00:14.5
`cat /sys/kernel/debug/usb/ohci/0000:00:13.1/*`:
size = 32 0 [117]: ed8/00000000dd878181 (ls dev4 ep1in-int qlen 1 max 8 00083084) 1 [ 92]: ed8/000000001f1ee77f (ls dev3 ep1in-int qlen 1 max 4 00043083) 8 [117]: ed8/00000000dd878181 9 [ 92]: ed8/000000001f1ee77f 16 [117]: ed8/00000000dd878181 17 [ 92]: ed8/000000001f1ee77f 24 [117]: ed8/00000000dd878181 25 [ 92]: ed8/000000001f1ee77f bus pci, device 0000:00:13.1 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x28f RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x00000 SOC=0 intrstatus 0x00000024 FNO SF intrenable 0x8000005a MIE RHSC UE RD WDH ed_controlhead 0108d0e0 hcca frame 0x6d8a fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001dd1 FRT FR=0x1dd1 periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 02000b03 POTPGT=2 OCPM NPS PSM NDP=3(3) roothub.b 00000000 PPCM=0000 DR=0000 roothub.status 00008000 DRWE roothub.portstatus [0] 0x00000100 PPS roothub.portstatus [1] 0x00000303 LSDA PPS PES CCS roothub.portstatus [2] 0x00000303 LSDA PPS PES CCS
`lspci -vv -s 13.0`:
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/ SB8x0/SB9x0 USB OHCI0 Controller (prog-if 10 [OHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-78/880-series motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 NUMA node: 0 Region 0: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci
`lspci -vv -s 13.1`:
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller (prog-if 10 [OHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-MA78GM-S2H motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 NUMA node: 0 Region 0: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci
`dmesg` of the suspend sequence with dynamic debug on `usbcore`:
[ 1113.101923] PM: suspend entry (deep) [ 1113.145038] Filesystems sync: 0.043 seconds [ 1113.209491] Freezing user space processes [ 1113.211153] Freezing user space processes completed (elapsed 0.001 seconds) [ 1113.211163] OOM killer disabled. [ 1113.211165] Freezing remaining freezable tasks [ 1113.212471] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 1113.212497] printk: Suspending console(s) (use no_console_suspend to debug) [ 1113.214870] usb usb7: usb auto-resume [ 1113.215460] serial 00:03: disabled [ 1113.215540] usb 6-3: usb suspend, wakeup 0 [ 1113.216021] usb usb5: usb auto-resume [ 1113.216177] usb usb4: usb auto-resume [ 1113.216546] usb 6-2: usb suspend, wakeup 1 [ 1113.217234] usb usb3: usb auto-resume [ 1113.217406] usb usb2: usb auto-resume [ 1113.217440] hub 2-0:1.0: hub_resume [ 1113.217499] hub 2-0:1.0: hub_suspend [ 1113.217508] usb usb2: bus suspend, wakeup 0 [ 1113.218431] usb usb1: usb auto-resume [ 1113.218463] sd 4:0:0:0: [sda] Synchronizing SCSI cache [ 1113.220421] ata5.00: Entering standby power mode [ 1113.228391] hub 6-0:1.0: hub_suspend [ 1113.228413] usb usb6: bus suspend, wakeup 0 [ 1113.238347] hub 3-0:1.0: hub_resume [ 1113.238404] hub 3-0:1.0: hub_suspend [ 1113.238414] usb usb3: bus suspend, wakeup 0 [ 1113.263489] hub 7-0:1.0: hub_resume [ 1113.263522] hub 7-0:1.0: hub_suspend [ 1113.263531] usb usb7: bus suspend, wakeup 0 [ 1113.264405] hub 5-0:1.0: hub_resume [ 1113.264429] hub 4-0:1.0: hub_resume [ 1113.264450] hub 5-0:1.0: hub_suspend [ 1113.264458] usb usb5: bus suspend, wakeup 0 [ 1113.264600] hub 4-0:1.0: hub_suspend [ 1113.264621] usb usb4: bus suspend, wakeup 0 [ 1113.268364] hub 1-0:1.0: hub_resume [ 1113.268414] hub 1-0:1.0: hub_suspend [ 1113.268425] usb usb1: bus suspend, wakeup 0 [ 1114.710476] ohci-pci 0000:00:14.5: wakeup: 1 [ 1114.710501] ohci-pci 0000:00:14.5: --> PCI D0 [ 1114.710605] ohci-pci 0000:00:13.1: wakeup: 1 [ 1114.710610] ohci-pci 0000:00:13.1: --> PCI D0 [ 1114.710615] ohci-pci 0000:00:13.0: wakeup: 1 [ 1114.710635] ohci-pci 0000:00:13.0: --> PCI D0 [ 1114.710641] ehci-pci 0000:00:12.2: wakeup: 1 [ 1114.710669] ohci-pci 0000:00:12.1: wakeup: 1 [ 1114.710674] ohci-pci 0000:00:12.1: --> PCI D0 [ 1114.710705] ohci-pci 0000:00:12.0: wakeup: 1 [ 1114.710710] ohci-pci 0000:00:12.0: --> PCI D0 [ 1114.710752] ehci-pci 0000:00:13.2: wakeup: 1 [ 1114.722478] ehci-pci 0000:00:13.2: --> PCI D3hot [ 1114.722570] ehci-pci 0000:00:12.2: --> PCI D3hot [ 1114.722596] ACPI: PM: Preparing to enter system sleep state S3 [ 1114.722737] ACPI: PM: Saving platform NVS memory [ 1114.722777] Disabling non-boot CPUs ... [ 1114.724483] smpboot: CPU 1 is now offline [ 1114.725283] ACPI: PM: Low-level resume complete [ 1114.725303] ACPI: PM: Restoring platform NVS memory [ 1114.725347] LVT offset 1 assigned for vector 0x400 [ 1114.725359] LVT offset 1 assigned [ 1114.725707] Enabling non-boot CPUs ... [ 1114.725747] smpboot: Booting Node 0 Processor 1 APIC 0x1 [ 1114.728737] CPU1 is up [ 1114.729088] ACPI: PM: Waking up from system sleep state S3 [ 1114.729555] ahci 0000:00:11.0: set SATA to AHCI mode [ 1114.743246] serial 00:03: activated [ 1114.756206] [drm] PCIE gen 2 link speeds already enabled [ 1114.764122] usb usb1: root hub lost power or was reset [ 1114.764173] usb usb7: root hub lost power or was reset [ 1114.764205] usb usb4: root hub lost power or was reset [ 1114.764219] usb usb6: root hub lost power or was reset [ 1114.764237] usb usb4: usb resume [ 1114.764254] usb usb5: root hub lost power or was reset [ 1114.764271] usb usb1: usb resume [ 1114.764276] usb usb2: usb resume [ 1114.764294] usb usb3: usb resume [ 1114.764316] hub 2-0:1.0: hub_resume [ 1114.764380] usb usb5: usb resume [ 1114.764399] usb usb6: usb resume [ 1114.768550] usb usb7: usb resume [ 1114.769473] [drm] PCIE GART of 2048M enabled (table at 0x0000000000165000). [ 1114.769571] radeon 0000:01:00.0: WB enabled [ 1114.769574] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 [ 1114.769576] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 [ 1114.769578] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 [ 1114.769579] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c [ 1114.769581] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 [ 1114.769982] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 [ 1114.785155] hub 3-0:1.0: hub_resume [ 1114.819119] hub 5-0:1.0: hub_reset_resume [ 1114.819122] hub 5-0:1.0: trying to enable port power on non-switchable hub [ 1114.819145] hub 4-0:1.0: hub_reset_resume [ 1114.819151] hub 4-0:1.0: trying to enable port power on non-switchable hub [ 1114.819156] hub 1-0:1.0: hub_reset_resume [ 1114.819158] hub 1-0:1.0: trying to enable port power on non-switchable hub [ 1114.823143] hub 7-0:1.0: hub_reset_resume [ 1114.823149] hub 7-0:1.0: trying to enable port power on non-switchable hub [ 1114.830220] hub 6-0:1.0: hub_reset_resume [ 1114.830226] hub 6-0:1.0: trying to enable port power on non-switchable hub [ 1114.835158] usb usb6-port2: status 0307 change 0000 [ 1114.835175] usb usb6-port3: status 0307 change 0000 [ 1114.835224] usb 6-3: usb resume [ 1114.835228] usb 6-2: usb resume [ 1114.887136] usb 6-3: Waited 0ms for CONNECT [ 1114.887143] usb 6-3: finish reset-resume [ 1114.887160] usb 6-2: Waited 0ms for CONNECT [ 1114.887161] usb 6-2: finish reset-resume [ 1114.931454] ata5.00: ACPI cmd ef/03:08:00:00:00:a0(SET FEATURES) filtered out [ 1114.931462] ata5.00: ACPI cmd ef/03:20:00:00:00:a0(SET FEATURES) filtered out [ 1114.945495] [drm] ring test on 0 succeeded in 1 usecs [ 1114.945504] [drm] ring test on 1 succeeded in 1 usecs [ 1114.945508] [drm] ring test on 2 succeeded in 1 usecs [ 1114.945515] [drm] ring test on 3 succeeded in 3 usecs [ 1114.945521] [drm] ring test on 4 succeeded in 3 usecs [ 1114.958500] sd 4:0:0:0: [sda] Starting disk [ 1115.048845] ata4: SATA link down (SStatus 0 SControl 300) [ 1115.048886] ata2: SATA link down (SStatus 0 SControl 300) [ 1115.048916] ata1: SATA link down (SStatus 0 SControl 300) [ 1115.048946] ata3: SATA link down (SStatus 0 SControl 300) [ 1115.122985] [drm] ring test on 5 succeeded in 2 usecs [ 1115.122990] [drm] UVD initialized successfully. [ 1115.123034] [drm] ib test on ring 0 succeeded in 0 usecs [ 1115.123067] [drm] ib test on ring 1 succeeded in 0 usecs [ 1115.123098] [drm] ib test on ring 2 succeeded in 0 usecs [ 1115.123130] [drm] ib test on ring 3 succeeded in 0 usecs [ 1115.123160] [drm] ib test on ring 4 succeeded in 0 usecs [ 1115.158192] usb 6-2: reset low-speed USB device number 4 using ohci-pci [ 1115.726225] usb 6-3: reset low-speed USB device number 3 using ohci-pci [ 1115.779259] [drm] ib test on ring 5 succeeded [ 1116.033742] OOM killer enabled. [ 1116.033752] Restarting tasks ... [ 1116.033903] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 1116.033950] hub 5-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.033959] hub 2-0:1.0: hub_suspend [ 1116.033973] hub 5-0:1.0: hub_suspend [ 1116.034013] usb usb2: bus auto-suspend, wakeup 1 [ 1116.034032] usb usb5: bus auto-suspend, wakeup 1 [ 1116.034113] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 1116.034133] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 1116.034181] hub 4-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.034195] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1116.034207] hub 6-0:1.0: state 7 ports 3 chg 0000 evt 0008 [ 1116.035547] done. [ 1116.035977] PM: suspend exit [ 1116.048179] hub 3-0:1.0: hub_suspend [ 1116.048201] usb usb3: bus auto-suspend, wakeup 1 [ 1116.049119] hub 7-0:1.0: hub_suspend [ 1116.050939] usb usb7: bus auto-suspend, wakeup 1 [ 1116.050966] hub 4-0:1.0: hub_suspend [ 1116.051052] usb usb4: bus auto-suspend, wakeup 1 [ 1116.051075] hub 1-0:1.0: hub_suspend [ 1116.051083] usb usb1: bus auto-suspend, wakeup 1 [ 1116.529188] RTL8211E Gigabit Ethernet r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) [ 1116.765376] r8169 0000:02:00.0 enp2s0: Link is Down [ 1119.704013] r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control off
Best Regards, Mingcong Bai
Hi Alan,
在 2025/2/9 18:22, Mingcong Bai 写道:
Hi again,
Oops. I missed the dmesg.
<snip>
Gentle ping as it has been almost a month since our last correspondence. Can you please advise if you would need any further information and, since the fix is probably incorrect, if you have any suggestions as to how we could move forward with a better fix or platform-specific quirk?
Best Regards, Mingcong Bai
On Wed, Feb 26, 2025 at 01:41:14AM +0800, Mingcong Bai wrote:
Hi Alan,
在 2025/2/9 18:22, Mingcong Bai 写道:
Hi again,
Oops. I missed the dmesg.
<snip>
Gentle ping as it has been almost a month since our last correspondence. Can you please advise if you would need any further information and, since the fix is probably incorrect, if you have any suggestions as to how we could move forward with a better fix or platform-specific quirk?
I was waiting to see if your last email (Feb 9) to Huacai Chen got a reply, since you suggested the problem was Loongson-specific.
As for a platform-specific solution... I wonder if it might not be better to fix this in userspace, by making Powertop (or whatever tool is responsible for managing wakeup settings) automatically enable root-hub wakeups on Loongson platforms.
Another possibility is to ask somebody at Intel if Loongson has some special way to handle UHCI wakeups that we don't currently support. The driver does contain support for the USBRES_INTEL register (see uhci-hcd.h and uhci-pci.c). Is this different for Loongson?
Alan Stern
linux-stable-mirror@lists.linaro.org
-
Alan Stern -
Greg Kroah-Hartman -
Huacai Chen -
Huacai Chen -
Mingcong Bai