Hi,
On Sunday, 6 of March 2005 20:41, Pavel Machek wrote:
> Hi!
> > > > Yes. I thought about using PG_nosave in the begining, but there's a
> > > >
> > > > BUG_ON(PageReserved(page) && PageNosave(page));
> > > >
> > > > in swsusp.c:saveable() that I just didn't want to trigger. It seems to
>
Hi!
> > > Yes. I thought about using PG_nosave in the begining, but there's a
> > >
> > > BUG_ON(PageReserved(page) && PageNosave(page));
> > >
> > > in swsusp.c:saveable() that I just didn't want to trigger. It seems to
> > > me,
> > > though, that we don't need it any more, do we?
> >
> > N
On Saturday, 5 of March 2005 00:41, Pavel Machek wrote:
> Hi!
>
> > > Actually, take a look at Nigel's patch. He simply uses PageNosave
> > > instead of PageLocked -- that is cleaner.
> >
> > Yes. I thought about using PG_nosave in the begining, but there's a
> >
> > BUG_ON(PageReserved(page) &
Hi,
On Friday, 4 of March 2005 15:21, Nigel Cunningham wrote:
[-- snip --]
>
> Will something like this patch help?
>
[-- snip --]
I think that the changes below are unnecessary. free_all_bootmem() is
actually called _before_ the loop in mem_init() in which PG_nosave is set for
the first time,
Hi,
On Saturday, 5 of March 2005 02:10, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2005-03-05 at 10:41, Pavel Machek wrote:
> > > non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure
> > > that
> > > we do not break things by dumping stuff to where we should not write to).
> >
On Sat, Mar 05, 2005 at 10:37:29AM +1100, Nigel Cunningham wrote:
> On Sat, 2005-03-05 at 10:26, Rafael J. Wysocki wrote:
> > Yes, I think I'll just port the Nigel's patch to x86-64. BTW, it's striking
> > that we found similar solutions independently (I didn't know the Nigel's
> > patch before :-
Hi.
On Sat, 2005-03-05 at 10:41, Pavel Machek wrote:
> > non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure
> > that
> > we do not break things by dumping stuff to where we should not write to).
>
> I'm not sure if it is not better to save & restore non-RAM areas, but
> it
Hi.
On Sat, 2005-03-05 at 10:26, Rafael J. Wysocki wrote:
> Yes. I thought about using PG_nosave in the begining, but there's a
>
> BUG_ON(PageReserved(page) && PageNosave(page));
>
> in swsusp.c:saveable() that I just didn't want to trigger. It seems to me,
> though, that we don't need it any
Hi,
On Friday, 4 of March 2005 21:11, Pavel Machek wrote:
> Hi!
>
> > > > > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > > > > to save that :(. Not sure what to do with data e820 marked as
> > > > > reserved...
> > > >
> > > > Perhaps we need another page flag, like
Hi!
> > Actually, take a look at Nigel's patch. He simply uses PageNosave
> > instead of PageLocked -- that is cleaner.
>
> Yes. I thought about using PG_nosave in the begining, but there's a
>
> BUG_ON(PageReserved(page) && PageNosave(page));
>
> in swsusp.c:saveable() that I just didn't want
Hi!
> > > > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > > > to save that :(. Not sure what to do with data e820 marked as
> > > > reserved...
> > >
> > > Perhaps we need another page flag, like PG_readonly, and mark the pages
> > > reserved by the e820 as PG_reserved
Hi.
On Sat, 2005-03-05 at 00:15, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, 4 of March 2005 12:04, Pavel Machek wrote:
> > Hi!
> >
> > > > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > > > to save that :(. Not sure what to do with data e820 marked as
> > > > reserv
Hi.
On Fri, 2005-03-04 at 22:04, Pavel Machek wrote:
> Hi!
>
> > > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > > to save that :(. Not sure what to do with data e820 marked as
> > > reserved...
> >
> > Perhaps we need another page flag, like PG_readonly, and mark the
Hi,
On Friday, 4 of March 2005 12:04, Pavel Machek wrote:
> Hi!
>
> > > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > > to save that :(. Not sure what to do with data e820 marked as
> > > reserved...
> >
> > Perhaps we need another page flag, like PG_readonly, and mar
Hi!
> > IIRC kernel code/data is marked as PageReserved(), that's why we need
> > to save that :(. Not sure what to do with data e820 marked as
> > reserved...
>
> Perhaps we need another page flag, like PG_readonly, and mark the pages
> reserved by the e820 as PG_reserved | PG_readonly (the same
Hi,
On Thursday, 3 of March 2005 00:54, Pavel Machek wrote:
> Hi!
>
> > > > It seems that we write to the BIOS while moving the image, at least on
> > > > my box,
> > > > which is quite not correct, IMO.
> > [-- snip --]
> > > >
> > > > IMO this may lead to unexpected results, like the mysterio
Hi!
> > > It seems that we write to the BIOS while moving the image, at least on my
> > > box,
> > > which is quite not correct, IMO.
> [-- snip --]
> > >
> > > IMO this may lead to unexpected results, like the mysterious reboots
> > > during
> > > resume.
> >
> > Well, I always thought that R
Hi,
On Wednesday, 2 of March 2005 23:05, Pavel Machek wrote:
> Hi!
>
[-- snip --]
> > It seems that we write to the BIOS while moving the image, at least on my
> > box,
> > which is quite not correct, IMO.
[-- snip --]
> >
> > IMO this may lead to unexpected results, like the mysterious reboot
Hi!
> > > It sounds to me like we run at 2GHz from batteries at resume time, and
> > > that causes bad things (tm),
> [-- snip --]
>
> It seems that we write to the BIOS while moving the image, at least on my box,
> which is quite not correct, IMO.
...
> At the same time, from powernow-k8, I got
19 matches
Mail list logo
