I think at this point this is what you should do. I find it probable, that this might be a kernel-related bug, because I had/have an issue with Linux on my Laptop for years now. The USB (even the internal ones) ports work only after restarting the distribution. Not booting. Not suspending. But only rebooting makes them work, for whatever reason. If that laptop wouldn’t have a touch screen to issue the reboot from, then it would be impossible to use Linux on it.
quite agreed that you’ve done some serious legwork on this one. i noticed as you did that the same physical port was identified differently based on whether it had my usb mouse or a usb 3.0 external drive (i didn’t think to look at the drivers. that part is interesting as well), but that is about as far as my technical knowledge gets me.
do i understand correctly from your most recent post that the
echo unbind/bind sequence gets you access to your mouse again? i know that isn’t technically a fix (more of a workaround?), but at least it relieves you from having to reboot. heck, throw that in a shell script to keep from having to re-type every time and you are a double click away from being back up and running in no time
again, great work on this one and thank you for keeping us apprised as @ElectricDandySlider said above.
Thank you all for the overwhelming support
I don’t know much about Linux, so I took this issue as an personal challenge and a way to learn more about the OS itself. That’s why I’m always asking a lot of questions and updating you guys as I get new insight on this matter.
In my last update, I had the following error:
[ 2.769543] Couldn’t get size: 0x800000000000000e
[ 2.769552] MODSIGN: Couldn’t get UEFI db list
[ 2.769622] Couldn’t get size: 0x800000000000000e
I can say that it is solved - I was using the 4.15.0-45-generic kernel and after updating to the kernel to 4.18.0-15-generic version, the error was gone but the suspend mode problem still persists.
Now I don’t think I’m able to solve this any further.
Yes, I’ve made a script for that. I’m still trying to find a way to automate it for when waking up the laptop after suspending.
Yes, I’ll report this issue.
What would be the best place to report this error, keeping in mind that I’m using a Mint distro?
Well, since it’s a kernel thing you’d need to report it to the Ubuntu forum in the kernel category (if such thing exists) or the Ubuntu repository for the Linux kernel. If Mint do not just copy the Ubuntu kernel, but add their own modifications, then you can start in the Mint forum or their kernel repository, again, if such exists.
Unfortunately, usually you start by the closest maintainer and they keep redirecting you upwards, so you will probably eventually end up at the original Linux kernel or 1 level lower. Another issue is, that your problem is apparently extremely rare or unique (as is mine) because else they would fix such a critical bug within hours, if it would affect a big amount of users, especially whales, like companies or entities of such sort.
Nevertheless, maybe just start at the Mint forum, asking for help from actual developers or maintainers of Mint OS. They should (I hope) lead you on the right path. After all, you are using Linux Mint and it should be their concern, at the very least on the first level of investigation.
wanted to make this reminder comment before i forget: there is a service called cron (well, that is in ubuntu. will check on mint. i believe it is a debian holdover. so probably?) that can run jobs at startup or reboot (not sure about waking from suspend). will look a little more when i get back.
Cronjobs are universal in the Linux world.
disclaimer: i was never able to get cron to launch conky (eventually some kind soul using my distro pointed me at how to add a command at startup in our gui) like i wanted it to so i don’t have a specific site with a good explanation that i can point you at. this is obviously the generic wikipedia entry that can hopefully aim you in a helpful direction:
Thanks again for the tips
I have an idea how cron works
For this specific case I’ve just found other way to run a script after resume of suspending mode::
- Create a script in /lib/systemd/system-sleep and make it executable
#!/bin/bash case "$1" in post) echo "0000:00:12.0" > /sys/bus/pci/drivers/ohci-pci/unbind echo "0000:00:12.0" > /sys/bus/pci/drivers/ohci-pci/bind ;; esac
This script could be “polished” but for now, after 20 hours of working on this fault it’s time to rest…
I’ve just reported it in Linux Mint forum:
you’ve definitely earned it. hopefully the good folks at mint will have some helpful advice soon
Today, I’ve reported this issued directly to the Kernel developers through mailing list reports
I’ll update this subject if I get any answer back
Thanks once again for all your support
For those who need, here’s a link on how to report kernel errors:
The answer I got from the kernel developers was that this fault could be an hardware bug
I don’t think I have the knowledge to go any further on this so, for now, I’ll just accept this as a hardware bug
My thread reporting the error on VGER.KERNEL.ORG
I’ll use the code I mentioned above to restart the controller after laptop enters the suspend mode
I’m closing this topic as solved
Once again, I’de like to thank you all for your heart-warming support
Stay tuned for the next @Tech_JA Linux adventure
any objection to me switching (or you can) the solution to the post with the code you mentioned here? as the solution is appended to the very first post for anyone who might find this question in a search, i think it would be helpful to link that one instead
yes, please, change it for better reading ( I don’t know how to do it)
Which one was it?
i missed the response earlier. finally changed