From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9) Date: Thu, 31 Jan 2019 02:02:34 -0500 Message-ID: <87k1ill36i.fsf@netris.org> References: <877eevq5i6.fsf@gnu.org> <87y37boqhk.fsf@gnu.org> <87y376ktcc.fsf@gnu.org> <8736pblkyw.fsf@gnu.org> <87ef8th3l3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gp6OJ-0004bi-L1 for bug-guix@gnu.org; Thu, 31 Jan 2019 02:04:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gp6OI-0006oq-Rw for bug-guix@gnu.org; Thu, 31 Jan 2019 02:04:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52843) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gp6OI-0006oY-Nm for bug-guix@gnu.org; Thu, 31 Jan 2019 02:04:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gp6OI-0006ZW-7p for bug-guix@gnu.org; Thu, 31 Jan 2019 02:04:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ef8th3l3.fsf@gnu.org> (Mike Gerwitz's message of "Wed, 30 Jan 2019 23:07:52 -0500") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mike Gerwitz Cc: 34176@debbugs.gnu.org reopen 34176 thanks Hi Mike, Mike Gerwitz 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 . 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