I ran some tests today to try and pinpoint it a little better, and understand why I didn't encounter it when testing a couple days ago. For me, the case seems to be related to the user that suspends.
I couldn't find any difference between the kernel "4.15.0-38-generic #41-Ubuntu" and "4.15.0-39-generic #42~lp1798921", meaning that on my tests, they both happened and didn't happen under the same circumstances.
* Boot Computer -> login to BOB -> Suspend -> Wake -> login to BOB => NO PROBLEMS.
No matter how many times I tried, as long as I suspended and when woke logged back in to the same user, I never encountered the bug.
* Boot Computer -> login to BOB -> Suspend -> Wake -> Login to MARY => FAIL.
If when I returned from suspend I logged in to a different user, I always encountered the bug.
* Boot Computer -> login to BOB -> Suspend -> Wake -> Suspend again -> login to BOB => FAIL.
If when I woke from the first sleep, the pc went back to suspend, and only then I logged back in to BOB, I encountered the bug 100% of the time.
* Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to BOB => NO PROBLEMS.
Again, once I return from suspend, logging back to the user that 'established the connection' means I don't have any issues.
* Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to MARY => FAIL.
Now, if I login to a different user, even if it is the user that performed the suspend, I always encountered the bug.
* The instance that was not clear cut is when I logged out of a user, instead of simply changing users. So for example, login to BOB, suspend, wake, login to BOB, logout, and then go to Mary. I very rarely encountered issues, but it did happen a couple times, so I'm not sure on this point.
One very important thing to note is that when the bug happens, it sticks up no matter what. So, if I encounter the bug, and do the workaround fix with the modprobe command, the bug will happen again in the next suspend, no matter in which circunstance. A reboot restores things to normal.
Not sure if my case is similar to yours kris, but hopefully this bit helps a bit more to pinpoint the issue.
I ran some tests today to try and pinpoint it a little better, and understand why I didn't encounter it when testing a couple days ago. For me, the case seems to be related to the user that suspends.
I couldn't find any difference between the kernel "4.15.0-38-generic #41-Ubuntu" and "4.15.0-39-generic #42~lp1798921", meaning that on my tests, they both happened and didn't happen under the same circumstances.
* Boot Computer -> login to BOB -> Suspend -> Wake -> login to BOB => NO PROBLEMS.
No matter how many times I tried, as long as I suspended and when woke logged back in to the same user, I never encountered the bug.
* Boot Computer -> login to BOB -> Suspend -> Wake -> Login to MARY => FAIL.
If when I returned from suspend I logged in to a different user, I always encountered the bug.
* Boot Computer -> login to BOB -> Suspend -> Wake -> Suspend again -> login to BOB => FAIL.
If when I woke from the first sleep, the pc went back to suspend, and only then I logged back in to BOB, I encountered the bug 100% of the time.
* Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to BOB => NO PROBLEMS.
Again, once I return from suspend, logging back to the user that 'established the connection' means I don't have any issues.
* Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to MARY => FAIL.
Now, if I login to a different user, even if it is the user that performed the suspend, I always encountered the bug.
* The instance that was not clear cut is when I logged out of a user, instead of simply changing users. So for example, login to BOB, suspend, wake, login to BOB, logout, and then go to Mary. I very rarely encountered issues, but it did happen a couple times, so I'm not sure on this point.
One very important thing to note is that when the bug happens, it sticks up no matter what. So, if I encounter the bug, and do the workaround fix with the modprobe command, the bug will happen again in the next suspend, no matter in which circunstance. A reboot restores things to normal.
Not sure if my case is similar to yours kris, but hopefully this bit helps a bit more to pinpoint the issue.