All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	jikos@suse.cz, mawilcox@microsoft.com, raven@themaw.net,
	akpm@linux-foundation.org
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: update-binfmts breaking suspend was Re: x32 suspend failuer in Re: linux-next: Tree for Apr 4
Date: Thu, 5 Apr 2018 22:30:45 +0200	[thread overview]
Message-ID: <20180405203045.GA23313@amd> (raw)
In-Reply-To: <20180405122503.GA28446@amd>

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

Hi!

> > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > parent of next-20180307.
> > 
> > But you are right that if I do bisect between -linus and -next, it
> > should work.
> > 
> > Anyway, does s2ram work for you in -next? Are you testing 32bit?
> 
> Hmm. I tested on T40p. That works ok, so at least some 32bit machines
> do work.
> 
> Hmm, and my test scripts were wrong.
> 
> Failure is not a hang, as they expect, but... machine locks up, but
> does not suspend, and then continues running after a delay..
> 
> [   35.038766] PM: Syncing filesystems ... done.
> [   35.051246] Freezing user space processes ...
> [   55.060528] Freezing of tasks failed after 20.009 seconds (1 tasks
> refusing to freeze, wq_busy
> =0):
> [   55.060552] update-binfmts  D    0  2727      1 0x80000004
> [   55.060576] Call Trace:
> [   55.060600]  __schedule+0x37a/0x7e0
> [   55.060618]  schedule+0x29/0x70
> [   55.060635]  autofs4_wait+0x359/0x7a0
> [   55.060653]  ? wait_woken+0x70/0x70
> [   55.060668]  autofs4_mount_wait+0x4a/0xe0
> [   55.060684]  ? autofs4_mount_wait+0x4a/0xe0
> [   55.060699]  autofs4_d_automount+0xe0/0x200
> [   55.060715]  ? autofs4_d_automount+0xe0/0x200
> 
> Did the rework of freezing start already in -next?

Hmm, so I did git bisect, and it pointed to:

commit 7cb03edf112fea6ead2fcd3c5fd639756d6d114b
Author: Matthew Wilcox <mawilcox@microsoft.com>
Date:   Thu Mar 29 10:15:17 2018 +1100

    autofs4: use wait_event_killable

    This playing with signals to allow only fatal signals appears to
    predate
        the introduction of wait_event_killable(), and I'm fairly sure
    that
        wait_event_killable is what was meant to happen here.

    Link:
    http://lkml.kernel.org/r/20180319191609.23880-1-willy@infradead.org
        Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
	    Acked-by: Ian Kent <raven@themaw.net>
	        Signed-off-by: Andrew Morton
    <akpm@linux-foundation.org>
        Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
	



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	jikos@suse.cz, mawilcox@microsoft.com, raven@themaw.net,
	akpm@linux-foundation.org, sfr@canb.auug.org.au
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: update-binfmts breaking suspend was Re: x32 suspend failuer in Re: linux-next: Tree for Apr 4
Date: Thu, 5 Apr 2018 22:30:45 +0200	[thread overview]
Message-ID: <20180405203045.GA23313@amd> (raw)
In-Reply-To: <20180405122503.GA28446@amd>

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

Hi!

> > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > parent of next-20180307.
> > 
> > But you are right that if I do bisect between -linus and -next, it
> > should work.
> > 
> > Anyway, does s2ram work for you in -next? Are you testing 32bit?
> 
> Hmm. I tested on T40p. That works ok, so at least some 32bit machines
> do work.
> 
> Hmm, and my test scripts were wrong.
> 
> Failure is not a hang, as they expect, but... machine locks up, but
> does not suspend, and then continues running after a delay..
> 
> [   35.038766] PM: Syncing filesystems ... done.
> [   35.051246] Freezing user space processes ...
> [   55.060528] Freezing of tasks failed after 20.009 seconds (1 tasks
> refusing to freeze, wq_busy
> =0):
> [   55.060552] update-binfmts  D    0  2727      1 0x80000004
> [   55.060576] Call Trace:
> [   55.060600]  __schedule+0x37a/0x7e0
> [   55.060618]  schedule+0x29/0x70
> [   55.060635]  autofs4_wait+0x359/0x7a0
> [   55.060653]  ? wait_woken+0x70/0x70
> [   55.060668]  autofs4_mount_wait+0x4a/0xe0
> [   55.060684]  ? autofs4_mount_wait+0x4a/0xe0
> [   55.060699]  autofs4_d_automount+0xe0/0x200
> [   55.060715]  ? autofs4_d_automount+0xe0/0x200
> 
> Did the rework of freezing start already in -next?

