Hi Chen.
Is there any issue with saving and restoring MSRs unconditionally? That would
simplify the patch and make things 'just work'.
Regards,
Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Hi Yao.
On 17/08/15 13:59, Yao Yuan wrote:
> On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku@gmail.com > wrote:
>> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan wrote:
>>> Hi Leo,
>>>
>>> Thanks for your review.
>>> About those two methods for DMA suspend that you have mentioned. We
>> have a lot
Hi all.
I've rejoined LKML, so I'll try to help with reviewing PM patches. I'd
forgotten how much it is a case of sipping at a fire hydrant!
Regards,
Nigel
On 17/08/15 07:23, Jiri Kosina wrote:
> On Sat, 15 Aug 2015, Pavel Machek wrote:
>
>>> For forwarding hibernation key from EFI stub to boo
Hi.
On 15/12/13 07:36, Tejun Heo wrote:
On Sat, Dec 14, 2013 at 03:31:21PM -0500, Tejun Heo wrote:
So, all this is about hibernation? Does that mean that it's safe to
unfreeze before invoking resume? ie. we currently do,
freeze
suspend devs
resume devs
unfreez
Hi again.
On 14/12/13 10:07, Tejun Heo wrote:
Hello, Nigel.
On Sat, Dec 14, 2013 at 09:45:59AM +1100, Nigel Cunningham wrote:
In your first email, in the first substantial paragraph (starting
"Now, if the rest.."), you say "libata device removal waits for the
scheduled writeba
Hi Tejun.
Thanks for your work on this.
In your first email, in the first substantial paragraph (starting "Now,
if the rest.."), you say "libata device removal waits for the scheduled
writeback work item to finish". I wonder if that's the lynchpin. If we
know the device is gone, why are we tr
From 68e866b8eac534405ae16b79b7ffd9de05c11c67 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:50:22 +1100
Subject: [PATCH] Fix uninitialised variable in rbd_dev_probe_update_spec.
The local variable ret can be used uninitialised in the error path
if the kstrdup at line
From b4a7ab768df17e1cda7d0ae8744e986215a644c3 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:53:51 +1100
Subject: [PATCH] Remove unused variable in rbd_dev_probe_update_spec.
As an aside to the previous patch, remove the unused local
variable reply_buf in that function
From b41864867464bfe0e2d114528bc9b39e2d9f546e Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:03:50 +1100
Subject: [PATCH] Fix rbd use after free.
This patch addresses Coverity #753114.
The use of ceph_opts in rbd_add is currently confusing - there
are three possible
value of true. Add support for catching this model
via DMI matching.
There have been no BIOS updates for the VPCSE15FG, so I've not specified
a BIOS version in the criteria for matching.
Signed-off-by: Nigel Cunningham
---
arch/x86/include/asm/mc146818rtc.h |2 +-
drivers/rtc/Mak
Hi Greg.
Greg KH wrote:
On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Matthew Garrett wrote:
No, with a freezer-based model you can basically *never* suspend to
anything related to FUSE or a userspace USB device or anything involving
userspace iSCSI initiators or
Hi.
Greg KH wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that
Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're still going
to have to bmap the ext3 fs and pass the block lis
Hi.
Jesse Barnes wrote:
Well, it seems like we'll have to fix drivers in either case, and isn't a
kexec approach fundamentally more sound and simple, design-wise? Rafael
pointed out some problems with properly setting wakeup states, but I think
that could be overcome...
No. AFAICS, kexec is
Hi again.
Pavel Machek wrote:
Hi!
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
...
0
acpi_sleep= [HW,ACPI] S
Hi.
Rafael J. Wysocki wrote:
Len, please pick this up, thanks.
On Tuesday, 5 of February 2008, Pavel Machek wrote:
Small documentation fixes/additions that accumulated in my tree.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
diff --git a/
Hi Michael.
Michael Tokarev wrote:
Nigel Cunningham wrote:
[]
That should be doable. How is your UPS connected? Presumably, with some
modifications to the appropriate driver, we could send the commands when
we're ready to shutdown. It would probably be useful whether or not your
hibern
Hi.
Michael Tokarev wrote:
I'm trying to "glue" hibernation and UPS control
together, and have a question.
When the system power comes off an UPS (Uninterruptable
Power Supply I mean), it's probably a good idea to turn
the UPS off when shutting the system down or hibernating.
Even with shutdow
Hi.
Rafael J. Wysocki wrote:
> On Thursday, 17 of January 2008, Andrew Morton wrote:
>> On Thu, 17 Jan 2008 10:36:51 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, 2008-01-16 at 22:24 -0800, Andrew Morton wrote:
So I take everyone's latest and greatest product and injudiciously type
Hi all.
First up, sorry for not inlining the patch - trouble with line wrapping.
In 2.6.24-rc8, call_usermodehelper_exec has an exit path that can leave
the helper_lock() call at the top of the routine unbalanced. The
attached patch fixes this issue.
Signed-off-by: Nigel Cunningham <[EM
Hi.
Miklos Szeredi wrote:
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged users.
> This
>
Hi.
Miklos Szeredi wrote:
>> On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
>>> From: Miklos Szeredi <[EMAIL PROTECTED]>
>>>
>>> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>>>
>>> FUSE was designed from the beginning to be safe for unprivileged users.
>>> This
>>> has also been ve
Hi.
Berthold Cogel wrote:
> Al Viro schrieb:
>> On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote:
>>
>>> Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel
>>> paging request at virtual address 00100100
>>
>> LIST_POISON1
>>
>>> Jan 1 17:34:39 wonderland kernel: EIP is
Hi.
Pavel Machek wrote:
> On Fri 2008-01-04 21:54:06, Oliver Neukum wrote:
>> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
>>> Oliver Neukum wrote:
>>>> Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
>>>>> Oliver
Hi.
Oliver Neukum wrote:
> Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
>> Hi.
>>
>> Oliver Neukum wrote:
>>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
>>>> On top of this, I made a (too simple at the moment) freeze_filesy
Hi.
Oliver Neukum wrote:
> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
>> On top of this, I made a (too simple at the moment) freeze_filesystems
>> function which iterates through &super_blocks in reverse order, freezing
>> fuse filesystems or ordinary ones. I
Hi.
Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
>> Pavel Machek wrote:
>>>>>>>> So how do you handle threads that are blocked on I/O or a lock
>>>>>>>> during the system freeze process, then?
>&
Hi Martin.
Martin Steigerwald wrote:
> Am Mittwoch 02 Januar 2008 schrieb Nigel Cunningham:
>> Hi.
>
> Hi,
>
>> Rafael J. Wysocki wrote:
>>> On Wednesday, 2 of January 2008, Theodore Tso wrote:
>>>> On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cu
Hi.
Pavel Machek wrote:
> Hi!
>
>> So how do you handle threads that are blocked on I/O or a lock
>> during the system freeze process, then?
> We wait until they can continue.
So if I have a process blocked on an unavilable NFS mount, I can't
suspend?
>>> That's correct, y
Hi.
Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Theodore Tso wrote:
>> On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote:
>>>> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go
>>>> to
>>>> one o
Hi Ted.
Theodore Tso wrote:
> On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote:
>>> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go
>>> to
>>> one of the kernel-related lists, but I think linux-pm may be better for that
>
Hi Christian.
Christian Hesse wrote:
> On Tuesday 01 January 2008, Nigel Cunningham wrote:
>> Third, regarding the patch itself, I'm taking my time in working towards
>> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported [...].
>
> Well, I think I
Hi.
Rafael J. Wysocki wrote:
> On Tuesday, 1 of January 2008, Nigel Cunningham wrote:
>> Hi all.
>
> Hi Nigel,
Gidday :)
>> With the start of a new year, I suppose it's a good time to think about
>> what I'd like to do with TuxOnIce this year and see wha
Hi all.
With the start of a new year, I suppose it's a good time to think about
what I'd like to do with TuxOnIce this year and see what feedback I get.
First up, I'm thinking about closing the mailing lists and asking people
to use LKML instead for reporting issues and so on. I'm thinking about
Hi Berthold.
Berthold Cogel wrote:
> Jan 1 17:34:39 wonderland kernel: usb 2-2: USB disconnect, address 3
> Jan 1 17:34:39 wonderland kernel: usb 2-2.5: USB disconnect, address 4
> Jan 1 17:34:39 wonderland kernel: drivers/input/tablet/wacom_sys.c:
> wacom_sys_irq - usb_submit_urb failed with r
Hi.
Huang, Ying wrote:
> This patchset provides an enhancement to kexec/kdump. It implements
> the following features:
>
> - Backup/restore memory used both by the original kernel and the
> kexeced kernel.
Why the kexeced kernel as well?
[...]
> The features of this patchset can be used as f
Rene Herman wrote:
> On 12-12-07 00:55, Nigel Cunningham wrote:
>
>> (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)
>>
>> [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80
>> [EMAIL PROTECTED]:~/Downloads$ sudo ./port80
>> cycles:
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
>
> Posted a previous incar
Hi all.
Please excuse me if this has already been answered. I'm not currently
subscribed to LKML.
I've just been preparing a new tux-on-ice release against Linus' current tree,
and encountered a failure to freeze pid 1 when seeking to resume, using an
initrd:
[ 74.192734] Freezing of tasks
t; Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>
> ---
> kernel/signal.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.23-mm1/kernel/signal.c
>
Hi Dave et al.
On Saturday 13 October 2007 11:22:44 Dave Jones wrote:
> On Sat, Oct 13, 2007 at 11:11:31AM +1000, Nigel Cunningham wrote:
> > Hi all.
> >
> > Maybe I just picked a bad time to try, but...
> >
> > arch/x86/kernel/alternative.c: In function &#
Hi all.
Maybe I just picked a bad time to try, but...
arch/x86/kernel/alternative.c: In function 'apply_alternatives':
arch/x86/kernel/alternative.c:191: error: 'VSYSCALL_START' undeclared (first
use in this function)
arch/x86/kernel/alternative.c:191: error: (Each undeclared identifier is
repo
Hi.
On Monday 01 October 2007 08:28:02 Rafael J. Wysocki wrote:
> On Sunday, 30 September 2007 23:43, Nigel Cunningham wrote:
> > On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote:
> > > On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote:
>
Hi.
On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote:
> > Hi Rafael et al.
> >
> > This looks like it will be vanilla material, maybe 2.6.23 material?
>
> Well, I wouldn't l
Hi Rafael et al.
This looks like it will be vanilla material, maybe 2.6.23 material?
Regards,
Nigel
-- Forwarded Message --
Subject: [Suspend2-devel] [patch] 2.2.10.3 build fixes
Date: Sunday 30 September 2007
From: "Roman Dubtsov" (dubtsov gmail com)
Hi,
I have recently run
Hi.
On Thursday 27 September 2007 16:33:54 Huang, Ying wrote:
> On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote:
> > But, in my ignorance, I'm not sure even fixing the ext3 bug will
> > guarantee you consistent metadata so that you can handle a
> > swap/hibernate file. You can do a syn
Hi.
On Thursday 27 September 2007 06:30:36 Joseph Fannin wrote:
> On Fri, Sep 21, 2007 at 11:45:12AM +0200, Pavel Machek wrote:
> > Hi!
> > > >
> > > > Sounds doable, as long as you can cope with long command lines (which
> > > > shouldn't be a biggie). (If you've got a swapfile or parts of a swap
Hi.
On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote:
> I think that in order for this to work, there would need to be some
> ABI whereby the resume-ing kernel can pass its entire ACPI state and
> a bunch of other ACPI-related device details to the resume-ed kernel,
> which I believ
Hi.
On Friday 21 September 2007 22:18:19 Rafael J. Wysocki wrote:
> On Friday, 21 September 2007 13:58, Nigel Cunningham wrote:
> > Hi.
> >
> > On Friday 21 September 2007 21:56:29 Rafael J. Wysocki wrote:
> > > [Besides, the current hibernation userland in
Hi.
On Friday 21 September 2007 21:56:29 Rafael J. Wysocki wrote:
> [Besides, the current hibernation userland interface is used by default by
> openSUSE and it's also used by quite some Debian users, so we can't drop
> it overnight and it can't be implemented in a compatible way on top of the
> k
Hi.
On Friday 21 September 2007 12:45:57 Huang, Ying wrote:
> On Fri, 2007-09-21 at 12:25 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Friday 21 September 2007 12:18:57 Huang, Ying wrote:
> > > > That's not true. Kexec will itself be an implementation,
Hi.
On Friday 21 September 2007 12:18:57 Huang, Ying wrote:
> > That's not true. Kexec will itself be an implementation, otherwise you'd
end
> > up with people screaming about no hibernation support. And it won't result
in
> > the complete removal of the existing hibernation code from the kern
Hi.
On Friday 21 September 2007 11:41:06 Andrew Morton wrote:
> > On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> > > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi Andrew.
> &g
Hi.
On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
<[EMAIL PROTECTED]> wrote:
>
> > Hi Andrew.
> >
> > On Thursday 20 September 2007 20:09:41 Pavel Machek wrote:
> > &g
Hi Andrew.
On Thursday 20 September 2007 20:09:41 Pavel Machek wrote:
> Seems like good enough for -mm to me.
>
> Pavel
Andrew, if I recall correctly, you said a while ago that you didn't want
another hibernation implementati
Hi.
On Tuesday 11 September 2007 23:23:32 Rafael J. Wysocki wrote:
> On Tuesday, 11 September 2007 15:12, Rafael J. Wysocki wrote:
> > On Tuesday, 11 September 2007 13:55, Rafael J. Wysocki wrote:
> > > On Tuesday, 11 September 2007 13:27, Nigel Cunningham wrote:
> > >
Hi again.
On Tuesday 11 September 2007 21:55:06 Rafael J. Wysocki wrote:
> On Tuesday, 11 September 2007 13:27, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tuesday 11 September 2007 21:04:22 Rafael J. Wysocki wrote:
> > > On Tuesday, 11 September 2007 05:54, Nigel Cu
Hi.
On Tuesday 11 September 2007 21:04:22 Rafael J. Wysocki wrote:
> On Tuesday, 11 September 2007 05:54, Nigel Cunningham wrote:
> > Hi all.
> >
> > Commit 831441862956fffa17b9801db37e6ea1650b0f69 (Freezer: make kernel
threads
> > nonfreezable by default) breaks
t has been told to enter
the refrigerator. The original patch replaced a call to try_to_freeze() with a
call to yield(). I believe a simple reversion is wrong because
if !CONFIG_PM_SLEEP, try_to_freeze() is a noop. It should still yield.
Signed-off-by: Nigel Cunningham <[EMAIL P
Hi.
On Monday 20 August 2007 21:06:01 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> >
Hi.
On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
>
Hi.
On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > Hi all.
> >
> > In current git (and for a while now), an attempt to allocate memory with
> > GFP_ATOMIC will fail if we're below the low w
ndering if this behaviour is correct.
Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?
The following patch is a potential fix for GFP_ATOMIC.
Regards,
Nigel
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
page_alloc.c |4 ++--
1 file changed, 2
Hi.
On Tuesday 24 July 2007 08:05:21 Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 23 July 2007 15:05, Nigel Cunningham wrote:
> > Hi all.
> >
> > As we all know, pageflags have been a scarce resource for a while now.
These
> > patches seek to help address t
Hi.
On Tuesday 24 July 2007 01:23:15 Alan Stern wrote:
> On Mon, 23 Jul 2007, Nigel Cunningham wrote:
>
> > Take a step back for a second.
> >
> > The problem we're facing now is that we're getting some userspace threads,
> > used in processing I/O, t
Hi.
On Tuesday 24 July 2007 00:29:55 Arjan van de Ven wrote:
> On Mon, 2007-07-23 at 23:05 +1000, Nigel Cunningham wrote:
> > Hi all.
> >
> > As we all know, pageflags have been a scarce resource for a while now.
These
> > patches seek to help address that issue
Hi all.
Sorry for all of the copies.
I was holding the message in the outbox, and double clicking on it, trying to
get the encoding right in kmail. Needless to say now, it lied to me about
whether it was keeping the previous copy of email in the outbox or not.
Nigel
pgpSf0dckH1fV.pgp
Descrip
Bah.
Sorry for sending it twice. Fun with figuring out Kmail encoding.
Anyway, I forgot to include the stats in the previous message. Here they are.
[ 20.667431] Dynpageflags testing...
[ 20.667433] Set page 1...Ok.
[ 20.667440] Test memory hotplugging #1 ...Ok.
[ 20.667442] Test memory
Switch the "MappedToDisk" pageflag to using dynpageflags.
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
include/linux/page-flags.h |9 +
mm/dyn_pageflags.c |2 ++
mm/page_alloc.c|3 ++-
3 files changed, 9 insertions(+), 5 deletio
Switch PageSwapCache flag to use dynamically allocated pageflags.
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
include/linux/page-flags.h |7 ---
mm/dyn_pageflags.c |3 +++
2 files changed, 7 insertions(+), 3 deletions(-)
diff -ruNp 921-page-swap-cache-pageflag
Convert PageBuddy to dynamically allocate pageflags.
Again, not sure that we'd actually want to apply this, but it demonstrates
that the implementation is usable.
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
include/linux/page-flags.h |8
mm/dyn_pageflags.c
Hi all.
As we all know, pageflags have been a scarce resource for a while now. These
patches seek to help address that issue by adding support for a new type
of 'dynamically allocated' pageflag.
The basic idea is that we use per node & zone bitmaps built out of order zero
allocations, to repla
This patch adds the core of the support for dynamically allocated pageflags.
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
include/linux/dyn_pageflags.h | 65 +++
init/main.c |3
mm/Makefile |2
mm/dyn_pageflags.c
Convert PageSlab to use dynamically allocated page flags.
I'm not sure that we'll actually want to apply this, but it does work
(I'm using it as I type this).
Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>
include/linux/page-flags.h |8
mm/dyn_pagef
Hi.
On Monday 23 July 2007 10:04:43 Paul Mackerras wrote:
> Nigel Cunningham writes:
>
> > I guess I want to persist because all of these issues aren't utterly
> > unsolvable. It's just that we don't have the infrastructure yet to
> > figure out the solutio
On Monday 23 July 2007 09:09:21 Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 23 July 2007 00:42, Nigel Cunningham wrote:
> > Hi Alan.
> >
> > On Monday 23 July 2007 01:26:23 Alan Stern wrote:
> > > On Sun, 22 Jul 2007, Nigel Cunningham wrote:
> > &g
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
> On Sun, 22 Jul 2007, Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> > > It seems that you could still potentially get a failure to freeze if
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> It seems that you could still potentially get a failure to freeze if one
> FUSE process depends on another, and the one that is frozen second just
> happens to be waiting on the one that is frozen first when it is frozen.
> I admit
Hi.
On Sunday 22 July 2007 04:12:22 Miklos Szeredi wrote:
> > It seems that you could still potentially get a failure to freeze if one
> > FUSE process depends on another, and the one that is frozen second just
> > happens to be waiting on the one that is frozen first when it is frozen.
> > I admi
Hi.
On Saturday 21 July 2007 21:44:32 Miklos Szeredi wrote:
> > The problem with FUSE is related to the fact that the freezer can't
> > freeze uninterruptible tasks and we said that perhaps we might avoid
> > it if FUSE was made freezing-aware. Still, no one has gone in this
> > direction and I d
Hi.
On Saturday 21 July 2007 08:43:20 [EMAIL PROTECTED] wrote:
> On Fri, 20 Jul 2007, Alan Stern wrote:
>
> > On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
> >
> when doing a suspend-to-ram you get to a point where you just don't use
> any userspace.
> >>
> >>> What do you mean? Ho
Hi.
On Friday 20 July 2007 07:06:01 Agarwal, Lomesh wrote:
> So basically I can not install a signal handler to catch freeze signal
> in the process. Right?
> Is there any other way to solve the problem I am facing? After resume
> some of the system calls are failing in some of my applications wit
Hi.
On Thursday 19 July 2007 14:09:56 Agarwal, Lomesh wrote:
> Can you point me to code where kernel captures process in signal
> handling and code which runs after suspend to ram is finished?
Sure.
It's in kernel/signal.c (get_signal_to_deliver) for x86 and x86_64, and
arch//kernel/signal.c fo
Hi.
On Thursday 19 July 2007 09:42:02 Agarwal, Lomesh wrote:
> My understanding is that Linux kernel sends a signal to freeze processes
> during suspend2ram operation. Which signal is used to achieve this?
> The problem I am facing is that some of the system calls are failing
> with EINTR errno du
Hi.
On Thursday 19 July 2007 11:04:20 Andrew Morton wrote:
> On Sun, 15 Jul 2007 15:13:13 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> >
> > The changelog between v1 and v2
> >
> > 1. The kexec jump implementation is put into the kexec/kdump
> >framework instead of software suspend
Hi.
On Wednesday 18 July 2007 17:29:30 Rafael J. Wysocki wrote:
> Hi,
>
> The patches in these series update the freezer to eliminate some existing
> shortcomings, so please consider them as 2.6.23 material.
>
> The patches do the following:
> * update the freezer documentation to describe, prev
> parent. Make it happen.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>
Regards,
Nigel
pgp9Q66WSNcm9.pgp
Description: PGP signature
n
> documented. Fix it.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
pgprrm0584AZr.pgp
Description: PGP signature
t state the hardware is in
> > when you start the resume is a problem.
>
> As I understand it, running a different OS between the hibernate and
> the resume would violate the ACPI spec.
Well then, I know one or two people who would argue that the ACPI spec is
faulty. :\
Regards,
Ni
before preparing the patch? It's harder to
read
> > with all the "Only in..." lines.
>
> A lot simpler is to feed the patch through "grep -v"
Yeah. I was going for the general principle :)
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 C
Hi.
On Sunday 15 July 2007 17:13:13 Huang, Ying wrote:
> The complete changelog of the patch is as follow:
>
> ---
>
> Kexec base hibernation has some potential advantages over uswsusp and
> TuxOnIce (suspend2). Some most obvious advantages are:
>
> 1. The hibernation image size can exceed half
Hi.
On Sunday 15 July 2007 22:33:32 Rafael J. Wysocki wrote:
> Hi,
>
> Since many alternative approaches to hibernation are now being considered
and
> discussed, I thought it might be a good idea to list some things that in my
not
> so humble opinion should be taken care of by any hibernation f
Hi Jonathan.
On Monday 16 July 2007 07:00:29 Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
> use
Hi Dave et al.
On Friday 13 July 2007 14:53:46 Dave Jones wrote:
> On Fri, Jul 13, 2007 at 01:23:16PM +1000, Nigel Cunningham wrote:
> Fixed in cpufreq.git, will go to linus real soon.
> patch below..
Thanks!
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists,
Hi.
Current git compilation fails on my amd64:
CC [M]
arch/x86_64/kernel/cpufreq/../../../i386/kernel/cpu/cpufreq/acpi-cpufreq.o
CC [M]
arch/x86_64/kernel/cpufreq/../../../i386/kernel/cpu/cpufreq/powernow-k8.o
arch/x86_64/kernel/cpufreq/../../../i386/kernel/cpu/cpufreq/powernow-k8.c: In
Hi.
On Wednesday 11 July 2007 23:16:41 Jeremy Maitin-Shepard wrote:
> Nigel Cunningham <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > No other _proper_ solutions have been proposed. Everyone who suggests
removing
> > the freezer also suggests implementing it all ov
PF_NOFREEZE. PF_NOFREEZE says the related kernel thread
shouldn't be frozen (11 hits in the source tree I'm looking at). Grepping for
try_to_freeze gets 29. By the way, find drivers/ -name '*.[ch]' | xargs grep
try_to_freeze (for example) is a better search - it isn't
Hi.
On Thursday 12 July 2007 03:55:40 [EMAIL PROTECTED] wrote:
> On Wed, 11 Jul 2007, Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote:
> >>> Anyway, to implement the kexec approach we must separate the
>
Hi.
On Wednesday 11 July 2007 22:19:10 Rafael J. Wysocki wrote:
> The sync probably slows down more than the freezing itself ...
Absolutely. Wy more. Maybe it would help if you popped in some printks
that help people see that it's not the freezer taking a long time, but
syncing?
Nigel
p
1 - 100 of 613 matches
Mail list logo
