On Thu, 4 Aug 2005, Andrew Morton wrote:
> Michal Schmidt <[EMAIL PROTECTED]> wrote:
> >
> > Does resuming from swsuspend work for anyone with amd64-agp loaded?
>
> It would seem not ;)
Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp.
Michal Schmidt <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Does resuming from swsuspend work for anyone with amd64-agp loaded?
It would seem not ;)
> On my system when I suspend with amd64-agp loaded, I get a spontaneous
> reboot on resume. It reboots immediately after reading the saved image
>
Michal Schmidt [EMAIL PROTECTED] wrote:
Hello,
Does resuming from swsuspend work for anyone with amd64-agp loaded?
It would seem not ;)
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from
On Thu, 4 Aug 2005, Andrew Morton wrote:
Michal Schmidt [EMAIL PROTECTED] wrote:
Does resuming from swsuspend work for anyone with amd64-agp loaded?
It would seem not ;)
Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp.
System is an Averatec 3270 (Mobile Sempron
Hi!
Does resuming from swsuspend work for anyone with amd64-agp loaded?
It would seem not ;)
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible.
Andreas Steinmetz [EMAIL PROTECTED] wrote:
[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]
Seems that the linux-kernel list has the same result ;(
I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp
On Thu, 2005-08-04 at 17:15 -0700, Andrew Morton wrote:
Seems that the linux-kernel list has the same result ;(
Are you serious, LKML is subscribers only now?
Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
if (!swsusp_resume_device) {
- if (!strlen(resume_file))
+ if (!strlen(resume_file)) {
+ up(_sem);
return -ENOENT;
+ }
swsusp_resume_device = name_to_dev_t(resume_file);
pr_debug("swsusp: Resum
(resume_file))
+ if (!strlen(resume_file)) {
+ up(pm_sem);
return -ENOENT;
+ }
swsusp_resume_device = name_to_dev_t(resume_file);
pr_debug(swsusp: Resume From Partition %s\n, resume_file
On Mon, 2005-08-01 at 09:09 +0200, Pavel Machek wrote:
> Hi!
>
> > > If you think it is a linux bug, can you produce small test case doing
> > > just the sigwait, and post it on l-k with big title "sigwait() breaks
> > > when straced, and on suspend"?
> > >
> > > That way it is going to get
[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]
I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp (suspend to disk mode).
1. When I do not access any pcmcia device from initrd during boot
I have
Hi,
>> > If you think it is a linux bug, can you produce small test case
doing
>> > just the sigwait, and post it on l-k with big title "sigwait()
breaks
>> > when straced, and on suspend"?
>> >
>> > That way it is going to get some attetion, and you'll get either
>> > documentation or kernel
Hi!
> > If you think it is a linux bug, can you produce small test case doing
> > just the sigwait, and post it on l-k with big title "sigwait() breaks
> > when straced, and on suspend"?
> >
> > That way it is going to get some attetion, and you'll get either
> > documentation or kernel
On Sat, 2005-07-30 at 18:30 +0800, Pavel Machek wrote:
> Hi!
>
> > >> One other glitch is that pdnsd (a nameserver caching daemon) has
> crashed
> > >> when the system wakes up from swsusp. It also happens when
> waking up
> > >> f
On Sat, 2005-07-30 at 18:30 +0800, Pavel Machek wrote:
Hi!
One other glitch is that pdnsd (a nameserver caching daemon) has
crashed
when the system wakes up from swsusp. It also happens when
waking up
from S3, which was working with 2.6.11.4 although not with
2.6.13-rc3.
Many
Hi!
If you think it is a linux bug, can you produce small test case doing
just the sigwait, and post it on l-k with big title sigwait() breaks
when straced, and on suspend?
That way it is going to get some attetion, and you'll get either
documentation or kernel fixed.
Looks like
Hi,
If you think it is a linux bug, can you produce small test case
doing
just the sigwait, and post it on l-k with big title sigwait()
breaks
when straced, and on suspend?
That way it is going to get some attetion, and you'll get either
documentation or kernel fixed.
Looks like a
[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]
I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp (suspend to disk mode).
1. When I do not access any pcmcia device from initrd during boot
I have
On Mon, 2005-08-01 at 09:09 +0200, Pavel Machek wrote:
Hi!
If you think it is a linux bug, can you produce small test case doing
just the sigwait, and post it on l-k with big title sigwait() breaks
when straced, and on suspend?
That way it is going to get some attetion, and
Pavel Machek wrote:
> It looks good. Perhaps it should go into
> Documentation/power/swsusp-dmcrypt.txt? Could you write you copyright
> and GPL in there, sign it off, and cc: it to linux-kernel?
> Pavel
The attached pa
On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday, 30 of July 2005 15:13, Pavel Machek wrote:
> > Hi!
> >
> > > > px >= n + x
> > > >
> > > > or
> > > >
> > > > (p-1)x >= n
> > > >
> > > > or
> > > >
> > > > x >= n / (p-1).
> > > >
> > > > The
From: Michal Schmidt <[EMAIL PROTECTED]>
The function calc_nr uses an iterative algorithm to calculate the
number of pages needed for the image and the pagedir. Exactly the same
result can be obtained with a one-line expression.
Note that this was even proved correct ;-).
Signed-off-by: Michal
Hi,
On Saturday, 30 of July 2005 15:13, Pavel Machek wrote:
> Hi!
>
> > > px >= n + x
> > >
> > > or
> > >
> > > (p-1)x >= n
> > >
> > > or
> > >
> > > x >= n / (p-1).
> > >
> > > The obvious solution is
> > >
> > > x = ceiling(n / (p-1)),
> > >
> > > so calc_nr should return n +
On Pá 29-07-05 21:46:40, Michal Schmidt wrote:
> The function calc_nr uses an iterative algorithm to calculate the number
> of pages needed for the image and the pagedir. Exactly the same result
> can be obtained with a one-line expression.
>
> Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
Hi!
> > px >= n + x
> >
> > or
> >
> > (p-1)x >= n
> >
> > or
> >
> > x >= n / (p-1).
> >
> > The obvious solution is
> >
> > x = ceiling(n / (p-1)),
> >
> > so calc_nr should return n + ceiling(n / (p-1)), which is exactly what
> > Michal's patch computes.
>
> Nice. :-)
On Saturday, 30 of July 2005 03:35, Alan Stern wrote:
> On Fri, 29 Jul 2005, Michal Schmidt wrote:
>
> > Rafael J. Wysocki wrote:
> > > On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
> > >
> > >>The function calc_nr uses an iterative algorithm to calculate the number
> > >>of pages
Hi!
> >> One other glitch is that pdnsd (a nameserver caching daemon) has crashed
> >> when the system wakes up from swsusp. It also happens when waking up
> >> from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
> >> Many people have s
On Saturday, 30 of July 2005 03:35, Alan Stern wrote:
On Fri, 29 Jul 2005, Michal Schmidt wrote:
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image
On Pá 29-07-05 21:46:40, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
Hi,
On Saturday, 30 of July 2005 15:13, Pavel Machek wrote:
Hi!
px = n + x
or
(p-1)x = n
or
x = n / (p-1).
The obvious solution is
x = ceiling(n / (p-1)),
so calc_nr should return n + ceiling(n / (p-1)), which is exactly what
From: Michal Schmidt [EMAIL PROTECTED]
The function calc_nr uses an iterative algorithm to calculate the
number of pages needed for the image and the pagedir. Exactly the same
result can be obtained with a one-line expression.
Note that this was even proved correct ;-).
Signed-off-by: Michal
Pavel Machek wrote:
It looks good. Perhaps it should go into
Documentation/power/swsusp-dmcrypt.txt? Could you write you copyright
and GPL in there, sign it off, and cc: it to linux-kernel?
Pavel
The attached patch contains a mini
On Fri, 29 Jul 2005, Michal Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
> >
> >>The function calc_nr uses an iterative algorithm to calculate the number
> >>of pages needed for the image and the pagedir. Exactly the same result
> >>can
>> One other glitch is that pdnsd (a nameserver caching daemon) has crashed
>> when the system wakes up from swsusp. It also happens when waking up
>> from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
>> Many people have said mysql also does not sus
On Friday, 29 of July 2005 23:14, Michal Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
> >
> >>The function calc_nr uses an iterative algorithm to calculate the number
> >>of pages needed for the image and the pagedir. Exactly the same
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Could you please post
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
> The function calc_nr uses an iterative algorithm to calculate the number
> of pages needed for the image and the pagedir. Exactly the same result
> can be obtained with a one-line expression.
Could you please post the proof?
Rafael
--
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff -Nurp -X dontdiff.new
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff -Nurp -X dontdiff.new linux-mm/kernel/power/swsusp.c
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Could you please post the proof?
Rafael
--
-
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Could you please post
On Friday, 29 of July 2005 23:14, Michal Schmidt wrote:
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be
One other glitch is that pdnsd (a nameserver caching daemon) has crashed
when the system wakes up from swsusp. It also happens when waking up
from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
Many people have said mysql also does not suspend well. Is their use
On Fri, 29 Jul 2005, Michal Schmidt wrote:
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained
ardctl eject (assuming that the error is related to the
swsusp failing). The error is puzzling because physically ejecting
the card doesn't produce the message. I'll try to chase that one
down, and welcome any hints on where to look or what debugging to turn
on. I've looked in drivers/pcmcia/cs.c,
> So, in short, problem is that if you leave prism54 card in, even
> with module removed, swsusp hangs, right?
Right, in some circumstances. To narrow them down I spent many hours
rebooting into combinations of runlevels and loaded modules. It is
reproducible even in single-use
On Thursday, 28 of July 2005 23:36, Pavel Machek wrote:
> Hi!
>
> > >>If I don't eject the pcmcia card (usually a prism54 wireless card),
> > >>swsusp begins the process of hibernation, but never gets to the
> > >>writing pages part.
> >
> &
Hi!
> >>If I don't eject the pcmcia card (usually a prism54 wireless card),
> >>swsusp begins the process of hibernation, but never gets to the
> >>writing pages part.
>
> > Well, it really may be the firmware loading. Add some printks to
> > conf
>>If I don't eject the pcmcia card (usually a prism54 wireless card),
>>swsusp begins the process of hibernation, but never gets to the
>>writing pages part.
> Well, it really may be the firmware loading. Add some printks to
> confirm it, then fix it.
I did more tests, t
From: Ben Dooks <[EMAIL PROTECTED]>
Subject: Re: [PATCH][RFC] swsusp for OSK
Date: Fri, 8 Jul 2005 16:03:37 +0100
> Hmm, I have no idea if this is correct... I assume it is not saving
> the page tables over suspend/resume, and that is why you are having
> trouble restoring the
From: Ben Dooks [EMAIL PROTECTED]
Subject: Re: [PATCH][RFC] swsusp for OSK
Date: Fri, 8 Jul 2005 16:03:37 +0100
Hmm, I have no idea if this is correct... I assume it is not saving
the page tables over suspend/resume, and that is why you are having
trouble restoring the page table?
I looked
If I don't eject the pcmcia card (usually a prism54 wireless card),
swsusp begins the process of hibernation, but never gets to the
writing pages part.
Well, it really may be the firmware loading. Add some printks to
confirm it, then fix it.
I did more tests, this time with 2.6.13-rc3-mm2
Hi!
If I don't eject the pcmcia card (usually a prism54 wireless card),
swsusp begins the process of hibernation, but never gets to the
writing pages part.
Well, it really may be the firmware loading. Add some printks to
confirm it, then fix it.
I did more tests, this time with 2.6.13
On Thursday, 28 of July 2005 23:36, Pavel Machek wrote:
Hi!
If I don't eject the pcmcia card (usually a prism54 wireless card),
swsusp begins the process of hibernation, but never gets to the
writing pages part.
Well, it really may be the firmware loading. Add some printks
So, in short, problem is that if you leave prism54 card in, even
with module removed, swsusp hangs, right?
Right, in some circumstances. To narrow them down I spent many hours
rebooting into combinations of runlevels and loaded modules. It is
reproducible even in single-user mode
(assuming that the error is related to the
swsusp failing). The error is puzzling because physically ejecting
the card doesn't produce the message. I'll try to chase that one
down, and welcome any hints on where to look or what debugging to turn
on. I've looked in drivers/pcmcia/cs.c, which
[EMAIL PROTECTED] wrote:
> HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY
> DOCUMENT? :-) --P
My Pleasure!
I can test on x86_64 and I am willing to document.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this
op. He has access to all
>>>>your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
>>>>ssh-agent keys. Odds are good that he invokes swsusp by closing the
>>>>laptop. This patch gets us very close to nothing.
>>>>
>>>>4) You
, which in all likelihood includes your IPSEC, dm_crypt, and
> > > ssh-agent keys. Odds are good that he invokes swsusp by closing the
> > > laptop. This patch gets us very close to nothing.
> > >
> > > 4) You suspend your laptop between typing your GPG key pass
invokes swsusp by closing the
laptop. This patch gets us very close to nothing.
4) You suspend your laptop between typing your GPG key password and
hitting enter, thus leaving your password in memory when it would
otherwise be cleared. Then you resume your laptop and hit enter, thus
swsusp by closing the
laptop. This patch gets us very close to nothing.
4) You suspend your laptop between typing your GPG key password and
hitting enter, thus leaving your password in memory when it would
otherwise be cleared. Then you resume your laptop and hit enter, thus
clearing the password from
[EMAIL PROTECTED] wrote:
HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY
DOCUMENT? :-) --P
My Pleasure!
I can test on x86_64 and I am willing to document.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list:
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Well, "how long are my keys going to stay in swap after
> > > swsusp"... that's pretty scary.
> >
> > Either they're likely in RAM _anyway_ and are thus already trivially
&
Hi!
> > Well, "how long are my keys going to stay in swap after
> > swsusp"... that's pretty scary.
>
> Either they're likely in RAM _anyway_ and are thus already trivially
> accessible to the attacker (for things like dm_crypt or IPSEC or
> ssh-agent), or the
our box is up and running and an attacker gains
> > access, the contents of your suspend partition are the least of your
> > worries. It makes no sense to expend any effort defending against this
> > case, especially as it's liable to become a barrier to doing this
> > right, namely w
Hi!
> > > the attached patches are acked by Pavel and signed off by me
> >
> > OK, well I queued this up, without a changelog. Because you didn't send
> > one. Please do so. As it adds a new feature, quite a bit of info is
> > relevant.
>
> I don't like this patch. It reinvents a fair amount
pend any effort defending against this
> case, especially as it's liable to become a barrier to doing this
> right, namely with real dm_crypt encrypted swap.
Well, "how long are my keys going to stay in swap after
swsusp"... that's pretty scary.
To prevent "stolen while suspended
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> >
> > the attached patches are acked by Pavel and signed off by me
>
> OK, well I queued this up, without a changelog. Because you didn't send
> one. Please do so. As it adds a new
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
Andreas Steinmetz [EMAIL PROTECTED] wrote:
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature,
this
right, namely with real dm_crypt encrypted swap.
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
To prevent stolen while suspended case... you'd either need to enter
password both during suspend and during resume, or you'd need
asymetric crypto
Hi!
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
I don't like this patch. It reinvents a fair amount of dm_crypt
defending against this
case, especially as it's liable to become a barrier to doing this
right, namely with real dm_crypt encrypted swap.
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
Either they're likely in RAM _anyway_ and are thus already trivially
Hi!
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC or
ssh-agent), or the application took care to zero them out
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
Hi!
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
It should include a description
Andreas Steinmetz [EMAIL PROTECTED] wrote:
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
It should include a description of
Hi,
On Thursday, 21 of July 2005 21:20, Pavel Machek wrote:
> hi!
>
> > >>I'd like to get this tested under as many configurations as
> > >>possible. With this, your hdd should no longer do "yoyo" (spindown,
> > >>spinup, spindown) during suspend...
> > >
> > >
> > >It looks like the patch is
Hi,
On Thursday, 21 of July 2005 21:20, Pavel Machek wrote:
hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use
Hi!
> swsusp now mostly works on my TP 600X. If I don't eject the pcmcia card
> (usually a prism54 wireless card), swsusp begins the process of
> hibernation, but never gets to the writing pages part. The eth0 somehow
> tries to reload the firmware (as if it's b
swsusp now mostly works on my TP 600X. If I don't eject the pcmcia card
(usually a prism54 wireless card), swsusp begins the process of
hibernation, but never gets to the writing pages part. The eth0 somehow
tries to reload the firmware (as if it's been woken up), and then
everything hangs
swsusp now mostly works on my TP 600X. If I don't eject the pcmcia card
(usually a prism54 wireless card), swsusp begins the process of
hibernation, but never gets to the writing pages part. The eth0 somehow
tries to reload the firmware (as if it's been woken up), and then
everything hangs
Hi!
swsusp now mostly works on my TP 600X. If I don't eject the pcmcia card
(usually a prism54 wireless card), swsusp begins the process of
hibernation, but never gets to the writing pages part. The eth0 somehow
tries to reload the firmware (as if it's been woken up), and then
everything
On Thursday, 21 of July 2005 17:24, Michal Schmidt wrote:
> Pavel Machek wrote:
> >>I'm trying to do something similar for x86_64. See the attached patch.
> >>Unfortunately, it doesn't help. The behaviour seems unchanged (resume
> >>still works iff amd64-agp wasn't loaded before suspend).
> >
>
hi!
> >>I'd like to get this tested under as many configurations as
> >>possible. With this, your hdd should no longer do "yoyo" (spindown,
> >>spinup, spindown) during suspend...
> >
> >
> >It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
> >But my disks still yoyo during suspend.
Michal Schmidt wrote:
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do "yoyo" (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still
Pavel Machek wrote:
I'm trying to do something similar for x86_64. See the attached patch.
Unfortunately, it doesn't help. The behaviour seems unchanged (resume
still works iff amd64-agp wasn't loaded before suspend).
Are you sure problem is on level4_pgt? We probably use constant
level4_pgt
Hi!
> >Long time ago there were i386 problems because we assumed that kernel
> >is mapped in one big mapping and agp broke that assumption. Copying
> >pages backwards "fixed" it (and then we done proper fix). It should
> >not be, but it seems similar to this problem
>
> Do you mean this
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do "yoyo" (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still yoyo during suspend.
Pavel Machek wrote:
Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards "fixed" it (and then we done proper fix). It should
not be, but it seems similar to this problem
Do you mean this
On Thursday, 21 of July 2005 03:25, Michal Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
> >>I also tried putting a printk before restore_processor_state(), but I'm
> >>not sure if it is safe to use printk there.
> >
> >
> > Yes, it is,
On Thursday, 21 of July 2005 03:25, Michal Schmidt wrote:
Rafael J. Wysocki wrote:
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
I also tried putting a printk before restore_processor_state(), but I'm
not sure if it is safe to use printk there.
Yes, it is, but you may be
Pavel Machek wrote:
Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards fixed it (and then we done proper fix). It should
not be, but it seems similar to this problem
Do you mean this
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still yoyo during suspend. What
Hi!
Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards fixed it (and then we done proper fix). It should
not be, but it seems similar to this problem
Do you mean this patch of yours?:
Pavel Machek wrote:
I'm trying to do something similar for x86_64. See the attached patch.
Unfortunately, it doesn't help. The behaviour seems unchanged (resume
still works iff amd64-agp wasn't loaded before suspend).
Are you sure problem is on level4_pgt? We probably use constant
level4_pgt
Michal Schmidt wrote:
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still
hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still yoyo during suspend. What more is needed?
On Thursday, 21 of July 2005 17:24, Michal Schmidt wrote:
Pavel Machek wrote:
I'm trying to do something similar for x86_64. See the attached patch.
Unfortunately, it doesn't help. The behaviour seems unchanged (resume
still works iff amd64-agp wasn't loaded before suspend).
Are you
;);/*I added this*/
> BUG_ON (nr_copy_pages_check != nr_copy_pages);
> restore_highmem();
> device_power_up();
> ...
>
> I'm recording the screen during resuming with a digital camera to see if
> the added printk is displayed before the reset and I am
Rafael J. Wysocki wrote:
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
I also tried putting a printk before restore_processor_state(), but I'm
not sure if it is safe to use printk there.
Yes, it is, but you may be unable to see the message if the box reboots before
it can be
701 - 800 of 1613 matches
Mail list logo
