bug#34176: X200 kernel panic on S3 resume (linux-libre > 4.18.9)

[Mark H Weaver <mhw@netris.org>]

reopen 34176
thanks

Hi Mike,

Mike Gerwitz <mtg@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 <control@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