All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Pop <elendil@planet.nl>
To: linux-kernel@vger.kernel.org
Cc: Yves-Alexis Perez <corsac@debian.org>,
	"Carlos R. Mafra" <crmafra2@gmail.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: Long delays and keystrokes required - related to disk encryption?
Date: Wed, 29 Oct 2008 01:53:21 +0100	[thread overview]
Message-ID: <200810290153.23514.elendil@planet.nl> (raw)
In-Reply-To: <200810281744.52587.elendil@planet.nl>

On Tuesday 28 October 2008, Frans Pop wrote:
> I'm seeing some very strange behavior with 2.6.28-rc2-95-g49fdf67 on my
> HP 2510p notebook.
>
> During the boot there are several places where I need to hit a key for
> the boot to continue. There are also some very long delays before the
> next syslog message is displayed.
> The boot does continue and regularly hitting a key helps (but does not
> get rid of all delays), but it is a huge regression from 2.6.27.
>
> The delays seem to continue until file systems get mounted.
>
> As the delays start at the point my system asks for the passphrase to
> unlock (LUKS) encrypted disks, I suspect it has to do with that.
> Especially since hitting a key seems to "trigger" new disk activity.
>
> However, the delays happen _again_ during shutdown, which makes it
> extra strange that the system does behave normally when logged in.
>
> During the first boot wireless networking failed. During the second
> boot, wireless networking did come up (without any relevant changes).
> This gave an interesting extra data point: with wireless the delays on
> shutdown started later: after iwlagn gets disabled.

I've bisected it to:
commit dc4304f7deee29fcdf6a2b62f7146ea7f505fd42
Author: Arjan van de Ven <arjan@linux.intel.com>
Date:   Mon Oct 13 10:32:15 2008 -0400
    rangetimers: fix the bug reported by Ingo for real

The bisection was one of those annoying ones where you switch branches
often and get a load of config changes. This means that I'm not 100% sure
about it, especially as the behavior changed for the last few "bad"s:
instead of endlessly repeated delays there would be only a few of them
immediately after entering the LUKS passphrase.

I'm fairly confident that the issue is in Arjan's hrtimer/rangetimer
series, but there seems to be some interaction with other changes.
The fact that the last bisect was a "good" also gives some assurance.

CC'ing Ingo and Thomas as they've worked on these changes as well.

Here is the full bisect log:
git-bisect start
# good: [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27
git-bisect good 3fa8749e584b55f1180411ab1b51117190bac1e5
# bad: [c1ca9151db2d432b6fa485cbff25b627f0926c76] SATA: Blacklist systems that spin off disks during ACPI power off
git-bisect bad c1ca9151db2d432b6fa485cbff25b627f0926c76
# good: [cf2fa66055d718ae13e62451bb546505f63906a2] Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6
git-bisect good cf2fa66055d718ae13e62451bb546505f63906a2
# good: [2be508d847392e431759e370d21cea9412848758] Merge git://git.infradead.org/mtd-2.6
git-bisect good 2be508d847392e431759e370d21cea9412848758
# good: [e82cff752f57810a2259415ad2e9087c2d69484c] Merge branch 'irq-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git-bisect good e82cff752f57810a2259415ad2e9087c2d69484c
# good: [5b34653963de7a6d0d8c783527457d68fddc60fb] Merge branch 'x86/um-header' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git-bisect good 5b34653963de7a6d0d8c783527457d68fddc60fb
# bad: [c3c9897c63ebb0b93b7f78724e38d6ee1da04041] Merge branch 'x86-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git-bisect bad c3c9897c63ebb0b93b7f78724e38d6ee1da04041
# good: [54d822a6169b76b807b8cdbbf76ff2812a88947f] Merge git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6
git-bisect good 54d822a6169b76b807b8cdbbf76ff2812a88947f
# bad: [1f6d6e8ebe73ba9d9d4c693f7f6f50f661dbd6e4] Merge branch 'v28-range-hrtimers-for-linus-v2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git-bisect bad 1f6d6e8ebe73ba9d9d4c693f7f6f50f661dbd6e4
# good: [db563fc2e80534f98c7f9121a6f7dfe41f177a79] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
git-bisect good db563fc2e80534f98c7f9121a6f7dfe41f177a79
# FJP: repeated due to merge failure because of ext3 build error fix
# good: [db563fc2e80534f98c7f9121a6f7dfe41f177a79] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
git-bisect good db563fc2e80534f98c7f9121a6f7dfe41f177a79
# good: [da8f2e170ea94cc20f8ebbc8ee8d127edb8f12f1] hrtimer: add a hrtimer_start_range() function
git-bisect good da8f2e170ea94cc20f8ebbc8ee8d127edb8f12f1
# good: [9fd87545c97b91cf9cfa52e914d66863878efe60] Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-hrtimer into timers/range-hrtimers
git-bisect good 9fd87545c97b91cf9cfa52e914d66863878efe60
# bad: [b6a4b7de4cb45ccf7157fc58de09c96f84d67108] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-hrtimer into timers/range-hrtimers
git-bisect bad b6a4b7de4cb45ccf7157fc58de09c96f84d67108
# bad: [40b8606253552109815786e5d4b0de98782d31f5] DECLARE_PER_CPU needs linux/percpu.h
git-bisect bad 40b8606253552109815786e5d4b0de98782d31f5
# bad: [dc4304f7deee29fcdf6a2b62f7146ea7f505fd42] rangetimers: fix the bug reported by Ingo for real
git-bisect bad dc4304f7deee29fcdf6a2b62f7146ea7f505fd42
# good: [030aebd2e439a2ebcca2b0ce30a02ed84feb043e] rangetimer: fix BUG_ON reported by Ingo
git-bisect good 030aebd2e439a2ebcca2b0ce30a02ed84feb043e

  parent reply	other threads:[~2008-10-29  0:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 16:44 Long delays and keystrokes required - related to disk encryption? Frans Pop
2008-10-28 17:11 ` Carlos R. Mafra
2008-10-28 21:52   ` Yves-Alexis Perez
2008-10-29  0:53 ` Frans Pop [this message]
2008-10-29  3:32   ` Arjan van de Ven
2008-10-29  6:54     ` Yves-Alexis Perez
2008-10-29  7:11       ` Yves-Alexis Perez
2008-11-03  7:23         ` Yves-Alexis Perez
2008-11-03  7:36           ` Yves-Alexis Perez
2008-11-05  2:03             ` Bernhard Schmidt
2008-11-05 15:13               ` Arjan van de Ven
2008-11-05 16:12                 ` Bernhard Schmidt
2008-11-05 18:17                 ` Yves-Alexis Perez
2008-11-05 20:41                 ` Frans Pop
2008-11-06 15:41                 ` Tony Vroon
2008-11-06 15:56                   ` Yves-Alexis Perez
2008-10-29 10:43     ` Frans Pop
2008-10-30 19:50 ` Pavel Machek
2008-10-31  0:04   ` Frans Pop
2008-10-31  7:57     ` Pavel Machek
2008-10-31 11:40       ` Yves-Alexis Perez

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=200810290153.23514.elendil@planet.nl \
    --to=elendil@planet.nl \
    --cc=arjan@linux.intel.com \
    --cc=corsac@debian.org \
    --cc=crmafra2@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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.