USB 2.0 ports doesn´t works after suspend mode

linux

#1

I’m using an ACER Aspire E1-522 with Mint 19 and today I upgraded to 19.1 but in both versions, after entered in suspend mode and wake up again, the USB 2.0 ports doesn’t work, but USB 3.0 works fine.
I think the USB has power because the mouse has the LED ON but the cursor doesn’t move connecting mouse in any USB 2.0 port
any Idea?


Is my laptop too old to run Mint 19.1?
#2

Does a USB stick connect/mount to your file system, and can you to transfer a file, between.

Wireless or Wired Mouse.? If a wireless mouse, try a new battery, first.


#3

Hi @mack,
Thanks for the reply
I already tried with two wired mouses and 1 wireless mouse without success
This problem only occurs with mouses. USB pens works without problems after suspend mode


#4

I suppose that you have tried the Drive Manager to install them? If you have you can try here, https://community.linuxmint.com/hardware/search - One final thing the USB 3 port should be backward compatible with USB 2 devices so if it works when you place it in there it should work as well. Other than that you can restart in compatibility mode and that might help as well. This is explained here https://linuxmint-installation-guide.readthedocs.io/en/latest/boot_options.html -


#5

sounds like those particular ports went into charge mode when your system was suspended and didn’t wake back up. is it possible there is a bios/uefi setting that is off?


#6

@cordx,
I can’t find nothing in uefi to turn off USB after suspend mod

@ElectricDandySlider
I’ll try the compatibility mode and after I’ll give you the feedback

Thanks


#7

The following are a process of elimination, unless a fellow member has experienced your specific issue, with a similar laptop. Your problem has affected numerous other laptop users with Window 7 installed.

Acer Manual

Ubuntu wiki - AspireOne522 - suspend seem to related to display issues.
https://help.ubuntu.com/community/AspireOne522

Before applying the Linuxmint community suggestion, below, you could try Power settings, by turning off Suspend to Never, to see if this solves your conundrum.

Linuxmint community blog about aggressive sleep mode
https://community.linuxmint.com/idea/view/5482

How to disiable hibernation
sudo mv -v /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla /
Then REBOOT

:thinking:


#8

@ElectricDandySlider,
I restarted in compatibility mode but didn’t solve this fault

I did more tests after suspend mode:

  • USB 3.0 Port - works with any pheripheral
  • USB 2.0 Ports - works with any pen i’ve tested it ( lists in lsusb)
  • USB 2.0 ports - doesn´t activated with USB mouses and USB keyboard (doesn’t list in lsusb)
  • Touchpad - works

The mouse works


#9

Excellent, can you mark this as solved, and who’s answer helped you. For future reference. :sunglasses:


#10

@mack,
thanks for the reply
in the link you sent to me https://community.linuxmint.com/idea/view/5482 they mention the suspend to RAM is fixed in Mint V19

My question to understand this fault is:

  • Why USB PENS works but mouse cannot be activated?

I think the problem is with the usbhid driver.
How can I reload this specific driver or restart this service?

Image:
lsusb before and after suspend mode (not hibernate):


#11

that was my thought when i was searching last night and came across the link below. not the first (accepted) answer, but the second one with 24 votes that uses echo seems to address the possibility of switching states from “suspend” to “on”. disclaimer: i haven’t tried this. i was waiting to see if you worked it out some other way. i am interested to see if it works and will give it a go here in the next couple hours. bonus: there are all kinds of other bites at this particular apple in the following solutions in case the echo command is not successful.


#12

Okay so a little more digging around and I came across this to try installing acpitool and try examining the status before and after suspending - sudo apt-get install acpitool
acpitool -w

I have looked elsewhere and haven’t found another mention as yet - as there isn’t anything in the bugs sections for 19.1


#13

perhaps not. i got two errors running echo on > /sys/bus/usb/devices/usb5/power/level. the first was:

power/level is deprecated use power/control instead

the second (and more important) being “permission denied” even when using sudo.


#14

Did changing the Suspend to Never get your USB mouse to function.?

I mentioned the Linuxmint community blog (and gave you the previous work around script) as he said it appeared (not being 100% sure) to have overcome this bug.

Your comment suspecting the driver=usbhid, I did came across articles mentioning this, but they seemed unrelated, to your specific problem of not waking from suspend.

Included screenshot, for some reason the article is showing up as a different question.
https://askubuntu.com/questions/714973/reboot-disable-and-enable-usb-ports/ This link works

Awake from suspend, again seemed unrelated to your specific issue.

All I can suggest at this juncture, is that a member who has experienced your specific issue, can guide you to find the technical answer you seek.

:thinking:


#15

i am wondering if dmesg --level=err or dmesg --level=warn might give any hints as to what might be wrong.


#16

updating the subject…
Thank you all for your help

