All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@mail.ru>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: michal.k.k.piotrowski@gmail.com, linux-kernel@vger.kernel.org,
	Pavel Machek <pavel@ucw.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation
Date: Sun, 9 Sep 2007 21:40:48 +0400	[thread overview]
Message-ID: <200709092140.57653.arvidjaar@mail.ru> (raw)
In-Reply-To: <200709091907.14642.rjw@sisk.pl>

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

On Sunday 09 September 2007, Rafael J. Wysocki wrote:
> On Sunday, 9 September 2007 16:00, Andrey Borzenkov wrote:
> > On Sunday 01 July 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
> > > > Since 2.6.18 I do not have suspend to RAM; now I am starting to lose
> > > > suspend to disk :)
> > > >
> > > > Environment - vanilla kernel (2.6.22-rc6 currently + squashfs +
> > > > single pata_ali patch to switch off DMA on CD-ROM), single root on
> > > > reiserfs, libata with pata_ali driver.
> > > >
> > > > Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc
> > > > system hung at least once in every rcX. Up to rc6 those lockups were
> > > > absolutely silent (black screen without reaction to any key). In rc6
> > > > I just got something different. After resume I got on screem:
> > > >
> > > > swsusp: Marking nosave pages: 000000000009f000-0000000000100000
> > > > swsusp: Basic memory bitmaps created
> > > > swsusp: Basic memory bitmaps freed
> > > >
> > > > After that it just sits there doing nothing. Ther was brief sound of
> > > > HDD but I suspect it was related more to power-on. System was
> > > > responding to power-on button press:
> > > >
> > > > ACPI Error (event-0305): No installed handler for fixed event
> > > > [00000002 20070125]
> > > >
> > > > And SysRq was functioning.
> > >
> > > That probably means that there's a deadlock somewhere in there.
> > >
> > > > Unfortunately I do not have serial console so I
> > > > copy manually stacks from several last screens of output; I have
> > > > tried to make a photo but right now my kbluetooth is refusing to work
> > > > at all so I cannot transfer them :( (but I suspect quality would be
> > > > too bad anyway)
> > > >
> > > > laptop_mode D
> > > > 	io_schedule+0xe/0x20
> > >
> > > Looks suspicious to me.  Can you identify what line of code this points
> > > to?
> > >
> > > > 	sync_buffer+0x35/0x40
> > > > 	__wait_on_bit+0x45/0x70
> > > > 	out_of_line_wait_on_bit+0x6c/0x80
> > > > 	__wait_on_buffer+0x27/0x30
> > > > 	search_by_key+0x15e/0x1250 [reiserfs]
> > > > 	reiserfs_read_locked_inode+0x64/0x570 [reiserfs]
> > > > 	reiserfs_iget+0x7e/0xa0 [reiserfs]
> > > > 	reiserfs_lookup+0xc7/0x120 [reiserfs]
> > > > 	do_lookup+0x138/0x180
> > > > 	__link_path_walk+0x787/0xce0
> > > > 	link_path_walk+0x44/0xc0
> > > > 	path_walk+0x18/0x20
> > > > 	do_path_lookup_0x88/0x210
> > > > 	__path_lookupintent_open+0x4d/0x90
> > > > 	path_lookup_open+0x1f/0x30
> > > > 	open_exec+0x28/0xb0
> > > > 	do_execve+0x36/0x1d0
> > > > 	sys_execve+0x2e/0x80
> > > > 	sysenter_past_esp+0x5f/0x99
> > > >
> > > > 90clock D
> > > > 	__mutex_lock_slow_path+0xa1/0x290
> > > > 	mutex_lock+0x21/0x30
> > > > 	do_lookup+0xa1/0x180
> > > > 	__link_path_walk+0x44/0xc0
> > > > 	path_walk+0x18/0x20
> > > > 	do_path_lookup+0x78/0x210
> > > > 	__user_walk_fd+0x38/0x50
> > > > 	vfs_stat_fd+0x21/0x50
> > > > 	vfs_stat+0x11/0x20
> > > > 	sys_stat64+0x14/0x30
> > > > 	sysenter_past_esp+0x5f/0x99
> > > >
> > > > alsactl D
> > > > 	io_schedule+0xe/0x20
> > >
> > > Same here.  Hmm.
> > >
> > > > 	sync_page+0x35/0x40
> > > > 	__wait_on_bit_lock+0x3f/0x70
> > > > 	__lock_page+0x68/0x70
> > > > 	filemap_nopage+0x16c/0x300
> > > > 	__handle_mm_faul+0x1d7/0x610
> > > > 	do_page_fault+0x1d7/0x610
> > > > 	error_code+0x6a/0x70
> > > > 	padzero+0x1f/0x30
> > > > 	load_elf_binary+0x743/0x1ab0
> > > > 	search_binary_handler+0x7b/0x1f0
> > > > 	do_execve+0x137/0x1d0
> > > > 	sys_execve+0x2e/0x80
> > > > 	sysenter_past_esp+0x5f/0x90
> > > >
> > > > After that I could remount, sync and reboot using SysRq (well, after
> > > > reboot it still insisted on replaying insane number of transactions
> > > > so may be it did *not* remount / ro after all). Before reboot there
> > > > was brief output that resembled lockdep warnings, but it went too
> > > > fast to be readable.
> > > >
> > > > usual stuff follows
> > >
> > > I see you're using CFQ as the default IO scheduler.  Can you please
> > > switch to AS and see if that changes anything?
> >
> > I just had the same lockup on resume using AS with 2.6.23-rc5.
>
> Hm.  Does your root partition sit on reiserfs?

yes - "single root on reiserfs"

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-09-09 17:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-30  4:59 [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation Andrey Borzenkov
2007-06-30 20:37 ` Rafael J. Wysocki
2007-06-30 21:34   ` Andrey Borzenkov
2007-06-30 23:33     ` Michal Piotrowski
2007-07-01 10:09     ` Rafael J. Wysocki
2007-07-15 18:56       ` Andrey Borzenkov
2007-09-02 11:29       ` Andrey Borzenkov
2007-09-02 14:49         ` Kasper Sandberg
2007-06-30 23:03   ` Pavel Machek
2007-09-09 14:00   ` Andrey Borzenkov
2007-09-09 17:07     ` Rafael J. Wysocki
2007-09-09 17:40       ` Andrey Borzenkov [this message]
2007-11-21 17:12       ` Andrey Borzenkov
2007-11-21 19:47         ` Rafael J. Wysocki
2008-03-13  4:08           ` Andrey Borzenkov
2008-03-13 20:46             ` Rafael J. Wysocki
2008-03-16 19:04               ` Andrey Borzenkov
2008-03-16 19:25                 ` Rafael J. Wysocki
2008-03-17  4:00                   ` Andrey Borzenkov

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=200709092140.57653.arvidjaar@mail.ru \
    --to=arvidjaar@mail.ru \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /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.