How to unload a module prior to suspend and reload it afterwards?

Upon entering the command

systemctl suspend

my machine would go to sleep only to wake up immediately. I eventually found the culprit. After executing

sudo modprobe -r xhci_pci 

my machine suspends fine. This module is still useful for stuff like USB memory drives so I need to reload it afterwards.

What is the correct way to automate this?

This is likely more akin to an YX problem.

XyProblem - Greg's Wiki

Whatever the case - and while this is doable - this might not be the best approach.

There is this (and likely much more) in the Arch wiki:

Power management/Suspend and hibernate - ArchWiki

It would help others help you if you could provide info on your hardware, too.
See how to best do that in the introductory threads under the label:
“How to provide good information”.

1 Like

Thanks for the quick reply.

I’ve never heard of this expression before! It’s interesting. Let me reframe my question as a YX problem and give the required context.

X (the actual the problem): My laptop does not to go to sleep when I close the lid lid.
Y (the question I’m asking that I think will solve my problem): Is there a way to automatically unload a given module as before the system goes to sleep and then reload when the system wakes up? Alternatively Is there a way to run a script with root privileges right before the system goes to sleep and another after it wakes up?

The fact is, if I first open a terminal and unload the module and close my laptop lid, then my laptop goes to sleep. If I do not do this, the laptop stays on and my backpack gets very hot.

I just want my laptop to go to sleep when I close the lid, without having that extra step. I could give more info about my computer or paste injournalctl outputs, but I honestly don’t think this is useful. Basically, reading throught the output of journalctl when I close my laptop lid, I see that the system starts going into sleep but then something happens that prevents it from entering the sleep state. Unloading the module beforehand fixes the problem.

Could somebody please answer my Y question?

Also I have looked at this below, but I don’t understand it.

I think they were trying to get at the idea that you may want to disable some powersaving setting for the USB to autosleep or something similar, rather than unloading/reloading the module.

That said … I’m not sure exactly what would be the best solution.

I had some examples of wireless cards that would fail if I did not do a unload/reload dance for suspend.

In that spirit heres this;

/etc/systemd/system/restart-xhci.service :

Description=Disable and reenable xhci_pci module

ExecStart=/usr/bin/rmmod xhci_pci
ExecStart=/usr/bin/sleep 1
ExecStop=/usr/bin/sleep 1
ExecStop=/usr/bin/modprobe xhci_pci


And do the enable thing:

systemctl enable restart-xhci
1 Like

You managed to misinterpret what the expression “xy problem” means. :grin:
That’s o.k.
My own irony detector is defunct since time immemorial.

Although you already got a ready made solution following your path of thinking
still no one but you knows anything about your system.

… which is what I was asking for, in a not very direct way :wink:

If it works with the given solution: fine!
It still might just be a crutch, a workaround, not actually addressing the cause of the problem.

Yes! This is exactly what I wanted! Thanks. I suspect we have similar issues.

I’ll try to implement the solution sometime this week and I’ll report back.

No worries. I know it`s important to ask questions properly in order to maintain the quality of the forum. I don’t mind getting schooled :slight_smile:

I now realize that with so little context my post isn’t much use to others. I’ll edit my question when I get around to it.