@ElectricDandySlider,
the acpitool -w status before suspend:

  1. GPP0 S0 *disabled pci:0000:00:02.2
  2. GPP1 S0 *disabled pci:0000:00:02.3
  3. OHC1 S4 *enabled pci:0000:00:12.0
  4. OHC2 S4 *enabled pci:0000:00:13.0
  5. OHC3 S4 *disabled
  6. EHC1 S4 *enabled pci:0000:00:12.2
  7. EHC2 S4 *enabled pci:0000:00:13.2
  8. EHC3 S4 *disabled
  9. XHC0 S4 *enabled pci:0000:00:10.0
  10. LID0 S3 *enabled platform:PNP0C0D:00
  11. SLPB S3 *enabled platform:PNP0C0E:00

after suspend:

  1. GPP0 S0 *disabled pci:0000:00:02.2
  2. GPP1 S0 *disabled pci:0000:00:02.3
  3. OHC1 S4 *enabled pci:0000:00:12.0
  4. OHC2 S4 *enabled pci:0000:00:13.0
  5. OHC3 S4 *disabled
  6. EHC1 S4 *enabled pci:0000:00:12.2
  7. EHC2 S4 *enabled pci:0000:00:13.2
  8. EHC3 S4 *disabled
  9. XHC0 S4 *enabled pci:0000:00:10.0
  10. LID0 S3 *enabled platform:PNP0C0D:00
  11. SLPB S3 *enabled platform:PNP0C0E:00

I can’t seem to find any change

@cordx,
The power level initial of USB ports was “ON”. I did several tests, changing power level and autosuspend without success

I already did some tests with code of answer with 15 votes and before suspend mode, unbind and bind the USB ports, the mouse reacts to these commands. After suspend mode, the problem maintains

@mack,
probably i misunderstood you first response. I changed the power settings from “Suspend” to “Never” but with this change, the laptop never enter in suspend mode so mouse keeps working without any problem but I would like to have the suspend mode activated so that’s the reason I keep testing this strange behavior only for mouse and keyboard.
About the screenshot you posted:

  • It’s possible to unbind and bind ‘3-1’ device (in my case) before suspend. After suspend it’ gives an error message “No such device” (I don’t have laptop with me to confirm the error but later I’ll edit the error message)

About your question:

How can I change this? did you refer to change /sys/bus/usb/devices/‘my-mouse’/power/autosuspend ?
I already did this test too

Late or tomorrow I’ll keep trying to do more tests, dmesg too and I’ll update this topic with results


#17

Thanks for the updates, that was good of you to do so. Have you looked here to see if there is an answer ? https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/ or tried reporting it? Sorry if you have, but I’ve no other idea at present


#18

I haven’t report it yet.
I would like to do more tests before report and I’m using this “error” to learn more about linux

I just read this about changing a line in grub config and could be one more tip to try it:


#19

@cordx,
you’re right. I have some errors related to the USB port after suspending

Before suspending:
dmesg --level=err
[ 2.769543] Couldn’t get size: 0x800000000000000e
[ 2.769552] MODSIGN: Couldn’t get UEFI db list
[ 2.769622] Couldn’t get size: 0x800000000000000e

After suspending:
dmesg --level=err
[ 2.769543] Couldn’t get size: 0x800000000000000e
[ 2.769552] MODSIGN: Couldn’t get UEFI db list
[ 2.769622] Couldn’t get size: 0x800000000000000e
[ 836.062810] ohci-pci 0000:00:12.0: frame counter not updating; disabled
[ 836.062813] ohci-pci 0000:00:12.0: HC died; cleaning up
[ 840.894748] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -22
[ 840.894767] PM: Device 3-1 failed to resume async: error -22

Here’s my conclusion from my latest tests:
The bus used for the mouse uses the driver ohci-pci and I think this driver is related to USB 1.1
but when I use a USB Pen in the same USB physical port, the bus used is a different one and uses the driver echi-pci:

  • Bus used for the mouse:
    /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M

  • Bus used for the USB Pen:
    /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
    |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M

When I did the first tests to unbind and bind the USB port I used these commands so restart the drivers:
echo ‘3-1’ > /sys/bus/usb/drivers/usb/unbind
echo ‘3-1’ > /sys/bus/usb/drivers/usb/bind

Today, after seeing the error message with dmesg, I tried reseting the controller after suspending the laptop with the commands below and I’ve realized that the mouse started working again:
echo ‘0000:00:12.0’ > /sys/bus/pci/drivers/ohci-pci/unbind
echo ‘0000:00:12.0’ > /sys/bus/pci/drivers/ohci-pci/bind

I’m still trying to figure out more about this matter but so far I only found two possible causes for the controller error:

  • Could be hardware fault;
  • Could be kernel bug.

Now, I guess I’ve reached my limit and I don’t know what more I can do to try to solve this problem before reporting it as a kernel bug

I haven’t given up yet, does anyone have any ideas?

I’d like to thank all of you for your support, reply’s and input on this matter, because it allowed me to learn more about linux to troubleshoot this problem


#20

Thanks for your keeping us updated as you’ve gone along @Tech_JA I think we’ve all learnt something from it by doing.
If you get to the bottom of this (as we say here) or find a solution, please will you update us.