> On Mon, 2007-09-17 at 18:37 +, Pavel Machek wrote:
> > > That's a bit tricky because hitting the keyboard is what unsticks things.
> > > And the video is black after resume-from-RAM (has always been thus) and we
> >
> > Ok, can we try to fix the video issue for you? That should make the
> >
On Saturday, 22 September 2007 10:50, Thomas Gleixner wrote:
> On Mon, 2007-09-17 at 18:37 +, Pavel Machek wrote:
> > > That's a bit tricky because hitting the keyboard is what unsticks things.
> > > And the video is black after resume-from-RAM (has always been thus) and we
> >
> > Ok, can we
On Mon, 2007-09-17 at 18:37 +, Pavel Machek wrote:
> > That's a bit tricky because hitting the keyboard is what unsticks things.
> > And the video is black after resume-from-RAM (has always been thus) and we
>
> Ok, can we try to fix the video issue for you? That should make the
> development
Hi!
> > Ok, here we are. The bad one uses C2 which stops the local apic on the
> > VAIO. I suspect we end up in the suspend/resume with going into C2
> > without the broadcast active.
> >
> > Can you try to get the output of SysRq-Q during the "it needs help from
> > keyboard" period ?
> >
>
>
On Wed, 12 Sep 2007 18:57:42 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Does the test hack below fix the problem for nohz/highres enabled
> kernels ?
>
> tglx
>
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -382,6 +382,8 @@ static int tick_broadcast
On Wed, 2007-09-12 at 02:16 -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 23:49:47 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > > > C1: type[C1] promotion[C2] demotion[--]
> > > > latency[001] usage[0
On Tue, 11 Sep 2007 23:49:47 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > > C1: type[C1] promotion[C2] demotion[--] latency[001]
> > > usage[0010] duration[]
> > >*C2:
On Tue, 11 Sep 2007 21:52:01 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 11:44 -0700, Andrew Morton wrote:
> > > > there doesn't seem to be a lot of difference in the time handling,
> > > > except
> > > > there are large changes in when things happen in the bootup seq
On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > C1: type[C1] promotion[C2] demotion[--] latency[001]
> > usage[0010] duration[]
> >*C2: type[C2] promotion[--] demotion[C1] latency[001]
> > usage[8316] duration[000
On Tue, 2007-09-11 at 11:44 -0700, Andrew Morton wrote:
> > > there doesn't seem to be a lot of difference in the time handling, except
> > > there are large changes in when things happen in the bootup sequence.
> >
> > The question is whether the system goes into C2 with the patch applied.
> >
>
On Tue, 11 Sep 2007 21:35:15 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > dmesg without the cpuidle patch:
> > http://userweb.kernel.org/~akpm/dmesg-bad.txt
> > dmesg with the cpuidle patch: http://userweb.kernel.org/~akpm/dmesg-good.txt
> > difference: http://userweb.kernel.org/~akpm
On Tuesday, 11 September 2007 20:25, Andrew Morton wrote:
> On Tue, 11 Sep 2007 14:09:12 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > On Tuesday, 11 September 2007 13:22, Andrew Morton wrote:
> > > On Tue, 11 Sep 2007 13:23:55 +0200 "Rafael J. Wysocki" <[EMAIL
> > > PROTECTED]> w
On Tue, 11 Sep 2007 20:38:03 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 11:25 -0700, Andrew Morton wrote:
> > > It evidently assumes cpuidle to be present, which is not in the mainline.
> >
> > Bear in mind that the cpuidle patch fixes resume-from-ram when cpuidle is
On Tue, 11 Sep 2007 11:25:31 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> dmesg without the cpuidle patch:
> http://userweb.kernel.org/~akpm/dmesg-bad.txt dmesg with the cpuidle
> patch: http://userweb.kernel.org/~akpm/dmesg-good.txt difference:
> http://userweb.kernel.org/~akpm/dmesg-diff.t
On Tue, 2007-09-11 at 11:25 -0700, Andrew Morton wrote:
> > It evidently assumes cpuidle to be present, which is not in the mainline.
>
> Bear in mind that the cpuidle patch fixes resume-from-ram when cpuidle is
> disabled in config.
>
> > It seems to me that the total effect of this one and the
On Tue, 11 Sep 2007 14:09:12 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Tuesday, 11 September 2007 13:22, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 13:23:55 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tuesday, 11 September 2007 12:31, Andrew Morton wr
On Tuesday, 11 September 2007 13:22, Andrew Morton wrote:
> On Tue, 11 Sep 2007 13:23:55 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > On Tuesday, 11 September 2007 12:31, Andrew Morton wrote:
> > > On Tue, 11 Sep 2007 11:16:04 +0200 Thomas Gleixner <[EMAIL PROTECTED]>
> > > wrote
On Tue, 11 Sep 2007 13:23:55 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Tuesday, 11 September 2007 12:31, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 11:16:04 +0200 Thomas Gleixner <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, 2007-09-11 at 01:35 -0700, Andrew Morton wrote:
>
On Tuesday, 11 September 2007 12:31, Andrew Morton wrote:
> On Tue, 11 Sep 2007 11:16:04 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-11 at 01:35 -0700, Andrew Morton wrote:
> > > On Tue, 11 Sep 2007 01:20:05 -0700 Andrew Morton <[EMAIL PROTECTED]>
> > > wrote:
> > >
>
On Tue, 11 Sep 2007 11:16:04 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 01:35 -0700, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 01:20:05 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 11 Sep 2007 09:47:20 +0200 Thomas Gleixner <[EMAIL PROTECTED]>
On Tue, 2007-09-11 at 01:35 -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 01:20:05 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 11 Sep 2007 09:47:20 +0200 Thomas Gleixner <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > >
On Tue, 2007-09-11 at 01:20 -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 09:47:20 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > > > I went back to the original patch which I sent to Linus and it matches
> > > > 18de5bc4c1f
On Tue, 11 Sep 2007 01:20:05 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007 09:47:20 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > > > I went back to the original patch which I sent to Linus and it matche
On Tue, 11 Sep 2007 09:47:20 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > > I went back to the original patch which I sent to Linus and it matches
> > > 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. So all I can think is that
> > >
On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > I went back to the original patch which I sent to Linus and it matches
> > 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. So all I can think is that there
> > must have been something else in the tree which I tested which fixed the
> > bug w
On Tue, 11 Sep 2007 09:34:31 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > > I went back to the original patch which I sent to Linus and it matches
> > > 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. So all I can think is that
> > >
On Tue, 2007-09-11 at 09:23 +0200, Thomas Gleixner wrote:
> > I went back to the original patch which I sent to Linus and it matches
> > 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. So all I can think is that there
> > must have been something else in the tree which I tested which fixed the
> > bug w
On Tue, 2007-09-11 at 00:00 -0700, Andrew Morton wrote:
> > > This patch broke the jinxed vaio.
> > >
> > > Which is a bit odd, considering that I must have tested it at the time.
> > > But I bisected it right down to this commit, and the below revert patch
> > > fixed it up.
> >
> > I just look
On Tue, 11 Sep 2007 08:37:16 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-10 at 14:47 -0700, Andrew Morton wrote:
> > >
> > > clockevents: fix resume logic
> > >
> > > We need to make sure, that the clockevent devi
On Mon, 2007-09-10 at 14:47 -0700, Andrew Morton wrote:
> >
> > clockevents: fix resume logic
> >
> > We need to make sure, that the clockevent devices are resumed, before
> > the tick is resumed. The current resume logic does not guaran
> Parent: 93da56efcf8c6a111f0349f6b7651172d4745ca0
> Author: Thomas Gleixner <[EMAIL PROTECTED]>
> AuthorDate: Sat Jul 21 04:37:34 2007 -0700
> Committer: Linus Torvalds <[EMAIL PROTECTED]>
> CommitDate: Sat Jul 21 17:49:15 2007 -0700
>
> clockevents: fix resume logic
&
We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The current resume logic does not guarantee this.
Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
event devices before resuming the tick / oneshot functionality.
Fixup the existing us
Oleg,
On Sat, 2007-06-16 at 20:51 +0200, Oleg Verych wrote:
> > arch/arm/plat-omap/timer32k.c |2 +
>
> Testers and users are most likely to run one particular arch on
> one particular test bench. If individual patches are arch
> separated, i think bisecting will be a little bit easier.
* From: Thomas Gleixner
[]
> Fixup the existing users.
>
> This removes the sysfs entry for the HPET, which is now controlled by
> the clockevents resume code.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> ---
> arch/arm/mach-davinci/time.c |2 +
> arch/arm/mach-imx/time.c
We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The current resume logic does not guarantee this.
Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
event devices before resuming the tick / oneshot functionality.
Fixup the existing us
On Sun, 2007-06-10 at 18:34 +0200, Rafael J. Wysocki wrote:
> On Sunday, 10 June 2007 15:17, Thomas Gleixner wrote:
> > On Sun, 2007-06-10 at 12:58 +0200, Rafael J. Wysocki wrote:
> > >
> > > This is the resume part, or at least it seems so, but the above one is a
> > > suspend callback. If I unde
On Sunday, 10 June 2007 15:17, Thomas Gleixner wrote:
> On Sun, 2007-06-10 at 12:58 +0200, Rafael J. Wysocki wrote:
> >
> > This is the resume part, or at least it seems so, but the above one is a
> > suspend callback. If I understand it correctly, this one replaces
> > hpet_resume(), but is it su
On Sun, 2007-06-10 at 12:58 +0200, Rafael J. Wysocki wrote:
>
> This is the resume part, or at least it seems so, but the above one is a
> suspend callback. If I understand it correctly, this one replaces
> hpet_resume(), but is it sufficient for the suspend part too?
Oops. Sorry, misunderstood y
On Sunday, 10 June 2007 12:30, Thomas Gleixner wrote:
> On Sun, 2007-06-10 at 12:19 +0200, Rafael J. Wysocki wrote:
> > > -/*
> > > - * Suspend/resume part
> > > - */
> > > -
> > > -#ifdef CONFIG_PM
> > > -
> > > -static int hpet_suspend(struct sys_device *sys_device, pm_message_t
> > > state)
> >
On Sun, 2007-06-10 at 12:19 +0200, Rafael J. Wysocki wrote:
> > -/*
> > - * Suspend/resume part
> > - */
> > -
> > -#ifdef CONFIG_PM
> > -
> > -static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
> > -{
> > - unsigned long cfg = hpet_readl(HPET_CFG);
> > -
> > - cfg &= ~(
On Sunday, 10 June 2007 11:44, Thomas Gleixner wrote:
> We need to make sure, that the clockevent devices are resumed, before
> the tick is resumed. The current resume logic does not guarantee this.
>
> Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
> event devices before r
On Sun, 2007-06-10 at 19:43 +1000, Nigel Cunningham wrote:
> Hi Thomas.
>
> On Sun, 2007-06-10 at 09:44 +, Thomas Gleixner wrote:
> > plain text document attachment (clockevents-fix-resume-logic.patch)
> > We need to make sure, that the clockevent devices are resumed, before
> > the tick is re
Hi Thomas.
On Sun, 2007-06-10 at 09:44 +, Thomas Gleixner wrote:
> plain text document attachment (clockevents-fix-resume-logic.patch)
> We need to make sure, that the clockevent devices are resumed, before
> the tick is resumed. The current resume logic does not guarantee this.
>
> Add CLOCK
We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The current resume logic does not guarantee this.
Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
event devices before resuming the tick / oneshot functionality.
Fixup the existing us
Hi!
> > > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > > return statement. Any theories there?
> >
> > Only stack or memory corruption come into mind, but I have no clue how
> > this is related to the resume logic changes.
>
> So I had the brilliant idea of turni
On Sun, 2007-05-13 at 23:42 -0700, Andrew Morton wrote:
> On Sun, 13 May 2007 18:12:50 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote:
> > > Still hangs in the same fashion, sorry.
> > >
> > > It's peculiar that the hang happens when
On Sun, 13 May 2007 18:12:50 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote:
> > Still hangs in the same fashion, sorry.
> >
> > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > return statement. Any theories
On Sun, 13 May 2007 22:07:39 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Yeah, I expect quite a few people will start seeing that. iirc it was
> > triggered by a couple of changes: a local_irq_save/local_irq_restore
> > in sched_clock() an
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yeah, I expect quite a few people will start seeing that. iirc it was
> triggered by a couple of changes: a local_irq_save/local_irq_restore
> in sched_clock() and a change Jeremy made to the softlockup detector.
hm, i specifically asked to not do
On Sun, 13 May 2007 18:48:07 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-05-13 at 10:07 +0200, Thomas Gleixner wrote:
> > > > Can you send me your .config please ?
> > > >
> > >
> > > http://userweb.kernel.org/~akpm/config-sony.txt
> >
> > No luck.
>
> I'm making progress.
On Sun, 2007-05-13 at 10:07 +0200, Thomas Gleixner wrote:
> > > Can you send me your .config please ?
> > >
> >
> > http://userweb.kernel.org/~akpm/config-sony.txt
>
> No luck.
I'm making progress. After fiddling with the config options I get a
solid lockup of netconsole during boot :(
But al
On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote:
> Still hangs in the same fashion, sorry.
>
> It's peculiar that the hang happens when acpi_evaluate_object() hits its
> return statement. Any theories there?
I assume you have a printk right before the return and one after the
call to acpi
On Sat, 2007-05-12 at 18:11 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 21:56:10 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> > > The broken-out queue should turn up at
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm
On Sat, 12 May 2007 21:56:10 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> > The broken-out queue should turn up at
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/
> > in a few minutes.
>
> Sigh. I can't reproduce your lockd
On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> The broken-out queue should turn up at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/
> in a few minutes.
Sigh. I can't reproduce your lockdep problem :(
Can you send me your .config please ?
tglx
-
To unsubscribe from
On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 19:01:41 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Can you upload a snapshot of your current queue ?
>
> Yeah, that's super-easy. It just happens that it all compiles
> and runs at present ;)
Really ?
/h
On Sat, 2007-05-12 at 19:01 +0200, Thomas Gleixner wrote:
> On Sat, 2007-05-12 at 09:51 -0700, Andrew Morton wrote:
> > The locking in clocksource_resume_watchdog looks pretty pointless anyway.
> > Can't we just delete it?
> >
> > The only thing it can race against is, conceivably,
> >
> >
On Sat, 12 May 2007 19:01:41 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Can you upload a snapshot of your current queue ?
Yeah, that's super-easy. It just happens that it all compiles
and runs at present ;)
The single-big-patch is at http://userweb.kernel.org/~akpm/tg.bz2
The broken-ou
On Sat, 2007-05-12 at 09:51 -0700, Andrew Morton wrote:
> The locking in clocksource_resume_watchdog looks pretty pointless anyway.
> Can't we just delete it?
>
> The only thing it can race against is, conceivably,
>
> resumed = watchdog_resumed;
> if (unlikely(resumed))
>
On Sat, 12 May 2007 13:44:13 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> lockdep complains about the lock nesting of clocksource and watchdog
> lock in the resume path. Move watchdog resume out of the clocksource
> lock.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> Index: li
On Sat, 2007-05-12 at 03:07 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 11:18:09 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > > return statement. Any theories there?
> >
> > Only stack or memory corrup
On Sat, 2007-05-12 at 03:07 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 11:18:09 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > > return statement. Any theories there?
> >
> > Only stack or memory corrup
On Sat, 12 May 2007 11:18:09 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > It's peculiar that the hang happens when acpi_evaluate_object() hits its
> > return statement. Any theories there?
>
> Only stack or memory corruption come into mind, but I have no clue how
> this is related to the
On Sat, 2007-05-12 at 02:00 -0700, Andrew Morton wrote:
>
> Still hangs in the same fashion, sorry.
I did not really expect that it fixes the problem. It just restored the
local APIC suspend/resume register fiddling which we had before the
resume logic patch.
> It's peculiar that the hang happens
On Sat, 12 May 2007 10:46:03 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-05-11 at 23:56 -0700, Andrew Morton wrote:
> > On Fri, 11 May 2007 23:09:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > > >
> > > > > hm, Fedora don't seem to want to give me an R
On Fri, 2007-05-11 at 23:56 -0700, Andrew Morton wrote:
> On Fri, 11 May 2007 23:09:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > > >
> > > > hm, Fedora don't seem to want to give me an RPM which contains acpidump
> > > > and
> > > > all the yum servers are featuring scrogged
On Fri, 11 May 2007 23:09:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> > >
> > > hm, Fedora don't seem to want to give me an RPM which contains acpidump
> > > and
> > > all the yum servers are featuring scrogged checksums. I could build it, I
> > > guess, but there's a principle i
On Friday, 11 May 2007 23:02, Rafael J. Wysocki wrote:
> On Friday, 11 May 2007 22:28, Andrew Morton wrote:
> > On Fri, 11 May 2007 22:10:24 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > > > Index: linux-2.6.21/drivers/acpi/hardware/hwsleep.c
> > > > >
On Friday, 11 May 2007 22:28, Andrew Morton wrote:
> On Fri, 11 May 2007 22:10:24 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > > Index: linux-2.6.21/drivers/acpi/hardware/hwsleep.c
> > > > ===
> > > > --- linux-2.6.2
On Fri, 11 May 2007 22:10:24 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > Index: linux-2.6.21/drivers/acpi/hardware/hwsleep.c
> > > ===
> > > --- linux-2.6.21.orig/drivers/acpi/hardware/hwsleep.c
> > > +++ linux-2.6.21/d
On Friday, 11 May 2007 18:47, Andrew Morton wrote:
> On Thu, 10 May 2007 22:12:07 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > On Thursday, 10 May 2007 11:27, Thomas Gleixner wrote:
> > > On Thu, 2007-05-10 at 02:18 -0700, Andrew Morton wrote:
> > > > > > > If that patch makes the
PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/i386/kernel/apic.c |3 +
arch/i386/kernel/hpet.c | 71 ++---
arch/i386/kernel/i8253.c | 43 +--
include/linux/clockc
On Thursday, 10 May 2007 11:27, Thomas Gleixner wrote:
> On Thu, 2007-05-10 at 02:18 -0700, Andrew Morton wrote:
> > > > > If that patch makes the problem go away, then we should have a quite
> > > > > good hint what we need to look at.
> > > >
> > > > No joy, sorry. It still hangs at the last st
On Thu, 2007-05-10 at 02:18 -0700, Andrew Morton wrote:
> > > > If that patch makes the problem go away, then we should have a quite
> > > > good hint what we need to look at.
> > >
> > > No joy, sorry. It still hangs at the last statement in
> > > acpi_evaluate_object().
> >
> > Can you add "n
gt;
> > > can you test the alternative replacement patch for
> > >
> > > clockevents: Fix resume logic - updated version
> > >
> > > It does not touch the interrupt controller, it does the PIT restart
> > > different. That's a
On Thu, 2007-05-10 at 01:46 -0700, Andrew Morton wrote:
> On Wed, 09 May 2007 23:26:22 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Andrew,
> >
> > can you test the alternative replacement patch for
> >
> > clockevents: Fix resume logic -
On Wed, 09 May 2007 23:26:22 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> can you test the alternative replacement patch for
>
> clockevents: Fix resume logic - updated version
>
> It does not touch the interrupt controller, it does the PIT re
e watchdog for the TSC is reset.
But that's only touching some variables.
The other change is the way how the clock events are resumed. It touches
the PIT, local APIC and the interrupt controller.
Andrew,
can you test the alternative replacement patch for
clockevents: Fix resume logic
On Wednesday, 9 May 2007 22:45, Thomas Gleixner wrote:
> On Wed, 2007-05-09 at 20:36 +0200, Rafael J. Wysocki wrote:
> > Well, apparently, not in -mm2:
> >
> > [EMAIL PROTECTED]:~/src/mm/linux-2.6.21-mm2> grep -r -I -l
> > 'timekeeping_resume' *
> > kernel/time/timekeeping.c
> > [EMAIL PROTECTED]
On Wed, 2007-05-09 at 20:36 +0200, Rafael J. Wysocki wrote:
> Well, apparently, not in -mm2:
>
> [EMAIL PROTECTED]:~/src/mm/linux-2.6.21-mm2> grep -r -I -l
> 'timekeeping_resume' *
> kernel/time/timekeeping.c
> [EMAIL PROTECTED]:~/src/mm/linux-2.6.21-mm2> grep clocksource_resume
> kernel/time/ti
t; - platform_finish();
> > device_resume();
> > resume_console();
> > pr_debug("PM: writing image.\n");
>
> It now hangs in a similar fashion in the device_resume() call.
>
> If I back off Thomas's clocke
On Wednesday, 9 May 2007 19:15, Thomas Gleixner wrote:
> On Wed, 2007-05-09 at 19:09 +0200, Rafael J. Wysocki wrote:
> > > > Well, where is unregister_time_interpolator() called from?
> > >
> > > # grep -rn unregister_time_interpolator .
> > > ./kernel/timer.c:1893:unregister_time_interpolator(str
wer/disk.c
> @@ -205,7 +205,6 @@ int hibernate(void)
>
> if (in_suspend) {
> enable_nonboot_cpus();
> - platform_finish();
> device_resume();
> resume_console();
> pr_debug("PM: writing image.\n");
It now hangs in a simila
On Wed, 2007-05-09 at 19:09 +0200, Rafael J. Wysocki wrote:
> > > Well, where is unregister_time_interpolator() called from?
> >
> > # grep -rn unregister_time_interpolator .
> > ./kernel/timer.c:1893:unregister_time_interpolator(struct time_interpolator
> > *ti)
> > ./include/linux/timex.h:270:e
; > > > these patches against 2.6.21.
> > > > > >
> > > > > > yup, same hang with just these three:
> > > > > >
> > > > > > origin
> > > > > > clocksource-fix-resume-logic
> > > > > > clockevents-fix-re
at 01:31 -0700, Andrew Morton wrote:
> > > > > > I suspect I just tested the wrong thing yesterday. Let me recheck
> > > > > > just
> > > > > > these patches against 2.6.21.
> > > > >
> > > > > yup, same hang w
tested the wrong thing yesterday. Let me recheck
> > > > > just
> > > > > these patches against 2.6.21.
> > > >
> > > > yup, same hang with just these three:
> > > >
> > > > origin
> > > > cloc
> these patches against 2.6.21.
> > >
> > > yup, same hang with just these three:
> > >
> > > origin
> > > clocksource-fix-resume-logic
> > > clockevents-fix-resume-logic-updated-version
> >
> > I have no idea, how this affects
> these patches against 2.6.21.
> > >
> > > yup, same hang with just these three:
> > >
> > > origin
> > > clocksource-fix-resume-logic
> > > clockevents-fix-resume-logic-updated-version
> >
> > I have no idea, how this affects
just these three:
> >
> > origin
> > clocksource-fix-resume-logic
> > clockevents-fix-resume-logic-updated-version
>
> I have no idea, how this affects acpi_evaluate_object()
I think the problem is that the ACPI code ordering here is broken in a
difficult to fix way.
Defi
On Wed, 2007-05-09 at 01:31 -0700, Andrew Morton wrote:
> > I suspect I just tested the wrong thing yesterday. Let me recheck just
> > these patches against 2.6.21.
>
> yup, same hang with just these three:
>
> origin
> clocksource-fix-resume-logic
> clockevents-fi
> > > The machine is still hanging with this patch applied.
> >
> > What did change since yesterday ?
>
> I suspect I just tested the wrong thing yesterday. Let me recheck just
> these patches against 2.6.21.
yup, same hang with just these three:
origin
clocksource-f
On Wed, 09 May 2007 10:18:17 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-05-09 at 00:10 -0700, Andrew Morton wrote:
> > > > find an updated patch below. It fixes the problem on Ingo's
> > > > VAIO-of-fun-emulator and I got confirmation from several other affected
> > > > users,
On Wed, 2007-05-09 at 00:10 -0700, Andrew Morton wrote:
> > > find an updated patch below. It fixes the problem on Ingo's
> > > VAIO-of-fun-emulator and I got confirmation from several other affected
> > > users, that the patch series is still solving their problems.
> > >
> >
> > The machine is
On Tue, 8 May 2007 22:59:20 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 06 May 2007 17:03:03 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Andrew,
> >
> > On Sat, 2007-05-05 at 13:51 +0200, Ingo Molnar wrote:
> > > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > > >
On Sun, 06 May 2007 17:03:03 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> On Sat, 2007-05-05 at 13:51 +0200, Ingo Molnar wrote:
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > Fixup the existing users.
> > >
> > > This one makes the Vaio-of-fun hang during suspend t
On Sun, 06 May 2007 17:03:03 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-05-05 at 13:51 +0200, Ingo Molnar wrote:
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > Fixup the existing users.
> > >
> > > This one makes the Vaio-of-fun hang during suspend to disk. It g
ulator and I got confirmation from several other affected
users, that the patch series is still solving their problems.
tglx
>
Subject: clockevents: Fix resume logic
We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Fixup the existing users.
>
> This one makes the Vaio-of-fun hang during suspend to disk. It gets
> up to "swsusp: critical section/: done (%d pages copied)" then it
> freezes.
after trying to reproduce it on 2 boxes without success it did trigg
y 2.6.21 plus
origin
clocksource-fix-resume-logic
clockevents-fix-resume-logic
and that hung in the same fashion.
Config at http://userweb.kernel.org/~akpm/config-sony.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
100 matches
Mail list logo