Hmm, so I did git bisect, and it pointed to:

commit 7cb03edf112fea6ead2fcd3c5fd639756d6d114b
Author: Matthew Wilcox <mawilcox@microsoft.com>
Date:   Thu Mar 29 10:15:17 2018 +1100

    autofs4: use wait_event_killable

    This playing with signals to allow only fatal signals appears to
    predate
        the introduction of wait_event_killable(), and I'm fairly sure
    that
        wait_event_killable is what was meant to happen here.

    Link:
    http://lkml.kernel.org/r/20180319191609.23880-1-willy@infradead.org
        Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
	    Acked-by: Ian Kent <raven@themaw.net>
	        Signed-off-by: Andrew Morton
    <akpm@linux-foundation.org>
        Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
	



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2018-04-05 20:30 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04  6:55 linux-next: Tree for Apr 4 Stephen Rothwell
2018-04-04  7:48 ` ARM compile failure in " Pavel Machek
2018-04-04  7:48   ` Pavel Machek
2018-04-04 17:58   ` Tony Lindgren
2018-04-04 17:58     ` Tony Lindgren
2018-04-04 18:15     ` Pavel Machek
2018-04-04 18:15       ` Pavel Machek
2018-04-04 18:46     ` Pavel Machek
2018-04-04 18:46       ` Pavel Machek
2018-04-04 19:59       ` Tony Lindgren
2018-04-04 19:59         ` Tony Lindgren
2018-04-04 20:18         ` FORTIFY_SOURCE breaks ARM compilation in -next -- was " Pavel Machek
2018-04-04 20:18           ` Pavel Machek
2018-04-15 17:39           ` [regression v4.17-rc0] " Pavel Machek
2018-04-15 17:39             ` Pavel Machek
2018-04-15 18:00             ` Kees Cook
2018-04-15 18:00               ` Kees Cook
2018-04-15 18:00               ` Kees Cook
2018-04-15 20:58               ` Pavel Machek
2018-04-15 20:58                 ` Pavel Machek
2018-04-15 20:58                 ` Pavel Machek
2018-04-20  7:34               ` Pavel Machek
2018-04-20  7:34                 ` Pavel Machek
2018-04-20  7:34                 ` Pavel Machek
2018-04-20 15:05                 ` Kees Cook
2018-04-20 15:05                   ` Kees Cook
2018-04-20 15:05                   ` Kees Cook
2018-04-20 17:21                   ` Russell King - ARM Linux
2018-04-20 17:21                     ` Russell King - ARM Linux
2018-04-20 17:21                     ` Russell King - ARM Linux
2018-04-20 19:15                   ` Pavel Machek
2018-04-20 19:15                     ` Pavel Machek
2018-04-20 19:15                     ` Pavel Machek
2018-04-20 19:18                     ` Daniel Micay
2018-04-20 19:18                       ` Daniel Micay
2018-04-20 19:18                       ` Daniel Micay
2018-04-20 19:28                       ` Pavel Machek
2018-04-20 19:28                         ` Pavel Machek
2018-04-20 19:28                         ` Pavel Machek
2018-04-20 19:30                         ` Daniel Micay
2018-04-20 19:30                           ` Daniel Micay
2018-04-20 19:30                           ` Daniel Micay
2018-04-20 20:30                           ` Pavel Machek
2018-04-20 20:30                             ` Pavel Machek
2018-04-20 20:30                             ` Pavel Machek
2018-04-04  7:50 ` x32 suspend failuer " Pavel Machek
2018-04-04  7:58   ` Rafael J. Wysocki
2018-04-04  8:49     ` Pavel Machek
2018-04-05 12:25       ` update-binfmts breaking suspend was " Pavel Machek
2018-04-05 20:30         ` Pavel Machek [this message]
2018-04-05 20:30           ` Pavel Machek
2018-04-05 22:27           ` Rafael J. Wysocki
     [not found]           ` <SN4PR2101MB073673B12998428D48DA62E5CBBA0@SN4PR2101MB0736.namprd21.prod.outlook.com>
     [not found]             ` <20180406144355.GA20605@bombadil.infradead.org>
2018-04-11  4:30               ` update-binfmts breaking suspend Matthew Wilcox
2018-04-11  6:09                 ` Pavel Machek
2018-04-06 22:41   ` x32 suspend failuer in Re: linux-next: Tree for Apr 4 Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180405203045.GA23313@amd \
    --to=pavel@ucw.cz \
    --cc=akpm@linux-foundation.org \
    --cc=jikos@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=rafael@kernel.org \
    --cc=raven@themaw.net \
    --cc=rjw@rjwysocki.net \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.