reopen 34176 thanks Hi Mike,
Mike Gerwitz <m...@gnu.org> writes: > On Tue, Jan 29, 2019 at 07:14:15 -0500, Mike Gerwitz wrote: >> reopen 34176 >> thanks > > I guess I don't have permission to do this, since nothing happened. Can > someone do this for me? No permission is needed, but it must be sent to the correct address. It must be sent to <cont...@debbugs.gnu.org>. I add that address to the BCC header when including such commands. > Alternatively, if this seems outside the scope of something we'd want to > track in Guix, just leave it closed. I'm glad to have it in our tracker. >> On Sun, Jan 27, 2019 at 10:34:11 -0500, Mike Gerwitz wrote: >> I have to go to work shortly, so I'll play around with it a little more >> later tonight and see if e.g. plugging in my Nitrokey (actually using >> the USB hub) had an effect. With that said, I use my Nitrokey every day >> (but I did _not_ use it most of the times I was trying to debug this >> issue) and I thought I've had suspend issues with it before. I guess >> we'll see. > > I was not able to figure it out with the time I had available to spend > on this the past couple of nights. It's once again locking up when > resuming, and I cannot get it to resume correctly. FWIW, unless someone has a better idea, my recommendation would be to do a binary search on the kernel versions, to find which version introduced the problem. You mentioned in your original report that 4.18.9 works and 4.19.5 fails. The first thing I would check is whether 4.19 works. If it works, then you could find which update to the 4.19.y branch introduced the problem. If 4.19 fails, then you could check 4.18.20, which is the final release of 4.18.y. If it fails, you could find which update to 4.18.y introduced the problem. The reason I suggest checking these first is because each stable update is relatively small, which will simplify the task of finding the faulty commit. It might be possible to look at the changelog of the relevant stable update and make some educated guesses about which commits to try reverting. If 4.18.20 works and 4.19 fails, then it will probably be necessary to do a "git bisect" on the upstream kernel git repository between those two versions, to find the commit that introduced the problem. If it comes to this, let me know and I'll help you find a way to do this efficiently. Regards, Mark