On Fri 2007-09-21 10:06:15, Thomas Gleixner wrote:
> On Fri, 2007-09-21 at 14:51 +1000, Paul Mackerras wrote:
> > Linus Torvalds writes:
> >
> > > It would indeed be nice if we could just take CPU's down early (while
> > > everything is working), and run the whole suspend code with just one CPU,
Thomas,
On Friday, 21 September 2007 21:16, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> > On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > > I simply rmmod'ed the processor module before suspend and the problem is
> > > solved a
Rafael,
On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > I simply rmmod'ed the processor module before suspend and the problem is
> > solved as well. The cpuidle patches make this problem more prominent due
> > to the poss
On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > > If you need any help from me with that, please let me know.
> > >
> > > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > > After
Rafael,
On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > If you need any help from me with that, please let me know.
> >
> > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > After debugging the swsusp_suspend() code path I figured out, that we
> > end u
Thomas,
On Friday, 21 September 2007 14:59, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 00:30 +0200, Rafael J. Wysocki wrote:
> > > -ETOOTIRED led me too a wrong conclusion, but still it is a valuable
> > > hint that this change is making things work again.
> >
> > Yes, it is.
> >
Rafael,
On Fri, 2007-09-21 at 00:30 +0200, Rafael J. Wysocki wrote:
> > -ETOOTIRED led me too a wrong conclusion, but still it is a valuable
> > hint that this change is making things work again.
>
> Yes, it is.
>
> > I need to go down into the details of the swsusp_suspend() code path to
> > fi
On Friday, 21 September 2007 09:56, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 19:35 -0400, Len Brown wrote:
> > > > (Btw, the above commit message points to just my response with a
> > > > testing
> > > > patch to the real email: the actual explanation of the INSANE ordering
> > > > is
> >
Thomas,
On Thursday, 20 September 2007 23:53, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > > We disable everything in device_suspend()
> >
> > No, we don't. sysdevs are _not_ suspended in device_suspend().
> > They are suspended in device_
On Fri, 2007-09-21 at 14:51 +1000, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > It would indeed be nice if we could just take CPU's down early (while
> > everything is working), and run the whole suspend code with just one CPU,
> > rather than having to worry about the ordering between C
On Thu, 2007-09-20 at 19:35 -0400, Len Brown wrote:
> > > (Btw, the above commit message points to just my response with a testing
> > > patch to the real email: the actual explanation of the INSANE ordering is
> > > from Len Brown in
> > >
> > >
> > > https://lists.linux-foundation.org/piper
Linus Torvalds writes:
> It would indeed be nice if we could just take CPU's down early (while
> everything is working), and run the whole suspend code with just one CPU,
> rather than having to worry about the ordering between CPU and device
> takedown.
That is certainly what we want to do on
On Thursday 20 September 2007 17:55, Linus Torvalds wrote:
>
> On Thu, 20 Sep 2007, Linus Torvalds wrote:
> >
> > (Btw, the above commit message points to just my response with a testing
> > patch to the real email: the actual explanation of the INSANE ordering is
> > from Len Brown in
> >
> >
On Friday, 21 September 2007 00:05, Thomas Gleixner wrote:
> Linus,
>
> On Thu, 2007-09-20 at 14:55 -0700, Linus Torvalds wrote:
> > And I think that's a damn reasonable thing to agree on: timers (and
> > anything else that CPU shutdown/bringup could *possibly* care about)
> > should be consider
Thomas,
On Thursday, 20 September 2007 23:53, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > > We disable everything in device_suspend()
> >
> > No, we don't. sysdevs are _not_ suspended in device_suspend().
> > They are suspended in device_
Linus,
On Thu, 2007-09-20 at 14:55 -0700, Linus Torvalds wrote:
> And I think that's a damn reasonable thing to agree on: timers (and
> anything else that CPU shutdown/bringup could *possibly* care about)
> should be considered core enough that they had better be on the
> suspend_late/resume_ea
Rafael,
On Thu, 2007-09-20 at 23:54 +0200, Rafael J. Wysocki wrote:
> > Hmm. This is close to the ordering we have in STR too.
> >
> > I have some dim memory of there being some ACPI reason why it had to be
> > done that way.
>
> Yes. We're executing _INI from the CPU initialization code and t
On Thu, 20 Sep 2007, Linus Torvalds wrote:
>
> (Btw, the above commit message points to just my response with a testing
> patch to the real email: the actual explanation of the INSANE ordering is
> from Len Brown in
>
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2006-Novem
Rafael,
On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > We disable everything in device_suspend()
>
> No, we don't. sysdevs are _not_ suspended in device_suspend().
> They are suspended in device_power_down(), which is called
> _after_ disable_nonboot_cpus() (from swsusp_suspend(
On Thursday, 20 September 2007 23:35, Linus Torvalds wrote:
>
> On Thu, 20 Sep 2007, Thomas Gleixner wrote:
> >
> > In meantime I figured out what's happening. The ordering in
> > hibernate_snapshot() is wrong. It does:
Actually, this is incorrect. Please read my reply to Thomas, just sent.
>
On Thu, 20 Sep 2007, Thomas Gleixner wrote:
>
> In meantime I figured out what's happening. The ordering in
> hibernate_snapshot() is wrong. It does:
Hmm. This is close to the ordering we have in STR too.
I have some dim memory of there being some ACPI reason why it had to be
done that way.
Thomas,
On Thursday, 20 September 2007 23:08, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 22:39 +0200, Rafael J. Wysocki wrote:
> > > Works as well. What's the difference between this and the real thing ?
> >
> > The real thing also calls device_power_down(PMSG_FREEZE), which is a
Rafael,
On Thu, 2007-09-20 at 22:39 +0200, Rafael J. Wysocki wrote:
> > Works as well. What's the difference between this and the real thing ?
>
> The real thing also calls device_power_down(PMSG_FREEZE), which is a
> counterpart of sysdev_shutdown(), more or less, and I think that's what goes
>
On Thursday, 20 September 2007 16:12, Rafael J. Wysocki wrote:
> On Thursday, 20 September 2007 15:43, Thomas Gleixner wrote:
> > On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > > > I haven't had the time to check if any special command line arguments
> > > > > help.
> > > > > Wi
On Thursday, 20 September 2007 17:49, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 16:50 +0200, Thomas Gleixner wrote:
> > > > > Well, the above may affect SMP systems, but the Vaio is UP. Hmm?
> > > >
> > > > My jinxed VAIO variant is SMP, but it looks like the same mysterious
> > > > error.
>
On Thu, 2007-09-20 at 16:50 +0200, Thomas Gleixner wrote:
> > > > Well, the above may affect SMP systems, but the Vaio is UP. Hmm?
> > >
> > > My jinxed VAIO variant is SMP, but it looks like the same mysterious
> > > error.
> >
> > Hm. Have you tried
> >
> > # echo test > /sys/power/disk
> >
On Thu, 2007-09-20 at 16:47 +0200, Rafael J. Wysocki wrote:
> On Thursday, 20 September 2007 15:53, Thomas Gleixner wrote:
> > On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > > > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
> > >
> > > ie. the one on the Vaio (I assume
On Thursday, 20 September 2007 15:53, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
> >
> > ie. the one on the Vaio (I assume).
> >
> > > I'm still fishing in rather dark water. Depending on the
On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
>
> ie. the one on the Vaio (I assume).
>
> > I'm still fishing in rather dark water. Depending on the added
> > instrumentation points the problem mutates up to the point whe
On Thursday, 20 September 2007 15:43, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > > I haven't had the time to check if any special command line arguments
> > > > help.
> > > > Will check tomorrow.
> > >
> > > Can you please disable the patches, which
On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > I haven't had the time to check if any special command line arguments
> > > help.
> > > Will check tomorrow.
> >
> > Can you please disable the patches, which I sent Linus wards:
> >
> > timekeeping-access-rtc-outside-xtime-lock.p
On Thursday, 20 September 2007 08:18, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 02:06 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 19 September 2007 21:21, Thomas Gleixner wrote:
> > > On Wed, 2007-09-19 at 19:44 +0200, Rafael J. Wysocki wrote:
> > > > > > It boots with nohpet alone and s
On Thu, 2007-09-20 at 02:06 +0200, Rafael J. Wysocki wrote:
> On Wednesday, 19 September 2007 21:21, Thomas Gleixner wrote:
> > On Wed, 2007-09-19 at 19:44 +0200, Rafael J. Wysocki wrote:
> > > > > It boots with nohpet alone and suspend/hibernation seem to work
> > > > > (still,
> > > > > it didn'
On Wednesday, 19 September 2007 21:21, Thomas Gleixner wrote:
> On Wed, 2007-09-19 at 19:44 +0200, Rafael J. Wysocki wrote:
> > > > It boots with nohpet alone and suspend/hibernation seem to work (still,
> > > > it didn't want to boot right after hibernation, but booted after I'd
> > > > switched
On Wed, 2007-09-19 at 19:44 +0200, Rafael J. Wysocki wrote:
> > > It boots with nohpet alone and suspend/hibernation seem to work (still,
> > > it didn't want to boot right after hibernation, but booted after I'd
> > > switched
> > > it off/on manually).
> >
> > Can you please check, whether
> >
On Wednesday, 19 September 2007 09:06, Thomas Gleixner wrote:
> On Tue, 2007-09-18 at 23:37 +0200, Rafael J. Wysocki wrote:
> > > > > - The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
> > > > >
> > > > > - And it hangs during suspend-to-RAM, due to git-acpi.patch
> > >
> > > Sor
On Tue, 2007-09-18 at 23:37 +0200, Rafael J. Wysocki wrote:
> > > > - The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
> > > >
> > > > - And it hangs during suspend-to-RAM, due to git-acpi.patch
> >
> > Sorry, I was wrong.
> >
> > > On my HP nx6325 it only boots with "noacpitime
On Tuesday, 18 September 2007 22:54, Rafael J. Wysocki wrote:
> On Tuesday, 18 September 2007 22:21, Rafael J. Wysocki wrote:
> > On Tuesday, 18 September 2007 10:18, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> > >
>
On Tuesday, 18 September 2007 22:21, Rafael J. Wysocki wrote:
> On Tuesday, 18 September 2007 10:18, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >
> > It took me
On Tuesday, 18 September 2007 10:18, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
>
> 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
>
> It took me over two solid days to get this lot compiling and booting on a few
> boxes.
40 matches
Mail list logo
